In previous blog posts the benefits of NGSI version 2have been described, as a harmonized API for IoT Big Data ecosystems and particularly for exposing real time context information. Harmonized APIs are a necessary but not sufficient condition to foster developer-friendly IoT Big Data Ecosystems, which enable building smart applications. If data models are not harmonized, developers, in practice, get forced to change their application when porting it to another context (E.g. a different city).
Harmonizing data models means creating a shared vocabulary of terms and relationships that provide uniformity on the representation of different concepts: parking, public transport, weather… Harmonized APIs and data models, together, will enable the creation of smart applications that are portable at data level.
The FIWARE community has started an agile, implementation-driven process, to devise harmonized data models. Focusing initially on the smart city domain, the work is evolving on a daily basis and it is being registered on the documentation hosted in the related Github repository. Such documentation is currently written in markdown format and published to a readthedocs site. There is also a landing page /data-models (to be redirected from http://schema.fiware.org, as per schema.org recommendations) which provides fast and convenient access to the different data models. Such data models are published under the Creative Commons by Attribution License.
The design principles behind the FIWARE data models promote reuse, thus existing vocabularies, especially schema.org, have been adopted and leveraged. Other design principles are flexibility and simplicity, enabling a phased adoption by data providers and applications.
A first, draft version of the following models has already been provided:
Parking. They allow to model on street and off street parking areas. The data models reuse parts of the vocabulary defined by DATEX II
Waste Management. It is intended to model all the assets intervening on (municipal) waste management (containers, isles, etc.)
Streetlighting. They model urban streetlights and certain aspects of their controlling equipment
Water Quality. Captures different observed measurements (ph, conductivity, etc.) about the quality of water in rivers and lakes, or water intended to human consumption
Other data models to be developed and documented are Weather, Environment, Alarms, Devices or Parks & Gardens. Contributions, in the form of Github pull requests, are encouraged.
It is noteworthy that, at the time of writing, different FIWARE community members and telco operators worldwide (with GSMA support) are starting to experiment in real applications with the referred data models. As a result, valuable feedback can be obtained in order to refine them. The final aim is to contribute these data models to standards organizations, industry associations (particularly GSMA) or global community-driven efforts (schema.org).
José Manuel Cantera – Technological Expert. FIWARE Team
FIWARE is helping power a major new city initiative that is helping one Brazilian city embark on an ambitious city-as-platform approach. The Brazilian startup VM9 is creating a smart cities platform that has already been adopted by the Brazilian city of Nova Friburgo, in Rio de Janeiro.
VM9 are currently working with Nova Friburgo to establish a digital interface for citizens to connect with the local municipality and to carry out tasks like checking and providing feedback on planning legislation, creating their own maps, or making a public service request.
Citizen Portal: Meio Ambiente Digital
“The Municipal Secretary of Environment and Sustainable Urban Development (“Secretaria do Meio Ambiente”) is the organ of municipal government in Nova Friburgo responsible for a great number of activities related to territorial management, including licensing and civil constructions monitoring, supervision of environment preservation areas, and urban planning”, explains Marcos Marconi, Founder and IT coordinator at VM9.
The Municipal Secretary of Environment and Sustainable Urban Development uses the VM9 Smart Cities Platform to provide better services to citizens and improve internal productivity through the portal Meio Ambiente Digital.
Marconi says the current project for the digital portal has been divided into two phases. He explains:
The first objectives are:
To construct a robust municipal geospatial database to be publish for citizens and provide internal support for technicians of the Secretary during approval process of licensing and others, and
To simplify and improve the services offered for citizens from digital workflows of public requests and enhance internal management.
The second phase will start in 2017 and will be used to monitor air and water quality, environmental conditions, etc and to publish information to citizens through a variety of communication channels.
Marconi says that as a pilot project, Meio Ambiente Digital is already receiving much interest and praise.
Government and City as a Platform
In 2013, media publisher and tech visionary Tim O’Reilly wrote a key paper on “Government as a Platform”. This seminal text summarised the many global initiatives that demonstrate an emerging new approach to how government services are created and delivered. Instead of citizens being receivers of government services — with their main input being to vote every election cycle — O’Reilly envisions a new approach to government where “Internet technologies will allow us to rebuild the kind of participatory government”. O’Reilly describes the concept of Government as a Platform:
There is a new compact on the horizon: information produced by and on behalf of citizens is the lifeblood of the economy and the nation; government has a responsibility to treat that information as a national asset. Citizens are connected like never before and have the skill sets and passion to solve problems affecting them locally as well as nationally. Government information and services can be provided to citizens where and when they need them. Citizens are empowered to spark the innovation that will result in an improved approach to governance. In this model, government is a convener and an enabler rather than the first mover of civic action.
O’Reilly’s paper has encouraged the then-fledgling civic tech movement to evolve even further, and while we are still at the start of this journey, there are now many tech startups (like VM9) around the world focused on helping government engage with citizens and help citizens co-create government services and participatory mechanisms.
These ideas of government-as-a-platform are also being thought of in terms of the “City as a Platform”. In many ways, cities may be faster at being able to take up the challenge of evolving into platforms. Government institutions can be huge monoliths that must meet the diverse needs of a geographically dispersed population. Cities, on the other hand, are where we live, work, and play every day and are at a much more human scale of participation. We all want a say over the areas we live in, how accessible is our transport and walkability, our access to resources like schools, supermarkets, and childcare, our local air and water quality, our safety, and our free movement and leisure opportunities.
Historically, cities have been governed through nineteenth and twentieth-century ideas of civic organization and social norms. Much revolves around representative governance and centrally directed bureaucracies overseen by experts using strict, formal rules of procedure. Conceiving of cities as platforms represents a significant shift in how cities might function. An open platform honours self-organized, bottom-up participation in the style of open source software, for example. It regards rigid and complex rule-sets and non-transparency as irksome impediments.
VM9 as a City Platform Hub
Startups like VM9 are leveraging FIWARE to help cities implement this new platform model.
To make the ambitious project achievable, the VM9 team has divided its scope into 5 interconnected project areas, with each also able to operate as independent services.
Marconi lists these five areas as:
1. Internet of Things (IoT)
This module — called FI-Guardian — “is totally based on FIWARE GEs”, says Marconi. “It is being developed in partnership with the Federal University of Uberlândia (UFU) with a grant provided by National Council of Scientific and Technological Development (CNPq) under the Human Resources in Strategic Areas (RHAE) initiative. The FIWARE components are deployed in the FIWARE Lab infrastructure hosted by UFU”.
Marconi shares an early iteration of how the IoT Module makes use of FIWARE to create an IoT module for use by the city and its partners:
2. Web Geographic Information System (WebGIS)
“Here we have a WebGIS module which manages a GeoSpatial Database to deliver interfaces to citizens as interactive maps, geospatial searches, and geoinformation publishing”, Marconi explains. In this way it can be used completely independently, but Marconi also says as part of the platform it is integrated with the business process management project to “create a powerful Territorial Intelligence System which helps analysts and technicians to conclude analyses about processes related to urban planning and city growth".
3. Business Process Management (BPM)
This is at the core of the first phase of Meio Ambiente Digital and is an excellent real world example of what city-as-a-platform can mean in practice. “It lets citizens make administrative requirements for the government, monitor the progress of processes, printing payslips, make online payments, and fulfil desired requirements. This could include building approvals, obtaining environmental licenses, any procedures that need administrative interaction between governments and citizens. It is based on an smart motor of logical workflow controls, dynamic and configurable forms, notifications panels, permission rules, and level of authorities. With this module, institutions can become more efficient and, at the same time, deliver comfort and simplicity to citizens and customers”, says Marconi.
4. Electronic Content Management (ECM)
“This delivers an advanced system to create interrelationship between contents (photos, videos, sites and documents in general) and geographic data, in order to structure rich computerized geographical information databases to be published to citizens or used for technical teams, in order to qualifies digital workflows”.
5. Digital Communication Management (DCM)
This area will connect the IoT module — for example, for measuring air and water quality and environmental conditions — with communication channels that share the information in an accessible format to citizens and business.
In stage one, the focus is on the WebGIS (project 2), automated workflows for citizen engagement with planning and service requests (project 3) and content management that supports these areas (project 4).
Marconi says modules 2, 3, and 4 are all now working and available to citizens, having been deployed on April 18th this year.
In early 2017, VM9 will focus on the IoT (project 1) as document communication (project 5).
FIWARE generic enablers, such as the GIS Data Provider GE, are being used to power the current work in stage one to enable citizens to create their own maps through the Meio Ambiente platform. “We also have the strong intention to use Kurento GE in the project related to Digital Communication Management”, says Marconi.
A true smart city platform solution goes beyond efficiency of public service delivery to look at local economic development opportunities, and Marconi is excited about the work that VM9 has planned in this regard:
"Combos IOT is the next challenge for VM9. These will be pre-built packages of hardware and software, integrated with the VM9 Platform and focused on specific needs of the market, such as: environmental monitoring, health, urban mobility, etc. The objective is to simplify and accelerate the IoT adoption for our customers, through the delivery of complete solutions (plug-and-play) for specific IoT vertical markets".
The VM9 team is now racing to complete all module work by March 2017.
Blog, DevelopersComments Off on FIWARE and NGSIv2: towards harmonized APIs and data models for real-time context data
FIWARE is enabling a new generation of smarter applications which exploit large scale, real-time ‘context information’. Particularly, the NGSI version 2 API is aimed at making developer’s life easier, by providing simpler but powerful RESTful interfaces. Markedly, the combination of NGSI version 2 and harmonized data models enables the creation of portability at the data layer. As a result, a myriad of end-user applications can seamlessly work and interoperate in different scenarios, namely smart cities.
During 2015, GSMA, FIWARE (represented by Telefónica I+D) and Korea Telecom have been working on a project called ‘IoT Big Data Ecosystem’ (IoTBDE). One of the most interesting results of the IoTBDE project is a set of harmonized data models exposed through NGSI version 2. These harmonized data models have been instantiated in different datasets, which encompass actual data coming from different and original sources (cities, public organisms).
Additionally, the referred datasets have been used by real world showcases, demoed with great success at MWC 2016, The datasets have engaged remarkably well, both with cities (Porto, Santander, Seville, Antwerp) and with accelerated SMEs. In fact, such pilot datasets are a proof of a concept with a view to developing further standardization, particularly in the context of the Open and Agile Smart Cities (OASC) initiative.
The work already done has been focusing on the following data models and accompanying datasets:
Point of interest (entity type PointOfInterest). It models different points of interest such as public parking lots, weather or air quality stations, and others. The pilot dataset includes data both from cities and from public organisms.
forecast (entity type WeatherForecast). It models a weather forecast, including all the expected values for the different variables (temperature, humidity, wind speed, maximum, minimum, etc.). In the pilot datasets, the weather forecasts come from public state meteorology agencies, from Spain (AEMET) and Portugal (IPMA).
observed (entity type WeatherObserved). It represents weather observations offered by the automated weather stations owned by AEMET.
alarms (entity type WeatherAlarm). They correspond to weather alarms provided by the European Meteoalarm service.
Ambient observed (entity type AmbientObserved). This entity type corresponds to the observations of the air quality in a city. The pilot dataset offers real time pollution data from the city of Madrid. Also, the data from Santander and Porto is currently following the same data model.
Parking (StreetParking or ParkingLot). Smart parking data models capture information that is needed to optimize car mobility in cities. The pilot dataset includes data from Santander. The cities of Seville, Antwerp and Porto are currently offering their data following the same data model.
Practical examples of using the NGSIv2 API, implementation details and additional information, are all provided at the Github repository of the project.
The IoTBDE project has enabled the experimentation, and validated the suitability of the FIWARE-NGSIv2 (APIs plus harmonized data models) as a universal mechanism for sharing context data of different nature. Further work, which will be conducted together with GSMA, other telco operators and with the whole FIWARE Community, will involve the refinement and improvement of NGSI version 2 by including linked data features (JSON-LD), and the commencement of a more formal standardization work around data models.
Last but not least, we encourage entrepreneurs, developers and researchers to contribute to this exciting work and to continue experimenting and building nice stuff with FIWARE and its open APIs!
Jose Manuel Cantera Fonseca. Technological Expert (Telefónica I+D)
Blog, DevelopersComments Off on FIWARE Orion Data Source Now Available for Freeboard™
We are excited to announce that the FIWARE Orion data source is now available on Freeboard!
In a nutshell, Freeboard allows FIWARE developers to build real-time, interactive dashboards and visualizations in a matter of minutes using the intuitive drag & drop interface for data at Orion FIWARE. According to its own webpage, the advantages of using Freeboard include its simplicity (intuitive interface), its cost (you can get started for free), its production readiness and its open-source nature.
Among other functionalities, it offers the following features:
Flexible Data Sources
Development with Widgets (you can select from a list and add your own)
Drag & Drop Simplicity (you can change layouts easily)
Public or Private access
Freeboard duplication (duplicate any Freeboard and use it as a starting point for a new one –permission required)
You can share it instantly (every Freeboard has a unique URL that you can share via email, SMS and social networks)
On the other hand, Orion is one of the main enablers developed by FIWARE. It maintains and delivers context information (like sensor data collected by an Arduino, weather information gathered from a station, and so on), supporting standard OMA NGSI Publish-Subscribe APIs.
FIWARE always tries to help developers, service providers, enterprises and startups to develop products that satisfy their needs while still being open and innovative. This is why we were inspired to create an open source plugin for Bug Labs’ visual dashboard, Freeboard. Making the plugin was fast and easy thanks to the documentation and help provided by the Bug Labs folks. In just a few days, the plugin was up and running!
Freeboard showing sensor data from Thinking Things connected to FIWARE Orion
Using this new Orion FIWARE datasource, anyone can create an incredible dashboard in a couple of minutes without writing a single line of code. The plugin has been really well received at FIWARE IoT hackathons.
We hope you try the new Orion FIWARE data source on Freeboard.
DevelopersComments Off on Build your own IoT platform with FIWARE enablers
Connecting “objects” or “things” involves the need to overcome a set of problems arising in the different layers of the communication model. Using its data or acting upon them requires interaction with a heterogeneous environment of devices running different protocols (due to the lack of globally accepted standards), dispersed and accessible through multiple wireless technologies.
Devices have a lot of particularities so it is not feasible to provide a solution where one size fits all. They are resource constrained and can’t use full standard protocol stacks: they cannot transmit information too frequently due to battery drainage, they are not always reachable since they are connected through heterogeneous wireless networks, their communication protocols are too specific and lack integrated approach, and they use different data encoding languages, so it is tricky to find a global deployment.
Developers will face complex scenarios where merging the information is a real challenge. For this reason, approaching an IoT platform must enable intermediation and data gathering functions to deal withdevices variety and it must be configurable and adaptable to market needs.
Solving the complexity with an IoT Platform
Each of the problems exposed when connecting “things” can be solved using the different components and tools of an IoT platform: from a connector (IoT Agent) solving the issues of heterogeneous environments where devices with different protocols approach to a common data format: NGSI; to several enablers whose purposes are improving the capacities of the stored information (security tools, advanced data store models, historical retrieval of information, linkage to third party applications…). And all these features are possible when a powerful central enabler, such as Orion Context Broker, is the heart of the architecture, to gather and publish context information at large scale.
A walk throughout some of these components and functionalities would comprise from data acquisition and command execution at device level to data usage from external applications.
There must be an layer to mediate between devices and the core piece, Context Broker. This module, intended to be a gateway for devices willing to communicate with the rest of the components, is based on agents architecture due to the modularity required to integrate devices within the platform.
IoT Agents act as translators between the protocols that devices use to send or receive information, and a common language and data model across all the platform: FIWARE NGSI.
Currently, there is available:
Off-the-shelve IoT Agents. There are several IoT Agents available, supporting different device protocols: HTTP Ultralight, MQTT & OMA Lightweight M2M (LWM2M).
IoT Agent development framework. The framework is used when it is required to integrate proprietary device protocols. The framework comprises common tasks that simplify the development process, i.e. IoT Agents introduce certain security features, such as authentication of devices or authorization for the channel.
Context Broker has the ability of managing Context Information at large scale in order to be used by the applications or offer it to potential consumers. Managing this information is possible since Context Broker keeps virtual representations of the physical devices. Interaction with devices will happen by updating and modifying the virtual representations attached/corresponding to them.
From an architectural point of view, Context Broker acts as a blackboard in a typical blackboard architecture. It is the core and control piece of the platform, in charge of interacting with the other components and agglutinate data. Therefore, Context Broker plays a key role when developing a data/context scenario.
Functionalities offered by Context Broker can be exploited due to different operations compressed within NGSI APIs exposed.
Short Term Historic
Sometimes, third party applications query about explicit information that could be handled in a faster and simpler way than the one offered by a Big Data analytic tool (more focused in extract implicit, non trivial, information present in the data set). Common operations, such as calculating the minimum, maximum, mean, bias or deviation of a set of data can be performed using a time series database (called from now on Short Term Historic) accurate for these scenarios, without an intermediate step of processing the whole set of data in order to obtain the desired information (and many other information) as insights.
CEP (Complex Event Processing)
Complex Event Processing is intended to analyse and react to events, generating immediate response and triggering actions due to changing conditions. It makes possible instant response or reaction to situations (conditions based on a series of events occurring within a time window) instead of to singular isolated events as other standard reactive apps do. For instance, actions launched through the CEP enabler could be SMS delivery, mail notifications, etc.
Security in the platform
Enablesthe identity management and access control policies: the platform supports an scheme of identity management, authentication and authorization based on three main elements: IdM, PEP, and PAP/PDP. These three elements exist inside the following enablers of the architecture:
The Identity Manager (IdM)carries the information about users, roles and profiles. It also sends and validates tokens, as well as authentication mechanisms.
A Policy Enforcement Point, or PEP, is meant to catch the request from a certain component, and force the requirements specified in terms of identification and authorization for that specific component, before start using it. PEP proxy is in charge of orchestrating all the communications between the IdM element and the PDP element.
For management and assessment of policies, the Access Control enabler chooses the requests after selecting the allowed or banned actions for each role vs. component.
The faster alternative to start working with the IoT Agents and Context Broker, is using the FIWARE Lab global instance, or deploy your IoT Bundle, available here:
This year as a new feature, the conference will be a single event bringing together all of Net Futures' interest groups around cross-cutting topics: IoT, open source, cloud, smart cities, and start-ups. It will also include consultation meetings that cover all Net Futures' topics: Network Technologies, Software & Services, Cloud, Net Innovation and Experimental Platforms.
The event will be structured around three pillars that represent stages in the life-cycle of an idea: research and innovation, technological validation, and final delivery to market. We want you to be involved!
Join us and share your thoughts and visionary ideas to provoke discussion and develop best practices. We are looking for creative approaches that can converge to define future research and innovation that drives the digital economy.
Come to hear the talks from some of the most influential minds in research and innovation. Participate in the cross-cutting sessions, unconference and FIWARE hackathon. There will also be a showcase of successful projects that became reality through funding by European Commission.
A full programme for both days will soon be available on the Net Futures 2015 website. Follow @netfuturesEU on twitter and ask any questions using the#netfutures15 hashtag.
Blog, DevelopersComments Off on Contribute to FIWARE Lab Ecosystem with your own IoT!
The following post was written by Carlos Ralli Ucendo. We would like to thank him for his helpfulness and his collaboration.
FIWARE Lab enables you to connect IoT devices in a private environment for your own Apps exploitation, but it also enables you to connect and share them publicly available for any other developer interested. This article focuses on the later approach, although it might work well as a learning exercise for the other goal.
The following diagram depicts the components in the FIWARE Lab for most IoT scenarios.
Our exercise today will focus on IDAS4, Orion4 and the Global ContextBroker enablers:
IDAS4 is the component you will use to register your devices and send their observations (measurements). IoT Providers are organized in “Services”, for instance the Smartcity of Seville will use an specific service. For public sharing, we use a specific service called “OpenIoT”.
Orion4 is the ContextBroker where all the data of “OpenIoT” service will be sent. Therefore anyone may access the Data of your IoT devices accessing his component.
Global ContextBroker: All the Context data at Orion4 is sent to the Global ContextBroker, which is a single access point for your data plus all smartcities connected to FIWARE.
To configure and connect your devices to IDAS4 there are three basic steps to cover:
Create a Model. All devices are based in models. We provide several models you can reuse and you may create your own ones too.
Register a Device+Asset. The platform needs to know your device before observations are sent. You need to clarify the Model the device is based on, a “Device ID” (that will be used in the southbound of IDAS4) and the “Asset ID” (that will be used in the Northbound of IDAS4 and therefore in the ContextBroker). The reason to have Device and Asset IDs is to decouple a physical device from a logical device. For instance, you may have “Vendor:model:Unique_ID” as “Device ID” and “Temperature_Garden_Ground” as asset name which is more meaningful and does not need to be changed if later on the physical device is replaced due to a failure or evolution.
Send Observations/Measurements. For devices to be able to send measurements to a service, for instance “OpenIoT” at IDAS4, a shared secret that we call API-KEY needs to be known. For OpenIoT is “”.
Later on you can read the last status and subscribe to changes of the devices at the ContextBroker. You may use Orion4 or the Global ContextBroker for that.
IDAS4 and ORION4 expose easy-to-use REST APIs that are well described in this presentation:
These are basically tools to interact with IDAS and the ContextBroker written in Python2.7, so you can easily run them on many gateway platforms, such as a RaspberryPI, but also you may run them in a computer (MACOS, Linux or anyone with python) and play with virtual sensors too.
Getting started is extremely easy. For a first exercise, let’s create a virtual temperature sensor in a few steps:
IDAS4 and Orion4 are obviously protected to avoid malicious usage and therefore access to them is protected with an Identity Proxy that can only be traversed if your request holds a valid Token in the HTTP headers.
Obtaining your Token is easy, just run the “python/GetToken.py” script. You will be prompted for your FIWARE account and password and a valid token for you will be printed in the screen (copy and paste it for use it in the next step). Token will expire after sometime but you’ll be able to use it for some days at least.
3. Configure python/config.ini file
Edit config.ini file and configure the following section with your FIWARE account username and the Token you obtained in the previous step:
Also configure the section identifying your computer, gateway or device. You just need to provide the system type and a unique identifier (recommended last 3 bytes in hexa of a MAC address or your FIWARE username). I included some fake ones for this example.
4. Register your Device
Note that the first argument is a generic model for a temperature sensor available at OpenIoT service, “Sensor1” is the name we choose for our physical device and “Temperature-Madrid28001” is a more meaningful name for App developers willing to use my outdoor temperature sensor (by including city and ZIP code).
Running this script will provide you with the actual IDs associated to your device (the prefix of your host identifier in the config.ini file is used as a prefix so you can easily look for your devices in the IDAS4, Orion4 or the Global ContextBroker later on).
5. Send Observations/Measurements
Once the device is registered, we can send new data, for instance temperature = 25, with:
Note that the first argument is the Device ID obtained as the result of the script in the previous step and ‘t|26’ is a payload composed by ‘[Measurement alias]|[value]’. Measurement aliases are the way to reduce the observation payload and they are described in the Model used to register the device.
6. Reading your data:
Sensor data is accessed at the ContextBroker. You may use FIGWAY scripts for that too:
Note that the first argument is the Entity ID that was provided to us when registering the device, that is based in the Asset name which is thought to be more meaningful for other developers than the Device name.
The ContextBroker offers you the possibility to subscribe to changes in Entity’s attributes. This way your App may get subscribed to changes in a specific observation of your devices. FIGWAY tools at “python/ContextBroker” folder allow you to test subscriptions with the “SetSubscription.py”, “SubscriptionDaemon.py” and “SubscriptionHandler.py” scripts, please read “README.md” file for more information on this.
What if I want to create other kind of sensors?
The step is to check whether there is a suitable available model for your purpose in the IDAS4 service we are using (“OpenIoT”). This might be done this way:
Once you know available models, you may check details of each one:
If finally you conclude there is no suitable Model for your specific IoT device, you may create your own by creating your model at “python/SensorsUL20/models” folder (check examples provided in that folder) and then run:
Where MODEL_FILE is the file holding the new model you want to create that must be located in the “/SensorsUL20/models” folder.
How to connect physical sensors instead of virtual ones?
The process is exactly the same as for the virtual sensors. Actually you can perform all those steps from your computer and just send the observations (step 5) from your IoT devices.
How you adapt step 5 to your specific platform is highly dependent on your IoT hardware/software. For instance, if your platform supports python2.7 you may just copy (and adapt if needed) the script SendObservation.py.
However, several platforms might not support a Python2.7 environment so you need to perform the HTTP post on your own. Just take into account:
What if I want to connect an actuator?
Maybe you are connecting a device that is capable of receiving commands (an actuator). Actuators can be synchronous (they receive the commands immediately) or asynchronous (they ask IDAS for pending commands from time to time).
Synchronous sensors need to implement a server to receive commands and their network connectivity needs to allow it, which is not always easy as long as they are behind a firewall and/or NAT with private IP addresses.
IDAS and FIGWAY tools support both types of sensors, but we will explain in this section only the asynchronous case as long as it is the one IDAS provides more added-value. We call this case “pooling commands”.
So let’s imagine we have got a switch that is driving a LED Lamp with the 3 RGB colours. The switch needs to receive commands in the form of “Get R-G-B” where R, G and B are numbers from 0 to 99 related to the intensity of each basic color.
Let’s assume also that the switch does not need to drive the lamp immediately after a command is issued but only needs to be updated every 5 minutes (asynchronous operation).
Let’s imagine the switch is connected to a RaspberryPI running FIGWAY tools and deployed in a private IPv4 network. Let’s assume it is connected to the Internet through and ADSL connection and the ADSL router runs a NAT to connect it all to the public Internet.
The first thing we would do is to create the device/asset with the model “SWITCH”, which is already available at the OpenIoT service.
The second thing is to generate a Command and send it to IDAS2.6. This can be done from anywhere in the Internet, but for this example we do it from the RaspberryPI too. You just need to clarify the Asset ID and the command to send.
At this point it is useful to understand how IDAS pooling commands work to check the command queue status (also from anywhere) for an specific Asset ID.
The third step is to collect pending commands from the device (in this case the RaspberryPI). Here we use the Device ID (not the Asset ID) as we target the southbound device API. According to the example description, we should run this every 5 minutes.
Finally, once we’ve got the command we should trigger our command to operate the LED SWITCH with the received command information.
Also, at this point we may check the queue again to see the command has been consumed.
If you are connecting actuators maybe you are not willing to share them publicly, the following section will guide you on that purpose.
What if I do not want to publicly share my IoT devices?
Our recommendation is to practice first by creating a public virtual sensor as explained above.
In this scenario, normally you will deploy your own instance of the ContextBroker, normally deployed with the blueprint facility of the FIWARE Cloud.
After that, just request us (firstname.lastname@example.org) to create your own service “MyServicenameProposal” at IDAS4 plus the details of your ContextBroker (IP address and port).
We will provide you then with the given service name and the API-Key that you only will know, so no other devices will be able to send data. Then simply provide the ContextBroker details and access to your partners developing Apps for you.
This post tells the use of FIWARE made by the developers of BotCar/Wadjet, winners of the mention as Best IoT Solution in the FIWARE Excellence Challenge (October 2014). Thanks to them for the collaboration!
I'm sure you remember The Knight Rider well, don't you? Many times along the TV series, Michael Knight said to KITT: "keep your scanners peeled"; and we all thought: "wow, how amazing it would be to talk to your car". Do you remember it? Well, this is what we can do with BotCar, an IoT platform that lets drivers talk to their cars and that was recently recognized as the Best IoT solution within the FIWARE Excellence Challenge celebrated last October in Las Palmas, where we competed under the Project name of Wadjet.
Nowadays a standard vehicle has among 60 and 70 sensors, such sensors are producing tons of data each time you drive. Your car is itching to share all these data with you in real time as KITT used to do, but it is simply not able to do it, it can't connect with you.
BotCar solves this for you, our solution gathers all the data produced by the car, processes them and gives back to you in real time the insights you need to save up to 20% of your fuel consumption, while letting you know, just in time, the meaning of the orange light which has just switched on again in the dashboard of your car and how to solve it, improving the safety of the passengers on board by giving the car the capability of sending an immediate alert to the emergency services in case of crash.
BotCar comprises a combination of a hardware device and a software solution developed with Node.js and Mongo.db. The hardware device is connected to the car through a plug & play solution and captures all the information from the sensors of the vehicle. As the device includes both a GSM and Bluethooth 4.0 modules, the information is sent to a server directly or via smart phone. Then the logs of data are processed in real time giving back to the user specific feedback via web service and mobile app.
As you can imagine, the architecture of BotCar fits quite well with the FIWARE Technology. On the one hand, we tackle a global need and we wish to change the world, so we need to be ready for a huge and rapid scalability. On the other hand, we face specific needs related to Big Data and to machine to machine automations based on physical sensors.
In such a context FIWARE is the perfect match, as it was designed fully focused in supporting the Internet of Things world as it was already proven in several Smart Cities across Europe. This IoT specialized approach is what makes the difference among FIWARE and other platform technologies, so, for a project like BotCar, purely IoT, FIWARE is the right choice; on the other hand, our Startup nature can leverage from the zero investment requirement of using FIWARE, which undoubtedly gives to FIWARE a singularity. Therefore we have chosen four FIWARE Generic Enablers to enhance our solution. Our selection comprises: the FIWARE Cloud GE, Object Storage GE, COSMO GE, and ORION Context Broker.
The FIWARE Cloud provides us a GUI to manage the services and resources deployed. We use the Object Storage GE to store all the logs generated in a given trip, these data is storaged in a raw manner, without any kind of processing. The Big Data needs are solved by the COSMO GE, it let us to anonymize all the data which lets us optimize data mining, providing aggregate added value to the users through benchmarking features, and to third parties like insurance companies, automotive industry, fleet transport companies, or Smart Cities. Finally, the ORION Context Broker GE gives us the capability of storing those logs specifically related to automations and alerting features like the last position in which the car was located to alert about steals or parking incidents.
So, remember, with FIWARE technologies you can say to all of your Things "keep your scanners peeled", to empower the users to interact with their Things is easier, cheaper and more scalable using FIWARE.