- By Darek Kominek, Matrikon
- February 07, 2003
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.
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.
Figure 1: Custom Driver Problem: Each application requires a device or protocol specific driver to allow it to communicate with each respective device. Drivers are not re-usable between applications because each application uses its own data format(s).
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.
Rather than competing with BACnet, OPC complements it by coming into play where BACnet leaves off.
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.
Figure 2: OPC introduces a layer of abstraction between a data source and a data-consumer so they are independent of each other’s native.
Figure 3: OPC Specifications define how OPC Clients and OPC Servers communicate but leave the OPC Client-Application and OPC Server-Device communications open since this depends on the Application and Devices being used.
OPC 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.
MadeFor 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.
Figure 4: Multiple Applications using OPC to communicate with a Device without directly using its native protocol. The OPC Server for BACnet utilizes the BACnet protocol to natively communicate with the BACnet Device.
Figure 5: OPC Servers allowing all the applications to get data from each device without having to know each device’s native data format or protocol.
Please visit www.matrikonopc.com for more information
Did you enjoy this great article?
Check out our free e-newsletters to read more great articles..Subscribe