1. Overview

The Device module is responsible for all communication between FrameworX and field devices (PLCs, sensors, supervisory systems, among others).

This communication is handled by protocol drivers, which implement the specifications of each market protocol (Modbus, OPC UA, Siemens, etc.).
The Device module provides the standardized layer where these drivers run, ensuring consistent behavior in terms of initialization, execution, and diagnostics.

2. Operating Structure

2.1 Module Initialization

At startup:

  • The Device module identifies the configured communication drivers.
  • Communication groups are created, taking into account:
    • Operand type (bits, words, registers, blocks, etc.).
    • AccessType (Read or Write).
    • Scan intervals (configured polling time).
    • Limits of operand size and quantity supported by the protocol.

This grouping optimizes performance, reduces communication overhead, and ensures protocol compliance.

2.2 Communication Triggers

After initialization, group execution depends on communication triggers:

  • Periodic (polling time): the group is executed at defined intervals.
  • Event-driven: the trigger occurs when a system object or tag requests a read or write.

The trigger type and operation (read/write) are defined by the AccessType parameter.

2.3 Event Queue and Threads

When a trigger is fired:

  1. The event is placed in the Device execution queue.
  2. The module has a central thread that scans this queue every 20 ms.
  3. Each event is allocated to an independent execution thread, allowing parallel and isolated communication.

This architecture ensures:

  • Low response latency.
  • Fault isolation (an error in one group does not block others).
  • Better use of multicore resources.

2.4 Communication Execution

Within the execution thread:

  1. The corresponding group generates the TX message (read or write).
  2. Depending on the protocol:
    • A TCP/IP, UDP, or Serial connection is opened (if not already active) or reused.
  3. The driver sends the message and waits for the response.
  4. For reads, the received values are mapped into system tags.
  5. For writes, the values from the tags are retrieved and sent to the field device.

The entire cycle is handled asynchronously and safely within the thread.

3. Responsibilities of the Device Module

The Device module acts as the orchestrator of communication, with the following responsibilities:

  • Manage configured protocols.
  • Create communication groups during initialization.
  • Define execution triggers (time/event) based on AccessType.
  • Schedule independent threads to perform communication.
  • Provide data to drivers (tag values in case of write).
  • Receive and store data returned by drivers (in case of read).
  • Perform continuous diagnostics, including:
    • Communication status (success/failure).
    • Execution Time: time taken by each thread.
    • Cycle Time: interval between two consecutive executions of the same group.

4. Diagnostics and Monitoring

The Device module provides a set of essential diagnostics for reliability:

  • Verification of success or failure in each cycle.
  • Recording of execution times per group.
  • Measurement of average communication cycle times.
  • Detection of connection issues (TCP/UDP/Serial).

These diagnostics can be accessed for performance analysis, troubleshooting, and configuration optimization.

5. Architecture Benefits

  • Standardization: consistent logic regardless of protocol.
  • Scalability: multiple threads allow handling hundreds of groups simultaneously.
  • Efficiency: intelligent grouping reduces communication overhead.
  • Robustness: isolated failures do not compromise the system.
  • Comprehensive diagnostics: facilitates predictive and preventive maintenance.


  • No labels