Upload
erivelton-silva-rocha
View
265
Download
0
Embed Size (px)
Citation preview
Universidade Estadual do Piauí – UESPI Licenciatura Plena em Computação
Pro
f. Erive
lton
da
Silva
Ro
cha
1
Em muitos sistemas, é possível implementar a tolerância
a defeitos de software por meio da inclusão explícita de
ações de verificação e recuperação no software.
Isso é denominado programação defensiva. Contudo,
essa abordagem não trabalha eficientemente com
defeitos do sistema que surgem com base em interações
entre o hardware e o software.
Além disso, a má compreensão dos requisitos pode
significar que tanto o código do sistema quanto a defesa
associada estão incorretos. 2
Pro
f. Erive
lton
da
Silva
Ro
cha
Para a maioria dos sistemas críticos,
particularmente aqueles com requisitos
rigorosos de disponibilidade, pode ser
necessária uma arquitetura específica
projetada para apoiar a tolerância a defeitos.
3
Pro
f. Erive
lton
da
Silva
Ro
cha
Exemplos de sistemas que usam essa
abordagem de tolerância a defeitos são os
sistemas de aviação, que devem estar em
operação durante o vôo, os sistemas de
telecomunicações, e os sistemas críticos de
comando e controle.
4
Pro
f. Erive
lton
da
Silva
Ro
cha
Há muitos anos existe a necessidade de se
construir hardware tolerante a defeitos.
A técnica de hardware tolerante a defeitos
mais comum é baseada na noção de
redundância modular tripla – TMR (Triple-
Modular Redundancy).
5
Pro
f. Erive
lton
da
Silva
Ro
cha
A unidade de hardware é replicada três (ou
algumas mais) vezes.
A saída de cada unidade passa para um
comparador de saída normalmente
implementado como um sistema de votação.
Se uma das unidades falha e não produz a
mesma saída que as outras unidades, sua
saída é ignorada
6
Pro
f. Erive
lton
da
Silva
Ro
cha
7
Pro
f. Erive
lton
da
Silva
Ro
cha
Um gerenciador de defeitos pode tentar
reparar a unidade defeituosa
automaticamente, mas se isso for impossível,
o sistema será automaticamente
reconfigurado para tirar a unidade de
serviço. Em seguida, o sistema continuará a
funcionar com duas unidades operando.
8
Pro
f. Erive
lton
da
Silva
Ro
cha
Através dessa técnica é que foi possível a
NASA colocar o homem na lua. Embora com
computadores precários e extremamente
simples, foi somente com esse tipo de
arquitetura tolerante a falhas que foi possível
garantir o pleno sucesso dessa missão.
9
Pro
f. Erive
lton
da
Silva
Ro
cha
Essa abordagem de tolerância a defeitos
baseia-se no fato de que a maioria das falhas
de hardware é resultante das falhas de
componente em vez de ser ocasionada por
defeitos de projeto. Os componentes são,
portanto, propensos a falhar
independentemente.
10
Pro
f. Erive
lton
da
Silva
Ro
cha
Supõe-se que, quando completamente
operacionais, toas as unidades de hardware
operem de acordo com a especificação. Há,
portanto, baixa probabilidade de falha
simultânea de componentes em todas as
unidades de hardware.
11
Pro
f. Erive
lton
da
Silva
Ro
cha
Naturalmente, todos os componentes
poderiam ter um defeito de projeto em
comum e, assim, todos produziriam a mesma
resposta errada. Usando unidades de
hardware com uma especificação em
comum, mas projetadas e construídas por
fabricantes diferentes, reduzem-se as
chances de uma falha de modo comum.
12
Pro
f. Erive
lton
da
Silva
Ro
cha
Presume-se que a probabilidade de equipes
diferentes cometerem o mesmo erro de
projeto ou de fabricação seja bem pequena.
13
Pro
f. Erive
lton
da
Silva
Ro
cha
Se os requisitos de disponibilidade e
confiabilidade de um sistema forem tais que
você necessite usar um hardware tolerante a
falhas, você pode também precisar de um
software tolerante a defeitos. Existem duas
abordagens para fornecer software tolerante
a defeitos.
14
Pro
f. Erive
lton
da
Silva
Ro
cha
Ambas as técnicas foram derivadas do
modelo de hardware em que componentes,
ou sistemas, redundantes são incluídos e
componentes defeituosos podem ser
desativados.
15
Pro
f. Erive
lton
da
Silva
Ro
cha
AS DUAS ABORDAGENS PARA TOLERÂNCIA A DEFEITOS DE SOFTWARE
SÃO:
Programação Em N-Versões:
Usando uma especificação comum, o sistema de
software é implementado em uma série de
versões por diferentes equipes. Essas versões
são executadas paralelamente em
computadores separados. Suas saídas são
comparadas com a utilização de um sistema de
votação, e saídas inconsistentes ou saídas não
produzidas em tempo, são rejeitadas. 16
Pro
f. Erive
lton
da
Silva
Ro
cha
No mínimo três versões de sistema devem
ser disponibilizadas de modo que duas
versões sejam consideradas consistentes no
evento de uma única falha. Essa é a
abordagem mais comum usada para
tolerância a defeitos de software. Ela foi
usada em sistemas de sinalização de
ferrovias, em sistemas de aviação e em
sistemas de proteção de reatores.
17
Pro
f. Erive
lton
da
Silva
Ro
cha
BLOCOS DE RECUPERAÇÃO:
Nessa abordagem, cada componente do programa inclui
um teste para verificar se componente foi executado
com sucesso. Também inclui um código alternativo que
permite ao sistema fazer uma cópia e repetir o
processamento se o teste detectar uma falha.
As implementações são, deliberadamente,
interpretações diferentes da mesma especificação. Elas
são mais executadas em seqüência do que em paralelo.
18
Pro
f. Erive
lton
da
Silva
Ro
cha
Dessa maneira, o hardware replicado não é
necessário. Na programação em n-versões,
as implementações podem ser diferentes,
mas não é incomum que duas ou mais
equipes escolham o mesmo algoritmo para
implementar a especificação.
19
Pro
f. Erive
lton
da
Silva
Ro
cha