The Last Big Thing

Developers of the Internet of Things always seems to be moving into the last big thing—at least as far as communications expectations and protocols. Too often security is an afterthought, something that can be bolted on afterward.

I often have to design secure communications for new deployments on a University campus. Many new roll-pits are still using RESTfull JSON. Remote systems often transfer telemetry to the cloud using unencrypted FTP. OpenADR generally uses reverse polling because corporate security won’t let external systems interact with on-premises systems secured with last generation security.

BACnet is moving closer to modern expectations with BACnet/SC. Control nodes and sensors can communicate using TLS-secured messages. Devices within the internal internet can work with certificates issued by the BACnet hub. Legacy systems can hide behind a BACnet hub and act AS IF they were secured.

Even so, older protocols and expectations sink in. BACnet router to BACnet application is still limited to Web Socket. ASHRAE specifies TLS 1.2 when many enterprises have moved to TLS 1.3. It is difficult to match the nimbleness of modern IT systems when putting in place systems that will not be replaced or re-programmed for a couple decades.

(Let me be clear here—my biggest complaint about BACnet SC is that I cannot yet deploy it. It is far more secure, and far better architected than what came before.)

Newer IT expectations are expected to continuously tune themselves based upon actual observed performance within their own environment. Applications that cannot do this on their own will end up sharing their data to cloud AI, with resulting loss of performance and loss of privacy and security. We all should know by now that data that goes to the cloud tends to get free in the cloud, offering the hacker or commercial competitor information for a decade. Once released, privacy never comes back.

Some IoT platform models have moved toward Docker. Docker provides a minimal Linux-like operating system (OS) to deploy code anywhere. I’m afraid that mainline IoT will get to Dockers just as the cloud moves to the next thing. On the edge, with the devices themselves, developer may wish to have multiple operating systems: one for Control, one for User Interface, one for AI. A Docker supporting Python for AI may require a lot of resources. Docker is and will remain to fat resource-demanding to support such applications on the edge.

I recently have seen some movement past Docker to DAPR (the Distributed Application Runtime). One can consider DAPR as a much lighter weight Docker. Different DAPR nodes are optimized for different languages. For example, there is a DAPR node pre-adapted to run the GO language (GOLANG or simply GO). GO is ideally suited to develop tiny replacements for Python AI routines. A GOLANG DAPR node can be much smaller and more efficient than is a Python routine on a Docker. Three DAPR nodes, one for control, one for AI based on GO, and one for UI based on .NET core can fit on a thermostat or other small system.

Upgrading some part of such a system, say upgrading the AI, could be as simple as swapping out the single DAPR node without touching the rest.

Don’t be slow to the last big thing. I recommend that smart building developers and smart energy developers consider what they might do with DAPR today.

The Human Side of Energy Micromarkets

This post is part of the continuing Paths to Transactive Energy series. You can find them all listed by clicking on the matching metatag at the bottom of each post.

The Human Beings must have a say, or any model for transactive energy is doomed to failure. No model based on satisfying The Computers or The Grid will acheive prominence in the market. If optional, people will opt out. If mandatory, people will work around. The market is not a model for decision making, it is a pattern for interactions. In the abstract, semiotics does not determine meaning, only how meaning is conveyed. The interaction patterns do not determine the value of energy used at a particular place and time, they only determine how it is negotiated and conveyed.

Decision making must be local, driven by internal needs. Those decisions take place in the context of a larger market, but the larger market is not determinative of particular actions. People, whether at home or at work, will participate to the extent that it enhances their own satisfaction in some way, and transactive energy is, and must be, thoroughly agnostic about which layer of the Maslovian cake is driving decisions.

The occupants of the house, or of the business facility, determine the values of those systems that they use and how they negotiate. No one outside the house can know whether that spare refrigerator is deep storage or beer refrigerator, and if this weekend’s party makes the beer refrigerator and the ice-maker priority uses. (Note that I am not discussing the human interface that might make it useful or desirable to interact with the priorities of these systems—because these interfaces are outside the scope of transactive energy).

One system keeps things cool, within a range determined by biological safety or by personal preference, with limited flexibility over time of operation. One manages ice production, a pre-consumer that wants to acquire when power is cheap. Those two agents may have the same locus of interaction, let’s call it an IP address. They may be expressions of a single control system, of no open standard. They may not choose to share any temperature information with the EMS/BMS. The EMS/BMS does not care what protocols are used inside the refrigerator. In a similar way, a BACnet network with 5 AHUs may choose to represent itself as any number of agents (likely 1-5, but ventilation may come to market as a separate service than cooling) but not as a collection of BACnet points.

Transactive integration is the way to solve the problem of diversity of systems in the home. Developers of small microgrids aim to waste no energy, but struggle to develop drivers for every system. Energy device drivers for every CPAP? Every stereo system and television? Plate warming drawers? Expresso machines? In my home, the biggest energy user might be my well. The diversity of home systems is daunting. Each of them is valued for the service it provides, but each can have an economic profile, a meta-model, a prototypical pattern for its energy use.

This simplicity and abstraction is a benefit for the maker of the system or device as well as of the EMS/BMS. The owner can look at a device profile in a store or on-line and can say “yes, that is the way this device uses/stores/generates energy”. We can imagine heuristics, such as “you need some more pre-consumption devices to smooth your load.” The economic actor profiles become a way to discuss the systems as well as how they will interact when sharing resources.

Profiles for the Economic Actors in Distributed Energy

This post is part of the continuing Paths to Transactive Energy series. You can find them all listed by clicking on the matching metatag at the bottom of each post.

As this series continues its survey of Transactive Energy, we get, at last to what I see are the essential agent personalities. The Agent Personalities are a mid-level abstraction that makes it easier for the appliance supplier and the EMS/BMS maker to know what is being attached. Every appliance at the local store could be a pluripotent transactive agent, but this does not aid the brain-developer in understanding what you just bought. A wine cellar may not be on the list of known appliances, but it is useful to know that it is similar to the refrigerator and to an air conditioner in how it approaches the in-home energy market.

http://www.theenergymashuplab.org/blog/8agents 

These agent types interact based on the principals of transactive energy. The non-power services provided and mechanisms used by each system are not known to the energy market. The precise mechanism of each system is not known to the market. Each system uses the market to achieve its own goals.

The creator of a system can identify which economic best suits the system. Some systems may be most easily represented by aggregate roles, wherein each role remain simple.

For example, an air conditioning system and a refrigerator may each act as intermittent consumers. When in the same market, each system can optimize its own costs by buying when the other does not. The air conditioner produces an equilibrium of comfort, the refrigerator produces an equilibrium of the conditions to store food safely, and the market achieves a punctuated equilibrium of power use with lower peaks. An ice maker may act as a pre-consumer, buying power when it is cheap to have a supply of ice at the target time. A pre-consumer buys when others do not, so long as its delivery time and product (ice) can be met. These two agent types may coexist in a single interface just as the two roles coexist in the same refrigerator.

These agent profiles indicate patterns for market interaction. But the market doesn’t care what kind of agent you are. User interfaces, which is to say human interfaces, that want to augment information beyond market summaries, will need to look for another means to discover that information.

The ASHRAE Facility Smart Grid Info Model (FSGIM) allows for communication of expected forward load curves, I think. A controller needs to know more than a partner’s present state. The partners trading position is Inflexible until when? Shiftable until when, then available for how long? How adjustable (shed levels)? Etc. These are all things that higher-level controllers need to get from lower-level controllers. A higher level controller could pass DR-related signals to lower level controllers: it may choose to alter them for its own purposes.

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.