A fronteira entre TI e TO em uma empresa de serviços públicos não é uma linha nítida em um diagrama de rede. É uma membrana permeável por onde os dados fluem em ambas as direções: programas em lote COBOL geram arquivos de configuração de pontos de ajuste consumidos por PLCs; programas RPG leem dados históricos do SCADA para faturamento e relatórios regulatórios; sistemas legados de ponte C traduzem saídas de mainframe para formatos que os sistemas de controle distribuído entendem; fluxos de tarefas JCL agendam e sequenciam as trocas de dados através da fronteira, com base no tempo do qual os processos operacionais dependem. O software que gerencia esse fluxo não é puramente TI nem puramente TO. É o tecido conjuntivo que faz os serviços públicos funcionarem e é a categoria de código que as equipes de modernização estão menos preparadas para analisar quando um programa de transformação começa.
O setor de energia está passando por uma das transformações digitais mais significativas de sua história. À medida que as concessionárias modernizam sua infraestrutura com redes inteligentes, subestações conectadas, sistemas de controle industrial (ICS) e automação avançada, as redes de tecnologia operacional (OT) tornaram-se mais interconectadas do que nunca. Essa interconexão não elimina a camada de código legado, mas a torna ainda mais crítica, pois cada novo ponto de acesso de rede inteligente e plataforma de análise em nuvem depende de fluxos de dados originados em aplicações escritas décadas atrás. Modernizar essas aplicações sem compreender seu papel na cadeia de dados operacionais não é modernização, mas sim uma disrupção com consequências que vão além do data center, atingindo a infraestrutura física.
Encontre todos os parâmetros operacionais fixos no código.
SMART TS XL Localiza todas as constantes da UE, limites de alarme e endereços de protocolo incorporados em seu portfólio de código legado.
SAIBA MAIS…O que significa, na prática, "adjacente ao SCADA"
O termo "adjacente ao SCADA" descreve o software do lado da TI que interage com os sistemas de tecnologia operacional, não o próprio software SCADA, nem o firmware do PLC, nem o código embarcado da RTU, mas sim a camada de aplicação de negócios que envia e recebe dados desses sistemas. Essa categoria é ampla, pouco analisada e genuinamente diferente do restante do portfólio de aplicações corporativas.
Em um ambiente típico de serviços públicos, o código adjacente ao SCADA inclui:
Programas de cálculo de taxa e ponto de ajuste. Programas em COBOL e PL/I que calculam pontos de ajuste de carga, metas de tensão, limites de pressão e limites operacionais, fornecidos a sistemas SCADA como arquivos de configuração ou fluxos de dados diretos. Esses programas incorporam requisitos de conformidade regulatória, especificações de engenharia e limites de segurança física. Um cálculo incorreto não produz um número errado em um relatório, mas sim um ponto de ajuste operacional incorreto que o sistema de controle utiliza.
Consumidores de dados históricos. Programas em RPG e COBOL que leem dados operacionais de bancos de dados históricos SCADA para faturamento, relatórios regulatórios e análise de desempenho. Esses programas dependem de formatos de dados específicos, convenções de carimbo de data/hora e definições de unidades de engenharia geradas pelo sistema histórico. Uma alteração no formato de saída do sistema histórico ou uma alteração no programa consumidor do lado da TI pode corromper silenciosamente os cálculos de faturamento ou os envios regulatórios.
Programas de ponte de protocolo. Programas personalizados em C que traduzem entre formatos de saída do mainframe e as interfaces baseadas em arquivos ou em rede utilizadas por sistemas DCS (Sistema de Controle Distribuído) e SCADA. Essas pontes implementam protocolos específicos, como Modbus, DNP3, IEC 61850 e formatos proprietários de fornecedores, e possuem suposições fixas sobre estrutura de mensagens, ordem de bytes e temporização que não constam em nenhuma documentação.
Fluxos de dados de lote para tempo real. Fluxos de tarefas JCL que agendam e sequenciam trocas de dados entre TI e TO em janelas de tempo específicas. Uma execução em lote noturna de uma concessionária pode gerar dados de configuração que devem estar disponíveis para o sistema SCADA antes do início das operações da manhã. A dependência de tempo está implícita na configuração do agendador e nas expectativas operacionais da sala de controle, não estando documentada em nenhum lugar no código do aplicativo.
Programas de processamento de alarmes e eventos. Programas que recebem registros de alarmes de sistemas SCADA, aplicam lógica de classificação e roteamento, geram ordens de serviço e produzem registros de conformidade regulatória. A lógica de classificação de alarmes, que define quais eventos exigem quais relatórios regulatórios e dentro de quais prazos, está frequentemente incorporada em código de programa que acumulou décadas de mudanças regulatórias.
Este é o código que controla tanto engenheiros quanto desenvolvedores de TI, que o dominam parcialmente, mas que nenhum dos dois compreende completamente. Quando um programa de modernização pergunta "o que podemos mudar?", a resposta para o código adjacente ao SCADA é quase sempre "menos do que você imagina, e somente após uma análise mais aprofundada do que a planejada".
Por que a análise de modernização padrão falha aqui
A maioria das estruturas de análise de modernização empresarial parte do pressuposto de que o código analisado controla apenas dados e lógica de negócios, e que uma alteração em um programa produz um resultado de dados diferente, sem consequências no mundo físico. O código adjacente ao SCADA quebra essa premissa de quatro maneiras específicas.
Consequências físicas de erros de dados
Em um sistema de faturamento padrão, um cálculo incorreto gera uma fatura errada. O erro é detectável, reversível e de escopo limitado. Em códigos adjacentes a SCADA, um cálculo incorreto pode gerar um ponto de ajuste incorreto, um valor alvo sobre o qual um sistema de controle atua ajustando parâmetros físicos: pressão, tensão, vazão, temperatura. A consequência não é um número errado em um banco de dados. É um processo físico operando fora dos parâmetros previstos, com consequências que variam de ineficiência a danos em equipamentos e incidentes de segurança.
Essa assimetria entre erro de dados e consequência física é a razão fundamental pela qual o código adjacente ao SCADA não pode ser analisado com a mesma tolerância ao risco que o código comercial padrão. Uma alteração que "funciona corretamente" do ponto de vista de produzir uma saída válida ainda pode produzir uma saída operacionalmente incorreta, dentro do intervalo permitido para o tipo de dados, sintaticamente válida, mas fisicamente inadequada para o contexto operacional que representa.
Dependências temporais que a análise estática não consegue modelar
Os programas do lado da TI adjacentes aos sistemas SCADA frequentemente possuem restrições de tempo que são operacionalmente significativas, mas invisíveis para ferramentas de análise estática. Um programa que gera dados de configuração deve ser concluído antes que o ciclo de polling do sistema SCADA os leia. Um job em lote que agrega dados históricos deve terminar antes do timestamp de fim de intervalo exigido pelos relatórios regulatórios. Um programa de ponte que retransmite alarmes deve processar os eventos dentro do tempo de resposta especificado pelos procedimentos operacionais da sala de controle.
Essas restrições de tempo existem nos procedimentos operacionais da concessionária, na configuração do agendador e no entendimento implícito dos desenvolvedores que escreveram os programas, e não no código-fonte. Ferramentas de análise estática que se concentram na estrutura do código e no fluxo de dados não têm visibilidade dos requisitos de tempo que existem fora do próprio código.
A implicação prática: a análise de modernização para código adjacente ao SCADA deve documentar explicitamente o contexto temporal de cada programa em escopo. Isso requer conhecimento operacional, entrevistas com operadores da sala de controle, revisão de cronogramas de conformidade regulatória, análise das dependências das tarefas do agendador, e não apenas análise de código.
Identificação da função de segurança
As normas IEC 61511 (segurança funcional para setores da indústria de processos) e IEC 61508 (segurança funcional para sistemas elétricos/eletrônicos/eletrônicos programáveis relacionados à segurança) definem os requisitos de certificação para softwares que executam funções de segurança. O código certificado por essas normas não é simplesmente um código legado que pode ser refatorado para facilitar a manutenção. A certificação se refere a artefatos de código específicos, à versão específica do binário específico que o organismo de certificação avaliou. Alterar o código, mesmo para corrigir um problema de qualidade que seria irrelevante em uma aplicação comercial, invalida a certificação e exige uma nova certificação antes que o código alterado possa ser implementado em uma função de segurança.
Muitas concessionárias de serviços públicos possuem programas adjacentes ao SCADA que realizam cálculos relacionados à segurança, detecção de sobrepressão, cálculo de ponto de ajuste de proteção de transformadores e lógica de desligamento de emergência, os quais podem estar sujeitos a requisitos de certificação de segurança sem que a equipe de modernização de TI tenha conhecimento disso. A primeira questão analítica para o código adjacente ao SCADA é: alguma parte desse código executa uma função de segurança? Em caso afirmativo, quais funções, sob qual certificação e o que a alteração exige?
Acoplamento de hardware e protocolo
Os programas de ponte de protocolo e o código de interface embarcada têm dependências diretas do hardware e das versões de protocolo que implementam. Um programa que implementa Modbus RTU com códigos de função, mapeamentos de registradores e valores de tempo limite específicos para um modelo específico de RTU de um fornecedor específico não está implementando Modbus de forma genérica, mas sim implementando essa combinação específica, com pressupostos que podem não ser válidos para qualquer outra configuração.
Ao analisar esse código para modernização, percebe-se que a dependência não se limita ao código-fonte COBOL ou C, mas também ao modelo do dispositivo RTU, à versão do firmware, à topologia da fiação física e à configuração da rede. Alterações em qualquer um desses elementos podem comprometer a interface, mesmo que o código-fonte do programa permaneça inalterado. Além disso, alterações no código-fonte do programa podem comprometer interfaces aparentemente não relacionadas, visto que a ponte foi desenvolvida para compensar peculiaridades de protocolo específicas do fornecedor, que não estão documentadas em lugar nenhum.
A fronteira entre TI e TO: onde reside o código
O Modelo Purdue (ISA-99 / IEC 62443) define a arquitetura conceitual de redes de sistemas de controle industrial em cinco níveis, desde processos físicos no Nível 0 até sistemas de negócios empresariais no Nível 4. O código legado adjacente ao SCADA em ambientes de concessionárias de serviços públicos normalmente reside nos Níveis 3 e 4, as zonas de operações de manufatura e rede empresarial, mas seus fluxos de dados cruzam para o Nível 2 (a camada de supervisão do SCADA) em ambas as direções.
A fronteira entre TI e TO, entre os níveis 3 e 2, é onde o risco de segurança e operacional é maior. Atores estatais se posicionam dentro das redes de TO meses antes da ativação, enquanto grupos de ransomware agora implantam payloads que visam sistemas de controle industrial (ICS) e são projetados para bloquear interfaces homem-máquina (IHMs) e interromper a produção. O ponto de entrada mais frequente não é o software SCADA embarcado, mas sim a camada de fronteira entre TI e TO, onde o código do lado da TI e os sistemas do lado da TO trocam dados por meio de interfaces projetadas para confiabilidade operacional, e não para segurança contra ataques.
Compreender o conjunto exato de programas que cruzam essa fronteira e o que eles fazem ali é um pré-requisito tanto para o planejamento da modernização quanto para a melhoria da postura de segurança. Um programa que lê dados de um histórico SCADA e grava os resultados em um banco de dados de faturamento cruza a fronteira em uma direção. Um programa que calcula pontos de ajuste e os grava em um diretório de configuração lido por um CLP cruza a fronteira na outra. Ambos são adjacentes ao SCADA. Nenhum deles aparece em uma varredura de rede SCADA ou em um inventário de aplicativos de TI, razão pela qual são sistematicamente subanalisados.
Padrões de código específicos para programas adjacentes ao SCADA
Código de Cálculo de Unidades de Engenharia
Os cálculos de Unidades de Engenharia (UE) convertem valores brutos de sensores, tipicamente contagens inteiras de conversores analógico-digitais, em medições físicas com unidades, faixas e precisão específicas. Um circuito de corrente de 4-20 mA de um transmissor de pressão produz uma contagem bruta; o cálculo de UE a converte para PSI ou bar com a calibração correta de zero e span.
Este código de cálculo possui características que o diferenciam da lógica de negócios padrão:
cobol
CALCULATE-PRESSURE-EU.
* RAW-COUNT ranges 0-4095 (12-bit ADC)
* SENSOR-ZERO-OFFSET = 819 (4mA = 20% of 4095)
* SENSOR-SPAN = 3276 (16mA span = 80% of 4095)
* RANGE-LOW-PSI = 0
* RANGE-HIGH-PSI = 500
COMPUTE EU-PRESSURE-PSI =
(RAW-COUNT - SENSOR-ZERO-OFFSET) /
SENSOR-SPAN *
(RANGE-HIGH-PSI - RANGE-LOW-PSI)
+ RANGE-LOW-PSI
IF EU-PRESSURE-PSI < RANGE-LOW-PSI OR
EU-PRESSURE-PSI > RANGE-HIGH-PSI
MOVE 'RANGE-VIOLATION' TO ALARM-STATUS
PERFORM GENERATE-ALARM
END-IF.As constantes neste cálculo, SENSOR-ZERO-OFFSET, SENSOR-SPAN, RANGE-LOW-PSI, RANGE-HIGH-PSI, correspondem às especificações físicas do instrumento. Se estiverem codificadas diretamente no código (como frequentemente ocorre em códigos legados), uma alteração no instrumento físico exige uma alteração no código. Se estiverem incorretas (devido à recalibração, substituição ou configuração incorreta original do instrumento), o valor da Unidade de Engenharia (UE) estará sistematicamente incorreto para todos os registros já produzidos pelo programa. A análise estática pode identificar onde essas constantes estão definidas; somente a validação operacional pode confirmar se estão corretas para a configuração atual do instrumento.
Lógica de geração e classificação de alarmes
O código de geração de alarmes está entre os códigos adjacentes ao SCADA mais sensíveis às regulamentações em ambientes de serviços públicos. Os padrões NERC CIP (Proteção de Infraestrutura Crítica) para concessionárias de energia elétrica, os requisitos da NRC para instalações nucleares e os requisitos de relatórios da EPA para concessionárias de água e esgoto especificam quais eventos devem gerar alarmes, quais informações esses alarmes devem conter e dentro de quais prazos eles devem ser relatados.
cobol
CLASSIFY-ALARM.
EVALUATE TRUE
WHEN EU-PRESSURE-PSI > HIGH-HIGH-LIMIT
MOVE 'HH' TO ALARM-PRIORITY
MOVE 'NERC' TO REPORTING-FLAG
PERFORM GENERATE-NERC-EVENT
WHEN EU-PRESSURE-PSI > HIGH-LIMIT
MOVE 'HI' TO ALARM-PRIORITY
MOVE 'LOG' TO REPORTING-FLAG
WHEN EU-PRESSURE-PSI < LOW-LIMIT
MOVE 'LO' TO ALARM-PRIORITY
MOVE 'LOG' TO REPORTING-FLAG
WHEN EU-PRESSURE-PSI < LOW-LOW-LIMIT
MOVE 'LL' TO ALARM-PRIORITY
MOVE 'NERC' TO REPORTING-FLAG
PERFORM GENERATE-NERC-EVENT
END-EVALUATE.Os limites de alarme neste código, HIGH-HIGH-LIMIT, HIGH-LIMIT, LOW-LIMIT, LOW-LOW-LIMITOs limites de alarme são parâmetros operacionais com relevância regulatória. Alterações nesses limites afetam tanto o comportamento operacional do sistema de controle quanto as obrigações de reporte regulatório da concessionária. Qualquer programa de modernização que altere o código de classificação de alarmes deve passar por uma revisão de assuntos regulatórios em seu processo de controle de mudanças, e não apenas pela aprovação da engenharia.
Implementações de ponte de protocolo
Os programas de ponte de protocolo legados estão entre os códigos adjacentes ao SCADA mais difíceis de modernizar, pois suas dependências são as mais difíceis de enumerar. O programa implementa uma versão específica do protocolo para um dispositivo específico, com comportamentos específicos do fornecedor não documentados compensados no código.
c
/* Legacy Modbus RTU bridge -- written for Modicon 984 PLCs, circa 1998 */
/* NOTE: 984 series uses 1-based register addressing, not 0-based */
/* Function code 03 only -- 984 does not support FC 04 */
/* Max 60 registers per request -- 984 firmware limitation */
#define MODBUS_FC03_READ_HOLDING 0x03
#define MAX_REGS_PER_REQUEST 60 /* 984 firmware limit, not Modbus spec */
#define REGISTER_OFFSET 1 /* 984 uses 1-based addressing */
int read_holding_registers(int start_reg, int count, uint16_t *buffer) {
/* Compensate for 984 1-based addressing */
uint16_t adjusted_start = (uint16_t)(start_reg + REGISTER_OFFSET);
if (count > MAX_REGS_PER_REQUEST) {
/* 984 will return error if count exceeds 60 */
/* Split into multiple requests silently */
return read_registers_chunked(adjusted_start, count, buffer);
}
/* ... */
}Este código possui quatro pressupostos implícitos sobre um modelo específico de CLP que não fazem parte da especificação Modbus: endereçamento de registradores baseado em 1, código de função 03 apenas, máximo de 60 registradores e o comportamento de fragmentação para requisições maiores. Nenhum desses aspectos consta na documentação Modbus. São comportamentos específicos do fornecedor do Modicon 984, documentados em um manual de hardware de 1998 que pode não estar mais disponível. Se esta ponte for modernizada sem o devido conhecimento desses pressupostos, ou se o CLP for substituído por um modelo mais recente que utilize endereçamento padrão baseado em 0, cada leitura de registrador retornará o valor incorreto por exatamente um deslocamento de endereço de registrador.
Análise da Pré-Modernização: O Que Deve Ser Produzido
Antes que qualquer código relacionado ao SCADA seja modificado, refatorado ou substituído, a análise deve produzir um conjunto de entregáveis que vão além do que uma análise padrão de modernização empresarial oferece.
Inventário de funções operacionais. Cada programa adjacente ao SCADA deve ser classificado por sua função operacional: cálculo de EU (Unidade de Configuração), entrega de pontos de ajuste, consumo de dados históricos, geração de alarmes, ponte de protocolo, caminho de processamento em lote para tempo real. Essa classificação determina quem deve estar envolvido no processo de mudança: apenas engenheiros de TI ou uma equipe multifuncional que inclua engenheiros de controle, equipe de operações e conformidade regulatória.
Mapa de cruzamento de fronteiras TI/OT. Todo fluxo de dados que cruza a fronteira TI/OT deve ser documentado: qual programa produz os dados, em que formato e em qual cronograma; qual sistema OT os consome; e qual a consequência caso os dados estejam incorretos, atrasados ou ausentes. Este mapa representa o perfil de risco operacional para a camada adjacente ao SCADA.
Identificação da função de segurança. Cada programa deve ser avaliado para determinar se executa uma função de segurança de acordo com as normas IEC 61511, IEC 61508, NERC CIP ou outras normas aplicáveis. Programas identificados como código de função de segurança exigem controle de alterações separado, notificação regulatória e, potencialmente, recertificação. O cronograma de modernização para esses programas é fundamentalmente diferente do código de negócios padrão.
Registro de parâmetros operacionais fixos. Cada constante fixa que representa um parâmetro operacional, valores de calibração de sensores, limites de alarme, restrições de protocolo, limites de temporização, deve ser identificada, documentada com seu significado operacional e validada em relação às especificações atuais do instrumento. Esse registro se torna a entrada para o processo de gerenciamento de configuração que substitui as constantes fixas por configurações gerenciadas externamente.
Documentação de dependências de tempo. O contexto de tempo de cada programa, as janelas operacionais dentro das quais ele deve ser concluído, as dependências do escalonador que impõem essas janelas e os procedimentos operacionais que dependem de sua conclusão devem ser documentados explicitamente. Essa documentação é a especificação com base na qual a implementação modernizada deve ser validada.
Especificação de protocolo e interface. Cada programa de ponte de protocolo deve ser analisado quanto a comportamentos específicos do fornecedor, suposições de versão do protocolo e compensações específicas do dispositivo. O resultado é um documento de especificação que pode ser usado para validar uma implementação de substituição, confirmando que todos os comportamentos compensatórios são preservados, mesmo aqueles que não estavam na especificação original.
As abordagens de modernização que funcionam e as que não funcionam.
O padrão Strangler Fig, aplicado com cuidado, consiste em construir novas funcionalidades em paralelo com as antigas, roteando incrementalmente e desativando-as gradualmente. É apropriado para código adjacente a sistemas SCADA que realiza processamento de dados no lado de TI (consumidores de dados históricos, cálculos de faturamento). O programa antigo continua em execução durante a transição; a nova implementação produz saídas paralelas que são validadas quanto à equivalência antes que o programa antigo seja desativado.
A Figura do Estrangulador não se aplica a fluxos de dados em tempo real. Para programas que residem em um fluxo de dados em tempo real, onde não há uma maneira segura de executar o programa antigo e o novo em paralelo, pois isso produziria efeitos operacionais conflitantes, a transição deve ser instantânea e validada offline antes de qualquer transferência para a produção. Executar um programa paralelo de cálculo de ponto de ajuste que produza valores diferentes do programa atual enviaria pontos de ajuste conflitantes para o sistema de controle.
Externalização da configuração antes das alterações de código. Para programas com parâmetros operacionais fixos no código, a primeira etapa de modernização mais segura é externalizar esses parâmetros para um arquivo de configuração ou banco de dados, sem alterar a lógica de cálculo. Isso torna os parâmetros visíveis, gerenciáveis e auditáveis, sem afetar o código de cálculo que tem importância operacional. O risco de externalizar parâmetros é substancialmente menor do que o de refatorar a lógica de cálculo.
Código com função de segurança: análise e documentação, não refatoração. O código com certificação de segurança deve ser analisado e documentado durante a fase de planejamento da modernização, mas as alterações nele devem ser adiadas para um programa de recertificação específico, com coordenação regulatória, e não abordadas como parte de uma iniciativa geral de modernização. O risco de invalidar uma certificação de segurança durante uma ampla modernização não se justifica por nenhum benefício típico da modernização.
Como SMART TS XL Suporta análise de código legado adjacente ao SCADA.
SMART TS XL'S análise de código estático Aplica-se ao lado de TI da fronteira adjacente ao SCADA, aos programas COBOL, JCL, RPG, PL/I e C que são executados em mainframes e sistemas de médio porte e geram, transformam ou consomem dados que cruzam para ambientes de OT (Tecnologia Operacional). Para esse código, a análise estrutural produz o inventário de funções operacionais e o registro de parâmetros fixos que a análise pré-modernização exige.
O mapeamento de dependências de aplicações constrói o mapa de cruzamento de fronteiras entre TI e TO: cada programa que escreve em uma interface de arquivo consumida por um sistema SCADA, cada etapa de job JCL que produz dados com relevância para o tempo operacional, cada programa no fluxo de dados do histórico, da fonte TO ao consumidor de TI. Quando um programa COBOL de faturamento de uma concessionária lê dados do histórico por meio de uma ponte C intermediária, o mapa de dependências representa tanto a dependência COBOL-para-C quanto a dependência C-para-histórico como uma cadeia conectada, tornando o cruzamento completo entre TI e TO visível, em vez de detectável apenas por meio de incidentes operacionais.
A capacidade de análise de impacto é particularmente crítica para códigos adjacentes ao SCADA, pois enumera o raio de explosão de qualquer alteração proposta antes que a alteração seja implementada. Uma modificação em um programa de cálculo de UE que é compartilhado (via copybook) com o código de geração de alarmes, o código de entrega de pontos de ajuste e o código de gravação do histórico requer a compreensão de todos os três impactos secundários antes de qualquer alteração no cálculo. Em códigos comerciais padrão, uma alteração incorreta produz dados errados. Em códigos adjacentes ao SCADA, produz parâmetros operacionais errados.
A capacidade de expansão do JCL revela a estrutura de temporização e sequenciamento da camada de lotes: quais tarefas são executadas em que ordem, quais saídas de conjuntos de dados alimentam quais etapas subsequentes e quais fluxos de tarefas são limitados no tempo por requisitos operacionais. Essa é a base de evidências estruturais para a documentação de dependência temporal que a modernização adjacente ao SCADA exige.
A funcionalidade de busca corporativa torna o registro de parâmetros fixos viável em grande escala: encontre todas as ocorrências de uma constante de unidade de engenharia específica, todos os valores limite de alarme, todos os endereços de protocolo fixos em todos os artefatos COBOL, C, RPG e JCL do ambiente, em segundos, em milhões de linhas de código. Para concessionárias de serviços públicos que gerenciam centenas de milhares de linhas de código legado adjacente ao SCADA, essa funcionalidade de busca representa a diferença entre uma auditoria manual que leva meses e um inventário automatizado que leva horas.
Para equipes de planejamento modernização legada de sistemas de utilidade pública, SMART TS XL Fornece a análise estrutural do lado da TI que permite à equipe de modernização trabalhar eficazmente em conjunto com os engenheiros de controle do lado da TO, que compreendem o contexto operacional. A fronteira entre TI e TO não é atravessada com segurança apenas pelas equipes de TI ou apenas pelas equipes de TO; ela é atravessada com segurança quando ambos os lados possuem um conhecimento estrutural preciso do que seus sistemas contêm.
Por que esse código exige um tipo diferente de atenção?
As empresas de serviços públicos que modernizam seus códigos legados adjacentes ao SCADA não estão simplesmente atualizando softwares antigos. Elas estão alterando a camada de software que serve de intermediação entre os sistemas de negócios e a infraestrutura física. As consequências de uma implementação incorreta não se limitam a erros de dados, interrupções de serviço ou perdas financeiras; elas se estendem aos sistemas físicos que atendem às pessoas que dependem dos serviços públicos para funcionar.
As características que tornam este código especial — as consequências físicas de erros de dados, as dependências temporais invisíveis à análise estática, as restrições de certificação de segurança, o acoplamento de hardware e protocolo — não são argumentos contra a sua modernização. São argumentos a favor de compreendê-lo completamente antes de qualquer alteração. A estrutura de análise deste guia proporciona essa compreensão. O programa de modernização resultante é mais seguro porque o escopo da mudança é definido por evidências, e não por suposições; as dependências temporais são documentadas, e não implícitas; o código da função de segurança é identificado, e não modificado acidentalmente; e as intersecções entre TI e TO são mapeadas, e não descobertas por meio de incidentes operacionais após a implementação.
