More and more online devices and appliances are installed in buildings today: heat pumps, solar inverters, smart meters, electric vehicle charging stations, smart control valves, blinds control… As each of these subsystems works as a silo, the deployment of applications spanning over more than one subsystem is at best hard and often impossible. This is a problem for energy management, which requires the synchronised operation of multiple appliances.

 

In this context, the domOS ecosystem provides a solution to decouple the field infrastructure in buildings and applications. The domOS ecosystem is not a platform but a specification that can be implemented with limited effort on multiple platforms. Three platforms have been upgraded in the frame of the domOS project: cloud.iO, S-IOT and ArrowHead.

 

In this interview, Frédéric Revaz from HES-SO Valais and Brian Nielsen from Aalborg University will introduce their platforms and will explain their work within the domOS project.

 

Frédéric Revaz is an associate professor at the Institute Sustainable Energy of HES-SO Valais. His research interests are at the intersection of economy and technology to solve energy problems. His current projects are focused on H2 seasonal storage and IoT solutions for energy in small buildings.

 

Cloud.io

1. What is the cloud.io platform made out of (its components, architecture)?

 

cloud.iO is a scalable open-source IoT platform developed and maintained by our university HES-SO. “Things” synchronise their states with their digital twins stored centrally in the cloud. Technically, the cloud.iO central platform is made up of low-complexity stateless micro-services built-around field-proven high-performance components. Fine-grained access rights can be configured for applications.

 

2. How and when would the cloud.io platform be accessed? (When will it be available?)

 

The platform is readily available on GitHub and Docker Hub, see https://cloudio.hevs.ch/. A version compliant with the domOS ecosystem is still in the test phase. The original cloud.iO platform provides authorised apps with means to monitor and control buildings. With the domOS upgrade, each building will get a digital nameplate (“Building Description”) indicating in a semantic (i.e., machine-readable) way what can be measured and pointing to cloud.iO URLs. The upgrade will be made publicly available before summer.

 

3. What do I need in my building to connect to cloud.io?

 

You first need to deploy the smart infrastructure in the building: meters, and appliances. You then need to deploy a gateway bridging the local infrastructure with cloud.iO. The cloud.iO endpoint libraries help you with that task. Then you need to fill up the digital nameplate for the buildings. At this stage, applications can “understand” your building’s topology thanks to the nameplate and readily begin controlling/monitoring the building.

 

4. What are the benefits that cloud.io offers?

 

The coud.iO platform features a lean architecture made up of autonomous low-complexity and stateless components. While not as complete as leading platforms, it offers to its users a good basis for customisation.

 

5. On what kind of building is the cloud.io platform used?

 

The domOS Sion demonstrator uses cloud.iO to monitor and control single-family residential buildings: electrical data related to a smart meter, PV and heat pumps as well as temperatures are gathered and acquired. The heat pump is controlled to help the energy supplier better match its customers' overall consumption with energy bought the day ahead.

 

6. Where can more information be found? Who should I contact?

 

Documentation and how-tos are available at https://cloudio.hevs.ch. Any contribution is welcome, join us on GitHub!

 

Brian Nielsen is an Associate Professor, Ph.D. at the Department of Computer Science, Aalborg University.  He is a member of the Distributed and Embedded Systems research group. His research interests include distributed, embedded, and cyber-physical systems and software, Internet-of-Things, robotics, and methods and tools for model-based development and test generation for embedded real-time systems, and industrial applications. A current focus is ICT infrastructure for energy control and optimization in buildings.

 

Arrowhead

1. What is the domOS-Arrowhead platform made out of (its components, architecture)?

 

The domOS Arrowhead platform uses the Arrowhead SOA industrial automation framework as a foundation to implement the domOS ECO System specification. This allows platform components as well as applications to take advantage of the Arrowhead automation clouds and its core services.

 

The domOS Arrowhead platform targets an open platform and thus addresses the particular security concerns that arise from this. It implements the following key features:

 

• AIM using OATH2.1 implemented by Keycloak, a standard and well-known access and identity manager.
• domOS dCO compliant things- and building descriptions.
• Semantic web-based knowledge bases, validation, and semantic queries. Building descriptions are queried using semantic web sparql queries. Support for import and export via JSON-LD is planned. These technologies are introduced in Section 2.3.
• Forced intermediation handles all communications between external applications and things performing access control upon each affordance access.
• Fine-grained things access control on affordance level; each access to a thing’s affordance is checked against specified rwx affordance permissions as specified by the building owner.
• Uses an intermediation strategy that enforces a distinction between registered things and their credentials from things descriptions that are revealed to applications. Hence the internal things descriptions are re-written before they are sent to applications. 
• Internal and external applications. An application may be written as a normal Arrowhead application and executed in the local cloud, or it may be completely external.
• Efficient implementation of the intermediator using Reactive Java. The platform has the ability to add multiple intermediators when required for scaling.
• It is developed as an Arrowhead-compliant SOA application, thus building on a well-established software infrastructure. Application service providers and consumers execute core services in a local automation cloud. It thus provides an industrially accepted foundation to base developments thereby increasing the possibilities for wider adoption.  It further supports a variety of deployment options with local and remote automation clouds.

The domOS platform adds to the Arrowhead components to serve as things description- and building description directories forced intermediation with access control, platform monitoring, and user and management interfaces, see below.

 

Overview of implemented domOS-Arrowhead components

 

Reachability of the Building Descriptions: The platform offers a REST API for semantic querying of the building description using sparql queries, see Section 4.2. The semantic inference is done by the platform. These are handled by the BDD component. Import/export of building descriptions in JSON-LD is planned, but not yet implemented.

 

Reachability of the Things Descriptions: Things descriptions are offered through a WoT standard-compliant things description directory via a REST API, as described in Section 4.1. We remark 1) there are two interfaces, one for the platform components that output the actual things descriptions and one for applications that return a modified description where the access URL and credentials point to the platform to enable the forced intermediation. Also, 2) the BDD is the normal gateway to query the building.

 

Generation of the TDs and BDs: At present no user interfaces exist to edit or import things- or building descriptions, so they are loaded manually.

 

Access to legacy systems: Neogrid has developed an automated generation of things descriptions from their platform for the Aalborg demonstrator. The export of building descriptions is ongoing.

 

2. How and when would domOS-Arrowhead be accessed? (When will it be available?)

 

The domOS-Arrowhead platform is in beta development. It will be tested and demonstrated during the next half a year, and further user interfaces developed. It is being containerized for easier deployment. Then it will be publicly released.

 

An instance of the domOS-Arrowhead platform will be run, administrated, and hosted by a platform operator. Thus, building owners will need to contact a platform operator, which may or may not coincide with companies delivering energy services, housing associations, or private hosts.

 

3. What do I need in my building to connect to domOS-Arrowhead?

 

Things descriptions of deployed sensors and actuators, a building description, and a subscription/agreement with a platform operator and a supplier(s) of one or more smart energy service(s). Devices must be accessible via the resource locator given in the TD.

 

4. What are the benefits that the domOS-Arrowhead offers?

 

The ambition of the domOS ecosystem is to improve interoperability between buildings and service providers, breaking down both technical IoT and business silos, and opening buildings up for access to more service providers with less effort. Being compliant with the domOS eco-system the domOS-arrowhead platform provides the ICT to enable this ambition.

 

Further main advantages are the fine-grained access control offered to the building owner, and the ability for a platform operator to manage several buildings and different service providers.

 

5. On what kind of building is the domOS-Arrowhead platform used?

 

Residential buildings, one-family houses, and apartment blocks are offered by housing associations.

 

6. Where can more information be found? Who should I contact?

 

So far, the current implementation is described in domOS deliverable D2.5 and contact bnielsen@cs.aau.dk.