9 Fiabilidade, testes e tolerância a falhas

Transcrição

1 9 Fiabilidade, testes e tolerância a falhas Um sistema fiável é o resultado de um processo sólido de desenho, boa engenharia, e um processo sólido de testes. Neste capítulo vamos discutir fiabilidade, e como a melhorar, através de testes ao sistema e de tolerância a falhas. 9.1 Bugs, faltas, falhas e defeitos Embora seja comum associar a estes termos o mesmo significado, há muita diferença entre eles. O termo bug significa que existe um erro num sistema sem ninguém ser responsável. O termo preferível é o defeito. Este defeito evidencia-se, na operação do sistema, como ma falta. Se esta falha implicar que um dos requisitos do sistema não foi cumprido, temos então uma falha. 9.2 Fiabilidade Esta característica desejável para um sistema pode ser definido, informalmente, de vários modos. Podemos definir um sistema fiável como: - Aquele em que podemos confiar; - Está livre de erros catastróficos; - Os seus resultados são previsíveis; - É um sistema robusto (no contexto de pode recuperar de erros). Especificamente para sistemas de tempo real, fiabilidade pode ser caracterizada por: - Determinismo de eventos; - Determinismo temporal; - Carga temporal razoável - Carga de memória razoável Definição formal Admitamos que S é um sistema de software e que T denota o instante de tempo em que uma falha do sistema ocorre. Então, a fiabilidade do sistema S, no tempo t, denotada por probabilidade que T seja maior que t, isto é: ( ) rt (), é a rt () = PT> t (9.1) 9-1

2 Deste modo, um sistema com rt () = 1 nunca tem falhas. De acordo com a distribuição assumida para a função de falha, temos diferentes modelos para caracterizar a fiabilidade de um sistema. Um modelo normalmente utilizado assume uma distribuição exponencial. Assim, a probabilidade de falhas é grande ao início (o que tem lógica, dada ser um novo código) e decresce com o tempo (à medida que os erros vão sendo resolvidos). O seguinte modelo usa uma função como a ilustrada na fig Intensidade da falha tempo Fig. 9-1: Função de falha Este modelo é bastante usada para descrever a evolução das falhas em hardware (o aumento da intensidade das falhas após um certo tempo tem a ver com o envelhecimento dos componentes), mas não é tão vulgar para software. Em termos de software, o aumento da intensidade é devido a erros provocados por alterações ao software, ou pela utilização mais exigente do software, à medida que o utilizador vai tendo experiência com ele Calculando a fiabilidade do sistema Há algumas técnicas que podem ser utilizadas para estimar a fiabilidade de um sistema. Vamos referirmo-nos a 3 técnicas: o modelo de blocos de processos, a métrica de McCabe e a métrica de Halstead O modelo de blocos de processos Entende-se um sistema como sendo constituído por uma série de sub-sistemas, denominados por blocos de processos, ligados entre si em série ou em paralelo. A probabilidade de falha, ou, ao contrário, a fiabilidade de um sistema podem ser calculadas utilizando simples regras de probabilidade. Este método assume independência de cada bloco (que é uma 9-2

3 simplificação exagerada, dado poder haver comunicação de dados entre blocos) e só suporta controlo de fluxo síncrono. Se dois sub-sistemas estiverem ligados em paralelo, como é ilustrado na fig. 9.2, então o sistema conjunto só falha se ambos os sistemas falharem. 1 2 Fig. 9-2: Sub-sistemas em paralelo Como a função de falha é dada por ( 1 rt ( )) conjunto é:, então a função de falha para o sistema req () t ( r1() t )( r2() t ) () = () + () () () 1 = 1 1 r t r t r t r t r t eq (9.2) Para um sistema série, o sistema falha quando algum dos sub-sistemas falha. 1 2 Fig. 9-2: Sub-sistemas em série Neste caso, eq () = () () r t r t r t 1 2 (9.3) Métrica de McCabe Alguns especialistas acreditam que a fiabilidade do software pode ser estimado através de características do código fonte. Uma dessas métricas, introduzidas por McCabe, é baseada na complexidade do fluxo de controlo. Esta técnica admite que um programa pode ser visto como um grafo em que cada nó representa um bloco de código sequencial, enquanto cada 9-3

4 mudança síncrona de fluxo representa um arco. Do mesmo modo que no caso anterior, mudanças de fluxo assíncronas não são suportadas. Num sistema multitarefa, cada tarefa é representada por um grafo, que pode ser obtido directamente dos grafos de fluxos, diagramas de fluxo de dados, redes de Petri, ou de autómatos finitos. Admita-se que existem p grafos, e nós, e n arcos. Então a complexidade ciclomática, C, é dada por: C= e n+ 2 p (9.4) A hipótese de McCabe é a de que C reflecte a dificuldade em perceber, testar e manter o software. Segundo ele, se 3 C 7, o programa está bem estruturado Métrica de Halstead Os dois métodos anteriores têm o problema de que não contemplam mudanças de fluxo de controlo assíncronas, que acontecem em sistemas de tempo real. Este método não sofre desta desvantagem. Esta métrica depende de características do código: η 1 1. : o número de instruções distintas begin-end, e de GOTO ou análogas; estas são chamadas de operadores; η 2 2. : o número de linhas distintas terminadas por ; em C ou análogas; estão são chamadas de operadores; 3. N 1 : o número total de ocorrências de operadores no programa; 4. N 2 : o número total de ocorrências de operandos no programa; Com estas características, Halstead propões as seguintes medidas: O vocabulário, η= η + η ; 1 2 O comprimento do programa, N = N + N ; O volume do programa, V = Nlog 2 η ; 1 2 ( ) ( ) O volume potencial, V* = 2+ η log 2+ η ; O nível do programa, L= V */ V Halstead sugeriu que L mede o nível de abstracção do programa. À medida que L aumenta, a fiabilidade também aumenta. Uma outra medida introduzida é o esforço requerido para desenvolver o programa. E= V / L Diminuindo E, aumenta a fiabilidade do programa. 9-4

5 9.3 Testes É importante referir que o objectivo de testar um sistema não é apenas o de detectar erros, dado que um teste só detecta a presença de erros, e não a sua ausência. A finalidade última de testar um sistema é de verificar se um sistema satisfaz os seus requisitos. Desta maneira, no ciclo de desenvolvimento de um sistema deve ser construído um plano de testes, com critérios objectivos que permitam determinar se o sistema cumpre ou não os requisitos. Este plano deve testar o sistema módulo a módulo, sub-sistema a sub-sistema, e finalmente o sistema total Testes a módulos As técnicas abaixo descritas podem ser utilizadas pelo programador, ou pelo um grupo independente de testes Testes caixa negra Neste tipo de testes, só as entradas e saídas são relevantes; como as saídas são geradas em função das entradas não é considerado. Tem a vantagem de poder ser utilizado para qualquer tipo de módulo, e a desvantagem de não fornecer qualquer informação sobre a habilidade do programador, não podendo também identificar código inatingível. Para cada módulo, um determinado número de casos de teste são gerados, dependente da funcionalidade do módulo, número de entradas/saídas, etc. Se para qualquer caso de teste um erro é detectado, é corrigido e toda a bateria de testes novamente aplicada. Para gerar os casos de teste, pode-se usar: 1. Geração exaustiva (força bruta) todas as combinações possíveis das entradas são geradas; isto é sempre possível, mas pode ser proibitivo em termos de tempo; 2. Casos de canto (corner cases) por exemplo, os valores máximo, mínimo e médio para cada variável são testados; 3. Casos patológicos combinações não usuais que podem conduzir a erros; 4. Testes estatísticos testes aleatórios ou assumindo uma determinada distribuição de probabilidade para cada entrada Sempre que possível, geração exaustiva deve ser usada. Se tal não for possível, é normalmente utilizada uma combinação das outras técnicas. 9-5

6 Testes caixa branca Estes testes são desenhados para testar todos os possíveis fluxos do programa. Normalmente não é apenas o programador que testa todo o código, mas porções diferentes de códigos são passadas a diferentes grupos, que além de testar o código inspeccionam-no para testar todos os possíveis erros e eventualmente melhorar o código Métodos formais de prova Um tipo de testes de caixa branca interpreta as especificações e o código gerado como especificações verificáveis que são provadas matematicamente. Além de não serem muito viáveis para grandes sistemas, necessitam de conceitos de lógica temporal ou de álgebra de processos que está fora do âmbito desta disciplina. Não há muitas ferramentas comerciais que implementem estas técnicas Testes ao nível do sistema ou de sub-sistemas Após todos os módulos serem testados individualmente, então os sub-sistemas ou o sistema total precisa de ser testado. Aqui, a equipa de programadores passa o produto para a equipa de teste. O teste de um sistema ou sub-sistema é um teste do tipo caixa preta, e assim todos os métodos atrás referidos podem ser usados. Se um erro for detectado nesta fase, o erro deve ser reparado. Idealmente, o módulo onde o erro foi detectado deve ser sujeito a testes de módulo, antes de se continuar os testes do sistema ou sub-sistema. Após o sistema testado pela equipa de testes, segue-se o denominado teste-alfa. Aqui, o sistema é distribuído pela empresa, e testado. Seguem-se os testes-beta, onde o produto é distribuído por alguns consumidores que se disponibilizam para utilizar o sistema. Um outro tipo de testes, que ocorre mais tarde na vida de um sistema, é o teste de regressão. Se houver novas versões de software, então a bateria de testes a que o sistema foi inicialmente submetido deve ser aplicada ao novo produto, eventualmente com casos de testes adicionais Testes estatísticos Uma técnica que pode ser usada também ao nível do módulo como ao nível do sistema é o uso de testes estatísticos. Se se conhecer a função distribuição de probabilidade para cada entrada podem-se gerar números aleatórios tirados dessa distribuição. Os principais problemas com este tipo de testes são, na maior parte das vezes, o desconhecimento da(s) 9-6

7 distribuição(ões), e o facto de os erros mais difíceis de serem detectados serem exactamente aqueles que tem uma menor probabilidade de ocorrência Teste de stress Neste caso o sistema é submetido a forte perturbações nas entradas (por exemplo várias interrupções sucessivas), seguidas de poucas perturbações na entrada, por um largo período de tempo. 9.4 Tolerância a falhas Tolerância a falhas significa a habilidade do sistema de continuar a funcionar na presença de uma falha de hardware ou software. A fiabilidade de um sistema de tempo real pode ser melhorada, utilizando tolerância a falhas, de duas maneiras: tolerância espacial, isto é, a utilização de métodos que envolvem redundância em software ou em hardware, e tolerância temporal, isto é, a utilização de métodos que toleram a falha do cumprimento de metas temporais Solução geral A fiabilidade do hardware pode ser melhorada usando tolerância a falhas espacial usando 3 ou mais dispositivos ligados por um esquema de votação maioritária. Por vezes é também usado um ou mais pares de dispositivos redundantes. Cada elemento de um par compara a sua saída com a do seu companheiro. Se os resultados diferem, então o par declara-se em erro, e as suas saídas são ignoradas. Esquemas de votação podem também ser usados para software. Diferente informação pode ser usada para melhorar a estimativa de uma dada variável Checkpoints Em localizações fixas do código, resultados intermédios podem ser escritos em ficheiros ou posições de memória. Estas localizações, chamadas de s, podem ser usados durante a operação do sistema ou durante a verificação do sistema. Se os s forem usados durante o teste, isto é chamado de test probe. Estes pontos de prova introduzem pequenos erros temporais que são difíceis de diagnosticar. 9-7

8 Bloco 1 Bloco 2 Bloco 3 Fig. 9-3: Implementação de Técnica de recuperação Os s podem ser usados conjuntamente com técnicas de recuperação (recovery) para aumentar a fiabilidade do sistema. Neste caso, pontos pré-determinados do código são pontos de reset. Nestes pontos os s são testados para verificar se os resultados são razoáveis. Se o são, então passa-se para o próximo bloco de recuperação. Se não são, esse bloco é corrido novamente, ou o controlo é passado para outro anterior, com eventualmente novos dados, o que possibilita que o sistema recupere de uma eventual falha. Bloco 1 Bloco 2 Bloco 3 Testa resultados intermédios Restart Fig. 9-3: Implementação de um bloco de recuperação Cada bloco de recuperação funciona assim, de um certo modo, como um bloco em paralelo, aumentando a fiabilidade do sistema Programação de n versões Qualquer sistema pode bloquear por ter sido executada uma mudança de fluxo não testada e entrar num estado em que não existe saída. Para diminuir a possibilidade de estas situações acontecerem, podem-se introduzir processadores redundantes que executam software com as mesmas especificações, mas produzidos por diferentes programadores. A possibilidade de os diferentes sistemas bloquearem no mesmo ponto é assim altamente reduzida. Dado que 9-8

9 normalmente cada sistema tem um watchdog timer, o sistema total pode rapidamente chegar à conclusão que esse processador está inoperativo, e ignorá-lo. Esta técnica é chamada de programação de n versões. Os processadores redundantes podem usar um esquema de votação para decidir das saídas, ou pode ser usado um esquema master-slave. Neste caso o master está on-line, a produzir saídas aplicadas ao processo, enquanto o slave só vigia a sua operação. Se, no entanto, for detectada alguma anomalia no master, o slave fica on-line Software de teste incorporado Uma outra forma de aumentar a fiabilidade do hardware é incorporar software de teste no código (built-in test software BITS). Como exemplo, se um canal de I/O não está a funcionar correctamente, o software pode encerrá-lo e reconfigurar o sistema. BITS têm importantes vantagens, mas torna-se difícil depois determinar análises de performance de pior caso Teste de CPU O CPU é provavelmente o dispositivo mais importante do sistema. Podem-se desenhar testes para validar o bom funcionamento do CPU em todos os modos de endereçamento. Este conjunto de testes é no entanto demorado, e por isso deve ser executado em background, e com as interrupções inibidas Testes de memória Há dois tipos de erros de memória: erro de conteúdo, denominado de soft error, e erro da célula de memória, denominado hard error Memória ROM Muitas vezes a memória ROM é testada utilizando checksums, que são essencialmente adições binárias para toda a memória ROM. Este valor é comparado com a checksum original, calculada na linkage e armazenada numa posição de memória ROM. A desvantagem que este método tem é a de que um número par de erros em cada bit pode-se anular, e portanto não se trata de um sistema muito fiável. O método mais utilizado é utilizar um código redundante cíclico (cyclic redundant code CRC), que trata o conteúdo da memória total como uma cadeia enorme de bits, associando-a a uma polinomial de ordem muito elevada. Esta é conhecida como a polinomial de mensagem. Uma segunda polinomial de mais baixa ordem (tipicamente de ordem 16) é 9-9

10 chamada de polinomial geradora, é dividida pela polinomial da mensagem, a qual é acrescida de um conjunto de bits a 0 para cada termo na polinomial geradora. O resultado da divisão é um quociente e um resto, sendo o 1º descartado e o 2º usado para detectar todos os erros de 1-bit e virtualmente todos os erros de bits múltiplos. Não permite, no entanto, diagnosticar a causa do erro Memória RAM Dada a natureza dinâmica desta memória, as técnicas anteriores não podem ser utilizadas. Uma maneira de proteger esta memória contra erros é adicionar bits extra, para implementar um código de Hamming. Dependendo do número de bits, chamados de sindroma, erros de 1 ou mais bits podem ser detectados e corrigidos. Chips que implementam a detecção e correcção de erros (error detection and correction EDC) estão disponíveis comercialmente. Durante uma operação de leitura ou de escrita, os dados passam pelo chip, são comparados com o sindroma e as correcções são implementadas. De salientar que numa operação de leitura os conteúdos da memória não são alterados, o que quer dizer que numa operação de leitura subsequente todo o processo é repetido. Numa operação de escrita o código é computado e armazenado simultaneamente com os dados. Isto é chamado de RAM scrubbing. Na ausência de hardware para teste e correcção, um conjunto de testes, normalmente executados na inicialização, é utilizada para testar a memória Outros dispositivos A outros dispositivos estão normalmente associados hardware timers, que indicam se o dispositivo está ou não on-line. BITS podem também estar incorporados nos dispositivos e no software para aumentar a fiabilidade Interrupções espúrias e perdidas Interrupções não desejadas são chamadas de espúrias. Podem acontecer por ruído, descargas de alimentação, e outros factores. Interrupções perdidas podem ter causas semelhantes Tratamento de interrupções espúrias O método mais utilizado é incorporar redundância nas interrupções. Além de provocar uma interrupção, uma flag adicional é levantada para indicar uma interrupção válida. A rotina de tratamento da interrupção testa essa flag adicional, baixando-a e continuando o tratamento da interrupção se a flag estiver levantada. Em caso contrário, trata-se de uma interrupção espúria e a rotina deve terminar o mais rapidamente possível. 9-10

11 Interrupções perdidas Estas são mais difíceis de serem detectadas e corrigidas. Podem-se utilizar watchdog timers em software que são ligados ou desligados pela rotina em questão. Rotinas de mais alta prioridade e executando a uma taxa mais alta podem verificar essas posições de memória de modo a garantir que a frequência de interrupções é correcta. Caso não seja, a tarefa é reinicializada ou um erro indicado. 9-11