New intelligent plant sensors and actuators are now appearing in the industrial automation arena that combine built-in processing capabilities with standard communications interfaces; such devices are now known collectively as ‘Fieldbus’ devices, even though they may not all use the same communications standards. In fact, the IEC has been developing a multi-part Fieldbus standard under the designation of IEC 1158 for a number of years. The IEC Fieldbus standard is planned to cover the complete ISO communications stack from the physical to
Figure 6.10 Conveyor test station distributed FBD
QualData Resource 2 INIT RSP Q1 ID SD_1 INIT0 IND QO STATUS RD_1 SUBSCRIBE FB_Sub1 #TRUE #ADDR_1 COLD WARM STOP E_RESTART INIT Feed INIT0 OK Feed FB_Feed1 Running OnBelt InitI Check OnBelt Parms INIT0 Done Pass Count FB_QualStation1 QualStation Identify QualData #Parms InitI Save Stored Done FB_Inventory Inventory InitI Run Running INIT0 OK OffBelt FB_RollOff1 RollOff Pass Pass Pass Identify Count INIT REQ Q1 ID SD_1 INIT0 IND QO STATUS RD_1 PUBLISH FB_Pub1 Initl Stopl INIT0 EXO Running DriveCntl FB_DriveCntl1 #TRUE #ADDR_1 Init Stop Exec FB_Exec1 Resource 1 FB_Start1
application protocol layers. It is intended as a global standard that will allow sensors and actuators from different vendors to be both compatible at a physical level, i.e. by having standard plugs and sockets, and software compatible, i.e. new replace- ment devices from different vendors can be automatically re-configured to operate in an existing system. It should be possible to build a system using I/O devices from different vendors that interoperate at all levels. For example, it should be possible to remove a pressure sensor produced by vendor A and exchange it for a device from vendor B and the system software should be able to automatically adapt and remain operational.
IEC 1158 is not yet an agreed international standard but parts are becoming fairly stable. At the physical layer, the IEC 1158 standard defines a variety of different options for the physical communications media and data rates. Figure 6.11 shows some of the physical cabling and data rate options in IEC 1158-2; there are also wireless and fibre optic options defined in the standard. Unfortunately, this standard has been a long time in development so that a variety of alternative proprietary Fieldbus solutions are now emerging in the marketplace, e.g. using Siemens Profibus, and Allen-Bradley’s DeviceNet.
It has been extremely difficult for the IEC to find a suitable compromise solution that is acceptable to all industrial nations and that also fits all types of application domains. For example, field devices used in a hazardous area of a petro-chemical plant will need to be intrinsically safe, i.e. designed for low voltage and low energy to remove risks of gas ignition; these devices will also need to react at relatively high-speed. On the other hand, field devices used by water utilities, for example, to monitor water treatment plants, will generally need to be low cost and operate over longer distances at lower data rates. Having so many conflicting requirements has resulted in a wide range of different options and solutions being defined for Fieldbus communications standards, so that interoperability of different devices at the physical level may not always be possible. Currently there is also a variety
of proprietary implementations of the Fieldbus concepts that allow devices either from a single vendor or group of vendors to interoperate.
Although a single standard for all industrial field devices is still some way off or may never be achieved, the issues regarding how to design and model systems built from networks of intelligent devices is still relevant. IEC 61499 concepts can apply to both IEC Fieldbus as well as the proprietary Fieldbus devices.
When using Fieldbus, devices are connected to a common communications medium so that data can be transferred between any two or more devices. The layout of the physical wiring arrangement of Fieldbus devices is not determined by the application. Devices can generally be cabled together in any way that is most convenient to the installer, such as in a daisy chain that minimises point-to- point cabling: see Figure 6.12. The linkage between the processing elements within each device is achieved by software by routing data between devices in such a manner as to satisfy a particular application.
Figure 6.13 shows part of an application created by linking instrumentation in different Fieldbus segments. This is part of a causticising process used to make wood pulp in paper manufacturing. Each instrument provides a ‘resource’ that is capable of executing function blocks. Each Fieldbus device may either have a built-in repertoire of function blocks or may be installed with new function blocks; for example new block type definitions can be downloaded and stored in some form of non-volatile storage within an instrument. Applications are created by configuring the software links between Fieldbus devices and, in some cases, between controllers. Where controllers are connected these will be typically Distributed Control System (DCS) work stations but other types of controllers such as PLCs may be used. With small applications, clusters of Fieldbus devices may be configured into simple applications without the need for a main controller. For example, a simple control loop could be configured by linking an analogue input instrument, such as a temperature controller, that has an on board PID block, with an intelligent valve that has an analogue output block.
The top-level functional control requirements can be expressed in terms of the function blocks that exist within the distributed instruments as shown in Figure 6.14. Blocks within clusters of instruments concerned with a specific aspect of the control can be linked into a network. The example shows part of a cascade and ratio control loop used in the causticising process. The main advantage of using Fieldbus devices is that the logical connections between function blocks within the instrumentation are de-coupled from the physical location of the instruments. It is also necessary to identify the timing relationships between the various blocks. A large number of blocks can be scheduled to run concurrently if they have no inter-dependencies. Part of the execution strategy for this example is shown at the bottom of Figure 6.14.
The next stage is to use IEC 61499 models for the various function blocks to create an IEC 61499 application. This will include the addition of service interface function blocks to provide the communications links between the IEC 61499 Resources that exist in the different instruments.
There is a proposal to develop a range of standard Fieldbus function blocks that can provide the main types of functionality required in general process control applications; these are listed in Figure 6.15. Of course, additional specialist blocks will also be required in other control domains, and instrument vendors will also be free to develop their own blocks to encapsulate proprietary algorithms or to interface with new types of instrumentation.