Key concepts

Development vs Runtime Environments

The development environment is where you design, configure, and test your Solution. It provides a comprehensive set of 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 the 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 you to manage different stages of your solution lifecycle efficiently. By using profiles, you can apply settings and configurations specific to the Development, Test, and Production environments without having to create separate solution files.

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

Note: In FrameworkX, you can also enable "Online Configuration", allowing for 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, making sure to select 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

FrameworX uses a client-server architecture on its execution processes. 

• Server process: The Server processes are modules that has globals impact in the Application, such as Data Acquisition, Historian, Alarms and server side calculations.
• Client process: The client components are the graphical user interfaces and related scripts.

Those Server and Clients processes can run on the same computer, when running both the data-acquisition and the graphical displays on the same computer, or you can have an Distributed System, where the Solution file in installed in a server, and remote clients, with no local installation of the process, can access the Graphical Displays and interact with communication with the server.

Deployment Scenarios and Architecture

In this section, we will discuss various deployment architecture options and scenarios available in this software platform. Each scenario has its benefits and is suited for different situations, depending on factors such as network topology, available hardware, and performance requirements. Explore the following scenarios to find the best fit for your application:

• 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. Offers 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.

By understanding the different deployment scenarios, you can choose the most suitable architecture for your specific application requirements and ensure a smooth deployment process.

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.

Deployment Overview

The platform always uses a Client-Server architecture, some of scenarios describe they may thought use a sub set of the functionality, or run both the. server and client components on the same computer.  

The Server side installation involves coping the Solution File (.dbsln or .dbrun) to the computer and making sure the sources the server-side modules will need, like external files or communication ports,  are available on the computer. The server side modules are Devices, Alarms, Historian. The Datasets, Scripts and Reports have some of functionality executing on the server side, some executing on the client side. 

When you have a local or stand-alone project, the server and the client components run on the same machine.

For the Client components, Displays and actions started by the displays or its code Behind, there are various technologies supported, each one with its own procedure to setup.

The steps to do the deployment are detailed in the following sections, but in a nutshell, it involves:

• Product Installation on the Target Computer

• License and Solution Settings Verification

• Setup the Solution file and Dependencies in the computer

• Document the Client URLs for connection and its optional parameters

Preparing for Deployment

This section guides you through the process of preparing your solution for deployment. It focuses on key considerations and best practices related to installation, licensing, and system requirements while referencing the relevant chapters in the product documentation for detailed information. The topics covered include:

• 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

Product Installation on the Target Computer

The product must be installed and license on the Target Computer. The necessary steps to perform that were described in previous sections of the documentation, here is a reference to located the information according your deployment scenario and operating system. 

This section summarizes the deployment process on various platforms, such as Windows, Linux, and Docker environments. It includes references to the specific documentation topics on installation steps and platform platform-specific instructions.

Platform Overview > System Requirements: presents the basic procedure and requirements for installation.

Getting Started > Managing Installations: addresses custom scenarios, like WebServer, Canary Historian and other additional tools.

Getting Started > License And Activation: information on how to acquire and install a license.

License and Solution Settings Match Verification

A Solution can be created target different product series, like Unlimited, or EdgeHMI, EdgeGateway, and its target of process tags.

A verify important final verification before deployment for production is to make sure the Solution Settings matches the license on 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 Management software, to the License tab, and verify the license information for the computer you run the solution. 

The License must be from a version equal or newer your solution, and the product series must be equal or higher (in family type and quantity of tags) than your solution.  For more information in product series, go to Platform Overview > Product Series

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

Installing the Solution File

Each solution is save in a single file, with extension dbsln or dbrun, according is a standard solution, or a read-only published solution.

That file can be sent to the Target Computer using the Solutions Management tool, or with a custom application created with the RemoteAPI for more advanced scenarios. It certainly can also be copied manually or using some FTP or other file exchange tool available on your device. 

Although one file contains the entire project configuration, you should use the following checklist to ensure that any external dependencies are also taken care of. If the folder structure is different on the production computer and the computer used for your project's development, make sure that all of your project's file paths are correctly mapped to the production computer.

There are many macros you can use in some connection and file names, such as _ExecutionPath_, or SolutionName_, which can assist you to create solutions that will be easily installed in different computers. Whenever possible, avoid using fixed path locations in your projects.

Any external WPF controls should also be copied to the target computer. For remote web access, these files should be located in the WpfControl folder and the utility that updates the web manifest must be executed.
If the application references external DLL or .NET assemblies, ensure they are available and at the correct paths on the target computer.
If the project uses Retentive values, you must decide if the target computer will create a new Retentive database or if you will copy one with predefined values.
Enable the firewall to allow remote clients. Ports 3101 for startup (optionally other ports according your runtime settings).

For Web clients, the TServer port 3101, or the port you have defined, is also a HTTP/HTTPS protocol listener, so no installation of Web Servers is necessary. If there is a policy or requirement to use Microsoft IIS, or other external WebServer, that setup is described in the Installation section. 

Setup the Solution on the Production Environment

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

1. Running as a Service:
   Setting up FrameworkX to run as a service ensures consistent and uninterrupted operation. You can view the setup in Service Verification page.

2. Server AutoStartup Options & Startup Parents:
   These features enable automatic initialization of specific components and maintain parent-child hierarchies in the solution structure.

3. Embedded Devices:
   Deploying FactoryStudio on embedded devices comes with its own set of challenges and benefits. Ensure you understand the nuances and considerations.

4. Redundancy Systems:
   Designing a robust solution often involves setting up redundancy. Learn how FactoryStudio handles failover mechanisms and maintains data integrity.  Please see the Redundancy Configuration page.

5. Additional Configurations:
   Each production environment is unique. Dive deeper into specialized configurations tailored for specific use cases.

Installing the Solution file. 

A solution is installed on the server as a single file, either the main configuration file (with the "tproj" extension ) or a read-only file (with the "trun" extension) if you have created one.

The Solution Management utility allows you to connect with remote servers and download the solution file to remote computers.

Although one file contains the entire solution configuration, you should use the following checklist to ensure that any external dependencies are also taken care of.

• If the folder structure is different on the production computer and the computer used for your solution's development, make sure that all of your solution's file paths are correctly mapped to the production computer. FactoryStudio has many features and macros to define paths relative to the solution location, product installation, or execution path. Whenever possible, avoid using fixed path locations in your solutions.
• Any external WPF controls should also be copied to the target computer. For remote web access, these files should be located in the WpfControl folder and the utility that updates the web manifest must be executed.
• If the application references external DLL or .NET assemblies, ensure they are available and at the correct paths on the target computer.
• If the solution uses Retentive values, you must decide if the target computer will create a new Retentive database or if you will copy one with predefined values.
• Enable the firewall to allow remote clients. Ports 3101 for startup (optionally port 3201 for Test Mode). For web and iOS clients, data web services are enabled on port 80.
• If the application uses external DLLs, WpfControls, configuration files, or embedded databases, make sure you copy the files to the target machine and double check if the PATHNAMES you used in the solution configuration are compatible.

<< The description above is good. The Deployment checklist should not repeat all of it, in the other chapter,  but must have a checkbox to Verify the Solution files installation, which points to this section. >>>>
<< Or the other way around, in this section describe the various scenario in a higher level, and add a link to the CheckList for the details >>>

Deployment Check-list

• 1. Licensing:

     • FactoryStudio must be licensed either on a standalone computer or on the server in distributed systems.
     • 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" guide.
     • All servers and clients must have .NET framework version 4.0 or higher installed.
     • 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:

     • Ensure TWebServer or IIS is installed and operational on the server computer if remote users will be accessing the system.

  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 - OPCServer: Exclusively for OPC server solutions.
       • Express: These licenses or solutions are not authorized for production use.
     • The "Model" in the license should support the required communication points.
     • "License Type" should be either "Engineering" or "Runtime". DEV (Development) licenses are exclusively for System Integrators' internal use and shouldn't be 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.

Client Displays and Remote Visualization

This section focuses on setting up client displays for the application. It covers various client configurations, remote access options, and guidance on how to optimize the user experience for end-users. The topics covered include:

• 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 support by the platform

• Windows based rich clients, using WPF (Windows Presentation Foundation)
• .NET SmartClients, which allows no-install thin-client access from compatible platforms. 
• HTML5 web pages, for both desktop and mobile devices.

Go to chid page <Remote Clients Setup> for detailed information.

Auto-Starting .NET and HTML5 Clients

FrameworX has the ability to automatically start the client application, either using .NET or HTML5, when it detects the Server is available. 

The child page Display Client Types has information on how to configure and use that features.

User Authentication and Security

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

Platform Overview > Security and Compliance: high level view of security and compliance features in FrameworX.

Solution Development > Security, Users and Roles: configuration of development and runtime users, definition of User Roles and access on Displays and Commands.

Solution Development > Security → Windows AD / LDAP Servers: explains about Active Directory integration and alternate security models for non-Windows targets. 

Solution Development > Displays > (Need to create): explain how to customize the built-in Logon page for remote clients and operators. 

Secure Multi-Port WebGateway: explains the built-in to route data across Network Security zones, and create application level protection for intrusions.

Remote Management and Monitoring

Discuss options for deploying and managing applications remotely, including any web-based tools or remote access features. Explain built-in tools and features for monitoring the performance and health of the deployed application, as well as troubleshooting any issues that may arise.

Tools for Remote Management

• Remote Access API: We have tools for Remote Acess Management, like:
  
  • WebAccess API : A essential tool for remote system management. It offers methods to interact with the system via web-service, allowing reading and writing tag values, in addition to other essential operations.
  • Remote Execution : A guide to how configure devices for Remote Clients. Allows the an out of-the-box setup for gateway and tunneling applications. See the Remote Channels page for more details.
  • Remote Clients : Its possible acess multiple clients with FrameworkX. Please view the setup on the Remote Clients Setup page.
  • Service Verification : Enables remote project configuration access and advanced diagnostics and installation information, in case a manual setup or verification. Service Verification
• Built-in Monitoring Tool: FrameworkX have monitoring tools for all of your functions. You can check the full content on Connections Monitor, Devices Monitor, Historian Monitor to monitor and analyse your solution.

Monitoring performance and health

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

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

Using these resources ensures that your FactoryStudio systems are robust and efficient.

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 pivotal in maintaining the consistency of your projects. Ensure that both the core product and individual solutions are tracked effectively to avoid conflicts and guarantee streamlined rollbacks if necessary.

Recommended Workflows, Tools, and Techniques:
There are best practices and tools tailored specifically for FactoryStudio. Adhering to these workflows can drastically simplify the maintenance process.

Upgrading Deployed Applications:
Keeping your applications current ensures access to the latest features and security updates. Understand the upgrade pathways to transition smoothly between versions.

Troubleshooting:
For solutions to common challenges, refer to our Troubleshooting Guide.

Reference Materials

• Startup parameters
• Server autostart options
• Redundancy configurations
• Remote clients setup
• Secure multi-port gateway
• Linux and Docker deployment
• Deployment checklist

In this section: