Sistemas em Tempo Real

Sistemas em Tempo Real Módulo 3: Tolerância a Falhas Créditos, em sua maioria, ao Prof. Helano de Sousa Castro. Jarbas Silveira

Ementa:3. Tolerância a Falhas: Falha, Erro e Defeito; Tipos de falhas; Redundância (Estática e Dinâmica); Detecção; Avaliação de Danos; Recuperação de erros. Roteiro Jarbas Silveira

Introdução- Classificação das Falhas- Prevenção de Falhas- Tolerância à Falhas- Estratégias de Tolerância à Falhas- Recuperação do Erro Roteiro Jarbas Silveira

Roteiro Jarbas Silveira

- Técnicas de tolerância a falhas são usadas em sistemas de computadores como forma de se lidar com condições de erro que podem surgir durante as suas vidas operacionais.- O relacionamento entre causa e efeito é melhor entendido sob a luz de três conceitos básicos : defeito, erro e falha. Introdução Jarbas Silveira

-Um defeito é um desvio do comportamento do sistema de algum conjunto de especificações pré-definidas. Um Erro é parte de um estado errôneo que constitui uma diferença de um estado válido.Uma Falha ocorreria como resultado de um erro de um componente ou no projeto do sistema. Introdução Jarbas Silveira

Falha Erro Defeito Introdução Relacionamento entre Falha, Erro, e Defeito. Jarbas Silveira

-A fim de proteger o sistema contra falhas, o projetista terá que provê-lo com técnicas que possam lidar com elas. Entretanto, esta estratégia só pode levar em conta as falhas que tenham sido antecipadas durante a fase de projeto.Infelizmente, o único tipo de falha que pode ser antecipadamente previstas com algum grau de precisão são falhas em componentes do hardware do sistema [ANDERSON 81]. Classificação das Falhas Jarbas Silveira

-Falhas em um sistema podem resultar de várias e diferentes razões, desde envelhecimento de componentes, a falhas na interação do homem com computador. - Por este motivo, é comum se classificar as falhas de acordo com suas origens. Avizienis [AVIZIENIS 71] classifica as falhas em três grupos : falhas de projeto, falhas de interação e, falhas físicas. Classificação das Falhas Jarbas Silveira

Falhas de projeto podem ser devido a :- especificações erradas, ambíguas, ou incompletas; - enganos cometidos durante a tradução de uma especificação na implementação final.Embora as falhas resultando de erros de projeto possam ocorrer tanto a nível de hardware, quanto a nível de software, estas últimas são mais predominantes e difíceis de se eliminar do sistema [TOY 87] Classificação das Falhas Jarbas Silveira

Falhas de iteração são causadas por:- Ações não apropriadas do operadorUma forma de reduzir o número de ocorrências de tais falhas é fornecer treinamento extensivo tanto para o pessoal de operação como manutenção.Outra forma de atingir esse objetivo poderia ser o uso extensivo de interfaces homem-máquina que fossem de fácil uso (“user-friendly”) [TOY 87]. Classificação das Falhas Jarbas Silveira

Falhas físicas geralmente resultam do envelhecimento dos componentes e, portanto, estão associadas com o hardware do sistema.Elas podem ser classificadas por : duração, valor, ou extensão [AVIZIENIS 78].A duração está relacionada com o fato da falha ser, transiente ou permanente. Classificação das Falhas Jarbas Silveira

Valor se refere a se a falha leva as variáveis assumirem um valor determinado ou indeterminado. - No primeiro caso, também conhecida como “colado em” (“stuck-at”), a variável é levada a assumir um valor lógico constante “1” ou “0”. - No segundo caso, o efeito da falha sobre a variável é tal que seu valor se alterna entre dois valores, mas não em um modo especificado na especificação original. Classificação das Falhas Jarbas Silveira

A extensão de uma falha é determinada pelo fato de se os erros provocados por ela são locais ou distribuídos. - Falhas locais afetam somente componentes de uma única variável lógica, enquanto falhas distribuídas afetam duas ou mais variáveis lógicas, um subsistema, ou o sistema [AVIZIENIS 78]. Classificação das Falhas Jarbas Silveira

De um modo geral, erros causados por falhas no hardware são mais fáceis de antecipar que aqueles causados por falhas no software. Classificação das Falhas Jarbas Silveira

análise dos históricos de falhas para se identificar “tendências” (26R Space Shuttle-Relatório da Comissão Roger):- Criticalidade 1 - Problemas que poderiam resultar em perda de vida ou do veículo;- Criticalidade 2 - Problemas que poderiam criar um perigo real ou em potencial que poderiam levar a perda da carga da missão ou de toda missão, ou ainda em risco à tripulação;- Criticalidade 3 - Problemas que poderiam criar um retardo real ou em potencial da missão;- Criticalidade 4 - Defeitos “cosméticos” e/ou não funcionais, ou defeitos que sejam imediatamente reparáveis, sem nenhum impacto no tempo de execução da missão. Classificação das Falhas Jarbas Silveira

Classificação das Falhas Distribuição de relatórios de problemas (287 eventos) Jarbas Silveira

Classificação das Falhas -A experiência anterior mostra a importância de se coletar dados relacionados com eventuais problemas que o sistema possa experimentar (comunicação de problemas). Essa informação pode ser usada a fim de corrigir imperfeições no projeto, deste modo aumentado sua confiabilidade (esta estratégia é largamente empregada pelos engenheiros de controle de qualidade em sistemas comerciais). Jarbas Silveira

Prevenção de Falhas • -Na técnica de prevenção de falhas, também conhecida como Intolerância à Falhas , todos os esforços são concentrados na eliminação de todas as possíveis fontes de falhas antes que o sistema entre em operação. - Componentes altamente confiáveis são usados no projeto; Uma blindagem eficaz é utilizada, e testes exaustivos são feitos na esperança de se eliminar todas as falhas. Assim, o sistema funcionará apropriadamente (de acordo com suas especificações), contanto que nenhuma falha ocorra. Jarbas Silveira

Prevenção de Falhas - Embora esta técnica seja relativamente fácil de implementar, ela tem empecilhos quando usada isoladamente. - O sistema só irá operar de acordo com suas especificações somente quando estiver livre de erros - O pessoal de manutenção terá que estar de plantão para eventuais interrupções de funcionamento - Tais restrições podem ser inaceitáveis para sistemas que estejam localizados em lugares de difícil acesso para manutenção (p.ex. naves espaciais não tripuladas). - Por estas razões, prevenção de falhas é usada conjuntamente com tolerância à falhas. Jarbas Silveira

- Nesse caso, o projetista vê o sistema de um modo mais realístico, considerando as falhas como eventos normais que devem ser tratados. Um sistema (de computador) tolerante à falhas é aquele que, sem nenhuma intervenção manual, é capaz de lidar com falhas operacionais e de projeto, e de manter o desempenho do sistema dentro de suas especificações. Tolerância à Falhas Jarbas Silveira

- Estratégia mais comum: Redundância- Redundância a nivel de software, hardware e tempo- O uso de recursos redundantes empregados em tais sistemas não tem como objetivo aumentar o desempenho deles, como no caso, por exemplo, quando múltiplos processadores são usados para aumentar a velocidade de processamento de dada certa computação. De fato, de um modo geral, a computação em sistemas redundantes pode acabar sendo mais lenta (!) Tolerância à Falhas Jarbas Silveira

-A redundância em sistemas tolerantes à falhas podem ser classificadas em : hardware, software, e tempo. - Poderia ser dito, entretanto, que o uso de um tipo de redundância pode levar ao uso de outros tipos. Na redundância de software, por exemplo, o programa de controle faz uso tanto do espaço de memória (hardware), como de execução (tempo) [TOY 87]. Tolerância à Falhas Jarbas Silveira

Redundância de HardwareA redundância de hardware consiste do uso de circuitos extras para detectar e corrigir erros e pode ser dividido em dois tipos : estática e dinâmica. Tolerância à Falhas Jarbas Silveira

Redundância de Hardware EstáticaNa redundância estática (ou “mascaramento”), componentes adicionais são usados para mascarar os efeitos de uma falha (isto é normalmente conseguido através do uso de componentes “em paralelo”). Tolerância à Falhas Jarbas Silveira

Redundância de Hardware Estática- Seu uso em sistemas reparáveis pode vir a ser indesejável, uma vez que o processo de isolamento do componente falho teria que contar com outros mecanismos para localizá-la.- Entretanto, porque a falha não é “sentida” pelo sistema, esta técnica pode ser muito atrativa em aplicações em tempo real com requerimentos de tempo muito exigentes, uma vez que não seria necessário se gastar tempo no processo de detecção e isolamento da falha. Tolerância à Falhas Jarbas Silveira

Redundância de Hardware Estática- Um exemplo típico do uso deste tipo de redundância é a Redundância Modular Tripla (TMR - “Triple Modular Redundancy”). M1 M2 M3 votador Tolerância à Falhas Jarbas Silveira

Redundância de Hardware Estática M1 M2 Vota Mn M3 Tolerância à Falhas Redundância N-modular (NMR) Jarbas Silveira

Redundância de Hardware DinâmicaEm contraste com a redundância estática, nesta técnica, (também conhecida como redundância seletiva), os módulos redundantes existem em um modo “stand-by” e podem substituir um módulo falho, automaticamente ou manualmente, pelo módulo reserva selecionado, que pode está ativo (ligado) ou passivo (desligado). Tolerância à Falhas Jarbas Silveira

Redundância de Hardware Dinâmica M1 M2 saída Mn M3 Tolerância à Falhas Em um sistema Stand-by, um dos n módulos é usado para fornecer a saída do sistema e n-1 módulos são usados como cópias. Jarbas Silveira

Redundância de Hardware Dinâmica- A falha tem que ser primeiramente detectada, uma vez que ela não é mascarada.- Se uma falha é detectada, um procedimento de diagnóstico deve ser executado a fim de localizar quais os módulos que estão falhos, antes de substituí-los.- Note que o tempo entre a detecção da falha e a substituição de um módulo falho por um reserva pode ser considerável (especialmente se o módulo reserva é passivo), e isto pode não ser tolerável em algumas aplicações em tempo real. Tolerância à Falhas Jarbas Silveira

Redundância de SoftwareRedundância de software é usada para ajudar o sistema a superar tanto falhas de hardware como de software. Ela consiste de programas e instruções extras tanto em macro como micro níveis [TOY 87]. Existem dois tipos de redundância de software : estática e dinâmica. Tolerância à Falhas Jarbas Silveira

Redundância de Software EstáticaNa redundância de software estática, programas replicados são executados concorrentemente em máquinas separadas e seus resultados são comparados numa base de “a maioria vence” (uma versão software de um TMR). Tolerância à Falhas Jarbas Silveira

Redundância de Software DinâmicaNa redundância de software dinâmica, uma cópia do estado de um módulo é salva, periodicamente, em alguns pontos do programa, conhecidos como pontos de checagem (“checkpoints”), durante a operação do sistema. A recuperação de um erro é alcançada retrocedendo a execução do programa (“rolling back”) para o último ponto de checagem. Tolerância à Falhas Jarbas Silveira

Redundância de TempoNeste caso a redundância é implementada através da repetição de operações e é normalmente usada para detectar falhas transientes [LALA 85]. Exemplos desta técnica são : re-execução (“rollback”) de instruções, segmentos de programas ou programas inteiros, e o re-envio de mensagens em um sistema distribuído. Tolerância à Falhas Jarbas Silveira

Redundância de TempoEm operações “rollback”, a re-execução de programas começa de pontos pré-definidos em um programa, conhecidos como pontos de checagem (“checkpoints”), onde o status do programa e toda informação necessária para uma recuperação bem sucedida é armazenada.O JPL-STAR [AVIZIENIS 71] e o computador Non-Stop Tandem [KATZMAN 78] são exemplos de sistemas que fazem extensivo uso desta técnica. Tolerância à Falhas Jarbas Silveira

Um sistema tolerante à falhas deve executar uma seqüência de passos, (que incluem detecção e recuperação), após a ocorrência de uma falha. O número e tipo de passos podem depender do tipo de redundância a ser empregada. Existem, entretanto, quatro passos básicos que iremos descrever agora :- Detecção de Erros;- Confinamento e Avaliação de Danos;- Recuperação de Erros;- Tratamento da Falha e Continuação do Serviço. Estratégias de Tolerância à Falhas Jarbas Silveira

Detecção de Erros:Este é o ponto de partida para qualquer técnica de tolerância à falhas com alguma chance de ser bem sucedida. De um modo geral, quanto mais detecção de erros em um sistema, mais confiável ele será.Não é prático, entretanto, equipar o sistema com um grande número de facilidades para detecção de erros, sobretudo devido ao custo e “overheads” impostos por extensivas checagens. Estratégias de Tolerância à Falhas Jarbas Silveira

Detecção de Erros:O sistema não deve ter nenhum ponto comum de falhas relacionado com seu checador e, idealmente, ele (checador) deveria ser projetado por uma diferente equipe de projetistas. Anderson e Lee [ANDERSON 81] dão três critérios que balizam o projeto de um checador ideal:1. Ele deveria ser derivado tão somente das especificações do sistema;2. Ele deveria ser capaz de fazer uma completa checagem do sistema;3. Ele deveria ser independente do sistema. Estratégias de Tolerância à Falhas Jarbas Silveira

Detecção de Erros: Duas principais estratégias podem ser usadas, no que se refere a quando a checagem deveria ser feita. – Last-moment checks – Early check Na prática, entretanto, uma combinação das duas estratégias acima deveriam ser usadas para se atingir uma boa cobertura de falhas. Estratégias de Tolerância à Falhas Jarbas Silveira

Detecção de Erros: Enquanto as técnicas de detecção de erros podem variar de sistema para sistema, a maioria delas pode ser situadas em uma das seguintes [ANDERSON 81] :- Checagem por Replicação- Checagem por temporização- Checagem por Codificação- Checagem por Reversão- Checagem por Consistência- Checagem por Diagnóstico- Checagem por Sequência de Controle Estratégias de Tolerância à Falhas Jarbas Silveira

Checagem por Replicação Consiste da replicação da atividade do sistema que está sendo checada e é uma das mais completas medidas para se detectar erros em um sistema de computador [ANDERSON 81]. É normalmente usada a fim de se detectar falhas no hardware, e pode ser implementada tanto a nível de circuito como a nível de subsistema. Apesar de ser uma técnica relativamente cara, está se tornando praticável, em termos de custos, para aplicações que têm grandes requisitos de confiabilidade, devido aos rápidos avanços nas tecnologias de VLSI e microprocessadores [TOY 87]. Estratégias de Tolerância à Falhas Jarbas Silveira

Checagem por Replicação Estratégias de Tolerância à Falhas “Matching Circuits” usados no sistema de comutação ESS da AT&T Jarbas Silveira

Checagem por temporizaçãoChecagem por Temporização é particulamente eficaz na detecção de erros no software em programas replicados [TOY 87]. Aqui, a execução de uma operação não deve exceder um tempo máximo pré-determinado, caso contrário um exceção de “timeout” (“tempo ultrapassado”) é levantada para indicar que um defeito ocorreu. Estratégias de Tolerância à Falhas Jarbas Silveira

Checagem por temporizaçãoEsta técnica é normalmente associada com o uso de um temporizador, que pode ser implementado tanto por hardware como por software. Quando um temporizador hardware é utilizado, ele é chamado de temporizador “cão de guarda” (“watchdog timer”) e tem que ser periodicamente “resetado”pelo programa. Caso este temporizador não “resete” (atualize) o temporizador (devido a, por exemplo, um laço infinito no programa, ou um problema qualquer no software e/ou hardware), ele irá levantar uma exceção. Estratégias de Tolerância à Falhas Jarbas Silveira

Checagem por Codificação Esta técnica usa uma representação redundante de objetos como forma de detectar erros. Esta representação mantém um relacionamento fixo com a representação original (não redundante) do objeto, e uma exceção será levantada se este relacionamento não existir mais, como resultado de um erro [ANDERSON 81]. Estratégias de Tolerância à Falhas Jarbas Silveira

Checagem por Codificação O exemplo mais comum de checagem por codificação é o uso de checadores de paridade, onde um bit de paridade está associado com um número de bits (normalmente uma palavra), e seu relacionamente é tal que a soma módulo 2 de todos os bits é ou 0 (zero), paridade par, ou 1 (um), paridade ímpar. Estratégias de Tolerância à Falhas Jarbas Silveira

Checagem por Reversão A Checagem por Reversão envolve o cálculo de qual deveria ser a entrada para uma computação, baseado em uma saída (já obtida) para aquela mesma computação, e posterior comparação daquela entrada com a entrada original. Estratégias de Tolerância à Falhas Jarbas Silveira

Checagem por Reversão Ela é somente factível quando o relacionamento entre as entradas e saídas é na base de uma para uma. Estes tipos de checagens podem ser usados, com grande eficiência, em sistemas onde funções matemáticas estão envolvidas (no relacionamento de entrada com saída), embora margem para discrepâncias deve ser aceita quando operações em ponto flutuante são usadas. Estratégias de Tolerância à Falhas Jarbas Silveira

Checagem por Consistência Nesta técnica um teste é feito para checar se o estado das variáveis no sistema é “razoável”, baseado no conhecimento prévio de suas características. Por exemplo, se o resultado de uma dada computação não pode resultar em valores negativos, uma checagem por consistência poderia ser usada para levantar uma exceção caso um valor negativo fosse obtido como resultado. Estratégias de Tolerância à Falhas Jarbas Silveira

Sistemas em Tempo Real