Long-time readers may recall that I consider many systems over-integrated. Access control and intrusion detection have been routinely integrated into BACnet using the notion that actuators are actuators, and sensors are sensors. This usually results in systems that do at most one thing well. An industry (HVAC) that uses the word “alarm” for what everyone else would call an “event” is not writing the right code to run everyone else. Still, we had a single baseband in place, and a single expensive computer for the building, so this model sometimes won. Recent changes in the technologies and architectures of the Internet of Things are challenging this old model.

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 from a distance. In homes, these were unpopular because most people did 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.

The AllSeen Alliance is pushing hard to build a world with an ecosystem of Apps. The AllSeen Alliance works for rapid wide deployment of AllJoyn, the Quaalcom-backed open source Linux Foundations platform for Internet of Things. AllSeen support by most of the Asian white box manufacturers puts pressure on the central control model of ZigBee SEP2. Traditional controls players such as Honeywell have created open source plug-ins between AllJoyn and traditional baseband communications such as BACnet. AllJoyn platform support by makers of home networking gear make ready internet connectivity of AllJoyn Apps a given.

Ease of development is also important. Microsoft has committed heavily to tools that make AllJoyn development easy. This includes ready support even for non-windows CPUs, such as Raspberry Pi and the open hardware Arduino as well as fat-platforms such as Windows, Android, OSX, and IOS. The gateway connector opens up access to many legacy systems. Even before the release of Apple TV, the age of widespread IoT Apps had arrived.

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 send 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.

App platforms means App coexistence. If the consumer is empowered to choose the Kitchen App of his choice, then any all-home Microgrid app (or even all-home OpenADR system) must be able to interact with any Kitchen App. The aging and unpopular (to consumers) monolithic control model reduces all systems to commodities and thereby limits consumer acceptance even as it blocks supplier innovation. Apps must be free to supply unique value propositions even as they play nicely with others.

In Smart Energy, we approached this through common resource frameworks and transactive smoothing and balancing of those resources. This approach, which we named service oriented energy, does not care about the internal mechanisms represented by an agent, only upon the effects over time on a resource such as power.

Overload. There are too many processes running under this userid. Please wait a minute and try again. (fork failed)The abstract resource over time model at the heart of EMIX is resource agnostic; it works the same to manage power, or voltage regulation, or congestion fees or transmission rights. It also works for other resources such as water supply, natural gas, and even sewage and wastewater management. This list is all what I would call hygiene factors, i.e., low-down concrete factors on which consumer services are built. Can higher level, amenity resources be defined?

Other aspects of resource frameworks have to do with performance. The smart energy standards include performance-specific information such as ramp times, notification times, maximum run times, required down-times between invocations, and minimum economic values. These were developed to support simplified bidding into bulk power markets while also being applicable to simpler and smaller systems.

I will be proposing resource frameworks for AllJoyn Apps at the AllSeen summit in Seattle in October.  These frameworks will not attempt to define what goes on within apps, but instead to define how Apps can cooperate to achieve optimum outcomes as defined by their owners. This same model is at the heart of The Energy Mashup Lab’s microgrid agents.

The third wave is just beginning. I will be discussing new models for development in the Internet of Things at my talk this month at TechIntersection in Monterrey, CA. If you are there, come by and catch up. If you attend, you can save $50 on registration by mentioning my last name.

Overload. There are too many processes running under this userid. Please wait a minute and try again. (fork failed)
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]