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.

Lessening the Integration Barrier to Smart Energy

We do not have a problem of knowing what to do to make buildings participants in smart energy. We do not have a problem that the technology is too expensive. We do have a problem that it takes too long to integrate systems. High integration costs lead to vendor lock-in. High integration costs lead to long sales cycles for replacements and upgrades. High integration costs will continue to slow the adoption of distributed energy resources. High integration costs lead to islands of automation, unable to participate in smart energy and demand response.

In design and in construction, today’s best practice is to use a BIM (Building Information Model) to deliver better buildings on-time and under budget. BIM trades higher design costs for much lower construction costs and reduced risk. We use BIM to generate energy models, essential to green certifications for buildings. Until recently, BIM hasn’t had much to do with the operations of a building, or with systems inside a building. This month, I am writing about how this is starting to change.

In traditional CAD, we have used libraries of templates supplied by product vendors for years. Suppliers of plumbing and lighting equipment have wanted it to be easy to design with their products, and they have wanted their products to look good in design renderings. Specifiers Property information exchange (SPie) is a project that encourages this approach applied to the more detailed requirements of BIM. SPie objects are cross-referenced with Omniclass and can include hookup and connection information. The National Electrical Manufacturing Association (NEMA) and is one of the associations participating. SPie brings the things we install in buildings into BIM.

Two technologies dominate the generation of building energy models. GBXML has wide support not only in energy modeling, but also in the design of HVAC and control systems. Information built on GBXML has had no path pack into BIM. EnergyPlus is purported to generate more accurate energy models, and has a well-defined model view for re-entry into BIM. ENERGie, (the ie is again for information exchange) is an effort to merge the two to provide a single model coordinating system design with building design and supporting full system detail. It is likely that ENERGie will soon be required for General Service Administration (GSA) and Department of Defense (DOD ) work. GSA and DOD are the two biggest landlords in North America, so their wants can drive the industry.

In information technology, we again and again see the technology we develop for the most advanced systems flowing down through normal business and all the way to the consumer. ISO 15926 is an information framework developed to express the relations between systems and components in the largest chemical processing plants. Today, ISO 15926 being adapted for a variety of tasks, from the esoteric mapping between ontologies to the automated mapping between form and function to operate smaller systems. ELie is a project to hand over the Equipment Layout in buildings to the owner by mapping from BIM to ISO 15926. ELie connects a static design to a runnable model.

Management of live electrical load in buildings is the largest challenge in smart energy. Plug load is almost unknowable in any automatic way. It will be some time before smart energy-communicating systems will outnumber legacy dumb-load equipment. Smart electrical panels that expose energy use per circuit have not found wide use; they follow no standards, and it is unclear what space they support. PLie standardizes the description of Panel Layout and brings it into the BIM of electrical wiring. PLie can provide automate the mapping of building wiring into the spaces and equipment it supports.

The EIS Alliance is developing models to support autonomous load management and shaping in buildings. One of their concepts is that the buildings electrical meter should be an information appliance for the building EMS. New building equipment and appliances could support the same interface to report their own energy use. Web services (WS) aware electrical panels could use the same interface to standardize their load reporting. Combining this interface and PLie brings the buildings dumb load under management with minimal integration.

Everything above is talking about plans and designs. New systems present ongoing integration costs. WS-DD and WS-DP are new standards to enable the automatic discovery of systems. These standards enhance the value of the energy information appliances by describing what each meter is tracking.

This laundry list of energy-related specifications are the answer to high integration costs and provide a path to sustained re-integration of systems. The flow of information through Model Views into smart energy is the key to continued understanding of building performance. These specifications will move the markets in energy management systems into improved interfaces, for users, for enterprises, and for energy marketeers.

Highlights from the FIATECH Member Meeting

These have been a couple busy, challenging days at FIATECH, extremely dense in information and conversation. FIATECH is the consortium for the application of IT to Capital Projects. FIATECH was instrumental in the rapid progress of the National Building Information Model Standard (NBIMS). FIATECH is also a national clearing house for information about applying developing technology to construction, including the use of mobile computing and RFID. I am not going to write of either of those today.

FIATECH is home to a far reaching project, now known as IDS-ADI. The IDS (Intelligent Data Sheet) defines coherent collections of data about classes of equipment. These data sheets include ontologically significant metadata to define the contents and meaning of each attribute. ADI project is an effort to complete and deploy systems based upon the ISO 15926 standard describing process control plant and equipment. ADI stands for Accelerated Deployment of ISO 15926. ISO 15926 also includes all 3 dimensional information on system components. These groups merged and you can read about them at www.ids-adi.org.

The team has developed a generic data model and reference data library to manage and store this information, including OWL/RDF supplying ontology for each of the attributes. They now report that other data sets, non 15926 data sets can be stored in the same library. By referencing the RDF, the system can automatically translate between one data set, or group of data sets, into another, mixing and matching until there is a match. This is ambitious work.

The next step for the IDS-ADI team is to re-write the code into what they call the industrial strength version. They want the repository to be strong enough to generate three -dimensional visualizations of the ISO1529 process control systems, with all knowledge still attached, fast enough for someone to respond in an emergency. This moves from ambitious to astonishing. To my OWL and Ontology readers, please drop me a line on what you think of this work.

I am not in the process control world, and I do not work at a chemical plant, so my attention was elsewhere, on the whole series of projects that are missing the same keystones of information. The projects need business oriented definitions of the services provided by building systems and a lightweight, far lighter than BIM, set of abstractions for building information.

Scenario-Based project planning aims to capture and formalize the pre-design goals of capital projects. What are the business deliverables of the project, can we track them, and, perhaps, can use them to judge the project's success. I think these deliverables should include the services the building systems should provide and their performance goals. For example, a high end office space might specify a higher than standard health index to justify higher than market rents. For a green project, the same building might specify lower than normal energy use. The higher than normal rents are part of the business justification of the project, and the performance requirements become overarching design goals for the project, incurring costs, but perhaps also mitigating project risk.

These service performance goals can then become the basis for evaluating the project energy model, effectively commissioning the design. The same goals become the basis for performance contracting of building systems, and of commissioning the building. They also provide a baseline for ongoing building system analytics.

For a business to make any but the smallest response to grid-based signals about energy usage, the business manager must be able to understand the consequences of his decisions. A lightweight BIM could describe which systems and which areas would be affected. The effects would be described in terms of degradation of the business services described above. Knowing, in business friendly terms, what the consequences of decisions would be would free the business manager to make more effective and bigger decisions than he is willing to today.

In emergency response scenarios, information from building systems must be presented up though a lens of simplified structural and use information to provide easily understandable information to the first responder. To support building owners who have security concerns, this information needs to be filtered based upon policy assertions that can be implemented in code. Business rather than engineering experts would apply these assertions to something that must be simpler than the BIM.

Autodesk has indicated some interest in submitting GBXML (Green Building XML) to a standards organization. GBXML is a lightweight derivative of the IFCs in NBIMS used to support energy modeling. The GBXML specification, if promoted to a standard, could perhaps be the lightweight BIM I describe above.

This would leave only the semantic service definition for building services for advancing these projects.

Ontological requirements of the service oriented grid

We will be unable to scale out the integration of the power grid on a continental scale, to support the diversity of systems currently installed using process oriented integration. We must support even more diversity, from technological innovation as well as from business innovation to achieve the new markets in energy today’s challenges require.

While simple demand-response capable systems provide great aggregate value to the grid, the small-scale benefits they offer seldom make a compelling interest to the home or commercial building occupant. This limits new energy scenarios to small advantages that can be achieved by static regulation. If we enforce participation through regulation, we will only harvest the lowest of hanging fruit and encourage cheating and “malicious compliance.” To do more, we must increase the value proposition for building and home owners. This means either decreasing the costs of integration, offering more value for integration-capable systems, or both.

Service oriented coordination is opens up new avenues for energy re-allocation and conservation in the home and business. Service orientation solves the diversity of systems challenges while providing the building owner/operator with new means of controlling power use. A key challenge to establishing such services is common semantics to enable conversations about energy use and system performance. If properly defined, these semantics enable the owner to recapture investments in performance and interactivity through non-operations business processes, reducing the barriers to adoption.

The energy grid itself must acknowledge its roles as a service provider in the systems architecture of each building owner and operator. To be a full participant, business negotiations between building and grid must beyond availability and burn rate to a fuller model of cost, and scarcity, and projected reliability. To create discoverable markets in power, power source semantics must be mappable to ontologies of value that are relevant to the energy purchaser. In other words, we must move beyond mere price signals of demand-response. The integration client must be able to decide whether to make or buy based upon projected quality and reliability. Markets that allow the building to discover and negotiate with power sources must also enable the building to negotiate for which kind of energy sources.

 Electric cars and their batteries are popularly cited as a solution to problems of peak shaving and energy demand smoothing. Wholesale adoption of electric cars would instead increase peak demand volatility in many scenarios. To achieve the hoped-for benefits of electric cars, drivers, automobile producers, and the power grid must develop a common vocabulary for use in the acquisition, storage and use of power. This semantics will be critical to the e-commerce underpinnings of electric car adoption.

 To achieve full realization of the potential benefits from the new energy technologies, we must move beyond process oriented interactions to service orientations that accept diversity and enable technical as well as business innovation. These approaches will require the development of ontologies around building-based and grid-based services so that each can be full participants in enterprise and consumer interactions.