Challenges of the Integration of Lighting Systems and Components in IoT

Over the past 3 years the OpenAIS project has worked on use cases, requirements and an architecture exploiting emerging IoT-technologies and IP to the end node for lighting. The defined architecture was implemented and evaluated in a real operational office environment by the installation of 400 luminaires in the White Lady building in Eindhoven (Figure 1). The installed system comprises wired and wireless luminaires from two different vendors: Philips and Zumtobel, seamlessly operating as one system. Use cases exploiting the advantages of this new lighting control system, for example: app-based personal light control, BMS integration and daylight control have been demonstrated.

During the creation and evaluation of this pilot, the team had to overcome several challenges that result from applying not yet mature or “fit for purpose” IoT-technologies in this first of a kind lighting control system. This article describes the solutions to these challenges composed by the project team and the lessons derived for future IoT-based Lighting Control Systems.

Figure 1: The White Lady pilot site

The Move To IoT

The move to IoT fits in the overall picture of four decades of digitization. Where the digital changeover first happened in the domains of complex and large equipment like manufacturing lines and medical devices, it gradually came down, driven by the relentless Moore’s law, via CE and telecommunication devices to finally reach even the smallest devices like door locks, luminaires and lamps. In all the affected domains this transformation has come with significant benefits in (product) costs and development efficiency by leveraging hardware, network and software stacks from a rapidly expanding ecosystem offering standardized solutions. The evolving and expanding ecosystems, often driven by de-facto (not formal) standardization, truly changed the way of working in entire industries.

The digital transformation in lighting does not only offer cost reduction, it also brings several additional benefits. Lighting systems can now utilize the network infrastructure in the building for control (and sometimes power) instead of using dedicated (and often costly) lighting solutions. Off the shelf protocols are supported by transparent gateways without (application) protocol translations and related development effort. Standard IP connectivity for lighting also enables much easier interoperability with other systems, such as Building Automation Systems (BAS), smart grids and cloud services that all are moving or have moved away from dedicated connection and protocols towards IP-backbones.

The interoperability, the IPstandardization, the network openness and growing ecosystem, together, enable a growing offering of services that are now unavailable or often nearly (economically) impossible. A simple example of such service can be found in the well-known occupancy detection function, applied in lighting systems for energy reduction purposes and ease of use already for decades. Sharing the available occupancy data collected by presence detectors of the lighting control system with HVAC, opens up advanced control and increased energy saving opportunities.

Many have therefore predicted the approaching end of controls systems and protocols that are intended to control lighting only. The project is first to fulfill this promise of an open IP-based system for professional indoor lighting controls.

Overview of Lighting Specific Challenges for the Project

Despite the fact that lighting does follow the general historic trends in digitization, the research revealed several lighting systems specifics that prevent a simple, one to one application of these in the lighting domain. The following points require specific attention when introducing standard IoT-technology for lighting control systems.

Duration of deployment

Lighting systems are normally deployed in a building for at least 20 years of continuous operation, the major maintenance activity over that period being the replacement of lamps/lLEDs reaching their designated end of life. However, digital systems, in general, have a much shorter (economic) lifetime. Network protocols, cpu’s and software standards tend to be replaced at a frequency of just a few years. Various strategies to deal with this discrepancy have been applied in different industries with the “throw away after two years” of the early PC and mobile phone markets as the extreme variant of upgrade strategy. As replacing the entire luminaire after a few years is not a viable approach in the lighting industry (the cost of installation of the same order of magnitude the cost of the luminaires) other options need to be explored.

Short response delay

Where most IoT-applications focus on connecting (distributed) sensors and equipment to the internet sec, the lighting application stands out from the pack, as it requires, in office environments, extensive local communication between end nodes for, e.g. group behaviour and immediate and deterministic reaction to user requests. Also synchronization of multiple devices, like a group of luminaires has requirements in the 100 milliseconds second range that can not be guarenteed by a fully internet/cloud based control solution.

Local Operation and Availability

Despite its “ubiquity” and “normality” the presence of lighting often gets unnoticed and we tend to forget that lighting is actually a mission critical application in many “daily” circumstances, being a condition for productivity inside buildings and during certain periods of the year/day. In many circumstances the availability of lighting is directly related to safety. Development and even education is greatly boosted in countries where electrical lighting is introduced. This position demands availability of lighting; always, everywhere and with a fast reaction to lighting demands. Currently, internet connectivity and responsiveness have not yet reached the service levels of, for example, power networks in most countries. This requires the architecture to foresee local operation and availability even in situations with loss of connectivity towards central servers or the Internet.

The above lighting specific characteristics should be carefully considered when designing a lighting control system based on IoT-technologies. In the next paragraph we will list further challenges that will include more “standard” issues that come with digitization as well as those that are the consequence of being very early in the adaptation of IP-technology in this domain.

Overview of Generic Challenges for IP Controlled Lighting

The challenges that the project faced during its three and a half year itinerary into IoT-based lighting fall into several categories:

Early adopter effects

OpenAIS is designing and implementing a new lighting controls architecture fully based on IP to the end node and on IoTplatforms. Although all partners agree on this direction and share the belief that the final stage of lighting controls will be its full absorption into the IoT-infrastructure in buildings, it is still early days for an actual implementation. Many required technologies, both hardware and software, were available in prototype form only and still are maturing, leading to regular releases of improved versions. As a research project for the participating companies many of the developments have been prototypes only. Also, the architecture had to be based upon roadmaps and projections in many areas, where actual implementations were not yet available. Consequently, the implementation had to deal with the immaturity of the field, which led to major challenges. Main points here:

Overall silicon roadmaps:

Cost and availability of processors with sufficient storage capacity and computing power. Although Moore’s law and the progress of the silicon roadmap is the driving force that has opened up the vision of IoT-based lighting in the first place, reality is lagging here. Designing architecture for 2020 and beyond is reasonable and feasible based on the overall silicon roadmaps and the insights of the silicon partners in the project. However, the prototype implementation for the White Lady pilot, had to be based on existing silicon and CPU’s, which were restricted in price and performance vs. the long-time expectations for the project.

IoT-frameworks & stacks:

Applying a standard IoT-framework to implement all basic connectivity and functionality is at the core of the OpenAIS philosophy and goals. However, at the start of the project most of the IoT-frameworks, if even announced, were paper ware at best. Even the IoT-framework selected (LWM2M) and its ARMMBED implementation as main carrier were in an early phase of their development. During the project the stacks were continuously being extended, improved and matured by their suppliers. It is expected that this process will continue for some years, while IoT is maturing. Also, many more IoT-stacks have emerged over the duration of the project and any project starting such an endeavor now should perform a new state-of-theart investigation to select the appropriate one.

Integration in the IT domain

Integrating lighting in the IT infrastructure using open standards has been ongoing since the introduction of techniques like Power over Ethernet (POE), but is still relatively new for lighting suppliers, who previously relied on fully proprietary and separated busses and infrastructure. This brings a whole new viewpoint to the lighting design phase, including performance guarantees (and demands), throughput and reachability for lighting control and data reporting. Entering the IT-world also drives a whole new set of requirements, especially around security (and privacy) because now lighting will be prone to attacks, viruses and hacking as well. Hence, there is an increasing challenge to implement security in resource-constrained devices.

Interoperability and standardization

Customers in the 2020’s will require that luminaires from multiple vendors can be mixed and controlled with the same system. At least the key functions such as switching on and off and dimming must be fully interoperable. More advanced features like, for instance, following circadian rhythms in an optimized way, can still be proprietary and offer competing companies an opportunity to differentiate. In addition, interfaces with BIM and the BMS must work seamlessly across vendors. This requires an unambiguously agreed upon standard.

Shifts in the value chain

A final aspect and important challenge recognized by the consortium from the beginning was the impact the proposed changes, with lighting becoming an integral element of the building wide IoT-network, would have on the value chain and the roles of various parties therein. It is clear that with lighting and ITinfrastructure merging responsibilities and dependencies in the chain necessarily change. Installers may move more to IT-responsibilities or IT-installers may pick up the installation of the lighting network. Also, the business models for IP-points may change drastically. Now significant yearly charges for a single IP-point are the commercial standard. However, with hundreds or thousands of additional lighting points these kind of cost levels will no longer hold - and they will not be necessary. The number of nodes will be an order of magnitude higher, yet the data rate requirement will be low. This will result in a cost structure that is intrinsically different from current IP points for standard computing infrastructure. With open standards, interfaces and networks also the position of the classical lighting manufacturers will change, open standards will increase competition and allow entrants with standard software or package to enter the market. On the other hand, opportunities to add value by advanced control features and light effect will increase and lead to additional revenues [1].

While this part has been recognized and analyzed, the implementation of these changes in the market is beyond the project scope.

The Approach and Solutions to the Challenges

In this section we will discuss how the project tackled the challenges described in the previous two sections and simultaneously indicate which of these are “persistent” and will have to be solved/incorporated in any commercial implementation/ deployment of the architecture and which are temporary and related to the early adopter characteristics and first of a kind effect. Finally, a number of challenges have not been fully addressed due to their commercial nature. These can only be solved in a true business context and are beyond the scope of the project.

Group behavior, local communication and synchronization

To deal with the specific requirements of a lighting controls system, a group communication mechanism was developed that operates independently of the main IoT-framework (LWM2M in the case of the pilot implementation). This mechanism, based on CoAP Multicast over IPv6, supports a multicast model, offering authentication and authorization for group communication. For technical details refer to [2], a graphical illustration for the solution is shown in figure 2.

Figure 2: Independence of central server. Low latency group control

This mechanism is one of the cornerstones, as it does not rely on a central server or Internet connection to be present. As such it allows independent “always on” communication for the vital lighting functions. Its lightweight multicast operation supports the performance and synchronicity requirements of lighting, especially in a constrained wireless environment.

Early adopter effects

The project had the challenge that both the architecture and the applied technologies and concepts were new and, hence, not yet mature. During the project, we, over time converged on a practical best way to manage this situation.

The keywords in this are:

Plan for change and updates until the end of project and work incrementally. The latter is a standard project management wisdom firmly embedded in agile methods. The second one, however, is more counter-intuitive from a normal product development perspective.

In some detail:
• Assume in the planning a very frequent update of all
  (experimental/prototype) components, as they will mature over time.
  This even applies to components very recently commercially released
• Guarantee that OtA (Over the Air) SW upgrade works flawlessly. This is
  the most important function on any feature list for a connected IoT-system!
  In the pilot many SW updates were applied after installation of the
  luminaires and this was absolutely necessary to cope with updates of the
  IoT frameworks, Mbed and Thread
• Start with the implementation of a (very) reduced system and work
  incrementally thereafter. Start with one room approach and then scale up
  to the size of the real pilot installation
• Carefully consider the complexity and flexibility allocated to components in
  the system. Don’t be afraid to fix variation points and reduce
  implementation efforts for the first release

Standardization and interoperability

The consortium has standardized the Object Model as an extension to LWM2M at IPSO/OMA. This Object Model, including all API’s needed for an advanced lighting control system [3] was developed within the project to optimally serve the scenarios and use cases of the 2020’s [4, 5] and provide full interoperability between the devices of various suppliers in the project. Within the pilot, devices of various suppliers were mixed and matched and full interoperability of (group) control over various vendors and wired/ wireless was demonstrated.

Agreements across the industry to develop luminaires and controllers according to the same standard are among the major challenges for the near future.

IT-integration

Standard network components and topologies were used to build up the network for the system. The backbone network consists of a number of interconnected rings using the Cisco® Catalyst® Digital Building Series Switch in a decentralized configuration for the ring which could also be used for powering the POE devices. A single connection between the network and the existing office network was established. The back-end applications like the BMS, Commissioning Tool, etc. were hosted on a (standard) server.

User apps were connected and directed to the already existing wireless-network of the office and connected to the access server. Only Thread, a relatively new standard, still needed some specific implementations. The partners in the consortium developed Thread border routers. It is important to note that nothing in these border routers was actually OpenAIS specific and it is expected that commercial, off the shelf routers, when available, can be deployed in the system without any modifications. During the pilot, the quantity of Thread border routers was over-dimensioned to avoid any risks with the wireless performance of the still new Thread implementation. In practice, a single hop configuration was created to each end node. Results from the pilot give confidence that with ongoing deployment of Thread and the availability of commercial components the Thread network will also become part of the standard building infrastructure.

Duration of deployment

The software update mechanism has already been described as the most important function in any connected lighting control system that is based on IoT-technologies. It is very similar to the PC and mobile device market, already familiar with a high frequency of updates and never-ending maintenance, especially for security aspects. This mechanism has been extensively used in the project to cope with incremental development and continuous framework improvement by the suppliers. The fact remains that existing CPU’s will probably no longer be capable of executing the standard software stacks a decade from now. This topic has not been addressed in the project and remains to be solved. In various industries, solutions have been developed to cope with similar issues. Full replacement (mobile phone), addition of external memories and other components (PC) and full replacement of the digital part of the system (e.g. large medical equipment) are amongst the strategies applied. A future commercial implementation will have to give further thought to this issue and define a suitable strategy.

Conclusions

Despite the many challenges encountered in the realization phase, OpenAIS succeeded in implementing a fully operational multi-vendor lighting control system based on IoT-standards and frameworks, with IP connection to the end node, in a commercial setting. This system combined wired and wireless devices from multiple vendors in a single system connected through a standard IT-network with commercial components. The openness of the system was validated by the implementation of several additional components, commissioning tooling and user applications, by parties outside the main lighting manufacturers from the consortium. Figure 3 shows one room in the White Lady office building with the pilot installation.

Figure 3: Room in the White Lady pilot site

The major lighting specific challenges, secure: fast and reliable group communication and serverless (no-internet) operation have been solved in the architecture. The consortium also standardized and proved the interoperability between lighting controls components from various vendors, as such, opening the route to a complete ecosystem of lighting controls.

Due to the timeframe of this project, the early adopter problem caused huge challenges during the implementation of the large-scale prototype. While, at this moment, there is still some IoT-ecosystem super fluidity, there is clear evidence that the mainstream developments are solving this problem. Over the lifetime of the project the number of ecosystems and their stability has been growing exponentially. This is not an uncommon phenomenon in digital transformations and it is to be expected that soon the market will settle, and a number of de-facto standard frameworks will emerge, allowing the system of the future to be built on. Furthermore, extending the Internet Protocol to very restricted end nodes has been sufficiently proven to assume current commercial issues will be resolved by the processor roadmaps of the mainstream silicon vendors. Yet still some challenges remain to be solved at the actual introduction of OpenAIS based systems in a commercial release. Value chain adaptations are required and still form a risk for a successful introduction of IoT-based lighting systems, while lifecycle management still needs attention as well. Software upgrade mechanisms have been sufficiently proven, however, a clear and simple (controls) hardware upgrade strategy is still to be defined.

References:
[1] The impact of the Internet of Lighting on the Office Lighting Value
     Network, T.C.F. van de Werff, H.A. van Essen and J.H. Eggen,
     Journal of Industrial Information Integration, January 2018
[2] OpenAIS Integrating Lighting in the Internet of Things, Frank van Tuijl and
     Ben Pronk, Led Professional Review #67, May 2018
[3] OpenAIS Deliverable: 2.7 - Final reference architecture of
    OpenAIS system: http://www.openais.eu/user/file/openais_final_reference_ architecture_(d2.7)_v2.0-pub.pdf
[4] Selected Scenarios and Use Cases, John Sayer, LPS 2016:
     http://www.openais.eu/user/file/openais-lps2016-selected_scenarios_and_ use_cases-sayer(jci).pdf
[5] OpenAIS Deliverable 1.1, Selected Scenarios and use cases:
     http://www.openais.eu/user/file/openais-lps2016-selected_scenarios_and_ use_cases-sayer(jci).pdf

THE OpenAIS CONSORTIUM & THE OpenAIS PROJECT
The OpenAIS project started in 2015 as a response to the emergence of IoT as a leading force in the digitalization of buildings and homes. OpenAIS is a European Community supported project that is partially funded through the Horizon2020 program. The project team started from the assumption that further developments in IoT-infrastructure would drive a revolution in connected lighting solutions, moving these to open (IoT) standards and off the shelf Internet technology. Additionally, the project definition included the vision that the ubiquitous lighting infrastructure would be an ideal platform to integrate multiple IoT-devices and deliver additional functionality beyond lighting. Such a development would revolutionize the lighting business, moving it away from vertical silos and proprietary (and closed) solutions towards the use of (open) IoT- ecosystems and standards. As has happened in many “digitized” domains, this transition would, in the view of the project consortium members, also greatly shake up the entire value chain and stimulate demands for openness and interoperability by professional customers keen to avoid lock-in.
The OpenAIS project runs from 2015 to mid-2018 and is coordinated by Signify (formerly known as Philips Lighting). The OpenAIS consortium includes partners from all segments of the lighting industry and its adjacencies: facility management, installation, lighting manufacturing, technology suppliers and two academic partners. As a carrier case for the project Professional Indoor Office lighting in Europe has been chosen.
The OpenAIS partners are Signify (formerly known as Philips Lighting B.V.), Zumtobel Lighting GmbH, Tridonic GmbH & Co KG, Johnson Controls Systems and Service Italy SRL, Dynniq Belgium N.V., NXP, ARM Ltd, Eindhoven University of Technology and TNO-ESI.