Design Concepts Of FOUNDATION™ Fieldbus Products

MORIOKA Yoshitsugu¹

Field communication function is one of the elements of an enterprise information system. The information generated in field devices has been used mainly for control and maintenance management. Yokogawa currently provides hybrid field communication devices based on the BRAIN protocol for these purposes. This article describes our design concept for full-digital field communication products based on the FOUNDATION™ Fieldbus.

1. Fieldbus Center

INTRODUCTION

As a founding member of the Fieldbus Foundation and one of the companies on the board, Yokogawa Electric Corporation has contributed to the development of fieldbus specifications from the outset. Yokogawa Electric has lead the foundation by proposing the technical base for interoperability among other things. We also participated in he technical committee for the IEC international standard, the framework on which the FOUNDATION™ Fieldbus standard is based. From these meetings, we realized that a satisfactory level of interoperability could not be attained by achieving only the major standards such as the communication protocol standard and the specifications of function blocks. As a result, we have been taking part in the specifications development project of the Fieldbus Foundation, which involves defining a communication profile and common file format and developing interoperability test tools. We at Yokogawa Electric are proud to have played a leading role in this project.

The communication profile specifications specify the device classes and define a set of options, class by class. The fieldbus communication specifications include options for specifying the presence/absence of functions as well as several options for the parameter values. The communication profile specifications need to be fixed because the options adopted for devices connected to the same fieldbus must be coordinated well in order for them to be able to communicate with each other.

The common file format specifications define the format of a data file where such items as the device functions and application capacity are stated. This data file acts as a reference that enables us to identify the functions of each device and how we should set their parameters, regardless of the manufacturer of the device. These specifications are designed to achieve the interoperability necessary for system engineering.

Interoperability tests involve tests to verify whether the basic functions of field devices, mainly those relating to function blocks, satisfy the specification requirements.

FIELD COMMUNICATION IN AN ENTERPRISE INFORMATION SYSTEM

Figure 1 Enterprise Information System (Process Industry)

Yokogawa Electric believes that the typical enterprise information system in the process industry should be set up as shown in Figure 1. Field communication in this context means the function that links field devices to the system. The term encompasses not only the fieldbus introduced in this paper but also conventional hybrid communication such as that based on 4-20 mA analog transfer and BRAIN communication. Information provided by field devices via these types of field communication is used primarily to implement control functions. Since hybrid communication became popular, information on the various field device settings as well as the main information (measured values, etc.), has been used for device management and maintenance. One problem with hybrid communication, however, is that all signals except the main continuously-transferred ones (e.g., process value and manipulation output value) are comparatively slow and the communication method varies from manufacturer to manufacturer. Another problem is that the main signals are 4-20 mA signals and, therefore, can only be transferred one signal at a time, thereby creating a communication bottle neck.

The FOUNDATION™ fieldbus (hereinafter simply referred to as fieldbus) is the fully digital communication protocol that almost all field device manufacturers either support or plan to support in the future. Two or more field devices can be connected to each fieldbus. Fieldbus is best characterized as a mechanism that enables a great amount of information to be exchanged at high speed, while also guaranteeing fixed-interval data transfer (i.e., scheduled communication) of the main signals used with the control functions. In addition to this feature, the fieldbus allows two or more main signals to be transferred periodically. Consequently, even multi-variable field devices can be connected to the fieldbus using a small amount of cable.

Auxiliary information obtained from field devices via field communication makes it possible to centrally and remotely manage and maintain field devices, as well as the overall plant itself. Previously, we experienced a great deal of difficulty in our attempts to systematically and directly link device management functions with field devices, even though these functions exist as part of the enterprise information system. This is however now possible.

Yokogawa Electric intends to propose and build systems capable of both hybrid and fieldbus communication and thereby enabling the user to effectively manage field information. We also intend to include hybrid communication in any device management system or other system to be built in the future. In the following section, we will discuss our main design concepts during the course of the development of fieldbus products.

DEVELOPMENT OF BASE TECHNOLOGIES

Figure 2 Configurator Using Common Files

The base technologies for field devices include a transceiver circuit known as a medium attachment unit (MAU), a fieldbus communication interface IC, and fieldbus communication software. These technologies are commonly used for a variety of field devices.

The objectives for the development of the communicationpurpose ICs, were:

1. to make it possible to interface with various types of microprocessors; and
2. to minimize the frequency of interruption.

More specifically, the IC is designed to be able to support Inteland Motorola-compatible interfaces. In addition, it is provided with a FIFO (first-in/first-out) buffer that is large enough to accommodate most PDUs (protocol data units), as well as a DMA (direct memory access) function. These features keep the requirements for immediate response to the microprocessor to a minimum.

Communication software for use in field devices should be structured to provide especially high performance since the throughput of a microprocessor is limited in most cases. The performance of communication processing depends on two parameters: the processing time for immediate response and the response time at the application layer (FMS) level. The processing time for immediate response is represented directly by the minimum response time V (MRT) . Thus, this communication parameter affects the performance of the whole fieldbus segment to which the device in question is connected. In other words, the software must wait for as long as the amount of time of the greatest V (MRT) among all of the connected devices' V (MRT) , before it can send out the subsequent PDU.

The response time at the FMS level is a performance factor for the device in question; it does not affect the communication performance of the whole segment.

Another performance factor accompanying communication software for host devices is the concurrent processing function. More specifically, it is possible to acquire data more efficiently if communication requests at the FMS level can be issued concurrently to multiple field devices.

As discussed above, the development of these base technologies involved careful consideration of their performance as well as their ability to support a variety of devices' internal structures. This approach was taken due to the fact that the technologies are common to all field devices.

CONTROL SYSTEM DESIGN

Figure 3 Operation and Monitoring of Function Blocks within Field Devices

We have designed a control system that continues to carry out the conventional methods of system engineering and operation smoothly while at the same time, handling a fieldbus system for control purposes.

It is also necessary to enable the user to establish an engineering scheme that can be applied to multi-vendor field devices with no field devices actually connected. To realize this, we devised and proposed a concept of "common files" to the Fieldbus Foundation and defined the specifications for resource and value files. Our engineering tool has been developed utilizing to these specifications.

Figure 2 shows how the configuration using common files, works. Once an engineer defines the device and function block configurations, the configuration software refers to the vendorsupplied resource file to complete the configuration. The resource file contains all of the parameters necessary for configuration, including the types and number of function blocks of each device and their execution time, as well as each device's number of communication ports, minimum response time, and so on.

Using the functions of our existing control station, we materialized a completely new concept known as "function blocks within a field device" for fieldbus technology. This approach has enabled us to execute fieldbus-based system operation by using exactly the same human-machine interface as that which was used in conventional instrumentation. Figure 3 shows how the function blocks within a field device are operated and monitored. Using a faceplate block in a field control station (FCS), the AI, PID, AO, and other parameters of each function block within a field device, can be handled in the same way as those in a control loop of the FCS.

In order to enable any prospective new field-device function, we must prepare both engineering tools that can interpret the Fieldbus Foundation's common file specifications as well as applications that can interpret device descriptions (DD). Tools compliant to these specifications have been developed as separate software modules so that they can keep up with future specification requirements without delay.

In fieldbus communication, a system is constructed by connecting devices from multiple vendors. Interoperability is therefore required in every aspect of system operation. This means that consideration must be not only given to communication during system operation but also to the exchange of information between the field devices and host applications during system engineering and maintenance. In early field trials, the focus was on the verification of interoperability during system operation. Future field trials, however, must encompass the Fieldbus Foundation's communication profile, common file format and device description specifications in order to verify the interoperability of information exchange during system engineering and the handling of maintenance information, particularly device parameters unique to the manufacturer of that device.

CONCLUDING REMARKS

The fieldbus is a new technology designed to enable a combination of products from multiple vendors to be used together. Consequently, it is an urgent necessity for us to establish what the required engineering methodology is. Other issues that are important for achieving better system performance include improvements in device performance, as well as effective use of the fieldbus in our system engineering. We plan to develop more userfriendly tools based on this recently developed configuration tool.

We believe that fieldbus technology will become more and more popular as application technologies, such as increasingly advanced and multi-functional field devices and system design tools, influence each other like dependent parts. As with the earlier spread of DCSs, the future of fieldbus technology depends on the research efforts made by manufacturers and users.

• CENTUM is a registered trademark of Yokogawa Electric Corporation.

REFERENCES

1. Kai Tadamichi., "Fieldbus Fundamentals Handbook," Ohmsha, pp. 128 (1995).
2. "FOUNDATION™ Fieldbus Specifications," Fieldbus Foundation (1996).
3. IEC 1158, "Fieldbus Standard for Use in Industrial Control Systems," International Electrotechnical Commission, (1993).
4. ISA-S50, "Fieldbus Standard for Use in Industrial Control Systems," Instrument Society of America, (1992).
5. Tomita S., et al. "Standardized File Exchange Eases Fieldbus Interoperability Design," InTech, Volume 44, No. 3, pp. 46-49 (1997).

OVERVIEW OF THE FOUNDATION™ FIELDBUS

Figure A Building Blocks of a Fieldbus System

The components of the fieldbus system include field devices, fieldbus cables and host equipment. Figure A illustrates the fieldbus system, highlighting the role of the typical applications of host equipment and the fundamental technologies, i.e., the common file (RF) and Device Description Service (DDS) function. These applications may be installed in just one host equipment unit. The field devices, such as sensors and actuators, contain function-block applications. The Fieldbus Foundation defines ten typical function blocks. As field devices advance, the definition list will very likely grow to include many more different types of function blocks.

Figure B is a schematic representation of how fieldbus communication works. The black line segment represents "transmitting," the gray line segment "receiving." The LAS (link active scheduler), which is a function defined for the data link layer, manages the right to use the bus, segments, etc. Normally, the LAS function is installed in host equipment. In the fieldbus system, process data communication is carried out under the control of this LAS function at a fixed interval and in synchronization with the execution of function blocks. Communication based on the publisher-subscriber model using compel data (CD) and data transfer (DT) shown in Figure B (the leftmost section) belongs to this class of communication. In contrast, such types of communication as those where the host equipment applications read the data within field devices are called ondemand communication. This type of communication is controlled using a token (called a delegated token because the node that receives the token always returns it to the LAS function) and carried out during periods of no periodic communication. Figure B (the middle section) illustrates how the host requests devices 1 and 2 to send data and the devices respond to the host. Since the devices in this example take some time before they can set up data, they fail to respond to data when they first receive the token. They do respond successfully when the token is passed to them the next time though. The figure (rightmost section) gives three examples of management-purpose communication:

1. the examination of the recovery of nodes using the Probe Node (PN) frame,
2. the publication of the data link time using the Time Distribution (TD) frame, and
3. the publication of the system time by the system management function of the host.

The figure shows major instances of steady-state communication only; there are however several other dedicated communication frames defined for the startup of a segment and other purposes.

Figure B Typical Communication Frames on the Fieldbus