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.

Why Follow This Methodology?

Field Proven

→ Catalog

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 solution

Solution Templates

Quick Start Templates, with guided explorer

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

OEE calculations
Andon Dashboards

Utilities

GEO Asset Monitor
Distributed Systems

Continuous Process

Brewery Plant
High Performance HMI

Edge & IIoT

Edge PLC to SQL
Protocol Converter & OPC UA server

Next Steps

After Understanding the Methodology

Deep Dive Into Each Pillar

Get Hands-ON

Get Aware of the Quick Links Tables
Follow a Tutorial
Build a sample solution
Follow a tutorial
Modify a template

Quick Reference Tables

→ Four Pillars At a Glance
→ Modules Key Concepts Review
→ Development Time Estimates
→ Shorten Dev time & Increase Reliability Checklist
→ Best Practices Checklist
→ Common Pitfalls and Solutions

Four Pillars at a Glance

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)
→ 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.

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

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

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 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

Building successful FraeworX solutions follows a proven four-pill methodolog that ensures scalability, maintainability, and performance. This sapproach guides you from initial data modelig through to inal deplyment, with each pilla building upon the previous to create a coplete industrial application.

Found→ Integration → Logic → Visualization

Each pillar represents a critical layer of your solution, implemented in sequence optimal results:

Why Follow This Methodology?

Benefits of the Four-Pillar Approach

Benefit	Description	Ipact
Structured Developent	Cle sequence of implementation	Reduced errors and rework
ScalabilitOverview	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

Comm Mistakes to Avoid

? Starting with displays-Without proer dat structure ? Skippin UDTs - Ladingto tag sprawl ? Direct device-to-display binding - Creating maintenance nightmares ? Ignoring naming conventions - Causing confusion later ? monolithic solutions - Instead of modular architecture

Pillar 1: Unified Namespace (Foundation)

Purpose

The Unified Namespace (UN) is your s'datafoundation - a single source of truth for all real-time and configuration data.

What to Build

Tag Structure
- Define naming conventions
- Create tag hierarchy
- Set data s andranges
- Configure engineering units
Asset Tree
- irror physical/logical structur
- Organize by area/process/equipmen
- Create navigable ierarchy
User Data Types (UDTs)
- Create equipment templates
- Define standard bjects
- Buil reusable components

→ Sutin Dev - Use Case Example

Detailed UNS→

Pillar2: Process Modules (Industrial Oerations)

P

Process modules connect your solutionto the hysica world, connecting & collecting dta from feld devices admanaging indusrial operations.

Wat to Build

DevicCommunications
- Conigure channels and protocls
- Setp nodes and devices,
- Map points to tags, o use direct binding
Alarm Management
- Define alarm areas and groups
- Configure conditions and limits
- Setup notifications
Historian (Timeseries Data Collection)
- Configure historian storage
- Set collection rates
- Define retention olicies

P3: Application Module (Stre & Process)

Purpose

Appication modles add business logic, data processing, and integracapailities to transform raw data into actionable information.

What to B

Database Integrato
- Connect to SQL databases
- Create queries and views
- Setup synchronization
Business Loic
- Writeclculation scrits
- Imlement contl logic
- Crete data validation
Reporting
- Design report templates
- Configure sedules
- Setupdistribution

DetailedAplication Modules Guide →

P 4UserInterface(Analyze& Visualize)

Purpose

The UI layer presents information to operators, managers, and stakeholders through interactive displays anddashboards.

WhattoBuild

OperationalDisplays
- Processgraphics
- Controlpanels
- Navigationstructure
Dashboards
- KPI visualization
- Alytics
- Mobile views
Client Deploynt
- Richclients
- Web access
- Mobile I

Detailed User Iterface Gude →

Consolidate

Dev to Production Worklow

Overvw

FrameworX 10.1 follows a moular,scalable rchitecture designed for industrial applications fro small single-machine interfac to enterrise-wide systems. Understnding the platform arhitcturehelpsyoudesignrobustsolutions,ptimize peformance, and plan for growth. This gui exploesthe core componentsdataflow,anddeploymentpatterns that makeFrameworX a owerfl industial aplicatin platform.

FrameworX i morthn jus softwre tool,

It's the enablingield-prven architectre a methodology to deploy applics managing critical assetsfromlargedistributedsystemstostandalone edge apps. It unloks the sphistication, perforance and oenness f latest techologis, yet keepig a simple configuraion, and a clear cot with advantageous Total Cost of Ownership.

Reference Link
Solutions Guidebook (examples of solution rchitecture in production)

Solution Development Workflow

Specification to Solution Flow

Confiuration Workflow
(1) Define Your Data	(2) Setup Indutrial Process Modules
Unified Namespace (Local UNS)	SQL Database Connections and Queries
DataExplorer	Scripts and Business Logic
Extended UNS using Direct Binding	Reportsdata pub (PDF, CSV, HTML, XML & JSON

(3) Setup pplication Module	(4) Ur Inerface Deign
DevicesField Connections	Symbol Library extensions
Alarms, Events, and Audit-trail	nified eigner(Canvas&ResponsiveDashboard)
Historiantime-seriesdata	Layouts,Desktop(.NET),Web&rMobile(WebAssembly)

SolutionDeployment Workflow

Development toProduction Flow

Tools Interaction

Complete Solution Lifecycle

== > Link to Development to Production Best Practices and Industry Standard pages.

Stage 1: Iitite (Planning)

Project Definition - Scope Developnt

Define clear boundaries and objectives

ProjectScope Document
- Business Objectives
  - ROI Targets
  - Efficiency Goals
  - Compliance Requirements
- Technical Requirements
  - I/O Count
  - User Count
  - Integration oints
  - Pefrmance Targets
- Constrains
  - Budget
  - Timeline
  - Resources
  - Technology
- SucCriteria
  - Acceptance Tests
  - Performance etrics
  - Deliverables

Stakehler Analysis

Stakeholder	Role	Reqirment	Concerns
Operations	End Users	Intuitive interfacereliableoperation	Easeofuse,training
Maintenance	SupportStaff	Diagnstic tools, documentation	Toubleshooting, upates
Management	Decision Maks	Reports,KPIsROI	Cost,timeline,benefits
IT	Infrastructure	Security,integration,standards	Compliance,comatibility
Engineering	Technical Design	Flexibility, feates, erfrmance	Technical debt, calability

RquirementsGathering

unctonal Rquirements Checkist

Process control requirements
Data acquisition nees
Alarmmanagement requrements
Reporting specifications
User interface requirements
I requirements
Security requirements
Performance requirements

Source:PLC-01

Protocol:ModbusTCP

IPAddress:<proteted fr ublic dcumets>

Scan Rate: 1 scond

Poi Count: 250

DataType

HoldingRegisters: 150
Coils (digital): 100

Stage 2: sgn (Arhitcture)

Sytem ArchitectureDesign

rchitecture Decision Matrix

Component	Option 1	Option 2	Decision	Rationale
Depoyment	Stndalone	Distibuted	Distributed	Multiple sites
Database	SQLite	SQL Server	SQL Server	Scale requireent
Redundancy	None	Hot-Standby	Hot-Standby	Critical process
Clients	Rich only	Rich + Web	Rich +Web	Remote access
	Local	Enterprise	Enterprise	Corporate reporting

Network Architecture

Data Architecture

Tag Naming Convention

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

??? WTP (Water Treatment Plant)
?   ??? PUMP01
?   ?   ??? MOTOR
?   ?   ?   ??? RUNNING
?   ?   ?   ??? SPEED_SP
?   ?   ?   ??? SPEED_PV
?   ?   ??? VALVE
?   ?       ??? OPEN_CMD
?   ?       ??? POSITION
?   ??? TANK01
?       ??? LEVEL_PV
?

UDT Design - UNS Data Template
UDT: MOTOR_VF0

UDT: Motor_VFD
Properties:
  -Name:String
  -Location:String
  -RatedHP:Float
Members:
  Commands:
    -Start_CMD:Boolean
    -Stop_CMD:Boolean
    -Speed_SP:Float(0-100%)
  Status:
    -Running: Boolea
    - Fulted: Boolean
    - Speed_PV: Float
    - Current: Float
    - TepratureFloat
  larms:
    - OverCurrent: Boolean
    - OverTem: Boolean
    - CommLoss: Boolean
  Statistics:
    - RunHours: Double
    - StartCount: Integer
    - LastStartTime: DateTime

Disay Archteture

NavigHierarchy

ain Men
??? Overview
?   ??? Pant Ovrview
??? Area
?  ???Area1
?  ?  ???Prcess Oveview
?   ?   ??? Equipment
?   ?   ??? Trens
?   ??? Ara 2
?   ??? Aea
???Utilities
?  ???PowerMonitoring
?  ???Comressed Air
?   ??? Steam System
??? Reports
?   ??? Prodction
?   ??? Quality
?   ??? Maintenance
??? Administation
    ??? Setint
    ??? Rcipes
    ??? User Management

Stage 3ld (Developmet)

Dvelopment Workflow

Sprint Planning (Example of a 2-Week Sprint)

Sprint 1: Foundation
??? Day 1-3: Create tag databae
???Day 4-6: Buid UDTs
??? Day 7-9: Cnfiure deves
???Day10:Testing&review

Sprint2: Proess Lgic
??? Day 1-3: Alar cfiguration
??? Day 4-6: Scripts developm
??? Day 7-9: Hitorian setup
??? Day 10Testing & review

print 3: Visualization
??? Day 1-3: Template displays
??? Day 4-6: Proess gaphcs
??? Day 7-9: Dashboards
??? Day 10: Testing & review

Srint 4: Integraion
??? Day 1-3:ab connecion
???Day 4-6:
???Day7-9:Externalinterfaces
???Day10:Testing&review

ConfigurationManagement

VersionControlStrategy

RepositoryStructure:
/FrameworX-Project
???/Documettion
?   ??? Requirents.docx
?   ???Design.docx
?   ??? Manual.docx
???/Solution
?   ??? MyProject.dbsln
?   ??? /Exports
?       ??? Tags_v1.0.xml
?       ??? Displays_v1.0.xml
??? /Scripts
?   ??? Calculations.cs
?   ??? Reports.sql
??? /Graphics
?   ??? P&D.svg
?   ??? Logos.pg
??? /Tess
    ??? UnitTsts.cs
    ??? TestPocedures.xlsx

Change Request ? Impact Analysis ? Approval ? Implementation ? Testing ? Deployment
? ? ? ? ? ?
Document Assess Risk Get Signof Mke Change Validate Release

TstingStrategy

TestLevels

Level	Scope	Responsibility	Tools
UnitTesting	Individualcomponents	Developer	Designertestmde
Integation Testing	Moule intactions	Developer	Runtimetest
System Testing	Complete solution	QA Team	Test scripts
Acceptance Testing	Business requirements	Customer	Testprocedures

TestDocumentation-TestCaseTemlate

Test ID: TC 001

Feate: Pum Contrl

Precondition:

Pump in Auto mod
Tank level at 50&

Steps

SetTank Setpoint to 75%
erfy pump starts
Monitor speed increases

Expected Relt:

Pump running indication ON
Speed ramps to cculated data
No alarms generated

Actual Result:

Stage 4: Deploy (Producton)

Deployment Plnning

Pre-Deploymen Checklst

All tests passed
Dcumetationcomplete
Backupcreated
Licensesverified
Trainingcompleted
Supportplanready
Rollbak plan prepared
Maintenance windw scheduled

Deployent Sequence

Delymet Sequence

1. Pre-Deploym (T-1 Week)
   * Final teting in staging
   *User training
   * ocumentaton review

2. Deployment Day (T-0)
   * 00:00 - Sytem backu
   * 01:00 - Instal softwre
   * 02:00 - Import configuration
   * 03:00 - Configure devices
   * 04:00 - Test communications
   * 05:00 - Verif operation
   *06:00 - Go live

3. Post-Deployment (T+1 y)
   * Monitor performance
   * Addres issues
   * Gater feedack

Cmmissioning Process

System Commissioning Steps

System Comissoning Step

1. Hware Ready
2. Software & Licene Installation
3. Configuration load
4. I/O Checkout
5. Device Testing
6. Function Testing ==> Loop 45, 6 as needed
7. Performance Testing
8. ustomer Acceptance
9. Production Reease

Commssioning Documation

Document	Purpoe	Responsibility
I/OList	Verifyallpoints	ControlsEngineer
LoopSheets	Testeachcontrollop	Technician
Alam List	Verify alarm functions	Operations
Interloc Matrix	Test saety intercks	Safety Engineer
Performance Log	Record system metrics	System Integrator

Stage 5Support(Maintenance)

SupportStructure

SupportTiers

SupportTies

Tier 1: Oerations
* Basic troublesooting
* Restrt procedure
* Known issue rolution

Tier 2Maintenance
* Configuration changes
* Device troubleshooting
* erformance tuning

Tier 3: Engineering
* Compex problems
* System modifictios
* Root cause aalyss

Tier 4: Vedor
* Software bus
* Licenseissues
* Advanced support

Maintenance Activities

Preventive Maintenance Schedule

Frequency	Tasks	Responsibility
aily	Check system status, Riw aarms, Mnitor erforance	Opratios
Weekly	Backup soluion, Review logsChck disk sace	Maintenance
Monthy	Archive data, Update dcumentation, Performance analsis	Engineering
Quarterly	Security review, Disaster recovery test, Training update	Manage
Annually	License renewalMajorupdates,Systemauit	All teams

Continous Impovement

Performnce Moniorng

KPI Dashboard Example

KPI Dashboard Example

  System Uptime:       99.8%
  Avg Respse Time  87ms
  Alarm Rate:          /hour
  Data Loss:           0.00%
  User Satisfaction:   4.5/5

Iprveme Opportunities:
- Reduce alarm rate (target: <10/r)
- Optimize reponsetime (<100ms)
- Increase automation (reuc manual tasks)

Tools and Temlats

Project Maagement Tools

FrameworX Native Tools

Tool	Purpose	Description
Track Cross-Reference	Governance	monitor governance of all places a object is use.
Track RecentChanges	Verso Control	liht,built-in, recrd of latest used phases
Track Uusedobject	Optimation	Idntify objects potentially not in use
Track VersionControl	Version Control	Keep automated VersionID to all modulestablesandobjects.Global VersionID for entire solution.
Build, backup flag	Backup/Restore point	Crete a bcku copy of duct current stge
Publish	Lok production version	FDA compliance, lock solution file version

Tird-party recommend tools

Tool	Purpose	Comments
JIRA//Azure DevOps	Task tracking	critical for maintenance and productphases
Git/VN	Vrsion control	Add comparing version, in top of bilt-in FramworX TrackChages ools
Confluence	Document management	All phases
Teams/Slack	Communction	Alhases

Standard Templates

Avaable Temptes

PojectCharter
Requreents Secification
Design Document
Test Pan
Dploy Guide
Training Merals
Support Prcedures
ChageRequestForm

QualityGates

GateReviews

Gate Review

Gate 1: Design Review
* Requirements complete?
* Architecture approved?
* Risks identified?
* Resources availal?
    *
    * Pas
Gae 2: Development Review
* Code complete?
* Testing done?
* Documentation ready?
* eformne me?
    *
    * Pass
Gate 3: Deployment Revew
* Customer approval?
* Training omplte?
* Support ready?
* Rollback plan?
    *
    * Pas
ProductionRelease

BestPractices

Do'sandDon'ts

DO:

?naming conventons consistently
? Document a decisions and chnges
? Test thooughly at eachtag
? Incld operators i dsignreviews
?Planfor 20-30%growth
? Use version control
?

DON'T:

? Skip testing to save time
? Ignore user feedback
?Hardcodevalues
?Forgetsecurity considerations
? eply without bakups
? Ass requiremeswon't chang
? Neglct documentation

Risk Management

Risk	Pobabilit	Impac	Mitigation
Scope Creep	Hig	Hgh	Clear chae 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

Workflow Optimization

Automation Opportunities

Collabatin Tips

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    ?                                   ?
?                         ????????????????                                   ?
??????????????????????????????????????????????????????????????????????????????

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 architecture

Pillar 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
- Define naming conventions
- Create tag hierarchy
- Set data types and ranges
- Configure engineering units
Asset Tree
- Mirror physical/logical structure
- Organize by area/process/equipment
- Create navigable hierarchy
User Data Types (UDTs)
- Create equipment templates
- Define standard objects
- Build reusable components

→ Solution Dev - Use Case Example

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
- Configure channels and protocols
- Setup nodes and devices,
- Map points to tags, or use direct binding
Alarm Management
- Define alarm areas and groups
- Configure conditions and limits
- Setup notifications
Historian (Time-series Data Collection)
- Configure historian storage
- Set collection rates
- Define retention policies

Pillar 3: Application Modules (Store & Process)

Purpose

Application modules add business logic, data processing, and integration capabilities to transform raw data into actionable information.

What to Build

Database Integration
- Connect to SQL databases
- Create queries and views
- Setup synchronization
Business Logic
- Write calculation scripts
- Implement control logic
- Create data validation
Reporting
- Design report templates
- Configure schedules
- Setup distribution

Detailed Application Modules Guide →

Pillar 4: User Interface (Analyze & Visualize)

Purpose

The UI layer presents information to operators, managers, and stakeholders through interactive displays and dashboards.

What to Build

Operational Displays
- Process graphics
- Control panels
- Navigation structure
Dashboards
- KPI visualization
- Analytics
- Mobile views
Client Deployment
- Rich clients
- Web access
- Mobile UI

Detailed User Interface Guide →

Best Practices

Team

Best Practices

Cross-Fnctional Reuar snc meetingssharedworkspace

RemoteTeams Videocals, screen shrig, cloud tools

Customer Interaction Demos, prototypes,eedback sessions

VendCoordination Clear specifications, reula updates

Next Steps

After Understanding Workfl

Download Templaes
- Project Templates
- DocumentationStandards
ReviewExamples
- Solution Examples
- Case Stuies
G Trning
- Project Management
- Best Practice

Consolidate

Dev to Production Workflow

Overview

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)

Solution Development Workflow

Specification to Solution Flow

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)

Solution Deployment Workflow

Development to Production Flow

Tools Interaction

Complete Solution Lifecycle

== > Link to Development to Production Best Practices and Industry Standard pages.

Stage 1: Initiate (Planning)

Project Definition - Scope Development

Define clear boundaries and objectives:

Project Scope Document
- Business Objectives
  - ROI Targets
  - Efficiency Goals
  - Compliance Requirements
- Technical Requirements
  - I/O Count
  - User Count
  - Integration Points
  - Performance Targets
- Constrains
  - Budget
  - Timeline
  - Resources
  - Technology
- Success Criteria
  - Acceptance Tests
  - Performance Metrics
  - Deliverables

Stakeholder Analysis

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

Requirements Gathering

Functional Requirements Checklist

Process control requirements
Data acquisition needs
Alarm management requirements
Reporting specifications
User interface requirements
Integration requirements
Security requirements
Performance requirements

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
Coils (digital): 100

Stage 2: Design (Architecture)

System Architecture Design

Architecture Decision Matrix

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

Network Architecture

Data Architecture

Tag Naming Convention

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

??? WTP (Water Treatment Plant)
?   ??? PUMP01
?   ?   ??? MOTOR
?   ?   ?   ??? RUNNING
?   ?   ?   ??? SPEED_SP
?   ?   ?   ??? SPEED_PV
?   ?   ??? VALVE
?   ?       ??? OPEN_CMD
?   ?       ??? POSITION
?   ??? TANK01
?       ??? LEVEL_PV
?

UDT Design - UNS Data Template
UDT: MOTOR_VF0

UDT: Motor_VFD
Properties:
  - Name: String
  - Location: String
  - RatedHP: Float
Members:
  Commands:
    - Start_CMD: Boolean
    - Stop_CMD: Boolean
    - Speed_SP: Float (0-100%)
  Status:
    - Running: Boolean
    - Faulted: Boolean
    - Speed_PV: Float
    - Current: Float
    - Temperature: Float
  Alarms:
    - OverCurrent: Boolean
    - OverTemp: Boolean
    - CommLoss: Boolean
  Statistics:
    - RunHours: Double
    - StartCount: Integer
    - LastStartTime: DateTime

Display Architecture

Navigation Hierarchy

Main Menu
??? Overview
?   ??? Plant Overview
??? Areas
?   ??? Area 1
?   ?   ??? Process Overview
?   ?   ??? Equipment
?   ?   ??? Trends
?   ??? Area 2
?   ??? Area 3
??? Utilities
?   ??? Power Monitoring
?   ??? Compressed Air
?   ??? Steam System
??? Reports
?   ??? Production
?   ??? Quality
?   ??? Maintenance
??? Administration
    ??? Setpoints
    ??? Recipes
    ??? User Management

Stage 3: Build (Development)

Development Workflow

Sprint Planning (Example of a 2-Week Sprints)

Sprint 1: Foundation
??? Day 1-3: Create tag database
??? Day 4-6: Build UDTs
??? Day 7-9: Configure devices
??? Day 10: Testing & review

Sprint 2: Process Logic
??? Day 1-3: Alarm configuration
??? Day 4-6: Scripts development
??? Day 7-9: Historian setup
??? Day 10: Testing & review

Sprint 3: Visualization
??? Day 1-3: Template displays
??? Day 4-6: Process graphics
??? Day 7-9: Dashboards
??? Day 10: Testing & review

Sprint 4: Integration
??? Day 1-3: Database connections
??? Day 4-6: Reports
??? Day 7-9: External interfaces
??? Day 10: Testing & review

Configuration Management

Version Control Strategy

Repository Structure:
/FrameworX-Project
??? /Documentation
?   ??? Requirements.docx
?   ??? Design.docx
?   ??? UserManual.docx
??? /Solution
?   ??? MyProject.dbsln
?   ??? /Exports
?       ??? Tags_v1.0.xml
?       ??? Displays_v1.0.xml
??? /Scripts
?   ??? Calculations.cs
?   ??? Reports.sql
??? /Graphics
?   ??? P&ID.svg
?   ??? Logos.png
??? /Tests
    ??? UnitTests.cs
    ??? TestProcedures.xlsx

Change Management Process

Change Request ? Impact Analysis ? Approval ? Implementation ? Testing ? Deployment
? ? ? ? ? ?
Document Assess Risk Get Signoff Make Change Validate Release

Testing Strategy

Test Levels

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 Documentation - Test Case Template

Test ID: TC 001

Feature: Pump Control

Preconditions:

Pump in Auto mode
Tank level at 50&

Steps:

Set Tank Setpoint to 75%
Verify pump starts
Monitor speed increases

Expected Result:

Pump running indication ON
Speed ramps to calculated data
No alarms generated

Actual Result:

Stage 4: Deploy (Production)

Deployment Planning

Pre-Deployment Checklist

All tests passed
Documentation complete
Backup created
Licenses verified
Training completed
Support plan ready
Rollback plan prepared
Maintenance window scheduled

Deployment Sequence

Deployment Sequence

1. Pre-Deployment (T-1 Week)
   * Final testing in staging
   * User training
   * Documentation review

2. Deployment Day (T-0)
   * 00:00 - System backup
   * 01:00 - Install software
   * 02:00 - Import configuration
   * 03:00 - Configure devices
   * 04:00 - Test communications
   * 05:00 - Verify operations
   * 06:00 - Go live

3. Post-Deployment (T+1 Day)
   * Monitor performance
   * Address issues
   * Gather feedback

Commissioning Process

System Commissioning Steps

System Comissoning Step

1. Hardware Ready
2. Software & License Installation
3. Configuration load
4. I/O Checkout
5. Device Testing
6. Function Testing ==> Loop 4, 5, 6 as needed
7. Performance Testing
8. Customer Acceptance
9. Production Release

Commissioning Documentation

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

Stage 5: Support (Maintenance)

Support Structure

Support Tiers

Support Ties

Tier 1: Operations
* Basic troubleshooting
* Restart procedures
* Known issue resolution

Tier 2: Maintenance
* Configuration changes
* Device troubleshooting
* Performance tuning

Tier 3: Engineering
* Complex problems
* System modifications
* Root cause analysis

Tier 4: Vendor
* Software bugs
* License issues
* Advanced support

Maintenance Activities

Preventive Maintenance Schedule

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

Continuous Improvement

Performance Monitoring

KPI Dashboard Example

KPI Dashboard Example

  System Uptime:       99.8%
  Avg Response Time:   187ms
  Alarm Rate:          12/hour
  Data Loss:           0.00%
  User Satisfaction:   4.5/5

Improvement Opportunities:
- Reduce alarm rate (target: <10/hr)
- Optimize response time (<100ms)
- Increase automation (reduce manual tasks)

Tools and Templates

Project Management Tools

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

Standard Templates

Available Templates

Project Charter
Requirements Specification
Design Document
Test Plan
Deployment Guide
Training Materials
Support Procedures
Change Request Form

Quality Gates

Gate Reviews

Gate Review

Gate 1: Design Review
* Requirements complete?
* Architecture approved?
* Risks identified?
* Resources available?
    *
    * Pass
Gate 2: Development Review
* Code complete?
* Testing done?
* Documentation ready?
* Performance met?
    *
    * Pass
Gate 3: Deployment Review
* Customer approval?
* Training complete?
* Support ready?
* Rollback plan?
    *
    * Pass
Production Release

Best Practices

Do's and Don'ts

DO:

? Follow naming conventions consistently
? Document all decisions and changes
? Test thoroughly at each stage
? Include operators in design reviews
? Plan for 20-30% growth
? Use version control
? Create reusable components

DON'T:

? Skip testing to save time
? Ignore user feedback
? Hardcode values
? Forget security considerations
? Deploy without backups
? Assume requirements won't change
? Neglect documentation

Risk Management

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

Workflow Optimization

Automation Opportunities

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

Collaboration Tips

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

Next Steps

After Understanding Workflow

Download Templates
- Project Templates
- Documentation Standards
Review Examples
- Solution Examples
- Case Studies
Get Training
- Project Management
- Best Practices

Page tree

The Four Pillars (Concept)

Why Follow This Methodology?

Field Proven

Benefits of the Four-Pillar Approach

Solution Templates

Quick Start Templates, with guided explorer

Industry Templates

Next Steps

After Understanding the Methodology

Deep Dive Into Each Pillar

Get Hands-ON

Quick Reference Tables

Four Pillars at a Glance

Four Pillars at a Glance

Modules Key Concepts Review

One Line Descriptions

Data Flow Examples

Example 1: PLC to Display

Development Time Estimates

Shorten Dev time & Increase Reliability Checklist

Best Practices Checklist

Design Phase

Development Phase

Deployment Phase

Maintenance Phase

Common Pitfalls and How to Resolve

Why Follow This Methodology?

Benefits of the Four-Pillar Approach

Comm Mistakes to Avoid

Pillar 1: Unified Namespace (Foundation)

Purpose

What to Build

→ Sutin Dev - Use Case Example

Pillar2: Process Modules (Industrial Oerations)

P

Wat to Build

P3: Application Module (Stre & Process)

Purpose

What to B

P 4UserInterface(Analyze& Visualize)

Purpose

WhattoBuild

Consolidate

Dev to Production Worklow

Overvw

Solution Development Workflow

Specification to Solution Flow

SolutionDeployment Workflow

Development toProduction Flow

Tools Interaction

Complete Solution Lifecycle

Stage 1: Iitite (Planning)

Project Definition - Scope Developnt

Stakehler Analysis

RquirementsGathering

unctonal Rquirements Checkist

Stage 2: sgn (Arhitcture)

Sytem ArchitectureDesign

rchitecture Decision Matrix

Network Architecture

Data Architecture

Tag Naming Convention

Disay Archteture

NavigHierarchy

Stage 3ld (Developmet)

Dvelopment Workflow

Sprint Planning (Example of a 2-Week Sprint)

ConfigurationManagement

VersionControlStrategy

TstingStrategy

TestLevels

TestDocumentation-TestCaseTemlate

Stage 4: Deploy (Producton)

Deployment Plnning

Pre-Deploymen Checklst

Deployent Sequence

Cmmissioning Process

System Commissioning Steps

Commssioning Documation