|
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,
|
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.
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]
