Hospitals and Control Systems Data

Of late, I have been so interested in the Grid, that I have forgotten the internal enterprise and the use it can make of information from embedded systems. Recently I fielded a question on hospital recordkeeping, refrigerators, and TJC (The Joint Commission) compliance.

There are refrigerators dispersed throughout every hospital that store medication, research samples, lab cultures, et al. To maintain their TJC certification, hospitals must monitor and record the refrigerator temperatures. Today, many have a manual process of reading and recording this information, followed by log consolidation and other potentially manual processes. The question concerned how to best support this process.

My answer follows.

Embedded control systems are inside each of the embedded systems you name. Access to the information within these systems is, alas, non-standard and quirky. Even if you can get the reading from a particular sensor, it is likely to be non-qualified and non-abstract. Those are fancy words to say that you may be asking a temperature sensor and getting the answer back in millivolts. Even getting that answer is hard, because the protocols used inside the systems do not look like anything that your IT folks have seen before.

There is a new standard, now in early adoption, for getting to the information in controls systems. oBIX (open building information exchange) is a web services based protocol developed within OASIS ( www.oasis-open.org ), meaning within a business communications group rather than within a controls manufacturers group. Several manufacturers are in early testing of there oBIX gateways to underlying controls systems. I am using 70 such gateways to get to building operation information right now.

What is good about web services is that they are open and accessible. They do not require that you be an engineer in the control room to get to information. I have seen Excel spreadsheets using only out of the box software polling a web service periodically and automatically adding another row of data.

If you work in hospitals, you may have run across HAVE (Hospital Availability Exchange) standard. HAVE lets, say, emergency medical responders poll nearby hospitals operators for the shortest wait time for critical diagnostic equipment. Because the HAVE standard includes no patient or procedure oriented information, it cannot put HIPAA sensitive information in play – only wait times and resource availability.

For implementation today, you should rely on someone else’s advice. But for mid term planning, look to service oriented architectures based upon abstract surfaces expressed as web services.

Full disclosure here – I am co-chair of the oBIX committee. Some in ASHRAE would passionately defend BACnet-WS as the architecture of choice. That discussion is a long and nuanced one that I will spare you. But *I* say, starting asking your suppliers about oBIX.

Do you choose Incrementalism or Markets?

The Grid doesn’t get better because we keep on relying on central planning to make it better. Any efforts developed exclusively by the current stakeholders and run through the utilities commissions will predictable and incrementalist. There is one (at least) that is not. The GridWise Architectural Council is trying to create open interoperable protocols to enable vibrant markets to develop, ones that are not driven by or yoked to the lumbering old style utilities companies.

GridWise looks to transform the production, delivery, and consumption of energy by adopting an open standards-based architecture across the entire power grid. GridWise makes no assumptions that future power markets will look as they do now. GridWise applies the latest approaches of Information Technology to the problem of grid modernization, and envisions a future in which the electric power grid is an information-rich, transactive network of decentralized economic agents. GridWise anticipates that opening up the interfaces to each business activity of the Grid will open electric power markets to innovation and create more choice and product differentiation for consumers.

Most folks are not going to live off the Grid, in my opinion. They might live what I call “near grid”. This means end points, whether homes or businesses, take responsibility for their own reliability. This will co-develop with approaches to storage, whether fancy batteries, chemical reactions, or even the water storage tank forty feet in the air I grew up with on the ranch. Live power pricing will drive storage development better than any number of central government programs; better storage will make responsiveness to price signals easier. From there, every means of alternate energy, no matter how unreliable, become another way to charge the storage. Sites will have multiple generation strategies depending upon their location, winds, sun coverage, thermal posture….

OBIX will package underlying control systems as services. Service definitions make meaningful statements of security and policy possible. Service definitions of each system will enable ad hoc discovery and control by software agents.

These agents may live at the home, the office, or at the hosting site of the 3^rd party energy and maintenance manager. These agents will read live meter readings and live energy prices. There will be a competitive marketplace for the software used by these agents. The best will expand building amenity and responsiveness as well as reducing the costs of energy and maintenance.

POE: Who’s using the Power?

There has been a lot of talk in the The Continental Automated Building Association (CABA) in Cisco Connected Commercial Real Estate (CCRE) and other venues about the collapsing of building wiring plans into a single wiring plan that handles all communications, whether within the building systems, or for voice communications, or for computer networking. The presumptive protocol for all this is IP (as in TCP/IP).

Superficially, this is a compelling vision. Certainly the combination of Voice and Data networking is well under way. Wiring is a large part of the systems expense for every building. Reducing the number of wiring systems offers opportunities for cost reduction.

I have trouble putting the components of building systems in this category. I think each building systems provide an integrated service. Defending and supporting the provision of that service is the mission of each system. Components of that system do not really make sense outside of that system. Defining security for these system components is nonsensical.

Security and Access can only reasonably be defined at the level of the service. What is the security posture for a sensor that reveals an unidentified temperature? What does the value of a sensor mean if isolated from its system. How can we define access to a setpoint if that setpoint is isolated from the service it controls?

One counterpoint might be if the wiring went beyond networking to provision of power. This might reduce cost enough to make such systems worth-while. I do not know if anyone is using Power Over Ethernet (POE) to reduce the wiring costs of sensors or actuators.

Is anyone using POE to power sensors or actuators within a control system? Can onyone point out to me anyone whi is actually doing POE to control systems? Or does this entire field remain in the realm of “marketecture”.

Grid Interop Coming up

I submitted an abstract for a talk at Grid Interop today. I have been near academia too long. Abstracts bring out the most pompous side of my writing. Even so, I am sharing this abstraction with you.

Business Innovation and Service Abstractions

True Scalability and interoperability require abstraction and security. Most control systems today expose name/value tag pairs as their interface. This poses two problems. Interaction with exposed tag pairs requires a deep understanding of the underlying systems. Secure interaction with sets of tag pairs can only practically be exposed as monolithic yes/no decisions for the entire set.

The smart grid will require integration with smart buildings and their associated power capabilities. We will need to develop abstract models for system interaction to enable such large-scale system integrations. These abstract models will hide underlying system detail while exposing the diversity of systems for orchestration.

None of this will happen without mature security models. Significant segments of people and businesses will not give up autonomy over their private resources to any third party. System abstractions will make building systems appear as printer drivers do, exposing themselves to owner agents able to negotiate with the intelligent grid.

A service can abstract the operations of each system. This service defines the mission of the internal operations each system. Each building system should defend its mission. Systems that are quite different in complexity and technology can provide the same service. Owners and integrators will be able to compare different systems as to how safe, effective, and economic their operation is without changing the higher level integration.

Services enable security, and security enables allowing the tenant or owner to interact with building systems. Agents can be restricted to which services they interact with, and what performance they request using understandable business rules. This level of abstraction will support internal tenants or third party service managers to safely and effectively interact with the building systems.

Service oriented architectures and integrations make possible large scale interactions. Service discovery enables ad hoc interactions. Services hide implementation details. Service oriented architecture to will enable orchestration of building systems including site-oriented energy generation and storage. New business models will take advantage of these new interactions to drive energy use reduction through innovation.