You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Introduction and Key Concepts

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:

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.


Deployment and Architecture Scenarios

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 (2.1): Suitable for small-scale applications, testing, and development purposes.
  • Edge and Embedded Devices (2.2): Ideal for real-time data processing and decision-making at the network edge.
  • Client-Server Operations (2.3): Offers better resource utilization, centralized management, and improved scalability.
  • Redundant Servers and Hot-Standby Systems (2.4): Provides high availability and fault tolerance for critical applications.
  • Cloud Deployment (2.5): Enables improved scalability, flexibility, and reduced infrastructure costs.
  • Using the Secure WebGateway (2.6): 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. Read on for detailed information about each scenario.


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

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

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

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

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

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




Local and Distributed Systems

Our platform supports many deployment scenarios such as:

  • Embedded devices with no local user interface.
  • Stand-alone panels or computers with local user interface.
  • Distributed systems with many client stations accessing a server.
  • Redundant servers with multiple users connected.

The setup procedures for each scenario have many common steps. For all systems, FactoryStudio uses a client-server architecture.

The server components are the project file and the modules that run the server side tasks, such as data-acquisition, alarms, and data logging. The client components are the graphical user interfaces and related scripts.

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

FactoryStudio's client technologies simplify deployment because you only need to install the project on the server computer. The client's will use the project from the server.

In order to setup the server components or the stand-alone configurations, refer to the following sections: "Product Installation on the Target Computer", "License and Project Settings Verification", and "Installing the Project File".

Setting up the client can be slightly different according to its type. FactoryStudio supports the following client technologies:

  • Windows rich clients
  • Windows smart clients
  • Windows web-based clients
  • HTML5 clients
  • iOS clients

For more information on these client types, see "Remote Client Users Setup" below.

If you need to use Active-X, COM, and JavaScript, you can access the runtime application using the DataAccess API. This is a COM interface that provides integration with Active-X, JavaScript on web pages, or legacy programming languages such as VBScript. Contact support for assistance. 

For redundant scenarios, see "Deploying Redundant Systems" below.


Product Installation on the Target Computer

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 Info → Project → Settings 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 Family defined in the license must be the same as the family in the project or a higher hierarchy family.
  • Enterprise licenses can run all projects (Enterprise, HMI and OPCServer)
  • HMI licenses can run HMI and OPC Server projects
  • 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 "Versions and Licenses".<<<<.add link>>>>


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.


In this section...

  • No labels