Ex Machina: Middleware for a modbus energy monitoring solution

In early May, Ex Machina, one of the 8 winners of the first open call, presented its progress with the AGILE platform to professional IoT developers and advanced IoT geeks in Athens.

Manolis Nikiforakis, Ex Machina CEO, described an environment for building powerful industrial IoT solution, using a typical energy monitoring use-case as an example.

The Ex Machina solution is built on open source technologies like Eclipse Kura, Eclipse Kapua, Eclipse hawkBit, Thingsboard.io, Agile-IoT, Resin.io, Node-RED, openHAB, Raspberry Pi, ESP8266/32, Modbus, and MQTT.

Our Testbed is here for YOU !

Do you want to try AGILE but you don’t have access to a RaspberryPi and a SensorTag? Use our Testbed hosted by our partner, INRIA.

Here is a short demo explaining how to connect:

Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Link to wiki page: https://github.com/Agile-IoT/AGILE-Testbed/

FORSEC Published Book – AGILE Collaboration

AGILE has collaborated with a Bavarian project called FORSEC. FORSEC has recently published a book collecting their results, in which they mention their collaboration with AGILE. In particular, they mention how UPFROnt, a policy framework developed within FORSEC, that is also used by AGILE, uses the AGILE Identity Management Framework.

Moreover, as UPFROnt is included as part of SEDARI, a framework to store and apply policies to data in the Cloud, the collaboration with AGILE turns SEDARI into an Oauth2 server and OAuth2 provider. They also mentioned that these capabilities are considered essential for IoT applications.

Thank you FORSEC for acknowledging our collaboration. We are pleased that both projects could help each other to achieve their goals!

Midterm project status

A set of new presentations are published. They describe the progress and the achievements of the AGILE-IoT project during the last 18 months.

Enjoy !

Using the AGILE framework to implement a Quantified Self application: Advantages and Challenges

New biosensors are released daily promising to help us monitor important biosignal parameters.  Until recently, lower priority has been given to interoperability while emphasis has been put on data collection, many times on remote servers without the level of guarantees that the user’s data will not be misused.  The AGILE software stack with the component-based architecture and open source licensing and development model allows for the implementation of a fully-fledged gateway under the user’s control.

The proliferation of a multitude of biosignal sensors and activity trackers to gather user biosignal and wellness attributes poses unique challenges for their effective integration into user-centric applications which will provide valuable insights and promote healthy behaviors. Such sensors include medical sensors for biosignals such as heart-rate, oxygen saturation and weight, b) trackers measuring activity and steps, and c) smartwatches that also incorporate the biosignal or activity measurement functionality.

The architecture of the AGILE Software stack allows for the integration of new sensors increasing the usefulness of the Agile Gateway in many applications. In order to ease access to sensors data the Agile –IoT project has defined a set of REST commands which homogenize access to sensors. Unfortunately, due to the great variance of features and access protocols between devices, great effort is needed to integrate them via the implementation of corresponding device drivers but the architecture of the AGILE software stack aims to ease these difficulties.  AGILE offers two methods of device integration:

  • Protocol-based implementation: Implementation of functionality which converts device communication to Agile compliant protocol primitives.
  • Device based implementation: Implementation of device communication using existing AGILE PAN networking protocols. Bluetooth Low Energy and Zigbee are currently supported.

Sensor values from BLE devices can have various formats depending on the underlying parameter that is being measured.  The values sent to the gateways can be sent as:

  • Single Measurements: The information of the measured parameter is fully described in a single transaction. Devices that send data in this way include blood pressure monitors and glucometers.
  • Multiple Measurements: Information is dependent upon a sequence of measured values in a specific timeframe ranging from seconds to hours. Devices which fall in this category include oximeters and ECGs.
  • Continuous Monitoring: In this case, data is sent to the gateway in real-time or stored continuously on the device until connectivity to the gateway is possible. Wearables (activity trackers and smartwatches) as well as sensors that monitor continuously various biosignals belong to this category.

The Quantified Self Application

The Quantified Self application uses the AGILE software stack to access data from the supported sensors.  The application allows the user to monitor his activity against predefined goals. Sensor-based and cloud-sourced data can be used to quantify the progress.

Figure 1. Activity Summary and User Goals

 

 

 

 

 

 

 

 

 

Figure 2. Sensor and Cloud Activity Visualizations

The application also allows the monitoring of the following biosignals via supported devices

  • Blood Pressure
  • Heart Rate
  • Oxygen Saturation
  • Body Weight

Figure 3. Biosignal Visualizations

 

 

 

 

 

 

 

 

 

 

 

 

*The Quantified-Self application has been developed by BioAssist S.A. in the frame of the respective AGILE Pilot.

Trusted Data Sharing with Linked Data in the Internet of Things (IoT)

This post intends to give the reader a perspective on how Jolocom brings trusted data sharing to the AGILE IoT Gateway (AGILE is a H2020 project). It should provide essential value to the user, not only but also in context of the internet of things, and not least to benefits from the EU’s General Data Protection Regulation (GDPR).

The original idea of the World Wide Web

To start with, the vision of Jolocom aligns with the original idea of the World Wide Web, which was distributed: everyone would have their own node (e.g. home page), everyone would share their content (e.g. blog posts), and everyone would own their own data. The web consisted of nodes connected through links with no center. Jolocom wants to help reclaiming this vision that everyone owns their own node (digital identity) and that every node can communicate with any other node, with no intermediation (e.g. centralized platform).

The dominating power of a few

Today a handful of companies dominate vast parts of the web’s activities – Facebook for social networking, Google for searching, Paypal for payments or eBay for auctions, Samsung/IBM for IoT – and they actually own the data their users have provided and generated. Ergo these companies have unprecedented insight and power over us. They can influence and nudge us without our knowledge, which gives them not only a huge competitive advantage, but also interferes with fundamental values of society and the right for privacy.

Social Linked Data (Solid) and Blockchain (Ethereum)

Jolocom uses a decentralized software architecture that is very promising. It was initiated by Tim Berners-Lee who invented the web and gave it to us as a gift, free and open source. His new project is called Solid (“social linked data”) and it allows you to own your own data, while also using it with only the applications you want to use. With Solid, you simply store your data in your own Personal Data Store (PDS; in Jolocom’s case: a Solid Server), which is hosted wherever you wish. At the core of Solid is the WebID, which Jolocom integrates with the Ethereum blockchain, to build a self-sovereign digital identity that allows you to represent yourself and to enrich your data with semantic meaning. Besides that and storing data, it also lets other applications ask for your data. Solid authenticates the DApps (Decentralized Applications) through Access Control Lists (ACLs) and if you’ve given access permission to the requester of the data, the Solid server delivers it.

Here’s a concrete example.You might store data from your IoT devices or sensors in your own PDS: the sort of data about yourself that would normally be uploaded directly from your IoT device to a third party. That way if someone built a new DApp, to offer specialized services to people, you could join it by using your WebID. To share information with others (individuals or organisations), you simply give them permission to access the appropriate information in your PDS. The data in your PDS would remain your own, in every sense of the word: fully under your control, stored where you choose, and usable only by an Organization’s WebID that you’ve given permission to.

The fantastic thing about Solid is that it does all this without having to centralize information in hands that we can’t- and too often also should not – fully trust.

General Data Protection Regulation (GDPR)

Users are becoming increasingly aware of the need and importance for strong data rights. Governments are slowly adapting to this, with the upcoming EU General Data Protection Regulation as the first move towards a market in which businesses will have to adapt with new business models and technical infrastructure. With the decentralized web as an answer to these needs, users will be able to use services they want to interact with, data will be stored in their own private location, and they will be able to switch between them. This will allow and encourage for a market with a significantly lowered barrier to innovate, one in which collaboration between players is much favourable over competition. Without the main competitive advantage of data, network effects and vendor lock-in will become virtually obsolete. We help businesses create and participate in collaborative decentralized ecosystems where the value generated by its services benefits the ecosystem as a whole.

GDPR compliance is now mandated by May 2018. This means businesses are now required to show exactly how the data they collect is used and enables them to freely take this data with them to different services.

Conclusion

Social Linked Data with its decentralized architecture has the properties to profoundly enrich trust, data portability, and privacy. At the same time it will step up usability to a whole new level for both the user and service providers, while simultaneously becoming compliant to GDPR.

Author: Joachim Lohkamp, Jolocom

Demo Day at TU Graz, Austria

The AGILE consortium had its quarterly plenary meeting at the end of March in Graz, Austria. FBK / Create-Net, AGILE project leader, took advantage of this opportunity to ask each of the partners to create a demonstration focusing on one aspect of the project for which they were responsible or involved. This resulted in an excellent demo session where we were able to take the pulse of the project.

This post lists and describes most of these demonstrations in order to share with you this excellent feedback.Continue reading

Gateway Management

Remote Gateway Management: Benefits, and how we make it happen

Key features of the AGILE gateway include the ability to provide data and device management, execution of Internet of Things (IoT) applications and, importantly, communicate with the Cloud to enable a plethora of use-cases. But there is also features that are provided “under the hood”, features such as security.

Resin.io: a not-so-silent force working alongside the AGILE gateway

For AGILE to enable user application deployment, remote updates, and monitoring of connected gateways, we are customising and will utilise a software technology built by one of the project partners called Resin.io – it is a Remote Gateway Management interface that is deployed in the Cloud, and has, amongst others, a local component that will be running on each gateway called “Agent”.

Resin.io Container used in AGILE: Enables remote management features

The Resin.io Agent works on container level, with elevated privileges to manage both the underlying Operating System (OS), but also the user-space (any applications installed). In simple scenarios, it downloads the changed layers of any application container images, stops the old versions of those applications, and starts the new ones. As the process is ongoing, you can see the overall progress of the process in a dashboard. It is fully interactive, and allows clicking on any specific gateway devices to see more detailed information about the device, such as logs.

Dashboard

Staying up-to-date: A dashboard allows you to see the current status of a gateway

The Agent, which we are customising for use in pilots and use-cases adopted by AGILE, also contains the necessary components to keep a persistent, always-on connection to the Cloud environment which controls it (over secure VPN, as we are paranoid about security!). The Agent allows, upon authorisation, anything from updating the AGILE gateway on the fly, restarting modules and applications, adding functionality as well as providing monitoring information (such as OS logs) automatically and upon request. It also enables a streamlined approach to defining environment variables or other configuration options on the gateway.

Security, as always, is paramount

By far the most important feature is its ability to receive over-the-air updates. And we believe this is extremely important on any IoT application for security reasons. Imagine your gateway, end-devices and deployed applications suffering from a bug whilst you are unable to deploy a fix remotely – and now imagine if it’s not an issue with your own code, but rather an urgent OS security vulnerability! A popular real-world example of this is the U.S. Traffic Safety Administration car recall announcement, one from Tesla Motors, and one from GM. Both are related to problems that could cause fires. Tesla’s fix can be conducted as an “over the air” software update and doesn’t require owners to bring their cars to the dealer (more on this on the Wired article here). And there are recent cases of cameras being hijacked, armies of devices used for Distributed Denial of Service (DDoS) attacks… so let’s just say that it’s important for us to “have the users covered” as part of the AGILE project.

Of course, there is even more urgent need for these solutions to be secure (after all, any device which is why we are dedicating months of work, and the expertise of research and industry partners, in making sure the hardware and software stack behind AGILE is secure, end-to-end.

What does the management interface it look like?

As one our principles is to make things as easy as possible for our users, we are utilising the latest standards in Web development, User Interface (UI) design, and User Experience (UX).

Here is what you should expect to see once you get your hands on an AGILE gateway:

Device management interface: Environment Variables, Terminal, Actions (e.g. reboot)

Gateway Management

Multi-gateway management: Information on OS updates, availability, monitoring/logs

Let us know your thoughts

The AGILE consortium comprises pioneering partners in hardware and software for IoT. Resin.io has been built to bring the Cloud deployment workflow to the world of embedded devices, and the customisation for use in AGILE with an AGILE-specific gateway management system, is no exception. Along the lines, we discover and assimilate interesting ideas from the Cloud or embedded worlds, or even invent ideas that only apply to the new paradigm the project represents.

There is a lot going on behind the scenes, and we are very keen to hear from the community about features they would like to see on the Remote Gateway Management interface. The consortium partners are organising pilots that will allow IoT device manufacturers (devices that will be controlled by the AGILE gateway through its integrated network modules), as well as developers and end-users to get hands-on with our early prototypes and final hardware gateway.

Author
Georgios Michalakidis, R&D Manager, Resin.io

https://www.jisc.ac.uk

AGILE Identity Management

The basis of a security framework is to identify and authenticate users and entities in the system. As a result, developing a proper identity management platform is the first step to start building the security mechanisms in the gateway. Now, we will describe key aspects of AGILE’s IDM and how it can be integrated on external systems, why some of the design choices were made, and point to additional resources which are hopefully useful for newcomers.

A Polyglot User Identity Management

We want to make our user’s lives easy by not creating yet another identity management system which forces them to create new username and passwords just to interact with the gateway. In our daily lives we already deal with a high amount of different credentials with particular restrictions; for example, passwords need to have a minimal length and must include particular characters. Some users deal with this by reusing passwords in different systems; however, this is a bad practice since the system administrator, or an attacker compromising the system, would obtain the user’s credentials for other external systems.

As a result, we have put considerable effort to find proper ways to integrate different authentication mechanisms into our identity management in order to have a usable user management. Currently, AGILE IDM allows users to authenticate using a range of protocols such as Web ID, Oauth2, or username and passwords verified locally on the gateway’s side.

Practically, this means that users who have been already registered with external identity providers, such as Google or GitHub can use their accounts to log into their AGILE gateways as users do when they login using services that rely on such identity providers using Oauth2. Furthermore, for users who do not want to use such identity providers, AGILE offers also other options to authenticate.

For instance, in particular installations of AGILE IDM, it may be desirable that users can log in using the username and passwords used by the underlying Linux system (also avoiding the creation of new username and passwords for the gateway management). Another option is to obtain a Web ID certificate from a provider (such as databox.me or similar) to login in AGILE by just selecting the client-side certificate during the validation step. The Web ID protocol, which is commonly used on linked data environments, allows users to authenticate with a web application by using a client side certificate validation step during the TLS handshake. The integration of this protocol will favor the integration of applications relying on linked data protocols (such as the Little Sister Jolocom’s application).

Last but not least, for users who still desire to have a local username and password generated just for the gateway management this is also supported.

Oauth2 Integration with AGILE IDM

AGILE IDM behaves as an Oauth2 provider towards applications relying on its authentication services. This integration method between applications and AGILE IDM is completely independent from the authentication mechanism used by AGILE IDM to authenticate the user. The latter could be Oauth2, Web ID, or a local username and password.
In consequence, any application relying on AGILE IDM to authenticate its users can use one of the Oauth2 grant types supported by AGILE IDM. Currently, AGILE IDM supports the following grant types:

  • Authorization code
  • Implicit (also known as token) flow
  • Client Credentials

To facilitate the use of AGILE IDM within the project, and by external adopters we have created a set of Node.js applications relying on AGILE IDM which implement the proper Oauth2 flows here. Furthermore, the authorization code application also provides a basic web interface to create and update entities and users, change their attributes, and them to groups. This will hopefully make testing and understanding how AGILE IDM works easier for newcomers.

Portable and Flexible

AGILE IDM uses Node.js as runtime; as a result, it can be employed not only on the gateway but also in other scenarios and operating systems. Also, in addition to the user management and authentication component, AGILE IDM allows the definition of flexible policies on the principal’s attributes in such a way that they can be written or read by particular users. This is paramount to support the definition of other entities, such as sensors or applications connecter or running on the gateway.
Currently, along with the German FORSEC project, we have begun a collaboration effort to integrate AGILE IDM in an IoT platform allowing users to control their data usage in a Cloud-based platform. AGILE IDM will offer not only user authentication, but also the management of principals in the system through its flexible attribute definition system. Last but not least, AGILE IDM also receives input from FORSEC regarding the policy enforcement framework on the attribute level.

Hands on Tutorials

To foster the use of the identity management platform developed in AGILE, we have also spent resources to document its functionality and to provide tutorials describing how to install, configure or extend AGILE’s IDM. For more information, please check the following links:

Authors

  • Juan D. Parra Rodriguez, University of Passau
  • Daniel Schreckling, FORSEC