Glossary · Distributed automation and IEC 61499
Communication function block
Also known as: Communication SIFB, PUBLISH/SUBSCRIBE blocks, CLIENT/SERVER blocks
German: Kommunikationsfunktionsbaustein
In IEC 61499, a communication function block is a service interface function block that exchanges events and data between resources or devices, either unidirectionally with a PUBLISH/SUBSCRIBE pair or bidirectionally with a CLIENT/SERVER pair, while the protocol behind it is fixed by the device and the compliance profile.
- IEC 61499
- Standards
In one sentence
IEC 61499 communication function blocks link devices: PUBLISH/SUBSCRIBE for one-way data, CLIENT/SERVER for request and response.
Example
The filler controller sends the fill level with a PUBLISH_1 block; the labeler's SUBSCRIBE_1 block with the same ID receives it and fires IND, which starts the label check.
How it applies
- Two patterns: IEC 61499-1 defines generic communication function block types. PUBLISH_m and SUBSCRIBE_m transfer m data values in one direction: the publisher sends on the REQ event (confirmed with CNF), the subscriber issues IND when data arrive. CLIENT_m_n and SERVER_m_n form a bidirectional transaction: the client sends m values on REQ and receives n values with CNF; the server receives the request with IND and answers on RSP. The numbers in the type name give the number of data inputs and outputs (SD_1 … SD_m to send, RD_1 … RD_n received).
- Common interface: All of them follow the same service conventions: INIT with the qualifier QI starts or stops the connection and is confirmed by INITO; ID carries the connection identifier, for example an address and port or a topic, in the format the compliance profile defines; QO and STATUS report success or the error. Their behavior is specified with Service sequence diagrams, including connection loss.
- Distribution: When an application is mapped to several devices, every event or data connection that crosses a device boundary needs communication blocks at both ends. Some tools insert them automatically; others expect the engineer to place them. The choice between publish/subscribe and client/server decides whether the sender waits for an answer.
- Interoperability: The block interface is standardized, the protocol is not. Whether a PUBLISH block on one vendor's device can talk to a SUBSCRIBE block on another's depends on a shared Interoperability profile and the same ID format. Runtimes map the blocks to protocols such as UDP, TCP, MQTT or OPC UA.
- Documentation: Document each cross-device connection with the block pair, the ID (address, port or topic), the data types in order, the expected cycle or event rate and the reaction to communication loss. Device documentation should list the communication block types and protocols the runtime supports.
PUBLISH/SUBSCRIBE vs. CLIENT/SERVER
PUBLISH/SUBSCRIBE is one-way and unconfirmed across the network: the publisher's CNF only says the data were sent, and several subscribers can listen to the same ID. CLIENT/SERVER is a two-way transaction between one client and one server: the client's CNF arrives with the server's response data, so the client knows the request was handled.