⚡ electrical engineering

VICP: A Majority-Lease Runtime for Highly Available Industrial Edge Clusters

Este artigo apresenta o VICP, um tempo de execução para clusters de borda industriais que garante a alta disponibilidade e a segurança da falha de serviço ao desacoplar a replicação de estado reversível da autoridade de saída física irreversível por meio de concessões de maioria e cercamento (fencing), alcançando uma redução de 50,54% na interrupção de saída em comparação com o ativo-reserva, mantendo simultaneamente a precisão do controle.

Autores originais: Ruifeng Ding, Jie Zhou, Benjun Dou, Xingwu Zhu, Shengyang Gao

Publicado 2026-08-10

📖 4 min de leitura☕ Leitura rápida

CC BY 4.0

Autores originais: Ruifeng Ding, Jie Zhou, Benjun Dou, Xingwu Zhu, Shengyang Gao

Artigo original sob licença CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine um mundo onde as máquinas que mantêm nossas luzes acesas, nossa água limpa e nossas fábricas funcionando não são mais apenas caixas burras e cabeadas, mas programas de software inteligentes e flexíveis vivendo em clusters de computadores. Esta é a fronteira da computação de borda industrial (industrial edge computing). Mas há um problema complexo: nos velhos tempos, se um controlador quebrasse, um reserva assumiria o controle. No novo mundo do software, se um computador travar e reiniciar, ele pode tentar falar com as máquinas do mundo real ao mesmo tempo que aquele que acabou de acordar. Se dois computadores disserem simultaneamente a uma válvula gigante para "abrir", o caos se instala. Este artigo aborda uma questão muito específica e de alto risco: Como permitimos que o software rode em muitos computadores para velocidade e segurança, sem nunca deixar que dois deles pressionem acidentalmente o mesmo botão físico ao mesmo tempo? É como tentar ter uma equipe de chefs cozinhando a mesma refeição, mas garantindo que apenas uma pessoa tenha permissão para realmente ligar o fogão em qualquer momento dado.

Os pesquisadores por trás deste estudo, da Rundian Energy Science and Technology Co., Ltd., construíram um sistema chamado VICP (Virtualized Industrial Control Platform) para resolver este enigma. Eles perceberam que, embora possamos copiar e sincronizar facilmente dados digitais (como uma receita ou uma leitura de temperatura), não podemos "desapertar" um botão físico depois que ele foi pressionado. Por isso, dividiram o problema em dois. Primeiro, eles permitem que cada computador no cluster mantenha uma cópia local e atualizada dos dados para que possam pensar rápido. Segundo, criaram um sistema rigoroso de "autorização". Para realmente enviar um comando para o mundo físico (como abrir uma válvula), um computador deve deter um contrato de arrendamento com apoio da maioria (majority-backed lease). Pense nisso como um "bilhete dourado" que só é válido se a maioria dos outros computadores do grupo concordar que ele ainda é válido e não expirou. Se a rede se dividir ao meio, ou se um computador falhar e tentar voltar, ele não pode simplesmente começar a dar ordens; ele tem que esperar até que possa provar à maioria que é seguro fazê-lo.

Em seus experimentos, a equipe testou essa ideia em um pequeno cluster de três computadores rodando um protótipo baseado em Go. Eles criaram falhas na rede e desligaram computadores para ver o que acontecia. Os resultados foram promissores: quando um computador falhou, o VICP conseguiu transferir o controle para um reserva em uma média de 1.039,061 milissegundos (cerca de 1 segundo). Isso foi uma melhoria massiva — cerca de 50,54% mais rápido — do que uma configuração tradicional de "ativo-reserva" (active-standby), que levava 2.100,614 milissegundos para se recuperar. Mais importante ainda, em 30 testes diferentes onde simularam divisões de rede, eles detectaram zero instâncias de dois computadores tentando enviar comandos ao mesmo tempo. Eles também testaram o sistema com hardware físico real, enviando sinais elétricos de 4–20 mA (a linguagem padrão de sensores industriais) através de um "gateway de cercamento" (fencing gateway) que atuou como um guarda de segurança final. O sistema manteve os sinais incrivelmente precisos, com um erro máximo de apenas 0,02078 mA.

No entanto, os autores são cautelosos ao não chamar este sistema de uma solução mágica para todas as situações de segurança crítica. Eles afirmam explicitamente que seu sistema não é um substituto para equipamentos de segurança certificados ou lógica de desligamento de emergência independente. É uma forma de tornar a camada de controle mais flexível e disponível, mas a rede de segurança final ainda precisa estar presente. Eles também observam que seus resultados baseiam-se em simulações e configurações de hardware específicas (usando máquinas virtuais e placas de E/S específicas), portanto, embora a matemática e a lógica se sustentem em seu laboratório, a implantação no mundo real exigiria testes ainda mais rigorosos. O artigo sugere que, ao separar o "pensar" (que pode ser copiado em todo lugar) do "fazer" (que exige um voto de maioria estrito), podemos construir sistemas industriais que sejam ao mesmo tempo super flexíveis e incrivelmente seguros, desde que respeitemos as regras do contrato e do cercamento. É um passo em direção a um futuro onde nossa infraestrutura industrial seja tão resiliente quanto um bando de pássaros, onde, se um pássaro for separado, os outros continuem voando em perfeita sincronia sem nunca colidirem uns com os outros.

Resumo Técnico: VICP – Um Tempo de Execução de Maioria de Leases para Clusters de Borda Industrial de Alta Disponibilidade

1. Declaração do Problema

A automação industrial está migrando cada vez mais para arquiteturas nativas da nuvem utilizando servidores de prateleira e contêineres para hospedar funções de controle avançadas (ex: controle preditivo baseado em modelo). No entanto, os mecanismos padrão de recuperação de falhas de sistemas nativos da nuvem — como o reagendamento de processos ou o redirecionamento de tráfego — abordam a disponibilidade do serviço, mas falham em abordar a segurança da saída física.

Nos Sistemas de Controle Distribuído (DCS) tradicionais, a comunicação de campo, o estado de execução e a autoridade de saída estão vinculados a um hardware dedicado. Em contraste, um ambiente virtualizado permite que múltiplas réplicas de um controlador existam simultaneamente. Se ocorrer uma partição de rede ou se as réplicas divergirem, os modelos de consistência eventual padrão podem permitir que múltiplos nós emitam comandos físicos irreversíveis (ex: movimentos de atuadores) concorrentemente. Isso cria um risco crítico de segurança: enquanto valores pontuais (dados de sensores) podem ser reconciliados posteriormente, ações físicas não podem ser "retiradas" uma vez executadas. O artigo identifica a questão central de sistemas: Como um pequeno cluster de borda industrial pode reter a capacidade de controle local durante falhas de nós enquanto impede estritamente a saída física concorrente de réplicas isoladas?

2. Metodologia e Design do Sistema

Os autores propõem o VICP (Virtual Industrial Control Platform), uma arquitetura de tempo de execução que desacopla a replicação de estado de pontos reversíveis da autoridade de saída física irreversível.

2.1 Arquitetura Central

Estado Local-First: Tarefas de controle rodam em réplicas locais usando tabelas de pontos em memória. Loops de controle de alta frequência acessam o estado local sem viagens de ida e volta pela rede (round trips). Réplicas pares são mantidas "quentes" via propagação assíncrona.
Convergência Determinística: Atualizações de pontos são representadas como tuplas contendo carimbos de tempo (timestamps), prioridades, IDs de origem e números de sequência. As réplicas resolvem conflitos de forma determinística usando comparação lexicográfica, garantindo que todos os nós convirjam para os mesmos valores de estado sem exigir consenso para cada leitura.
Autoridade de Saída por Maioria de Lease: A saída física é controlada por um lease (concessão) com tempo limitado.
- Um nó deve deter um lease não expirado, respaldado por um quórum de maioria ( $Q = f+1$ ), para emitir comandos físicos.
- O lease inclui um epoch, identidade do detentor e prazo de expiração.
- Se um nó perder conectividade com a maioria, seu lease expira e ele é proibido de emitir saída.
- Um modo de "sobrevivente único" é possível, mas requer autorização externa explícita (ex: um árbitro de hardware ou procedimento de operador), não apenas observação de rede.

2.2 Recuperação e Isolamento

Recuperação em Estágios: Um nó reiniciado não se reintegra imediatamente ao loop de controle. Ele progride através de uma máquina de estados: Iniciando → Descoberta → Recuperação de Estado → Validação → Pré-Serviço → Servindo. Isso garante que atualizações locais obsoletas não sobreponham valores mais recentes dos pares.
Isolamento de Recursos: Tarefas críticas (comunicação de campo, loops de controle, guardiões de lease) são fixadas (pinned) a núcleos de CPU específicos e isoladas de tarefas de gerenciamento (logging, histórico, configuração). Tarefas não críticas são degradadas ou pausadas sob pressão de recursos.
Gateway de Fencing: Um gateway de I/O persistente valida tokens de fencing (epoch do lease e detentor) antes de encaminhar comandos para dispositivos físicos. Ele rejeita comandos com epochs obsoletos, mesmo que o processo de tempo de execução retome após uma pausa.

3. Principais Contribuições

O artigo apresenta quatro contribuições primárias:

Modelo de Correção Dividido: Define um modelo que separa a convergência determinística para o estado de ponto reversível da necessidade de maioria de lease para a saída física irreversível.
Arquitetura de Tempo de Execução Local-First: Apresenta uma arquitetura com propriedade explícita de pontos, resolução de conflitos determinística, epochs de lease, fencing de saída e uma máquina de estados de recuperação em estágios.
Gerenciamento Integrado de Disponibilidade e Recursos: Demonstra como as fronteiras de grupos de computação e o isolamento de CPU/armazenamento protegem os caminhos de controle críticos da carga do plano de gerenciamento.
Protótipo Reproduzível e Avaliação: Fornece um protótipo baseado em Go e uma avaliação abrangente cobrindo failover, comportamento de partição, escala de sincronização, interferência de recursos e validação bidirecional de hardware-in-the-loop.

4. Resultados Experimentais

Os autores avaliaram um protótipo de três nós em Go rodando em openEuler com contêineres Docker.

4.1 Desempenho de Failover

Tempo de Interrupção: O VICP alcançou uma interrupção média de saída de 1039,061 ms (IC 95%: 1024,492–1053,631 ms).
Comparação: Isso representa uma redução de 50,54% em relação a uma linha de base ativa-standby configurada (2100,614 ms).
Segurança: Nenhuma sobreposição de execução entre nós foi detectada em 30 execuções de failover.

4.2 Comportamento de Partição

Em 30 execuções de partição (isolando um nó dos outros dois), nenhum candidato de saída duplicado foi detectado.
O nó isolado executou de 5 a 9 ciclos antes que sua autoridade local expirasse, enquanto o lado da maioria continuou. A lacuna entre a última saída isolada e a primeira saída da maioria foi de, em média, 944,081 ms.
Sob uma interpretação de Bernoulli, a taxa de eventos 0/30 resulta em um limite superior exato de 95% para a probabilidade de evento por execução de 9,5%.

4.3 Sincronização e Escala

O sistema sincronizou com sucesso 50.000 pontos com um throughput médio de ~18.363 pontos/s.
A latência média de sincronização foi de 8,192 ms para amostras intra-grupo.

4.4 Interferência de Recursos

Isolamento de CPU: A pressão de CPU em núcleos isolados teve efeito negligenciável no jitter do ciclo de controle. No entanto, a pressão em núcleos de runtime compartilhados aumentou o jitter de P99 para 4,981 ms.
I/O de Disco: O I/O de disco síncrono no host de runtime aumentou significativamente o jitter de P99 para 28,542 ms, destacando que fronteiras de contêiner por si só não isolam a interferência de disco.

4.5 Validação Hardware-in-the-Loop (HIL)

O sistema processou 1.200 amostras físicas de 4–20 mA (600 entrada analógica, 600 saída analógica) através de um gateway Modbus/TCP com fencing.
Precisão: O viés máximo entre setpoint e média foi de 0,01764 mA (AI) e 0,02078 mA (AO).
Linearidade: Valores de $R^2$ excederam 0,999999.
Segurança: Nenhuma amostra de má qualidade ou offline foi registrada.

5. Significância e Alegações

O artigo posiciona o VICP como um estudo de viabilidade e um protótipo reproduzível, em vez de um produto certificado para segurança.

Escopo: Os autores declaram explicitamente que o protótipo não reivindica garantias de tempo real estrito, tolerância a falhas bizantinas ou conformidade com níveis de integridade de segurança (ex: SIL).
Principal Conquista: O trabalho demonstra que a separação da autoridade de saída da replicação de estado é implementável em infraestrutura de prateleira. Prova que um lease respaldado por maioria pode efetivamente controlar a saída física irreversível, reduzindo o tempo de interrupção de failover em aproximadamente metade em comparação com uma configuração ativa-standby padrão, ao mesmo tempo em que evita a saída concorrente durante partições.
Fronteira de Engenharia: O artigo enfatiza que a segurança depende das suposições de tempo de lease e da implementação de fencing na fronteira de I/O físico. Argumenta-se que, embora o mecanismo de software seja sólido, a implantação em produção requer árbitros de hardware certificados, mensagens autenticadas e sincronização de relógio monitorada.
Trabalhos Futuros: Os autores observam que mais validação é necessária, incluindo a movimentação do fencing para hardware independente, testes em arquiteturas ARM e a realização de campanhas de longa duração com diversas injeções de falhas.

Em resumo, o VICP oferece um padrão arquitetural prático para clusters de borda industrial que equilibra a flexibilidade da computação nativa da nuvem com os rigorosos requisitos de segurança do controle de processos físicos, desde que controles de engenharia específicos (fencing, isolamento de recursos e autorização externa) sejam aplicados rigorosamente.