Today's Power Markets are Too Big

The span of power markets today is too big. Market participation by net metering applying tariffs across a whole region makes no sense if power from the seller cannot physically get to the would-be buyer. Power markets are intrinsically local. (This is net of transmission/distribution line capacity and topology, whether or not particular transformers can “run backward”, etc.). Atop this, one must factor in the line loss transforming up from the local small-scale prosumer

For such local markets, there needs to be some equivalence of market participant scale. A large factory does not order wholesale supplies from the corner store in any non-power market. A bidder who works at an order of magnitude larger scale than anyone else deforms the local market. A local market may reach aggregate scale large enough to participate with bigger players.

Once one breaks the market down into the local smaller markets, storage can easily participate, either as part of portfolio management within a prosumer, or independently as a merchant battery within the local market. Local markets open the way to replace central battery control with autonomous power storage systems.

Different storage systems have different participation characteristics; fast or slow charge, fast or slow discharge, switching from charge to discharge, etc. Running a specific storage technology into the wrong participation scenario can degrade the system, or even result in “rapid unplanned energy discharge” (fire and explosions). We need the room to experiment with different strategies for market participation for different storage technologies, or even hybrid storage systems wherein several technologies are working together as a single participant. This experimentation will not happen in a centrally owned, operated, and regulated environment.

Large central markets may try to emulate this by targeting specific prices at specific devices or groups of devices. This attempt at direct control by proxy across neighborhood and region will not work much better than direct control does.

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.

Defining OpenC2 Cybersecurity for OT: Microgrids

OpenC2 is an open cybersecurity command language for the Internet of Things, also known as Operational Technology (OT). Traditional cybersecurity concerns are focused on the traditional networks of file servers, database servers, web servers, and desktop computers. Cybersecurity commands from firewall directives to interdiction of malware in documents have as their goal the protection of those administrative and data services. The communications requirements and systems architectures of OT are quite different than those of administrative systems, and the services provided by OT are far more diverse. The security directives for each type of OT system are just now being defined.

The services provided by OT may be critical to the performance of other systems. A cyber-threat to a power distribution system may create risks to every mission supported by that system. OpenC2 on OT systems may be able to provide critical situation awareness on threats to other missions.

Microgrids are a type of OT whose purpose is to supply local power to a system, facility, campus, or base. New microgrids autonomously match the supply and demand of electrical power in real time. Many microgrids incorporate some level of internal power storage. A microgrid may incorporate proprietary controls for managing unique set of distributed energy resources such as solar or wind. Many microgrids incorporate some level of internal power storage. A good cyber-defense profile for microgrids should be common to all microgrids while allowing for diversity of technology within any particular microgrid.

OpenC2 commands are directed to discrete sets of functions grouped as a cyber-defense service, termed an Actuator Profile. A given system may offer multiple actuators. For example, a network gateway might offer three actuator profiles: a stateless packet filter service, a stateful packet filter service, and a malware-blocking service.

So, too, an OT system may support multiple actuator profiles. An OT system may support the Stateless Packet Filter Profile as well as OT specific services.

Part of developing the OpenC2 profile for Microgrids will be discovering the separable OpenC2 cyber-defense services. An autonomous microgrid that interacts with other microgrids may support an actuator profile for that. A microgrid may support a profile for situational awareness of operational risks to power-dependent systems. An actuator profile for power storage may be broken out of the overall microgrid profile, enabling technology agnostic commands to prepare for widespread threat to power availability (“Charge Up!”) as well to be ready to provide extra power to another microgrid to support a fast-developing operational need. This last service may be one of several profiles on a microgrid, but the sole profile on a battery.

Microgrid deployments, especially of autonomous microgrids, are poised for accelerated deployment across DoD facilities. Deployed Microgrids are foundational to other services on bases. Microgrid functionality is tied to many key vulnerabilities of expeditionary or mobile basing. The required profiles should be a priority so that the cyber-defense of these new assets can be managed within a common operational and training framework with other cyber command and control functions.

While microgrids are first on the list, traditional building automations systems, such as HVAC, access control, and intrusion detection will soon get their own profiles. These profiles are already being discussed, but without significant input from the building automation industry or from commercial owners. As each profile arrives, it will begin to drive the market.

Cyber Command & Control for OT Cybersecurity

In August of 2017, US Cyber Command was raised to the status of a unified combatant command. Organizationally, this put USCYBERCOM at the same level as the regional commands such as the European Command or the Indo-Asian Command, and the functional commands such as Special Forces. The term “unified” says that the commands cross the organizational boundaries such as Army, Navy, Air Force and Space Force.

USCYBERCOM is tasked with centralizing command of cyberspace operations, and strengthening DoD cyberspace capabilities. USCYBERCOM is concerned that the cyber-defense model of traditional monolithic systems that tightly couple the sensing, analytics, decision making and acting blocks of cyber-defense activities leads to brittle cyber-defense infrastructure that is relatively static and difficult to coordinate for inter-domain responses to cyber-attacks.

Accordingly, USCYBERCOM demands more responsive, flexible, product agnostic and interoperable cyber defense components include the standardization of interfaces and the adoption of standard protocols. The goal is to ease interoperability and enable unambiguous machine to machine command and control messages.

To achieve these goals, USCYBERCOM and the NSA are encouraging the development of the cybersecurity open command and control specification, OpenC2. It is their hope that OpenC2 will find wide acceptance making OpenC2 conformance readily available. It is a goal of USCYBERCOM to be able to use OpenC2 for all critical infrastructure.

This initiative will affect every participant in the smart building and operational technology (OT) markets. The twin goals of modern Defense Department specifications are to make technologies executable and readily available. Executable means that those who need custom applications, which includes systems which are designed for a specific building, will be able to use these requirements when going to bid, and be able to test whether those requirements were met. Readily available means that there are standard items on the market that meet the requirements. Integrators and suppliers will both be held to the new specifications—building owners will benefit from the new market.

USCYBERCOM intends OpenC2 as a cybersecurity command language for the Internet of Things, also known as Operational Technology (OT). Traditional cybersecurity commands are focused on the traditional networks of file servers, database servers, web servers, and desktop computers. Cybersecurity commands from firewall directives to interdiction of malware in documents have as their goal the protection of those administrative and data services. The communications requirements and systems architectures of OT are quite different than those of administrative systems, and the services provided by OT are far more diverse. The security directives for each type of OT system are just now being defined.