The Runtime Environment is the active stage where a Solution starts and operates.
Executing a Solution, or starting the Runtime, involves:
When the Runtime Environment loads the module's configuration. Some settings, such as network addresses and database connections, can be applied according to the execution profile. Profiles enable the same solution configuration to interface with various databases and devices, accommodating different phases of the solution life cycle, such as Development, Validation, or Production.
The purpose of the Runtime Environment is to actively operate configured solutions, executing real-time data acquisition, scripts, alarms, and all items from all modules. It represents the essential final phase of solution development, delivering the application's functionality.
Runtime
The term "Runtime" or "Runtime Environment" refers to the execution environment when the solution is running, distinguishing it from the Configuration (or Engineering, or Development) phase. "Runtime" also denotes the software components and computer processes that are in execution when the solution is started.
Execution Profile
An Execution Profile consists of settings that allow customization of database connections and device network addresses. This enables the management of different environments.
Online Configuration
This feature allows real-time modifications to a running solution without stopping its execution. Users can adapt the solution to changing requirements, enhancing flexibility and responsiveness.
Hot Updates / Hot Reload
Hot Updates are a subset of online configurations that allow the application of offline solution changes without disrupting the runtime environment. They maintain solution stability and prevent downtime, ensuring the solution remains up-to-date with the latest changes.
Build and Publish
The Build process involves compiling the solution code. The Publish process creates a read-only version of the solution for distribution in regulated sites.
When the solution is in execution, variables like Tags, Templates, and Assets are loaded into the memory. These variables act as a central point of reference, allowing other functional modules to request or publish values as they perform their functions. The computer process and executable responsible for maintaining the real-time database is TServer.exe. This application can run as a Windows Service or be deployed to Linux and other supported operating systems.
→ For details on the startup procedure review the Runtime Startup Settings page.
→ For details on setting up the execution review the Solution Deployment (Reference) page.
During Runtime, the Four Pillars transform from static configuration into an active system. Each pillar operates as an independent yet interconnected layer, with data flowing from field devices through the foundation layer, processed by business logic, and presented to users through visualization interfaces.
When a solution starts, each pillar activates in sequence:
[Field] → [Devices] → [UNS Tags] → [Scripts] → [Displays]
↓ ↓ ↓ ↓
[Alarms] [Historian] [Datasets] [Clients]
From Pillar | To Pillar | Method |
|---|---|---|
| Process → Foundation | Tag writes | Direct memory update |
| Foundation → Application | Tag changes | Event notifications |
| Application → Foundation | Calculated values | Tag writes |
| Foundation → Interface | Value updates | Subscription/publish |
| Interface → Foundation | Operator commands | Tag writes |
Different runtime behaviors for the same configuration:
The Runtime executes your solution (real-time tags, UNS, modules, utilities). Clients (desktop & web) visualize and interact with the running system. This page explains how execution works and how clients connect.
On this page
Execution model (Runtime, services, UNS)
Client types (desktop, web)
Basic diagnostics you’ll use first
Component | Function | Access |
|---|---|---|
| TServer | Core execution engine | Runs as service |
| Tag Database | Real-time data storage | In-memory |
| Module Engines | Execute specific functions | Auto-started |
| Client Server | Serves displays to clients | TCP port 9000 |
The Runtime Module executes your configured solution, transforming the static configuration into an active system. It loads tags into memory, processes real-time data, executes scripts and alarms, and serves information to clients - making your solution come alive.
When you start the Runtime:
Aspect | Development | Production |
|---|---|---|
| Purpose | Testing and debugging | Live operation |
| Database | Local SQLite | SQL Server |
| Diagnostics | Full logging | Minimal overhead |
| Changes | Online edits allowed | Protected operation |
| Performance | Debug information | Optimized speed |
Access runtime information through:
Pillar | Primary Memory Use | Typical Range |
|---|---|---|
| Foundation (UNS) | Tag values, templates | 100MB - 2GB |
| Process Modules | Communication buffers | 50MB - 500MB |
| Application Modules | Script execution | 100MB - 1GB |
| User Interface | Display cache | 50MB - 200MB per client |
Parallel Execution: Each pillar's modules run independently
Priority Management: Critical operations get precedence
TServer.exe starts (< 5 seconds)
Module activation (5-30 seconds)
Steady state (< 60 seconds)
The Solution Center maintains a real-time view of all available solutions through file system monitoring and server connections. Solution files (.dbsln) contain complete configurations as encrypted embedded SQL databases, enabling portability and backup.
Solution Center supports three primary access modes:
Local Access: Direct file system access to solutions on the local computer
Server Connection: Remote access via TWebServices
Web UI Access: Browser-based interface
http://<server>:10108/solutions| State | Description | Visual Indicator |
|---|---|---|
| Stopped | Solution not running | Gray icon |
| Running | Active in Runtime | Green icon |
| Designing | Open in Designer | Blue icon |
| Error | Execution failure | Red icon |
| Starting | Initialization phase | Yellow icon |