Page History

One liner.

How-to Guides → Pillars → Process Modules | Concept | Tutorial | How-to Guide

Process Modules form the industrial integration layer of FrameworX, connecting your solution to the physical world. These modules handle all aspects of field device communication, event detection and management, and time-series data collection. Working together, they collect raw data from your process, monitor conditions, generate notifications, and store historical records - providing the real-time and historical data foundation for your industrial application.

Where Process Modules Fit

Process Modules bridge the gap between field equipment and your application:

Connect to - PLCs, RTUs, sensors, and industrial equipment
Collect from - Real-time process values and equipment status
Monitor for - Alarm conditions and critical events
Store in - Time-series databases for trending and analysis
Feed to - Application logic and user interfaces

The Three Core Process Modules

Devices Module - Field Communication

The Devices module manages all communication with industrial equipment:

70+ Native Drivers - Direct connection without middleware
Multi-Protocol Support - Simultaneous different protocols
Redundant Paths - Primary and backup connections
Store and Forward - Buffer data during outages
Automatic Recovery - Self-healing connections

Alarms Module - Event Management

The Alarms module provides comprehensive event detection and notification:

Real-Time Monitoring - Continuous condition evaluation
Flexible Conditions - Limits, deviation, rate-of-change
Notification System - Email, SMS, audio, visual
Acknowledgment Tracking - Operator response management
Complete Audit Trail - Regulatory compliance

Historian Module - Time-Series Storage

The Historian module captures and stores process data over time:

High-Speed Collection - Millisecond resolution
Data Compression - Efficient storage algorithms
Multiple Storage Options - Local, SQL, cloud
Automatic Aggregation - Hourly, daily, monthly summaries
Built-in Retrieval - Trending and analysis tools

Devices Module Configuration

Channel Configuration

Channels define the communication method:

Navigate to Devices → Channels
Click New Channel
Select protocol type (Modbus TCP, Allen-Bradley, OPC UA, etc.)
Configure channel properties:
- Protocol Settings - Port, timeout, retry
- Performance - Polling rate, priority
- Advanced - Keep-alive, optimization

Node Configuration

Nodes represent individual devices:

Right-click channel → New Node
Configure device-specific settings:
- Primary Station - IP address or COM port
- Backup Station - Redundant path
- Device Address - Unit ID or station number
- Model - Device type selection
- Timing - Response timeout

Points Mapping

Points link device data to tags:

Right-click node → Import Points or New Point
Configure point properties:
- Device Address - Register, coil, or tag name
- Data Type - Matching device format
- Access Type - Read, Write, or Read/Write
- Tag Mapping - Link to UNS tag
- Scaling - If different from tag scaling

Communication Optimization

Block Reads - Combine adjacent addresses
Scan Groups - Different rates for different data
Event-Based - Use unsolicited messages
Pack Optimization - Automatic request combining
Priority Levels - Critical data first

Alarms Module Configuration

Alarm Groups

Organize alarms logically:

Navigate to Alarms → Groups
Create hierarchy:
- Areas - Plant sections
- Groups - Functional organization
- Items - Individual alarm points

Alarm Items Configuration

Define alarm conditions:

Select group → New Item
Configure alarm properties:
- Tag - Monitored tag selection
- Condition - Type of alarm
- Limits - Threshold values
- Priority - 1 (Critical) to 999 (Low)
- Message - Alarm text template

Condition Types

Hi/HiHi - High and high-high limits
Lo/LoLo - Low and low-low limits
Deviation - Difference from setpoint
Rate of Change - Value changing too fast
Digital - State change detection
Quality - Bad quality detection

Notification Configuration

Go to Alarms → Notification
Create notification groups:
- Recipients - Users or groups
- Methods - Email, SMS, popup
- Schedule - When to notify
- Escalation - If not acknowledged
- Templates - Message formatting

Alarm Properties

Deadband - Hysteresis to prevent chattering
Delay - Time in condition before alarm
Auto-Acknowledge - When condition clears
Shelving - Temporary suppression
Enable/Disable - Runtime control

Historian Module Configuration

Storage Configuration

Navigate to Historian → Storage Locations
Define storage targets:
- Local Storage - Embedded database
- SQL Database - SQL Server, MySQL, PostgreSQL
- Time-Series DB - InfluxDB, Canary
- Cloud Storage - Azure, AWS, Google

Table Configuration

Create historian tables:

Click New Table
Configure table properties:
- Name - Table identifier
- Storage Location - Where to store
- Retention - How long to keep data
- Table Size - Records per table
- Auto-Create - New tables automatically

Tag Configuration for Historian

Go to Historian → Tags
Select tags to historize:
- Storage Table - Target table
- Storage Type - How to store
- Trigger - When to store
- Deadband - Minimum change
- Rate - Maximum storage rate

Storage Types

Periodic - Fixed time intervals
On Change - When value changes
Compressed - Swinging door algorithm
All Changes - Every update
Min/Max/Avg - Statistical storage

Data Retrieval

Trend Object - Built-in trending
SQL Queries - Direct database access
Tag Historian - Programmatic access
Export Tools - CSV, Excel export
Web Services - REST API access

Integration Patterns

Pattern 1: SCADA Collection

Typical SCADA data collection setup:

Field Devices → Channels → Nodes → Points → Tags
     ↓              ↓         ↓        ↓        ↓
   PLCs        Protocols  Devices  Mapping  Values
                                              ↓
                                     Alarms & Historian

Pattern 2: Redundant Communication

High-availability configuration:

Primary channel with main network path
Backup channel with alternate path
Automatic failover on communication loss
Synchronized data between paths

Pattern 3: Multi-Rate Collection

Optimized data collection:

Fast (100ms) - Critical control values
Normal (1s) - Process variables
Slow (10s) - Status information
On-Demand - Configuration data

Pattern 4: Event-Driven Architecture

Minimize polling with events:

Unsolicited messages from devices
Report-by-exception configuration
Change-based triggers
Alarm-initiated collection

Runtime Behavior

Device Communication Runtime

Connection Management - Automatic connection/reconnection
Request Optimization - Combined polling
Error Handling - Retry logic
Statistics - Success/failure rates
Diagnostics - Protocol traces

Alarm Processing Runtime

Continuous Evaluation - Real-time checking
State Management - Track alarm lifecycle
Notification Queue - Reliable delivery
Acknowledgment - User interaction
History Logging - Audit trail

Historian Runtime

Buffer Management - Store during outages
Compression Engine - Real-time compression
Forward Store - Catch up after recovery
Aggregation Service - Calculate summaries
Purge Service - Automatic cleanup

Performance Optimization

Device Communication

Group similar data for block reads
Use appropriate polling rates
Enable unsolicited messages when available
Implement connection pooling
Monitor communication statistics

Alarm Management

Set appropriate deadbands
Use alarm shelving for maintenance
Configure delay times to filter noise
Prioritize alarms effectively
Regular review of alarm performance

Historian Optimization

Choose appropriate compression settings
Partition tables by time period
Index frequently queried columns
Archive old data regularly
Monitor storage growth

Best Practices

Device Integration

Test communication in development first
Document all device connections
Use meaningful channel and node names
Implement redundancy for critical devices
Monitor communication health

Alarm Philosophy

Follow ISA-18.2 alarm management standards
Rationalize alarms to prevent flooding
Set meaningful priorities
Test notification delivery
Regular alarm performance reviews

Data Collection Strategy

Collect only necessary data
Set appropriate storage rates
Plan retention policies upfront
Regular database maintenance
Monitor storage capacity

Troubleshooting

Symptom	Likely Cause	Solution
No device communication	Wrong IP or port	Verify network settings and device configuration
Intermittent data	Network issues	Check cable, switches, and network load
Alarm flooding	Limits too tight	Review and adjust alarm limits and deadbands
Missing historical data	Storage full	Check database size and retention settings
Slow polling	Too many points	Optimize scan groups and polling rates
Quality "Bad"	Communication timeout	Increase timeout or check device response
Notifications not sent	SMTP configuration	Verify email server settings
Historian gaps	Buffer overflow	Increase buffer size or reduce collection rate

Module Dependencies

Data Flow Dependencies

Devices → Tags (Write values)
Tags → Alarms (Monitor conditions)
Tags → Historian (Store values)
Alarms → Notification (Send alerts)
All → Displays (Visualization)

Configuration Dependencies

Tags must exist before point mapping
Storage locations before historian tables
Alarm groups before alarm items
Channels before nodes
Nodes before points

Introduction

In this guide, we’ll explore concepts when utilizing the Devices module in FrameworX for communication and data exchange with field devices. We’ll present the typical configuration workflow and links to related topics in the documentation.

On this page:

Introduction
Design Concepts
Configuration Workflow

Design Concepts

The following main concepts are key when setup the devices Communication.

Configuration Workflow

Creating Device Channels
- Navigate to Devices → Protocols
- Select the Protocol that supports the connection if you Device and press Create New Channel
- Go to Devices → Channels to Customize Protocols Options, if needed. The Protocol Options is dependent on the protocol, use the Help button to go open the online documentation of the protocol you are using.
Defining Nodes and Stations:
- Go to Devices → Nodes
- Use the Plus button to create a new Node, selecting the Channel (and consequently the Protocol) that device shall use.
- Define the contents for PrimaryStation, which is the physical network address of the device you want to connect with.
Mapping Tags to the Device Addresses
- Go To Devices → Points to map Tags in your solution to valued within your field Device
- The key columns to setup are the TagName, the Node (that identifies the device), and the Address. Each device has its syntax for the address, but the concept of address applies to all protocols.
- Use the column AccessType to define if you want the tag and the device be connected with Read, Write or both Read and Write modes.
- Custom behavior can be defined extending the AccessTypes.

AI Assistant Data

<details> <summary>Structured Information for AI Tools</summary>

json

{
  "module": "Process Modules",
  "pillar": "Connect & Collect",
  "purpose": "Industrial equipment integration and data collection",
  "modules": {
    "devices": {
      "purpose": "Field communication",
      "components": ["Channels", "Nodes", "Points"],
      "drivers": 70,
      "protocols": ["Modbus", "OPC UA", "EtherNet/IP", "BACnet"]
    },
    "alarms": {
      "purpose": "Event detection and notification",
      "components": ["Groups", "Items", "Notifications"],
      "conditions": ["Limits", "Deviation", "Rate of Change", "Digital"],
      "standards": "ISA-18.2 compliant"
    },
    "historian": {
      "purpose": "Time-series data storage",
      "components": ["Storage", "Tables", "Tags"],
      "types": ["Periodic", "On Change", "Compressed"],
      "databases": ["SQL Server", "PostgreSQL", "InfluxDB"]
    }
  },
  "commonTasks": [
    "Configure device channels",
    "Map points to tags",
    "Set alarm limits",
    "Configure notifications",
    "Setup historian storage",
    "Create collection groups"
  ],
  "integrationFlow": "Devices → Tags → Alarms/Historian → Application/UI",
  "performanceFactors": [
    "Polling rates",
    "Block read optimization",
    "Compression settings",
    "Network bandwidth",
    "Database capacity"
  ]
}

</details>

Claude can make mistakes.
Please double-check responses.

Research

Opus 4.1

Page tree