Interoperability & APIs for the legacy lighting industry
Time: September 13, 2018
Pointer from: Electrical Contractor article
Note type: Direct
Connected Lighting System Interoperability Study (DOE Oct 2017)
Although such connected lighting systems (CLS) might enable dramatic improvements in the energy performance of lighting and other energy-intensive systems or services, at this early stage in their development, that potential is limited by significant fragmentation of the underlying technologies and interfaces. As a result, today’s CLS are generally not natively interoperable, meaning they cannot be assumed to work well together or be capable of exchanging the data that they collect with one another or other systems
Although owners of devices and systems that produce information are generally understood to own that information, the utility of that ownership is limited if the information is locked up in a proprietary data model. Interoperability unlocks the data in a system by allowing it to be communicated to and used by other systems, analyzed by other applications, and managed or archived in other ways, thereby enabling true ownership.
Integrating multiple CLS through APIs does not result in a homogenous system; at best it yields a common user interface and experience.
Differences among network protocols, device representations, and access policies that affect performance must be understood, addressed (if possible), and managed – not only initially, but over the course of hardware, firmware, and software upgrades. Asynchronous data flow can lead to latency issues and bandwidth bottlenecks. Integrated system failures and performance issues can be very difficult to debug and subsequently isolate and mitigate, without taking down the entire system. Implementing mechanisms and policies that maximize reliability and quality of service while still allowing the integrated system to scale and simultaneously continue to deliver end-use functionality requires advanced developer skills. Further, at present, system integrators may have to navigate API implementations that are poorly or insufficiently documented, or have not been well- exercised, rendering them immature or, in some cases, unusable.
Connected lighting systems (CLS) – composed of intelligent light-emitting diode (LED) luminaires with one or more modern network interfaces and one or more sensors – hold the potential to deliver improved energy performance and to become platforms for the collection of data relevant to their surrounding environment. Although the ability to control lighting and implement energy-saving strategies is not new, many of today’s lighting systems and their underlying technologies are rooted in outdated command-and-control architectures that require significant configuration effort, and that centralize information and intelligence. In contrast, IoT systems are being built on the most modern and mature communication technologies, with architectures that allow for information and intelligence to be more distributed and extensible. Because data are also the fuel powering emerging IoT capabilities (e.g., space utilization, location-based services), delivering data can add significant value to lighting systems.
Connected lighting systems are uniquely positioned to be a backbone of the IoT and change the way people interact with their surroundings. Lighting is ubiquitous – it exists everywhere that people gather – and often has a near-ideal viewpoint from which to monitor surrounding conditions, making it perhaps the most attractive infrastructure for developing sensing platforms. Further, the same electronics that regulate the delivery of low-voltage power to LEDs can easily be modified to provide power to embedded sensors, microcontrollers, and network interfaces. In addition to occupancy and daylight sensors that have traditionally been used to implement energy-saving lighting-control strategies, other sensors that might be integrated into lighting devices include, for example, those to measure carbon dioxide, vibration, and sound – resulting in such “smart building" or “smart city" benefits as air quality monitoring, theft detection, and guidance to available spaces (e.g., office, parking). CLS are already being used as a platform for monitoring occupant position and movement in retail environments and other heavy-traffic buildings (e.g., shopping malls, airports, universities, healthcare facilities, and warehouses) by using Bluetooth beacon and/or visible-light communication technologies. This data is then analyzed to provide personalized location-based services to help occupants navigate in the building, and space-utilization and occupant-flow services to help building owners improve operational efficiencies, enhance safety, and increase revenues.
Because the IoT market is still relatively young, highly competitive, and at least perceived as being driven by both cost and time-to-market, market forces are currently working against interoperability. Many manufacturers are pursuing proprietary approaches in hopes of becoming a de facto standard and achieving a significant competitive advantage over other solutions,9 and open specifications and standards have thus far seen a slow adoption rate.
Technology providers are primarily supporting such needs by providing technical assistance for specific integrations, developing and releasing interfaces for legacy protocols (e.g., DALI, BACnet), and developing and releasing one or more APIs, by which a CLS can interact with the Internet and, in doing so, communicate and exchange data with other devices and systems or cloud applications.
3 layers of interoperability
Limited interoperability can manifest itself in many different ways:
- reliability, scalability, and latency issues
- difficulty developing cross-platform applications
- difficulty maintaining a functioning communication network
- slower identification of failure modes and cybersecurity issues
- limited reusability of technical solutions
- higher costs, lower adoption rates, and higher user dissatisfaction
Application layers in interoperability frameworks essentially define how data should be represented, structured, and understood. They are often further broken down into (1) information models, which define schemas for conceptual objects separately from any underlying architecture, interface, or protocol; and (2) data models, which define those objects at a lower level of abstraction and can include implementation-specific details.19 There are many different application layer protocols that could conceivably be used for IoT device communication, and most industry experts do not believe that a single Internet application layer protocol will be well-suited for all conceivable IoT use-cases.
In general, RESTful practices adhere to two defining implementation constraints25:
Addressability: Each resource or representation of it should be identifiable and accessible. Uniform Resource Identifiers should define a global namespace and use consistent nomenclature. Resources can comprise individual items or collections of items, virtual or physical objects, or computation results.
Statelessness: Each communication should always contain all information and metadata needed to perform the request. Messages should be self-descriptive and cacheable. Clients should not need prior context or knowledge of the service to execute the request, and should be able to dynamically discover available resources and possible actions.
It is often incumbent on the system integrator to figure out what a resource represents, and what its data model defines (e.g., measurement units, data type)
APIs enable the implementation of many use-cases. However, use-case performance may be hampered by one or more issues. Asynchronicity is a significant hurdle to the creation of an interoperability platform via APIs. When a number of processes are running in parallel on different machines in several locations, and the network between them is not always perfectly reliable or immune to latency issues and bandwidth limitations, synchronization of commands or readings may be difficult. Further, partial failures of a subsystem or an interface, as well as performance issues, are difficult to control, debug, and handle in a system stitched together using APIs. Implementing mechanisms and policies that maximize reliability and quality of service, while still allowing the integrated system to scale and remain effective and perform when the number of managed resources or the number of users increases, requires advanced developer skills. Finally, providing a user experience that reduces the inherent complexity of multiple systems and interfaces requires the navigation of data residing in multiple heterogeneous locations, potentially presented in different formats and conveying different information, and also requires an ability to mend structural and semantic gaps.
Added efforts in integration
What type of effort is required to exchange information between – or, more fundamentally, to integrate – heterogeneous and asynchronous resources residing in different CLS, via their APIs, into a single interoperable platform?
- Software coding: Such integration requires some degree of software coding. Although the type and amount of coding required can vary by the approach pursued, integration via APIs requires more than configuration and validation. Integration via an existing “platform" might require less development time – in particular, if the platform was designed for, or has been previously used to implement, intended use-cases. However, the use of such “platforms" typically comes with tradeoffs between user-friendliness, functionality, and flexibility. Further, they must be maintained to address hardware, firmware, and software updates, and ideally support new systems as they enter the market.
- Harmonization: In lieu of sufficient documentation, system integrators may have to ascertain, sometimes through crude trial-and-error experimentation, what an available API resource represents and what information and data model it uses. Converters or translators may need to be developed to handle inconsistent data models. Further, an information model that suitably encompasses the myriad data models to be integrated may need to be inferred, in order to effectively aggregate data or broadcast commands, for example.
- Maintenance: Integrating multiple CLS through APIs does not result in a homogenous system; at best, it yields a common user interface and experience. However, effectively hiding the underlying complexity can require a significant amount of backend integration work. Managing what functionally remains a distributed system at one or more layers can be challenging and effortful. Differences between network protocols, device representations, and access policies that affect performance must be understood, addressed (if possible), and managed – not only initially, but over the course of hardware, firmware, and software upgrades.