Control programming today is like writing device drivers. Internal to a computer, low level programming is about moving data in and out of internal registers. Control system programming is, for the most part, reading and setting remote points. oBIX 1.0, first and foremost, provides point services for setting, reading, and tracking remote control systems. By defining a web-services based pattern for accessing the point service, control systems have been made accessible to enterprise systems and to enterprise programmers. Point services are not, however, enterprise friendly.
In almost all creation myths, the first task of man is the naming of things. We call formal rules for naming of things “semantics”. The next task for oBIX is to move to formal semantics of embedded systems. There are three approaches we could follow for semantics: tagging, system, and service.
Tagging is the most traditional naming for control systems. Tags are merely the naming of each point. Tags may appear on the initial schematic diagram of the control system. There may be some sort of internal logic to tagging. CWCRT007 may be the Chilled Water Coil Return Temperature #7. I might just as easily use the tag CWC007RT for the Chilled Water Coil 7 return temperature. The control system integrator assigns tags within control systems. If I am lucky, the integrator working on the third floor will use a naming convention compatible with that used by the man working on the sixth floor. If I am an advanced owner, I might have specified the standard to be used pre-construction. Tag standards such as these do little to help the enterprise work with multiple buildings.
System based semantics will name things by the system they are part of. This approach aligns well with the data life cycle defined by NBIMS (National Building Information Model Standard), especially if the contractor uses COBIE (Common Operation Building Information Exchange) to hand over NBIIMS information to maintenance and operations. Each system gets the same name it had on the initial design documents. One problem with this approach is that most design documents have significant errors and duplication in the controls portions. These names, while useful to those performing maintenance on the building, they often have little to do with how the tenants see the building, and thus may be difficult for enterprise programmers to use.
Service-based semantics name systems for what they do, not what they are made of. Service-based semantics may be mapped to the spaces they support, i.e., “Heating and Cooling for Big Conference Room”. This makes it easy to link business processes with building processes; we can easily imagine inviting the heating and cooling system to the big meeting. It may require additional maintenance, as the C-level executive’s office, however critical, may move from one room to another.
Ontologies are the next step above semantics. Ontologies are the classifications that semantics fit into. A computer-based ontology would enable a computer to fit a system into one or several hierarchies of meaning. To illustrate, consider a room in which a cat is playing. I ask the computer, “Are there any animals present?” Using semantics, a cat is not an animal, and the answer is “No”. Using an ontology, the system considers that a Cat is a type of Pet and a type of Mammal. A Mammal is recognized as a type of Animal. Now the computer can answer, correctly, yes.
Today, we talk of the interactive web, and call it Web 2.0. Web 2.0 is interactive and responsive in ways that the initial internet was not. Small point services add increased functionality such as the type-ahead and spell-check functions in Gmail. Current discussions of the future of the internet imagine systems being able to negotiate with multiple remote web sites to increase function and responsiveness. These functions may include discovering new remote service on the fly to respond to user or system requests. These new functions will require that systems be able to recognize and understand the services provided by remote systems. The basis of Web 3.0 will be the formal ontological classification of web services.
Service-based semantics provide a better basis for ontologies than do system-based or tag based semantics. A single system may provide more than one service. Each service may be linked to multiple chains of ontology, just as the cat above is linked to both the “Pet” and the “Mammal” ontological hierarchies. A single service may be linked to both an external standards-based ontology and an internal organization-based ontology.
All of this sounds at first hearing as a bit of a stretch, but in the near time, it will become the basis of what we expect from all system integrations. Interested readers may wish to check out Ontolog ( http://ontolog.cim3.net/ ), a Web 2.0 home for those exploring how to find meaning (ontology) in engineered systems.