FrameworX 10.1 — Complete Architecture Reference

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

...

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.

...

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:

...

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:

...

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.

...

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:

...

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

1. 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 solution

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

...