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:
- 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
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
Opus 4.1