Вы находитесь на странице: 1из 34

1

CURSO DE ENGENHARIA CONTROLE E AUTOMAO SISTEMA DE TEMPO REAL TOLERANTES A FALHAS

DESENVOLVIMENTO DE SISTEMAS TOLERANTES A FALHAS

Prof. Pedro Saldanha 2012_2

Esta aula baseada Nas Notas de aula da UFPE


Fonte: http://www.cin.ufpe.br/~if682/20111/slidesAulas/22_Desenv SistemasCritico livro Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

CONFIANA DE SOFTWARE

Em geral os usurios de um sistema de software esperam que ele seja confivel; Para aplicaes no crticas podem estar dispostos a aceitar algumas falhas; Algumas aplicaes, contudo, tm requisitos muito altos de confiabilidade;

Exigem tcnicas especficas de engenharia de software.


Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

PARA ATINGIR A CONFIANA

Preveno de falhas
O sistema desenvolvido de modo que provadamente atenda sua especificao;

Remoo de falhas
Tcnicas de verificao e de validao so usadas para descobrir e remover falhas em um sistema antes que seja entregue;

Tolerncia a falhas
O sistema projetado de forma que as falhas no software entregue no resultem em defeitos em tempo de execuo;
Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

DIVERSIDADE E REDUNDNCIA

Redundncia
Parte do sistema ou de suas aes que no seriam necessrias se as falhas no existissem;

Diversidade
Prover a mesma funcionalidade de maneiras diferentes para que no falhem de forma anloga;

A adio de diversidade e de redundncia aumenta a complexidade;


Simplicidade e V & V extensivas podem ser uma rota mais eficiente para a confiana do software;
Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

EXEMPLOS DE DIVERSIDADE E REDUNDNCIA

Redundncia
Onde a disponibilidade crtica (por exemplo, em sistema de e-commerce), as empresas normalmente mantm servidores de backup e chaveiam automaticamente caso ocorram falhas.

Diversidade
Para fornecer resistncia contra ataques externos, diferentes servidores podem ser implementados com o uso de sistemas operacionais diferentes (por exemplo, Windows, Mac OS e Linux).

Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

SOFTWARE LIVRE DE FALHAS

Os mtodos atuais de engenharia de software permitem a produo de software livre de defeitos.


para sistemas relativamente pequenos;

Significa que o software atende especificao.


no significa que sempre executar corretamente;

O custo de produo de software livre de falhas muito alto.


mais barato aceitar falhas e pagar por suas consequncias;
Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

CUSTOS DE REMOO DE DEFEITOS

Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

PROCESSOS CONFIVEIS

Para assegurar um nmero mnimo de defeitos de software, importante ter um processo de software bem definido e repetvel; Um processo bem definido e repetvel aquele que no depende inteiramente de habilidades individuais, isto , podem ser realizados por pessoas diferentes; Para deteco de defeitos, claro que as atividades de processo devem incluir um esforo significativo dedicado verificao e validao.
Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

ATIVIDADES QUE AJUDAM NA REMOO DE FALHAS

Inspees de requisitos
descoberta de problemas com a especificao;

Gerenciamento de requisitos
acompanhamento de mudanas no projeto e implementao;

Verificao de modelos
anlise automtica de modelos;

Inspees de projeto e de codificao


listas de defeitos comuns para descoberta e remoo deles;

Anlise esttica
anlise de programas;

Planejamento e gerenciamento de teste


cobertura e rastreabilidade entre testes e requisitos;

Gerenciamento de configurao
incluso correta de componentes no sistema;

Arquiteturas adequadas
remoo localizada de erros;
Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

TOLERNCIA A FALHAS

Sistemas crticos devem ser tolerantes a falhas. Tolerncia a falhas significa que o sistema pode continuar em operao apesar da falha do software. necessrio complementar as tcnicas para remover falhas.

Abordagem muito usada na prtica.


Um sistema tolerante a falhas com relao a um dado modelo de falhas. Falha, erro e defeito.
Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

ETAPAS DE TOLERNCIA A DEFEITOS

Deteco de erros sistema deve detectar se um erro ocorreu (um estado incorreto de sistema); Avaliao de danos as partes do estado de sistema afetadas pelo erro devem ser detectadas; Recuperao de erros o sistema deve ir para um estado seguro estvel; Reparao de erros o sistema pode ser modificado para evitar recorrncia da falha; Tudo isso feito em tempo de execuo!

Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

DETECO DE ERROS

O primeiro estgio de tolerncia a falhas detectar se um erro ocorreu;

Envolve a definio de restries que devem ser mantidas em todos os estados legais, e a verificao do estado contra essas restries;

Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

RESTRIES DE ESTADO DE UMA BOMBA DE INSULINA

A dose de insulina a ser liberada deve ser sempre maior do que zero e menor do que alguma dose mxima nica definida; _ 0 _ __ A quantidade total de insulina liberada em um dia deve ser menor ou igual dose mxima diria definida;

_ __
Restries de estado que se aplicam bomba de insulina.

Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

Class RobustArray { //verifica se todos os objetos em um vetor de objetos atendem a alguma //restrio definida boolean [ ] checkState; CheckableObject [ ] theRobustArray; RobustArray (CheckableObject [ ] theArray) { checkState = new boolean [theArray.length]; theRobustArray = theArray; } //RobustArray public void assessDamage () throws ArrayDamageException { boolean hasBeenDamaged = false; for (int i=0; i <this.thewRobustArray.length; i ++) { if (! theRobustArray [i].check ()) { checkState[i] = true; hasBeenDamaged = true; } else checkState [i] = false; } if (hasBeenDamaged) throw new ArraydamagedException (); } //assessDamage } //RobustArray

Classe de vetor com avaliao de danos.

Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

AVALIAO DE DANOS

Analisa o estado do sistema para estimar a extenso da corrupo causada por um erro; Deve verificar quais partes do estado do sistema foram afetadas pelo erro; Geralmente baseada em funes validadas que podem ser aplicadas aos elementos de estado para avaliar se seu valor est dentro de uma faixa permitida;
Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

RECUPERAO DE ERROS

Recuperao por avano (forward error recovery) levar o estado do sistema para um novo estado livre de erros; Recuperao por retrocesso (backward error recovery) restaurar um estado anterior do sistema, livre de erros; A recuperao por avano especfica de aplicao A recuperao por retrocesso de erros mais simples e genrica; mas no se aplica a todos os casos;
Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

RECUPERAO POR AVANO

Corrupo de dados codificados adicionam redundncia aos dados codificados dados redundantes podem ser usados para reparao de dados corrompidos; Ponteiros redundantes quando ponteiros redundantes so includos em estruturas de dados, uma lista ou repositrio de arquivos corrompidos pode ser reconstituda se um nmero suficiente de ponteiros no estiverem corrompidos;
frequentemente usados para reparao de banco de dados e sistemas de arquivos;

Tratamento de excees nfase na estruturao;


Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

RECUPERAO POR RETROCESSO

Transaes so um mtodo popular mudanas no so aplicadas at que a computao seja completada; se um erro ocorre, o sistema deixado no estado anterior ao da transao;

Checkpoints locais usados pelo MS Office e pelo OpenOffice; Checkpoints distribudos peridicos baseados em logs;
Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

ARQUITETURAS TOLERANTES A FALHAS

Tcnicas de V & V no so capazes de ajudar a prever interaes entre o hardware e o software.

Mau entendimento dos requisitos pode significar que as verificaes so incorretas ou incompletas.
Se requisitos de confiabilidade so crticos, pode ser usada uma arquitetura especfica para apoiar tolerncia a falhas. Podem tolerar falhas de hardware e/ou de software.

Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

TOLERNCIA A FALHAS DE HARDWARE

Depende da redundncia modular tripla (TMR); Trs componentes idnticos replicados recebem a mesma entrada e tm suas sadas comparadas; Se uma sada diferente, ela ignorada e uma falha do componente simulada; Premissas bsicas: falhas de hardware decorrem de falhas de componentes (e.g. por desgaste natural) e no de projeto; falhas so excees e falhas simultneas so raras;
Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

CONFIABILIDADE DE HARDWARE COM TMR

Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

TMR E SOFTWARE

As suposies bsicas da TMR no valem para sistemas de software. no possvel simplesmente replicar os mesmos componentes quando eles tm falhas de projeto em comum; falhas simultneas de componentes seriam, portanto, virtualmente inevitveis;

Para ser tolerantes a falhas, sistemas de software devem incluir diversidade.


Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

DIVERSIDADE DE PROJETO

Verses diferentes do sistema so projetadas e implementadas de maneiras diferentes.


podem apresentar modos de falha diferentes;

Abordagens diferentes para projeto


implementao em linguagens de programao diferentes; uso de ferramentas e ambientes de desenvolvimento diferentes; execuo em diferentes sistemas operacionais; algoritmos e escolhas de projeto diferentes;
Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

ABORDAGENS PARA DIVERSIDADE DE PROJETO

Programao de N-verses a mesma especificao implementada em uma srie de verses diferentes por equipes diferentes; todas as verses calculam simultaneamente e a sada da maioria selecionada usando um sistema de votao; essa a abordagem mais comumente usada, por exemplo, em muitos modelos da aeronave comercial Airbus;

Blocos de recuperao uma srie de verses explicitamente diferentes da mesma especificao escrita e executada em sequncia. um teste de aceitao usado para selecionar a sada a ser transmitida.

Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

Preveno de falhas

A despeito de todos os testes e tcnicas de verificao, os componentes de hardware podero falhar. A abordagem feita pela preveno de falhas poder no ser bem sucedida quando a frequncia dos reparos ou a durao destes for inaceitvel, ou quando o sistema estiver indisponvel para manuteno e atividades de reparo. Um exemplo extremo dessa ltima situao a sonda no tripulada Voyager.

Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

PROGRAMAO EM N-VERSES

Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

PROGRAMAO EM N-VERSES

As verses diferentes de sistema so projetadas e implementadas por equipes diferentes. Admite-se que existe uma baixa probabilidade dessas equipes cometerem os mesmos erros. Existe evidncia emprica (1) de que as equipes: cometem com frequncia erros de interpretao de especificaes da mesma maneira e Escolhem os mesmos algoritmos em seus sistemas.

An Experimental Evaluation of the Assumption of Independence in multi-version programming


Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

BLOCOS DE RECUPERAO

Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

BLOCOS DE RECUPERAO

Foram o uso de vrios algoritmos diferentes.


reduzem a probabilidade de erros comuns;

Exigem um teste de aceitao.


difcil de elaborar de forma independente do algoritmo;

No sempre aplicvel a sistemas de tempo real, devido sua operao sequencial. Existe evidncia de que a programao em Nverses tambm no !
Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

PROBLEMAS COM DIVERSIDADE DE PROJETO

Equipes no so culturalmente diversas e tendem a resolver os problemas da mesma maneira. Erros caractersticos:
equipes diferentes cometem os mesmos erros; algumas partes de uma implementao so mais difceis que outras;
equipes tendem a cometer erros no mesmo lugar;

falhas na especificao;
so refletidas em todas as implementaes;

Esses problemas podem ser atenuados pelo uso de representaes mltiplas da especificao.
Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

EXEMPLOS DO QUE PODE ACONTECER

Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

Fonte: Engenharia de Software 8 edio captulo 20, de Ian Sommerville, 2006

34

Оценить