Capítulo 2 — Sistemas computacionais
Mapa da aula
Aula 02 publicada. Mapa, exemplo, EX004.
flowchart TD
N0["2.1 O ciclo de varredura"]
N1["2.2 CLP versus servidor"]
N2["2.3 O que vive no firmware"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3
N3 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX004"]
Desenho lógico
flowchart LR
N0["2.1 O ciclo de varredura"]
N1["2.2 CLP versus servidor"]
N2["2.3 O que vive no firmware"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3 --> Q["EX004"]
[2.1 O ciclo de varredura]
|
v
[2.2 CLP versus servidor]
|
v
[2.3 O que vive no firmware]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX004]
Objetivos de aprendizagem
Você vai (1) descrever as camadas de um controlador lógico programável, da placa de E/S ao ciclo de varredura; (2) contrastar um CLP com um servidor de uso geral; (3) explicar por que a temporização determinística é uma propriedade de segurança em TO; e (4) listar o que uma imagem de firmware contém.
2.1 O ciclo de varredura
Um CLP lê entradas, executa a lógica, escreve saídas e atende às comunicações, repetidamente. Na LDHP, o PLC-H da caldeira completa esse laço a cada 20 ms. Se o tratamento das comunicações cresce — por exemplo, porque um historiador mal configurado consulta 400 registradores a cada 50 ms —, o tempo de varredura se alonga e o watchdog pode levar o controlador a uma parada segura. Em TO, uma negação de serviço pode, portanto, chegar como tráfego comum que é simplesmente demais. Maya encontrou isso na segunda semana: um projeto de painel pedia "todas as tags, a cada varredura". Convertido em tempo de varredura, esse pedido teria carregado o tratamento de comunicações do PLC-H em todo ciclo de 20 ms, então ela recomendou ler o historiador.
2.2 CLP versus servidor
Um servidor é projetado para rodar muitos programas, aceitar atualizações e se recuperar com uma reinicialização. Um CLP é projetado para rodar um único programa durante anos, muitas vezes sem contas de usuário, com registro limitado e com firmware que o fabricante assina (ou, em modelos mais antigos, não assina). Reiniciar um servidor é rotina; reiniciar um controlador numa casa de caldeiras em operação exige permissão de trabalho, presença do operador e um plano para manter o processo seguro. Para o PLC-H, isso significa que uma correção de firmware não pode simplesmente ser aplicada numa terça-feira à tarde: ela precisa da janela mensal de quatro horas, de uma permissão de trabalho e da presença do líder de turno.
2.3 O que vive no firmware
O firmware reúne um sistema operacional de tempo real, pilhas de protocolos, o runtime que executa ladder ou texto estruturado e um bootloader. Daí decorrem consequências de segurança: um defeito na pilha de protocolos pode afetar todos os programas do dispositivo, e um caminho de atualização não assinado permite que qualquer pessoa que alcance a porta de engenharia substitua o runtime. O NIST SP 800-82r3 trata a integridade do firmware e o download controlado de programas como práticas centrais de TO. Para o PLC-H, a pergunta prática é quem consegue alcançar a porta de engenharia: se a EWS-1 é o único host que consegue, proteger a EWS-1 protege o runtime; se a VLAN do escritório também alcança a porta 502, o comportamento de assinatura do firmware passa a ser a última barreira.
Exemplo resolvido (LDHP sintética)
O PLC-H tem uma varredura-alvo de 20 ms e um watchdog de 100 ms. A lógica leva 9 ms, a E/S 4 ms, e cada requisição Modbus custa 0,6 ms para ser atendida. Com 10 requisições por varredura, o ciclo é 9 + 4 + 6 = 19 ms. Se um novo painel acrescenta 30 requisições por varredura, o ciclo passa a 37 ms: ainda abaixo do watchdog, mas a temporização de 20 ms que as malhas sintonizadas esperam se perde, e a qualidade do controle se degrada antes que qualquer alarme dispare.
Caso sintético — Lakeside District Heating Plant. Maya encontra um projeto de painel que pede "todas as tags, a cada varredura". Ela converte o pedido em milissegundos de varredura e recomenda consultar o historiador, e não o controlador.
Erros e limites
Os modelos de varredura dos fabricantes diferem; alguns atendem às comunicações numa tarefa separada. Nunca meça o impacto na varredura carregando um controlador em produção — use uma unidade de bancada ou os números do fabricante.
Exercícios
- EX004 — Carga de comunicações e tempo de varredura. Com 9 ms de lógica, 4 ms de E/S e 0,6 ms por requisição, quantas requisições por varredura mantêm o PLC-H em 20 ms ou menos? Rubrica: 3 = 11 requisições, com o cálculo; 2 = número certo, sem cálculo; 1 = ignora a E/S; 0 = nada.
- EX005 — Hábitos de servidor que prejudicam controladores. Cite dois hábitos de administração de servidores que são inseguros num CLP em operação e dê a alternativa de TO para cada um. Rubrica: 3 = dois hábitos com alternativas; 2 = um par; 1 = hábitos sem alternativas; 0 = nada.
- EX006 — Camadas do firmware e raio de impacto. Explique por que uma vulnerabilidade na pilha de protocolos de um controlador tem impacto mais amplo que um defeito num degrau do ladder. Rubrica: 3 = a pilha compartilhada atende a todos os programas e é alcançável antes de a lógica rodar; 2 = parcial; 1 = vago; 0 = nada.
Síntese
Um controlador é primeiro uma máquina temporizada e só depois um computador; a sua segurança começa por respeitar o ciclo de varredura e controlar o que pode ser carregado nele.
Continue estudando — capítulo 02 de 40
← Capítulo 01 · Índice de capítulos do curso · Capítulo 03 →
Siga para a próxima lição escrita.