IEC 61158 Parts 5 & 6 Explained: Application Layer & Protocol Machines

By | March 2, 2026

The application layer is where industrial communication becomes meaningful.

If:

Then the application layer defines what those frames actually mean.

IEC 61158 Parts 5 and 6 define:

  • Application services
  • Communication models
  • Protocol state machines
  • Device control mechanisms
  • Application relationships

This layer enables:

  • Device configuration
  • Parameter access
  • Control commands
  • Messaging
  • Device identification

This article explains the IEC 61158 application layer in clear, practical terms for automation engineers and protocol developers.

1. What the Application Layer Does

The application layer (Layer 7 of the OSI model) is responsible for:

  • Device-level communication
  • Command execution
  • Data exchange semantics
  • Service requests and responses
  • Control logic communication

Unlike the lower layers, the application layer understands:

  • Meaning
  • Commands
  • Parameters
  • Device behavior

It turns communication into functionality.

2. IEC 61158 Part 5 vs Part 6

The application layer is divided into two parts:

Part 5 – Application Layer Service Definition

Defines:

  • Application Service Elements (ASE)
  • Communication models
  • Service primitives
  • Data types

This part defines what services exist.

Part 6 – Application Layer Protocol Specification

Defines:

  • Protocol data units (PDUs)
  • State machines
  • Transfer syntax
  • Encoding rules
  • Device profile structures

This part defines how services are implemented.

Together, they create structured device communication.

3. Application Service Elements (ASE)

ASEs are logical service blocks.

They define:

  • Read operations
  • Write operations
  • Control operations
  • Messaging services

ASEs provide a clean interface between:

  • Device application logic
  • Communication protocol layer

This modular design improves portability and conformance.

4. Communication Models

IEC 61158 application layer supports structured communication models.

These include:

  • Client/server interactions
  • Device control services
  • Message services
  • Application relationships

The model defines how devices:

  • Establish communication
  • Exchange commands
  • Manage sessions

Industrial systems require predictable application-level behavior.

5. FAL – Fieldbus Application Layer

The Fieldbus Application Layer (FAL) defines the application communication environment.

FAL includes:

  • Application entities
  • Service access points
  • Protocol machines

It coordinates:

  • Service invocation
  • Message processing
  • Response handling

FAL ensures standardized device communication.

6. Protocol Data Units (PDUs)

Application communication is structured into PDUs.

PDUs include:

  • Service identifiers
  • Parameters
  • Command fields
  • Data payload

The application layer defines:

  • Abstract syntax (logical structure)
  • Transfer syntax (encoded structure)

This ensures consistent device communication across implementations.

7. Protocol State Machines

IEC 61158 defines formal state machines at the application layer.

These machines control:

  • Connection establishment
  • Service execution
  • Message handling
  • Error handling

Common protocol machines include:

  • Field Device Control Protocol Machine (FDC PM)
  • Message Protocol Machine (MSG PM)
  • Application Relationship Protocol Machine (ARPM)

State machines ensure deterministic application behavior.

8. Application Relationship Protocol Machine (ARPM)

ARPM manages relationships between communicating devices.

It handles:

  • Connection setup
  • Session maintenance
  • Termination
  • Error conditions

This ensures structured device-to-device communication.

In industrial control systems, predictable session handling is critical.

9. Device Profiles and Device Information

IEC 61158 application layer defines structured device information.

This may include:

  • Device identifiers
  • Version information
  • Parameter sets
  • Virtual memory space

This allows:

  • Standardized device representation
  • Interoperability
  • Structured configuration

Device profiles define how specific device types behave within the communication model.

10. Abstract Syntax vs Transfer Syntax

The standard separates:

Abstract Syntax

Logical data structure.

Transfer Syntax

Encoded transmission format.

This separation ensures:

  • Platform independence
  • Structured data representation
  • Clear protocol documentation

It allows vendors to implement different internal structures while maintaining interoperability.

11. Field Device Control (FDC)

Field Device Control defines command sets for device management.

It includes:

  • Control commands
  • Parameter updates
  • Status requests
  • Device resets

FDC ensures standardized device behavior within the fieldbus system.

12. Messaging Services

In addition to cyclic control, the application layer supports messaging.

Messaging is typically:

  • Acyclic
  • Event-driven
  • Used for diagnostics or configuration

This allows:

  • Firmware updates
  • Parameter reads
  • Alarm notifications

Messaging complements cyclic control communication.

13. Application Layer and Determinism

While determinism is heavily controlled at the data-link layer, the application layer must also behave predictably.

This requires:

  • Defined state transitions
  • Structured service execution
  • Controlled session handling

Uncontrolled application behavior can destabilize real-time systems.

14. Error Handling and Robustness

The application layer includes:

  • Service error responses
  • Timeout handling
  • State recovery

This ensures:

  • Safe failure
  • Predictable behavior
  • Controlled recovery

Industrial systems cannot tolerate undefined application states.

15. Practical Engineering Considerations

When working with the application layer:

Understand Device Profiles

Different devices implement different service sets.

Validate Service Support

Not all services are mandatory.

Monitor Application States

Protocol analyzers can reveal state transitions.

Test Session Handling

Improper ARPM handling can cause communication lockups.

16. Common Application Layer Problems

  • Unsupported service requests
  • Incorrect device identifiers
  • Session timeout failures
  • Improper state transitions
  • Misconfigured device profiles

These issues often appear as:

“Device not responding”
But originate in the application layer logic.

17. Why This Matters for SCADA Systems

SCADA systems typically operate at or above the application layer.

Understanding IEC 61158 Parts 5 and 6 helps engineers:

  • Integrate field devices correctly
  • Diagnose control command failures
  • Evaluate vendor compliance
  • Understand device configuration models

Application layer knowledge prevents costly integration errors.

Frequently Asked Questions

What does IEC 61158 Part 5 define?

It defines application layer services and communication models for fieldbus systems.

What does IEC 61158 Part 6 define?

It defines application layer protocol structure, PDUs, state machines, and device profile handling.

Why is the application layer important?

It defines how devices exchange commands, parameters, and control information in industrial networks.

Final Summary

IEC 61158 Parts 5 and 6 define the application layer of industrial fieldbus systems.

They specify:

  • Application service elements
  • Protocol data units
  • Communication models
  • State machines
  • Device profiles
  • Messaging services
  • Session management

This layer gives meaning to industrial communication.

It enables device control, configuration, and structured interaction.

Without a properly implemented application layer, fieldbus communication cannot support real industrial automation.

Author: Zakaria El Intissar

I'm an automation and industrial computing engineer with 12 years of experience in power system automation, SCADA communication protocols, and electrical protection. I build tools and write guides for Modbus, DNP3, IEC 101/103/104, and IEC 61850 on ScadaProtocols.com to help engineers decode, analyze, and troubleshoot real industrial communication systems.

Leave a Reply

Your email address will not be published. Required fields are marked *