It’s all about connections We worked with the Digital Twin Consortium to build their model of system interoperation, work that was mostly defining capabilities for connections.

Toby Considine TC9, Inc The New Daedalus https://www.linkedin.com/in/tobyconsidine/ http://automatedbuildings.com/editors/tconsidine.htm

Angered and motivated by my experience preparing a large state university for Y2K, I made my public entrance to the public building systems space in 2002. Y2K was a crisis when it was anticipated that any program that used a two-digit year in the date (as in 99, and it was all of them) would fail after the year 2000 (when the year might be 01). State universities build using low bidders in accord with state construction law, and the University of North Carolina had accumulated a hodge-podge of systems for building operations, steam distribution, chill water distribution, cogeneration, and electricity purchases that barely interoperated. Worse still, the interoperations were fragile, and upgrading any one system would break the connections with any number of other systems. I simply wanted stable inter-system connections that did not break with any minor change to either system.

We were using system interoperation to address problems of smart energy. Back then, an operator would log into a utility web portal in each afternoon and download a CSV file with 24 power prices for the next day. We would then adjust the interactions of all these incompatible systems to align with the day’s prices. When the process broke without warning, we found that the file now included 96 15-minute prices. When asked, the utility replied that we should not worry, that they had no plans for 15-minute prices; but had merely upgraded their software. Connections to a utility or other external system were unpredictable at best.

In the early 2000s, system interoperation meant XML and messages. Most accounting and line of business applications were exchanging XML. I worked with many industry leaders to define OBIX—which then became the heart interactions of the Niagara system and others. Ken Sinclair and Automated Buildings were a big part of that effort. The whole building industry knew we needed an easier and more stable way to make connections between systems.

A decade later, the smart grid recognized that smart energy must be a conversation between buildings and power grids. Standards for M2M schedule negotiation, for energy market information, and for service-oriented energy came out of that, with a central place held by OASIS Energy Interoperation. OpenADR 2.0 and TEMIX are the two largest and most successful message exchanges based on that work. Standard purpose-built connections help us connect systems, but they work only for that single purpose.

Connecting power grids to building systems became easier, but I was consumed with connections with a smaller scope. Green Registrar’s Offices rely on interactions between class scheduling and building operations. Buildings adjacent to a BMS with a weather station all want to use that weather data to improve their own operations. BAS systems can tell physical security and emergency management systems if a building is occupied. Door locks and foot traffic systems can tell a BAS when to turn on. For three years, I worked on BIFER, Building Information For Emergency Responders, with target users from fire control to hazmat response. Each connection between systems increases the value of each system.

We have just begun to discover the lightweight interactions that should be easy to create and use. COEL-based applications would like to interact with conference room environmental controls to evaluate how alert attendees are before critical votes. Smart streets want to know when a mass of people is leaving a building. Easy-to-create connections are the path to create tenant value and to build smart cities.

Three years ago, Anto Budiardjo asked me to work with him to define mechanisms for defining and publishing limited connection points between systems. Anto was the first person that I was told to meet when I began work on OBIX. Anto’s new company is Padi, the Indonesian word for rice. Anto’s vision was to easily connect all the grains of rice in a bowl. Too many sophisticated interactions today are lost when one system or another is upgraded, and the original integrator is no longer on site. The mechanisms we defined had to not only be easy to use, but be repeatable, cybersecure, and self-documenting. We met with anyone who would listen.

Anto and I worked with the Digital Twin Consortium to build their model of systems of systems, work that was mostly defining capabilities for connections. Digital twins use intersystem connections to enable AI (artificial intelligence) and ML (machine learning) to constantly monitor cyberphysical systems. These tools can detect changes in configuration or performance by comparing actual performance of a system with a simulation, or with an emulation from yesterday, in real time. Connections between systems are the foundation of digital twins.

Related work, with a longer-range focus, is defining the future of the Internet, sometimes called Web 3.0, The Spatial Web, Architecture and Governance Working Group looks to combining the Internet of Things and the Internet of Systems at the edge, without required reliance on central monitoring and control. IEEE P2874 has many parts, from decentralized identity and security, to edge-based decision-making, to support for virtual and augmented reality (VR and AR). The Spatial Web will encompass ever-growing diversity of systems through use of common connection definitions.

The result of this work is the Connection Naming System / Connection Profiles (CNS/CP), a simple specification to create a control plane for the Internet of Things. (You can see the current draft at https://github.com/CNSCP/specification/blob/main/cns-cp.md.)  We have shared this work with the T2T (thing to thing) committee of the Internet Research Task force. We plan to submit CNS/CP to be a standard internet specification (RFC). CNS/CP will connect buildings to enterprises, systems to their twins, and maintenance personnel to augmented reality. Connections will continue to grow more pervasive and are central to future systems of systems.

We invite you to review the specification and provide feedback, comments, and suggestions. Let us know what you think.