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. 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
APPLICATION MODULES ? ? (Foundation) (Industrial Operation) (Business Logic) ? ? ? ? ???????????? ???????????? ???????????? ? ? ? Tags ? ??????? ? Devices ? ??????? ? Scripts ? ? ? ? Assets ? ? Alarms ? ? Datasets ? ? ? ? UDTs ? ?Historian ? ? Reports ? ? ? ???????????? ???????????? ???????????? ? ? ? ? ? ? ? ??????????????????????????????????????????????????? ? ? ? ? ? 4. 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
|
[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 architectureDetailed User Interface Guide →
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 | ||||
---|---|---|---|---|
|