deti - ufc sistema em tempo real jarbas silveira sistemas em tempo real módulo 3: tolerância a...

DETI - UFCSistema em Tempo Real Jarbas Silveira

Sistemas em Tempo Real

Módulo 3: Tolerância a Falhas

Créditos, em sua maioria, ao Prof. Helano de Sousa Castro.


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


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

Roteiro


Roteiro


- 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


-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


Introdução

Falha Erro Defeito

Relacionamento entre Falha, Erro, e Defeito.


-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


-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.



-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]



-Falhas de iteração são causadas por:- Ações não apropriadas do operador

Uma 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].



-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.



-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.



-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].



-De um modo geral, erros causados por falhas no hardware são mais fáceis de antecipar que aqueles causados por falhas no software.



-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.




Distribuição de relatórios de problemas (287 eventos)


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).


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.


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.


- 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


- 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 (!)



-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].



Redundância de Hardware

A 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.



Redundância de Hardware Estática

Na 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”).




- 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.




- Um exemplo típico do uso deste tipo de redundância é a Redundância Modular Tripla (TMR - “Triple Modular Redundancy”).


M1

M2

M3

votador




M1

M2

Vota

Mn

M3

Redundância N-modular (NMR)


Redundância de Hardware Dinâmica

Em 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).





M1

M2

saída

Mn

M3

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.



- 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.



Redundância de Software

Redundâ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.



Redundância de Software Estática

Na 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).



Redundância de Software Dinâmica

Na 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.



Redundância de Tempo

Neste 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.



Redundância de Tempo

Em 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.



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


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.




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.




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.




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



-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].



-Checagem por Replicação


“Matching Circuits” usados no sistema de comutação ESS da AT&T


-Checagem por temporização

Checagem 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.



-Checagem por temporização

Esta 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.



-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].



-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.



-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.



-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.



-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.



-Checagem por Diagnóstico

Checagem por diagnóstico também usa um conhecimento prévio de partes do sistema. Entretanto, nesta técnica, uma checagem é feita nos componentes do sistema, e não no seu comportamento (como na checagem por consistência). Nesse sentido, a checagem por diagnóstico usa o conhecimento prévio das saídas dos componentes para todas as possíveis entradas, de modo a compará-las com as saídas resultantes da estimulação dos componentes com algum conjunto pré-definido de entradas.



-Checagem por Sequência de Controle

Esta técnica é basicamente relacionada com detecção de erros no software e é baseada em técnicas que checam o sistema para qualquer desvio de uma sequência de execução especificada. Uma falha relacionada com este tipo de erro é chamada uma falha de controle (“control fault”) e pode causar as seguintes conseqüências [TOY 87] :- execução infinita de um laço;- execução de um laço de programa em um número incorreto de vezes;- desvio ilegal ou errado.




Tres tipos de técnicas podem ser usadas para lidar com falhas de controle : checagem de desvios permitidos , esquema do “passador de bastão (“relay-runner”), e o uso combinado do “watchdog timer” e do esquema do passador de bastão.




Checagem de desvios permitidos consiste na detecção da execução de uma operação de desvio inapropriada [GALLAHER 81] e um exemplo do uso desta técnica pode ser achado no sistema de comutação eletrônica da AT&T. Nesse esquema, um bit de desvio-permitido está associado com cada palavra na memória principal, e é usado para indicar se uma posição de memória pode ou não ser usada por qualquer instrução de desvio.




O esquema do passador de passador de bastão [RAMAMOORTHY 74] pode ser usado também como um meio de detecção de execução ilegal de “jumps”. Nesse esquema, códigos pré-definidos ou bastões (similares a senhas), são associados com cada transferência de controle e são checados em pontos apropriados.




O esquema que consiste da combinação “watchdog timer” e “relay runner”, é usado a fim de detectar laços infinitos em um programa e falhas na estrutura de sequência de controle de um programa [KRAFT 81]. O temporizador (“timer”) levantará um exceção de “timeout” caso o programa não se apresente apropriadamente (por exemplo, se um número especificado de pontos de checagem não tenham sido atravessados em uma dada ordem e dentro de um dado período).



Confinamento e Avaliação de Danos:

As técnicas discutidas na última sessão fornecem ao sistema a capacidade de detectar os efeitos de uma falha (isto é, o erro). Entretanto, mesmo se o mecanismo de detecção fosse perfeito (todos os erros fossem detectados), haveria ainda um período de tempo decorrido entre o momento em que a falha ocorreu e o momento em que o erro foi detectado (este tempo é geralmente referido com latência da falha).



Confinamento e Avaliação de Danos:

Um conceito útil para organizar um sistema a fim de facilitar o confinamento dos danos é o da ação atômica [LOMET 77]. A atividade de um elemento constitui uma ação atômica se não existem interações entre aquele elemento e o resto do sistema por toda duração da atividade [ANDERSON 81].



Recuperação de Erros:

As discussões apresentadas nas duas sessões anteriores não se preocuparam com a alteração do sistema após a ocorrência de uma falha. Uma vez que um erro é detectado, esforços devem ser feitos a fim de trazer o sistema de volta para um estado operacional ou, em outras palavras, fazer o sistema recuperar-se dos erros.




O método de recuperação de erro usado pode ser influenciado pela técnica de detecção de erros utilizada. Em sistemas que usam as técnicas de mascaramento de falhas (p.ex, sistemas TMR), a detecção e a recuperação de erros ocorrem simultaneamente. Esses sistemas não necessitam incorporar todos os passos relacionados com sistemas tolerantes à falhas mencionados anteriormente, por razões óbvias. A ação de recuperação de erro envolve o uso de algoritmos de recuperação que podem (ou não) requerer decisões humanas.




A primeira classe de algoritmos é dita de automática , ao passo que o segundo caso é dita controlada manualmente. Algoritmos de recuperação automática podem ser classificados, de acordo com o estado do sistema após a ação de recuperação, como : recuperação completa, recuperação com degradação, e desligamento seguro (“safe shutdown”) [AVIZIENIS 78].




Recuperação completa tenta deixar o sistema com a mesma capacidade de hardware e software que existia antes da ocorrência da falha. Isto é alcançado usando-se chaveamento automático dos módulos falhos (reconfiguração) e substituido-os por cópias “sadias”.




Na recuperação com degradação, também conhecida como degradação progressiva (“graceful degradation” ou “fail-soft operation”) [LALA 85], os módulos falhos são também isolados, como no método anterior, entretanto, não existem cópias disponíveis e portanto o sistema irá prosseguir de uma forma degradada.




Desligamento seguro (“safe shutdown” ou “fail-safe operation”), é o caso limite de uma recuperação com degradação [TOY 87]; nesse caso o sistema não é mais capaz de fornecer a computação requerida porque todas as cópias foram utilizadas em tentativas anteriores de recuperação, ou o número de cópias sobreviventes não pode dar conta da computação requerida.



Tratamento da Falha e Continuação do Serviço:

Uma vez que os passos anteriores não asseguram que a falha que provocou o(s) erro(s) seja identificada, outro passo pode ser necessário a fim de evitar que a falha ocorra novamente. Note que um tipo particular de erro poderia ser o resultado de muitas fontes de falhas. Este passo é utilizado para isolar a falha, ou para reconfigurar o resto do sistema, em um esforço para evitar suas manifestações repetidas e, usualmente envolve dois estágios : localização e reparo do sistema.


deti - ufc sistema em tempo real jarbas silveira sistemas em tempo real módulo 3: tolerância a...

Documents