Overview
The Runtime Startup section of the Designer Interface allows you to start and stop the execution of the solution, specify the execution profile you want to use, and customize all connection settings for that execution.
The settings defined here are also applied when the startup is executed via the Start Solution command line or when starting the solution as a Windows service. This section focuses on the various settings when using the Designer configuration tool. For advanced information to run solutions in production environments, refer to the page Solution Deployment.
On this page:
Table of Contents | ||||
---|---|---|---|---|
|
Runtime Startup Settings
Runtime Startup Page when All Features are enabled
Runtime Startup Page, when Basic Modules Filter is Selected
Note | ||
---|---|---|
| ||
Some specific configurations, including Windows Authentication and Windows Service |
Introduction to Solution Execution and Runtime
Solution Execution and Runtime designate the active stage where a Solution operates. This involves the utilization of functional Modules, data acquisition and processing, updating visual displays, and carrying out other tasks in accordance with the solution's specified configuration.
The runtime environment consists of all the Modules loaded and operating according to the solution configurations. This setup is directed by Execution Profiles, which guide the solution's connections and actions. These profiles enable the same solution configuration to interface with various databases and devices, accommodating different phases such as Development, Validation, or Production.
A distinct feature of this runtime framework is its Online Configuration, which supports real-time adjustments to an actively running solution without causing any disruption to its execution. Additionally, Hot Updates facilitate the seamless integration of offline solution changes, ensuring flexibility and adaptability in the continuing runtime environment.
On this page:
Table of Contents | ||
---|---|---|
|
Purpose and Key Concepts
The purpose of the Runtime and Solution Execution is to actively operate the configured Solutions, execute real-time data-acquisition, scripts, alarms, and all Solution configured items from all Modules. It is an essential and final phase of the Solution development, effectively delivering its functionality.
Runtime
The term Runtime, or Runtime environment, refer to the execution environment operates. It is used to do a differentiation from the Configuration (or Engineering, or Development) phase. The term Runtime is also use to refer the software components and computer processes in execution.
Execution Profile
An execution profile is a set of configurable settings that allows customization during runtime of Database Connections, Device Network addresses, facilitating the management of different environment. It allows to setup the connections used during the Development, Validation and Production phases, to their settings, still having only solution configuration file.
Online Configuration
This feature enables real-time modifications to be made to a running solution without stopping its execution. It allows users to adapt the solution to changing requirements, improving flexibility and responsiveness.
Hot Updates
Hot updates are a subset of online configuration, permitting the application of offline solution changes without disrupting the runtime environment. They are essential for maintaining solution stability and avoiding downtime while ensuring the solution stays up-to-date with the latest changes.
Build and Publish
The build and publish process involves compiling solution code and creating a read-only version of the solution, which can be distributed to end-users. This step is critical in ensuring the solution is ready for deployment and accessible to the intended audience.
Real-time in-memory Database
When the solution is in execution, the realtime-variables for the application, i.e. Tags, Templates, Assets, are loaded into memory, and it acts as central point of reference, to other functional modules can request values from those variables, or publish values, as they perform its function.
The computer process and executable responsible to hold the Real-time database is the TServer.Exe.That application can as a Windows Service, or it can be deployed to Linux and other supported operating systems.
Startup Steps
The are various ways to start the execution of a Solution. You can start it manually by going to the Runtime→Startup page. The various other ways to setup its execution are detailed in the chapter Deploying the Application.
When you click on the Start button on the Designer interface, the follow steps are executed:
title | Note regarding the selected Target Platform for the solution |
---|
, are exclusively available when Windows is selected as the Target Platform for the solution. This |
option unlocks |
the specific functionalities and |
security feature that are inherent and exclusive to Windows operational systems. |
1. The TStartup.exe application is launched
This utility is a solution loader, it will read the Solution Configuration for Startup, accordingly the Execution Profile selected, parse \ command line parameters, and active the main process TServer.exe
2. Starting the Real-Time DatabaseThe TServer.EXE starts
The TServer.EXE starts, loading solution objects, tags, templates, assets, into memory, and a communication service is stablished allowing other modules to start and connect for that.
3. Modules Startup
The other modules defined to start, like Historian, Alarms, Devices, Scripts, Datasets and Reports, start their execution, reading the solution configuration and establish connection with the main process.
4. Execution Profiles are applied
When the modules are starts they will behave according the definitions on the Execution Profiles. For instance, you can estou that in Development mode, you use a temporary local SQLite database for your alarm records, and on the Production mode, the Alarm Database is automatically mapped to a SQL server.
5. Solution Designer Automatic Connection
The Solution designer automatically connects to the running solution, allowing users to monitor progress, make adjustments, and troubleshoot issues as needed using the Monitor and Diagnostics pages.
6. Opening Client-Side Displays
The Operations display, using HTML5 from any type of Browser, or high performance WPF graphics pages can be opened from any remote computer connected with the server.
7. Applying Online Changes and Hot Updates
During execution, the system can apply online configuration changes and hot updates without disrupting the runtime environment. This capability enables users to adapt the solution to changing requirements and maintain high system availability.
Configuration and Runtime Process Isolation
In a software development solution, it is essential to maintain stability and prevent interference between various stages and components of the solution. Configuration and runtime process isolation is a technique used to achieve this goal, ensuring that the configuration and development aspects of the solution do not negatively impact the solution's runtime environment.
The configuration process involves setting up parameters, profiles, and other solution settings, which define how the solution should operate. On the other hand, the runtime process focuses on executing the solution and maintaining optimal performance. By isolating these processes, developers can modify configurations and test new features without disrupting the running solution.
This isolation is achieved through several means:
Separate Environments: By using separate environments for development, testing, and production, it is possible to work on solution configurations and features without affecting the runtime environment. Any changes made during development are not reflected in the runtime environment until they are thoroughly tested and deployed.
Containerization: Containerization technologies, such as Docker, allow developers to create isolated containers for different parts of the solution. This approach ensures that modifications made in one container do not impact the runtime environment or other containers.
Version Control: Implementing version control helps manage solution configurations and code changes. This method allows developers to experiment with configurations, roll back to previous versions, and track changes without affecting the runtime environment.
Access Control: By implementing access control mechanisms, it is possible to restrict modifications to the runtime environment and configuration settings. This approach ensures that only authorized personnel can make changes, reducing the risk of accidental disruptions or unauthorized access.
By employing configuration and runtime process isolation, solutions can maintain stability, enhance security, and minimize disruptions during the development and execution phases. This practice allows for continuous improvements, troubleshooting, and adjustments without compromising the solution's overall performance.
Runtime Execution Configuration
The Runtime Section in the Solution Designer allows to the define the settings to start the execution the application, perform solution verification and backup, and diagnostic the execution.
The User interface for Runtime configuration, is composed by four sub-section that will be covered in this chapter. They are:
Startup
Execution Profiles
Diagnostics
Build And Publish
Startup Parameters
Those parameters define which Profile the solution will use, Communication Ports and other settings. It allows to control the starting and stopping of the execution, as well the Online Configuration.
Settings on this page define which profile the solution will use, communication ports, and other configurations. They allow control over starting and stopping the execution, as well as managing the online configuration.
Main |
Commands and Options | |
Run Startup | This command button starts the application. |
Stop | This command button stops the application. |
Online configuration | You can use Enable Online Configuration to apply changes in real-time. All changes must be saved before they can appear on a screen. This is a setting you check to make changes apply immediately. You need to be connected to the running app for it to work. |
Execution Profiles
Execution
Development
This profile is designed for use in live environments, where the solution is fully functional and serves end-users. It optimizes performance and stability while minimizing the system's resource usage. Debugging and development tools are generally disabled or limited in this profile to ensure seamless operation.
Validation
The development profile is tailored for solution creation, testing, and iteration. It enables a wide range of debugging and diagnostic tools to assist developers in identifying and resolving issues during the development process. While performance might not be fully optimized in this profile, the focus is on providing a robust environment for developers to build and refine their solutions.
Production
The validation profile is intended for use during the final stages of solution development, such as quality assurance and user acceptance testing. It provides a balance between the development and production profiles, enabling necessary debugging tools while maintaining a level of performance and stability suitable for testing. This profile helps ensure that the solution meets its requirements and performs as expected before being deployed to a production environment.
Profiles allow for the dynamic replacement of database connections or device nodes during solution runtime, enabling smooth transitions between development, validation, and production environments.
The solution uses its main configuration in the Production profile without additional overrides. When you change from the Production Profile to any other profile in Runtime → Startup, this change will be reflected in the Startup Command line.
Execution Profiles | |
---|---|
Development | Provides an environment with debugging and development tools enabled. Developers use this profile during the development and testing phases to test and troubleshoot the solution. |
Production | Optimizes performance and stability for running in a production environment. Based on the selected profile, it automatically applies different database connections and device configurations. |
The User can enable Validation and Custom profiles on Runtime / Execution Profiles. For detailed information, refer to the Runtime Execution Profiles.
Startup Port Settings
The startup port settings allow you to define the network ports used by the application, both for internal communication and external access via the web. You can activate automatic port allocation and configure authentication via Windows.
Startup Port Settings | The ports must be enabled and available on the server. |
Main Port | Sets the port that each execution profile uses to access. By default, the Development profile uses the 3301 port, the Validation execution profile uses the 3201 port and the Production execution profile uses the 3101 port. These ports must be enabled and available on the server. |
Auto Ports |
Ensures that the software runs even when the specified main ports are unavailable. When |
enabled, and if the port defined |
as the Main Port |
is unavailable |
, the software will automatically search for and select an available port |
to use. | |
WA Port | Defines the port used by software platform for access with Windows Authentication. |
Windows Authentication | Checks if the system can only accept Windows Authentication. |
Web Port | Enables the web port in the solution. By default, the port is set to 80. |
AutoStartup / Windows Service |
Configures the solution to auto-start. For Windows solutions, it will setup the solution to run as a Windows Service |
when the computers starts, without requiring users login on the sever. If the Solution is MultiPlatform, but you using it in a Windows Computer, it will also run as a Windows Service. For MultiPlatform solutions on remote .NET 8 devices, it will setup the TWebServicesRunPrograms.json to start the solution when the TWebServices starts. Typically on Docker and Linux platforms the TWebServices.exe is set to run when the device is on, so you can manage it remotely. For more information on that configuration file, go to the TWebServices documentation. |
Execution Environment
The execution environment allows you to choose between running the application locally or on a solution server. This section also includes settings for the MQTT broker, facilitating communication between IoT devices.
Execution Path Settings |
Local Computer | The Solution is launched locally on the local computer. |
Solution Server | Read-only. Displays the IP address or the name of the computer where the solution is, which is based on the configuration in the Server tab. |
Path/Use Solution Path | Overrides the default execution path, which is the solution file location. Used by the system to allow one station to automatically update the solution in the redundant pair when doing online solution changes and HotStart commands. |
DataHub Service | |
Publish to a DataHub Service | When is checked, activate and share objects with a remote DataHub Service. |
It requires a TagProvider Connection configured using the Data Hub Server Communication. | ||||||
DataHub Services Settings | When the user clicks on this icon, it opens the DataHubService Settings dialog. This dialog allows configuring the connection between the solution and the DataHub Service, enabling data exchange between distributed solutions. The following configuration items are available in this dialog: The Alias field identifies the Solution within the DataHub. The Primary Host defines the main server handling the communication, while the optional Secondary Host provides redundancy. The Port sets the TCP communication channel, defaulting to 30001. The AccessKey field allows authentication control, ensuring only authorized runtimes can publish data.
For detailed information on the TagProvider Connection configuration check Data Hub Server Communication. |
Built-in Broker Settings | |
Publish to Built-in MQTT Broker | When is checked, the UnifiedNamespace is made visible to the built-in TMQTTBroker. The execution is very efficient, as all the Unified Namespace is made visible to Broker clients for subscriptions, but only when there is a client subscribing the data is published. |
TMQTT Broker Settings | This icon opens the TMQTT broker settings, where you can customize security and other execution options. As these settings are not applied dynamically, they will be used only in the next time the broker is started. For more information on the built-in broker configuration go to Built-in MQTT Broker page. |
Startup Modules
Startup Modules allow you to define which application components will be active at startup, ensuring that only the necessary modules are loaded, thus optimizing resources and performance.
Startup Modules | Select which modules will be started up when running the solution. |
Devices | Enables Devices module. |
Alarms | Enables Alarms module. |
Historian | Enables Historian module. |
Datasets | Enables Datasets module. |
Reports | Enables Reports module. |
Scripts | Enables Scripts module. |
Displays | Enables Displays module. When starting it the local computer, open the TRichClient application show the solution displays, in Windows WPF. |
OpenBrowser | When starting it the local computer, open the web browser pouting to the solution displays. |
OPC Server | Enables the OPC Server. |
Redundancy Enabled
Redundancy configurations allow you to define a high-availability environment, where a secondary server can take over operations in the event of a primary server failure.
Redundancy Enabled | |
Primary Server IP/Port | Enter the IP address and port of the primary server. |
Secondary Server IP/Port | Enter the IP address and port of the secondary server. |
Timeout | Connection timeout time |
in seconds. If reached, this will cause the system to switch to the secondary server. | |
On Primary Startup | Switch back to primary: When the primary instance becomes available again after a failure, the system will automatically switch back to using the primary instance. Keep secondary active: Even after the primary instance is restored, the system continues to use the secondary instance until manually switched back. |
Replication | AlarmHistorian: Replicates alarm history data to ensure that alarm events are preserved and accessible even if the primary instance fails. TagHistorian |
Retentive
: Replicates tag history data, which includes historical values of tags, ensuring data continuity and availability. |
Command Lines and URLs
The command lines and launch URLs provide the commands and shortcuts necessary to launch the application and access different clients, such as RichClient, SmartClient, and HTML5 Client, ensuring flexibility in accessing the application.
Tip | ||
---|---|---|
| ||
Click the button to start the Client. |
Command Lines and URLs | |
Startup Command line | TStartup.exe: It's the executable file responsible for initiating the startup process. /solution: Specifies the path to the solution file that will be run. /profile |
: Defines the |
Execution Profile to be used. Refer to Execution Profiles for more details. /profile:1 refers to the Development Execution Profile; /profile:2 refers to the Validation Execution Profile; /profile:3 refers to the Custom Execution Profile. /OnlineConfig:true: Indicates whether the online configuration is enabled or not. /wa: Enables the Windows Authenticator. /port1: |
Specifies the port number used during the startup. | |
Rich Client command | TRichClient.exe: It's the executable file used to start the Rich Client. /port1: |
Specifies the port number to be used by the Rich Client. | |
Smart Client URL | This URL is used to access the Smart Client interface via a web browser, allowing for interaction with the industrial solution using advanced, intelligent features. The IP address and port number define the network location of the service. |
HTML5 Client URL | This URL provides access to the HTML5 Client interface. This allows users to interact with the solution using web technologies and ensures compatibility with modern web browsers. |
NoSplash | When checked, |
suppresses the display of the splash screen during the startup of the application, potentially reducing the startup time. | |
WA | When checked, |
enables the Windows Authenticator for added security during the startup and operation of the solution on Windows operating systems. | |
SSL | When checked, |
enables Secure Sockets Layer (SSL) for encrypted and secure communication between the client and the server, protecting data integrity and confidentiality. | |
ViewOnly | When checked, |
sets the client to a read-only mode, where the user can view but cannot modify the configurations and data. |
Development and testing profiles are used to manage different environments within a solution. These profiles enable developers to work on new features, bug fixes, or improvements while keeping the production environment stable. By configuring separate profiles for development and testing, teams can maintain code quality and avoid deploying untested changes to the live environment. This separation also facilitates the debugging process and helps to identify issues that may arise during development. You can learn more about each of the profiles at Execution Profiles.
Diagnostics
Diagnostics on runtime execution are essential for monitoring a solution's performance, identifying potential issues, and ensuring overall stability. By implementing logging, performance metrics, and error reporting, developers can gain valuable insights into the execution process. These insights can be used to troubleshoot problems, optimize performance, and maintain system health. Effective diagnostic tools are crucial for maintaining a reliable and high-performing solution. For more information on Diagnostics, see Diagnostics Tools.
Build and Publish
Publishing read-only versions of a solution is crucial for maintaining a stable production environment while allowing developers to work on new features and bug fixes. The process involves preparing the solution for publication, creating a snapshot or branch, building and testing the solution, packaging the build, marking it as read-only, and deploying it to the production environment.
This approach reduces the risk of unintentional changes, simplifies rollback processes, and separates development and production environments. Adhering to best practices like regular release scheduling, using version control, thorough testing, documentation, and clear communication ensures a smooth and efficient publishing process for read-only versions. To learn more, visit Build and Publish.
Accessing HTML5 Clients on Devices Connected to the Same Network
To access HTML5 clients from other devices on the same network, follow these instruction:
Understanding the Localhost Address
The address 127.0.0.1 is the loopback address or "localhost". It refers to the device where the application runs, such as the engineering workstation or the controller computer.
Network Configuration
Assume you have an engineering workstation where your solution runs. This workstation has a specific IP address on the local network, different from 127.0.0.1.
Accessing from Other Devices
Open any browser on the target device (notebook, smartphone).
Enter the IP address of the engineering workstation followed by the port used by the application. The URL format will be http://
<Workstation-IP>:<Port>/html5
.
Practical Example
Identifying the Workstation's IP Address:
Assume the engineering workstation's IP address is 192.168.0.8 and the application uses port 3201.
Accessing the Application:
In the browser on the target device (notebook, smartphone), type the following URL: http://192.168.0.8:3201/HTML5.
If SSL is enabled, use https://192.168.0.8:3201/HTML5.
This process will allow you to access the HTML5 application running on the engineering workstation from any device connected to the same local network.
The software platform allow you monitor the users connected at runtime. For detailed information, refer to the Security RuntimeUsers.
Info | ||
---|---|---|
| ||
If you change the monitor scale or resolution while using the HTML5 client, you may need to refresh the client to ensure all elements are properly resized and positioned. This is because the browser dynamically adjusts the devicePixelRatio, but the UI layout does not automatically update. A quick refresh will align everything with the new display settings. |
Working with the Runtime
Working with the runtime is a key aspect of software development, as it involves managing the execution of a program while it's running. This includes starting and stopping the execution, switching execution profiles, and applying configuration changes. This comprehensive guide provides an overview of best practices and techniques for efficiently working with the runtime.
Starting and Stopping the Solution Execution
To start the solution execution, you need to launch the application or server, depending on the solution type. It's essential to monitor the system for any errors or issues during startup, as they may prevent the application from running correctly.
To stop the solution execution, you can use the appropriate command or interface provided by the runtime environment or the application itself. Make sure to gracefully shut down the application to avoid data loss or corruption.
To start the solution is production mode,
Go to Runtime → Startup
Click the Run Startup button
Applying Configuration Changes
Configuration changes can be applied to the runtime environment to modify the behavior of the application. These changes can include modifying settings, adding or removing modules, or adjusting resource allocation. To apply configuration changes, follow these steps:
Identify the configuration file or settings for your application.
Modify the configuration settings as needed.
Restart the application or reload the configuration to apply the changes, depending on the capabilities of the runtime environment.
Common Issues and Solutions
Performance bottlenecks: Slow solution execution can be caused by a variety of factors, such as inefficient code or inadequate hardware resources. To resolve this issue, optimize your code, allocate more resources, or employ parallel processing techniques.
Configuration errors: Incorrect settings in the solution configuration can lead to unexpected behavior or failure. Review your configuration files, verify the parameters, and ensure they adhere to the documentation.
Runtime environment mismatch: Incompatibilities between development and production environments may cause issues during runtime. To address this, ensure that all dependencies are consistent across environments and use containers or virtual machines for environment isolation.
Module conflicts: Conflicts between modules can lead to unexpected behavior or crashes. To resolve this, check for duplicate or outdated modules and ensure that your modules are compatible with each other.
Database connectivity issues: Problems connecting to the real-time database can be caused by network issues, incorrect credentials, or misconfigured database settings. Verify the database connection settings, ensure the database server is accessible, and check the credentials.
Client-side display errors: Issues with client-side displays can stem from incompatible browser versions, outdated JavaScript libraries, or improperly configured display settings. To fix this, ensure your solution supports the target browser versions, update your libraries, and double-check display settings.
Hot updates not applied: If hot updates are not being applied correctly, confirm that your solution is configured to accept online changes and verify the update mechanism is functioning as expected.
Build and publish failures: Errors during build and publish processes may be due to incorrect settings, code issues, or dependency problems. Review the build and publish configuration, fix any code issues, and ensure all dependencies are resolved.
Troubleshooting and Best Practices
Runtime issues can occur during the execution of the application, such as crashes, performance problems, or unexpected behavior. To troubleshoot these issues, follow these steps:
Review the application logs for any error messages or warnings.
Use debugging tools to inspect the state of the application at runtime.
Monitor system resources, such as CPU, memory, and disk usage, to identify potential bottlenecks or resource constraints.
Consult the documentation or support resources for known issues and solutions.
Make sure you're using appropriate execution profiles for different stages of the development lifecycle.
Apply configuration changes carefully, always testing before deploying to production.
Document any custom configurations or modifications for future reference.
Keep the runtime environment up to date with security patches and software updates.
Info, Server And Client Namespaces
There are a few runtime objects that provide information about running the solution.
The Info namespace is the main location for the runtime status. The main objects on the namespace are:
Info.Solution: information about the solution that is running
Info.License: information about the license
Info.Module: information and start/stop command to Modules
Info.Trace(): displays a message on the TraceWindow
Info.TestMode: shows if the solution is running in Test Mode
The Server namespace has information about the server computer. The Client namespace has information about each client compute that runs a graphical interface. See Namespaces for the complete programming reference on runtime objects.
In this section:
Page Tree | ||||
---|---|---|---|---|
|