N-Version Programming Paulo Henrique Zanin

Apresentação em tema: "N-Version Programming Paulo Henrique Zanin"— Transcrição da apresentação:

1 N-Version Programming Paulo Henrique Zanin

2 Roteiro N-Version Proramming: A Foult-Tolerance Approach to Reliability of Software Operation. (Liming Chen and Algirdas Avizienis)‏ Software Reliability Measureents in N-Version Software Execution Environment. (Michael R. Lyu)‏ Managing Redundancy in CAN-based networks supporting N-Version Programming. (Julián Proenza, José Miro-Julia and Hans Hansson)‏

3 N-Version Programming: A Foult-Tolerance Approach to Reliability of Software Operation (Liming Chen and Algirdas Avizienis)

4 Introdução Programação n-versões é um método para prevenção de defeitos na qual são criado vários módulos contendo a mesma funcionalidade. Em 1966, em um seminário da IEEE, ocorreu o primeiro debate sobre o viabilidade desta técnica. Em 1975, foi criado um projeto de pesquisa, intitulado N-Version Programming, para realmente verificar a viabilidade desta abordagem.

5 Programação N-Versões
Definida como a geração independente de duas ou mais funcionalidade equivalentes no mesmo programa. A junção destas n-versões é chamada de unidade de software; Programação independente, onde distinto esforços são empregados a programação destas versões.

6 Programação N-Versões
Especificação inicial deve possuir: A funcionalidade que todas as versões devem possuir; O formato dos dados para a comparação e o mecanismo de sincronização destes dados; Os pontos de checagem dos dados; A forma de escolha do resultado (votação ou comparação).

7 Programação N-Versões
Para a criação de uma unidade de software com N-Versões é necessária a criação de um supervisor (driver). Este supervisor irá coordenar a execução destas versões e após coordenar o recebimento dos resultados para votação. Cada versão retorna um vetor, o qual possuí os valores a serem votados, além de informações refentes a execução de cada versão.

8 Programação N-Versões
Mecanismo de sincronização: Serve para as versões indicarem ao supervisor que seus resultados estão prontos; Serve também para o supervisor evitar a votação dos resultados ocorra antes que alguma versão não tenha enviado seus resultados;

9 Programação N-Versões
Após o recebimento dos resultados de cada versão o supervisor deverá levar em consideração: Se todos as versões entregaram o resultado dentro do tempo especificado; Se os resultados concordam ou discordam;

10 Comparação Apresenta uma comparação realizada entre a Programação N-Versões e com a abordagem de blocos de recuperação. Blocos de recuperação possuí vantagem na evolução do sistema. Desvantagem é que um bloco de recuperação somente vai ser executado após a obtenção de uma saída incorreta de outro bloco;

11 Comparação Devido a isto, a abordagem da programação N-Versões oferece algumas vantagens; Não há atraso na operação, pois os blocos são executados em paralelos, havendo assim um mascaramento do defeito;

12 Implementação – Voto Inexato
Concepção de diferentes processos de votação para tratar de resultados não idênticos Para cálculos numéricos dois tipos de desvios podem aparecer nos resultados: Esperado: que pode acontecer pela representação inexata de hardware ou devido ao informações especificas do algoritmo; Inesperado: ocorre devido a uma concepção inadequada, ou pela mal implementação do algoritmo, ou ainda pelo mal funcionamento do hardware.

13 Implementação – Voto Inexato
Existem duas alternativas que podem ser aplicadas neste voto inexato: Adaptativa: Atribuir pesos aos resultados recebidos; Com isso a intenção é fornecer resultados aceitáveis e diminuir o efeito destes resultados discordarem; Resultado desta função gera um ruído; Caso esta saída servir de entrada para outras computações este ruído poderá causar problemas sérios.

14 Implementação – Voto Inexato
Não-adaptativa: Determinar um intervalo permitido para estes resultados. Desvantagem: Este intervalo é difícil de ser determinado dinamicamente para cada instância de votação. Não existe uma estratégia de voto inexato que possa ser aplicado para todos os casos de forma satisfatória.

15 Viabilidade RATE: Também aplicada com 3-versões. MESS:
Esta técnica foi aplicada com 3-versões. Mostrou-se relativamente simples, podendo ser generalizada para outras aplicações similares.

16 Esta técnica é relativamente simples. Eficaz na prevenção de defeitos.
Conclusão Esta técnica é relativamente simples. Eficaz na prevenção de defeitos.

17 Software Reliability Measureents in N-Version Software Execution Environment. (Michael R. Lyu)‏

18 Introdução NVP é uma abordagem que esta ganhando bastante aceitação em áreas de aplicações criticas. Mas ainda há muitas questões controversas quanto a eficácia desta técnica no aumento de confiabilidade. Neste artigo são apresentadas as N-versões de um projeto obtido a partir de seis linguagem diferentes, e avaliar aspectos de confiabilidade dos resultados obtidos.

19 Introdução As linguagens de implementação destas N-versões são ADA, C, Pascal, Modula-2, Prolog, T. A aplicação para a qual estas implementação foi desenvolvida é um piloto automático para a aterrissagem de aviões comerciais.

20 Introdução

21 Testes Foram realizados três fases de testes, testes de unidade, integração e de aceitação. Durante o ciclo de vida deste projeto 93 falhas foram encontrada. Algumas falhar ocorridas foram devido ao mal entendimento das especificações iniciais, por parte dos programadores. As linguagem de programação orientadas a objetos parecem herdar menos defeitos do que outras linguagens de programação.

22 Testes

23 Sistema de simulador de vôo

24 Conclusão Ao final de todas estas execuções pode-se realmente demonstrar a potencial capacidade de melhoria na confiabilidade de um software desenvolvido a partir da programação com n-versões.

25 Managing Redundancy in CAN-based networks supporting N-Version Programming (Julián Proenza, José Miro-Julia and Hans Hansson)‏‏

26 Introdução Implementação de Miro-Julia:
As versões são executadas em computadores distintos. Quando cada uma das versões concluí seu processamento envia broadcast o resultado. Estes resultados são enviados através da rede por um equipamento especial denominado NVXP (N-Version Executivo Processor). O qual é anexado em cada computador para gerenciar esta comunicação.

27 Introdução

28 Introdução Propõem eliminar a inconsistência citada:
Pelo fator baixo custo requerido, optou-se por utilizar computadores normais onde as versões são executas. Devido ao custo, a confiabilidade e ao desempenho em tempo real, eles utilizaram Control Area Network (CAN) protocol. Além destas alterações no hardware também foi criado um novo software para o gerenciamento de redundância desta arquitetura. Desenvolvem um novo projeto para o NVXP, chamado de RCMB (Redundancy and Communication Management Boards).

29 Arquitetura Proposta Limites de contenção de erros:
É um mecanismo que procura impedir que uma falha ocorrida em um determinado nó não se propague, impedindo que ocorram erros. Controller Area Network (CAN) protocol, pois oferece uma transmissão confiável. É utilizada a topologia de barramento devido a vantagem de reduz o custo e facilidade de extensibilidade da rede.

30 Arquitetura Proposta

31 Conclusão A partir destas mudanças realizadas foi possível solucionar a inconsistência que o projeto do Miro-Julia possuía. Com esta abordagem proposta diminui-se possíveis ocorrências de falhas de comunicação.

32 N-Version Proramming Paulo Henrique Zanin