Dr. Walter Werner is head of the Werner Management Services, a consultancy company in the field of lighting and the Internet of Things. He worked as Head of System Architecture at the Austrian lighting enterprise Zumtobel Group from 2011 until 2014. From 2009 to 2011 he worked as an Innovation Consulter and parallel to that taught at the Institution for Higher Education in Rankweil, Austria. From 2006 to 2008 he was the Managing Director of a Swiss software startup company called mivune, situated in Zurich. He was employed at Moeller of Germany as Technical Manager Switchgear from 2004 – 2006 and prior to that, formed the smart lighting agenda of Zumtobel in the years 1985 to 2004. Dr. Werner completed his studies at Innsbruck University in Experimental Physics with a PhD.
How the OpenAIS Group Communication Allows Secure and Low Latency Interoperable IoT Based Lighting Controls Designs
One of the main challenges in IP based lighting controls is the challenge to match the performance of simple wired systems like 1..10V or DALI, and in parallel provide all the benefits that Internet-to-the-node promise.
The main reason is given by the different nature of Internet-based communication and those simple systems:
- Simple systems: only one signal source delivers the signal always to all participants in parallel.
- IP based systems: A port is opened, a connection is used to establish a session with a server, data are exchanged, session is closed, next session is established etc.
With ultra-fast Gigabit wired LAN infrastructure some hundred light points may be addressed serially without conflicting to the low latency requirements typical for lighting, but whenever restricted bandwidth or non-zero media access timing is applied, as seen in almost every RF communication, the time delay between the first and the last light point addressed the OpenAIS team added a secure group communication to the standard internet interaction to cope with these requirements. (See www.openais.eu/en/results for detailed information) We replace the session – oriented communication (TCP) with a datagram – oriented communication (UDP) and use CoAP instead of HTTP. (CoAP uses numbers instead of the words used in the http:// “address line” to save some bandwidth and to reduce the parsing effort.) To ensure high security standards the content of the messages is encrypted. The only open information of messages is the “Key-ID” that points to the (pre-negotiated) key that is used to decrypt the message. To overcome the one-after-one communication we are using the IPv6 Multicast addresses to talk to a set of nodes in parallel. (In the RF domain all devices are able to pick up all other communication in their physical reach, but this is usually not used for Internet transported data: Using multicast addresses this gets enabled.)
Additional measures need to be taken: A receiving device that is addressed by a multicast message may have more than one light point embedded, and so the message needs to be routed to the correct recipients, that are members of this “group”. To achieve this we do use group-ID’s (“Application Group ID”) that tell the device internal routing mechanisms where the message belongs to.) This ends up in being able to “talk to a group” via the Internet just like we were used to “talk to a group” in DALI or KNX networks. Being able to use the Internet Methods in group communication lead to some structural differences in the communication objects: The restrictions that formed the logical base for the DALI (and the KNX) definitions have less or no weight in this field, but other restrictions (e.g. Data-formats and object structures etc.) apply to allow the use of standard tools in the IP environment. Also “interoperability” is a completely different story: The already fully standardized internet communication environment already provides most of what is hard work e.g. with DALI 2, only a “small common language set” for the group communication is needed. Outside group communication the interoperability is very much eased, as a commissioning tool may well talk to each device in a different “language”, as long a s the language plug-ins are provided by the manufacturers: There is NO NEED to unify the languages used for commissioning and parametrization.
Conclusion: The OpenAIS Consortium has in a substantial effort, partly financed by the H2020 program of the EU, defined a group communication stat allows to use standard IP based networking systems for (future) Lighting Controls.