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.

Just-In-Time Infrastructure and Watergy

The future of infrastructure is just-in time. Just-in-time delivery of structures, ready to support people and business, customizable to the site, long lasting, ready for smart energy and water. Just in time delivery of distributed energy, ready to support structures, the people who live and work in them, and the services they need, and ready for smart grids. Just in time delivery of pure water, ready to support people and agriculture, able to work alongside smart power and smart grids.

Consider a simple building with only a refrigerator, air conditioning, a solar panel (PV) and a power storage system (battery). Each is represented by an autonomous market agent.

The refrigerator and the air conditioner are similar: each runs episodically to support some private purpose, prefers to run an entire cycle or not at all, can shift any cycle forward or back in time while still providing its service. To coexist within the power supplied by the PV, they must not run at the same time lest they exceed the power available. Each determines when it cycles by submitting time-based tenders, finding the minimum price, i.e., buying power when the other is not.

The PV is represented by an agent acting as a seller, able to make commitments based on its internal predictions of weather. When it is unable to meet commitments, say when a cloud passes over, it must go to the more expensive aftermarket, and buy power from the battery.

The battery is represented by a merchant actor, buying power low and selling high. In another model, it could operate as the “market specialist”, brokering market transactions and improving market liquidity through trading on its own account.

As we add more systems to the building, each represented in the internal power market by an agent, we do not need to add complexity to the control systems; we merely add participants to the market. The knowledge problem of specific system operations and controls is simplified through abstraction to the common transactions. If the building is able to connect to a grid of some kind, it does not expose its inner workings; the building exposes only the aggregate market position of the interior market.

In this model buildings may trade with each other using the same market services and interactions unused to manage the internal supply and demand. A community energy resource such as an independent wind generator or larger power storage system acts as a peer node within the neighborhood. A non-building entity such as a wastewater pumping station may participate in the local building-to-building (B2B) market.

In a similar way, the local B2B market can participate in a larger neighborhood market. Where transactions between particular market participants are limited by transmission capabilities, a parallel transport or congestion market can be introduced.

Inside any building, any system can potentially operate an internal market. For example, a multi-story building may choose to have its multiple air conditioning (HVAC) zones operating as their own market, with only the aggregate HVAC market participating in the building market. The underpinning for in-building markets in power are described in detail in the recently published ANSI/ASHRAE/NEMA Standard 201-2016, the Facility Smart Grid Information Model.

This pattern of integration is sometimes referred to as fractal microgrids. With transactive integration, the market negotiations and transactions are identical at each level, and the underlying complexity of each market participant is hidden. Inside a building with a single owner, the complexity of block-chain as a transaction monitor may be unnecessary. At the largest scale, in the bulk power markets, transactions may require traditional financial instruments. In-between, where the transactions many and small, where resources are flowing between systems with different owners, and where local settlement may be desired to achieve resilience goals, blockchain is of most use. Within any microgrid, systems may use blockchain to create and manage identity, to record contracts, and to settle transactions.

Blockchain is in essence a means to create a distributed database, with information shared between participants, so no one participant can change the information. Blockchain is in growing use from early power trading in the Brooklyn Microgrids project, to world-wide logistics management. Some codebases such as Open Ledger, look to bankable blockchain, wherein the net of transactions can easily flow into the world banking system. Others, such as IOTA, aim at lightweight models that are cost-effective for transactions a tenth of a cent and smaller, and that can run on very small chipsets.

New initiatives are extending the principles of transactive energy to water distribution. These models make sense today where there are tight restrictions on aquifer pumping shared between farms. Since water must be pumped, and pumped water can generate electricity, markets in transactive power and transactive water can work together. This scenario is particularly interesting in communities that are off the water grid and may be using energy intensive technologies such as Atmospheric Water Generation (AWG) to provide water for homes and hydroponics.

Transactive power and transactive water work together to create what soem of us are starting to call watergy.

Resource Frameworks for the Internet of Things

The first wave of the Internet of Things (IoT) was widespread but disorganized. SCADA operated nearly every industrial process, and was proprietary and the network rarely left the building. Power grid sensors and telemetry, if available, only extended to the substation. Home Security systems bundled sensors and a hardware-based app to provide fixed functionality. Building systems moved slowly off of pneumatics and onto digital controls. Hobbyists built apps on X10, but they enjoyed the making as much as the function. Over all of them, security was non-existent.

The second wave was the Internet of Sensors—thousands and thousands of sensors. These sensors were typically carefully placed. The meaning of the sensors came from the deliberate placement and recording of metadata.  Some of this was encoded in SensorML, but few sensors could describe themselves.  There were limited if intriguing demonstrations of sensors that could describe their locations, typically in the interoperability demonstrations of the Open Geospatial Consortium (OGC). Wearable sensors were identified types that gained meaning through the person that wore them.

During the second wave, the low level descriptions were standardized in some domains. BACnet and LON and KNX identified standardized communications in buildings.  OPC, which began as OLE for Process control, matured into more robust protocols. OBIX normalized the base of communications to read, change, and interact with control systems. Higher level vertical smokestack ontologies such as MIMOSA saw limited acceptance.

The second wave began to transition to the next wave with efforts to homogenize systems and guide them through central control. One-size-fits-all cloud applications were the standard. The energy Standard Energy Profiles (SEP) treated all home systems as commodities, with identical energy use and minimal involvement of those who owned the systems. This created its own risks, as the fan and ducts for fume hoods, office cooling, and biohazard labs are all identical form distance. In homes, these were unpopular because most people do not want to cede control over their personal spaces and possessions to third parties.

The third wave will be built on Apps of Things, and ontologies based on composite semantics of sensors. The pervasive availability of the AllJoyn platform, as multi-platform open source, and now as a core component of Windows 10 will enable the wide development of Apps for Things. The Smart Television Alliance will soon bring its own App platform into consumer electronics and smart phones. The larger applications already in existence, for large building operations and the like, will gain some App characteristics.

Apps, as we know them on our smart phones, can be thought of as re-collecting and re-purposing feature sets for novel purposes. You may have a dozen apps on your phone that make use of the GIS functions and the SMS functions available. A sensor on a system component of your Smart Kitchen App may be used by an Aging at Home App to alert near-by relatives. Smart laundry systems already sends text when you can move clothes to the dryer. Smart EV chargers with their own storage may plan their strategies by consulting other Apps in the home.

More and more I think of Apps as the Device Drivers for the Internet of Things. My first commercial microcomputer app was a bubble sort that incorporated explicit memory mapping, explicit disk IO, and even disk head activity into a single hot mess of assembly code. It was a great relief to let the disc activity go as we got enough memory to support drivers, and later to stop moving blocks of memory around within business code. The first SCSI drives moved the disk IO out of the CPU and onto the device. RAID controllers are Apps that manage both IO optimization and fault recovery. Today the IO is off on network attached storage, with the technology optimization incorporated into the storage service. There are some conversations about using transactive frameworks to manage multi-application and multi-system allocation of storage services.

A growing challenge of overall efficiency is managing the interactions between these quite different Apps. A highly efficient dishwasher may reduce an instant hot water heater to the inefficiency of a peaker plant. Resource smoothing is of growing importance, not just for electric power, and not just to incorporate distributed energy. Resource frameworks, at the App level, can be a big part of that. This is why the Energy Mashup Lab joined the AllSeen Alliance—the cross-industry group pressing for wide adoption of the AllJoyn platform.

I will write more about the resource frameworks, from smart energy (EMIX) to the BIM for O&M (COBie), from UNITY to the Classification of Everyday Living (COEL). Come and see me at TechIntersection in Monterrey, California in mid-September (http://ow.ly/QSKGp), use my code CONSIDINE for a $50 Discount.

Slim BIM: The Middle Ground between Document and Service Part 1

Engineering information is document oriented. Large documents, even sheaths of documents, are exchanged, specifying in great detail exactly what to do, and how to do it. Modern IT (Information Technology) is based on Services. Service exchanges are minimal, as small as can specify results, and do not specify the means of execution at all. For the last 50 years, IT has moved far faster than have engineered system, the things we can touch, inhabit, or ride around in. For the next 50 years, when engineered systems will need to evolve as fast as IT has for the last 50, we will need a middle ground, between document and service call. This is the challenge of configuration, shared configuration that will enable big systems to interact as nimbly as does IT does today.

Buildings are big systems, composed of big systems, that must interact with the IT-based systems of their occupants. The systems of the occupants will change many times during the life of a building. If we are to meet national and international energy goals, the collection of systems in each building will change frequently as well. These systems will interact with services, simple calls conveying only requests and results. Before they can communicate with each other as services, each must learn about the other. Each system must be configured with the information it needs to request services. This information must be non-specific, to avoid the complexity of details. This information must be specific, cataloguing service entry points and potential performance.

For buildings, designed by architects and engineers, the design and specification uses BIM (Building Information Model). These are traditionally very large and cumbersome files. The National BIM Specification (NBIMS) describes documents based on the International Foundation Classes (IFCs). The IFCs are two cumbersome for exchange, so NBIMS specifies Information Delivery Models (IDMs) for each structured hand-off of information, and a model view for each IDM. These information exchanges are detailed and overly specific. They rely on document-centric notions of XML from long ago, seen as a “replacement” for large the documents in SGML. The IDM for each stage of a project is different, even if the information is essentially the same.

The problem is, no one outside of architecture and construction uses these approaches, and few seem willing to adopt them.

Recently, members of the National Institute of Building Science (NIBS) have worked on the hand-off of information at the end of a construction project to the maintenance management system (CMMS). They have developed the Construction Operations Building Information Exchange (COBIE). COBIE lists the spaces and their fittings, the systems and the spaces they support, and the equipment in each system with its maintenance requirements and spare parts. The market leaders in CMMS each support COBIE import. Maintenance staffs have reported replacing weeks of error-prone hand entry with 15 minutes of COBIE import, and had their Preventive Maintenance (PM) and spare parts management ready to go.

Other systems could benefit by importing COBIE as well. Building owners often run many Line-Of-Business (LOB) systems, often selected by different parts of the company, from different vendors. Asset Management, Capital Renewal, and the Registrar’s Classroom Scheduling, each has its view of the core facility information in COBIE. An owner may outsource maintenance to several different businesses that need to share information. The enterprise scheduling software, used to schedule staff and meetings, has its own view of the same data. If each system is initially configured through the import of the same COBIE data set, if each system uses the same identities for spaces and systems, then these systems will be ready to exchange Service calls sharing expectations and requests.