Page History

One linerConfigure alarms, devices, and historians.

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

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:

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

Node Configuration

Nodes represent individual devices:

1. Right-click channel → New Node
2. 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:

1. Right-click node → Import Points or New Point
2. 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:

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

Alarm Items Configuration

Define alarm conditions:

1. Select group → New Item
2. 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

1. Go to Alarms → Notification
2. 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

1. Navigate to Historian → Storage Locations
2. 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:

1. Click New Table
2. 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

1. Go to Historian → Tags
2. 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

In this section...

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. 

• Protocol Selection 
• Organizing Channels and Nodes
• Using Access Types

Configuration Workflow

1. 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. 

2. 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. 

3. 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. 

Related Topics

• Unified Namespace - Tag configuration
• Connectivity & Integration - Driver details
• Application Modules - Data processing
• Performance Tuning - Optimization

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