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 Operation → Logic & Data → Visualization
Each pillar represents a critical layer of your solution, implemented in sequence for optimal results:
Pillar 1- Foundation - Unified Namespace: Tag, AssetTree, User Data Types
Pillar 2 - Industrial Operations - Process Modules: Devices, Alarms, Historian
Pillar 3 - Logic & Data Enrichment - Application Modules: Scripts, Datasets (SQL), Reports (PDF/JSON/XML(
Pillar 4 - User Interface Modules: Displays, Dashboards, Layouts. Desktop, Web and Mobile clients.
→ Catalog
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 solution |
Template | Description | Components | Time to Explore |
---|---|---|---|
Basic HMI | Simple machine interface | Displays. Modbus , TouchPanel UI | 10 min |
SCADA Starter | Small SCADA system | Alarms, trends | 15 min |
MES Interface | Production tracking | Database, reports, KPIs | 20 min |
IIoT & MQTT | MQTT Edge Integration | MQTT Broker, Client & Publisher & SQL | 15 min |
Central Server ProveIt! | Situational Awareness, Corporation Level | Enterprise Unlimited, Local & Extended UNS, Direct Binding to MQTT | 20 min |
Industry Templates | |
---|---|
Discreet manufacturing
| Utilities
|
Continuous Process
| Edge & IIoT
|
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 |
Modules Key Concepts Review | |
---|---|
One Line Descriptions | Data Flow Examples |
Tags (UNS) → Devices (Read/write values) | Example 1: PLC to DisplayPLC → 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 |
Development 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.
Shorten Dev time & Increase Reliability Checklist | |
---|---|
What to do | Reason |
Start with UNS, not Displays | Displays seems easier, but without proper data structure, the total development time increases, and reliability decreases. |
Leverage UNS features | Local UNS Tags x Linked-Tags x Direct Mapping establishes the foundation for the entire solution Life-cycle |
Maintain Library of Classes, Symbols & Templates. | Create a solution-specific reusable artifacts. Keeps consistency. |
Building Modular Scalable solutions | Modular architecture & solid design, prevent errors to happen, and provide core to future requirements not yet identified or raised by the end-users, avoid monolithic solution design. |
Best Practices Checklist | |
---|---|
Design Phase
| Development Phase
|
Deployment Phase
| Maintenance Phase
|
Common Pitfalls and How to Resolve | ||
---|---|---|
Pitfall | Impact | How to Resolve |
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 |
Overview
The four-pillar methodology (UNS, Process Modules, Application Modules, UI) provides a unique organizational principle that differentiates Tatsoft from competitors. This architectural approach to documentation surpasses the typical product-centric organization seen in platforms like FactoryTalk or WinCC, potentially offering superior conceptual clarity for system designers.
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 Field Proven Methodology
Foundation → Integration → Logic → Visualization
Each pillar represents a critical layer of your solution, implemented in sequence for optimal results:
??????????????????????????????????????????????????????????????????????????????
? 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.
Process modules connect your solution to the physical world, connecting & collecting data from field devices and managing industrial operations.
Application modules add business logic, data processing, and integration capabilities to transform raw data into actionable information.
Detailed Application Modules Guide →
The UI layer presents information to operators, managers, and stakeholders through interactive displays and dashboards.
FrameworX 10.1 follows a modular, scalable architecture designed for industrial applications from small single-machine interfaces to enterprise-wide systems. Understanding the platform architecture helps you design robust solutions, optimize performance, and plan for growth. This guide explores the core components, data flow, and deployment patterns that make FrameworX a powerful industrial application platform.
FrameworX is more than just software tool,
It's the enabling field-proven architecture and methodology to deploy applications managing critical assets, from large distributed systems to standalone edge apps. It unlocks the sophistication, performance and openness of latest technologies, yet keeping a simple configuration, and a clear cost with advantageous Total Cost of Ownership.
Reference Link:
Solutions Guidebook (examples of solution architecture in production)
Configuration Workflow | |
---|---|
(1) Define Your Data | (2) Setup Industrial Process Modules |
Unified Namespace (Local UNS) | SQL Database Connections and Queries |
DataExplorer | Scripts and Business Logic |
Extended UNS using Direct Binding | Reports, data pub (PDF, CSV, HTML, XML & JSON |
(3) Setup Application Modules | (4) User Interface Design |
Devices, Field Connections | Symbol Library extensions |
Alarms, Events, and Audit-trail | Unified Designer (Canvas & Responsive Dashboard) |
Historian, time-series data | Layouts, Desktop (.NET), Web &r Mobile (WebAssembly) |
== > Link to Development to Production Best Practices and Industry Standard pages.
Define clear boundaries and objectives:
Stakeholder | Role | Requirements | Concerns |
---|---|---|---|
Operations | End Users | Intuitive interface, reliable operation | Ease of use, training |
Maintenance | Support Staff | Diagnostic tools, documentation | Troubleshooting, updates |
Management | Decision Makers | Reports, KPIs, ROI | Cost, timeline, benefits |
IT | Infrastructure | Security, integration, standards | Compliance, compatibility |
Engineering | Technical Design | Flexibility, features, performance | Technical debt, scalability |
Data Collection Worksheet Example
Source: PLC-01 |
---|
Protocol: Modbus TCP |
IP Address: <protected from public documents> Scan Rate: 1 second Point Count: 250 |
DataTypes: Holding Registers: 150 |
Component | Option 1 | Option 2 | Decision | Rationale |
---|---|---|---|---|
Deployment | Standalone | Distributed | Distributed | Multiple sites |
Database | SQLite | SQL Server | SQL Server | Scale requirements |
Redundancy | None | Hot-Standby | Hot-Standby | Critical process |
Clients | Rich only | Rich + Web | Rich + Web | Remote access |
Historian | Local | Enterprise | Enterprise | Corporate reporting |
Standard: [Area]_[Equipment]_[Component]_[Signal]
Examples:
WTP_PUMP01_MOTOR_RUNNING
WTP_PUMP01_MOTOR_SPEED_SP
WTP_TANK01_LEVEL_PV
BLDG_HVAC_AHU01_TEMP_SP
UNS Structure
|
UDT Design - UNS Data Template
UDT: MOTOR_VF0
|
|
|
|
|
Level | Scope | Responsibility | Tools |
---|---|---|---|
Unit Testing | Individual components | Developer | Designer test mode |
Integration Testing | Module interactions | Developer | Runtime test |
System Testing | Complete solution | QA Team | Test scripts |
Acceptance Testing | Business requirements | Customer | Test procedures |
Test ID: TC 001 Feature: Pump Control |
---|
Preconditions:
|
Steps:
|
Expected Result:
|
Actual Result: |
Deployment Sequence
|
System Comissoning Step
|
Document | Purpose | Responsibility |
---|---|---|
I/O List | Verify all points | Controls Engineer |
Loop Sheets | Test each control loop | Technician |
Alarm List | Verify alarm functions | Operations |
Interlock Matrix | Test safety interlocks | Safety Engineer |
Performance Log | Record system metrics | System Integrator |
Support Ties
|
Frequency | Tasks | Responsibility |
---|---|---|
Daily | Check system status, Review alarms, Monitor performance | Operations |
Weekly | Backup solution, Review logs, Check disk space | Maintenance |
Monthly | Archive data, Update documentation, Performance analysis | Engineering |
Quarterly | Security review, Disaster recovery test, Training update | Management |
Annually | License renewal, Major updates, System audit | All teams |
KPI Dashboard Example
|
FrameworX Native Tools
Tool | Purpose | Description |
---|---|---|
Track Cross-Reference | Governance | monitor governance of all places a object is used. |
Track RecentChanges | Version Control | light, built-in, record of latest used phases |
Track Unused objects | Optimization | Identify objects potentially not in use |
Track VersionControl | Version Control | Keep automated VersionID to all modules, tables and objects. Global VersionID for entire solution. |
Build, backup flag | Backup/Restore point | Crete a backup copy of product current stage |
Publish | Lock production version | FDA compliance, lock solution file version |
Third-party recommend tools
Tool | Purpose | Comments |
---|---|---|
JIRA//Azure DevOps | Task tracking | critical for maintenance and product phases |
Git/SVN | Version control | Add comparing version, in top of built-in FrameworX TrackChanges tools |
Confluence | Document management | All phases |
Teams/Slack | Communication | All phases |
Gate Review
|
Risk | Probability | Impact | Mitigation |
---|---|---|---|
Scope Creep | High | High | Clear change control process |
Integration Issues | Medium | High | Early testing, vendor support |
Performance Problems | Medium | Medium | Load testing, optimization |
User Resistance | Medium | Medium | Training, involvement, support |
Hardware Delays | Low | High | Early ordering, alternatives |
Manual Tasks → Automated Solutions
?????????????????????????????????
Tag Creation → Excel Import
Alarm Config → Template Application
Report Gen → Scheduled Tasks
Testing → Automated Scripts
Deployment → Scripted Installation
Backup → Automated Schedule
Team | Best Practices |
---|---|
Team | Best Practices |
Cross-Functional | Regular sync meetings, shared workspace |
Remote Teams | Video calls, screen sharing, cloud tools |
Customer Interaction | Demos, prototypes, feedback sessions |
Vendor Coordination | Clear specifications, regular updates |