You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Process Modules (Connect & Collect)

Overview

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:

  1. Navigate to DevicesChannels
  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 AlarmsGroups
  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 AlarmsNotification
  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 HistorianStorage 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 HistorianTags
  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

SymptomLikely CauseSolution
No device communicationWrong IP or portVerify network settings and device configuration
Intermittent dataNetwork issuesCheck cable, switches, and network load
Alarm floodingLimits too tightReview and adjust alarm limits and deadbands
Missing historical dataStorage fullCheck database size and retention settings
Slow pollingToo many pointsOptimize scan groups and polling rates
Quality "Bad"Communication timeoutIncrease timeout or check device response
Notifications not sentSMTP configurationVerify email server settings
Historian gapsBuffer overflowIncrease 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:




Design Concepts

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

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


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

  • No labels