Within the full set of the international IEC 61131 standard, part 5 deals with communication. As such it is approved as Standard in 2000, and is available at IEC or at the local representations (adres info).
This part 5 describes the way PLCs can communicate to each other. A PLC as used in the context of IEC 61131 may be a real controller or a SoftPLC or any device which supports the programming languages of IEC 61131-3 and the communication defined in IEC 61131-5. This means from PLC-to-PLC, to HMI, Plant control, and even robots and CNC’s. Even it can provide communication to intelligent devices via a fieldbus. However, it does not include distributed control or communication to simple I/O devices via a sensor / actuator level bus or fieldbus.
The IEC 61131-5 describes the communication services from the point of view of the programmer and/or user. As such it is a application program interface for PLC communication. For this it provides communication services in the form of functions combined with the concepts and elements of the IEC 61131-3 programming languages. This means also that it lies on top of the ISO/OSI stack. Otherwise stated, it lies on top of the layer 7 – application layer. As such it really provides services to the users – they do not have to write the code by themselves, nor to worry about how it is done. This matches the high user friendliness of the IEC 61131-3 Function Blocks.
IEC 61131-5 does not describe a communication bus-system – it defines independent services at a higher level, which can be used in existing communication networks and systems. Pre-requisite for these systems is that they support connections, access to variables and message services, as well as the loading of large data sets. Also, this standard contains the mapping onto ISO/IEC 9506-1/2 (MMS, Manufacturing Message Specification, as a result of the MAP, Manufacturing Automation Protocol, initiative of General Motors in the 1980’s.) and onto ISO/IEC 9506-5 (PLC Companion Standard). Other communication systems based on other standards or de-facto standards may be used as communication subsystems for IEC 61131-5 too. Example of these are EN 50170 (Profibus FMS), and EN 50170 – 3 (Sub MMS), which is currently under definition.
Data ConsistencyWithin IEC 61131-5 data consistency is guaranteed. Nevertheless inconsistencies can occur when the application program is interrupted by a higher priority task, for instance an alarm function. If this function changes the data under communication, an inconsistent set can be created. In this case the user has to take measures to guarantee that the data areas used to send or receive the data values shall not be used during the time that the function blocks are busy.
If one transfers larger sets of data at once with the function blocks BSEND / BRCV, one has to be aware of the effect on the reaction time of the system. One way is to divide the large set into smaller units, as part of the application program.
For user, like application programmers, the combination of IEC 61131-3 and –5 is of course the most natural.
ConnectionsIn IEC 61131-5, the communication itself is done via communication connection. These take care that Client and Server can find each other and understand each other, or change the role of client and server. The data are transmitted between instances of the IEC 61131-5 function block. The user does not have to worry about how: it is contained in the function blocks, and normally hidden. In the application program, the sending function block has a variable set of inputs with the data to be sent (SD_i). Via the communication system these data set is send to the corresponding receiving side, and made available to the other application program via the outputs (RD_i). Of course both data-types of SD-i and RD_i have to match. Please note that the implementation of flexible number of inputs and outputs at run time (expandable FBs) is very difficult, and will not be seen often in praxis – fixed length is preferred by the supplier.
With this set, not only 1-to-1 connections, but also 1-to-n connections multi-cast) as well as 1-to-all connections (broadcast) can be supported (if the communication system can support it). With these last two, the Publisher-Subscriber model is supported, besides the standard Client-Server model.
Connection can be made within a system, for instance between different CPU’s in one PLC, or between different tasks on a SoftPLC, or between different PLC applications. All communication service of IEC 61131-5 need connections. In most cases these are constructed and maintained in an implicit way, meaning that no coding in the application program has to be done for this. This is what is meant with the functionality lying above level 7, application layer, of the OSI/ISO stack.
Figure 1: - Programmable Controller – Communication Model (subset)
Figure 2: Programmable Controller hardware model
IEC 61131-5 has defined an extensive set of status information on the hardware itself. This means that for the user this part is covered by the standard itself, and needs no additional coding. The hardware model (conform IEC 61131-1 and –2) identifies seven entities (units, modules or subsystems) per PLC. These entities which are can present status information are (see figure 2):
| No. | Status presenting entities |
| 1 | PLC (as a whole) |
| 2 | I/O subsystem (includes I/O modules and other intelligent I/O devices) |
| 3 | Processing unit |
| 4 | Power supply subsystem |
| 5 | Memory subsystem |
| 6 | Communication subsystem |
| 7 | Implementer specific subsystems |
The status is intended to provide information about the controller including its hardware and firmware subsystems, not considering configuration information. It is not intended to provide information about the controlled process nor the PLC application program. The status data contains information concerning the state and the health of the PLC and its subsystems.
There are two concepts used in this part of IEC 61131 related to status: health and state. The "health" of a PLC or its subsystems is specified by returning one and only one of the three possible values. The semantics associated with each value is specified below. They are, in order of decreasing health:
- GOOD - If TRUE, the PLC (or the specified subsystem) has not detected any problems which would prohibit it from performing the intended function;
- WARNING - If TRUE, the PLC (or the specified subsystem) has not detected any problems which would prohibit it from performing the intended function, but it has detected at least one problem which could place some limits on its abilities. The limit may be time, performance, etc;
- BAD - If TRUE, the PLC (or the specified subsystem) has detected at least one problem which could prohibit it from performing the intended function.
Each of the status information can also have implementer specified attributes.
For instance, for the I/O subsystems the following summary status information has been defined (Table 1). Similar sets have been defined for the PLC, the status of the processing units, power supply, memory, communication subsystem, and implementer specific subsystems. This covers all entities, and takes this part out of the hands of the users. Also, the representation of the status information is defined.
| No. | Item | Description |
| 1 | Health | GOOD | indicates that there have been no errors detected in this I/O subsystem |
| 2 | | WARNING | indicates that a minor fault has been detected in the I/O subsystem. An example of a minor fault is the occurrence of recoverable errors in the communication with a remote I/O station |
| 3 | | BAD | indicates that a major fault has been detected in the I/O subsystem. An example of a major fault is losing communication with a remote I/O station |
| 4 | No outputs disabled | If TRUE, this attribute indicates that the PC can change the physical state of all outputs associated with the specified I/O subsystem as a result of application program execution or other means. If not TRUE, the physical state of some of the outputs is not affected (logical state may be affected). This is typically used in the testing and modifying of application programs in the PC |
| 5 | No inputs disabled | If TRUE, this attribute indicates that the PC can access the physical state of all inputs associated with the specified I/O subsystem as a result of application program execution or other means. If not TRUE, the physical state some inputs cannot be accessed. This is typically used in the testing and modifying of application programs where the inputs can be simulated |
| 6 | I/O forced | If TRUE, this attribute indicates that at least one I/O point associated with this subsystem has been forced. When an Input is forced, the application program will receive the value specified by the PADT instead of the actual value from the machine or process. When an output is forced, the machine or process will receive the value specified by the PADT instead of the value generated by execution of the application program |
Table 1: Status of the I/O Subsystem
In addition, the functions which a PLC provides to a control system using the communication subsystem have been defined. This means a complete set for the communication function: device verification, data acquisition, control, synchronization between user applications, alarm reporting, connection management, program execution and I/O control, and application program transfer. This means that the features are defined, and the function blocks (except for the last two) are available.
Programmable Controller Function BlocksIf you have reached this point, you noticed that the IEC 61131-5 standard does not only cover some communication functions or function blocks. But of course, they are defined too. And they are well defined all function blocks include timing diagram, state diagram and the corresponding transitions. The following FBs are defined (Table 3):
| Application specific functions | Name of communication
function block or function |
| Addressing of remote variables | REMOTE_VAR (function) |
| Device verification | STATUS, USTATUS |
| Polled data acquisition | READ, |
| Programmed data acquisition | USEND, URCV, BSEND, BRCV |
| Parametric control | WRITE, |
| Interlocked control | SEND, RCV |
| Programmed alarm report | NOTIFY, ALARM |
| Connection management | CONNECT |
Table 3 - Overview of the communication function blocks
Most of them are clear, but others need some additional information:
Device verification: FBs STATUS and USTATUS
A PC can request a remote communication partner to send back to it its status information using the STATUS function block. A PC can itself enable to receive status information of a remote communication partner using the USTATUS function block.
Programmed data acquisition: FB USEND / URCV and BSEND / BRCV
For the programmed data acquisition, there are two pairs of FBs defined. The difference between these pairs of function blocks lies in the way they operate.
The FB pair USEND / URCV transmits a set of variables between a pair of instances of USEND/URCV or between one instance of USEND and many instances of URCV. In the application program, USEND has a variable set of inputs with the data to be sent (SD_i). Via the communication system these data set is send to the corresponding URCV, and made available to the other application program via the outputs (RD_i) of URCV. Of course both datatypes of SD-i and RD_i have to match.
BSEND/BRCV are used for the transmission of a data buffer, with length as specified in the application program. The number of bytes to be transferred can dynamically be set via one input parameter. This makes this function block flexible in its usage. The communication system may use segmented transfer to transmit larger amounts of data. The user does not take care of that: segmentation is hidden inside the function block or the communication system. Of course the user has to take care of the data consistency, he shall not use the data buffers during the function blocks are busy.
Parametric control: FB WRITE; Polled Data Acquisition: FB READ
This combination to read and write data are used in 1-to-1 connections only. The application program requests if and when the data shall be read or written.
Two kinds of variables in the PLC may be used with READ and WRITE:
1. Directly represented Variables with direct representation
2. Other variables which have Access paths (See IEC 61131‑3 for the definition of access paths)
If the directly represented variables are accessible these variables shall use the direct representation as an identifier. The PLC which own the variables can interpret the identifier using an implementer defined algorithm. The PC system may restrict access to variables with direct representation.
Interlocked control: FBs SEND and RCV
The SEND instance requests the RCV instance to execute an application operation and to inform the SEND instance of the result of the operation. This has two aspects, the synchronization of the application program of the SEND and RCV instances and the exchange of information between them. This function can be used to have the effect of a remote procedure call from one application program to another.
Programmed alarm report: FBs NOTIFY and ALARM
A PC can be programmed using the ALARM function block to report an alarm message with an acknowledgement capability. Or, it can be programmed using the NOTIFY function block to report an alarm message without an acknowledgement capability.
Connection management: CONNECT
Connections are controlled explicitly by the application program using the CONNECT function block or are provided by the communication subsystem if and when needed. This communication function block allows to establish a connection between the calling communication partner and the remote communication partner. The remote communication partner is identified using its name. A communication channel to the remote communication partner is defined. The remote communication partner shall decide whether or not to establish the connection.
Consistent semantic of the Function BlocksNow concerning the function blocks, first of all the semantics are defined, meaning that they all use a common semantics to their inputs and outputs as far as possible (see Table 2).
| Parameter name | Data type of the parameter | Interpretation |
| EN_R | BOOL | Enabled to receive data |
| REQ/RESP | BOOL | Perform function on raising edge |
| ID | COMM_CHANNEL | Identification of the communication channel |
| R_ID | STRING | Identification of the remote FB inside the channel |
| SD_i | ANY | User data to send |
| VAR_i | STRING or data type of the output of the function REMOTE_VAR | Identification of a variable of the remote communication partner |
| DONE | BOOL | Requested function performed (good and valid) |
| NDR | BOOL | New user data received (good and valid) |
| ERROR | BOOL | New non-zero status received |
| STATUS | INT | Last detected status (error or good) |
| RD_i | ANY | Last received user data |
Table 2: Semantic of communication FB parameters
Additional information to table 2:
The ID input references the communication channel used by the instance of the communication function block, i.e. it determines the remote communication partner. The ID input is of COMM_CHANNEL type which shall be implementer defined.
The R_ID input is used to identify the corresponding instance of the communication function block at the remote partner, if the PLC communication function is provided by a corresponding pair of function block instances. One instance of a communication function block shall use the same communication channel and communicate to the same corresponding remote function block instance throughout its whole lifetime.
The variables to be read or written are identified using the VAR_i inputs of the READ and WRITE function blocks. The actual parameter is typically a string which contains the name of the remote variable.
Additionally the VAR_i parameter may also have an implementer defined data type named VAR_ADDR. A function REMOTE_VAR is defined to generate the access information for nested variables.
An example with timer in Function Block Diagram:
 The FutureIEC 61131-5 combines communication over different networks with a common user interface. By hiding much of the complexity, it provides an easy to use and neutral interface. With currently many different communication solutions and systems, IEC 61131-5 can help to harmonize this wide variety at the software level. This brings the user many advantages, very much like IEC 61131-3 programming languages did and does.
At the moment only a limited number of suppliers support this part of IEC 61131. Partly this is because the standard became available as an official standard only recently. Since IEC 61131-5 can cooperate with many different networks, implementations can be done in parallel, providing a standard communication to the user a across different networks. For instance, lying on top of TCP/IP based networks.
The same is valid for OPC, OLE for Process Control. This uses ActiveX and DCOM objects and methods for reading and writing of process variables. At the next level, additional functions have to be defined. IEC 61131-5 certainly can help here to create efficient communications to the PLC world.
The overall effect of IEC 61131-5 is still unclear. Although it provides a solid basis, the number of implementations has to increase dramatically. User demands certainly will play a role here. This article may push the use of IEC 61131-5. For user, like application programmers, the combination of IEC 61131-3 and –5 is of course the most natural.
Further reading:PNO publication - PROFIBUS Communication and Proxy Function Blocks according to IEC 61131-3, check http://www.profibus.com/downloads.html | 
|
