Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Operations Business Logic

& Data

→ Visualization

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

:

Image Removed

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

BenefitDescriptionImpact
Structured DevelopmentClear sequence of implementationReduced errors and rework
ScalabilityFoundation supports growthEasy expansion without redesign
MaintainabilityOrganized architectureSimplified troubleshooting
ReusabilityTemplate-based approachFaster development
Best PracticesIndustry-proven patternsReliable solution

Solution Templates

Quick Start  Templates, with guided explorer

Template

Description

Components

Time to Explore

Basic HMISimple machine interfaceDisplays. Modbus , TouchPanel UI10 minSCADA StarterSmall SCADA systemAlarms, trends15 minMES InterfaceProduction trackingDatabase, reports, KPIs20 minIIoT & MQTTMQTT Edge IntegrationMQTT Broker, Client & Publisher & SQL15 minCentral Server
ProveIt!
Situational Awareness,
Corporation LevelEnterprise Unlimited, Local & Extended UNS, Direct Binding to MQTT20 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

This field-proven approach has been refined across hundreds of deployments to minimize rework and maximize reliability.

On this page:

Table of Contents
maxLevel2
minLevel2
indent10px
excludeSteps
stylenone



The Four Pillars Overview

Image Added


Pillar

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

UNSData foundationTags, Assets, UDTsFirst
ProcessField integrationDevices, Alarms, HistorianSecond
ApplicationBusiness logicScripts, Datasets, ReportsThird
InterfaceVisualizationDisplays, Dashboards, ClientsFourth

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,0001-2 weeks1 personMedium1,000-10,0004-8 weeks2-3 peopleLarge10,000-50,0003-6 months3-5 peopleEnterprise>50,0006-12 months5+ 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 doReasonStart with UNS, not DisplaysDisplays seems easier, but without proper data structure, the total development time increases, and reliability decreases.Leverage UNS featuresLocal 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 standardConfusion, errorsDefine and enforce standards earlySkipping UDTsMaintenance nightmareCreate templates for all equipmentOver-polling devicesPerformance issuesOptimize scan rates based on needsComplex displaysOperator confusionFollow ISA-101, simplify graphicsNo documentationSupport difficultiesDocument as you buildIgnoring securityVulnerabilitiesImplement 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    ?                                   ?
?                         ????????????????                                   ?
??????????????????????????????????????????????????????????????????????????????

Why Follow This Methodology?

Benefits of the Four-Pillar Approach

Benefit

Description

Impact

Structured DevelopmentClear sequence of implementationReduced errors and rework
ScalabilityFoundation supports growthEasy expansion without redesign
MaintainabilityOrganized architectureSimplified troubleshooting
ReusabilityTemplate-based approachFaster development
Best PracticesIndustry-proven patternsReliable 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 Image Added

Asset TreeImage Added

User Data TypesImage Added

  • 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)
  • -
  • Enable asset-based navigation
  • Create equipment templates
  • Define standard objects
  • Build reusable components

→ Solution Dev - Use Case Example

  • Ensure consistency

[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 CommunicationsImage Added

Alarm ManagementImage Added

HistorianImage Added

  • Configure channels and
protocols
  • protocols 
  • Setup nodes and devices
,
  • Map points to tags
, or use direct binding
  • Optimize scan rates
  • -
Alarm Management
  • Define alarm areas and groups
  • - Configure conditions and limits
  • - Setup notifications -
Historian (Time-series Data Collection)
  • Implement ISA-18.2 standards
  • Configure data
Configure historian
  • storage
  • Set collection rates
  • Define retention
policies
  • policies 
  • Plan for growth

[Detailed Process Modules Guide →]


Pillar 3: Application Modules (

Store & Process

Business Logic)

Purpose

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

What to Build

Database Integration

ScriptsImage Added

DatasetsImage Added

ReportsImage Added

  • Write calculation logic
  • Implement workflows
  • Create data validation
  • Automate processes
  • Connect to SQL
databasesReporting
  • databases 
  • Create queries and views
  • Setup synchronization
  • Business Logic
    • Write calculation scripts
    • Implement control logic
    • Create data validation
    • Manage transactions
    • Design report templates
    • Configure schedules
    • Setup distribution
    • Export formats (PDF//XML/JSON)

    [Detailed Application Modules Guide →]


    Pillar 4: User Interface (

    Analyze & Visualize

    Visualization)

    Purpose

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

    What to Build

    Operational DisplaysImage Added

    DashboardsImage Added

    Operator UI ClientsImage Added

    • Process graphics
    • Control panels
    • Navigation structure
    Dashboards
    • Alarm summaries
    • KPI visualization
    • Analytics views
    • Mobile
    views
    • layouts
    Client Deployment
    • Executive summaries
    • Rich & Smart clients (.NET)
    • Web access (WebAssembly)
    • Mobile UI (Responsive)
    • Multi-monitor setup


    [Detailed User Interface Operator UI Guide →]

    Consolidate 

    Solution Ready to Run (Secure & Deploy)

    Purpose

    Solution ready to Run, validate, apply security, and deploy.

    What to Do

    RuntimeImage Added

    SecurityImage Added

    DeploymentImage Added

    • Test with Execution Profiles
    • Development Environment (Lab)
    • Validation Environment (FAT)
    • Production Environment (SAT)
    • Protect Configuration
    • Secure Scripts and IP
    • Defile Users & Roles
    • Apply on Operator UI
    • Single file deployment
    • Publish to FDA & regulated area
    • Container for Edge & Cisco Routers
    • Setup Version Control & Maintenance 

    [Detailed Solution Runtime Guide →]


    Why This Methodology Works

    Benefits of the Four-Pillar Approach

    BenefitDescriptionImpact
    Structured DevelopmentClear sequence of implementation50-70% reduction in rework
    ScalabilityFoundation supports growthEasy expansion without redesign
    MaintainabilityOrganized architectureSimplified troubleshooting
    ReusabilityTemplate-based approach40% faster development
    Best PracticesIndustry-proven patternsReliable solutions

    Common Mistakes to Avoid

    (error) Starting with displays - Without proper data structure

    (error) Skipping UDTs - Leading to tag sprawl

    (error) Direct device-to-display binding - Creating maintenance nightmares

    (error) Ignoring naming conventions - Causing confusion later

    (error) Building monolithic solutions - Instead of modular architecture



    Solution Templates

    Quick Start Templates

    TemplateDescriptionComponentsTime to Explore
    Basic HMISimple machine interfaceDisplays, Modbus, TouchPanel UI10 min
    SCADA StarterSmall SCADA systemAlarms, trends, reports15 min
    MES InterfaceProduction trackingDatabase, reports, KPIs20 min
    IIoT & MQTTEdge IntegrationMQTT Broker, Client, SQL15 min
    Enterprise ProveIt!Corporate LevelEnterprise Unlimited, Extended UNS20 min



    Development Workflow

    Image Added

    Solution Development Stages

    InitiateDesignBuildDeploySupport
    • Requirements
    • Scope
    • Resources
    • Architecture
    • UNS design
    • Standards
    • Configuration
    • Testing
    • Integration
    • Installation
    • Commissioning
    • Training
    • Maintenance
    • Optimization
    • Updates

    Platform UI Components

    Three Essential Workspaces


    Image Added


    UI EnvironmentPurposeKey Functions
    Solution CenterSolution Management
    • Create/open solutions
    • License management
    • Server configuration
    • Launch Designer and Runtime
    DesignerSolution Configuration
    • UNS Configuration
    • Process Modules Design
    • Application Modules Design
    • Operator UI Design
    Runtime

    Solution Execution

    • Real-time data processing
    • Client connections
    • Module execution
    • Performance monitoring



    Quick Reference Tables

    Development Time Estimates

    Solution SizeTagsDevelopment Time (*)Team Size
    Small<1,0001-2 weeks1 person
    Medium1,000-10,0004-8 weeks2-3 people
    Large10,000-50,0003-6 months3-5 people
    Enterprise>50,0006-12 months5+ people

    (*) About the Development Time estimates

    Best Practices Checklist

    DO:DON'T:

    ?(tick) Start with UNS design

    ?(tick) Use naming conventions

    ?(tick) Create UDTs first

    ?(tick) Test each pillar

    ?(tick) Document decisions

    ?(tick) Use version control

    ?(error) Start with displays

    ?(error) Skip testing phases

    ?(error) Hardcode values

    ?(error) Ignore standards

    ?(error) Build without UDTs

    ?(error) Deploy without backup



    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
    root@parent
    spaces93DRAF

    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

    Image RemovedUnified Namespace (Local UNS)

    Image RemovedSQL Database Connections and Queries

    Image RemovedDataExplorer

    Image RemovedScripts and Business Logic

    Image RemovedExtended UNS using Direct Binding

    Image RemovedReports, data pub (PDF, CSV, HTML, XML & JSON

    (3)  Setup Application Modules (4) User Interface Design

    Image RemovedDevices, Field Connections

    Image RemovedSymbol Library extensions

    Image RemovedAlarms, Events, and Audit-trail

    Image RemovedUnified Designer (Canvas & Responsive Dashboard)

    Image RemovedHistorian, time-series data

    Image RemovedLayouts, Desktop (.NET), Web &r Mobile (WebAssembly)

    Solution Deployment Workflow

    Development to Production Flow

    Image Removed

    Tools  Interaction

    Image Removed

    Complete Solution Lifecycle

    Image Removed

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

    OperationsEnd UsersIntuitive interface, reliable operationEase of use, training
    MaintenanceSupport StaffDiagnostic tools, documentationTroubleshooting, updates
    ManagementDecision MakersReports, KPIs, ROICost, timeline, benefits
    ITInfrastructureSecurity, integration, standardsCompliance, compatibility
    EngineeringTechnical DesignFlexibility, features, performanceTechnical 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

    DeploymentStandaloneDistributedDistributedMultiple sites
    DatabaseSQLiteSQL ServerSQL ServerScale requirements
    RedundancyNoneHot-StandbyHot-StandbyCritical process
    ClientsRich onlyRich + WebRich + WebRemote access
    HistorianLocalEnterpriseEnterpriseCorporate reporting

    Network Architecture

    Image Removed

    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 TestingIndividual componentsDeveloperDesigner test mode
    Integration TestingModule interactionsDeveloperRuntime test
    System TestingComplete solutionQA TeamTest scripts
    Acceptance TestingBusiness requirementsCustomerTest procedures

    Test Documentation - Test Case Template

    Test ID: TC 001

    Feature: Pump Control

    Preconditions:

    • Pump in Auto mode
    • Tank level at 50&

    Steps:

    1. Set Tank Setpoint to 75%
    2. Verify pump starts
    3. 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 ListVerify all pointsControls Engineer
    Loop SheetsTest each control loopTechnician
    Alarm ListVerify alarm functionsOperations
    Interlock MatrixTest safety interlocksSafety Engineer
    Performance LogRecord system metricsSystem 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

    DailyCheck system status, Review alarms, Monitor performanceOperations
    WeeklyBackup solution, Review logs, Check disk spaceMaintenance
    MonthlyArchive data, Update documentation, Performance analysisEngineering
    QuarterlySecurity review, Disaster recovery test, Training updateManagement
    AnnuallyLicense renewal, Major updates, System auditAll 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-ReferenceGovernancemonitor governance of all places a object is used.Track RecentChangesVersion Controllight, built-in, record of latest used phasesTrack  Unused objectsOptimizationIdentify objects potentially not in useTrack VersionControlVersion ControlKeep automated VersionID to all modules, tables and objects. Global VersionID for entire solution. Build, backup flagBackup/Restore pointCrete a backup copy of product current stagePublish Lock production versionFDA compliance, lock solution file version

    Third-party recommend tools

    Tool

    Purpose

    Comments

    JIRA//Azure DevOpsTask trackingcritical for maintenance  and product phasesGit/SVNVersion controlAdd comparing version, in top of built-in FrameworX TrackChanges toolsConfluenceDocument managementAll phasesTeams/SlackCommunicationAll 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 CreepHighHighClear change control process
    Integration IssuesMediumHighEarly testing, vendor support
    Performance ProblemsMediumMediumLoad testing, optimization
    User ResistanceMediumMediumTraining, involvement, support
    Hardware DelaysLowHighEarly 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-FunctionalRegular sync meetings, shared workspace
    Remote TeamsVideo calls, screen sharing, cloud tools
    Customer InteractionDemos, prototypes, feedback sessions
    Vendor CoordinationClear specifications, regular updates

    Next Steps

    After Understanding Workflow

  • Download Templates
  • Review Examples
  • Get Training
  • Project Management
  • Best Practices