Capítulo 41 — Segurança de TO, IoT e sistemas ciberfísicos: otimização do sistema
Mapa da aula
Aula 41 publicada. Mapa, exemplo, EX121.
flowchart TD
N0["41.1 Primeiro o perfilamento"]
N1["41.2 Preservando as restrições"]
N2["41.3 Veto da segurança física"]
N3["Nota prática"]
N4["41.1b Descarte de carga e N+1"]
N5["Nota de campo — parágrafo de segurança física"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX121"]
Desenho lógico
flowchart LR
N0["41.1 Primeiro o perfilamento"]
N1["41.2 Preservando as restrições"]
N2["41.3 Veto da segurança física"]
N3["Nota prática"]
N4["41.1b Descarte de carga e N+1"]
N5["Nota de campo — parágrafo de segurança física"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX121"]
[41.1 Primeiro o perfilamento]
|
v
[41.2 Preservando as restrições]
|
v
[41.3 Veto da segurança física]
|
v
[Nota prática]
|
v
[41.1b Descarte de carga e N+1]
|
v
[Nota de campo — parágrafo de segurança física]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX121]
Objetivos de aprendizagem
Você vai (1) fazer o perfilamento de pipelines de segurança de TO de forma ética; (2) otimizar sob as restrições de tempo de ciclo e das regras de engajamento; (3) rejeitar otimizações que enfraqueçam a segurança física.
41.1 Primeiro o perfilamento
Meça para onde vai o tempo: decodificação, avaliação de permit, escrita do evento. Otimize o termo dominante. Apenas carga sintética.
Na ABP, Lena fez o perfilamento do monitor na bancada antes que qualquer otimização fosse aprovada. Reproduzindo um dia gravado de tráfego do tronco, ela mediu quanto tempo a decodificação, a avaliação de permit e a escrita dos eventos levavam cada uma, e descobriu que a escrita dos eventos dominava. Agrupar as escritas reduziu a latência total sem mudar uma única regra de permit. Ela usa apenas carga sintética ou reproduzida, porque perfilar contra equipamentos em operação acrescentaria exatamente o risco que o monitor existe para reduzir, e a cópia de bancada do PLC-A se comporta de forma próxima o bastante para o trabalho de temporização.
41.2 Preservando as restrições
Pôr a AllowListVersion em cache é aceitável se a invalidação na publicação estiver correta. Pôr em cache as decisões de permissão entre estações não é — as estações diferem.
No CNHP, a lista de permissões fica em cache na memória com o seu número de versão, e toda publicação limpa o cache antes de a nova versão ser usada, então regras velhas não podem permanecer. Pôr em cache as decisões individuais foi rejeitado, porque a HMI-1 e a estação de engenharia têm permissão para registradores diferentes, e uma decisão guardada para uma estaria errada para a outra. Os testes de Lena incluem uma publicação sob carga pesada, para confirmar que a primeira decisão depois da publicação sempre usa a nova versão.
41.3 Veto da segurança física
Qualquer otimização do monitor que pule as verificações da lista de permissões, encurte campos de auditoria ou falhe aberta é rejeitada, qualquer que seja o tempo de ciclo economizado.
"""Lab: does a polling schedule fit the PLC scan/communication budget? (synthetic)"""
link_bps = 115200; bits_per_byte = 10 # RS-485 serial, 8N1 + start bit
polls = [("T-1 level", 8), ("T-2 level", 8), ("R-101 block", 40), ("pump status", 8), ("historian sweep", 120)]
overhead = 12 # bytes of request+framing per poll (assumed)
total = sum(n + overhead for _, n in polls)
t = total * bits_per_byte / link_bps
print(f"bytes per cycle={total} time per cycle={t*1000:.1f} ms")
for target in (100, 50):
print(f"cycle budget {target} ms -> {'fits' if t*1000 <= target else 'OVERRUN'}")
Saída esperada:
bytes per cycle=244 time per cycle=21.2 ms
cycle budget 100 ms -> fits
cycle budget 50 ms -> fits
Caso sintético — Ashford Batch Plant. Pôr em cache na memória as listas de permissões assinadas reduziu a latência; a invalidação na publicação preservou a segurança física. Uma proposta de pular as verificações de registradores para IHMs "sabidamente boas" foi vetada.
Lena registra cada proposta vetada na ABP com o ganho de velocidade esperado e o motivo da rejeição. O registro de decisões significa que a mesma ideia não é reaberta a cada trimestre sem novos argumentos de segurança.
41.4 Erros e limites
Benchmarks em laptops não predizem troncos de planta.
Na ABP, um decodificador que rodava com folga no laptop de um desenvolvedor ficou para trás quando Lena o testou na cópia de bancada do tronco RS-485, com temporização e tamanhos de quadro reais. Os laptops têm processadores mais rápidos e nenhum dos limites de temporização serial que importam na planta. Lena agora só aceita números de desempenho vindos da bancada, e cada relatório de benchmark declara o ciclo de polling de 21 ms do tronco e a parada em 50 ms ao lado do resultado medido, para que os leitores possam julgar a margem.
Nota prática
As propostas de otimização exigem um parágrafo de segurança física. As propostas sem ele são devolvidas sem leitura.
41.1b Descarte de carga e N+1
Sob sobrecarga, descarte o trabalho de descoberta antes de descartar a avaliação de negação. Atualizações tagarelas de tickets durante uma importação em massa esmagam o repositório de constatações — agrupe as escritas e meça. Mantenha folga dentro do orçamento de tempo de ciclo, para que uma tempestade de novas tentativas não o ultrapasse.
A ordem de descarte de carga é escrita no runbook, para que o líder da janela saiba qual trabalho pausa primeiro.
As revisões de Lena aplicam cada regra. Na ABP, Lena testou a sobrecarga reproduzindo o tráfego em velocidade tripla: a descoberta pausou primeiro, enquanto as decisões de negação continuaram em taxa plena e ficaram bem abaixo do orçamento de ciclo.
Nota de campo — parágrafo de segurança física
Um PR de otimização que removia os códigos de motivo dos logs do caminho crítico para economizar microssegundos foi devolvido sem leitura por falta de um parágrafo de segurança física. O PR revisado manteve os códigos e encontrou o seu ganho em outro lugar. Os parágrafos de segurança física não são burocracia; são o mecanismo de veto.
A reprodução de sobrecarga é repetida a cada versão que toca o decodificador.
41.5 Exemplo resolvido — otimização com veto da segurança física (ABP sintética)
A produção pede para encurtar o lote do R-101 aumentando a vazão de alimentação, e pede ao CNHP que relaxe o limite de taxa da função permit para escritas de setpoint de uma a cada 10 s para uma por segundo, para acomodar a receita mais rápida. Lena faz o perfilamento primeiro: só a fase de carga precisa de escritas mais rápidas. Ela propõe um limite específico por fase, aplicado apenas enquanto o estado do lote for "carga", e o submete ao engenheiro de segurança de processo, que confirma que os desarmes por temperatura alta e por nível alto do SIS-B não são afetados. O engenheiro de segurança tem poder de veto sobre qualquer otimização que toque uma malha relevante para a segurança física; esta passou, com um teste de carga na bancada.
Exercícios
- EX121 — Veto. Uma otimização que precisa ser rejeitada. Rubrica: 3 = exemplo que enfraquece a segurança física; 2 = vago; 1 = aprova; 0 = nada.
- EX122 — Cache. Quando o cache de decisões é seguro? Rubrica: 3 = mesma versão+estação+fc+registrador, TTL curto, invalidação na publicação; 2 = parcial; 1 = sempre; 0 = nada.
- EX123 — Descarte. O que você descarta primeiro sob sobrecarga? Rubrica: 3 = descoberta/avaliação antes da avaliação de negação; 2 = parcial; 1 = descartar negações; 0 = nada.
Síntese
Velocidade sob restrições; a segurança física tem poder de veto.
Continue estudando — capítulo 41 de 50
← Capítulo 40 · Índice de capítulos do curso · Capítulo 42 →
Siga para a próxima lição escrita.