Overview
Building successful FrameworX solutions follows a proven four-pillar methodology that ensures scalability, maintainability, and performance. This structured approach guides you from initial data modeling through to final deployment, with each pillar building upon the previous to create a complete industrial application.
The Four-Pillar Methodology
Foundation → Integration → Logic → Visualization
Each pillar represents a critical layer of your solution, implemented in sequence for optimal results:
esults:
??????????????????????????????????????????????????????????????????????????????
? FRAMEWORKX SOLUTION ?
??????????????????????????????????????????????????????????????????????????????
? ?
? 1. UNIFIED NAMESPACE 2. PROCESS MODULES 3. APPLICATION MODULES ?
? (Foundation) (Industrial Operation) (Business Logic) ?
? ?
? ???????????? ???????????? ???????????? ?
? ? Tags ? ??????? ? Devices ? ??????? ? Scripts ? ?
? ? Assets ? ? Alarms ? ? Datasets ? ?
? ? UDTs ? ?Historian ? ? Reports ? ?
? ???????????? ???????????? ???????????? ?
? ? ? ? ?
? ??????????????????????????????????????????????????? ?
? ? ?
? 4. USER INTERFACE ?
? (Analyze & Visualize) ?
? ???????????????? ?
? ? Displays ? ?
? ? Dashboards ? ?
? ? Mobile ? ?
? ???????????????? ?
??????????????????????????????????????????????????????????????????????????????
Benefit | Description | Impact |
---|---|---|
Structured Development | Clear sequence of implementation | Reduced errors and rework |
Scalability | Foundation supports growth | Easy expansion without redesign |
Maintainability | Organized architecture | Simplified troubleshooting |
Reusability | Template-based approach | Faster development |
Best Practices | Industry-proven patterns | Reliable solutions |
? Starting with displays - Without proper data structure ? Skipping UDTs - Leading to tag sprawl ? Direct device-to-display binding - Creating maintenance nightmares ? Ignoring naming conventions - Causing confusion later ? Building monolithic solutions - Instead of modular architecture
The Unified Namespace (UNS) is your solution's data foundation - a single source of truth for all real-time and configuration data.
Step 1: Plan Your Namespace
??? Define naming standards (Area_Equipment_Signal)
??? Document tag requirements
??? Plan for 20% growth
Step 2: Create Base Tags
??? System tags (heartbeat, status)
??? Communication tags
??? Calculation tags
Step 3: Build UDTs
??? Motor (Running, Speed, Current, Hours)
??? Valve (Open, Close, Position, Fault)
??? Tank (Level, Temperature, Pressure)
??? PID (SP, PV, CV, Mode)
Step 4: Organize Assets
??? Plant
??? Area1
??? Line1
??? Line2
??? Area2
WTP_PUMP01_RUNNING
Process modules connect your solution to the physical world, connecting & collecting data from field devices and managing industrial operations.
Step 1: Setup Devices
??? Create Channel (Protocol, Port, Timeout)
??? Add Nodes (IP, Device ID)
??? Map Points to Tags
Step 2: Configure Alarms
??? Create Areas (Plant sections)
??? Define Groups (Equipment types)
??? Set Conditions (Limits, Deviation)
??? Configure Notifications
Step 3: Enable Historian
??? Select Storage Location
??? Create Tables
??? Configure Tag Collection
??? Set Compression
Field Level Communication UNS & Operation
??????????? ??????????? ???????????
? PLCs ? ? Drivers ? ? Tags ?
??????????? ??????????? ???????????
? RTUs ? ??????? ?Protocols? ??????? ? Alarms ?
??????????? ??????????? ???????????
? Sensors ? ?Providers? ?Historian?
??????????? ??????????? ???????????
Application modules add business logic, data processing, and integration capabilities to transform raw data into actionable information.
Step 1: Database Setup
??? Configure Connections
??? Create Tables/Views
??? Build Queries
??? Test Transactions
Step 2: Script Development
??? Calculation Tasks
??? Control Logic
??? Data Processing
??? Error Handling
Step 3: Report Creation
??? Design Templates
??? Configure Data Sources
??? Set Schedules
??? Test Distribution
Raw Data → Scripts → Calculations → Database → Reports
↓ ↓ ↓ ↓ ↓
Tags Process Transform Store Distribute
Use Case | Implementation |
---|---|
KPI Calculations | Scripts calculate OEE, efficiency, yield |
Batch Records | Database stores recipe and production data |
Integration | REST APIs connect to ERP/MES |
Reports | Automated shift, daily, monthly reports |
The UI layer presents information to operators, managers, and stakeholders through interactive displays and dashboards.
Step 1: Display Architecture
??? Create Navigation Structure
??? Design Template Displays
??? Build Process Graphics
??? Implement Standards
Step 2: Display Development
??? Overview Displays
??? Detail Displays
??? Control Faceplates
??? Alarm Displays
Step 3: Dashboard Creation
??? KPI Dashboards
??? Analytics Views
??? Mobile Layouts
??? Executive Reports
Step 1: Display Architecture
??? Create Navigation Structure
??? Design Template Displays
??? Build Process Graphics
??? Implement Standards
Step 2: Display Development
??? Overview Displays
??? Detail Displays
??? Control Faceplates
??? Alarm Displays
Step 3: Dashboard Creation
??? KPI Dashboards
??? Analytics Views
??? Mobile Layouts
??? Executive Reports
Plant Overview
↓
Area Overview
↓
Process Display
↓
Equipment Detail
↓
Faceplate Popup
PLAN BUILD DEPLOY
????????????????? ????????????????? ?????????????????
1. Requirements ???? 5. Implementation ???? 9. Installation
2. Architecture 6. Integration 10. Commissioning
3. Standards 7. Testing 11. Training
4. Design 8. Validation 12. Support
Tags (UNS)
→ Devices (Read/write values)
→ Alarms (Monitor conditions, notify and request ack, as needed)
→ Historian (store and recover time-series data)
→ Scripts (process data, implement workflows)
→ Dataset (sync with SQL databases, or recipe files)
→ Reports (pub PDF or CSV data, exchange JSON/XML data
→ Displays (Visualize)
Security Module
→ Restrict access to configuration modules and artifacts.
→ Provides Identification & Authorization for Displays client users.
PLC → Driver (Device Point) → Tag → Display
PLC address → Dynamic TagProvider → Display
Example 3: Calculation to Database
Tags → Script (Calculation) → Result Tag → Dataset (SQL)
Example 4: User Command
Display → Button Click → Tag Write (UNS) → Device → PLC
& → Audit Log (when enabled)
Template | Description | Components | Time to Deploy |
---|---|---|---|
Basic HMI | Simple machine interface | 100 tags, 5 displays | 1 hour |
SCADA Starter | Small SCADA system | 1000 tags, alarms, trends | 4 hours |
MES Interface | Production tracking | Database, reports, KPIs | 1 day |
IIoT Gateway | Cloud connectivity | MQTT, REST API, store-forward | 2 hours |
Pitfall | Impact | Solution |
---|---|---|
No naming standard | Confusion, errors | Define and enforce standards early |
Skipping UDTs | Maintenance nightmare | Create templates for all equipment |
Over-polling devices | Performance issues | Optimize scan rates based on needs |
Complex displays | Operator confusion | Follow ISA-101, simplify graphics |
No documentation | Support difficulties | Document as you build |
Ignoring security | Vulnerabilities | Implement security from start |
Pillar | Purpose | Key Components | Order |
---|---|---|---|
UNS | Data foundation | Tags, Assets, UDTs | First |
Process | Field integration | Devices, Alarms, Historian | Second |
Application | Business logic | Scripts, Datasets, Reports | Third |
Interface | Visualization | Displays, Dashboards, Clients | Fourth |
Solution Size | Tags | Development Time | Team Size |
---|---|---|---|
Small | <1,000 | 1-2 weeks | 1 person |
Medium | 1,000-10,000 | 4-8 weeks | 2-3 people |
Large | 10,000-50,000 | 3-6 months | 3-5 people |
Enterprise | >50,000 | 6-12 months | 5+ people |
Note: Those are order of magnitude references. Specific requirements & workflow & user review process need to be accounted for.
<details> <summary>Structured Information for AI Tools</summary>
json
{
"page": "Building Solutions",
"type": "Methodology Guide",
"purpose": "Explain the four-pillar solution building approach",
"pillars": [
{
"name": "Unified Namespace",
"order": 1,
"purpose": "Data foundation",
"components": ["Tags", "Assets", "UDTs"]
},
{
"name": "Process Modules",
"order": 2,
"purpose": "Field integration",
"components": ["Devices", "Alarms", "Historian"]
},
{
"name": "Application Modules",
"order": 3,
"purpose": "Business logic",
"components": ["Scripts", "Datasets", "Reports"]
},
{
"name": "User Interface",
"order": 4,
"purpose": "Visualization",
"components": ["Displays", "Dashboards", "Clients"]
}
],
"workflow": {
"phases": ["Planning", "Development", "Deployment"],
"duration": "1-12 months depending on size",
"approach": "Sequential pillar implementation"
},
"bestPractices": [
"Follow pillar sequence",
"Create reusable components",
"Document everything",
"Test thoroughly",
"Plan for growth"
]
}
</details>
Template | Includes | Best For |
---|---|---|
Basic HMI | Tags, Displays, Navigation | Simple machine control |
SCADA System | Devices, Alarms, Historian, Displays | Process monitoring |
MES Integration | Datasets, Scripts, Reports, Dashboards | Production tracking |
IIoT Gateway | MQTT, TagProviders, Cloud connectivity | Edge computing |