November 2010
Article

AutomatedBuildings.com

[an error occurred while processing this directive]
(Click Message to Learn More)


Connecting Building Automation to Everything

In an ideal world, we will be able to be vendor and protocol independent. Everything will talk to everything.
 


Nino Kurtalj, President,
Elma Kurtalj Ltd
 Our world is becoming dominated by machines. Rarely will we find a single activity without interaction with machines. More and more we are seeing machine to machine interactions too. Still today these interactions are dominantly contained in certain process domains. The changes what we are experiencing are opening boundaries between technologies, which were irreconcilable yesterday. We are approaching a time where everything will talk to everything.
 

Articles
Interviews
Releases
New Products
Reviews
Editorial

[an error occurred while processing this directive]

Coming Events
Sponsors
Site Search
Blogs
Archives
Past Issues
Home

[an error occurred while processing this directive]


If we just think about our homes and the technologies that we find there, it amazing how many different communication technologies we find.  I will just mention the most common ones: IR, RF,  Serial, Bluetooth, IP, WiFi, Zigbee, LonWorks … Some of these protocols could be seen as Personal Area Network domain protocols, some will fit into the Local Area Network domain, as well into the Internet domain. . Such different focus of the protocols complicate more the interconnection of  everything with everything. Why is this so complicated to achieve?
 
There is no simple short answer. Most of the technology evangelists are pointing towards Semantic Web as an ultimate answer. However, do we really need Semantic Web to connect our IR device with the device on the WiFi network? After being able to interact with each other over the web do we need an ability to share states and resources from our personal devices with others?  Good friends were always sharing their belongings like books, movies, and sometimes clothes. It seems that the social web just moved old habits to a new dimension of sharing pictures, videos, and other data with our virtual friends.  As we come to a time of interaction of everything to everything we will respond probably on the same way. We will share. However, how will all that happen, and when? What will the ultimate force be in the creation of these interactions? There are still no simple answers.
 
One of the key features of today is networking. Most of the things we are buying today have a network connectivity socket, the old RJ45 or some kind of wireless interface. However, interaction between things is another story. Sometimes it is possible, but often is not. In an ideal world, we will be able to be vendor and protocol independent. Everything will talk to everything. It is possible if we narrow protocol space and  respond only to a few protocols. Creating data flow between devices is really easily achievable, but the real issue is behavioral  semantics; in other words, meaningful interaction between things. We need to be able to translate actions and behavior from one protocol to another seamlessly.
 
If we look, for example, into the ZigBee semantic level, we notice User-defined Application Profiles at the ZigBee Object Layer. To be able to interact between device products from different vendors Zigbee Alliance created the ZigBee Cluster Library of specific functional domains like HVAC, Security, Lightings and others. Within every functional domain, we have different profiles like home automation profiles, building automation profiles, automatic meter reading, consumer electronics, Telco services. Through a profile we have standardized behaviors for devices as well as services. For example, a fan coil is a typical device, and the scenes are typical services.  What we see is that the devices are modeled through Application Objects, which are communicating through the exchange of Clusters and Attributes. Each Profile Object can contain single or multiple Clusters and Attributes. The binding mechanism ensures the interoperable exchange of Clusters/Attributes which are sent directly to destination application objects within a target device. Unfortunately, Application Profiles are in various stages of development and standardization, and as always there is space for some proprietary stuff in the Private Appication profile area.
 
The ZigBee Alliance used to be very US-centric, but today we see very intensive growth in Europe and Asia. Most serious companies from the field see ZigBee as the wireless technology of choice in their domain.
 
When I first read about ZigBee, I found its general concepts such as the Bottom Up concept. It reminds me in a certain sense of my old friend LonWorks. In Lon we have objects, which are similar items to ZigBee Application profiles.  I am not trying to compare them, since they are really very different technologies but both can suit very well the purposes for which they are built. And that is the key. All protocols are not built for the same purposes. For example, Bluetooth has been developed to serve different application spaces than Lon and ZigBee. Bluetooth targets higher data rates to transport richer media (typically voice signals).  Not to mention video protocols. Generally, we can look on the protocol space as on two separate domains, control and media domain. These are two totally different application domains, and at the end everything could be narrowed down to probably two super application protocols. Until that happens, we will need to live within our colorful and rich application protocol world.
 
One of the key drivers of the industry is to find and implement techniques that can reduce project time and cost, as well as improve productivity and performance. We are seeing growing trends of integration and decentralization in the industry, that is pushing us to invent technologies, which will wipe out boundaries between different application protocols. One of the key ways in achieving this is through the usage of an Ontology model.
 
What is the Ontology?
 
Let's assume that between our real world and the problem domain and solutions is the conceptual world with conceptual models and otologies. Following that concept software and hardware are just gears. One explanation for ontology could be that ontology is a gateway between Semantic and Pragmatic, where semantic represents structures, forms expressions of content and Pragmatic represents intended use, design methods and context of the domain.  Standards are really floating between both Semantic and Pragmatic boundaries, but the challenge is to create common formalization. In history, the ontology was used to represent knowledge, but it could be efficiently used to generate new knowledge too. Simply, we can look on ontology as a way of storing, organizing and representing knowledge. It is used in various fields from technical systems to biology. Since ontology allows us to represent specific knowledge in an abstract and organized way it could be use to create a common layer between different application protocol paradigms. 
 
[an error occurred while processing this directive]Creation of such technology where the devices and networks comply, even if they are produced by different vendors, represents a major move to really open systems. Today within one technology the devices are able to communicate with each other. This vendor-independence we call interoperability. Interoperability does not guarantee just communication, it guarantees distributed application processing among products from different vendors within one system and one technology domain.  Since, all technologies have their data model as well an application model, we cannot mix devices from different technology domains. We can do it through gateway translations, but that makes integration very complex and expensive.  We see that integrating dissimilar technologies is not a trivial task.  Within different networks ( BACnet, LonWorks, ZigBee) particular application models use different communication services as well as different data structures to store application data. A mapping between different models is the only way for integration of dissimilar systems. Commonly, we use gateways for such applications.  Usage of ontology principles in integration of heterogeneous networks brings major benefits. First we are able to commission and configure an automation system centrally through ontology changes only. The central management approach guarantees system consistency. Since there is no translation between protocols, there is always translation between the protocol and ontology model, we don't have the data overhead we have normally in most of today's heterogeneous systems. Generally, what we do is shift interconnection on top of the application layer. That significantly simplifies information management and processing. Simply, that brings us to a possibility to integrate variables (information) from various protocols as input parameters of a particular function, do the processing, and the output parameters could again go to a different protocol. To be able to do so, we have to separate generic information from a dependent installation using an abstract model. That is exactly what happens within BrightCore. BrightCore uses the ontology concept in integration of dissimilar networks through the abstract control network model. 

The ontology is used for abstracting  existing building automation networks (LonWorks, BACnet, Modbus) and for creating a generic control network model.  All management and configuration tasks could be performed regardless of BAS technology. What is below a generic control network model? The biggest benefit of such a system is avoidance of gateways. We do not need rules on how to do mapping between dissimilar protocols any more, since every protocol is mapped just once to abstract representation within a generic control network model. Having such a common base for all protocols opens us one to one data relationship between dissimilar protocols, as well one to many relationships too.   We have single mapping defined. Mapping, which goes from technology to ontology. Extension to other protocols is very simple. Clearly, all integration models what we used to use within one protocol network, for example, LonWorks, we can now extend to multi protocol domain. We can simply bind data from LonWorks to Modbus or from LonWorks to BACnet. Within BrightCore, there is a Tool BrightCore Builder, that is an Ontology tool as well as a commissioning and integration tool too.

The centralized binding approach facilitates a possibility to directly connect information from devices which are living within various networks. For example, we can connect a LonWorks variable directly to a Modbus data representation and a LonWorks temperature sensor could provide data directly to a Modbus PLC without a gateway. All semantic changes are made automatically within a generic control network model. The process is very simple. It consists of simple binding of the data points. After binding is finished, the model could be automatically deployed to corresponding networks through a Bright Node. Furthermore, within the model it is possible to create new classes, which will be used for complex processing and for integration with totally dissimilar information models. That is the way for integration of the ERP application data directly with filed bus data.

BrightNode represents the device which is equally attached to a particular network, as to any other network device, obeying from the network side the rules of the network and from the system side the general control network rules. As the nodes receive change in the configuration data, for example new mapping, it will initiate a stop and restart procedure. This will hardly be noticed within the data flow from the network to generic control network model. This online commissioning feature is the critical one if we have geographically distributed network. The Generic Control Network model is living within the Core.

Such models could be used for integration of data from networks, which are handling totally various scopes. Clearly, control data such as temperature could be combined with the video from a camera with any problem through classes defined in the ontology model. One of the key things in such an approach is introducing new components in our networks  - Process Application Controller, within BrightCore framework it will be microCore. This is a position of the ontology concept deeply in the network right at the level of data flow. As hardware prices drop, we will reach the point where such nested component in the systems will be unavoidable in our daily automation routines in homes and as well as in commercial buildings as a key everything to everything component.

footer

[an error occurred while processing this directive]
[Click Banner To Learn More]

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

Events

Want Ads

Our Sponsors

Resources