Unveiling the Unseen World at UNC

Many problems of sustainability stem from costs that are invisible or are ignored. Building performance is rarely managed as building control systems are rarely accessible. As long as building systems are invisible and uncontrollable, then they will only rarely be operated with more than minimal efficiency.

We are just completing a multi-year project at UNC in exposing building control systems using ecommerce protocols. We called this system the Enterprise Building Management System (EBMS).

We had hundreds of existing buildings, each with its own low-bidder installed systems.

Most solve such complexity by opting for sole source acquisitions. Some areas, however, have special purposes that demand a special solution that may not be available from a sole source. In any case, we were starting with a substantial installed base. Merely achieving a traditional sole source solution applied to hundreds of buildings would take decades to complete, and cost far more than our budget.

We placed each system securely in its own sandbox, keeping the low level protocols off our network while exposing web services interfaces to operations staff and our customers. Our central monitoring and operations, based upon open source software, can now interact with systems from each vendor. Its interface is exclusively the web browser, and we have used it, and its graphics, on devices ranging from PCs to iPhones. We are planning to introduce these interfaces to the wider campus, faculty, and students.

While we were planning EBMS, I recognized we needed a new model for interactions with building systems, to open them up to the interaction with business operations, and make their operation visible to building occupants, to students, and to the public. Low level standard protocols such as BACnet and LON and proprietary vendor protocols require deep integrations while shielding information from the non-elect. Even when based on low level standards the supervisory systems are proprietary and without programming interfaces.

Five years ago we decided to move oBIX to OASIS for standards development. We lost several members of the team at the time, members who wanted to develop the standard within the traditional building system community. Web services are the protocols used for business-to-business interactions, but not all web services are usable by business or e-commerce. OBIX uses ecommerce style interfaces so that business programmers with normal skill-sets can interact with buildings.

The approach opens up systems to market competition and innovation. Each building system can be chosen based upon performance and functional fit, rather than compatibility to installed base. We anticipate this will help us see more rapid improvements in the future.

With this work in place, we are now moving forward to more exciting opportunities that our open interfaces create. We are working with the Registrar to schedule building operations around actual use, exchanging information using the same protocols used to schedule meetings by email. This will enable us to schedule heating cooling tied to actual building use. We are opening up environmental monitoring information to building users. The data center can see the building’s operating posture. Archeology can see each collection's environmental conditions.

Service Oriented Physical Security

Enterprise and government security are now deeply enmeshed in service oriented architectures. Policy-based event management increasingly drives access to data and access to information. Complex problems of who is granted what kind of access are resolved in conversations in which practitioners assert semantics and compare ontologies.

Members of the Security Industry Association (http://www.siaonline.org/) are in a complicated world with few standards. The big three services (access control, intrusion detection, closed circuit monitoring) share almost noting in control protocols or in implementation. The special needs of diverse facilities, whether highly hardened, or adverse environment (high radiation, extreme cold …) are likely to prevent technology consolidation. Because security must always be concerned with hostile agents, security systems are arguably an area where standardization is actually bad.

The best security systems interact with the enterprise. The trivial example is awareness that an employee was fired yesterday. Closing the office during the company picnic can change both the access control and intrusion detection rules in the building. But enterprise programmers do not really understand the inner working of these systems and their volatile technology.

Security is never about just locking the gate. It is far easier and cheaper to build a fence with no gate, if the goal is to make sure that no one enters. The point of security is to make sure that right person at the right time can easily access a facility or service. Therefore, the most important attribute of security is situation awareness.

Physical security faces the same key issues as system security. Identification is the first question: who is attempting the activity in question. One of the most important identities is the well known person Anonymous. The next question what roles does this person possess. What job does this person have? What role is he assuming today? Is he working on this week’s maintenance call-back list?

Intrusion detection has the same issues. Intrusion detection is also able to add spatial awareness to the enterprise security system. This week, I was introduced to a security system in which a user’s phone and network access were disabled as long as he was in a certain location.

Clean simple enterprise interfaces to security systems should treat the entire systems as an enterprise appliance, offering up situational awareness and providing simple services. Those services can then be made subject to all of the nuances of policy-based security used in the IT realm.

Service enabling Telecommunications – lessons for Buildings and Grid

Peter Carbone, Vice President of SOA for Nortel, gave a nice high level talk on the challenges facing a company that grew up with rigid account control and vertical integration in a regulated environment learning to dance in the world of SOA and mash-ups. As markets for building systems are still characterized by rigid account control and vertical integration, and the power grid is still vertically integrated, regulated, and almost complete account control, there are some useful lessons.

Infrastructure convergence was the enabling and driving change for telecommunications. Provisioning telecommunications was long the most difficult task. Over the last decade, the diverse communication infrastructure converged to a single packet-based infrastructure with resulting dramatic simplification of security and reliability. The questions move from “What low level communications do you need” to “What interactive services do you need?”

This evolution changed how Nortel had to think about and market their services. Before the change, Nortel sold vertically integrated applications that were inflexible. As the core technologies converged, Nortel was forced to decompose advanced services into core functions and then plug them back into the new architecture.

Fortunately, decomposing integrated services into core functions looks a lot like defining a service for service oriented architecture. Fundamental telecommunications functions can now be built into enterprise applications without requiring exotic skills are deep domain knowledge.

Skills-based routing and deployment was one example. Peter discussed a SAP integration with critical system causing expensive downtime, emergency part ordering, and synchronizing communication with an outside expert so that the repair personnel, the piece of equipment, and, via telecommunications and real-time identification of the expert on call, the expert’s telepresence were synchronized.

In a similar vein, he discussed abstracting the GPS function from the cell phone to block access in the security system when the phone was in a forbidden zone. Peter gave many more examples and you can find his slides on the OASIS conference site.

So what can building systems and the power grid learn from this?

Well, the owners expect the systems to just run, and are annoyed whenever someone says words like BACnet or LON (or any other control protocol) in their presence. We need to decompose advanced services to discover the core functions, from the owner’s and the tenant’s perspective, and present them as interfaces that can be plugged back into the enterprise.

As Peter summed up the C-Level response: “I just spent $100 Million fixing my processes, you had better be compatible.”

Building services that can present themselves as that can interact with SAP, or with PeopleSoft will have an advantage. The services that know how to display themselves on Google Earth will know how to request the nearest technician.

Likewise, Grid requests that present themselves to ERP services will find faster acceptance. Grid requests that describe grid pricing as shapes that can be pinned to Google Earth will enable the enterprise to come up with multi-site responses that may be different from any single site.

No one cares about the old vertical applications. Enterprise interactions are everything.

Semantic Assembly of Business Projects

I attended a super presentation this morning, that is a presentation on Semantics Utilized for Process management within and between Enterprises (SUPER). SUPER’s goal is to use ontological frameworks to make web services autodiscoverable and autoconfigurable.

While web services have enabled interactions between systems and companies more flexibly than ever before, they are still too hard to work with. Today’s web services were often created any naming standards were readily available. All too often, the similar items will have different names in very similar service offerings (poor semantic interoperability). When elements in two services share the same name, they may mean different things to the two services because they mean different things to the two companies (poor ontological interoperability).

Even when the fields have the same definition, they may be laden with external information that is not part of the schema. Certain aparantyl simple terms such as “shipping date” and “receiving date” may be overlaid with legal contracts that are not apparent in the web service description.

The SUPER project attempts to do the semantic assembly of business projects from existing services. By comparing ontologies, SUPER can rank available services as to how well they conform to the expectations of the business analyst. The goal of SUPER automated integration. Today, it can prepare a semi-automated response that leverages annotation, service comparison, and even composing hybrid services to deal with heterogeneity of service offerings.

Beware, though, as SUPER relies on a whole alphabet soup of standards.

SUPER uses Web Service Modeling Ontology (WSMO) to characterize systems, WSMO looks for strict WS compliance and strict decoupling of services. WSMO relies on ontology based classification of services to define core mediation services and execution semantics. WSMO is about service description, not implementation, defining a path to Semantic Business Process Management (SBPM).

SUPER augments SBPM by defining a semantic execution environment (SEE) based upon an open reference ontology. SEE is an architecture that defines what it is possible to ask for, but that does not specify how to do it, or at what granularity. SEE mediates between ontological representations rather than mediating between different behaviors

If you want to play around with this, there is a lot of open source material you can pull down, including:

• Apache ODE, a BPEL aware web server based on Apache
• WSMO Studio, an extended Eclipse
• WSMX on SourceForge
• SUPER, www.ip-super.org

These guys are bright and driven, and their work is well worth checking out.