Plano de Recuperação de Blocos
O esquema de blocos de recuperação é uma técnica de tolerância a falhas de software baseada na diversidade de projeto e na recuperação de erros retroativa. Ele estrutura um programa como uma série de blocos, cada um com um módulo primário, um teste de aceitação e um ou mais módulos alternativos. Se a saída do módulo primário falhar no teste de aceitação, o estado do sistema é restaurado e um módulo alternativo é executado.
O conceito de bloco de recuperação, introduzido por Brian Randell, é uma abordagem estruturada para alcançar tolerância a falhas em software. Ele opera com base no princípio de fornecer módulos de software redundantes, conhecidos como alternativas, para uma determinada operação, juntamente com um mecanismo para verificar a correção do resultado da operação. Os componentes principais são: o teste de aceitação (TA), a alternativa primária (P) e uma sequência de alternativas secundárias (Q1, Q2, ...). Antes de executar a alternativa primária, o sistema salva um ponto de verificação de seu estado atual. Após a conclusão de P, o teste de aceitação é executado na saída. O TA é uma peça lógica crucial que verifica se o resultado é aceitável; ele não precisa provar a correção absoluta, mas sim que o resultado é razoável e consistente.
Se o resultado passar no teste de aceitação (TA), o ponto de verificação é descartado e o programa prossegue. No entanto, se o TA falhar, ou se a alternativa principal falhar ao executar (por exemplo, devido a um erro de tempo de execução), o sistema realiza um rollback. Ele restaura o estado a partir do ponto de verificação salvo e, em seguida, executa a próxima alternativa na sequência (Q1). A saída de Q1 é então submetida ao mesmo teste de aceitação. Esse processo continua até que uma alternativa produza um resultado que passe no teste, ou até que todas as alternativas tenham sido esgotadas, momento em que uma falha em nível de sistema é declarada.
The effectiveness of recovery blocks hinges on the diversity of the alternates. The primary and secondary modules should be designed and implemented independently, ideally by different teams using different algorithms or programming languages. This minimizes the chance of a common design flaw (a bug) existing in all alternates, which would cause them all to fail the acceptance test in the same way. The acceptance test itself is a single point of failure and must be simpler and more reliable than the modules it is testing. Compared to N-version programming, another software fault tolerance technique, recovery blocks can be more efficient as they only execute one module at a time, but they introduce latency due to the potential for rollback and re-execution.
UNESCO Nomenclature: 1203
Ciência da Computação
Precursores
- Conceitos de tratamento de exceções em linguagens de programação
- Mecanismos de transação e reversão de banco de dados
- Trabalhos iniciais sobre verificação e correção de programas
- Princípios gerais de redundância da engenharia de hardware
Aplicações
- software crítico para a segurança em sistemas de sinalização ferroviária
- sistemas de proteção de reatores nucleares
- Aplicações aeroespaciais onde a falha de software é catastrófica
- sistemas operacionais experimentais tolerantes a falhas
Ideias de Inovação Potencial
- automated generation of acceptance tests from formal specifications
- hardware-accelerated checkpointing and rollback mechanisms
- integration of recovery blocks with machine learning for predictive fault detection
- distributed recovery blocks for microservices architectures
- recovery blocks for securing smart contracts on blockchains
- adaptive recovery block systems that reorder alternates based on past performance
- lightweight recovery block frameworks for resource-constrained embedded systems
- concurrent recovery blocks for multi-threaded applications
- verificação formal tools for proving the correctness of recovery block implementations
- self-synthesizing software that generates its own alternate modules
Relacionado a: blocos de recuperação, tolerância a falhas de software, diversidade de projeto, teste de aceitação, recuperação de erros retroativa, checkpointing, Brian Randell, software crítico para segurança, módulos redundantes, programação em N versões.