Como é testado o software em sistemas críticos de vida ou morte?

Um avião, ao contrário de, por exemplo, um site, é um sistema em que qualquer falha em certos sistemas é completamente inaceitável, pois erros em, por exemplo, o monitoramento de vôo podem fazer com que o piloto automático não funcione e mergulhe. Obviamente, isso não acontece, uma vez que os brilhantes engenheiros da Boeing e da Airbus verificam o piloto automático para garantir que ele não decida repentinamente que um mergulho é uma manobra perfeitamente aceitável e segura. Ou talvez o computador trava, e os pilotos das aeronaves fly-by-wire mais recentes não conseguem mais pilotar o avião. Obviamente, existem vários procedimentos de segurança e redundâncias embutidos nesses sistemas para evitar acidentes (do software e da aeronave).

No entanto, por outro lado, é bastante óbvio que o software não é perfeito - o software de código aberto e o de código fechado travam regularmente, e apenas o programa "Hello World" mais simples não falha. Como os engenheiros que projetam os sistemas de software nas indústrias aeronáutica, médica e outras indústrias de vida ou morte conseguem testar seus softwares para que eles não falhem (e se falharem, pelo menos falharão graciosamente)?

_{Espero desesperadamente que você não vá: "Ah, eu trabalho na Boeing / Airbus / (alguma outra empresa) e não é! Divirta-se na sua próxima visita ao hospital / vôo".}

Eu trabalhei muito em controles industriais. Não precisa estar em uma indústria gloriosa como aeroespacial. Quase todas as máquinas industriais têm energia potencial suficiente para causar ferimentos graves ou morte. Eu estive por perto quando as pessoas ficaram feridas. Se você passa a maior parte do tempo na mesa de um escritório, provavelmente ficará surpreso com o quão perigosa a maioria dos trabalhos de fábrica pode ser (e certamente era até recentemente). Agora, temos melhores métodos de proteção da máquina. Veja como funciona na prática (embora varie de jurisdição para jurisdição):

Existem normas da OSHA nos EUA e diretrizes semelhantes (geralmente mais rigorosas) na UE. Geralmente, isso exige que você faça uma análise do risco. Isso significa que você faz uma lista de todos os perigos e depois os categoriza, levando em consideração coisas como a frequência com que uma pessoa seria exposta ao risco, quão fácil é evitá-lo (depende da velocidade etc.) e quais é a severidade do resultado (corte, amputação, morte etc.).

Muita análise tem a ver com a proteção de perigos. Se você colocar uma gaiola grande em torno da máquina e apertá-la com força, ela será considerada segura se os componentes da máquina não puderem violar a proteção. Se você precisar de uma ferramenta para entrar, isso é considerado uma tarefa de manutenção, e as pessoas de manutenção devem ser treinadas em como trabalhar com segurança em uma máquina. Na realidade, no entanto, a maioria das máquinas precisa de interação regular com os operadores, por isso temos que colocar portas de acesso nas proteções ou cortinas de luz, etc. Essas portas e cortinas de luz precisam ser monitoradas e a potência dos riscos aos quais o operador está se expondo. deve ser desligado de maneira "confiável de controle".

Com base nessa análise, o risco é colocado em várias categorias. Uma escala de classificação comum é da categoria 1 à categoria 4 (com base na norma EN 954-1). Com base nessas categorias, você é legalmente obrigado a fornecer um certo nível de proteção e segurança da máquina.

A categoria 4, por exemplo, exige que:

Uma única falha em cada uma dessas partes não causa a perda da função de segurança.

A falha única é detectada com ou antes da próxima solicitação à função de segurança ou, se isso não for possível, um acúmulo de falhas não pode causar a perda da função de segurança.

Isso pode ser difícil de conseguir na prática, mas é simplificado pela disponibilidade de componentes padrão certificados para a Categoria 4. Por exemplo, um componente comum nesses sistemas é um relé de segurança. Estes são mais do que apenas relés mecânicos:

• Eles são projetados para monitorar canais de entrada redundantes duplos; portanto, se você possui um sensor que detecta uma condição de falha (como uma porta de proteção aberta), ele normalmente possui dois contatos com circuitos redundantes. O relé monitora os dois canais e, se um deles abrir, ele desligará a energia dos atuadores, mas se os dois não desligarem ao mesmo tempo, entrará em uma condição de falha e a máquina não poderá ser reiniciada até que seja reparada. .
• O relé também usa pulsos elétricos nessas linhas e usa esses sinais para monitorar fios cruzados ou em curto, para detectar uma falha na fiação.
• No lado da saída, ele usa um conjunto de circuitos duplos para acionar as bobinas de saída; portanto, se um falha na condição "ligado", o outro deve impedir que a saída seja energizada. Além disso, eles são monitorados e, se uma falha for detectada, isso impede a operação. As bobinas são, na verdade, relés de dupla força, o que significa relés físicos redundantes na saída, além de garantir que os contatos de cada relé sejam fisicamente ligados entre si, para que um contato, digamos 4, não possa ficar preso sozinho. Estes também são monitorados.
• Ele também inclui uma entrada para monitorar um contato auxiliar normalmente fechado da carga que você está controlando. Se desligar a saída, ele deverá ver o contato normalmente fechado engatando, o que significa que valida a desativação do contator do motor, ou o que quer que fosse, antes de poder operar novamente na condição ligada.

Como você pode ver, esses são dispositivos complicados. Os custos típicos estão na faixa de US $ 200 a US $ 600 para cada relé de segurança. Obviamente, há software nesses dispositivos. Para obter a certificação do seu relé de segurança, normalmente é necessário seguir um design como este:

• Dois processadores redundantes, normalmente provenientes de diferentes fornecedores, com base em projetos diferentes.
• O código em execução em cada processador deve ser desenvolvido por duas equipes que trabalham em condições isoladas. Isso evita que um único erro de software seja um único ponto de falha.
• A saída de ambos os processadores tem que concordar ou então o relé de segurança falha.

Depois de projetar seu sistema de segurança para sua máquina, usando componentes com classificação de segurança, é necessário que o projeto seja revisado e carimbado por um engenheiro profissional. Então você constrói a máquina. Então o P.Eng. revisará a construção da máquina, certificando-se de que foi construída de acordo com o projeto. Eles o documentarão e farão alguns testes para garantir que esteja funcionando conforme o esperado. Isso é chamado de revisão pré-início (PSR) e não é feito em todas as jurisdições. Depois que o PSR passar, você poderá ter um operador executando a máquina.

Nos últimos anos, houve algumas revoluções nos sistemas de segurança. Por um tempo, ninguém confiava na transmissão de dados de segurança por uma rede; portanto, o que normalmente é chamado de "sistemas de E / S distribuídos", como DeviceNET e EtherCAT, não era permitido na parte de segurança do sistema. No entanto, protocolos recentes agora permitem que dispositivos de segurança passem por essas redes industriais. Os protocolos usam mensagens com registro de data e hora e processamento redundante duplo nas duas extremidades da conexão.

Os relés de segurança estão lentamente seguindo o caminho do dodo bird, substituído por CLPs de segurança mais complicados, que são como uma maneira de construir a lógica de segurança em uma linguagem de diagrama de blocos de funções. Novamente, esses CLPs de segurança usam tudo redundante. Quando o programa é aprovado, antes da máquina ser colocada em serviço, o P.Eng. irá carimbar o programa e o programa / CLP será bloqueado com uma senha. Também é necessário um hash do programa e esse hash é registrado na documentação (é o que o P.Eng. Está realmente estampando).

Agora que você projetou seu sistema de segurança, a lógica que você escreve para controlar a própria máquina pode ser muito fácil. Os programadores freqüentemente batem em máquinas, causando milhares de dólares em danos, mas pelo menos ninguém será ferido.

Há um movimento sério em direção à verificação formal, em vez de testes funcionais aleatórios.

Agências governamentais como a NASA e algumas organizações de defesa estão gastando cada vez mais nessas tecnologias.

Eles ainda são um PITA para o programador médio, mas geralmente são mais eficazes no teste de sistemas críticos.

Há também uma tendência de experimentar mais técnicas da academia, para validar código multithread.

Depende do que é o software. Por exemplo, em aviões, geralmente há processamento com redundância dupla para sistemas críticos; no caso extremo, podem ser utilizados dois projetos de hardware diferentes e duas peças de s / w desenvolvidas de forma independente, uma para executar em cada uma. Ambos calculam e se cruzam. Isso não é infalível e é extremamente caro.

Quando se trata de testes de sistemas de aeronaves, há uma série de testes - o teste de sistemas relacionados a voos leva meses e, se você fizer alguma alteração, é necessário executar uma série de re-testes. Isso geralmente é feito em um simulador, que pode realmente estar cheio de peças reais da aeronave (por exemplo, cockpit), digamos, com um motor simulado ou similar. Como você pode imaginar, isso também é terrivelmente caro de construir. As alterações são avaliadas em relação a um programa formal de teste e, em seguida, executadas em uma aeronave real em voos de teste. Ao longo do caminho, coisas como testes "funcionais perturbados" são executados, é aqui que o item alterado pode fazer suas coisas normais e tudo é verificado / testado para verificar se não houve efeito prejudicial. Isso também custa muito dinheiro e pode levar semanas.

Conheço um exemplo em que era necessária uma mudança muito simples em um sistema de vôo - tão simples que você ficaria surpreso com o quão pequeno. No entanto, o novo teste levaria mais de 3 meses e custaria algo como US $ 1 milhão.

Quando você entra na área médica, há toda uma série de obstáculos regulatórios relacionados não apenas aos testes, mas também aos processos e documentação de desenvolvimento.

Todos esses campos são um grande avanço em relação a lugares que resumem um pouco do código PHP de um site. É lento, meticuloso, difícil, chato, tedioso, meticuloso e muito caro. Pegue seus custos normais de desenvolvimento / teste e multiplique por cerca de 100 e você está chegando perto da marca.

Para o software de ônibus espacial da NASA, leia They Write the Right Stuff . Para o FDA (US Food and Drug Administration) leia leia este

Como você já tem respostas ótimas e informativas suficientes, aqui está minha opinião.

É simples - o primeiro teste é sempre realizado pelos próprios programadores. Ele tende a manter baixa a contagem de bugs e garante que apenas os programadores de qualidade sejam mantidos na folha de pagamento.

O software essencial para a vida não é testado com nenhum outro padrão que não seja o "parece funcionar" , como é feito em todo o lugar.

Todo o investimento vai para o que parecia funcionar antes ou para projetos que permitam que não programadores produzam software melhor .

ps Não há comentários sobre o primeiro -1, mas ficaria feliz em aceitar -1cada referência que contrarie minha declaração.

Posso marcar +1 para cada referência que encontro a softwares críticos que não estão sendo bem projetados ou testados? Simson Garfinkel documenta dez casos em um artigo sobre WIRED.

Não há uma resposta para todos os casos. Cabe ao fabricante individual decidir como projetar e testar seu software. Mas todo o processo de desenvolvimento de software deve estar em conformidade com as especificações formais.

Por exemplo, ao criar software para dispositivos médicos, você deve seguir a norma IEC 62304 para software para dispositivos médicos. (Infelizmente, só posso vincular à wikipedia, pois não é gratuito). Praticamente todos os países do mundo exigem que esse padrão seja seguido.

A rigidez desses requisitos depende do risco de danos. Por exemplo, um dispositivo de suporte à vida teria o maior risco de dano (morte certa ou falha do sistema), enquanto um sistema que trabalha com diagnóstico de doença tem um risco menor (morte possível se uma doença terminal não foi diagnosticada corretamente se o sistema falhar).

Mas o que isso diz basicamente é que deve haver uma rastreabilidade dos requisitos para o software. Você deve executar verificações da unidade de software. Isso não especifica o que é a verificação. Podem ser testes de unidade, podem ser revisão de código. Para os dispositivos de maior risco, você deve revisar manualmente as interfaces entre as unidades de software (tanto quanto eu entendo e lembro). E, claro, muitas outras regras. Ah, e você deve escrever muita documentação para documentar seu trabalho.

O padrão não proíbe o desenvolvimento ágil, embora ao ler pareça ter sido escrito com o desenvolvimento em cascata em mente.

Não conheço outras áreas do desenvolvimento de software, como aviação, trens, carros etc. Mas suponho que existam outras diretrizes formais semelhantes.

Muitas técnicas são usadas, incluindo, entre outras:

• projeto formal e / ou validação
• rigorosos padrões de codificação, evitando programação sofisticada, como alocação dinâmica de memória
• engenheiros de qualidade muito exigentes
• manys técnicas de análise estática, como revisão de código, árvores de falhas, FMECA, ...

Mas a técnica número um é:

• TESTANDO

O software de uma espaçonave precisa de mais esforço para testar do que para projetar e codificar em primeiro lugar.

As aeronaves passam por vários anos de testes de voo, onde o avião é levado a situações extremas. Isso testa não apenas a estrutura física, mas também o software.

Há um artigo "Perfect software" de Jack Ganssle no EETimes de 01/03/2009 às 00:00 EST. Alguns pontos de lá:

• "Teoricamente, o software é o único componente que pode ser perfeito, e esse sempre deve ser o nosso ponto de partida". - Isso é dito por Jesse Poore. Seguindo sua página na web, você descobrirá como o software perfeito pode ser fabricado sem muito mais custo do que o software normal.
• Existem fornecedores industriais de sistemas operacionais altamente confiáveis. O artigo mencionava Mircrium e Green Hills. Após a página da Web da Micrium, há uma lista de padrões para certificações. Esses devem ser os processos e regras que a indústria segue. Isso se baseia na validação formal, mas se desvia muito da teoria.

Curiosamente, em relação ao software comercial, os dados coletados pela Capers Jones sugerem que "o software em geral possui uma eficiência de remoção de defeitos (a porcentagem de erros removidos antes do envio) de 87%. O firmware obtém 94% muito melhores". Para mim, nada disso é quase perfeito. O artigo mencionado anteriormente indica que a equipe de ônibus espaciais da NASA alcançou uma taxa de remoção de bugs de 99%, mas o custo é de 35 milhões por ano para cerca de 400 mil linhas de código.

Um artigo mais interessante "Software para sistemas confiáveis", do mesmo autor em 1/11/2009, parece ser mais relevante. Pode ser resumido assim:

• Quanto ao processo de desenvolvimento, o setor seguiu o DO-178B ou IEC61508. Ele enfatiza os testes com maior cobertura. Mas pouca evidência pode ser encontrada sobre a eficácia disso.
• Uma autoridade de certificação, o Comitê de Sistemas de Software Certificadamente Confiáveis, publicou um livro intitulado "Software para Sistemas Confiáveis ​​- Evidência Suficiente". É uma boa referência.
• O livro basicamente pede três coisas: [1] Faça regras explícitas para testes de confiabilidade. [2] Testes contra as regras, mas também garantem que os testes sejam compreensíveis por clientes ou reguladores normais, com uma magnitude menor que o tempo gasto pelos desenvolvedores. [3] Certifique-se de que os especialistas em engenharia de software e o domínio do problema estejam desenvolvendo e testando.
• O fornecedor do software deve se comprometer com uma garantia ou outras soluções para qualquer falha de software.
• Use um idioma seguro, especificamente não o C. SPARK é sugerido.
• A abordagem de design para contrato é um dos pontos fortes do SPARK. O projeto por contrato é uma tecnologia importante para incorporar testes em todas as chamadas de função / método e sempre executá-lo em tempo de execução. Mais do que uma simples afirmação () nos velhos tempos, o contrato também pode incorporar testes contra a intenção estrutural e garantir que nenhuma violação seja escorregada posteriormente no ciclo de manutenção, quando os desenvolvedores originais passaram a outros projetos. Existem evidências de que o design do contrato produziu produtos de software muito confiáveis. O SPARK e suas ferramentas podem ser usadas para ajudar a gerar casos de teste de certificação para simplificar o processo de certificação.

Segundo minha memória, a HP praticou o projeto por contrato há quase uma década. Com uma equipe pequena, 500 mil linhas de código, apenas dois bugs relatados após a entrega. Muito impressionante.

Na minha opinião, um software confiável ou perfeito só pode ser alcançado se o custo não for proibitivamente alto. Estruturas ou automações é um must-have.

Eles geralmente têm um bloqueio de hardware usado como segurança contra falhas.

Por exemplo, os designs padrão de caixas de texto ruins para robôs assassinos sempre vêm com um interruptor de interrupção: P

Cada setor possui seu próprio conjunto de agências reguladoras que possuem requisitos de teste e documentação para hardware e software relacionados à segurança. Considere este PDF do Underwriters Laboratory (UL) que apresenta o padrão UL 1998: http://www.ul.com/global/documents/offerings/industries/hightech/software/UL_softwareconformityassessment.pdf

Há referências nesse documento a muitos outros relacionados da UL, CSA e IEC.

Normalmente, o software relacionado à segurança terá circuitos de hardware redundantes ou será necessário ter outros recursos de controle redundantes para garantir operação segura e modos de falha seguros.