Modbus (RTU / TCP)

Purpose and Description

A simple and widely used industrial protocol for exchanging process data between controllers, sensors, and actuators. Developed in 1979 by Modicon (now Schneider Electric), it has become the de facto standard for industrial automation. Used in SCADA systems, PLCs, variable frequency drives, measuring instruments, and sensors. Thanks to its implementation simplicity and minimal computational resource requirements, the protocol is ideally suited for embedded systems and devices with limited memory.

Architecture and Data Model

The register-based data model is built on four types of address space:

• Coils (0x) — discrete outputs (read/write bit values)
• Discrete Inputs (1x) — discrete inputs (read-only)
• Input Registers (3x) — 16-bit input registers (read-only)
• Holding Registers (4x) — 16-bit holding registers (read/write)

Client-server (master-slave) architecture: the master device initiates requests, slaves respond. Each slave device has a unique address (1–247). The protocol contains no built-in data semantics — interpretation of register values is defined at the application level and in device documentation. Supports read and write operations for single and multiple registers.

Transport

Modbus RTU:

• Serial lines RS-485 (up to 32 devices per bus, distance up to 1200 m) or RS-232 (point-to-point)
• Binary data representation
• Integrity verification via CRC-16
• Baud rate: from 1200 to 115200 baud
• Half-duplex transmission

Modbus TCP:

• Encapsulation of Modbus frames in TCP/IP (port 502)
• MBAP header (Modbus Application Protocol) for transaction identification
• Full-duplex transmission
• Ability to work simultaneously with multiple devices
• No checksum required (reliability provided by TCP)

Key Capabilities

• Reading and writing discrete signals (Coils) and registers
• Support for standard Function Codes (FC 01–06, 15–16, 23)
• Diagnostic functions (FC 08)
• Reading device identification data (FC 17, 43)
• Minimal computational resource requirements for devices
• Simple implementation and debugging
• Low implementation cost
• Exception handling and error codes
• Support for broadcast messages (address 0) in RTU
• Scalability up to 247 devices on a line (RTU) or unlimited via TCP

OPC UA

Purpose and Description

A universal cross-platform standard (OPC Unified Architecture, IEC 62541) for secure and structured exchange of industrial data, metadata, and semantic information. Developed by the OPC Foundation as a successor to classic OPC DA/AE/HDA specifications, eliminating dependency on Microsoft DCOM technologies. Enables vertical and horizontal integration in industrial systems — from field level to corporate information systems (ERP, MES). Supports Industrie 4.0 and digital twin concepts thanks to rich information modeling capabilities.

Architecture and Data Model

Object-oriented data model representing information as an addressable node space (Address Space):

• Nodes of various types: Variable, Object, Method, View, DataType, ReferenceType
• Node attributes: Value, DataType, AccessLevel, Timestamp, Quality, DisplayName, etc.
• References between nodes: hierarchical, associative, component-based
• Data types: primitives, structures, arrays, enumerations

Supported services:

• Subscription — data change monitoring with configurable sampling intervals and filters
• Events & Alarms — asynchronous notifications for events, alarms, and states
• Historical Access — access to archived data and events
• Methods — remote procedure invocation on devices

Industry-specific information models (Companion Specifications): mechanical engineering, energy, oil & gas, pharmaceuticals.

Transport

UA Binary Protocol over TCP/IP:

• Binary protocol with optimized serialization (port 4840)
• High performance and minimal overhead

HTTPS / SOAP:

• Web Services profile for integration with enterprise systems
• JSON encoding for cloud applications

OPC UA PubSub:

• Publisher-subscriber model for distributed systems
• Transport: UDP Multicast, MQTT, AMQP, Ethernet TSN
• Deterministic transmission for time-critical applications

Security:

• Multi-level security modes (None, Sign, SignAndEncrypt)
• X.509 certificates for authentication
• AES, RSA encryption

Key Capabilities

• Information modeling: transmission not just of “raw” values but of complex structured data with semantics, typing, and metadata
• Subscriptions with configurable polling intervals, deadband filters, and buffering
• Events and alarm system with conditional filtering
• Method invocation for device control and operation execution
• Historical data access with aggregation
• Service discovery in local networks
• Built-in security: channel encryption, certificate- or username/password-based authentication, node-level access control
• Server redundancy and fault tolerance
• Cross-platform: Windows, Linux, VxWorks, QNX and other OSes
• Scalability: from microcontrollers to distributed systems

MQTT

Purpose and Description

A lightweight messaging protocol (Message Queuing Telemetry Transport) for telemetry, remote monitoring, and IoT device management, optimized for unreliable networks, limited bandwidth, and high latency. Developed in 1999 by IBM for oil pipeline monitoring, standardized by OASIS and ISO/IEC (20922:2016). Widely used in industrial IoT, smart homes, vehicle telematics, and mobile applications. The protocol focuses on minimizing network traffic and device power consumption.

Architecture and Data Model

Asynchronous Publish/Subscribe model with a centralized broker:

• Publisher — device or application publishing messages to topics
• Subscriber — device or application subscribed to receive messages from topics
• Broker — central message routing server (Mosquitto, HiveMQ, EMQ X, etc.)

Topics — hierarchical path structure for message categorization:

• Level separators: / (e.g., factory/building1/temperature)
• Wildcards: + (single level), # (multiple levels)
• Subscription example: sensors/+/temperature or factory/#

Data format defined by the application: JSON, Protocol Buffers, XML, binary data, text.
Retained messages: broker stores the last message for a topic and delivers it to new subscribers.
Persistent sessions: broker preserves client subscriptions upon disconnection.

Transport

• Transport layer: TCP/IP (port 1883 for unsecured connections)
• TLS/SSL (port 8883) for encryption and authentication
• WebSockets for browser and web application integration
• Protocol versions: MQTT 3.1.1 (most common), MQTT 5.0 (extended features)
• Header size: minimum 2 bytes (fixed header)
• Keep-alive mechanism: periodic PINGREQ/PINGRESP for connection monitoring
• Broker-based operation ensures publisher-subscriber decoupling, horizontal scaling, and centralized management

Key Capabilities

• QoS (Quality of Service) three delivery guarantee levels:
  • QoS 0: At most once (no acknowledgment)
  • QoS 1: At least once (with acknowledgment)
  • QoS 2: Exactly once (four-step handshake)
• Minimal network overhead: 2-byte fixed header, efficient binary encoding
• LWT (Last Will and Testament): automatic notification mechanism for unexpected device disconnection — broker publishes a pre-defined message if the client terminates the session abnormally
• Clean Session / Persistent Session: ability to restore subscriptions and messages after reconnection
• Retained Messages: availability of the latest value for new subscribers
• Low power consumption: ideal for battery-powered devices
• Scalability: support for millions of concurrent connections on broker clusters
• Wildcard subscriptions for flexible topic filtering

DLMS / COSEM (IEC 62056)

Purpose and Description

An international standard for data exchange with utility meters: electricity, gas, water, and heat (Device Language Message Specification / Companion Specification for Energy Metering). Developed by the DLMS User Association together with IEC to ensure interoperability of smart meters in Automated Metering and Billing Systems (AMBS). Enables remote meter reading, power quality monitoring, tariff management, and detection of unauthorized access. Widely used by power grid operators, utility providers, and Smart Grid system integrators.

Architecture and Data Model

COSEM object model (Companion Specification for Energy Metering):

• Meter data represented as logical objects (COSEM objects) with interface classes
• OBIS codes (Object Identification System) — six-byte identifier for universal parameter addressing: A-B:C.D.E*F
  • A — energy type (1=electricity, 6=heat, 7=gas, 8=water)
  • B — measurement channel
  • C — physical quantity (e.g., 1=active energy)
  • D — measurement type (8=integration time)
  • E — tariff zone
  • F — historical depth

DLMS protocol:

• Application layer according to OSI model
• Associations with different access rights: Public, Reader, Manager
• Authentication: Low Level Security (LLS), High Level Security (HLS) with challenge-response
• Encryption: DLMS Security Suite support with AES-GCM-128 algorithms
• Load Profiles: buffer objects for storing time-series data
• Scripting system: execution of action sequences on the meter

Transport

Physical and data link layer:

• Optical port (IEC 62056-21, flag) — direct connection via infrared head for local reading
• RS-485 / RS-232 with HDLC protocol (High-Level Data Link Control) for multi-drop networks
• TCP/IP (port 4059) — DLMS over TCP or IP encapsulation for remote access
• GSM/GPRS/LTE — data transmission via mobile networks (wrapper protocols)
• PLC (Power Line Communication) — transmission over power lines (PRIME, G3-PLC)
• M-Bus — for integration with water and heat metering systems

Transmission profiles depending on meter implementation:

• IEC 62056-46: COSEM over HDLC
• IEC 62056-47: COSEM transport over TCP-UDP/IP

Key Capabilities

• Meter reading — current values of energy consumption, power, voltage, current, power factor
• Load Profiles — detailed timestamped data (15-min, hourly, daily intervals)
• Event logs — recording of cover tampering, power failures, overvoltages, parameter changes
• Multi-level authentication and authorization: role-based access control (public access, read, configuration)
• Tariff management — remote modification of tariff schedules and rates
• Time synchronization for timestamp accuracy
• Relay control (load connection/disconnection)
• Power quality monitoring (sags, surges, harmonics)
• Support for group operations across multiple meters
• Cryptographic data protection and message integrity