In order to highlight the benefits of an IPv6-based IoT, in this page we present three different use cases that have been implemented in the context of the IoT6 project. They show well how it is possible to interconnect different devices, and create interactions between different services. In detail, first, we illustrate the integration of legacy building automation devices into a homogeneous IoT IPv6-based smart office. Then, an advanced scenario regarding building safety is described. And finally, in the last use case, focused on building maintenance, we describes the replacement of a faulty device.
Use case 1: Smart Office and legacy devices Integration
As there still exists a heterogeneous landscape and large variety of legacy devices and networks in the building automation domain, their integration into the Internet through a single interface is still a challenge to face. But, actually it can be addressed by IPv6 and the IoT. In the presented Smart Office scenario, several automation devices of different legacy networks (i.e., BACnet, KNX) are integrated through a gateway which is responsible for translating legacy protocol messages into IPv6 packages and providing a homogeneous view on the underlying heterogeneous networks and associated devices.
Figure - Use case 1: smart office presence detection
The Smart Office use case starts when an employee enters the building and presents his/her RFID badge to the system’s RFID reader. As the RFID reader is IPv6-enabled it may directly communicate with the CMS using IPv6. The CMS subsequently chooses the employee’s comfort profile for his/her office and sends settings and commands to the IoT6 GW which integrates devices of the particular office into the IoT. The IoT6 GW controls a variety of different devices from heterogeneous building automation
networks and masks this heterogeneity by providing a uniform IPv6 interface for all devices. The IoT6 Gateway can in further consequence be used to set user-defined preferences for the employee in his/her office. In the example case, the heating actuator setpoint (H) and two brightness actuators (L) integrated through a BACnet network are adjusted. At the same time, also the position of the sunblind (B) which is controlled via a KNX network is adapted according to user preferences. For the CMS, the idiosyn-crasies of the different underlying legacy networks make no difference as the IoT6 Gateway transparently integrates these devices into the IoT allowing to adjust them in a uniform way.
A similar situation to the one illustrated in Figure can be observed when the employee leaves the office building. As soon as he/she provides his/her RFID badge to the RFID reader, the CMS is informed that the employee is about to leave the building. In this case, the CMS can execute an energy-saving rule which turns off all devices in the employee’s office. Alternatively, a presence sensor in the office combined with a time-out could be used to detect absence and initiate the energy-saving scenario.
Use Case 2: Safety alert and dynamic routing
The second use case, slightly more complex than the first one, is focused on an emergency situation and the capabilities of an IoT architecture to deal with this. As initial setup for this use case, an IPv6-enabled temperature sensor (S) is considered which periodically sends an update of the sensed temperature value to a Control and Management System (CMS) available as service in the IoT. The starting point for this use case is a sensor that reads a temperature which is too high (i.e., outside the boundaries of usual operation). The Control and Management System detects this abnormality and flags the received message as an alert message. It sends the value to a smart router which is a component in the IoT that according to the type of the message may take different routing decisions. If a normal temperature message is received the smart router sends the temperature messages to a Building Energy Management Server (BEMS) that may be responsible for logging and reporting the energy demand of a building. In the present case (excessive temperature), however, the smart router detects the priority of the message (alert) and according to the tagging carried out by the CMS forwards the value to a specific Safety Server (StS) which is responsible for handling alert situations. As the StS receives the abnormal value it firstly contacts the Global Resource Directory (GRD) to gather information about the location of the sensor. If the StS already has a list of alarm devices with their location it can compare the location of stored devices with the location of the temperature sensor to directly turn on an IPv6-enabled alarm device (A) in the vicinity of the alert situation. If the StS has no pre-stored alarm devices for the area for which the alarm was reported, it is possible to issue another query to the GRD service requesting alarm devices that are in the vicinity (e.g., found in 15 meters radius) of the alert. Any device capable of signaling an alarm which is found can subsequently be switched on. Further, the StS may have a list of mobile phones of persons in charge for alert situations (e.g., fire wardens, system engineers). In this case, the CMS has to gather information about the current location of the IPv6-enabled mobile phones from the Global Resource Directory through an additional query. After it received this information, the CMS can inform responsible persons near the area of interest about the alert situation via their mobile phones. As shown in the Figure, all communication is handled via IPv6 which emphasizes the diversity of devices and components that may be integrated in the IoT. If legacy devices are involved, either on the sensor or on the actuator side, again an IoT6 Gateway can be used for integration as described before.
Figure - Use case 2: safety alert
Use case 3: Building maintenance
The third use case is related with building service maintenance. It involves a variety of IoT components and demonstrates how these components in combination with IPv6 communication can be used to detect device failures in a building and investigate as well as fix the cause. In the shown case, a number of sensors are connected to the IoT through an IoT6 gateway (IoT6 GW) which assures that all legacy sensors can be accessed in a uniform way through IPv6 communication (as in the Use Case 1). This use case starts with the failure of a legacy component in the subnet controlled by a specific IoT6 gateway, e.g., a temperature sensor. Usually, a Control and Management System (CMS) observes the value of a temperature sensor to, for example, detect safety situations or perform energy reporting (as in Use Case 2). In the case an observed sensor silently fails, a time-out occurs at the CMS, indicating that something is wrong with the device. A message is generated at the Control and Management System and sent to the Maintenance Tool (MaT) for further examination. In its simplest form, the Maintenance Tool could also run on a local CMS but presently is pictured as global service in the IoT cloud. As soon as the MaT gets the message about the failure of a device, it creates an alert ticket and sends out failure notifications to a variety of mobile phones of responsible persons (e.g., system engineers). The group of recipients may again be based on the current location of the mobile phones for which a lookup call to the Global Resource Directory would be necessary (as in Use Case 2). A person associated with one of the contacted mobile phones seeks out the faulty device and uses a maintenance app on the mobile phone to scan its RFID tag. The information is relayed to the MaT which needs to find out the device which is associated to the respective RFID tag. Therefore, it queries the Global Resource Directory (GRD) for the location of the Smart Things Information Service (STIS), a database-like service that keeps associations between RFID tags and devices. The MaT further sends back information to the maintenance app running at the mobile device providing the system engineer with more information about the device. With the help of this information, the engineer has the possibility to run diagnostics on the device. In this case, the CMS further acts as an intermediary between Maintenance Tool and the IoT6 Gateway, accepting and relaying messages from the Maintenance Tool to the IoT6 Gateway. In case the device’s defectiveness is confirmed, a replacement order needs to be made. This order can again be performed using the MaT. The information previously retrieved from the STIS may in this case further be used to directly order the spare part from an Inventory Management System (IMS), another service in the IoT. If the address of the IMS is not yet known by the MaT, it first again has to issue a request to the GRD. Alternatively, the IMS may be part of the maintenance tool in which case the separation of the two services can be omitted.
Figure - Use case 3: building maintenance