Page History

Key Concepts and Terms

Development vs. Runtime Environments

The development environment is where you design, configure, and test your solution. It provides comprehensive tools for building HMI, SCADA, and MES applications, including graphical editors, scripting support, and debugging capabilities.

The runtime environment, on the other hand, is where the deployed application runs and interacts with actual devices, data sources, and end-users. It executes the solution's logic, collects and processes data, and manages the user interface based on the configuration created in the development environment.

The primary goal of the deployment process is to transfer the solution from the development environment to the runtime environment, ensuring that all necessary settings, configurations, and resources are correctly transferred and applied.

Execution Profiles

Execution Profiles enable efficient management of different stages of your solution lifecycle. By using profiles, you can apply settings and configurations specific to the Development, Test, and Production environments without creating separate solution files.

• Development: Profile for building and making changes to the solution.
• Validation: For testing and validating changes in a simulated environment.
• Production: For operation in a live production environment.

Note: The software platform also allows "Online Configuration," enabling real-time changes without disrupting the system. Use with caution.

Each profile can have its own set of configurations, such as database connections, device communication settings, and user access permissions. This allows you to test and validate your solution in different environments without affecting the production system.

To leverage profiles effectively:

1. Create separate Execution Profiles for Development, Test, and Production.
2. Define environment-specific settings and configurations for each profile.
3. Deploy the solution to the appropriate environment, selecting the corresponding Execution Profile during deployment.

By using Execution Profiles, you can ensure a smooth transition between solution stages and minimize potential issues caused by environment differences.

Server and Client Processes and Computers

The software platform uses a client-server architecture for its execution processes.

• Server Process: Modules with a global impact on the application, such as Data Acquisition, Historian, Alarms, and server-side calculations.
  Client Process: Graphical user interfaces and related scripts.

Server and client processes can run on the same computer, handling both data acquisition and graphical displays. Alternatively, you can have a distributed system, where the solution file is installed on a server, and remote clients, with no local installation of the process, can access the graphical displays and interact with the server.

Network Scenarios

There are the various deployment network scenarios supported by this software platform.

Deployment Scenarios:

• Standalone Computers: Suitable for small-scale applications, testing, and development purposes.
• Edge and Embedded Devices: Ideal for real-time data processing and decision-making at the network edge.
• Distributed Systems: Various client stations accessing a server, or server-to-server communications, offering better resource utilization, centralized management, and improved scalability.
• Redundant Servers and Hot-Standby Systems: Provides high availability and fault tolerance for critical applications.
• Cloud Deployment: Enables improved scalability, flexibility, and reduced infrastructure costs.
• Using the Secure WebGateway: Enhances security and enables remote monitoring, control, and management of the application.

Following See below the typical usage of for each scenario.

Standalone Computers

Standalone deployment involves running both the development and runtime environments on a single computer. This scenario is ideal for small-scale applications, testing, and development purposes. In standalone mode, the application communicates directly with the devices and data sources, and end-users access the user interface locally on the same computer.

Edge and Embedded Devices

Edge and embedded deployment scenarios involve running the runtime environment on edge devices, such as industrial PCs, IoT gateways, or embedded systems. In this case, the application is deployed close to the data sources and devices, providing lower latency and reduced network traffic. This scenario is suitable for applications that require real-time data processing and decision-making at the edge of the network.

Client-Server Operations

Client-server deployment involves running the runtime environment on a dedicated server, with multiple clients connecting to the server to access the user interface and interact with the application. This scenario allows for better resource utilization, centralized management, and improved scalability. In a client-server architecture, the server is responsible for data collection, processing, and execution of solution logic, while clients display the user interface and provide user interaction capabilities.

Redundant Servers and Hot-Standby Systems

Redundant deployment involves running the runtime environment on multiple servers, with each server acting as a backup for the others. This scenario provides high availability and fault tolerance, ensuring that the application continues to operate even if one server fails. Hot-standby systems consist of primary and secondary servers, where the secondary server takes over if the primary server fails, ensuring minimal downtime.

Cloud Deployment

Cloud deployment allows running the runtime environment on a cloud-based server, enabling improved scalability, flexibility, and reduced infrastructure costs. In this scenario, the application is hosted on a cloud provider, and clients can access the user interface and interact with the application through the internet. Cloud deployment also simplifies management and maintenance, as the cloud provider takes care of the underlying infrastructure.

Using the Secure WebGateway

The Secure WebGateway deployment scenario allows remote access to the application over the internet without exposing the server directly to external networks. This approach provides enhanced security and enables remote monitoring, control, and management of the application. The Secure WebGateway acts as a proxy between clients and the runtime environment, handling authentication, encryption, and communication between the two.

Summary of Deployment Steps

According to your network scenario, as descried on described in the previous topic, you will install the Platform in platform on one or more server, servers and enable its access to for various clients. Or one setup for Alternatively, you can set up standalone systems and edge devices. 

Server-Side Installation:

• Copy the Solution File (.dbsln or .dbrun) to the computer.
• Ensure that the necessary resources for the server-side modules, such as external files or communication ports, are available on the computer.
• Server-side modules include Devices, Alarms, and Historian. Some functionalities of Datasets, Scripts, and Reports execute on the server side, while others execute on the client side.

Client-Side Installation.

• WebClients and SmartClients don't need any installation.
• RichClients requires the installation on each client computer.

Deployment Steps:

• Product Installation on the Target Server Computer (and Clients, if using RichClients).
• Software License and Solution Settings Verification.
• Verify the Solution File for Dependencies on the Computer and Third-Party components.
• Document the URLs for Connection and Optional Parameters for the Client stations.

Detailed deployment steps are provided in the following sections.

Preparing for Solution Deployment

This section guides you through the process of preparing your solution for deployment, focusing on key considerations and best practices related to installation, licensing, and system requirements.

Topics Covered:

• Addressing specific installation and licensing considerations during deployment.
• Deploying the application on different platforms, including system requirements and platform-specific instructions.
• Handling licensing and activation requirements to avoid restrictions or limitations.
• Conducting post-deployment verification to ensure successful installation and application functionality.

Installation and Licensing on the Target Computer

The product must be installed and licensed on the target computer.

Here is a reference to locate the information according to your deployment scenario and operating system.

Windows

When possible, the MSIX installation can also be used for production. But there a few limitations, so in many scenarios the servers must have its installation with the tradition setup.exe version of the installer.

The reasons the MSIX install may not acceptable for production are:

• The Product Installation Folder can't not be changed, its the Windows Portable App folder,
• The Folders for TraceLogs, Libraries is necessary under the Documents of user logged when the install was executed. (But the solutions can be mapped to any folder)
• The Firewall authorizations and System Services need to be manually started. 

If those constrains aren't an issue in your case, keep the 10s installation using the MSIX. Otherwise, go to the Support Portal, to download the setup.exe version of the installer. 

For more information on the Installation procedure, see Managing Installations.

Linux (or other operating system supported by .NET 8)

→ See more at Linux Deployment.

Docker

→ See more at Docker Deployment.

Licensing 

The production system requires a valid software License.

For information on how go get and apply a license, go to Licensing and Activation

Product Series and License Verification

A Solution can be created to target different product series options, like Unlimited, or EdgeHMI, EdgeGateway, and the number of communication points allowed.

→ Read more about Product Series.

Here's how you can that verification:

The final step in verification is to make sure the Solution Settings matches the license on the production computer. 

In the Designer software, go to Solution → Settings, and verify the Product Series (Family and Model) the solution was designed for. You may have also a Historian requirement.

In the Solutions Manager software, go to the License tab, and verify the license information for the computer you are running the solution on. 

The License must be from a version equal or newer to your solution, and the product series must be equal or higher (in family type and quantity of tags) than your solution.  

Your solution may required specific additional licenses, like IEC protocols, or licenses for third-party systems.

Installing the Solution File

Each solution is saved in a single file with the extension .dbsln for standard solutions or .dbrun for read-only published solutions.

This file can be transferred to the target computer using the Solutions Management tool, a custom application created with the RemoteAPI for advanced scenarios, or manually via FTP or other file exchange tools available on your device.

Although one file contains the entire solution configuration, use the following checklist to ensure that any external dependencies are also addressed:

• External Dependencies: Verify that any external dependencies are included. If the folder structure differs between the development and production computers, ensure all file paths are correctly mapped.
• Macros: Utilize macros like ExecutionPath or SolutionName in connection and file names to create solutions that can be easily installed on different computers. Avoid using fixed path locations whenever possible.
• External WPF Controls: Copy any external WPF controls to the target computer. For remote web access, place these files in the WpfControl folder and run the utility that updates the web manifest.
• External DLLs or .NET Assemblies: Ensure any referenced external DLLs or .NET assemblies are available and correctly pathed on the target computer.
• Retentive Values: Decide whether the target computer will create a new retentive database or if you will copy one with predefined values.
• Firewall Configuration: Enable the firewall to allow remote clients, specifically port 3101 for startup and any other ports according to your runtime settings.
• Web Clients: The TServer port 3101, or the defined port, also serves as an HTTP/HTTPS protocol listener, negating the need for installing web servers. If there is a policy or requirement to use Microsoft IIS or another external web server, refer to the Installation section for setup instructions.

Setup the Startup Parameters and Auto-Start 

In a production environment, a streamlined installation and configuration process is crucial. While detailed instructions for software platform installation are available in the "Installation and Licensing" chapter, this section focuses on the Solution Configuration layer.

Running as a Service & Runtime Startup Parameters

• Setting up the software platform to run as a service ensures consistent and uninterrupted operation.
• The Startup Parameters allows customizations in the execution of solution, for instance enabling diagnostics logs.
• You also start the Runtime using a command line, this scenario can be useful in for the multi-platform solutions.

→ See Server Startup Parameters  for setup details.

Embedded Devices:

• Deploying on embedded devices comes with its own set of challenges and benefits, and in general they have their own setup procedures. Ensure you understand the nuances and considerations specific to embedded deployment.

Redundancy Systems:

• Designing a robust solution often involves setting up redundancy. Learn how the software platform handles failover mechanisms and maintains data integrity.

→ See Redundancy Configuration page for more information.

Server Preparation Check-list

• 1. Licensing:

     • Each Server computer must have their local license installed, or rely on a Network License Server. 
     • Client computers in distributed systems do not require their own licenses; they only connect to the server.

  2. Installation:

     • Detailed steps for FactoryStudio installation can be found in the "Installing FactoryStudio" section of the "Getting Started" guidethe Managing Installations.
     • All servers must have .NET framework 4.8 or NET 8.0, according the Solution is defined for Windows or Multiplatform.
     • Web clients require browser compatibles with HTML5 WebAssembly technology. 
     • RichClients requires client computers with .NET Framework 4.8
     • SmartClients requires client computer with .NET Framework 4.8 and a browser compatible with ClickOnce.
     • If you're using components that bypass the need for Windows Registry setup, simply copy the product files without running an installation.

  3. Web Server:

     • If using Web Client, or Smart Clients, or requesting Web Services and files from the server, the TWebServices or other WebServer, like IIS, is required to be in execution.

  4. Product and License Details:

     • Solutions are created targeting a specific Product Family and Product Model, as defined on the Solution Settings → General page.
     • Ensure the server computer's license aligns with or exceeds the solution’s requirements.
     • The "Product Family" in the license should match or supersede the one defined in the solution.
     • Various product offerings include:
       • FrameworX for Enterprises: Comprehensive solution inclusive of everything in FactoryStudio and more. Features include unlimited clients (.NET Smart Client, Web, HTML5, iOS), unlimited I/O points, unlimited drivers, and more.
       • FactoryStudio: Powerful tool for data collection and management, report and dashboard creation, and more. Includes all Edge HMI features and allows scalable I/O and client numbers. Comes with over 70 drivers at no additional cost, and supports languages like C#, VB.Net, and Python. Redundancy, SDK extensions, and toolkit are available.
       • Edge HMI: Suitable for running HMI and OPC Server solutions.
       • Edge Gateway : Suitable for data collection, protocol conversion, and other Edge connective solution.
     • The "Model" in the license should support the required communication points.
     • "License Type" should be  "Runtime".  DEV (Development) licenses are exclusively for System Integrators' internal use and shouldn't be used in production environments.
     • Even the process could allow leverage the 2 hours evaluation time for non-licensed software, Evaluation software isn't authorize to be installed or used in Production environments.
     • If the solution uses special interfaces like the OSIsoft™ PI System or IEC protocols, ensure the license on the target computer is enabled for these.

For more Information about product and license models, refer to Managing Licenses and Licensing and Activation pages.

Optional Additional Steps

1. If using the Device Tunneling feature, the setup of addition firewall ports, and the installation of the product in the data collation is necessary.  See  Remote Channels.
2. If using the SecureWebGateway, execute the installation, licensing and setup of the gateway computer. See Secure Multi-Port Gateway

Setting Up Client Displays

This section focuses on setting up client displays for the application, covering various client configurations, remote access options, and guidance on optimizing the user experience for end-users.

Topics Covered:

• Configuring remote client setups and access options for different client types, including mobile and web-based access
• Implementing auto-start client displays for efficient application launching
• Managing user authentication and security settings for client displays
• Optimizing client display performance and responsiveness across platforms and devices

Remote Client Setup: Desktop, Web, and Mobile

This section presents the setup and configuration processes for remote clients, including the various technologies supported by the platform:

• Windows-based Rich Clients: Using WPF (Windows Presentation Foundation)
• .NET SmartClients: Allowing no-install thin-client access from compatible platforms
• HTML5 Web Pages: For both desktop and mobile devices

The platform has also tools to assist on  automatically starting the client applications, either using .NET or HTML5, when it detects the server is available.

For detailed information, refer to the child page Remote Clients Setup.

User Authentication and Security

This section summarizes aspects of the software platform that address the importance of user authentication and security settings for client displays, including role-based access control, secure communication protocols, and best practices for maintaining a secure client environment. It also includes links to platform-specific security considerations for different client types.

Reference Links:

• Platform Overview > Security and Compliance: High-level view of security and compliance features in the software platform.
• User Guide  > Security > RuntimeUsers: Configuration of development and runtime users, definition of user roles, and access controls on displays and commands.
• User Guide > Security > Windows AD / LDAP Servers: Information on Active Directory integration and alternate security models for non-Windows targets.
• Secure Multi-Port WebGateway: Explains how to route data across network security zones and create application-level protection against intrusions.

Remote Management and Monitoring

• Remote Access API: We have tools for development of custom Remote Management Tools

  • Service Verification : Enables remote solution configuration access and advanced diagnostics and installation information, in case a manual setup or verification. → Read more about Service Verification.

• Built-in Monitoring Tool: The software platform have monitoring tools for all of your functions. → Read more about UNS Connections Monitor, Devices Monitor, and Historian Monitor.

• Solutions Manager: this tools allows connection with remote Server and Devices, to upload new version of the solution, or product updates. 

Resolving Connectivity Issues

The interruption of the communication link with Server, clients nodes, or data collector is a typical issue that may occur in factory networks.

Use this checklist to verify the connective.

→ See Connectivity Verification.

Monitoring performance and health

It's vital to regularly monitor your software's performance and health for reliability and optimal functionality.

For strategies to optimize system performance, see our : Best Practices Guide.

Version Control, Maintenance, and Upgrades

Navigating the intricacies of version control, maintenance, and upgrades is vital for the longevity and health of your deployed applications. By implementing robust strategies, you can ensure that your solutions remain up-to-date and reliable.

Managing Version Control for Product Core and Solution

Version control is crucial for maintaining the consistency of your solutions. Effective tracking of both the core product and individual solutions helps avoid conflicts and allows for streamlined rollbacks if necessary.

Key Steps:

• Core Product Tracking: Use version control systems to track changes and updates to the core product, ensuring that all modifications are documented and easily accessible.
• Solution Tracking: Apply version control to individual solutions to maintain a history of changes, enhancements, and bug fixes.

Upgrading Deployed Applications

Keeping your applications current ensures access to the latest features and security updates. Understanding the upgrade pathways is essential for a smooth transition between versions.

Upgrade Pathways:

• Plan Upgrades: Schedule regular upgrades to align with the release cycles of the software platform.
• Backup Data: Before upgrading, ensure that all data is backed up to prevent loss during the transition.
• Test Upgrades: Perform upgrades in a staging environment to identify potential issues before applying them to the production system.
• Rollback Procedures: Have a rollback plan in place in case the upgrade introduces unexpected problems.

Platform features to Assist on the Upgrade Process.

Use the Build (with Backup option flag) to create Solution Versions, with the rollback restore versions. Optionally, use the Publish command to send only controlled solution versions to production.

→ See Runtime Build and Publish

Use the Execution Profiles to facilitate Validation of the Solution upgrades.

→ See Runtime Execution Profiles

In this section: