Nesta pagina:
Typical deployment scenarios
The modules of Action.NET (Scripts, Dispositivo, Historiador ou Banco de Dados) se comunicam por Tcp-IP e assim podem ser colocados em diferentes computadores em um sistema distribuído. O mesmo conceito se aplica às ferramentas de visualização do cliente que podem ser executadas remotamente ou localmente no computador servidor.
Grandes projetos (aplicações) podem usar uma combinação de cenários de implantação do Action.NET, interconectar sites remotos ou usar os produtos EdgeHMI e IIoT Gateway para publicar dados no servidor principal.
Portanto, existem muitas configurações de implantação possíveis. Os básicos estão listados abaixo:
Sistema autônomo
Sistema Distribuído de Aquisição de Dados
Sistema Cliente e Servidor
Servidor Redundante
Sistema de controle
Sistema de controle distribuído e redundante
Conexão de dados com sites remotos
Aplicativos de múltiplas camadas
O Action.NET foi construído para ser usado em diferentes cenários e topologias, desde uma interface local em um painel embutido até servidores tolerantes a falhas que atendem a vários projetos e clientes. As ferramentas de desenvolvimento e os componentes do projeto do Action.NET são escalonáveis, reutilizáveis e consistentes.
Estabilidade Operacional
A implementação de código 100% gerenciado do Action.NET fornece estabilidade operacional incomparável devido à sua arquitetura de software intrinsecamente segura que inclui: isolamento de threads de execução, controle de exceção, recuperação de falha, implementação modular, abstrações de hardware e independência do sistema operacional.
| Info |
|---|
Altamente flexível, escalável e simples de usar Você pode acessar os dados de uma máquina remota de qualquer lugar e a qualquer hora. |
Da TI ao chão de fábrica
Para fornecer o melhor retorno de investimento possível em cada cenário de aplicação, o Action.NET um modelo de licenciamento flexível e simples que gera soluções que correspondem ao tamanho do seu projeto. As famílias e modelos de produtos permitem que você implante sistemas de alta qualidade e com boa relação custo-benefício, variando de IHM local, painéis de toque, sistemas embarcados, estações de supervisão, SCADA e sistemas distribuídos, bem como salas de controle e centros de operação.
Redundância e alta disponibilidade
Para sistemas de alta disponibilidade, o Action.NET tem a capacidade de ter um banco de dados em tempo real, servidores de Alarme e Historiador e aquisição de dados implantados como um sistema redundante hot-standby, sem necessidade de alterações no projeto.
A redundância hot-standby é comprovada em campo com centenas de dispositivos na rede e vários clientes.
Sistema autônomo
Em um sistema autônomo, os componentes do lado do servidor (aquisição de dados, alarmes e registro de dados) e os componentes do lado do cliente (telas e scripts do lado do cliente) são executados no mesmo computador.
O computador pode ser um desktop Windows, um Panel PC, um PC industrial, ou um sistema integrado. O sistema autônomo pode atuar como um publicador de dados para servidores Action.NET remotos que atuam como coletores de dados Edge.
Sistema Distribuído de Aquisição de Dados
Um Sistema de Aquisição Distribuída de Dados é caracterizado por possuir uma máquina servidor e módulos de dispositivos que funcionam em computadores dedicados à comunicação com PLCs ou historiadores em redes remotas que não podem ser alcançadas a partir do computador servidor. Na imagem de exemplo abaixo, o cliente SCADA pode ser colocado no mesmo computador que está executando o computador servidor ou em um remoto.
Este modelo é útil em fábricas que possuem dispositivos com portas seriais ou capacidade de comunicação limitada. Nessas fábricas, a comunicação em redes lentas ou de baixa largura de banda é otimizada e um melhor desempenho global é obtido pela adição de servidores de E / S que interagem com os dispositivos.
Sistema Cliente e Servidor
Em um sistema cliente e servidor, um servidor Action.NET executa os módulos do lado do servidor (alarme, historiador, aquisição de dados). As estações cliente do operador são executadas em outros computadores da rede ou em computadores remotos conectados por uma interface WAN ou Cloud.
Sistema de controle
Um Sistema de Controle pode ter vários servidores configurados em uma arquitetura distribuída em diferentes plantas e para diferentes projetos. Esta configuração permite que clientes específicos tenham acesso a uma sala de controle para qualquer uma dessas plantas ou projetos. Como os clientes da planta não serão integrados em uma única máquina, é necessário especificar qual planta os usuários desejam assistir.
Nesse cenário, o sistema é organizado em locais discretos controlados por operadores locais que são suportados por servidores redundantes locais. Ao mesmo tempo, um nível de gerenciamento em uma sala de controle central pode ser configurado para monitorar todos os sites simultaneamente. Cada site é representado no projeto como um cluster separado, agrupando seus servidores principal e em espera.
Sistema de servidor redundante
O Sistema de servidor redundante apresenta dois computadores diferentes executando servidores Action.NET, e a redundância é feita automaticamente pelo próprio sistema supervisório. Assim, é necessário apenas especificar os endereços IP das estações primárias e secundárias. Existem alguns cenários típicos de implantação para servidores redundantes:
O banco de dados de alarmes e / ou históricos está sendo executado em uma terceira máquina dedicada aos dados históricos.
As bases de dados nos servidores primário e secundário são utilizadas para armazenar os dados históricos dos módulos de Alarme e / ou Historiador, com sincronização automática dos dados entre eles.
O módulo do dispositivo (comunicação PLC) também se tornou redundante.
Sistema de controle distribuído e redundante
Um Sistema de Controle Distribuído e Redundante inclui uma máquina servidora com os módulos de Alarme, um Historiador, um Banco de Dados e Clientes SCADA localizados em diferentes computadores na rede.
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.
| Info |
|---|
Highly flexible, scalable and simple to use You can access data from a remote machine from anywhere, anytime. |
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.
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.
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.
| Scroll ignore | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
On this page: |