You want to integrate your operations with a network, but which protocol do you use? There are so many choices-and few are compatible with other standards. The answer is an open system, but does the beast exist?
The world of industrial automation has seen the emergence of a long line of buses and consortia that focus on providing interoperable solutions and open architectures, and yet the average users or implementers are still isolated on islands of individual protocols.
Why is this? Is what you see today the best you can hope for? What should you realistically expect from an open system, and how might it be delivered?Open Systems
The IEEE defines an open system as one that provides capabilities that enable properly implemented applications to run on a variety of platforms
The domain of a system is defined by the set of components and the types of functions the system addresses. The components and functions help identify the problem addressed by the system. The components define the magnitude of the system, and the functions provide the scope of complexity.
For example, if you look at a typical fieldbus system, its components include field devices, gateway nodes, configuration nodes, and a communication and power supply infrastructure. The scope of the functions achieved by a fieldbus is usually easily mapped into the layers of the OSI seven-layer model because fieldbus functions are communication oriented. In some cases, these include providing power to field nodes. But all fieldbus systems support mechanisms for shared access communications among components and transportation of user messages among components.
The domain of an open system does not have be confined to a single bus or protocol stack. In fact, if you look at a typical industrial automation system, you realize that the scope of the components of the domain is larger than the scope of a typical bus or protocol specification. The limited view of what constitutes an open system is the root of some of the problems encountered today. Vendors have achieved openness within a set of protocol specifications, but this is not an open system because the various specifications are largely incompatible with one another.
Similarly, the functions of a typical industrial automation system cannot be limited to a single bus or protocol stack; a true open system must allow components to interact with one another across various buses. The functions required by automation systems fall into layers of abstraction: they deal with aspects of the problem in different degrees of detail. These layers of abstractions are related to each other in that concepts and models used to describe functions in one layer have natural refinements (i.e., models with greater detail) or abstractions (i.e., models with less detail but greater scope) in layers lower or higher in the hierarchy.
As with the OSI Reference Model, the layers indicate changes in the abstraction used to deal with applications in the system at that level. For example, at the lowest layer, you deal with the physical world in terms of measurements and actuation. You cannot express the functionality of an intelligent node in these terms; you have to define a more refined model at a higher level of abstraction within which measurements and actuation play a defined part.
Looking at a typical system model, you quickly identify four layers of abstraction: the process connection level, the distributed intelligence level, the application level, and the enterprise level. At the process connection level, elements of an open system interact as measurements and actuation. In process control, for example, these are typically expressed as 420 mA inputs or outputs; in manufacturing they are digital inputs and outputs.
At the distributed intelligence level, interaction is between components of functionality (e.g., tasks or programs). Typically modeled as function blocks and expressed in a broad range of forms (e.g., ladder logic, structured text, or graphical programming languages), the components are used to construct control and sequencing operations to orchestrate the underlying process hardware.
At the application level, the interaction is among components of a framework (i.e., a basic structure of software components that work well together and can be used in a mix-and-match fashion to meet particular customer needs). Frameworks are typically tuned for applications, such as control, diagnostics, and asset management. An example of this in the control area is the growing appearance of "open control" packages, which provide such functions as alarming, trending, history, and life-cycle management.
Finally, at the enterprise level, the abstraction changes from the continuous process-oriented view to a transaction-oriented view represented by enterprise resource planning packages, such as SAP and Baan. Here the problem shifts from maintaining a flow, level, or temperature at a set point to the concepts of a batch and meeting a customer order.
These abstractions must have consistent refinement relations. This means that it should be possible to build each layer cleanly and consistently in terms of functions and concepts developed at the immediately lower level of abstraction. This allows concepts to be mapped between levels and clear interfaces to be developed, both of which are vital if the characteristics of an open architecture are to be achieved.Open Architecture
The structure and organization described is actually the outline of an open architecture. The IEEE defines an open architecture as "a specification of capabilities or services that provides the interconnection structure and defines the interface between interoperating components." It would have:
Why isn't there an open architecture that defines an open system in industrial automation? Surprisingly, the answer is technological progress. The evolving industrial automation environment, with the shift to bus-based architectures and intelligent field devices, has actually made it harder to reach the ideal of an open system. For example, the common abstraction of the 420 mA signal and the 15 V measurement has been overtaken by the different models and perspectives put forward by various protocol groups.
To move closer to achieving an open system, the industry must look at the problem not as one of communicationsas the current set of buses and protocols dobut rather from the perspective of an application. By focusing on common application models, the industry can develop an architecture that enables application portabilitythe ability to have applications run across multiple buses and platforms. This will close the circle on user expectations established by simpler solutions.
The problem would be a lot less critical if there were one unifying communications architecture on which to build (i.e., if there were a common bus). However, different protocols have established natural strongholds in different applications. For example, looking at four typical application areas, the dominant protocols are: HVACLonWorks; ProcessProfibus PA and Foundation Fieldbus; DiscreteDeviceNet, SDS, and Interbus S; Motors/DrivesSercos.
It's clear now that, despite the hopes of vendors and consortia, no single bus will become dominant. You must therefore deal with the increased integration problems that result from the complexity introduced by the various buses and the need for supporting multiple buses.
This problemusually (and somewhat incorrectly) termed the interoperability problemhas been partially addressed in several ways. Individual networks achieve varying degrees of interoperability within their own solutions, but these individual network approaches are consistently incompatible with one another, thus failing to provide a true open architecture.
Several vendors achieve limited multiple network interoperability and open architecture by offering multiple network interfaces on their product to permit integration with a customer-chosen architecture. They do this by mapping application functionality into common registers or shared memory. The information is easily translated into various bus protocols because of the limited functionality and the simplicity of the translation. This approach works well for simple I/O but less satisfactorily for smart devices, which have some capabilities that are difficult to express in terms of reads and writes of memory locations.
Initially, interoperability was achieved through profiles, specifications of implemented behavior and functionality. Profiles are largely network and application specific. For example, even a simple measurement (e.g., temperature) is sometimes represented and accessed differently, even on the same bus, depending on the measuring device. This concept was extended through the concept of standard variables and functions exemplified by the HART protocol and by descriptive languages. Some of these languages are custom made, such as those for Profibus PA (GSD files), HART (the HART Device Description Language), and the Foundation Fieldbus (Foundation Fieldbus Device Description Language). Some are generic, such as attempts by NEMA ICS 12.
Current efforts are based on the recognition that these approaches are insufficient. What is needed are new techniques based on standard models that separate device and implementation from function. In this way, representation and access to a temperature measurement are independent of the bus or device on which temperature is being measured. Making this separation is key to being able to define a multinetwork open architecture. Early attempts were network specific, as exemplified by SDS, DeviceNet, and LonWorks. A significant step forward was the extention from models that were specific to a given protocol to models that were specific to a given application area (usually called domain-specific models) in the Semiconductor Manufacturing Technology consortium common object model.
The IEEE/NIST family of specifications is a first step in solving the larger problem of creating an overall open system and architecture. The specifications address the bottom level of abstractions in the automation hierarchy at the process interface and distributed intelligence level. They were chosen because they could deliver value most rapidly at this level. This is possible because the functionality is relatively restricted, and it is desirable because there is a need for a firm foundation before addressing the upper levels. The IEEE/NIST specifications are based on the premise that interoperability/ open architecture solutions must address multiple plant floor devices and use multiple networking technologies to deliver value to the customer and realistically address the industrial automation market.
Jay Warrior is Chairperson of the IEEE P1451.1 working group, which is drafting a network-independent interface specification for smart transducers. He can be reached at Jay_Warrior@hpl.hp.com More information about the IEEE/NIST 1451.2 standard and the 1451.3 and 1451.4 working groups can be obtained from Kang Lee at NIST at Kang.Lee@nist.gov