A arquitetura SCADA define a organização dos componentes responsáveis por adquirir sinais industriais, apresentar condições operacionais, processar alarmes, registrar históricos e permitir comandos supervisionados. Ela pode incluir servidores de aplicação, bancos de dados, historiadores, estações de operação, gateways, redes OT e interfaces com CLPs, remotas ou controladores de processo. O dimensionamento exige requisitos funcionais, volume […]
Confira!
A arquitetura SCADA define a organização dos componentes responsáveis por adquirir sinais industriais, apresentar condições operacionais, processar alarmes, registrar históricos e permitir comandos supervisionados. Ela pode incluir servidores de aplicação, bancos de dados, historiadores, estações de operação, gateways, redes OT e interfaces com CLPs, remotas ou controladores de processo. O dimensionamento exige requisitos funcionais, volume de dados, tempos de atualização, disponibilidade, recuperação de falhas e segurança de acesso.
Um sistema SCADA não se resume ao software instalado em uma estação de trabalho. A engenharia precisa demonstrar como os dados são adquiridos, qual sua qualidade, quem tem autoridade de comando, como os alarmes são registrados e como o serviço permanece operacional diante de falhas previstas. Redundância de servidores, isoladamente, não garante continuidade quando rede, banco de dados ou alimentação permanecem como pontos únicos de falha.
Componentes funcionais de uma arquitetura SCADA
O sistema reúne fontes de dados de campo e camadas de aplicação. Controladores e remotas fornecem medições, estados e eventos; servidores recebem, organizam e distribuem informação; historiadores permitem análise temporal; estações de operação exibem estados e comandos. Cada componente precisa de responsabilidade e interface documentadas.
A segregação de funções favorece desempenho e segurança. Um historiador e um servidor de alarmes podem compartilhar infraestrutura conforme a arquitetura, mas as dependências precisam ser explicitadas. A escolha da topologia depende da criticidade, do volume de sinais e das necessidades de manutenção.
| Camada | Função | Evidência |
| Campo | Medição e atuação | Lista de pontos |
| Controle | Lógica e permissivos | Descrição funcional |
| Comunicação | Transporte de dados | Topologia e testes |
| Aplicação SCADA | Telas, alarmes e comandos | FAT funcional |
| Históricos | Armazenamento temporal | Retenção e consulta |
Aquisição de dados e qualidade da informação
A definição técnica dos requisitos e interfaces orienta a contratação e reduz adaptações durante a implantação.
O SCADA deve conhecer o significado de cada tag: origem, unidade, escala, limites, atualização e condição de qualidade. Um valor desatualizado precisa ser distinguido de uma medida atual. A camada de comunicação pode usar diferentes protocolos conforme os controladores e os requisitos de interoperabilidade.
A frequência de atualização deve considerar a dinâmica do processo, a rede e a capacidade de servidores. Consultar milhares de tags em intervalos desnecessariamente curtos pode sobrecarregar componentes sem melhorar a decisão operacional. Dados destinados a alarmes e controle de resposta rápida podem exigir tratamento diferente de tendências lentas.
A lista de tags deve ser rastreável a desenhos, documentação funcional e testes. No aceite, uma comunicação estabelecida não comprova que escalas, estados e comandos possuem o significado correto.
Servidores, estações e arquitetura lógica
A organização dos servidores depende de número de usuários, clientes simultâneos, quantidade de sinais, eventos, históricos e políticas de disponibilidade. Máquinas virtuais podem facilitar manutenção e recuperação, mas não eliminam necessidade de dimensionar CPU, memória, armazenamento e dependências de infraestrutura.
A arquitetura precisa definir sessões, autenticação, funções de operadores e engenharia, backups, licenças, capacidade de restauração e janela de manutenção. A decisão de centralizar serviços deve ser confrontada com o impacto de indisponibilidade. Ambientes distribuídos podem reduzir determinadas dependências, mas aumentam a necessidade de gestão de versões e comunicação.
Os desenhos lógicos devem identificar sistemas de operação, engenharia e dados, interfaces externas e fluxos permitidos, preservando segregação entre redes OT e sistemas corporativos.
Historiadores e retenção de dados
O historiador armazena séries temporais para análise de operação, desempenho e incidentes. A engenharia deve definir quais variáveis merecem coleta, resolução temporal, compressão quando aplicável, período de retenção e mecanismos de consulta. Registrar tudo na maior frequência possível não é uma estratégia de dados suficiente.
Eventos, alarmes, comandos e tendências têm semânticas diferentes. Um alarme reconhecido pelo operador não equivale à condição física normalizada. É recomendável manter rastreabilidade temporal e qualidade de dados, evitando que valores inválidos sejam interpretados em relatórios.
A política de retenção depende de requisitos de processo, obrigações contratuais, capacidade de armazenamento e recuperação. A validação deve incluir consulta de períodos, consistência de timestamps e restauração após falha.
Redundância e pontos únicos de falha
Uma arquitetura redundante pode duplicar servidores ou enlaces, mas o efeito real depende de como ocorre a transferência de serviço, de quais estados são preservados e de como os clientes se reconectam. Um banco de dados único, switch central ou fonte comum pode anular a disponibilidade pretendida.
O projeto deve documentar cenários de falha e definir expectativas de recuperação. A perda de um servidor não deve produzir comando indevido ou registros inconsistentes. Em certos casos, a supervisão pode ficar indisponível sem interromper o controle local; em outros, existem funções dependentes de integração e exigem avaliação própria.
| Elemento | Falha considerada | Teste recomendado |
| Servidor principal | Indisponibilidade | Transferência e recuperação |
| Historiador | Perda de conexão | Buffer e sincronização |
| Enlace OT | Ruptura | Recuperação de comunicação |
| Banco de dados | Falha de armazenamento | Integridade e restauração |
| Estação de operação | Indisponibilidade | Continuidade por estação alternativa |
Alarmes, eventos e operação segura
Uma estratégia de alarmes deve distinguir condição anormal, prioridade, ação esperada, reconhecimento, supressão autorizada e retorno ao estado normal. A qualidade não depende de apresentar o maior número de alarmes possível, mas de fornecer informações acionáveis e minimizar condições que confundam o operador.
A interface deve preservar visibilidade de comunicação indisponível, falha de medição e autoridade de comando. Um valor estático, sem indicação de qualidade, pode ser confundido com processo estável. É necessário definir quem pode executar determinadas ações e como comandos são registrados.
A revisão do sistema supervisório pode ser aprofundada no artigo de sistemas supervisórios e SCADA, enquanto os requisitos de automação e controladores permanecem detalhados no hub de automação industrial.
Topologia de referência e segmentação OT
O SCADA conecta sistemas de controle à operação, porém a integração com redes corporativas exige segmentação apropriada e fluxos explicitamente autorizados. O monitoramento remoto e a manutenção demandam autenticação, gestão de acessos e registros. A Ethernet industrial fornece os princípios de topologia e comunicação a considerar.
O diagrama não implica que dois servidores sejam obrigatórios; a escolha depende de disponibilidade requerida, orçamento de risco e capacidade de operação degradada.
FAT, SAT e cenários de resiliência
O FAT precisa verificar tags, alarmes, permissões, telas, tendências, relatórios e interfaces com sistemas representados em bancada ou simulação. O SAT complementa com equipamentos, redes e condições reais da instalação. Cada limitação da bancada precisa ser documentada e transferida para o plano de campo.
Falhas de servidor, comunicação, histórico e sincronização temporal devem ter cenários de teste próprios. A evidência não pode ser apenas a ausência de mensagem de erro: é preciso verificar continuidade funcional, integridade de dados e comportamento do operador.
| Teste | Condição | Critério |
| Falha de servidor | Nó indisponível | Recuperação prevista |
| Alarme de processo | Desvio induzido | Prioridade e reconhecimento |
| Dado inválido | Perda de fonte | Indicação de qualidade |
| Retorno da rede | Reconexão | Valores e eventos coerentes |
Contratação da engenharia SCADA
A contratação deve descrever escopo, fontes de dados, lista de pontos, arquitetura lógica, interface homem-máquina, requisitos de desempenho, disponibilidade, retenção, cibersegurança, migração e testes. O projeto precisa distinguir responsabilidades dos fornecedores de CLP, redes, servidores e aplicações.
A engenharia de projeto de automação industrial pode estabelecer critérios para aquisição e integração; o comissionamento de equipamentos deve receber planos e evidências de testes rastreáveis.
O preço do software não representa sozinho o custo do sistema. Infraestrutura, licenças, manutenção, interfaces e testes são partes essenciais do objeto.
Definição da arquitetura por funções e criticidade
Antes de dimensionar servidores, a engenharia deve distinguir funções de simples visualização, comando remoto, alarmes, registro histórico, relatórios e integração com outras aplicações. Cada função possui tolerância diferente à indisponibilidade e à perda de dados. Uma falha de historiador pode comprometer a análise posterior sem afetar controle local; já uma falha de comunicação pode tornar indisponível a operação remota. A especificação deve estabelecer o que pode continuar operando em modo degradado e qual evidência comprova essa continuidade.
A arquitetura lógica deve representar fontes de dados, caminhos de comunicação, aplicações, bancos, clientes e serviços compartilhados. Diagramas de rede e de implantação devem permitir identificar pontos únicos de falha. A divisão de responsabilidades entre equipe de OT, TI, automação e integrador precisa aparecer na matriz de interfaces. Isso evita atribuir ao fornecedor de software problemas de energia, rede ou hardware que não fazem parte de seu objeto, ou deixar lacunas entre fornecimentos.
Dimensionamento de tags, eventos e carga de consulta
A quantidade de tags é apenas o início do dimensionamento. A engenharia precisa estimar tipos de variáveis, frequência de leitura, taxa de mudanças, quantidade de clientes simultâneos, alarmes, eventos e volume histórico. Uma leitura de atualização rápida pode consumir muito mais recursos que dezenas de pontos lentos. Também é necessário avaliar retransmissão após reconexões, picos de eventos e consultas de histórico em períodos extensos.
A memória de cálculo deve documentar hipóteses de crescimento e critérios de capacidade. A coleta não deve reduzir a confiabilidade do controle local, nem gerar tráfego excessivo na rede. Deadband, compressão e políticas de amostragem podem ser utilizados quando apropriados, desde que preservem informação exigida para diagnóstico. A aceitação de desempenho precisa utilizar cargas representativas e indicadores mensuráveis, não apenas verificação de que as telas abriram.
Banco de dados, historiador e integridade temporal
Históricos permitem interpretar tendências, falhas e desempenho, mas seu valor depende de informação temporal confiável. É necessário definir origem do timestamp, qualidade dos dados, sincronização dos equipamentos, condições de perda de comunicação e critérios de retenção. Eventos que chegam atrasados devem ser tratados de forma que não distorçam a sequência observada. Um valor sem qualidade ou com horário incoerente pode prejudicar relatórios e investigação de incidentes.
O historiador também exige plano de backup, restauração, crescimento e consulta. A engenharia deve diferenciar retenção operacional de armazenamento de longo prazo quando houver necessidade de auditoria. Ensaios precisam demonstrar recuperação de dados e consistência entre servidores, especialmente após falhas simuladas. Não é suficiente verificar que o sistema continua gravando durante o FAT em condições normais.
Redundância, RTO e continuidade da supervisão
Falhas de integração e comportamento degradado exigem diagnóstico antes de mudanças no sistema.
A redundância deve ser especificada como função verificável, com cenários de indisponibilidade, transição e recuperação. Dois servidores no mesmo switch ou alimentados por uma única infraestrutura podem permanecer vulneráveis à mesma falha. O projeto deve analisar armazenamento, autenticação, redes, sincronização, licenças e estações operacionais. Recursos de failover só agregam valor se as funções necessárias continuarem disponíveis dentro de limites aceitos pelo empreendimento.
Critérios de recuperação podem incluir tempo de restabelecimento, perda admissível de registros e necessidade de reconexão manual. A aplicação não deve executar comandos antigos automaticamente após retorno de sessão. Os ensaios precisam observar alarmes, tendências, permissões e consistência de dados antes, durante e após a comutação. A demonstração de um servidor secundário em operação não comprova o desempenho de toda a arquitetura.
Gestão de alarmes e usabilidade operacional
Uma filosofia de alarmes define o que exige ação, como priorizar ocorrências e qual informação o operador precisa receber. Avisos de manutenção, eventos de estado e alarmes de processo não são equivalentes. Quando uma falha de rede gera centenas de alarmes derivados, o operador pode perder a causa principal. O sistema deve apresentar status de qualidade dos dados e condições de comunicação de modo inteligível.
A engenharia de alarmes deve produzir lista de condições, prioridades, consequências e respostas esperadas. O reconhecimento por operador não implica que a causa foi eliminada. FAT e SAT devem testar ativação, retorno, supressão autorizada, histórico e permissões. Telas e diagnósticos devem usar nomenclatura consistente com os documentos e com as funções implementadas nos controladores.
Cibersegurança OT e administração de acessos
Servidores SCADA são ativos operacionais que podem permitir comandos sobre processos físicos. A arquitetura de segurança deve contemplar segregação de redes, privilégios de usuário, controle de acesso de engenharia, registro de alterações e procedimentos de manutenção remota. A conexão corporativa precisa seguir fluxos explicitamente autorizados, com avaliação do impacto sobre disponibilidade. A referência NIST SP 800-82 permite estruturar ameaças e medidas de segurança específicas de OT.
Gestão de correções e atualização de sistema operacional requer teste de compatibilidade e janela adequada. Backups precisam incluir não apenas bases de dados, mas configurações de aplicação, drivers, telas, licenças e credenciais tratadas de forma segura. Uma política de restauração deve ser ensaiada periodicamente quando o risco operacional justificar. Controle de mudanças e inventário de ativos ajudam a reduzir falhas introduzidas por intervenções não documentadas.
Matriz de interfaces com controladores e terceiros
A integração com CLPs e remotas exige definição de endereços, escalas, unidades, qualidade, periodicidade e autoridade de comandos. Uma conexão estabelecida não comprova semântica adequada. A lista de tags deve identificar a origem de cada variável e qual equipe responde pela configuração em cada extremidade. Em sistemas com múltiplos fornecedores, o integrador SCADA não deve assumir unilateralmente que todos os pontos e mensagens serão entregues prontos.
O plano de testes deve prever valores extremos, sinais invertidos, indisponibilidade de dispositivo, reconhecimento de comando e retorno de estados. Além de evitar erros de exibição, essa revisão permite identificar responsabilidades por alarmes e eventos. Mudanças na estrutura de dados de um controlador devem passar por avaliação de impacto sobre telas e históricos, com controle de versão entre as aplicações.
Migração SCADA em instalações em operação
Os ensaios precisam comprovar funcionamento, falhas e recuperação com evidências vinculadas aos requisitos.
A substituição de um supervisório pode exigir operação paralela durante a transição. Antes da migração, é necessário levantar software, drivers, licenças, telas, alarmes, usuários, históricos, integrações e requisitos de retenção. Nem todos os elementos são automaticamente transportados entre plataformas. A decisão de manter ou reconstruir uma função precisa ser documentada junto ao processo e à equipe de operação.
A estratégia deve prever testes de interoperabilidade, compatibilidade de dados, janelas de parada e plano de retorno. Alarmes e permissões são especialmente críticos porque diferenças sutis podem alterar a resposta do operador. O aceite precisa comparar o comportamento da nova arquitetura com os requisitos aprovados e registrar eventuais mudanças. A documentação final deve incluir configuração e procedimento de recuperação, não apenas uma cópia do banco de dados.
Critérios de FAT/SAT para resiliência e dados
O plano de ensaios deve associar casos de teste a funções identificáveis: qualidade de tags, alarmes, comandos, permissões, armazenamento, redundância e recuperação. É necessário determinar quais condições serão simuladas em bancada e quais dependerão do ambiente instalado. Os procedimentos devem registrar precondição, estímulo, resposta esperada, duração admissível, evidência e versão do software.
Cenários de falha incluem indisponibilidade de servidor, perda de rede, interrupção de historiador e troca de autoridade de operação. Para cada um, os resultados devem comprovar dados coerentes, ausência de comandos indevidos e capacidade de recuperação. A existência de um relatório de SAT não é prova suficiente quando os requisitos não podem ser rastreados aos casos executados. Pendências devem ter classificação, responsável, prazo e reteste.
Modelo de contratação e documentação de aceite
O escopo técnico de um SCADA precisa diferenciar fornecimento de licenças, infraestrutura, engenharia de telas, banco de dados, integração, rede, alarmes, históricos, testes, treinamento e suporte. Sem essa decomposição, fornecedores podem precificar objetos distintos apesar de citarem o mesmo número de tags. O memorial deve estabelecer limites, desempenho, disponibilidade e documentação, incluindo direitos de uso e condições para expansão.
Marcos comerciais podem estar associados à aprovação da arquitetura, desenvolvimento, FAT, implantação, SAT e entrega final, conforme o contrato. A avaliação deve considerar riscos de continuidade e esforço de manutenção, não apenas o custo inicial do software. Requisitos de acesso, backup e operação degradada precisam ser negociados antes da implantação, quando ainda é possível comparar soluções sem custos significativos de retrabalho.
Exemplo de dimensionamento para operação multisite
Imagine um sistema supervisório que recebe dados de diversas estações de bombeamento, cada uma com CLP e comunicação própria. A arquitetura deve distinguir disponibilidade de controle local e disponibilidade de supervisão central. A perda de comunicação com uma estação não pode ser apresentada como nível ou pressão normal apenas porque os últimos valores conhecidos permanecem armazenados. A qualidade dos dados deve acompanhar as informações em telas, históricos e alarmes.
O dimensionamento precisa considerar quantidade de estações, periodicidade de leitura, picos de eventos, latência de enlaces e reconexões simultâneas. Também é necessário definir armazenamento temporário em cada origem quando aplicável e regras de sincronização posterior. O aceite precisa simular indisponibilidade e retorno da comunicação, verificando coerência temporal e apresentação ao operador. Essas condições têm maior valor do que uma demonstração limitada à rede em estado normal.
Arquitetura de serviços e virtualização
A virtualização pode facilitar recuperação e administração dos servidores SCADA, mas introduz dependências de hipervisor, armazenamento, autenticação e rede que precisam ser reconhecidas no projeto. Uma arquitetura com duas máquinas virtuais hospedadas em um único servidor físico não é equivalente à redundância de infraestrutura. A engenharia deve definir quais falhas devem ser toleradas e quais serviços compartilham recursos críticos.
Também é necessário considerar licenciamento, compatibilidade das aplicações e procedimentos de atualização. O dimensionamento deve preservar recursos para picos de processamento, consulta ao historiador e recuperação de sessão. Ensaios de failover devem verificar clientes, dados, alarmes e comandos autorizados, além da simples disponibilidade de instâncias virtuais. O plano de recuperação precisa ser testável e documentado.
Testes de integração semântica de tags
Uma tag pode apresentar comunicação ativa e ainda conter valor incorreto. A matriz de integração deve registrar unidade, escala, valor válido, endereçamento, origem, destino, frequência de atualização e condição de qualidade. Uma pressão recebida com fator de conversão inadequado pode parecer plausível na tela, mas levar a diagnósticos errados. O FAT precisa comparar valores conhecidos e verificar os limites operacionais.
Estados discretos também exigem cuidado: equipamento comandado, contator energizado e condição física confirmada não são equivalentes. A integração deve preservar essa distinção, inclusive em alarmes e históricos. Se o controlador muda a estrutura de dados, a atualização precisa ser comunicada aos responsáveis pelo SCADA e submetida a teste. A semântica da informação faz parte do projeto.
Indicadores de desempenho operacional
Além da disponibilidade dos servidores, a aceitação pode acompanhar tempo de atualização, falhas de comunicação, atraso de alarmes e capacidade de recuperar tendências, desde que sejam definidos métodos e limites de medição. A presença de gráficos em tempo real não comprova que o conjunto atende ao processo. É preciso determinar o que o operador precisa saber, em quanto tempo e com que grau de confiabilidade.
Uma aplicação com histórico volumoso deve ser testada durante consultas simultâneas e recuperação de dados após falhas. Também é necessário avaliar impacto de novas estações e novos sinais sobre a infraestrutura existente. A memória de dimensionamento fornece a referência para futuras ampliações e ajuda a evitar degradação silenciosa de desempenho.
Documentação e governança da supervisão
A documentação final deve incluir arquitetura lógica, diagramas de comunicação, matriz de tags, filosofia de alarmes, configuração de servidores, políticas de backup, usuários, licenças, procedimentos de recuperação e relatórios FAT/SAT. Em instalações críticas, também deve registrar responsabilidades entre TI, OT, operador e fornecedor. Sem essas informações, manutenção e expansão se tornam dependentes de conhecimento tácito.
Mudanças em telas, alarmes, drivers e servidores precisam de avaliação de impacto. Uma alteração pode afetar comandos, históricos ou relatórios sem interromper imediatamente a aplicação. O gerenciamento de versões e os testes regressivos preservam rastreabilidade. A revisão de documentação deve acompanhar a configuração realmente instalada, com pendências e exceções formalmente registradas.
Plano de contingência operacional para supervisão
O projeto precisa distinguir indisponibilidade de visualização, perda de históricos e impossibilidade de comando remoto. Esses eventos possuem impactos diferentes, e o plano de contingência deve especificar o que continuará funcionando localmente. Quando o controle reside em CLPs, a arquitetura pode permitir operação sem o SCADA, desde que as funções e procedimentos tenham sido projetados para essa condição. O operador precisa conhecer os limites do modo degradado e as informações que deixarão de estar disponíveis.
A restauração precisa seguir etapas documentadas: diagnóstico da falha, verificação da infraestrutura, reinicialização controlada de serviços, integridade de bancos, reconexão de fontes e confirmação de alarmes e comandos. O aceite deve exercitar cenários relevantes sem induzir riscos ao processo. Um plano escrito, mas não testável, oferece garantia limitada de continuidade.
Responsabilidade sobre rede, servidores e aplicações
A arquitetura de um SCADA envolve interfaces entre engenharia de automação, infraestrutura computacional, telecomunicações e operação. A matriz de responsabilidades deve especificar quem fornece equipamentos, parametriza redes, configura servidores, administra usuários, desenvolve telas e executa testes integrados. É necessário evitar contratos nos quais cada fornecedor entrega seu componente, mas ninguém assume a validação do fluxo completo de dados.
A definição de interfaces também orienta os marcos de medição. Um servidor instalado pode ainda não possuir tags integradas, alarmes aceitos ou capacidade de recuperação comprovada. A governança do projeto precisa reconhecer essas diferenças e manter rastreabilidade de pendências até o aceite.
Política de retenção e integridade de dados
A retenção de dados de processo deve ser definida com base em finalidade operacional, investigação de falhas, gestão de ativos e eventuais requisitos contratuais. Uma política genérica de armazenar todos os sinais por prazo indeterminado pode aumentar custos sem garantir utilidade. A engenharia deve classificar dados por criticidade, frequência, qualidade e necessidade de consulta, observando mudanças de configuração ao longo do tempo.
A recuperação de históricos deve ser testada após falhas de armazenamento e comunicação. Os registros precisam preservar, quando exigido, informações de contexto suficientes para interpretar os valores. Uma série temporal que perde unidade, origem ou indicação de invalidade pode ser inadequada para auditorias e análises técnicas.
Método de avaliação de propostas SCADA
Propostas de sistemas supervisórios podem ter o mesmo número de tags e diferenças relevantes em licenciamento, redundância, histórico, acesso remoto, telas, documentação e testes. A comparação precisa definir uma base técnica comum. A matriz deve separar licenças, engenharia de desenvolvimento, infraestrutura, integração com controladores, gestão de alarmes e serviços de comissionamento.
O resultado da avaliação deve indicar requisitos atendidos, desvios, riscos e condições comerciais associadas. Uma proposta tecnicamente incompleta não deve ser considerada equivalente apenas por preço. A seleção precisa considerar a capacidade de manter a aplicação ao longo do tempo, restaurá-la após falhas e demonstrar sua conformidade antes da entrada em operação.
Considerações finais
A qualidade de uma arquitetura SCADA depende menos da quantidade de servidores ou da aparência das telas e mais da capacidade de manter informação operacional íntegra, atualizada e utilizável. O projeto deve distinguir controle local, supervisão central, gestão de alarmes, registro histórico e comando remoto, atribuindo requisitos de desempenho, disponibilidade e segurança a cada função. Redundância só representa ganho comprovado quando pontos únicos de falha e mecanismos de recuperação são analisados como parte do sistema completo.
A integridade dos dados merece a mesma prioridade que a continuidade da aplicação. Escalas, unidades, qualidade, timestamps, perda e recuperação de comunicação precisam ser tratados desde a lista de tags até o historiador e a interface do operador. Sem essa consistência, um sistema pode continuar disponível tecnicamente e, ainda assim, fornecer informações inadequadas para diagnosticar a planta ou tomar decisões. A governança de acessos e mudanças também deve acompanhar a criticidade das operações permitidas.
O recebimento da engenharia SCADA deve ser orientado por cenários verificáveis de operação e resiliência: falha de servidor, interrupção de rede, restauração de históricos, atualização de alarmes e reconexão das fontes. FAT, SAT e procedimentos de recuperação precisam associar resultados à arquitetura e à versão efetivamente instalada. Assim, a contratação deixa de ser uma compra de software e passa a estabelecer requisitos de continuidade, rastreabilidade e desempenho para a operação industrial.
Referências técnicas
[1] IEC. IEC 61131-3:2025 — Programming languages. Disponível em: https://webstore.iec.ch/en/publication/68533.
[2] NIST. Guide to Operational Technology Security. Disponível em: https://csrc.nist.gov/pubs/sp/800/82/r3/final.
[3] PLCOPEN. Software Construction Guidelines. Disponível em: https://www.plcopen.org/guidelines/software-construction-guidelines/.
[4] SIEMENS. Industry Online Support. Disponível em: https://support.industry.siemens.com/.
[5] ISA. Standards and Publications. Disponível em: https://www.isa.org/standards-and-publications.
Perguntas frequentes
Por requisitos, desempenho, interfaces, disponibilidade e manutenção.
Testes em fábrica ou bancada conforme escopo documentado.
Ensaios de aceitação no ambiente instalado e nas interfaces reais.
Descrição funcional, arquitetura, sinais, versões, configurações, planos e evidências de teste.
Com diagnóstico, qualidade dos dados e estados de contingência especificados.
Testes rastreáveis aos requisitos e registro das pendências e retestes.
Com controle de versões, avaliação de impacto, backup e regressão.
Escopo, interfaces, responsabilidades, entregáveis e critérios de verificação.
Controle, interface de operação e supervisão, respectivamente.
