FrameworX embodies the principle of Unified by Design - a single platform architecture that eliminates the traditional boundaries between development, deployment, and runtime environments. This unified approach reflects in the platform's native inclusion of all required modules for real-time applications: industrial process modules (alarms, historian, devices with 100+ connectors) and core application modules (scripts, reports, datasets).
Vision: Aim high, start simple, scale without limits.
The architecture enables you to design once and deploy everywhere - desktop (.NET), web (WebAssembly), and mobile - from a single solution configuration.
Real-Time In-Memory Database
When a solution executes, variables like Tags, Templates, and Assets are loaded into memory, acting as a central point of reference for all functional modules. The TServer.exe process maintains this real-time database, running as either a Windows Service or deployed to Linux and other supported operating systems.
All modules interact with the real-time database through a publish/subscribe model, ensuring consistent data access and efficient performance across the entire system.
Deployment Models
FrameworX provides versatile deployment architectures tailored to your operational requirements, from standalone configurations to sophisticated distributed systems.
| Unified Designer | |
|---|---|
Standalone Configuration
| Distributed Architecture
|
Redundant Systems
| Cloud and Hybrid
|
Typical Deployment Scenarios
Single Server
- Server handles all runtime functions
Stand-Alone System
- Local client via Rich Client or remote SmartClient or Web
- Suitable for machine operation and Edge systems.
Server and Clients System
- Local or remote clients via Rich Client, Web Browser, or Mobile
- Suitable for single-site or line operations
Distributed Systems
- Multiple servers across different plants
- Local operators at each site
- Central control room for enterprise monitoring
- Each site can have redundant server pairs
Distributed Data Acquisition System
Distributed Control System
In a Distributed Data Acquisition System, a server machine hosts device modules communicating with remote PLCs or historians. The SCADA client can be on the same server or a separate computer. This setup is ideal for plants with devices on slow or limited networks, optimized with I/O servers for better performance.
Multiple servers are set up across different plants or projects, enabling access to control rooms for each. Users select the specific plant they wish to monitor since clients for each plant are not integrated into one machine. This setup features discrete locations with local operators and redundant servers for each site.
Redundant Server Configuration
- Primary and backup servers with heartbeat monitoring
- Automatic client reconnection on failover
Local Database with Alarm/Historian Synchronization
Remote Database Cluster
Cloud and Hybrid
Security Zones Secure Data Flow
Key Architectural Benefits
| Benefit | Description | Impact |
|---|---|---|
| Unified Development | Single Designer for all modules | Reduced learning curve |
| Modular Design | Independent module operation | Easier troubleshooting |
| Open Standards | OPC UA, MQTT, REST APIs | Enterprise integration |
| Scalability | From embedded to enterprise | Investment protection |
| Platform Agnostic | Windows, Linux, Docker | Deployment flexibility |
Next Steps
- Review Technology Foundation for development platform details
- Explore Product Editions to select appropriate licensing
- Continue to The Four Pillars for module architecture
1. Solutions Manager (Solution Management)
Our platform enables you to create industrial applications for any platform - you can run it on Windows, Linux, Mac, Routers and Universal Robots. This is the first interface you'll see when running the software and it showcases all the solution files you have. You can create, edit, manage and run solutions from here.
2. Designer (Solution Configuration)
The Designer Workspace allows you to edit solutions’ displays and tags, as well as modules such as Devices, Alarms, Scripts, Datasets and Historian.
3. Runtime (Solution Execution)
When you run your solution, the first UI you'll be presented with is the TStartup, which is responsible for loading everything the solution needs. This includes the TServer, which enables communications with databases, and the modules that will act behind the scenes to display the information the user sees. It will also open the User Interface, which can be either Windows or Web Clients.
one-page orientation + high-level diagram; link to pillars and key runtimes.
Platform Components
Solution Developer Journey: Create → Design → Deploy/Run
Core Components — servers, services, modules; how they fit together.
Workspaces — Solution Center Overview and Designer Workspace (can be siblings or a combined page).
Runtime & Clients — SmartClient/Web, roles, where logic runs.
Platform UI Tools Interaction
Our platform relies on the three components described below. It supports distributed architectures, which means that each one of these software components may be running on one computer, exchanging data with the modules on other computers.
