Page History

1. Overview

...

Device Engine (Reference) orchestrates communication between FrameworX and field devices

...

through protocol drivers, managing execution threads, communication groups, and diagnostics.

The Device

...

Engine provides:

Protocol driver orchestration
Communication group optimization
Thread pool management
Event queue processing
Performance diagnostics
Connection lifecycle management

The engine standardizes device communication regardless of protocol, ensuring consistent initialization, execution, and

...

monitoring.

2. Operating Structure

Table of Contents

maxLevel	2
minLevel	2
indent	10px
exclude	Steps
style	none

Devices → Tutorial | Concept | How-to Guide | Reference

Operating Architecture

Module Initialization

At startup, the Device Engine:

...

Identifies configured protocol drivers
Creates optimized communication groups based on:
- Operand Type - Bits

...

- , words, registers, blocks

...

- AccessType

...

- - Read

...

- , Write, or ReadWrite
- Scan Intervals - Polling time configuration
- Protocol Limits - Size and quantity constraints

...

This grouping optimizes performance

...

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:

The event is placed in the Device execution queue.
The module has a central thread that scans this queue every 20 ms.
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:

The corresponding group generates the TX message (read or write).
Depending on the protocol:
- A TCP/IP, UDP, or Serial connection is opened (if not already active) or reused.
The driver sends the message and waits for the response.
For reads, the received values are mapped into system tags.
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

...

Communication Groups

Groups are organized by:

Common data types
Similar polling rates
Access patterns
Protocol specifications

Execution Model

Communication Triggers

Trigger Type	Description	Use Case
Periodic	Fixed interval polling	Regular data updates
Event-Driven	On-demand execution	Tag writes, user requests
Mixed	Both periodic and event	Critical data with backup polling

Thread Architecture

Event Queue Processing:

Triggers place events in execution queue
Central thread scans queue every 20ms
Events assigned to independent threads
Parallel execution without blocking

Benefits:

Low latency response
Fault isolation between groups
Efficient multicore utilization
Non-blocking operations

Communication Flow

Execution Sequence

Group Activation - Thread receives communication task
Message Generation - TX packet created per protocol
Connection Management - Open/reuse TCP, UDP, or Serial
Data Exchange - Send request, await response
Value Mapping - Update tags with received data
Error Handling - Retry logic and diagnostics

Read Operations

Device → Protocol Driver → Tags
1. Build read request
2. Send to device
3. Receive response
4. Parse data
5. Update tag values

Write Operations

Tags → Protocol Driver → Device
1. Collect tag values
2. Build write request
3. Send to device
4. Await confirmation
5. Update status

Module Responsibilities

The Device Engine manages:

Protocol Management - Driver lifecycle and configuration
Group Creation - Optimal communication grouping
Trigger Definition - Time and event-based execution
Thread Scheduling - Independent thread allocation
Data Routing - Tag-to-device value mapping
Diagnostics - Performance and status monitoring

Diagnostics and Monitoring

Performance Metrics

Metric	Description	Use
Execution Time	Thread processing duration	Performance analysis
Cycle Time	Interval between executions	Throughput monitoring
Success Rate	Communication reliability	Quality assessment
Queue Depth	Pending operations	Load evaluation

Status Indicators

Connection state (Active/Failed/Reconnecting)
Last communication timestamp
Error counts and types
Retry attempts
Data quality

Configuration Guidelines

Group Optimization

Optimal Group Size:
- Modbus: 100-125 registers
- OPC UA: 500-1000 items
- Ethernet/IP: 400-500 bytes

Thread Pool Sizing

Threads = min(CPU_Cores * 2, Active_Groups)
Queue Size = Active_Groups * 2
Scan Rate = 20ms (default)

Error Handling

Retry Strategies

Error Type	Retry Logic	Max Attempts
Timeout	Exponential backoff	3
Connection Lost	Immediate retry	5
Protocol Error	Delay retry	2
Device Busy	Queue and retry	10

Fault Isolation

Thread failures don't affect other groups
Connection issues isolated per channel
Protocol errors logged per driver
Graceful degradation on partial failures

Performance Tuning

Reducing Latency

Decrease scan interval
Optimize group sizes
Use event-driven triggers
Enable connection pooling

Improving Throughput

Increase thread pool
Combine read operations
Use block transfers
Enable compression

Resource Optimization

Share connections
Cache static data
Filter unchanged values
Implement deadbands

Best Practices Checklist

Group Similar Points - Same data type and polling rate
Balance Group Sizes - Respect protocol limits
Stagger Polling - Distribute communication load
Monitor Cycle Times - Identify bottlenecks
Use Event Triggers - For write operations
Enable Diagnostics - Track performance
Configure Timeouts - Match network conditions

Troubleshooting

High Cycle Times:

Check network latency
Reduce group size
Increase thread pool
Review timeout settings

Communication Failures:

Verify device connectivity
Check protocol settings
Review error logs
Test with smaller groups

Queue Overflow:

Increase thread count
Reduce polling rates
Optimize group sizes
Check for blocking operations

In this section...

Page Tree

root	@parent
spaces	93DRAF

...

Page tree