Arquitetura

Objetivo desta página

O integrador configura o projeto no Studio, mas quem faz a usina/planta “acontecer” é o Console (o runtime industrial) junto com os drivers de comunicação. Esta página explica, sem entrar em código, o que cada peça faz, como o dado viaja do CLP até a tela web e o que observar quando algo não funciona.

Painel administrativo web

O painel reúne configurações, licenças, comunicação, infraestrutura e ações de manutenção. Use as seções do painel para consultar o estado dos serviços e planejar a manutenção da instalação.

O que é o Console

O Console (Flessak.Gerenciador.Console) é o programa que roda continuamente no servidor da planta. Ele é o coração do sistema em tempo de execução:

carrega o projeto publicado (o mesmo que o Studio edita) e o banco de dados;
instancia um leitor por máquina, de acordo com o driver configurado na máquina;
mantém o ciclo de leitura das variáveis de cada dispositivo;
publica os valores em tempo real para a web e para os demais serviços (mecanismo interno de publicação/assinatura);
executa escritas/comandos vindos da web, com as validações de permissão;
calcula e publica as Tags Virtuais agendadas (ver outras páginas desta seção);
executa o sincronismo de variáveis entre origem e destino (ver outras páginas desta seção);
hospeda serviços auxiliares, como o broker MQTT embutido e a integração Telegram.

Se o Console não está rodando, a web até abre, mas mostra tudo sem dado — nenhuma leitura chega e nenhum comando sai.

O caminho do dado (do CLP à tela)

O driver conversa com o dispositivo no protocolo dele (TwinCAT ADS, Modbus, DNP3, OPC UA...) e obtém os valores brutos.
O leitor da máquina aplica o mapa de variáveis: converte endereços em variáveis nomeadas do projeto, com tipo e escala.
O Console publica cada variável atualizada no barramento interno de tempo real.
A web assina essas variáveis e atualiza as telas abertas; alarmes, CEPs e sincronismos reagem ao mesmo fluxo.
Os serviços de gravação (relatórios, persistentes, CEP) armazenam no banco o que está configurado para ter histórico.

O caminho do comando é o inverso: a web valida a permissão do usuário, envia ao Console, o Console entrega ao driver e o driver escreve no dispositivo.

O que é um driver

Consequências práticas dessa arquitetura:

é possível adicionar um protocolo novo sem reinstalar o sistema — basta colocar o driver na pasta e reiniciar o Console;
se o driver informado na máquina não existir na pasta, a máquina simplesmente não lê — o erro é silencioso; confira o nome do driver e o conteúdo da pasta Drivers\;
versões do driver e do Console devem ser compatíveis — use sempre o pacote de deploy oficial.

Driver é o “tradutor de protocolo”. Cada máquina do projeto declara qual driver usa (campo DriverName no Studio). No servidor, os drivers ficam em uma pasta própria (Drivers\) como bibliotecas independentes; o Console descobre e carrega os drivers dessa pasta automaticamente ao iniciar.

Protocolos disponíveis

Driver / protocolo	Uso típico
Beckhoff / TwinCAT ADS	CLPs Beckhoff — protocolo nativo, leitura por NetId/porta. Existe o driver clássico e o driver ADS moderno
Modbus TCP/RTU	CLPs, relés, multimedidores e inversores em geral
DNP3	Telecontrole e integração com centros de operação (ONS/concessionárias)
OPC UA	Integração com outros sistemas e CLPs que expõem servidor OPC
MQTT	Sensores IoT e brokers de mensageria
Sparkplug B	Unified Namespace — o supervisório atua como Host e/ou Edge Node
IEC 61850	Relés de proteção e IEDs de subestação
Siemens S7	CLPs Siemens
SNMP	Equipamentos de rede e infraestrutura de TI
SER / AdvancedCamera	Sequenciadores de eventos e câmeras de análise

Serviços que acompanham o Console

Serviço	Papel
Monitor	Recebe comandos remotos de gestão (reinício, atualização) e supervisiona o ambiente
Watch (serviço Windows)	Vigia o Console e o reinicia se ele parar — garante operação contínua
Agendador de relatórios	Grava históricos e envia relatórios periódicos
Leitor de CEP	Registra eventos discretos de alta velocidade
Gateway	Republica dados em DNP3/Modbus para sistemas externos

Sinais de problema e onde olhar

Sintoma	Causa provável	Verificação
Tudo sem dado na web	Console parado	Verificar o processo do Console no servidor; o Watch deve religá-lo
Uma máquina sem dado	Driver errado/ausente, IP incorreto, dispositivo fora	Nome do driver na máquina, pasta Drivers\, ping no IP, tela de diagnóstico
Algumas variáveis sem dado	Endereço errado no mapa de variáveis	Conferir o mapa e testar a variável no tempo real
Valores atrasados	Ciclo de leitura sobrecarregado ou rede lenta	Reduzir quantidade de variáveis de alta frequência; verificar a rede
Comando não chega	Permissão, variável de comando errada ou driver sem escrita	Nível do usuário, VariavelComando do controle, tipo de acesso no mapa

Regras de ouro

O Console é quem lê e escreve — a web é só a janela. Diagnóstico de comunicação começa no servidor.
Nunca copie drivers avulsos entre instalações de versões diferentes.
Reiniciar o Console interrompe leitura, gravação e comandos por alguns segundos — prefira janelas de baixa atividade.
Salvar certas configurações no Studio pode reiniciar partes do runtime automaticamente — faça isso de forma consciente em planta em operação.

Acompanhar o comissionamento no runtime web

Ilustração do manual — Figura A.1 — Checklist de comissionamento no runtime web; usuário ocultado.

Abra /comissionamento para acompanhar o estado do Console, a conexão Remote e os itens de configuração e comunicação de cada máquina. Confira os indicadores de comunicação mesmo quando os serviços estiverem em execução.

Referência: Como funcionam o Console e os drivers de comunicação, do manual do integrador.

Como funcionam os serviços de Relatórios e de CEP

Objetivo desta página

Relatório e CEP são recursos que o integrador configura no Studio (outras páginas desta seção), mas quem produz os dados são dois serviços que rodam no servidor. Entender o papel deles evita o erro clássico: “configurei no Studio e o relatório veio vazio”.

O serviço de relatórios (agendador)

O agendador de relatórios é um programa que roda junto ao Console e tem duas funções:

gravar o histórico: a cada ciclo, lê do tempo real as variáveis marcadas como variáveis de relatório e grava no banco, respeitando a frequência de gravação configurada;
emitir relatórios agendados: nos horários configurados (periodicidade), monta o relatório e o envia por e-mail aos destinatários cadastrados.

Pontos de funcionamento que o integrador precisa saber:

só entra no histórico o que está configurado como variável de relatório — variável exibida na tela mas não configurada não terá histórico;
a gravação respeita a frequência: com gravação a cada 30 minutos, um pico de 2 minutos entre gravações não aparece no relatório;
o banco consolida valores por hora (tabela de valores consolidados) para acelerar consultas longas — o relatório usa a fonte adequada ao período;
valores sem dado (falha de comunicação) são excluídos das médias e agregações — não distorcem o resultado;
as métricas de sistema (saúde do servidor) também são gravadas por este serviço;
a configuração dos relatórios carregada do banco prevalece sobre a cópia do arquivo de projeto — o que se vê na web reflete o banco.

Fluxo de um relatório agendado

O integrador configura no Studio as variáveis, agregações (média, total, acumulado...), template, periodicidade e e-mails.
O agendador grava o histórico dessas variáveis continuamente.
No horário da periodicidade, o agendador monta o relatório com o período fechado (dia anterior, mês anterior...).
O arquivo é gerado e enviado por e-mail; o mesmo modelo pode ser emitido manualmente pela web a qualquer momento.

O serviço de CEP (eventos discretos)

Como funciona, em linhas gerais:

as variáveis de CEP são marcadas no Studio por menu ou por máquina (outras páginas desta seção);
um serviço dedicado faz um handshake com o CLP: o CLP acumula os eventos com carimbo de tempo e o serviço os coleta e confirma o recebimento — assim nenhum evento se perde, mesmo que a coleta atrase;
em drivers que não têm esse mecanismo no dispositivo, o registro é feito pelo motor de gravação no servidor, por detecção de borda;
os eventos ficam no banco e aparecem na web (página de CEP) e nos relatórios que incluem CEPs.

O CEP registra eventos discretos — transições rápidas de sinais digitais (partiu, parou, atuou, abriu, fechou) — com data e hora precisas, para análise estatística e rastreabilidade de sequência de eventos.

Diferença entre os registros

Registro	O que guarda	Quem grava
Histórico de relatório	Valor da variável em intervalos regulares	Agendador de relatórios
CEP	Cada transição discreta, com carimbo de tempo do evento	Serviço de CEP / motor de gravação
Ocorrência	Alarmes e trips (início, fim, reconhecimento)	Runtime (Console)
Persistente	Último valor + histórico de alterações de variáveis de configuração	Runtime + operação PERSISTENT

Diagnóstico rápido

Sintoma	O que verificar
Relatório vazio ou com lacunas	A variável é de relatório? O agendador estava rodando no período? Frequência de gravação adequada?
Relatório não chega por e-mail	Periodicidade e destinatários configurados; servidor de e-mail acessível; agendador em execução
Eventos de CEP faltando	Serviço de CEP rodando; variável marcada como CEP; comunicação com o CLP no período
Números diferentes entre tela e relatório	Tela mostra instantâneo; relatório mostra média/agregação por intervalo — compare com a mesma janela

Consultar o Historian

Abra /historian para consultar volume de dados, consolidações horária e diária, atrasos, índices e métricas. Antes de reprocessar uma consolidação, confira o período e o escopo, mantenha backup e programe a execução conforme a rotina de manutenção.

Referência: Como funcionam os serviços de Relatórios e de CEP, do manual do integrador.

Como funciona o Gateway (DNP3 e Modbus para sistemas externos)

Objetivo desta página

O Gateway Flessak existe para o caminho contrário do habitual: em vez de o supervisório ler dispositivos, ele entrega dados do supervisório para sistemas externos — centro de operação da concessionária, ONS, outro SCADA — nos protocolos que esses sistemas falam (DNP3 e Modbus).

O que o Gateway faz

atua como servidor DNP3 (outstation) e/ou servidor Modbus: o sistema externo conecta no Gateway e lê os pontos;
usa um mapa de pontos: cada ponto DNP3/Modbus é associado a uma variável do supervisório (medição, estado, comando);
recebe os valores do tempo real do Console e os disponibiliza no protocolo externo, com os tipos adequados (analógico, digital, contador);
pode aceitar comandos vindos do sistema externo (quando o ponto é configurado para isso), repassando-os ao supervisório.

Fluxo de integração do Gateway

CLPs/dispositivos → drivers → Console (tempo real) → Gateway → rede do órgão externo (DNP3/Modbus) → centro de operação. O Gateway é a fronteira: o sistema externo nunca conversa direto com os CLPs.

O mapa de pontos

O coração da configuração é o mapa que relaciona o endereço externo à variável interna:

Campo	Significado
Índice / endereço do ponto	Número do ponto que o sistema externo vai ler (índice DNP3 ou registrador Modbus)
Tipo do ponto	Analógico, digital (estado), contador ou comando
Variável do supervisório	Qual variável do projeto alimenta o ponto
Escala / banda morta	Conversão de unidade e variação mínima para reportar (DNP3)

Alterou o mapa? O Gateway precisa recarregar a configuração. Combine com o órgão externo qualquer mudança de índice — o mapa é um contrato entre as partes.

Particularidades do DNP3

o DNP3 trabalha por eventos e classes: o ponto reporta variações, e o mestre faz varreduras de integridade periódicas;
há carimbo de tempo nos eventos — mantenha o relógio do servidor sincronizado (NTP);
o mestre externo identifica o Gateway por endereço DNP3 e porta TCP — esses dados constam do acordo de integração.

Checklist de comissionamento do Gateway

Confirmar com o órgão externo a lista de pontos (planilha de integração): índice, tipo, descrição, escala.
Configurar o mapa no Gateway e validar ponto a ponto contra o tempo real do supervisório.
Liberar a porta no firewall somente para os IPs do parceiro externo.
Executar teste ponta a ponta com o centro de operação (leitura, evento e, se houver, comando).
Registrar a versão do mapa aprovado e guardar a planilha assinada com o parceiro.

Diagnóstico rápido

Sintoma	O que verificar
Mestre externo não conecta	Serviço do Gateway rodando; porta e IP corretos; firewall/NAT no caminho
Ponto com valor errado	Variável associada, escala e tipo do ponto no mapa
Ponto congelado	A variável de origem tem dado no tempo real? O Console está publicando?
Comando externo não atua	Ponto configurado como comando; permissões; caminho até o CLP validado

Segurança

trate o link com o órgão externo como perímetro crítico: restrinja por IP, use rede dedicada/VPN quando possível;
só exponha os pontos acordados — o mapa é também um filtro do que sai da planta;
mudanças no mapa em produção devem ser combinadas, versionadas e testadas com o parceiro.

Referência: Como funciona o Gateway (DNP3 e Modbus para sistemas externos), do manual do integrador.