Typical deployment scenarios

The modules of Action.NET (Scripts, Device, Historian, or Database) communicate through Tcp-IP and thus can be placed on different computers on a distributed system. The same concept applies to client visualization tools that can be run remotely or locally on the server computer.

Large projects (applications) can use a combination of Action.NET deployment scenarios, interconnect remote sites, or use products EdgeHMI and IIoT Gateway to publish data to the main server.

Therefore, there are many possible deployment configurations. The basics are listed below:

• As

• Distributed Data Acquisition System

• Client and Server System

• Redundant Server

• Control system

• Distributed and redundant control system

• Connecting data to remote sites

Multi-tier applications

The Action.NET is built to be used in different scenarios and topologies, from a local interface on a built-in panel to fault-tolerant servers that serve multiple projects and clients. Development tools and design components of the Action.NET scalable, reusable, and consistent.

Operational Stability

Action.NET 100% managed code implementation provides unmatched operational stability due to its intrinsically secure software architecture that includes: execution thread isolation, exception control, failure recovery, modular deployment, hardware abstractions, and operating system independence.

From IT to the shop floor

To provide the best possible return on investment in each application scenario, the Action.NET a flexible and simple licensing model that generates solutions that match the size of your project. Families and product models allow you to deploy high-quality, cost-effective systems, ranging from local HMI, touch panels, embedded systems, supervisory stations, SCADA and distributed systems, as well as control rooms and operation centers.

Redundancy and high availability

For high availability systems, the Action.NET it has the ability to have a real-time database, Alarm and Historian servers and data acquisition deployed as a redundant hot-standby system, with no need for design changes.

Hot-standby redundancy is field proven with hundreds of devices on the network and multiple clients.

As

In a standalone system, server-side components (data acquisition, alarms, and data logging) and client-side components (client-side screens and scripts) run on the same computer.

Your computer can be a Windows desktop, a Panel PC, an industrial PC, or an integrated system. The autonomous system can act as a data publisher for Action.NET servers that act as Edge data collectors.

Open

Distributed Data Acquisition System

A Distributed Data Acquisition System is characterized by having a server machine and device modules that work on computers dedicated to communicating with PLCs or historians on remote networks that cannot be reached from the server computer. In the sample image below, the SCADA client can be placed on the same computer that is running the server computer or on a remote.

This model is useful in factories that have devices with serial ports or limited communication capability. In these factories, communication on slow or low bandwidth networks is optimized and better overall performance is achieved by adding I/O servers that interact with devices.

Open

Client and Server System

On a client and server system, a Action.NET server runs the server-side modules (alarm, historian, data acquisition). The operator's client stations run on other computers on the network or on remote computers connected by a WAN or Cloud interface.

Control system

A Control System can have multiple servers configured in an architecture distributed across different plants and for different projects. This setting allows specific clients to have access to a control room for any of these plants or projects. Because plant customers will not be integrated into a single machine, you must specify which plant users want to watch.

In this scenario, the system is organized in discrete locations controlled by local operators that are supported by local redundant servers. At the same time, a management level in a central control room can be configured to monitor all sites simultaneously. Each site is represented in the project as a separate cluster, grouping its primary and standby servers.

Redundant server system

The Redundant Server System features two different computers running Action.NET servers, and redundancy is done automatically by the supervisory system itself. Therefore, it is only necessary to specify the IP addresses of the primary and secondary stations. There are some typical deployment scenarios for redundant servers:

• The database of alarms and/or hiss is running on a third machine dedicated to historical data.

• The databases on the primary and secondary servers are used to store the historical data of the Alarm and/or Historian modules, with automatic synchronization of the data between them.

• The device module (PLC communication) has also become redundant.

Distributed and redundant control system

A Distributed and Redundant Control System includes a server machine with Alarm modules, a Historian, a Database, and SCADA Clients located on different computers on the network.