Overview

Mention Key Concept: UNFIED BY DESIGN. Linke to tech pages on it. multiplategrationT Pyton int, WEbAssembly, 100+ 

The Unfied By Design relflect I the achcure with the adroit of Local UNS concept and all modules included.

Vision: Aim high, start simple, scale without limits. 

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.

Enterprise UNS

Image Removed

Locan UNS

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.

Image Removed

Connectify build in

Universal Connectivity for the Modern Industrial Enterprise

The FrameworX 10.1 Connectivity Hub bridges the gap between OT and IT. Seamlessly integrate data from PLCs, databases, historians, specialized equipment, and cloud platforms with 100+ native connectors and drivers.
Our native communication drivers provide high-throughput, secure, and reliable connections directly within the platform, accelerating your time-to-insight and simplifying your architecture.

Eliminate Data Silos and Bridge the OT/IT Divide

Sector

Group

#

Standard Protocols

Vertical Protocols

Automation Vendors

Factory-Floor Interfaces

Historian & Databases

AI, Cloud & Network

11

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.

Typical Deployment Scenarios

Single Server

• Server handles all runtime functions

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

Platform Components

Solution Developer Journey: Create → Design → Deploy/Run

1. Core Components — servers, services, modules; how they fit together. 

2. Workspaces — Solution Center Overview and Designer Workspace (can be siblings or a combined page). 

3. Runtime & Clients — SmartClient/Web, roles, where logic runs.

Platform UI Tools  Interaction

Platform Components

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.

Depoloyment models

Our platform provides versatile deployment choices tailored to your operational requirements. Whether you require a straightforward standalone configuration with both server and client components on a single machine or a sophisticated distributed system optimized for slower networks, our platform seamlessly adjusts.

Our platform is adept at managing client and server systems, whether they are networked computers or accessed remotely via WAN or Cloud. Additionally, it facilitates distributed control systems across various plants for real-time monitoring and management. For mission-critical applications, you have the option to deploy redundant servers with automatic failover and data synchronization, ensuring continuous operation.

Deployment Architectures

Standalone Configuration

• Single server with local clients
• Ideal for small to medium applications
• Simplified maintenance

Distributed Architecture

• Multiple servers across locations
• Distributed Remote I/O and UI Portal (DataHubNode & ApplicationNode)
• Enterprise-wide solutions

Redundant Systems

• Hot-standby failover
• No data loss during switchover
• Mission-critical applications

Cloud and Hybrid

Typical Deployment Scenarios

Our platform supports projects ranging from Edge applications on embedded devices to large-scale distributed applications.

This section covers some standard deployment architectures.

Stand-Alone System

In a Stand-Alone System, all components run on one machine, like a Windows desktop or industrial PC, serving as both server and client. It can also act as an Edge data collector for remote platforms.

ingle server with local or remote clients

Distributed Data Acquisition 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.

Client and Server System

In a Client and Server System, the platform's server handles server-side modules such as alarms, historians, and data acquisition.

Operator client stations run on other networked or remote computers connected via WAN or Cloud interface.

Distributed Architecture

Distributed Control System

In a Distributed Control System, 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, along with a central control room for simultaneous monitoring of all sites. Each site is represented by a separate cluster comprising primary and standby servers.

Redundant Systems

Redundant Server System

The Redundant Server System comprises two separate computers running the platform's servers, with redundancy managed automatically. Simply specify the IP addresses of the primary and secondary stations. Here are some common deployment scenarios:

• The Alarm and/or Historian database is hosted on a third machine dedicated to historical data.
• Both primary and secondary servers store historical data for the Alarm and/or Historian modules, with automatic data synchronization.
• Redundancy is implemented for the device module (PLC communication).

Redundant Server System With Centralized DB

Cloud and Hybrid

Security Zones - L1 to L4 (Concept)

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.

1. one-page orientation + high-level diagram; link to pillars and key runtimes. 

Stand-Alone System

In a Stand-Alone System, all components run on one machine, like a Windows desktop or industrial PC, serving as both server and client. It can also act as an Edge data collector for remote platforms.

-----

Consolidation to do: