IEC 61131-5

Providing User Oriented Communication

Eelco van der Wal, Managing Director PLCopen
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 611315. This means from PLC-to-PLC, to HMI, Plant control, and even robots and CNCs. 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
1980s.) 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 Consistency
Within 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.

Connections
In 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 CPUs 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:
1. GOOD - If TRUE, the PLC (or the specified subsystem) has not detected any
problems which would prohibit it from performing the intended function;

2. 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;

3. 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
If TRUE, this attribute indicates that the PC
outputs can change the physical state of all outputs
disabled 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
If TRUE, this attribute indicates that the PC
inputs
can access the physical state of all inputs
disabled 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
If TRUE, this attribute indicates that at least
forced
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 Blocks

If 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 Blocks

Now 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 Future
IEC 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 611315 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.