1. Introduction
The Internet of Things (IoT) stands for an updated vision of the Internet. It extends the Internet Protocol (IP) communication to billions of resource-constrained endpoints (‘things’) [
1], such as intelligent luminaires and sensors, reaching into the physical world. Things are typically connected into resource-constrained access networks, with low power, lossy, low bitrate asymmetric links and limited group communication primitives. As a network IoT connects uniquely identifiable things to ‘regular’ Internet services and fast networks. Information about things can be collected and their states can be changed from anywhere, anytime and by anything [
1]. IoT enables seamless communication, contextual services and data sharing between things and is bringing radical changes in several industries by converging multitudes of vertical markets [
2].
The lighting industry is currently going through a transformation to Solid State Lighting (SSL) such as LED-based systems to enable increased control capabilities (e.g., switching and dimming) and reduced operational costs and energy consumption. However, to stimulate the transition, added value propositions are needed, which are often difficult to achieve with the existing closed and proprietary lighting standards. The fragmented standards and their restrictive Application Program Interfaces (API) often lead to incompatibilities between vendors and limit interoperability with other building services. Embracing IoT in lighting systems creates new opportunities and value propositions. IoT is now maturing, and it is economically feasible to connect each luminaire to the Internet. The transformation from traditional lighting to SSL makes it way easier to convert light points to IP end-nodes. Hence, it is an excellent opportunity to establish the Internet of Lights (IoL), i.e., an advanced lighting system with IoT at its core.
A transition towards IoT has several benefits: It enables using the network infrastructure in the building for controlling and powering the lighting systems rather than using a dedicated lighting network. Having IP connectivity to all light points enables flexibility and interoperability with other systems such as Building Automation Systems (BAS), smart grids and cloud services. It enables the transition from command-oriented lighting control to service-oriented lighting control and, as a result, can bring in a large variety of new services, create new ecosystems, stimulate investments and innovations and benefits from the worldwide developments in protocols and tools. For example, sharing occupancy data collected by presence detectors used for lighting controls with BAS for air conditioning or with cloud for data analytics opens up new possibilities and services. Overall, it can increase the comfort and well-being of the people in a building, lead to more efficient use of the building and even help to achieve certifications such as BREEAM or LEED [
3] by increasing the building performance rating and reducing the carbon footprint.
In this article, we present how to design and realize an IoT-based lighting system for indoor office buildings using an IoT-centric intelligent lighting architecture developed by the European Union (EU) project OpenAIS [
4]. The paper is organized as follows: The motivation of going towards an open architecture, as well as the goals to achieve while embracing IoT are discussed in
Section 2. The proposed OpenAIS IoL architecture is presented in
Section 3. A pilot system is being built using the OpenAIS reference architecture.
Section 4 provides a deeper insight into its system design. An analysis of the system is presented in
Section 5, where we compare the OpenAIS system with a state-of-the-art system and explain how the architecture provisions the Key Performance Indicators (KPIs). Finally,
Section 7 concludes the work and summarizes the challenges yet to solve.
3. OpenAIS IoL Architecture
As a first step towards creating an IoL standard that is open, IP-based, extensible, interoperable and secure, the EU Horizon 2020 project OpenAIS has been set up with key players from the lighting industry and IoT. One of the key outcomes of the OpenAIS project is to develop an IoL architecture with novel solutions for network connectivity and security that can later be standardized. In this section, an overview of the proposed IoL architecture of OpenAIS is described.
The IoL architecture is developed as a reference architecture, i.e., a template for specifying concrete system architectures. The architecture is designed to support a wide range of deployment scenarios and use cases, which includes retrofitting and refurbishment (backward compatibility to legacy), as well as future office buildings [
11]. It envisions creating an open ecosystem to enable a wider community to deliver the smartness of light and allow easy adaptability to cater to the diversity of people and demands. It foresees that the lighting systems, as well as the building management systems will converge to an all-IP-based configuration, with Internet of Things concepts at the heart of new lighting system architectures.
The key objectives of the OpenAIS reference architecture are:
Define an open architecture for lighting systems with standardized open APIs;
Make the system interoperable with BAS, cloud services and other systems;
Increase the building value and reduce the carbon foot print by combining IoT, LED technology and smart grids;
Easy to specify, buy, install, maintain and use IoL systems for all stakeholders in the value chain.
The OpenAIS reference architecture is described from the viewpoint of different stakeholders using five concurrent views, namely logical, physical, deployment, networking and security views.
3.1. Logical View
The logical view presents the functional decomposition of the system into various functions as experienced by stakeholders that interact with the system. There are two main types, an application layer containing functions that implement domain-specific functionality of the lighting system and an infrastructural layer containing functions that take care of the system infrastructure.
The application layer functions are:
Sense: Detects events or changes in the environment such as presence, light-level and user inputs;
Actuate: Generates light;
Control: Implements lighting behavior/algorithm;
DataCollect: Collect, process and store data;
Group: Helps in administering entities that belong together in an application logic such as actuators, sensors and control;
Scene: Helps in creating specific effects or scenarios such as a presentation scene in a meeting room using a set of actuator settings;
Gateway: Interfacing with legacy or other non-OpenAIS systems.
The infrastructural layer functions are:
Discovery: Helps in detecting the available application layer functions in the system;
Communication: Supports an infrastructure for communication between the various functions;
Update: Enables software updates;
Security: Supports authorization and authentication and protects the confidentiality and integrity of the system against attacks;
Configuration: Supports updating the static parameters in the system
DeviceContainer: A container for the properties of a physical device and implements the functions and parameters that relate to a single device such as its IP-address, MAC address, reset, power states and health status.
OpenAIS adopts Sense-Control-Actuate (SCA) models where each sensor updates the actual value/state to the controllers, which then sets the actuators based on this information from sensors and from other controllers. The information flow from function
A to
B is shown with a directed edge from
A to
B in
Figure 1. The controllers support stacking of Control functions in several layers and overriding features which will be further explained in
Section 3.3. The DataCollect function collects data from sensors, actuators, controllers or other data-collectors who expose data for storage and analysis. The Group function helps in retrieving group details or administering group members such as a set of controllers, data-collectors, sensors and actuators.
The relations between the infrastructure layer functions shows that the Application function (could be any one of the application layer functions like Sense, Actuate or Control) is configured by the Configuration function, while it makes use of the Communication function for application-level communications and the Discovery function for detecting available functions. The dependency relationship, function
A uses
B, is shown with a directed dashed edge from
A to
B in
Figure 1. The DeviceContainer function uses the Configuration function for parameter settings and the Update function for software update. Discovery, Update and Configuration functions make use of the Communication function for communication, which in turn uses the Security function to make the communication secure.
These functions expose their functionality through certain interfaces. A generic categorization of interfaces defined in OpenAIS is:
IControl: Interface through which a caller can execute a certain method in a function, like setting a light level or a color.
IData: Interface through which a function communicates data or changes in its data to the outside world. Data producers send the data out to all interested entities, and the receivers determine how to handle them.
IConfig: Interface through which static parameters can be set, e.g., addresses, commissioning information, algorithmic parameters, scene values, regulation curves, thresholds.
IDiscover: Interface through which the element can be discovered on the network.
IDebug: Interface to configure debugging functionality and trigger testing/debugging operations.
3.1.1. Object Data Model
The OpenAIS Object Data Model (ODM) illustrates the resources of the lighting system in a structured fashion. Rather than introducing new protocols to access the resources, the OpenAIS ODM relies on RESTful standard protocols such as HTTP and CoAP. The representation format of the resources are also intended to be any of the widely-accepted industrial standards like XML, JSON or CBOR.
The OpenAIS ODM defines OpenAIS Objects, which are collections of Resources. Objects must be instantiated to make use of the Resources defined for an Object and can be instantiated multiple times. Within the context of the OpenAIS ODM, resources of the RESTful protocols can be Objects, Object instances and Resources. Therefore, the OpenAIS ODM is agnostic to different techniques of accessing the Resources. This is because different infrastructures may enforce restrictions on resource paths, such as limited paths or restricted names. For the sake of interoperability, vendors are expected to clearly explain the method of accessing their Resources.
Figure 2a shows the hierarchy between the Device, the Object, the Object instance and the entailed Resources. OpenAIS Objects could be of the type Physical or Logical. A Physical Object represents one hardware instance (e.g., a light-point, a sensor) and controls the associated physical effects. A Logical Object represents one controlled aspect of a hardware instance (e.g., intensity, color, sensor). A hardware instance can have only one Physical Object instance, but may have multiple logical instances as shown in
Figure 2b. The Device Object shown in
Figure 2b features the DeviceContainer functionality of OpenAIS and represents the whole device. Therefore, there is a one-to-one relationship between the device and the Device Object. In addition to the illustrated Objects in
Figure 2b, OpenAIS also defines Organizational Objects (e.g., Group, Security) and Functional Objects (e.g., BasicControl, Scene, DataCollect).
3.1.2. Groups
We have seen that the Group function is one of the application layer functions. In lighting, many tasks are often related to a set of sensors, controllers, actuators or data-collectors, and hence, Group is an important concept. In this section, we see how a Group can be realized in OpenAIS.
An OpenAIS group is formed by sharing a group vector between the grouped entities. The group vector provides the information needed to execute the grouping to all members of a group. It provides an Application Group ID, which is a unique identifier of the group. It also provides a Security Group ID that points to the Security Object that controls the encryption/decryption of the group communication. Additionally, the group vector provides a Multicast Group ID, which is the IPv6 multicast address used for the group communication. Ideally the members of Application, Multicast and Security Groups are all the same. However, implementation restrictions may lead to sharing Multicast and Security Group IDs (Object instances) with more than one Application Group.
3.2. Physical View
The physical view describes the physical components or devices in lighting systems, which include luminaires, sensors, area (floor, building) controllers, IT-infrastructure components, cloud computing and management and security systems.
As the reference architecture can be used for several systems with varying technology and design choices for components, the physical view gives only a representation of example system realizations that can be made out of the reference architecture. OpenAIS supports an open structure for lighting systems with respect to scale, topology and hardware.
Figure 3 shows an example physical view of an OpenAIS system with luminaires and sensors (standalone and user interface switches) that are connected together to a local field network using wired and wireless networks. Within local networks, all devices use the same network technology, and they need not be fully separated geographically. The network access layer may contain standard IT components such as switches, access points, OpenAIS devices such as Gateways to translate legacy/non-OpenAIS devices to OpenAIS devices and border routers to connect wireless network, e.g., 6LoWPAN [
12], to the wired backbone.
The backbone network contains core routers and switches providing high-speed access for the various management systems such as the network, lighting system, building automation and security system. The OpenAIS cloud also uses the backbone network protected by a firewall to get connected to the field devices.
OpenAIS does not impose any restrictions on the supported field devices. A direct integration of other field devices, e.g., shading devices, is also feasible. However, the corresponding data models need to be developed. The legacy/non-OpenAIS devices need to be integrated through the Gateway.
An OpenAIS system can extend network size and coverage to any type of network topology. System designers can decide on the appropriate network size and topology based on their requirements and budget. The choice of wireless, wired or a mix of both depends on deployment scenarios. For example, in the case of retrofitting or refurbishing, wireless devices may be preferred to avoid rewiring. One of the main restrictions in the networks, especially wireless networks, is to limit the network diameter to a few hops. Increasing the hop count degrades the performance. System designers can decide on the appropriate network diameter based on the trade-off between performance and cost. For better performance, they can also choose a wired network, but lose the benefits of the wireless networks, such as flexibility and ease of installation.
3.3. Deployment View
The deployment view shows the mapping of the abstract logical functions upon real software and hardware components. Mapping of logical functions to physical devices is easy in some cases, e.g., a Sense function to a standalone sensor or an Actuate function to a Light Point; but it gets complex with other application functions. For example, the Control function can be deployed to a dedicated device like an area controller or it could be deployed in a luminaire. A luminaire with integrated sensors has thus Sense, Control and Actuate functionality in the same physical device.
The versatility of the control deployment allows OpenAIS systems to be designed as centralized, fully-distributed or intermediary control modeled systems. In centralized models, the Control functions are allocated to one central controller that handles all decisions, whereas in fully-distributed models, they are allocated in all luminaires. In larger configurations, dedicated lighting controllers per group, area or floor are possible. Such stand-alone controllers are optional elements and can be even deployed on other IT-devices like local servers or even on the cloud. This flexibility in Control function deployment is supported by the provision for stacked control; a feature that allows for different levels of Control functions in the system with overriding capabilities, i.e., simple ones can be superseded by more versatile ones. It also allows extending the control behavior, i.e., a new Control function with a higher functionality can be added to extend existing functionality without replacing the existing one. This helps the architecture to be future-proof. Although the laws governing stacking can be made complex, the majority of the Control functionality needs for common lighting systems can be achieved in practice with a small number of Control layers with a straight forward relationship.
3.4. Network View
The typical IoT architectural models try to connect clients to a server in the cloud, which would limit their usage for real-time applications. OpenAIS solves this problem by allowing device-to-device(s) communication and thereby extending IoT to real-time applications like lighting systems.
OpenAIS IoL supports both wired and wireless networks and mandates IPv6 communication for all end nodes. IPv6 is the main decoupling point in the architecture, as the underlying physical, data-link layer stack choices are not mandated; instead, default choices have been proposed in the reference implementation, which are Thread [
13] for wireless and Ethernet for wired networks. The envisaged network stack is depicted in
Figure 4.
UDP is used for transport in conjunction with CoAP (including CoAP observe and CoAP multicast) [
14] to support constrained devices. For transport layer security, DTLS is used. RESTful web service interfaces are used for interfacing between the applications. To build the RESTful interfaces, the Open Mobile Alliance (OMA) Lightweight M2M (LWM2M), an efficient and emerging IoT framework [
15], is adopted. It supports bootstrapping, (DTLS) security, registration and Object/Resource access.
Although LWM2M enables both device management and application data communication, not all functions required for the lighting and building control market are supported. The LWM2M standard is focused on the device-to-cloud (back-end server) communication pattern and expects that field devices have a reliable connection to a server in the cloud, which cannot be guaranteed in a lighting system deployment. The application data communication in lighting system is mostly device-to-device(s), i.e., the communication is mostly between sensor, controller and actuator as detailed in the SCA model.
To support such communication, OpenAIS Group Communication (OGC) is defined. It enables secured and unsecured group communication using the CoAP multicast [
14,
16] protocol over IPv6 multicast, serial IPv6 unicast or a combination of these. In special cases, unicast can be used in group communication, to either address a single group member individually or for situations where the reachability of (some) devices is hampered by router settings.
The URI below shows how a CoAP request is made to address an Application Group using OGC:
where
is the Object ID to which the group request is targeted,
is the system-wide unique Application Group ID and
is the resource identifier that determines on which resource this request will act.
To deal with the unreliability of IPv6 UDP multicast communication, at the network level, a (one time) repetition policy of all operational multicast messages is adopted. At the application level, errors such as missing communications or an absence of a device can be detected by a liveness check that analyses the periodic reporting of the current states/commands sent. When an absence of an Object instance is detected, the provision for graceful degradation allows the device to revert to default safe behavior and resume its normal operation once the Object instance returns. For serious errors, a reset must be executed to bring a device back to a known and stable state.
OpenAIS Group Communication operations are secured at the application layer using OSCOAP/COSE [
17].
3.5. Security View
As OpenAIS systems are fully networked and connected to the Internet, they are prone to attacks and need to be protected against threats like unauthorized access, control, use of data and modification of the configuration of the lighting system. Security is provided as an internal feature of the system and works independently from site-protecting firewalls. The OpenAIS security architecture supports authorization, authentication, confidentiality and security of the communication, data privacy and integrity of the system against attacks. It reuses the LWM2M specification as much as possible. However, additional changes required for the lighting-specific applications such as support for role-based access control, OGC and the bootstrap process (not depending on Internet connectivity to a central server) are needed. For wireless links, link layer security is mandatory, while for wired links, it is optional.
There are essentially two types of Client/Server interactions occurring in the system, OGC and device-to-cloud communication, where the former is secured using Object Security at the application layer and the latter using DTLS sessions at the transport layer. The OpenAIS authorization policy for client-server interactions, applicable to both OGC and device-to-cloud communication, demands that only authorized clients with an authorization level greater than or equal to the category (security level) of the server resource are allowed to access the resource. For this, the authorized clients are categorized into one of multiple roles (e.g., lighting operational, commissioning, maintenance, etc.), and six access levels (0 to 5) are provided to support role-based access. To implement the authorization policy, OpenAIS uses the Access Control Lists and the Security Object from the LWM2M specification. For the OpenAIS Group Communication, all group members have Level 2 (lighting operational) access to the resources that are defined as accessible for group communication by the data model.
For unicast CoAP requests and responses with required access level greater than 2 (e.g., commissioning), the communication must be secured using DTLS. If the Security Object’s security mode is passwords, the J-PAKE cipher suite must be used, otherwise the cipher suites and security procedures specified in the LWM2M specification must be used. Unicast CoAP requests and responses for resources at access Level 2 may use either the Object Security (if OpenAIS Group Communication is used) or DTLS. For all multicast communication, COSE-based Object Security as defined by [
17] must be used.
The Object Security format used in both multicast and unicast communication within a group (OGC) for Access Level 1 and 2 resources is currently being standardized within the IETF ACE working group [
18]. It refers to OSCOAP as the method to protect CoAP messages using COSE-secured Objects.
4. System Solution
To validate the OpenAIS IoL architecture, the OpenAIS project is progressing with a pilot system installation in a real office at a premier building. The lifecycle of the OpenAIS system starting from the component and system design to use and maintenance is shown in
Figure 5. It illustrates the five phases of the lifecycle and related requirements. In this section, a deeper insight into certain aspects of the system solution within the scope of the article is presented.
4.1. System Requirements
The components of an integrated system have the following requirements:
-
The electronic components as part of the OpenAIS system for SSL lighting systems need to be interchangeable and allow replacement without changing the complete system.
Interoperability of the components is guaranteed on the physical level, the level of network connections and IP-end points.
The network stack must support the IEEE 802.15.4, Ethernet, Thread/6LoWPAN, IPv6, UDP, DTLS, CoAP (including multicast) and LWM2M protocols.
The OpenAIS lighting shall comply with lighting safety standards in each country.
Some key functions and performance metrics that need to be achieved in the integrated implementation are given in
Table 1.
4.1.1. Virtual Prototype
To validate system configuration and behavior in the early design phases and avoid errors and issues in the actual system development, we have created a model-based lighting system virtual prototype. A lighting system is specified using a Domain-Specific Language (DSL). DSLs are formal languages with formal syntax that generate executable models (simulators) for a particular application domain and thereby allowing static and dynamic validation of system instances.
We have created the following DSLs:
Building DSL, describing a building and its physical components;
Control template DSL, describing reusable Control functionality (e.g., cell office control behavior);
Control DSL, deploying the Control template DSL’s templates onto the Building DSL’s physical components;
Network DSL, describing the network topology;
Environment DSL, describing environmental triggers (e.g., occupancy and daylight patterns);
Visualization DSL, providing 2D visual models (e.g., buildings, luminaires and light outputs).
These DSLs are coupled and executed in a co-simulation framework, which addresses the timeliness of execution, synchronicity, data exchange and coherency of simulators.
Typical issues that affect the robustness of the system like power failure, start-up delays and memory errors are currently being simulated by using a fault model. Additionally, connectivity and bandwidth issues causing packet loss, delays, out-of-sync and variability in the delivery rate are also studied. Optimization strategies on adapting network topologies, retransmitting messages, fine-tuning of protocol parameters and adaptation of the control algorithms are being carried out to make sure that these inconsistencies do not affect much the performance and that the system is still responsive and behaves correctly.
4.1.2. Deployment
To validate the IoL architecture, a pilot installation in a real office setting with a paying customer had been envisioned. One of the premium buildings in Eindhoven, The Netherlands, The White Lady, a former Philips factory and now a national industrial monument, is the pilot site for validation [
4]. The system design and specification has been completed, and the installation will take place in the last quarter of 2017. Approximately 400 luminaires, with a mix of manufacturers, wired PoE and wireless controls will be installed in one of the floors of the building for a 3–6-month trial period. In addition to evaluating energy savings, enhanced lighting comfort and personal controls using apps, the complete ‘stakeholder journey’ from specifying, installing, using and maintaining the system will be evaluated. The total cost of ownership and the return on investment will be assessed and qualified accordingly. The pilot system design follows the regulations and relevant EU standards such as EN12464-1 [
19] for lighting requirements for indoor work places and EN-15193 [
20] for energy measurements.
The system configuration deployed in one of the wings of the pilot is given in
Table 2.
Here, we list the basic deployment of the functionality in the system.
For each restricted area like conference rooms, the coffee room and phone booths, one or more control groups are created.
Each group has a Control function deployed on one of its luminaires, which is configured to listen to specific sensors.
In the open areas, logical areas are formed (e.g., a set of four desks), and the corresponding Control function is deployed on one of its luminaires. The corridor’s controller is also configured and deployed in this way.
There is one floor controller that monitors all controllers in adjacent rooms and directly controls the Control functions in the corridor. Control functions like the Automatic Demand Response (ADR) are also included in the floor controller.
Data are gathered by DataCollect functions on the floor controllers, which have interfaces to the central controller in the building.
The power supply for luminaires has two forms. The first form is a parallel power supply. Each luminaire has its own power cable. A group of power cables is connected to a PoE switch. The second form is a series supply. The power cable of each luminaire is connected to a neighboring luminaire. Only the power cable of the first luminaire is connected to the PoE switch. In the implementation, both combinations are used depending on how the luminaires are grouped for power supply and how the existing power cables are deployed.
The requirements on Lux level change much in various conditions, which further affects the deployment of luminaires.
Table 3 demonstrates the Lux requirements in various conditions. The layout of the luminaires deployed depends on these requirements, and a suitable lighting design for the pilot has been created by professional lighting designers. Similarly, a network layout has also been designed. To meet the performance requirements given in
Table 1, in the wireless networks deployed, we limit the hop-count to a maximum of two between the wireless devices and the border routers.
To achieve a stable background light level for users, OpenAIS automatically balances the light level to surrounding light conditions, including daylight and other indoor lighting. Light sensors are deployed to provide input for the dimming values for luminaires to compensate for daylight. Control Objects in luminaires use information from all of the commissioned sensors (on/off, dimmer, local presence, daylight) to switch the light on when users are present and tune to the right dimming level. OpenAIS IoL supports building such application logics.
We will zoom into the following aspects that are relevant to the scope of the article.
4.2. Commissioning Plan
OpenAIS commissioning is adopting a pre-programmed workflow where devices are pre-programmed for their targeted operations prior to their installation. Site documentation on grouping and binding, parametrization and location identification information and system credentials are made available before commissioning. During the commissioning phase, a localization step is carried out where the relationship between the actual location of the device and the device ID is established. Afterwards, the devices are configured, functional verification is performed and a handover to the off-site commissioner (who refines the commissioning based on the customer request) is made.
To simplify the commissioning process and to reduce the commissioning time, OpenAIS is building a smart commissioning tool that can store the pre-programming workflow and assist the commissioner to easily localize, do grouping, binding and parametrization, set the system credentials and rectify on-site errors. The commissioning tool is used to setup and maintain various lighting configurations of devices. It links to the LWM2M server to aggregate device information and records the localization data during the commissioning operation. This information is stored in an external database for further processing. The commissioning tool mainly targets the themes shown in
Table 4. Based on these commissioning themes, the OpenAIS system is tested for whether it can provide the required services.
4.3. Out-Of-The-Box Operation
To verify the OpenAIS system after connection and installation, the devices are programmed with some specific behaviors called the out-of-the-box operations. These operations can be used for a first-step testing. This illustrates the basic operation of a system without commissioning. All actuators and sensors operate independently during out-of-the-box testing. For simplicity, the out-of-the-box operation excludes the Internet connection and security control.
There are mainly three testing categories in out-of-the-box operations, including physical devices, operational objects and networking. The out-of-the-box operations of physical devices demonstrate whether the devices are able to achieve correct states as in
Table 5. The operational objects are used for testing a simple control relation between devices as shown in
Table 6. Networking operations are to set up the basic connection operation of devices.
The basic settings for out-of-the-box networking operation are:
The devices can setup connections using IPv6.
Devices can setup a network without additional configuration once switched-on.
The network allows dynamic connectivity, which means that devices can be switched-on and can join the network at any moment.
The IPv6 multicast addresses are pre-programmed in the devices.
4.4. User Interaction with OpenAIS-Based Systems
The scope of intelligence and expectations from a smart building are subject to rapid change. Social demands from lighting may push unexpected requirements yet to be known. In order to cope with possible changes of expectations, OpenAIS chooses to be agnostic for the scope of intelligence. Instead of drawing boundaries of intelligence, OpenAIS leaves the largest possible room for different approaches towards the definition of intelligence. Hence, OpenAIS provides fundamental sensing and lighting control functionalities in the most performance effective way that is achievable by 2020’s technology.
Applications of OpenAIS are expected to exhibit smartness by utilizing the functionalities of OpenAIS. Developing applications for an existing lighting system used to require deep knowledge of the system (software architecture and network protocols) and the deployed instance of the system (network topology and interface of each device). However, OpenAIS drastically decreases the need for such knowledge through two innovations: IPv6-based lighting and the generic lighting API.
IPv6-based lighting and the lighting API enable the application development ability for almost any software developer rather than a small subset of specialists who possess up to date knowledge about a complex system. The OpenAIS ODM provides interfaces for the minimal set of operations sufficient for any lighting system deployment. Therefore, the ODM is the key building block of the API. However, the ODM itself is unable to address the expected functionality of an easily usable API.
The most tackling challenge of the ODM-based API is creating an infrastructure for allowing the user application to access functionalities of the ODM. Even though an API may allow accessing interfaces of all of the Objects, OpenAIS API enables access only for the interface of Control Objects. This is because Control Objects already utilize all functionalities of other Objects, providing a natural abstraction mechanism. Since access is restricted to Control Objects, the API becomes agnostic to the vendor differentiations of other Objects and their interaction with the Control Objects, i.e., future ODMs for different devices like luminaires may still utilize the existing API. This powerful flexibility is key to maintaining the API with minimal effort over the course of years. Moreover, the data model of the controller is expected to be similar to the Control Objects of different vendors. Hence, user applications will have backward compatibility and portability. However, the user application is not a part of the lighting system, despite utilizing the system’s functionalities. Therefore, user applications require a way to access the lighting system, which is provided by the LWM2M server. The LWM2M server can also translate HTTP requests to CoAP, allowing a simple web browser of a smartphone to access the system. The OpenAIS API is built using the HTTP protocol from the user application to the LWM2M server, which are then translated to OpenAIS CoAP messages that are sent to the Control Object.
Like other lighting systems, OpenAIS is designed to be agnostic to building plans. Because a lighting system has no knowledge of the location of Objects when it is installed, locations of rooms, hallways, sensors, switches, luminaires, and other entities, such location information is stored in the commissioning database during the deployment. Subsequently, the commissioning database enables the lighting system to locate specific Objects belonging to devices. CoAP messages of OpenAIS require the logical address of the Object in order to utilize functionalities of the corresponding Object. However, user applications usually want to act on the location of the Object, rather than its logical address. The OpenAIS API allows user applications to access the commissioning database in order to query the logical address of an Object based on its location. User applications can create CoAP messages for the intended Objects based on their location and utilize the functionality of the data model. Any user application that can access the LWM2M server can control all of the functionalities of OpenAIS. Therefore, access to the LWM2M server is protected with verified usernames and passwords. Users are asked to provide their credentials in order to access the LWM2M server.
4.5. Time Synchronization
An OpenAIS network is an IoT mesh network that needs time synchronization for several purposes. First of all, intelligent lighting requires an ordering of sensing and control events in time. Secondly, network-wide asynchronous coordination strategies for distributed applications are required. Finally, logging and debugging are only possible when there is time synchronization between the entities that log event-time pairs.
The Network Time Protocol (NTP), which is widely in use on the Internet, cannot be directly employed here due to its resource requirements from the network and the devices. In the OpenAIS project, we developed the Mesh Time Protocol (MTP) for time synchronization of nodes in a mesh network to one resource-rich node on the same mesh, such as a Gateway. The Gateway itself is synchronized with the Coordinated Universal Time (UTC) using NTP. The OpenAIS MTP is used to disseminate the UTC time in the mesh using radio broadcasts.
MTP is a modification of the 6LNTP protocol [
21]. Nodes synchronize their time using broadcast messages, through their neighbours hop-by-hop. In order to synchronize its time, a node sends a unicast request (REQ) message to the Gateway. This triggers the Gateway to send a synchronization (SYNC) message to its one-hop neighbours, and the Gateway captures timestamp
of transmitting this message. After transmitting the SYNC message, the Gateway sends a correction (CORR) message that contains
to its one-hop neighbours. Having received both messages, a node in the one-hop neighbourhood of the Gateway can calculate the sender’s time offset with respect to itself and uses this information to correct its local clock (to sync with the Gateway). The nodes that have already synced with the Gateway then send SYNC messages to the nodes in their one-hop neighbourhood, and the time propagates to the entire network in this way.
5. System Analysis
To analyze the capabilities of the OpenAIS prototype and evaluate its performance, we identified a set of critical aspects of the system from the user requirements. These aspects are then processed into well-defined technical criteria. To make the criteria measurable and comparable, a team of 10 experts from the OpenAIS architectural team jointly defined the criteria and then broke them down into three well-defined sub-criteria per criterion, which are in turn split into five independent levels for scoring.
Table 7 shows two criteria, namely performance and use of open standards and their respective sub-criteria. In some cases, the sub-criteria might have different priority levels, which are assigned based on the expert opinions. For example, the sub-criteria time-to-light, synchronicity and start-up time of the criterion performance are assigned weights 0.5, 0.35 and 0.15, respectively. The total score of a criterion is then the weighted sum of the score of its sub-criteria. Although, this process relies on expert opinions for scoring, the results are often useful and reproducible.
To avoid different interpretations or confusions during scoring, per sub-criterion, five independent levels for scoring are defined; two examples are given in
Table 8. Although, this process relies on expert opinions for scoring, the well-defined scoring levels reduce the differences in scoring among the experts. Additionally, ambiguities were resolved in the team discussions. For the clearly quantifiable sub-criteria, the results from empirical analysis or simulation/mathematical models were used to back the scoring. This makes the results of the otherwise fairly subjective process useful and reproducible.
For comparing the performance of the OpenAIS system against a state-of-the-art system, we chose the most recent heritage system called LITECOM that was introduced in 2014 [
22]. LITECOM is a DALI standard-based product with intelligent lighting controls. A DALI-based system is selected for comparison because many buildings that deploy other automation systems like KNX often use DALI subsystems interfaced via gateways for lighting controls. To score LITECOM system, two architects who developed LITECOM and that were also involved in the development of the OpenAIS architecture were approached.
5.1. Comparison of OpenAIS Pilot Implementation and LITECOM
A comparison of OpenAIS pilot and LITECOM based on eight criteria is shown
Figure 6. The evaluation is undertaken by the designers of both architectures, according to a list of decision-making criteria, which is generated by intelligence lighting domain experts. The spider diagram shows that the OpenAIS system exceeds LITECOM in all KPIs evaluated except for performance and power efficiency. OpenAIS is really strong in:
As discussed in
Section 2.2, one of the key goals of going towards IoL is to use open standards. Hence, the OpenAIS system is using open standards to realize IP connectivity (including L1, L2, L3), a standard application-level IoT framework (L4–L7) and open data/object models. This also allows reusing existing standards and software from the wider IT domain. LITECOM is based on the DALI standard and uses proprietary data models.
We have seen that existing lighting standards are weak when it comes to security. Being an IoT system, security is core to the OpenAIS architecture, and it makes use of the state-of-the-art security mechanisms in IT systems and adds on top of it.
Business control points (vendor differentiation) allow vendors to deploy their own differentiating offer without conflicting with the standard. This allows them to provide additional functionalities above the standard features. OpenAIS systems easily support multiple vendors and allow such functionality, whereas LITECOM systems are designed as single vendor systems.
In other aspects, such as interoperability, extensibility and scalability, OpenAIS is rated better than LITECOM. The power efficiency is slightly less than that of LITECOM, but comparable. The performance of general-purpose IP-based communication is less than the fully-optimized task-specific communication in the heritage systems. However, this lower rating is still in an acceptable range, as stated in
Table 1.
A SWOT analysis of the OpenAIS system highlighting strengths, weaknesses, opportunities and threats is given in
Table 9.
5.2. Provisions to Support KPIs
The details of the KPIs and architectural provisions to support them are discussed below.
5.2.1. Extensibility
OpenAIS systems can easily extend their functionality, network size and coverage. We have seen in
Section 3.3 that the stacking of Control functions allows extending functionality easily by adding new Control functions (even from the cloud) that can override or extend existing ones. The support for adding identical Object (instances) to one physical device also helps with extending the system behavior without the need to update its software. At the time of configuration/commissioning, the appropriate behavior can be enabled. The provision for adding new or renewed Objects also helps with supporting future communication protocols and additional protocol integration without conflicting with the functionality of the already commissioned system. The modular structure allows trusted (third) parties to add plugins or change single modules of device software and thereby update the software. Hardware drivers can also be updated without jeopardizing the already commissioned working system by relying on the original API.
5.2.2. Interoperability with BAS
Many times, IT infrastructures, BAS and (connected) lighting infrastructures are seen as separate investments where the combination does not have added value for building owners, due to the typical lack of interoperability between these systems. OpenAIS makes interoperability with BAS possible thanks to the following aspects. First of all, it allows transparency of input/output, trends, operations and maintenance data of the lighting subsystem. Furthermore, in general, the amount of effort needed by experts (from both domains) for configuration and maintenance of connections between BAS and lighting systems is a concern. Therefore, the fact that the OpenAIS solution is based purely on open standards instead of proprietary solutions is a big advantage. In the OpenAIS project, an extensive study of potential gateway architectures for connecting legacy networks to an OpenAIS system was performed. As a proof of concept, a ZigBee gateway that can mediate discovery, switching (on/off) and multicast interactions between the ZigBee network and the OpenAIS IoL network was implemented and tested successfully. Thirdly, building-wide energy optimizations are possible if data from both systems can be taken into account.
5.2.3. Security and Privacy
Security is the utmost requirement for a large networked system to be deployed in an office environment. Modern lighting systems offer many features requiring the use of personal information, most importantly the presence sensor information. Use of such sensitive information mandates not only authenticated access, but also authorization. Privacy can be ensured by setting up policies on the access of data based on proper authentication and authorization. The OpenAIS ODM flexibly supports different user roles with the corresponding authorization levels. Moreover, OpenAIS relies on state-of-the-art security techniques for not hampering the overall performance of the system. Instead of the traditional network security mechanism of the public private key pair, OpenAIS utilizes a novel multicast security protocol by employing symmetric keys for secure transmission of IP multicast packets. Thus, security does not add a significant load for time-to-light, the most important performance criterion.
The security of IoT devices is not a fully-resolved issue. A diverse threat model where the protection of devices, network, data and applications is needed. The security solutions of OpenAIS that extend the state-of-the-art security techniques need to be fail-proof. Furthermore, strong policies and enforcement of these policies for data storage and handling needs to be established.
5.2.4. Performance
As pointed out in
Table 1, many lighting operations have to be completed within certain deadlines. The most performance-sensitive operations are time to light, switching synchronicity of a group of luminaires (variance of time to light within the group) and start-up time of the system after a power loss. OpenAIS systems can be designed to get the same time to light performance as LITECOM, but synchronicity or start-up time may not be on a par with it. The cost of using open standards and keeping the architecture secure makes the performance of OpenAIS slightly less when compared to LITECOM. This is because closed systems can usually take advantage of cross-layer network protocol stack design, and they tend to impose tailored solutions rather than highly automated solutions.
Even though the performance of OpenAIS systems heavily depends on the performance of open Internet standards, architectural decisions of OpenAIS led to achieving the boundaries stated in
Table 1. As the performance of the standards usually improves with the technological advancements, OpenAIS is expected to stand the test of time for many years to come, in terms of performance.
5.2.5. Business Control Points (Vendor Differentiation)
OpenAIS is not a product by itself. It is a base for lighting vendors to manufacture interoperable products that comply with common principles of performance, security, scalability and extensibility while agreeing upon the same interfaces for semantic communication. OpenAIS leaves great room for each vendor to differentiate their product from the other vendors. For example, if a vendor innovates for more advanced products, OpenAIS actually makes it easier to add the advanced capabilities of devices or services into the connected luminaire network.
5.2.6. Use of Open Standards
OpenAIS strongly utilizes open standards and does not bring forward proprietary solutions. This design decision contributes to elevating other aspects of the architecture such as interoperability, extensibility, security and business control points.
OpenAIS solely relies on existing standards for IP connectivity of the devices. However, IoT is more than the IP connectivity. There are also IoT standards for upper layers of the protocol stack (i.e., L4–L7). For that, OpenAIS utilizes LWM2M, which is published by OMA. Moreover, data models of the OpenAIS also follow open standards in order to keep the possible information change simple.
5.2.7. Scalability
OpenAIS is intended for offices with any size. Typically, it is more difficult to add new devices to large setups since this increases maintenance costs and degrades the performance. However, OpenAIS scales quite well thanks to the flexibly stacking Control Objects. For large setups, such flexible hierarchical stacking of Control Objects ensures scalability without performance degradation or loss of functionality.
5.2.8. Power Efficiency
Power efficiency is the most important reason to switch over to SSL. The power consumption of the whole lighting system also includes consumption of devices such as control, interface and network/infrastructure, other on-premises devices, such as servers and databases, as well as various power losses. The standby power consumption of LED luminaire and sensors in OpenAIS is mostly in line with any modern lighting system. The infrastructural devices’ power efficiency is slightly lower than dedicated lighting devices. Having a smart lighting control, for example occupancy and daylight-based control, helps OpenAIS achieve additional energy savings. The interoperability with BAS allows building-wide energy optimization. Intelligent data analytics provides accurate energy consumption data and reporting capabilities that can further optimize energy usage.
5.3. Interoperability Specification and Standardization
OpenAIS regards IoT standards (protocols and frameworks) as carriers and uses them according to their original specification. The OpenAIS Interoperability Specification (OpenAIS-IS) enables third parties to develop components independently and to integrate them into a working system consisting of components that satisfy this specification. It specifies a minimal core (OpenAIS-MC) that is essential for the OpenAIS innovation and provides explicit means to extend a system beyond OpenAIS-MC. Third parties are free to extend functionality beyond OpenAIS-MC provided that it does not interfere with OpenAIS-MC.
The three pillars of the OpenAIS-IS are: (i) a reference specification; (ii) a reference implementation; and (iii) a method for interoperability validation. The reference specification gives a high-level specification of concepts, with limited relationships to particular technologies. It gives what is common in different realizations and defines the OpenAIS reference architecture (main scenarios of use, commissioning, management and update), as well as the OpenAIS protocols and interfaces. Furthermore, it presents a data model that considers devices as containers of Actuator, Sensor and Control Objects. The reference implementation, on the other hand, is a detailed instantiation of the reference specification. The reference specification and the reference implementation together constitute the OpenAIS-IS. Finally, interoperability validation is used to test the implemented rules and processes for interoperation. OpenAIS defines a set of interoperable interfaces of the system, as well as interoperability test cases (scenarios) and their required outcomes.
The vision of the recently-formed Fairhair alliance (partner program of IEEE-ISTO) [
23] supports the OpenAIS IoT approach and gives an opportunity to standardize (parts of the) OpenAIS specification for a wider scope. As the OpenAIS ODMs are built on top of LWM2M/IPSO models, standardization through the IPSO alliance is also possible. The OpenAIS security for Group Communication is currently being standardized in Internet Engineering Task Force (IETF) [
18].
7. Conclusions and Outlook
In this article, we explained how the lighting industry can benefit from IoT by moving from the traditional closed and proprietary systems to secure, extensible, interoperable and service-oriented systems. We presented an Internet of Light architecture, OpenAIS, designed to address the challenges while making this transition. An overview of the OpenAIS IoL architecture with a deeper look from different architectural perspectives has been provided. Additionally, a system solution explaining the design of a pilot system, with its configurations and design choices, has been provided. An analysis of the system by comparing it with a state-of-the-art commercial solution shows how IoL systems can exceed proprietary systems in several KPIs such as security, interoperability, extensibility and openness. A SWOT analysis of the OpenAIS system highlighting strengths, weaknesses, opportunities and threats is also provided.
The system analysis shows that despite careful design choices, the performance of the IoL is slightly lower than proprietary solutions. The transition towards IoT enables using/sharing the network infrastructure in the building instead of employing a dedicated network for each building services. Ensuring reliability and guaranteed performance of dedicated lighting networks in shared networks will be a challenge. The security and privacy of IoL is an issue not fully resolved. Careful monitoring of security vulnerabilities and updating to the latest security provisions are needed. To ensure privacy, strong policies and their enforcement for data storage and handling are needed. A careful study on the impact of IoL on various stakeholders and the changes it brings in to the lighting value chain and building sector need to be carefully analyzed.