OPC, Modbus and Fieldbus, Oh my!

When dealing with enterprise integration, do you ever get the feeling you’re wandering alone in an unknown landscape, filled with strange people and having to make tough decisions? Manufacturers are faced with a multitude of protocol choices; OPC, Modbus, Profibus, BACnet, Foundation Fieldbus… the list goes on. It would be nice to just click our heels three times and have all integration issues solved. The reality is that it is not simply a choice of one protocol versus another. It requires integrating multiple complementary protocols, each with individual strengths, to achieve the goal of a true enterprise system.

Although the physical setup of manufacturing or process automation systems varies greatly, the majority can be represented by a three-tier architecture consisting of the Control, Operations and Business layers. The Control layer represents low-level data transfer and control. The Operations layer generally includes software products such as visualization and supervisory applications, data storage, calculation and other automation packages. The Business layer represents higher-level visualization and reporting packages, decision support software, advanced analysis and web-based applications.

Just as Dorothy and her companions each had unique characteristics; there are distinct connectivity requirements between tasks performed by applications in the multiple levels of the enterprise hierarchy (See Figure 1 below). The protocols used with each layer, and to create interoperability between the layers, need to be optimized for different applications.

Heart of the Matter
The heart of any industrial process is the communications network between the transmitters, controllers and other control and measurement devices. The key requirements of this network layer are robustness, determinacy and compatibility. The evolution of a standard digital communication protocol for the process control network has been a long and bumpy road. The goal was to move from many vendor-specific and proprietary protocols towards an independent fieldbus standard that could be supported by multiple vendors. Many delays, bus wars and organizational body changes eventually resulted in the development of the IEC 61158 Fieldbus Standard. This actually represents several different standards with common requirements, including Profibus, Foundation Fieldbus, WorldFIP and others. Even with the 61158 Standard, choosing a single implementation for this level can be as difficult as dealing with flying monkeys. Regardless of what standard or protocols are chosen, interoperability with the rest of the enterprise hierarchy is an important factor.

Part of Courage is Simple Consistency
Modbus is often classified as a fieldbus protocol but with its various enhancements, particularly Modbus TCP, it has an even wider range of communication applications. One of the reasons for its proliferation is that Modbus is simple and hardy. In comparison to some other protocols, it is not sophisticated but gets the job done. As a straightforward protocol, it is generally easier and faster to code, apply, and troubleshoot than other more complex interfaces. For this reason the serial versions of the Modbus protocol have long enjoyed a position of market leadership. Its simple consistency has also led to a rapid acceptance of Modbus TCP as an Ethernet-based communication protocol. It goes without saying that with simplicity comes limitations which can cause issues when connecting higher-level applications. Extended data-type support, mapping logical object structure, and true peer-to-peer type architectures are some examples of higher-level functionality enterprise systems require. It sometimes takes courage to implement a more complex protocol in order to meet the needs of the whole system.

Brains of the Operation
If the Control layer is the heart, then the Operations layer is the brains. The Operations layer contains the applications that transform data into useful information and knowledge, and bridges the lower and higher hierarchies. Organizations need large amounts of data, quickly, derived from multiple sources and delivered simultaneously to many destinations. To achieve the benefits of flexible, scalable and interoperable systems, without high integration time and costs, the protocol for this level should be standardized across multiple vendors, systems and products. These characteristics make OPC an ideal choice for connecting this layer, as well as for integration with the other levels. OPC offers separate specifications to address different data semantics, including real-time data, historical data, alarm and event information and batch data. The interfaces are comprehensive enough to provide the functionality users require, yet simple and practical to implement, which results in wide vendor acceptance. This includes the availability of OPC products for complementary protocols such as Modbus, Profibus, Foundation Fieldbus, DeviceNet, HART, and many others.

The Business at Hand
The trend at the Business layer, as well as parts of the Operations layer, is towards open interfaces and web- or service-based technologies. Applications at the higher level are concerned with consolidating information from various sources and compiling it into reports and summarizing them into key performance indexes and other decision-support metrics. Therefore it is important that there be easy access to the all the underlying sources to allow for aggregating and analyzing data across multiple functions and applications. Early speculation is that OPC UA will be the protocol of choice for integration of the Business layer. OPC UA provides a rich information model and standardized messaging which will provide interoperability between the various event processing and automated analysis applications. Also, any cross-enterprise management system must be scalable and secure. All aspects of the OPC UA specifications have been designed with both robust security and a wide range of scalability in mind.

OPC UA – The Great and Powerful…
Because all protocols, when boiled down to the basics, represent moving data between applications, there are those that want to elevate one protocol to replace all others. Already there are many discussions and forums touting one protocol versus another. It is inevitable that there will be those that will try to make OPC UA out to be the Great and Powerful Oz. A protocol able to solve all the world’s integration problems with its magic abilities. The reality is OPC UA is not designed to replace every protocol from all levels of the enterprise. What OPC UA aims to do is provide interoperability to all levels, which means it will complement application-level protocols and other industry specific standards, including ‘classic’ OPC. Just as the Wizard of Oz helped the companions realize the potential they always had within themselves, OPC UA is designed to unify the power of existing applications.

This Side of the Rainbow
As industry standards evolve and strengthen, those with wide adoption and proven interoperability will continue down the road of enterprise integration while others will simply melt away. System architectures will always involve a selection of protocols and standards. The key is choosing complementary protocols offering the best interoperability options. Those who believe otherwise must be dreaming.

Eric Murphy, BSc, PEng (Alberta), is a chemical engineer with a process control specialization and an OPC expert. Eric has been a part of the OPC community since its early beginnings in the mid-1990s. He is heavily involved with the OPC Foundation and currently acts as the chair for the OPC Historical Data Access (HDA) working group. Eric is also a member of the OPC Technical Steering Committee (TSC) and an active member of the OPC Unified Architecture (UA) working group. Visit Eric at his Blog, the OPC Exchange, to follow the latest trends and discussions about OPC technology, or click here for free downloads.