The Challenge
As with all industries, Building Automation (BA) has gone through, and continues to go through, changes in what data sharing capabilities are expected of vendors’ solutions. Multi-vendor inter-connectivity was once accepted as either: not possible due to the proprietary protocol and hardware being used or risky and complicated due to custom development which, boiled down to costly solutions that were limited and difficult to maintain. In contrast, today’s solutions increasingly expect the opposite: simple, transparent data sharing among devices and applications regardless of the vendor.

In response to the growing need to freely communicate with a wide range of devices, protocols that originated in the BA industry have evolved to deliver straightforward access to a broad range of BA devices. Today, many vendor-specific proprietary protocols have given way to a standardized protocol such as BACnet. BACnet delivers what users are asking for: the ability to communicate with a broad range of devices using a common, well defined protocol. However, due to the scope of what BACnet focuses on, it does not resolve two key issues:

First, while thanks to BACnet, data connectivity to end devices has grown, there are many vendors who use other, often proprietary, protocols such as LonWorks™ which are not compatible with BACnet. In addition, a large install base of legacy systems that use older protocols do not support the latest device data connectivity solutions.

Second, the number of applications where access to real-time, alarm and event (A&E), and historical data is needed continues to grow daily. No longer limited just to BA, the users of BA data are increasingly spread throughout the enterprise. This introduces a wide range of off-the-shelf software applications, such as Human Machine Interfaces (HMIs), historians, and analysis and reporting packages which often originate from the process control industry but need BA data. The problem here is that many of these applications do not have drivers that support such protocols as BACnet or other BA specific protocols.

The OPC Solution
Fortunately, there is a simple, standards based, solution that addresses both issues – it is called OPC. Rather than competing with BACnet, OPC complements it by coming into play where BACnet leaves off.

Originating in the process control industry, OPC was designed from the ground up to address the multi-vendor, custom device driver problem. The process control industry faced the same data connectivity issues as BA and as a result, developed this flexible, robust method of moving data from any device to any application without getting bogged down with custom drivers. Instead of focusing on trying to make all devices talk the same language, OPC focused on how data from different device-drivers could be shared among them. For this reason, OPC has quickly become the method of choice for industrial data-connectivity.

The premise of OPC is simple: it introduces an abstraction layer between devices and applications to allow data to pass between them without them being aware of each other’s internal data representations.

The concept of what OPC aims to achieve sounds good on paper but, how is this functionality implemented in the real world? The answer: Through the use of a client/server model that conceptually splits the functionality of a traditional device driver in two. An software called an OPC Server, takes care of communicating natively with a device (data source). While OPC Client software, natively communicates with the Application (data sink) it was written for. The key for this to work is that OPC only defines the interaction between the OPC Client and OPC Server but does not get into the OPC Server-to-device and OPC Client-to-application communications since; these are different for each device and application respectively and are left to the vendor developing the respective OPC component.

This standardized data exchange between the OPC Clients and OPC Servers allows any OPC Client to communicate with any other OPC Server. Since the OPC Server takes care of translating Native device communications into an OPC format and the OPC Client does the same on the Application side; Applications and Devices can share data between each other without having to know each other’s native protocols or data formats.

OPC’s abstraction allows applications such as HMIs to communicate with any protocol based data source (for example BACnet devices) without having to natively support its protocl. It also allows multiple OPC Clients to simultaneously connect to a single OPC Server.

By allowing any OPC enabled application to communicate with any OPC Server, it’s possible for applications to get data from BACnet devices without the applications having to know anything about BACnet; this makes enterprise wide communications possible and resolves the second problem we started with.

An OPC Client can communicate with any number of OPC Servers which means that an OPC enabled application can communicate with numerous OPC enabled devices (meaning they have an OPC Server) regardless of their communication protocols.

In summary, using OPC is particularly beneficial for users because it allows them to:

• use any OPC enabled off the shelf application to work with their data (almost every major Historian and HMI comes with an OPC client built in)

• work with equipment and applications from multiple vendors without worrying about the native protocols employed by each component

• avoid being ‘locked into’ using a specific vendor due proprietary connectivity issues

• minimize controller loading

• continue using a popular protocol like BACnet without having to worry about how the rest of the enterprise will access it.

Made For Each Other
It’s important to understand that a device communications protocol such BACnet and OPC serve different yet complimentary purposes. BACnet and OPC are similar because they provide an open, standardized method of communication to various entities but they differ in their focus: BACnet on native communications with many BA related devices, OPC on the layer above this – allowing applications (data sinks) to access multiple data sources without concern for the vendor they come from or the underlying protocol they use.

About the Author

Darek Kominek: B.Sc. Eng. CompE, P.Eng. (Alberta, Canada), is an OPC Specialist and Instructor of all MatrikonOPC Workshops and Online Training Courses. Darek is responsible for MatrikonOPC's Training unit which is comprised of over 100 hands-on workshops around the world. Since 1997, Darek has been providing design and architecture assistance for OPC solutions, as well as taken part in the development of OPC Software.

[Click Banner To Learn More]

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