It’s all about the connections

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. The utility had given us no warning. 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 without some sort of machine-readable contract are not reliable.

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. The effort made it easier for one HVAC system ti integrate with another, but was rarely used to enable enterprise interaction 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. These connections work because they are requesting a single service, not trying to replace local control. Standard purpose-built connections help us connect systems, but only if they work 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.

The Great IoT Roll-Out

Today, is the largest roll-out of an open platform for the Internet of Things ever. So you have to be thinking, “How does this change my plans”

Today, millions of users are installing a securable open source IoT Platform. Users of Windows 7, Windows 8, and Windows 8.1 are eligible for free upgrade to Windows 10. Windows 10 includes an AllJoyn server as a core service.

The developers of digital controls in buildings have long been pioneers in the Internet of Things (IoT). For a long time, a strong concern was how to keep these systems off the Internet, especially as the level of security in these technologies was so poor. For the home hobbyist, the IoT began in with the release of the X10 protocol in 1975. X10-based systems were only embraced by hobbyists, because unless it was your hobby, you would never tolerate the drudgery and significant weekend time to configure and operate your systems.

Despite all the buzz, the IoT has been a confusing mass of non-standard protocols and custom applications. In 2011, Qualcomm presented AllJoyn as a common framework for interacting with the IoT. The code was later open-sourced and presented to the Linux Foundation. In 2013, the AllSeen Alliance was formed to encourage adoption of the AllJoyn platform.

The AllSeen Alliance is more than startups and communications companies, although there are plenty of those. Old line computer companies such as Microsoft and Lenovo are members. Building centric companies that shun open source, such as Honeywell are members. NREL has signed on. By now, each of your customers has probably installed some AllJoyn in a building.

AllJoyn complements the Message Queueing Telemetry Transport (MQTT), and open source bridges between the two are available. While AllJoyn is designed to handle discovery and message transfer over a proximal [local] network or local network. AllJoyn interfaces can support need from control applications to media streaming. MQTT is a publish/subscribe framework in which a MQTT broker acts as a public IP addressable node. Publishers and subscribers connect through the broker. MQTT was designed for remote monitoring and control for most part. Most deployments of MQTT deployments use WAN network atop cellular technologies.

Last week, the OBIX Technical Committee voted out OBIX 1.1 to what I hope is the final public review. The focus of the entire effort was improved interoperability of different code-bases through more abstract formal information models. Standardized encodings enable easy and accurate exchange of messages from XML to JSON, the protocol of choice for today’s web developers, and COaP, a newer protocol appropriate for very large sensornets.

All this get especially interesting when you consider Bindings rather than Encodings. One of the new Bindings defined in OBIX is WebSocket. The Smart TV Alliance has embraced OBIX encoded in JSON and bound to WebSocket as a means to communicate between consumer electronics. To a growing degree, MQTT is being used as a lighter weight, higher performance variant of WebSocket, with binding gateways also available in Open Source.

We now have some standards that stir the pot in a way the pot has not been stirred for a while. With wireless network companies supporting the AllSeen Alliance, we may soon see the open source AllJoyn as an option on your home router. A home router is a natural gateway between a proximal network and a Pub/Sub network. Less open solutions such as ZigBee will need to re-position themselves.

Larger systems using formal controls schemas, and probably OBIX, will soon look to AllJoyn as a way to extend their situation awareness. Natural bridges between the Consumer Electronics Association with the Smart TV Alliance platform and AllJoyn-based applications come from compatible bindings, compatible encodings, and open standards.

What will really turbo-charge this is the cross-platform development environment that comes with Windows 10. It can come as no surprise that Microsoft is releasing DotNet development tools for AllJoyn applications. ROTOR has long supported DotNet on multiple platforms, but support for the advanced development libraries that make DotNet so valuable on Microsoft platforms has been spotty.

This changes with AllJoyn component on Windows 10. Each version of the pre-production DotNet AllJoyn library has been released on the same day for Windows, Android, and IOS. At the end of June, 2015, the high-touch Microsoft development environment is now available to for all three platforms in all DotNet Languages.

Building system programming has always been isolated, and not really up to consumer and corporate expectations. The bar is now raised. Time to polish up your your IoT plans.

Smart Energy with a little bit of Seoul.

My visit to Seoul this month was fascinating. The country of Korea built its infrastructure essentially from scratch in the last 50 years, and in doing so was able to use modern technology to challenge some fundamental assumptions that we make in the USA. IP-based telephony predominates based on pervasive free Wi-Fi. Custom tailors use radical outsourcing mediated by IT to provide near-instant services. The National Virtual Power Plant (NVPP) is as up-to-date as any, while using big-data tools in ways not often seen here. There is a desire to embrace the new without fear that seems young and fresh in the way the US often does not. But somehow, the single observation that stays with me is how the use of IT to challenges our assumptions about natural monopolies.

The Seoul Metropolitan Subway system is by far the best I have been on. The signage is unusually good. Many stations have large interactive maps. Every car has digital signs that display the next station in multiple languages. Music plays on the platforms to warn of each impending arrival. In the winter, automatic seat warmers make even the ride itself pleasanter than expected.

The fare system is seamless. The system pioneered in Seoul is now used in many US systems: a card, a wave in, and a wave out, and a charge based on beginning and ending stations. The systems to add money to your fare card will tell you the remaining balance instantly, without inserting the card, or needing to punch buttons. Unlike in the US, every station has prominent stations on which to drop your card and get cash back. The $0.50 deposit on the card itself is just as easy to get back. There is even competition for these cards as three subway cards, one credit card, and several debit cards can be used interchangeably with your transit card. In short, it is customer focused, consumer friendly, and feels like anything but the bureaucratic experience it is in the US.

The high-tech experience extends into the amenities as well. Subways in the US are often dead zones. In Seoul, each line provides choices of digital connectivity: 4G, WiFi, DMB, and WiBro. This supports the widespread use of IP-telephony in Seoul; without the legacy commitment to lines, almost every smart phone uses the almost universal WiFi. (More on that later.)

All of this is supported by an easy to use App, one that puts the well-regarded BART App to shame. The free App, available for all the usual platforms, works out routes and provides station by station information with precise departure and arrival times. The cost for each route and stop is computed and displayed in advance. A potential rider always knows whether to rush, and when he will arrive.

In the US, this would all be delivered through a semi-private agency, a Transit Authority. In the Seoul, the nineteen subway lines are built and operated by ten separate companies. Some routes may have a higher cost per kilometer, or per station, but that information is readily available before your ride. Fares are automatically allocated to the different companies based on the same services that compute the entire fare. With appropriate use of IT, the multi-vendor service is provided as if through a single provider.

Regular readers may recognize that this is the model of Transactive Energy.

The Seoul Metropolitan Subway system tears down assumptions about how natural are our regulated natural monopolies. To someone who considers the smart grid, it stirs re-thinking of how we consider last mile distribution in a distributed energy world. Just as South Korean phones use the connectionless protocols of the internet to avoid considerable high-cost build out of telecommunications infrastructure, transactive energy and distributed energy can provide better service at lower costs.

To gain these advantages, we must embrace the distributed multi-supplier business models that enable them. Trust capitalism. Embrace minimal market design to limit friction when changing suppliers several times a day if desired. Use IT to smooth any bumps in transition. I’ve written about this in papers on microgrids and autonomous power nodes. It was nice to see it in the field.

Commercial Use of Live Energy Models

This is one of a series of posts on how the semantic expression in WS-Calender is beginning to affect buildings and smart energy. WS-Calendar recently completed its third public review and will soon be published as Committee Specification 1.0.

In a previous blog, I discussed new directions in commissioning; including commissioning that incorporates BIM, schedules, and continuous energy models.

Performance Contracting and the new Commissioning

Many building owners are suspicious of energy performance contractors because the performance contractor is both a player and a score keeper. Because a significant effort is required to understand the information in building systems, there are significant start-up costs. These costs, both in money and time, require that each contract include a significant minimum contract lengths over which to amortize the up-front costs. These up-front costs make it uneconomical for energy contracting to use a third party auditor to verify results.If the owner selects a new a new performance contractor, the up-front costs will be incurred again.

Standard semantic tags and ready access to a light-weight BIM can change this.

Imagine a market wherein a cloud-based energy performance contractor could offer same-day initial reports. That same market also supports a number of 3^rd party auditors, cloud-based, each able to independently assess the results of the performance contractor. Each of these parties can hook up to the BSI, read the BIM, read the tags, and begin analyzing right away. A potential energy performance contractor could offer the building owner a selection of third party auditors to report the success of the contract.

This competition between cloud-based services would drive rapid innovation. On one side driving costs down, on the other driving richer models. These models are likely to build upon two significant efforts currently underway. ASHRAE SPC201 would inform the models, and through the linkage of systems and space, become more nuanced. Schedule-based business assertions, as we are beginning to see in the links of WS-Calendar and the IFCs would make these models more business aware.

Continuous commissioning based on such a foundation would support an ecosystem of cloud-based service suppliers, each able to grow to scale.

Retail use of Live Energy Models

As we move in this direction, we move from information models that are tuned to reflect changed operating hours to models that can tied increased energy use to short term activities, including, say those associated with a sale in one portion of a store. That portion of a store with an ongoing sale may have increased HVAC driven by increased traffic or brighter lights to attract shoppers and display the merchandise, and other enhanced amenities. A side effect of the brighter lights may be increased heat load, thus causing still more HVAC requirements than at first expected.

The most respected retailers with superior operations are already using these sorts of models to fine-tune their special Sales.

Non-Energy adaptive re-use of new Energy Components

Because the approaches described above rely on the composition of multiple standards, they create components that building integrators can re-assemble to meet other purposes.

Emergency responders have long wished for a variety of interactive means to acquire situational awareness of the facilities they are entering. The standard light-weight building model described above is a natural basis for situation awareness sharing. During an emergency response, the goal may be closer to raw sensor readings than to energy use. Those sensor readings, like the performance information, cannot be interpreted without a framework that indicates the spaces and the business purposes where those sensors are located.

Common abstractions, business purposes, and frameworks are the foundations for policy-based interactions with any system. The business-purpose-based analysis of space and system and schedule, is a likely target for adaptive reuse for emergency-response based policy. In the simplest (and direst) case, the facility is on fire, every asset is at risk, and so every bit of information about a building might be shared. In a simpler case, if the Spill Response Team is responding to a minor spill in the warehouse, it is inappropriate to share with them acess to, say, a webcam in the executive suite.