Distributed Control Standard Connects Industry Regardless of Bus

In the early days of modern automation, the use of microprocessor technology addressed the need for fast and efficient configuration of control logics through graphical methods that mimic the hardwired relay logics. Over the past 30 years, the automation community has put the emphasis on simplifying and standardizing the method of programming this new breed of controllers. From these efforts came the adoption of the IEC 61131-3 standard that specifies the programming languages for automation.

Fieldbus Proliferation

Figure 1: Structure of an IEC 61499 Function Block.

From the very moment that the industry started to use microprocessor-based programmable logic controllers (PLCs), the need of having these controllers to exchange information, gather data from remote units, and set interlocks between controllers initiated a quest for a comprehensive solution. Early on, the industry focused on finding or establishing communication protocols and methodologies that would be candidates for standardization. The Modicon protocol, or Modbus, was one result of an internationally accepted standard. Derivatives of Modbus such as Modbus RTU or Modbus IP are good examples of partial solutions to meet the demand from automation engineers, but standards haven't stopped there. Over time, associations and major automation vendors have proposed industrial fieldbus networks that eventually evolved into standards, such as PROFIBUS, DeviceNet, ControlNet, Fieldbus Foundation, CANbus, SERCOS, EtherCAT, Siemens H1, and many others.

Interoperability Realized

Despite a proliferation of standards, however, interoperability still lagged among differing standards. Several organizations initiated discussion on how to achieve coherent cooperation among controllers in the same application. Fieldbus Foundation, among others, addressed the format of pertinent information to be shared on the network. Yet, although the mechanism of exchanging information could be defined, the cooperation between devices was not addressed. The International Electrotechnical Commission (IEC) came up with a conceptual view of how to have independent programmable logic controllers cooperate in a cohesive and very efficient manner. By defining the IEC 61499 standard, the IEC addressed the need for a comprehensive and familiar approach to automation controllers' cooperation. Using function blocks as a visual representation of a control entity, the IEC committee redefined the methodology of creating modern control systems. Today, industrial networking software providers are building network control and monitoring applications that take this visual block approach to defining industrial networks comprising disparate field bus components that traditionally could not communicate.

Implementing IEC 61499

Figure 3: IEC 61499 Link Architecture view.

In creating an automation system, one would traditionally start by looking at individual control applications and then determine how to have these interact with each other. The advent of IEC 61499 created the structure for, among other things, a supervisory application layer that connects isolated control systems. One example of this supervisory industrial networking and control software is the ISaGRAF 5 control software environment. These programming, networking, and control environments allow the designer to define the local behavior of the control devices as well as global diagrams using the IEC 61499 environment. A library of drop-in functional blocks regulates the behaviors of the cooperating devices. Custom-made function blocks also can be dropped into the diagram to regulate the behaviors. Each 61499 function block is made of two parts (see Figure 1). The top part holds the ECC (Execution Control Chart). The IEC 61499 standard specifies that this part should be programmed using a state machine. Under ISaGRAF 5, it is programmed using an SFC (Sequential Function Chart), which happens to be an ideal state machine.

The bottom part defines the actual control function. It can be programmed using any of the IEC 61131 languages: SFC, FBD (Function Block Diagram), LD (Ladder Diagram), ST (Structured text), and IL (Instruction List). Each IEC 61499 function block is assigned to a specific resource. These resources will eventually be assigned to a given device (called configuration under IEC 61131) and one device can hold more than one resource. Therefore, an IEC 61499 diagram can span multiple resources, which may also mean spanning multiple devices. IEC 61499 helps the automation engineer to tackle a range of control challenges, from simple control challenges to very complex ones. ISaGRAF, for example, gives the engineer the opportunity to have different views over the control application and refers to these views as the Hardware view, the Resource view and the Link architecture, as illustrated in Figures 2, 3, and 4, respectively.

The Hardware view shows the physical devices on the network, in 61499 mode. It also uses icons to indicate the devices that have an established 61499 relationship, as well as which 61499 diagram regulates the relationship. By double-clicking on the diagram reference, the user can have a look at the actual diagram. An IEC 61499 diagram greatly accelerates deploying applications across an industrial network made up of proprietary devices, switches, and controllers. The 61499 diagram supersedes the implementation of individual applications on individual devices. Traditionally, an application would be implemented on individual controllers in traditional automation, interacting with each other through manually implemented data transfers or interlocks.

However, the IEC 61499 function block diagrams span over multiple devices (referred in the past as configurations or controllers) and, therefore, regulate the interaction between the various devices using a single functional diagram. By using the graphic network design environments such as the ISaGRAF 5 suite of automation tools, it is now possible to create control systems that define interactions among multiple devices. These could be PLCs, field controllers, or field instruments (flowmeter, valves, pumps etc.) with variable footprints, but all interacting in a well-defined and coherent fashion without the need for manually implemented algorithms on individual devices. With IEC 61499, the industrial control network is a seamless extension to the hardware bus on the controller, making the design of networked control systems as simple as the design of a singular PLC.

This article was written by Julien Chouinard, Managing Director, at ICS Triplex ISaGRAF in Montreal, Canada. For more information, contact Mr. Chouinard at This email address is being protected from spambots. You need JavaScript enabled to view it., or visit http://info.hotims.com/10968-402.