Versions Compared

Old Version 26

changes.mady.by.user admin

Saved on

compared with

New Version Current

changes.mady.by.user admin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


HTML
<style>
.text-span-6 {
    background-image: linear-gradient(99deg, rgba(170, 163, 239, .5), rgba(125, 203, 207, .5));
    border-radius: 50px;
    padding-left: 15px;
    padding-right: 15px;
}

#title-text {
display: none;
}

.panelgradient {
    background-image: linear-gradient(180deg, #d5def0, whitesmoke);
    border-radius: 8px;
    flex-direction: column;
    justify-content: center;
    align-items: center;
    padding: 4rem;
    display: flex;
    position: relative;
}

</style>


<div class ="panelgradient">

<h1 style="text-align: center;">Solution Deployment</h1>

</div>



Introduction to Solution Deployment

When you finish developing and testing your solution, you can deploy the runtime application so it can be used by end users. Solutions can be deployed to run:

  • Locally
  • On an Embedded Device
  • In a Client-Server Distributed Architecture
  • On the Cloud
  • Using Hot-Standby Redundant Systems

This documentation section explores the various scenarios and operating systems where a solution can be deployed, with detailed explanations on how to install, set up, and deploy the solution for production in the field.

On this page:

Table of Contents
maxLevel2
minLevel2
stylenone

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.

See below the typical usage 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 described in the previous topic, you will install the platform on one or more servers and enable access for various clients. 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 installation can be accessed only on the User Account that did the installation,
  • The Windows Version must Windows 10 version 1709 or later, or Windows Server 2022 or later. 
  • 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, as it has the following benefits:

  • The installation, update and removal process is way much faster that the setup.exe.
  • The Security is enhanced, as it allows the Microsoft Specification for Portable Apps.
  • The installation and data folders follows standards, and are setup to your Windows login.
  • That is the newer Microsoft standard for installing apps and likely the one that will keep evolving in the long run.

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.

Warning
titleProduct Model and License Matching

It's very important to verify if the License applied is consistent with the Product Model the solution is using. Meaning the license Family and Model (number of points) must match the settings defined in the solution, or be superset of it.

Here's how you can that verification:

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 installation can be found in the 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:

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.
Tip

For Solution Tracking, leverage the built-in TrackChanges tools. For integration with other version controls systems, use the Automaticaly Export Changes on the Designer home page.

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:

Page Tree
root@self

Introduction to Application Deployment

When you finish developing and testing your project, you can deploy the runtime application so it can be used by end-users. Projects can be deployed to run locally on a stand-alone computer or embedded device, in a client-server distributed architecture, on the cloud, or using Hot-Standby Redundant systems.

This section explains the architecture of the Tatsoft FactoryStudio application deployment, including the relationship between the development and runtime environments. It reviews how to use the Execution Profiles feature, which allows the same Project configuration file to be shared on the Development, Testing, and Production installations. This organization simplifies the maintenance and the quality assurance of your solutions.

On this page:

Table of Contents
maxLevel3

Key concepts

Development vs Runtime Environments

In Tatsoft FactoryStudio, the development environment is where you design, configure, and test your project. 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 project'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 project from the development environment to the runtime environment, ensuring that all necessary settings, configurations, and resources are correctly transferred and applied.

Leveraging Profiles: Development, Test and Production

Execution Profiles in Tatsoft FactoryStudio enable you to manage different stages of your project lifecycle efficiently. By using profiles, you can apply settings and configurations specific to the Development, Test, and Production environments without having to create separate project files.

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 project 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 project 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 project 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 Project 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 Tatsoft FactoryStudio. 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 project 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.

Preparing for Deployment

This section guides you through the process of preparing your Tatsoft FactoryStudio application 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

Installation and licensing on Multiple Platforms

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: introduces the various platforms and its requirement, where you can deploy your Project solution. 

Project Development > Installation and Licensing: central point for details information on installation procedures.

Project Development > installation and Licensing >  Managing License and License Server setups presents the licensing methods.

Project Development > Deploying the Application > Deployment Checklist and product models: Basic verifications when preparation to deploy in production, including if the License Family and Model in the Target Computer will be able to execute the model selected in your project configuration.

Setup the Project on the Production Environment

Provide guidance on the installation and configuration process for deploying the application, the Project file, and its settings in production environments. Focus on specific steps and settings relevant to production use. Refer to the "Installation and Licensing" chapter for detailed installation instructions on FactoryStudio itself; this section focuses on the Project Configuration layer.

<< Explaing about running as a service, explains about Server AutoStartupOPtions and Startup Parents, explains about EMBEDED Devices, and Reducancy systems. >>

<<< Clear this section must follow the lead of section this chapter, an presentation summary of the various cases, with links to the child pages with the proper information 

Installing the Project file. 

A project 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 Project Management utility allows you to connect with remote servers and download the project file to remote computers.

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. FactoryStudio has many features and macros to define paths relative to the project location, product installation, or execution path. 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 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 project 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 Project 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

Emphasize the importance of verifying the successful installation and functionality of the deployed application. Outline the recommended steps and checks to ensure a seamless deployment experience and confirm that the application operates as intended in the production environment.

A FactoryStudio license must be installed on a standalone computer or on the server computer in distributed systems. The section "Installing FactoryStudio" in the "Getting Started" guide describes the standard way to install and license FactoryStudio. All servers and clients require the 4.0 of higher version of the .NET framework.

If you use components that do not require the setup of the Windows Registry, copy the product files without running an installation. This is especially useful for embedding the software on devices. If needed, you may remove the project examples or engineering components and add custom protocols. 

In distributed systems, the client computers do not require a license. They only need to connect to the server. For more information on the client setup, see "Remote Client Users Setup", below. 

TWebServer or IIS must be installed and running on the server computer if the system will have remote users.

License and Project Settings Verification

A FactoryStudio project is created targeting one specific Product Family and Product Model, as defined on the Project Settings → General page.

It is necessary to ensure that the license on the server computer is greater than or equal to the requirements of the project. Review the following checklist to ensure your license can handle your project. 

  • The Product Family defined in the license must be the same as the family in the project or a higher hierarchy family.
  • FrameworX for enterprises projects, everything included on FactoryStudio and more: Unlimited clients(.NET Smart Client, Web, HTML5, iOS), unlimited I/0 Points, unlimited Drivers.
  • FactoryStudio Powerfull and flexible tool for data collection and management, dashboard and report creation. Everything included on Edge HMI. Scalable the number of I/0 e clients. 70+ drivers included at no extra cost. C# VB.Net and Python. Redundancy available. SDK Extensions and Toolkit included.
  • Edge HMI licenses can run HMI and OPC Server projects
  • Edge Gateway - OPCServer licenses can run only OPC server projects
  • Express licenses or projects are not authorized for production environments
  • The Model in the license must support a number of communication points equal to or greater than the requirements of the project that will run on the server computer.
  • The License Type on the target computer must be Engineering or Runtime. Licenses of the DEV (Development) type are only for the internal work of System Integrators and may not be used in production environments.
  • If the project requires any additional interfaces, such as the OSIsoft™ PI System or IEC protocols, the license on the target computer must be enabled for those interfaces.
  • The number of enabled remote clients must meet the project requirements.

For more Information about product and license models, refer to Managing Licenses. "Versions and Licenses".<<<<.add link>>>>

Client Displays and Remote Visualization

This section focuses on setting up client displays for the Tatsoft FactoryStudio 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 Auto-Start Client Displays <page doesn't exist> has information on how to configure and use that features.

User Authentication and Security

This section summarizes various aspects of FrameworX documentation, 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.

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

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

Project 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

<<includes mention of Remote Access API and other builtin tools>>

Monitoring performance and health

 << mention <Troubleshooting and diagnostics> with link to main chapter on that>

Version Control, Maintenance and Upgrades

Discuss strategies for managing version control and upgrading deployed applications, including any recommended workflows and tools.

Managing version control for Product core and Project

Recommended workflows, tools and techniques.

Upgrading Deployed Applications

<< Mention Troubleshooting common issues with pointer to main chapter on that>

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

Page Tree
root@parent
spacesV10