Page History

...

Comprehensive product knowledge, for AI integration builders and advanced users.

Platform → Overview | Architecture Installation |Technology | Security | FrameworX |  Editions 

...

 Solution | Modules | Controls | Code | Troubleshooting

...

This page provides a comprehensive view of the FrameworX platform architecture, covering every module, data model, syntax rule, and integration pattern. It is designed for AI assistants working with FrameworX MCP services, system integrators building complex solutions, and advanced users who want a single-page understanding of how all platform components connect.

For getting started, see [Quick Start Guide]. For module-specific tutorials, see [BUILD section]. This page is the architectural map — not a tutorial.

This page provides a comprehensive view of the FrameworX platform architecture, covering every module, data model, syntax rule, and integration pattern. It is designed for AI assistants working with FrameworX MCP services, system integrators building complex solutions, and advanced users who want a single-page understanding of how all platform components connect.

For getting started, see [Quick Start Guide]. For module-specific tutorials, see [BUILD section]. This page is the architectural map — not a tutorial.

...

Platform Overview

FrameworX is a unified SCADA/HMI/IIoT platform built on .NET, designed for industrial automation, process monitoring, and real-time data management. The platform runs on dual frameworks — .NET Framework 4.8 for Windows deployments and .NET 8 for multiplatform deployments including Linux, Docker, and edge devices.

...

The Solution Designer is the Windows-based configuration environment where solutions are built and tested. The Runtime Engine (TServer.exe) executes solutions on any supported platform. Operator interfaces run as Rich Clients (WPF desktop), Web Clients (WebAssembly via Blazor), or Mobile Clients. The Solution Manager SolutionCenter provides a visual launcher for selecting and starting solutions.

FrameworX provides two AI integration services through the Model Context Protocol (MCP). The MCP for Designer service connects AI models to the Designer application for solution configuration — creating tags, displays, alarms, and all other objects through natural language. The MCP for Runtime service connects to running solutions for live data access — querying tag values, alarm status, and historian data. Both services enable AI-assisted industrial automation without requiring programming knowledge.

...

The Unified Object Model

Everything in FrameworX is an object in a unified namespace. Configuration, runtime, and navigation are three views of the same data:

When you create a row in a configuration table, it immediately becomes a runtime object accessible via its namespace path. There is no separate deployment or compilation step — the runtime reads directly from the solution database.

Solutions are stored as .dbSLN files (SQLite databases containing all configuration tables). This single-file format supports atomic solution management, JSON export/import per table for Git-based version control, and full solution export as ZIP archives for DevOps workflows.

...

Naming, Syntax, and Separators

Separator Rules

FrameworX uses two separators with precise, distinct roles:

...

Mixing these separators is the most common integration error. Built-in namespaces never use slashes — Server.DateTimeInfo.Second is correct, Server/DateTimeInfo/Second is not. Tag paths never use dots for folders — Tag.Area1/Line1/Tank1 is correct, Tag.Area1.Line1.Tank1 is not.

Syntax by Context

Object references follow different syntax rules depending on where they appear:

...

Current Level: {Tag.Tank1/Level}

The .Value Property

.Value is the default property for Tags. Writing @Tag.Tank1 and @Tag.Tank1.Value is equivalent. Other tag properties must be specified explicitly: @Tag.Tank1.Quality, @Tag.Tank1.Min, @Tag.Tank1.Max, @Tag.Tank1.Timestamp.

Built-in namespaces do not use .Value — they expose named properties directly. Use @Server.DateTimeInfo.Second, not @Server.DateTimeInfo.Second.Value.

The Asset() Function

The Asset function provides dynamic access to the Unified Namespace:

...

Asset paths use no namespace prefix — they map directly to the UNS hierarchy. This function is essential for TagProvider-sourced tags with dynamic addresses, where the tag path is not known at configuration time.

Key Column Patterns

Different tables use different key columns, and understanding which format each expects prevents common integration errors:

...

ObjectName is used by ScriptsExpressions. It binds a calculation to a namespace object. Format: full namespace path like Tag.Machine1/Level — requires the namespace prefix, no @, no .Value.

Singleton tables (SolutionSettings, AlarmsGlobalSettings, RuntimeStartup) have no key column — they contain a single configuration row.

Module Architecture

Tags — The Data Foundation

The Tags module provides the Unified Namespace (UNS) — the central real-time data repository that all other modules connect to.

UnsTags contains process data points organized in a hierarchical folder structure using / separators. The Name column holds the full path: Area1/Line1/Tank1/Level. Supported data types include Digital (Boolean), Integer, Double, String, DateTime, TimeSpan, and JSON.

Tags have a Domain property: Server domain (default) synchronizes values across all connected clients, while Client domain keeps values local to each client instance. Built-in client tags like @Client.UserName and @Client.Session.ComputerNameprovide session context.

UnsUserTypes defines custom tag templates (UDTs). When a UserType is defined with members such as Setpoint, ProcessValue, and AlarmLimit, creating a tag of that type automatically creates all member tags. Modifying the UserType definition auto-updates every tag instance — members are added, removed, or changed across the entire solution automatically. Members are accessed via dot notation: Tag.Loop1.Setpoint.

UnsTagProviders connects external data sources that dynamically populate the UNS with tags. When a TagProvider connects to an MQTT broker or OPC UA server, it discovers and creates tags automatically.

UnsEnumerations maps between numeric values and human-readable text labels.

Devices — Field Equipment Communication

The Devices module connects FrameworX to PLCs, sensors, controllers, and other field equipment through a three-layer architecture:

Key Columns: When using write_objects, tables with a Name field require only the name. Tables using TagName or ObjectName require both key columns to uniquely identify an object:

Singleton tables (SolutionSettings, AlarmsGlobalSettings, RuntimeStartup, DisplaysClientSettings) have no key column — they contain a single configuration row. RuntimeExecutionProfiles for AI will show only the differences between Development and Production profiles, directly on the Designer UI it has more options. 

...

Module Architecture

Tags — The Data Foundation

The Tags module provides the Unified Namespace (UNS) — the central real-time data repository that all other modules connect to.

UnsTags contains process data points organized in a hierarchical folder structure using / separators. The Name column holds the full path: Area1/Line1/Tank1/Level. Supported data types include Digital (Boolean), Integer, Double, String, DateTime, TimeSpan, and JSON.

Tags have a Domain property: Server domain (default) synchronizes values across all connected clients, while Client domain keeps values local to each client instance. Built-in client tags like @Client.UserName and @Client.Session.ComputerNameprovide session context.

UnsUserTypes defines custom tag templates (UDTs). When a UserType is defined with members such as Setpoint, ProcessValue, and AlarmLimit, creating a tag of that type automatically creates all member tags. Modifying the UserType definition auto-updates every tag instance — members are added, removed, or changed across the entire solution automatically. Members are accessed via dot notation: Tag.Loop1.Setpoint.

UnsTagProviders connects external data sources that dynamically populate the UNS with tags. When a TagProvider connects to an MQTT broker or OPC UA server, it discovers and creates tags automatically.

UnsEnumerations maps between numeric values and human-readable text labels.

Devices — Field Equipment Communication

The Devices module connects FrameworX to PLCs, sensors, controllers, and other field equipment through a three-layer architecture:

DevicesChannels configures the communication protocol. FrameworX DevicesChannels configures the communication protocol. FrameworX includes 70+ native drivers: OPC UA, OPC DA, Modbus TCP/RTU, Siemens S7, Allen-Bradley EtherNet/IP, MQTT, MQTT Sparkplug B, BACnet, DNP3, IEC 61850, and many more.

...

Six columns in Nodes and Points are protocol-dependent: ProtocolOptions, Interface, PrimaryStation, BackupStation, Address, and DataType. Their valid values change based on the protocol selected in the parent Channel. When configuring devices programmatically, always query the protocol schema to determine valid field values and formats.

Alarms — Event Detection and Notification

AlarmsGroups defines behavior rules including notification methods, escalation procedures, and acknowledgment requirements. Three groups are predefined: Critical (highest severity), Warning (operational attention), and AuditTrail (logging without operator notification).

...

AlarmsGlobalSettings is a singleton table containing alarm module defaults such as acknowledgment requirements and notification options.

Historian — Time-Series Data Storage

HistorianStorageLocations defines where historical data is stored. The predefined TagHistorian location uses SQLite by default and can be changed to SQL Server, PostgreSQL, or other supported databases.

...

HistorianHistorianTags specifies which tags are logged to which historian table, referenced via the TagName column.

Datasets — Database Connectivity

The Datasets module provides bidirectional database access for SQL integration, reporting data sources, and external system connectivity.

...

DatasetsFiles handles file-based data operations independent of database connections.

Scripts — Automation Logic

The Scripts module supports three languages: C#, VB.NET, and Python. Cross-language interoperability is fully supported — a C# task can call a Python class and vice-versa.

...

ScriptsReferences registers external .NET DLL libraries for use in scripts — an advanced feature for integrating custom compiled code.

Displays — Operator Interface

The Displays module provides the visualization layer with two distinct display paradigms:

...

Symbols deserve special attention. Unlike controls which have fixed behavior, symbols are fully customizable components created by solution developers. FrameworX provides five WizardSymbols (TANK, VALVE, PUMP, MOTOR, BLOWER) with built-in dynamic behavior and easy appearance customization — these cover the most common industrial visualization needs. The Symbols Library contains approximately 1,600 additional pre-built symbols (roughly 800 with dynamic behavior and 800 drawing-only) that can be imported into solutions. Symbols referenced in displays that are not present in the solution are auto-imported from the shared library automatically.

Layout System

DisplaysLayouts defines the screen regions for the running application. A layout can include up to five regions: Header (top), Footer (bottom), Menu (left side), SubMenu (right side), and Content (center, filling remaining space). A StartupLayout object determines which regions are active and which display loads in each region when the solution starts.

MainPage plays a dual role. It is the default display loaded into the Content region at startup, and it also serves as the solution preview image — the Solution Manager SolutionCenter shows whatever is rendered on MainPage as the solution thumbnail when selecting solutions to open.

Reports

ReportsForms defines document-based reports with formatted output. ReportsWebData provides JSON and XML data feeds. Both are independent of each other and depend only on the tags referenced within them.

Security

The Security module manages authentication, authorization, and access control through four tables:

...

SecuritySecrets stores credentials for external system authentication. Secret values are write-only and cannot be read back through any API.

Settings

Three singleton configuration tables control global solution behavior:

SolutionSettings contains global solution parameters. AlarmsGlobalSettings provides alarm module defaults. RuntimeStartup controls startup behavior, execution profile selection, and runtime options.

Runtime Architecture

Startup Sequence

The FrameworX runtime follows a seven-step startup sequence:

Solution and Runtime Configuration

SolutionCategories defines labels applied to any object in the solution. The predefined MCP category marks AI-created objects — AI can only modify objects that have this label. That label is added automatically when document was created by AI. User can apply or remove it manually in any object.

Four singleton configuration tables contain global settings with a single configuration row each:

SolutionSettings contains global solution parameters. AlarmsGlobalSettings provides alarm module defaults. RuntimeStartup controls startup behavior and runtime options. RuntimeExecutionProfiles defines connection replacements between Development and Production profiles — for example, different server addresses per execution profile.

...

Runtime Architecture

Startup Sequence

The FrameworX runtime follows a seven-step startup sequence:

1. TStartup.exe launches — loads the solution file, reads configuration, parses command line TStartup.exe launches — loads the solution file, reads configuration, parses command line arguments, and activates the runtime engine
2. TServer.exe starts — loads all objects, tags, templates, and assets into the real-time in-memory database and establishes the communication service
3. Modules initialize — Historian, Alarms, Devices, Scripts, Datasets, and Reports start their services and connect to the main runtime process
4. Execution profiles applied — modules configure themselves according to the selected profile (Development provides full access for testing; Production restricts modifications for operational safety)
5. Designer auto-connects — if the Solution Designer is open, it connects to the running solution for live monitoring and diagnostics
6. Client displays open — operator interfaces (WebAssembly or WPF) can be launched from any networked computer
7. Online changes applied — configuration changes made during runtime are applied through hot reload without disrupting the running solutionare applied without disrupting the running solution. If the online configuration is enabled, the modifications are pushed right away. If the configuration online is disabled, or the modifications requires restart of modules, like changing UTDs, tag types, or other modifications there requires validation of scripts, or may have global impact, those require the command hot_rreload. That command is on Designer, Runtime Diagnostics pages, or by the AI MCP for Designer tools.

Execution Profiles

Development profile provides unrestricted access for configuration, testing, and debugging. Production profile enforces operational restrictions appropriate for live industrial environments. The MCP for Designer service operates under the Development profile.

Built-in Runtime Namespaces

In addition to module namespaces (Tag, Alarm, Device, etc.), FrameworX provides built-in system namespaces:

...

These namespaces are browseable at runtime — use the MCP browse functionality or Designer's runtime navigation to discover all available properties.

Server and Client Domains

Tags with Server domain (the default) have their values synchronized across all connected clients. A value change made by one operator is immediately visible to all others.

Tags with Client domain maintain separate values for each client instance. These are used for UI state, user preferences, navigation context, and session-specific data that should not propagate to other users.

...

JSON Exchange Format

Table JSON Structure

Solution configurations can be exchanged as JSON files organized per table. Each file contains a header identifying the solution and table type, followed by an array of objects:

...

Full solution exports produce ZIP archives containing one JSON file per table.

Simple Objects vs Document Objects

Simple objects (Tags, Alarm Groups, Device Nodes, Historian Tags, and most other table rows) support property merge on write. When updating, only the fields included in the JSON are modified — all other fields retain their current or default values. This allows targeted updates without reading the full object first.

Document objects (Displays, Symbols, Script Tasks, Script Classes, Dataset Queries, Report Forms, and Report WebData) require full replacement on write. The entire object definition is replaced with the provided JSON. To modify a document object safely, first read its current configuration, apply changes to the JSON, then write the complete modified version back.

...

TrackChanges and Diagnostics

FrameworX provides built-in audit and diagnostic capabilities through four system tables:

...

These tables are query-only diagnostic tools available through the MCP get_track_changes operation.

...

AI Integration Architecture

Two MCP Services

FrameworX provides two separate Model Context Protocol services for AI integration:

...

The two services are completely independent processes with no shared state. They can run simultaneously, allowing AI to both configure solutions and query live data in the same workflow.

AI-Accessible Object Protection

FrameworX uses a category label system to control which objects AI can modify through the MCP for Designer service. Objects created through MCP tools are automatically labeled for AI access. In , with the label MCP added to the Category of object.  In new solutions created from templates, all predefined objects (MainPage, default alarm groups, predefined databases) are also labeled, giving AI full creative control from the start.

For existing solutions that were not created through AI, objects must be explicitly labeled for AI access by the solution developer. This prevents AI from accidentally modifying production configurations while still allowing intentional AI-assisted modification of specific objects.

...

Terminology Quick Reference

...

Related Documentation

Getting Started: [Quick Start Guide] — Build your first solution in 30 minutes

...