Integrating Lighting in the Internet of Things

The Internet of Things (IoT) extends the Internet Protocol (IP) communication beyond its established markets in computers and mobile phones to billions of resourceconstrained endpoints (“things”). In the lighting domain these “things” will comprise physical devices as intelligent luminaires and sensors as well as infrastructural elements as gateways. IoT opens these “things” to regular Internet services and fast networks allowing (remote) control and data collection from these devices. The introduction of IoT as the backbone for connected lighting systems enables seamless communication, contextual services and data sharing between devices (“things”) and is bringing radical changes to the industries by converging multitudes of vertical markets.

The lighting industry has been going through a transformation to Solid State Lighting for some years. The introduction of LED-based systems enables increased control capabilities (e.g., switching and dimming) and reduced operational costs and energy consumption. Incorporating IoT and connectivity in lighting systems now creates yet another revolution and opens a plethora of new opportunities and value propositions. IoT-technology is maturing quickly, which makes it economically feasible to connect each luminaire to the Internet. Hence, it is an excellent opportunity to establish the Internet of Lights, i.e., an advanced lighting system with IoT at its core.

Benefits of the Internet of Lights

Converting to IoT based systems will introduce mainstream digital and communication technologies in the lighting domain. As in other digitized domains, this transformation is expected to come with advantages in (product) costs, development efficiency and availability of solutions and vendors. This will provide opportunities for the lighting industry to decrease both CapEx and OpEx costs by leveraging on commodity hardware, network and other software stacks. A transition towards IoT is not merely a cost reduction effort, it brings several additional 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 also enables flexibility and interoperability with other systems such as Building Management Systems (BMS), smart grids and cloud services. It provides flexibility to seamlessly combine multiple connectivity technologies, for example, in both wired and wireless solutions and eliminates the need for expensive gateways for doing application layer translations. Finally, it enables a large variety of new services. For example, sharing occupancy data collected by presence detectors used for lighting controls with BMS 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 by increasing the building performance rating and reducing the carbon footprint.

User Scenarios of the 2020’s

The project researched the requirements for the office environments of 2020 and beyond. The information obtained in structured interviews with industry experts across the value chain, were analyzed, distilled and grouped into three main “super” scenarios.

The three "super" scenarios:
• Easy Life “…a solution that is easy to specify, design, install, commission,
  operate and maintain without making compromises on the ease of use…”
• Increase Building Value “…in the changing world of office space, provision
  owners will need to make their properties more attractive for businesses to
  lease or rent...”trophy workplaces” making visits to the office a luxury and a
  rewarding experience…”
• Building Wide Ecosystem “….in the future, systems in a building will be
  expected to share sensors and seamlessly interoperate to the benefit of
  the building and their stakeholders”

These scenarios form the cornerstone motivations behind the design work and value proposition.

The Architectural Challenges

Existing IoT architectures do not fully meet the requirements from the lighting industry and other stakeholders. Every IoT framework investigated was missing features for application in lighting control systems.

The most important features:
• Low-latency group communication: Most IoT frameworks are very much
  focussed on connecting field devices to the cloud. For many IoT
  applications like vending machines this is a suitable set-up. However,
  lighting has the unique property of intensive real-time local coordination and
  communication between many nodes. Therefore, efficient and secured n:m
  communication between the nodes in a system is a prerequisite
• Operation not dependent of central cloud server: lighting functions must be
  available always, therefore local communication and control has to be
  available also when a central server or a cloud connection is absent, be it
  temporarily or permanently. This again requires an independent, network-
  based communication amongst nodes
• For the application layer a dedicated Object Model was developed, as
  evaluation showed that public models like IPSO were much too limited for
  advanced high quality lighting control and simple integration into BMS’s.
  Existing application models like ZigBee or KNX were not taken into
  account by the consortium as they did not support IP natively (yet)

The OpenAIS Solution

We will now detail the architectural solution as proposed by the consortium. We will start with a discussion on the selection of a suitable IoT-framework to build the Internet of Lights on. This paragraph will be followed by a description of the network stack build-up. After that, we will focus on the two main topics identified above, the OpenAIS Group Communication and Object Model. Finally, we will explain how commercially differentiating features can be created.

IoT-framework

During the state-of-the-art research phase in 2015, various existing and upcoming IoT standards offering lightweight IP-based management and control were investigated. One of these standards is Lightweight M2M defined by the Open Mobile Alliance (OMA), abbreviated “LWM2M”. The public Version 1.0 of the LWM2M standard has been chosen as the basis for the OpenAIS architecture.

LWM2M is a framework for device management and service enablement that defines the LWM2M protocol between a LWM2M Client (i.e. a resourceconstrained M2M field device) and a LWM2M Server (which is the configuring entity and typically not resource-constrained). The protocol was developed for use over cellular M2M connections with potentially very low bandwidth and a nonnegligible communication cost per kilobyte, but the standard is also applicable when used over any other IP-based network technology.

The protocol is optimized for resource constrained field devices, that is, devices with limited RAM, limited flash memory, low-bandwidth connectivity and/or limited CPU resources. LWM2M uses the Constrained Application Protocol CoAP as a transport mechanism. It also supports data payloads in multiple data format standards: industry-standard JSON, compact TLV and plain text/numbers.

A key advantage of LWM2M compared to other IoT initiatives at the moment of selection was that it had a released specification and implementations already on the market.

Network stack

In the choices made for the network stack the project objectives are clearly visible.

Figure 1: Network stack

Project objectives:
• IPv6-based communication with UDP as the transport layer. IPv6 multicast
  and 6LoWPAN compression will be supported
• Support any (future) physical medium that is IPv6 capable and is able to
  deliver a defined minimum transport capacity. Typical larger systems will
  have a LAN backbone with IP routers or Border Routers to integrate
  different local IoT networks (using e.g. BT, BLE, 6LoWPAN, Wi-Fi, PLC,
  VLC, PoE, etc.)
• All communication uses the well-standardized CoAP protocol, defined by
  the IETF especially for use in the domain of constrained embedded
  devices. CoAP implements the REST communication paradigm that
  powers today’s web services
• Security and privacy of data communication are achieved by using a
  combination of transport layer (DTLS) and application layer (OSCORE)
  based encryption
• On top of these layers, LWM2M and other services run. Finally an
  application layer has been specified, which is elaborated in the Object
  Model paragraph

Open (Secure) Group Communication (OGC)

The consortium developed a group communication mechanism that operates in parallel to LWM2M device control to provide low latency and controlled bandwidth communication links, needed in lighting controls for professional buildings. Secure OpenAIS Group Communication enables the operative lighting use cases, supports local (node to node) control and event handling and ensures interoperability across vendors. Setup of groups is secured through commissioning.

Important characteristics and design choices for the mechanism are:
• CoAP Multicast [RFC7252] [RFC7390] protocol over IPv6 multicast
• Support for multiple Application Groups re-using an IPv6 Multicast Group,
  to obtain efficiency in the usage of IPv6 multicast addresses
• Multicast security model, offering authentication and authorization for
  multicast group commands or requests that is fast enough for lighting
  control
• Multiple instances of a particular object type at a single node are
  reachable with a single group request, even if the object instances have
  different instance identifiers across different devices. Multiple object
  instances at a single node may be associated with different groups to
  support lighting application best
• Multiple IPv6 Multicast Groups (destinations) supported per OpenAIS
  device, supporting complex device and controls structures
• Support of multiple IPv6 (multicast and unicast) destination addresses per
  group to allow for situations where multicast reachability of (some) devices
  is hampered by router settings or firewalls

The Group Communication is used in parallel with LWM2M.

Future systems may, if needed, use other IoT frameworks and still stay interoperable through use of the OpenAIS Group Communication (OGC). OGC can be applied across diverse IoT frameworks, enabling interoperability for lighting controls.

In our view, OGC is a nondifferentiating middleware stack that enables differentiated commercial solutions and is a prerequisite for interoperability between vendors on device level.

Object model

This application layer is completely based on a Sensor-Control-Actuator model to which the project added a datacollect object that simplifies the data acquisition in lighting networks. The OpenAIS Object Model is structured as a RESTful architecture. In the implementation CoAP and JSON have been used to implement a versatile RESTful communication. In the object model we identify next to common functionality for presence, buttons, on, off, dim and color control a number of new concepts.

Figure 2: OpenAIS Object Model examples

New concepts:
• Data Collect Object: A data object allows the collection of all status/event
  information as transmitted by actuators, sensors and groups in the
  system. It offers functionality for (pre)processing data (grouping, trending,
  compressing, and data reduction), intermediate storage and buffering, e.g.
  when the connection to the back-end/cloud is limited or interrupted
• The common API for group communication is represented by a unified
  logical object (per application), that hands over the data and requests to
  the (fully vendor specific) physical objects. This structural approach also
  helps to arbitrate conflicting requests to a single actuator
• Layered architecture: Contrary to ZigBee, that has the concept of direct
  links between sensors and actuators, in the OpenAIS architecture control
  objects sit “in between” sensors and actuators. These contain the logic
  that determines the actions to be taken on events, and may be physically
  placed at any place (sensor, actuator, server or cloud “devices”)
• Stacking of control objects: The architecture allows the stacking of control
  objects, i.e. Superior Control Objects can control groups of control objects
  and base their behaviour on the combined sensors settings of these
  groups. Simple examples of this behaviour are open plan behaviour or
  corridor linking. Note that this hierarchical model can be more than one
  deep. There may be floor and building control objects to represent even
  higher levels of control, e.g. scheduled control for an entire building.
  Stacking is organized to provide local control if superior control fails or
  becomes (temporarily) not available
• Redundancy: The architecture also includes mechanisms to define
  redundant control behaviour, where secondary or ghost control objects can
  serve as a fall back in case of communication interruptions or
  software/node crashes
• Legacy systems are incorporated using (application-layer) gateways that
  talk “OpenAIS” on the IPv6 interface. The level of legacy integration is up to
  the designers of the gateways and not limited by OpenAIS
• OpenAIS provides out-of-the-box functionality, which delivers (non-secured)
  basic operation to ease installation and installation-testing for luminaires,
  switches, presence detectors and light sensors
• Mobile devices like tablets and phones provide user control of this system
  with fine-grained access control and authentication. User access may
  include functions like selection of control algorithms/modes, as well as
  direct on-demand (lighting) group control. This is achieved without the need
  to commission the mobile device as a part of the system. Access control
  (AA/AAA) can be executed on a building server or in the cloud using
  standard IT solutions
• Cloud services benefit also from the data collector objects that also
  provides extended authentication and encryption before sending data
  to the cloud

In figure 2, some standard examples of instances of the object model are given. The Reference Architecture has been published including the object model [1].

Support for commercially differentiated solutions

The Architecture supports the stacking of control functions, which means that a new control function can be added to a system. This function can extend the already existing functionality by “controlling or overriding the control function”, without the need to physically replace it or take the existing one out.

Multiple object instances relating to one physical object can be used with a specific binding for each object instance. This mechanism can be used to extend the system behavior by configuration/ commissioning only. It can be used in a way that the basic behavior of the already commissioned system is maintained and used as fallback.

Additional or derived object (classes) may be added to the device, providing additional features. Such objects may also be created in a way that additional communication (frameworks) and properties are used, to support specific IoT data protocols, or even add in parallel future communication protocols like KNX/IoT, BACnet/IoT.

The basic security mechanisms and keys as implemented in OGC can also be used to protect commercial extensions and options in the field.

Large Scale Pilot

The consortium has chosen to validate and demonstrate the system in a real- life pilot, as this yields superior feedback and pushes the partners to deliver an implementation close to production quality. In this pilot, a lighting system prototype at scale of 400 luminiares - mixed vendor, mixed wired and wireless and mixed mains and UPoE devices - has been deployed successfully.

For the Pilot location, the “White Lady” building in Eindhoven has been selected. The building itself is a former Philips factory built in 1930 where light bulbs were made. Renovated by the city of Eindhoven it is now a national monument and in daily use as offices. Architects from all over the world study and visit the building for its remarkable design. It is therefore ideal to demonstrate the new OpenAIS architecture for lighting controls. The 5th floor tenant, GGD-BZO (municipal health service), has embarked on a renovation journey to update to LED using the latest controls architecture for lights.

Figure 3: The White Lady building with the OpenAIS pilot on the 5th floor

For the pilot, the consortium did a complete light, control and network design as well as the installation, commissioning and operation of the building.

Philips provided SmartBalance and PowerBalance luminaires, with adapted UPoE LED-drivers. For wireless, a module was implemented using NXP MCU and RF chips to design Thread connected luminaires. These wireless modules were used to control desk lights. A full non-differentiating software control and communication stack was implemented based upon the LWM2M and ARM Mbed embedded software platform and extended with the lighting specific and/or vendor specific additions. All luminiares are equipped with embedded PIR and lightlevel sensors. Zumtobel contributed luminaires from their Mirel and Glacier series, equipped with Tridonics’ Net4more (ethernet and Thread) communication modules, LED-drivers and embedded occupancy and lightlevel sensors.

Power is supplied via conventional mains cables or via PoE for stand-alone sensors. The common control and communication stack is used also with ARM’s Mbed embedded software platform.

Dynniq provided the IT infrastucture based on Cisco’s UPoE switches for the wired backbone and developed a commissioning tool. ARM and NXP provided the Thread border routers as the backbone of the wireless network. ARM provided Mbed as the common software development platform.

Johnson Controls integrated their Metasys BMS system into the system, collecting the data from the lighting system, e.g. energy consumption and occupancy data, and visualizes this data for workflow and process optimizations. They also implemented direct control of the lighting control strategy, operating with scenes and schedules.

Figure 4: User control app by TU/e (left). Impressions of the pilot office space in the White Lady building. Luminaires from Philips (top right) and Zumtobel (bottom right)

TU/e provided mobile apps for personal control of light settings at the individual workplaces and for scene settings in the meeting rooms.

Advanced lighting control strategies have been deployed including granular sensing and control strategies (local dimming) using local occupancy and light level sensing per luminaire. Personal control is achieved via Office Mobile app.

Validation and Demonstration

At the time of writing, the pilot has been successfully launched and the building is in full operational use by the tenant. The validation of the OpenAIS architecture is in progress through an extensive program that includes checking of the user requirements as collected for the 3 main 2020 “super”scenario’s described above. Furthermore there is a more specific Pilot specification that describes the details of the White Lady Installation and control, that will be validated together with the pilot design, the system, the Lighting, the network, the controls aspects and the user satisfaction. Naturally some aspects of the solution are not directly part of the pilot specification, but extremely important to assess, for example, the responsiveness and synchronisation reliability etc. Yet as these are essential aspects of the architecture, they will also be validated using the White Lady prototype.

The most visible public result until now is shown in the picture below. During the 2017 Eindhoven Glow Light festival the installation was used to play patterns visible from the façade of the building, showing the flexibility and performance of the control solution.

Figure 5: OpenAIS light show during the Eindhoven Glow Light Festival

Conclusion

OpenAIS has designed and implemented a fully functional (and stable) multi-vendor lighting control system based on IoTstandards and frameworks, with the IPv6 protocol to all end nodes, in a hybrid system of mixed wired and wireless networks. By using standard IP communication, translating gateways and proprietary protocols have been completely avoided.

At the same time, the consortium has proposed and validated a middleware solution to address the lighting specific digital era challenges in professional spaces of secure low latency group communication, central server independence and support for commercially differentiated solutions. It also defined and validated an object model for interoperable high quality office lighting and seamless integration into (future) BMS. The system specification and API’s are open available, enabling interoperability between the participating lighting vendors, as well as independent 3rd party developers of value added software.

The system offers a flexible lighting control mechanism allowing the fast implementation of many advanced and challenging use cases as will be demanded by the office workers and building owners of the 2020’s. OpenAIS has addressed the challenges of extending the Internet Protocol application to resource constrained IoT end nodes for professional lighting.

References:
[1] (http://www.openais.eu/en/results/)