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 →
Industrial Operations → Business 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. This field-proven approach has been refined across hundreds of deployments to minimize rework and maximize reliability.
On this page:
Table of Contents maxLevel 2 minLevel 2 indent 10px exclude Steps style none
The Four Pillars Overview
USER INTERFACE ? ? (Analyze & Visualize) ? ? ???????????????? ? ? ? Displays ? ? ? ? Dashboards ? ? ? ? Mobile ? ? ? ???????????????? ? ??????????????????????????????????????????????????????????????????????????????
Why Follow This Methodology?
Benefits of the Four-Pillar Approach
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 |
Common Mistakes to Avoid
? 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 architecturePillar 1: Unified Namespace (Foundation)
Purpose
The Unified Namespace (UNS) is your solution's data foundation - a single source of truth for all real-time and configuration data.
What to Build
Tag Structure | Asset Tree | User Data Types |
---|---|---|
|
|
|
|
Implementation Steps
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
|
[
Best Practices
- Naming Convention Example:
WTP_PUMP01_RUNNING
- WTP = Water Treatment Plant
- PUMP01 = Equipment ID
- RUNNING = Signal name
- Use consistent abbreviations
- Plan for expansion (reserve number ranges)
- Document everything
Detailed UNS Guide →]
Pillar 2: Process Modules (Industrial Operations)
Purpose
Process modules connect your solution to the physical world, connecting & collecting data from field devices and managing industrial operations.
What to Build
Device Communications | Alarm Management | Historian |
---|---|---|
|
|
|
|
|
|
|
|
|
Implementation Steps
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
Connection Architecture
Field Level Communication UNS & Operation
??????????? ??????????? ???????????
? PLCs ? ? Drivers ? ? Tags ?
??????????? ??????????? ???????????
? RTUs ? ??????? ?Protocols? ??????? ? Alarms ?
??????????? ??????????? ???????????
? Sensors ? ?Providers? ?Historian?
??????????? ??????????? ???????????
|
[
Best Practices
- Start with slow poll rates, optimize later
- Group similar devices on same channel
- Use event-driven updates when available
- Test each connection thoroughly
- Document IP addresses and settings
Detailed Process Modules Guide →]
Pillar 3: Application Modules (
Store & ProcessBusiness Logic)
Purpose
Application modules add business logic, data processing, and integration capabilities to transform raw data into actionable information.
What to Build
Database IntegrationScripts | Datasets | Reports |
---|---|---|
|
|
|
- Write calculation scripts
- Implement control logic
- Create data validation
|
|
Implementation Steps
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
Data Flow
Raw Data → Scripts → Calculations → Database → Reports
↓ ↓ ↓ ↓ ↓
Tags Process Transform Store Distribute
Common Implementations
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 |
|
[Detailed Application Modules Guide →]
Pillar 4: User Interface (
Analyze & VisualizeVisualization)
Purpose
The UI layer presents information to operators, managers, and stakeholders through interactive displays and dashboards.
What to Build
Operational Displays | Dashboards | Operator UI Clients |
---|---|---|
|
|
|
|
|
|
Implementation Steps
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
Display Hierarchy
Plant Overview
↓
Area Overview
↓
Process Display
↓
Equipment Detail
↓
Faceplate Popup
Design Principles
- Follow ISA-101 HMI standards
- Use consistent color philosophy
- Implement situational awareness
- Minimize animation
- Optimize for target resolution
Solution Building Workflow
Complete Development Process
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
Phase 1: Planning (Week 1)
Requirements Gathering
- Define project scope
- Identify data sources
- List user requirements
- Document interfaces
- Establish success criteria
Architecture Design
- Size system (tags, users, data)
- Design network topology
- Plan redundancy
- Define security zones
- Select hardware
Phase 2: Development
Step 1: Foundation (UNS)
- Create Local Tags structure
- Build UDTs
- Setup asset tree
- External Governance: Extend UNS with Dynamic Binding.
Step 2: Integration
- Configure devices
- Setup alarms
- Enable historian
- Test communications
Step 3: Logic
- Develop scripts
- Create queries
- Build reports
- Test calculations
Step 4: Visualization
- Design displays
- Create navigation
- Build dashboards
- Test clients
Step 5: Integration Testing
- End-to-end testing
- Performance testing
- Security testing
- User acceptance
Phase 3: Deployment
Go-Live Preparation
- Production installation
- Data migration
- User training
- Documentation
- Support handover
Module Dependencies and Interactions
Understanding Module Relationships
|
[Detailed Operator UI Guide →]
Solution Ready to Run (Secure & Deploy)
Purpose
Solution ready to Run, validate, apply security, and deploy.
What to Do
Runtime | Security | Deployment |
---|---|---|
|
|
|
[Detailed Solution Runtime Guide →]
Why This Methodology Works
Benefits of the Four-Pillar Approach
Benefit | Description | Impact |
---|---|---|
Structured Development | Clear sequence of implementation | 50-70% reduction in rework |
Scalability | Foundation supports growth | Easy expansion without redesign |
Maintainability | Organized architecture | Simplified troubleshooting |
Reusability | Template-based approach | 40% faster development |
Best Practices | Industry-proven patterns | Reliable solutions |
Common Mistakes to Avoid
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
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.
Data Flow Examples
Example 1: PLC to Display
PLC → Driver (Device Point) → Tag → Display
Example 2: PLC to Display, using Direct Binding.
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)Solution Templates
Quick Start Templates
Template | Description | Components | Time to |
---|---|---|---|
Explore | |||
Basic HMI | Simple machine interface | 100 tags, 5 displays | 1 hour|
Displays, Modbus, TouchPanel UI | 10 min | ||
SCADA Starter | Small SCADA system | ||
Alarms, | |||
trends, | |||
reports | |||
15 min | |||
MES Interface | Production tracking | Database, reports, KPIs | |
20 min | |||
IIoT | |||
& MQTT | Edge Integration | MQTT Broker, | 2 hours |
Industry Templates
Manufacturing Template
- Production tracking
- OEE calculations
- Downtime analysis
- Quality management
- Inventory tracking
Utilities Template
- SCADA infrastructure
- Telemetry systems
- Regulatory reporting
- Load management
- Outage management
Building Automation
- HVAC control
- Lighting management
- Energy monitoring
- Access control
- Tenant billing
Best Practices Checklist
Design Phase
- Define clear naming conventions
- Create reusable UDTs
- Plan for 20-30% growth
- Document all decisions
- Review with stakeholders
Development Phase
- Follow the four-pillar sequence
- Test each component thoroughly
- Use version control
- Regular backups
- Code reviews for scripts
Deployment Phase
- Complete testing before production
- Train all users
- Document operational procedures
- Establish support processes
- Monitor performance
Maintenance Phase
- Regular backups
- Performance monitoring
- Security updates
- User feedback
- Continuous improvement
Common Pitfalls and Solutions
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 |
Client, SQL | 15 min | ||
Enterprise ProveIt! | Corporate Level | Enterprise Unlimited, Extended UNS | 20 min |
Development Workflow
Solution Development Stages
Initiate | Design | Build | Deploy | Support |
---|---|---|---|---|
|
|
|
|
|
Platform UI Components
Three Essential Workspaces
UI Environment | Purpose | Key Functions | |
---|---|---|---|
Solution Center | Solution Management |
|
|
Designer | Solution Configuration |
|
|
Runtime | Solution Execution |
|
|
Quick Reference Tables
Development
Next Steps
After Understanding the Methodology
- Deep Dive into Each Pillar
- Explore Examples
- Get Hands-On
- Build a sample solution
- Follow a tutorial
- Modify a template
Quick Reference
Four Pillars at a Glance
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 |
Time Estimates
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.
AI Assistant Data
<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>
Claude can make mistakes.
Please double-check responses.
Quick Start Templates
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 |
(*) About the Development Time estimates
Best Practices Checklist
DO: | DON'T: |
---|---|
? ? ? ? ? ? | ? ? ? ? ? ? |
Next Steps
- Get Started: Download [Solution Templates]
- Deep Dive: Explore each pillar's detailed guide
- Learn More: Review [Best Practices] documentation
- Get Help: Access [Training Resources]
In this section...
Page Tree | ||||
---|---|---|---|---|
|