Simuladores — /simulators

Configurar uma integração de chão de fábrica costuma esbarrar num problema de agenda: o CLP está na linha de produção, o PI System é de outra equipe, e ninguém libera testes no equipamento em horário produtivo. O CMS resolve isso trazendo os servidores para dentro dele mesmo.

São três, em abas separadas:

Servem para:

• validar a configuração de uma Coleta ou Entrega antes de ter acesso ao equipamento;
• reproduzir um cenário de erro em ambiente de teste, quantas vezes for preciso;
• demonstrar o fluxo completo sem depender da fábrica;
• treinar quem vai operar, sem risco de escrever num equipamento de verdade.

O que os três têm em comum

A Conexão Externa aparece sozinha

Ao habilitar um simulador, o CMS cria e mantém a Conexão Externa correspondente — “OPC Simulator (interno)”, “Modbus Simulator (interno)”, “PI Simulator (interno)”. Ela aparece normalmente em Conexões Externas e pode ser escolhida numa Aplicação, numa Coleta ou numa Entrega como qualquer outra. Não há endereço para digitar, nem risco de digitar errado.

Desabilitar o simulador não apaga a conexão: ela apenas para de responder.

Perfis: guardar cenários inteiros

Os três simuladores trabalham com perfis — instantâneos nomeados do conjunto de tags. Em vez de recadastrar tag por tag para cada teste, você salva “Prensa 3”, “Planta Norte”, “Cenário de falha” e alterna entre eles.

Aplicar e sobrescrever pedem confirmação, porque os dois trocam um conjunto inteiro de tags de uma vez.

Os perfis entram no import/export de configuração da Danger Zone — cada simulador com seu domínio próprio. É assim que um cenário montado na máquina de quem configurou vai parar no ambiente de demonstração.

Qualquer mudança reinicia o servidor

Salvar uma tag, aplicar um perfil ou mudar a porta reconstrói o servidor do zero. É proposital: mexer no address space “ao vivo” seria mais complexo e mais sujeito a estado inconsistente — e aqui não estamos num caminho de produção. As alterações são agrupadas numa janela curta, então salvar cinco tags seguidas provoca um reinício, não cinco.

OPC UA Simulator

Servidor OPC UA completo, servido pelo próprio cms-api. Expõe uma variável por tag cadastrada.

Configuração

O rodapé mostra o estado real: Rodando na porta N ou Desligado, e o erro quando a porta já está em uso.

O servidor escuta só em 127.0.0.1, dentro do cms-api: as Coletas e Entregas do próprio CMS o alcançam, um cliente de fora (UaExpert, outro servidor da rede) não. É de propósito — o simulador é anônimo e tem tags graváveis.

Tags de teste

Cada tag tem nome, NodeId, tipo de dado e valor atual:

• Tipos — BOOLEAN, INT16, INT32, FLOAT, DOUBLE, STRING.
• NodeId — segue o formato ns={ns};s=NomeDaTag, sugerido automaticamente a partir do nome.
• Valor atual — editável na própria lista, com um botão que grava na hora. Em tag BOOLEAN esse botão se chama Disparar; nos demais tipos, Salvar.

É esse botão que torna o simulador útil de verdade: uma Coleta OPC_UA_TRIGGER fica assinando a tag, e você provoca o disparo quando quiser, sem esperar um ciclo de máquina.

Modbus Simulator

Escravo Modbus TCP embutido. Diferente do OPC UA, o Modbus não tem modelo de objetos: o protocolo opera sobre quatro vetores de registradores brutos, endereçados por número.

As quatro tabelas

O endereço de uma tag é escrito como Tabela:Endereço — por exemplo HOLDING_REGISTER:40.

Tipos de dado e ordem de palavras

Como o registrador Modbus tem 16 bits, valores maiores ocupam dois registradores consecutivos. As tags declaram:

• Tipo — BOOLEAN, INT16, UINT16, INT32, UINT32, FLOAT32.
• Ordem das palavras — BIG_ENDIAN ou LITTLE_ENDIAN, para os tipos de 32 bits.

A camada de tags do simulador é uma conveniência da tela — nome e tipo por cima dos registradores crus. O que o mestre enxerga são os registradores.

PI Simulator

Imitação do PI Web API do AVEVA PI System (ex-OSIsoft). É o único dos três que não sobe porta nova: o PI Web API é REST, então o simulador é um endpoint dentro da própria API do CMS, em /api/pi-sim/piwebapi. Só o próprio CMS chega nele: pela borda (nginx) a rota responde 404, porque o simulador aceita leitura e escrita sem autenticação.

Tags que variam sozinhas

Esta é a diferença central para os outros dois simuladores. Um PI System guarda séries temporais: perguntar “qual o valor agora” é menos interessante que perguntar “como foi na última hora”. Por isso cada tag tem um comportamento, e o valor é calculado em função do tempo:

Os parâmetros são valor base, amplitude e período (s). Cada tag tem ainda nome, descrição, unidade e tipo de ponto (Float32, Float64, Int32, Digital, String).

Como o valor é calculado, e não armazenado, consultas de histórico funcionam para qualquer intervalo — inclusive antes de o simulador existir. Não há série a popular.

Regenerar WebIds

No PI, todo objeto é endereçado por um WebId opaco, que o CMS resolve a partir do caminho da tag e guarda. Quando as tags são recriadas no PI, ou o servidor é migrado, esses WebIds deixam de valer e o cliente precisa re-resolver os caminhos sozinho.

O botão Regenerar WebIds provoca exatamente isso: invalida de uma vez todos os WebIds já entregues. Serve para provar que o CMS se recupera sem que ninguém edite Coleta nenhuma — um cenário que num PI real seria caro e arriscado de reproduzir.

Fidelidade ao produto real

O simulador reproduz o contrato REST do PI Web API, incluindo detalhes que costumam pegar quem integra:

• exige o header X-Requested-With, como o PI real, que devolve 401 sem ele;
• consulta por path devolve o objeto direto, não uma coleção;
• WebId obsoleto responde 404, e não um erro genérico;
• respostas de histórico são limitadas a 5.000 amostras.

O que ele não reproduz é autenticação: aceita qualquer credencial, ou nenhuma — como um PI de laboratório aberto. Ver PI Web API.

Escrita em equipamento: o gate de permissão

Escrever numa tag OPC UA ou num registrador Modbus altera o estado de um equipamento real. Por isso as Entregas OPC_UA_WRITE e MODBUS_WRITE aceitam configurar uma tag de permissão de escrita no próprio equipamento: o CMS assina essa tag e só grava enquanto ela estiver no valor esperado.

É o CLP, e não o CMS, que decide quando aceitar escrita — que é a única ordem correta dessa decisão. Sem a tag configurada, a Entrega grava sempre que receber mensagem.

Falhar sem conseguir perguntar

Uma Entrega com gate configurado cuja assinatura da tag não está de pé responde não — nunca “não há restrição”. A diferença parece sutil e não é: até agosto de 2026 o gate OPC UA respondia lendo a existência da sessão, e “gate configurado, mas não consegui conectar” chegava ali com a mesma cara de “esta Entrega não tem gate”. O resultado era o pior possível — falhar em verificar se o CLP podia receber liberava a escrita no CLP. Hoje os dois gates, OPC UA e Modbus, falham fechados.

A conexão do gate também volta a tentar sozinha, com espera crescente de 2s a 20s, e a queda dispara CONEXAO_OPCUA_PERDIDA ou CONEXAO_MODBUS_PERDIDA. Antes, uma falha na primeira tentativa deixava a Entrega sem gate até alguém reiniciar a API.