Sistemas safety-critical são aqueles que, em caso de falha, podem causar danos severos ou morte de indivíduos e/ou danos significativos ao meio ambiente. Esses sistemas estão presentes em diversos equipamentos que fazem parte do nosso cotidiano, como, por exemplo, carros (e.g. sistema de controle de frenagem, controle de piloto automático, ajuste de tração), aviões (e.g. sistema de controle de porta, sistema de ajuste de rota, navegação), e equipamentos médicos (e.g. sistema de ajuste de radiação em maquinas de ressonância magnética, sistemas de gatilho de marca-passo).

 Você já se perguntou como os requisitos desses sistemas são elicitados e documentados? As regras para tratar requisitos de safety são um tanto quanto diferentes das praticas “tradicionais” de elicitição de requisitos. Para que os produtos sejam homologados, e então liberados para o mercado, os equipamentos tem que ser desenvolvido seguindo praticas descritas em padrões ISO/IEEE (e.g. ISO 26262, ISO 14971). Esses padrões cobrem práticas que vão da especificaçao até à implantação do sistema. Nesse post vamos tratar apenas dos itens que são comuns à fase de requisitos de sistemas safety-critical.

Processos de elicitação de requisitos de safety, em geral, seguem 5 passos:

1 – Identificação do ítem: Considerando o domínio automotivo, o item não é o carro em si; mas um sistema que, ao final, irá compor o automóvel, como, por exemplo, o sistema de controle de tração, o sistema de piloto automático, etc.

2 – Análise de riscos e ameaças (hazard and risk analysis): Nessa fase são analisados e documentados todos os riscos inerentes àquele sistema. Um exemplo de hazard é “Piloto automático não desativar quando requisitado pelo motorista”. A cada um desses eventos é associado um Safety Integrity Level ou SIL (isso é assunto para outro post), que corresponde a uma indicação do quão catastrófico esse evento pode ser caso aconteça.

3 – Estabelecer Safety Goal: Cada evento ameaçador é associado a um safety goal ou, traduzindo literalmente, meta de segurança. Por exemplo, o safety goal associado ao hazard “Piloto automático não desativar quando requisitado pelo motorista” pode ser “Piloto automático precisa ser desativado quando requisitado pelo motorista”.

4 – Requisitos funcionais de safety: Para cada safety goal, uma série de requisitos funcionais de safety são derivados. Exemplo: “Ao pisar pedal de freio, piloto automático deve ser desativado”.

5 – Requisitos técnicos de safety: Cada requisito funcional de safety deve ter detalhes técnicos de como ele será implementado. Essa especificação deve conter detalhes dos blocos funcionais que vão implementar a função (hardware e/ou software).

No processo de certificação do produto, todos os artefatos e documentos associados são analisados e avaliados quanto a consistência, detalhamento, de modo a julgar a eficácia e eficiência do produto. Uma vez homologado, o produto é liberado para o mercado.

Processos de engenharia de safety são muito complexos e rígidos. Muitas outras técnicas são usadas para assegurar que esses sistemas não falharão. E, caso falhem, que o efeito seja o menos trágico possível.

No próximo post irei escrever sobre o que vem sendo feito no Brasil na área de sistemas safety-critical; mais especificamente no que diz respeito a software embarcado em equipamentos médico-hospitalares.