How does RESPOND Platform work?

In this article the internal composition of the RESPOND platform is described. The next figure shows the RESPOND Architecture, where the platform components are highlighted.

Respond Platform Structure

This figure shows a conceptual vision, but the technological vision is more complex due to the use of different frameworks and the micro services approach. The result is a complete platform covering all the aspects needed to implement an IoT system: starting from the data acquisition, to their storage, integration,  processing , analysis and finally the visualisation to offer comprehensive information to the home occupants and the facility manager.

Thanks to the use of standard protocols such as MQTT, SPARQL, SQL, LDAP, HTTPS and REST, the implementation of a micro service approach is feasible, thus allowing to add, change or remove certain functionalities easily and without interfering with the rest of the system. This high degree of interoperability between systems also allows to use different frameworks to implement and integrate the micro services.

The next figure shows all the technological modules used or developed that comprise the RESPOND platform.

Respond Platform

Third party components

The MQTT broker is the component that receives data generated by the field devices. This messaging protocol is optimised for high-latency or unreliable networks and using the publish/subscribe paradigm, the broker distributes the data to the modules that need the data in real time. The technological solution that implements the MQTT protocol in the RESPOND platform is the open source  Eclipse Mosquitto (https://mosquitto.org/).

The RESPOND platform relies on the TICK Stack bundle (https://www.influxdata.com/time-series-platform/), which is composed of Telegraf, InfluxDB, Chronograf and Kapacitor. Telegraf is the component that allows to save the data received by the MQTT broker in the time series database InfluxDB. This type of database is optimised to manage IoT data acquired in real time. Chronograf is another module of this bundle that allows to visualize the data and Kapacitor is an event processor engine that allows to transform or aggregate data and send notifications when some conditions are true.

Another key component of the architecture is Nginx (https://www.nginx.com/), a web server that is also used as a proxy server for micro services and load balancing. This component allows to expose the Open REST API to interact with the services.

The OpenLDAP (https://www.openldap.org/) is an open source implementation of the Lightweight Directory Access Protocol (LDAP). The user authentication and authorisation is controlled by this component. The administration frontend for this component is the PHP LDAP Admin (http://phpldapadmin.sourceforge.net). It is also open source and is used for defining the user credentials, permissions, and groups.

Regarding the information related with the topology of the pilot sites, including the appliances and devices connected in each home, it is defined with the semantic model in the semantic repository. This semantic repository has been implemented using the open source edition of Openlink Virtuoso (http://vos.openlinksw.com/owiki/wiki/VOS)

For data not managed by the previous repositories, the general purpose relational database MySQL (https://www.mysql.com/) is used. For example, this repository contains data related with  the analytical micro services.

The R Server (https://cran.r-project.org/ ) allows the remote execution of scripts written in the R programming language. This language is the leading language to implement artificial intelligence applications and services.

Micro services Developed by RESPOND partners

All the previous components are third party frameworks and artefacts used to provide the basic functionalities needed in an IoT platform. On top of these components, the RESPOND consortium has developed a set of micro services to provide the added value capabilities to exploit the Demand Response. These micro services are described in the next paragraphs. As it is shown in the architecture, the adapters are the components in charge of gather the exogenous data to be used by the RESPOND services and the final user. In this regard, two main adapters have been developed. On the one hand, the Weather Forecast Adapter which is responsible for gathering the weather forecast data of the day ahead, and on the other, the Energy Prices Adapter which acquires the prices of electricity for the upcoming hours.

Likewise, a set of services based on the predictive analytics have been developed. The Demand Forecast service forecasts the day ahead demand at the pilot sites. The Production Forecast service forecasts the day ahead production of the RES (Renewable Energy Sources) at the pilot sites. Predictions generated by these two services are used by the Optimisation service to generate an optimised profile for every pilot site. Afterwards, his optimised profile is used by the Heuristic Optimisation service in order to generate the energy-saving recommended actions which are sent in the form of notifications to the home occupants. The daily interaction between these modules is orchestrated by the Task Scheduler service.

Last but not least, a set of have been developed with views to ensuring an adequate interaction with users. The main tool used for the interaction is the Smart Energy Assistant App, a multilingual and cross-platform mobile app which available for download both in Google Play and Apple Store Markets (http://project-respond.eu/personal-energy-performance-assistant-version-1-13-released/). The additional  services that implement the interaction with users are the following:

  • The Smart Energy Assistant Proxy is in charge of answering the requests coming from the Smart Energy Assistant App used by the occupants of the pilot homes.
  • The User Adapter is the module that manages the preferences of the home occupants in order to adapt the prescriptions generated by the backend services.
  • The Notification module sends push messages to the smartphones of the users who use the Smart Energy Assistant App.
  • The Thermal DR is the service to generate and schedule the set points used in the use case related to the thermal demand response.

Francisco Javier Díez
C/ Iñaki Goenaga, 5
20600 Eibar, Gipuzkoa (Spain)
Tel.: +34 943 20 67 44