IEC 61499 Hardware-Software Decoupling: How It Works

Claire Rousseau3 min read
HMI ProgrammingSchneider ElectricTechnical Reference
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

What Hardware-Software Decoupling Means in IEC 61499

IEC 61499 enables application-centric design by separating the application model from the system model. Application programming is performed independently of the underlying control devices, resources, and communications infrastructure topology — the system model defines that topology separately. The standard supports both distributed and centralized architectures.

The practical result: application logic is written once, then mapped to whatever hardware you eventually select, across heterogeneous devices, without writing communication code between controllers.

The Three Models That Enable Decoupling

Model Role
Application model Contains the control logic (function block networks). Written with no knowledge of target devices or network topology.
System model Maps and distributes one or more applications by defining which parts execute on which devices/resources.
Device/resource model Manages the connection to the process interface (sensors/actuators via the device I/O bus) and the communication interface to other devices used by the distributed application.

Combined, these models let applications be designed independently of automation hardware, distributed across heterogeneous devices with zero programming effort, and interoperate through standardized communications and data models across networks — again without additional programming.

The Two Decoupling Mechanisms

The separation between hardware and software is achieved through exactly two mechanisms:

  1. Mapping of function blocks to devices — assigns where each part of the application logic executes.
  2. Association of symbolic links to device I/O — a symbolic link represents a basic variable; binding it to physical I/O happens only after function blocks are mapped.

Once function blocks are mapped, the engineering tool automatically calculates the information that must be exchanged between devices. No hand-written communication logic is required.

Engineering Workflow

  1. Define the application logic without considering how it will be distributed or executed across devices.
  2. Select the devices to purchase and map the execution logic (function blocks) to them.
  3. Let the tool automatically generate the inter-device data exchange.
  4. Associate the symbolic links in the mapped function blocks to the physical I/O of each device.
  5. To change a hardware device later, repeat the mapping process on the new hardware — the application logic itself does not change.

Operational Advantages

  • Late hardware decisions: The application can be completed before the hardware architecture is finalized and deployed at the last minute.
  • Fast commissioning changes: If last-minute changes require adding CPUs, redistributing the application to the new hardware configuration is reported as a roughly 15-minute job, with the system auto-generating the programs and inter-controller communication.
  • Lifecycle upgrades: Controllers can be upgraded and kept current over the plant lifetime without rewriting applications.
  • Reusable libraries: Users can build hardware-independent, proven-in-use application libraries that are reused regardless of the target controller.
  • Targeted compute placement: Calculation-intensive function blocks can be deployed to appropriate hardware types, such as edge computers.

Verification and Further Reading

To verify a correct decoupled design, confirm that the application model contains no device-specific references, that every function block is mapped to a device/resource in the system model, and that all symbolic links are bound to physical I/O before deployment. For background on portability and Industry 4.0 use cases, see the whitepaper "IEC 61499: The Industrial Automation Standard for Portability that Unleashes Industry 4.0."

FAQ

How does IEC 61499 separate software from hardware?

Through two mechanisms: mapping function blocks to devices in the system model, and associating symbolic links (basic variables) to physical device I/O. The application logic itself contains no hardware references.

Do I need to program communication between distributed IEC 61499 controllers?

No. Once function blocks are mapped to devices, the engineering tool automatically calculates and generates the data exchange between devices, using standardized communications and data models.

What happens if the hardware changes after the application is written?

Repeat the mapping process on the new hardware: remap the function blocks to the new devices and re-associate symbolic links to the new I/O. The application logic remains unchanged, and redistribution during commissioning is reported as roughly a 15-minute task.

Back to blog