embedded

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.

Antes de me aventurar no domínio de sistemas embarcados, trabalhei com desenvolvimento de sistemas financeiros e de administração público-privada. Diversas vezes, ao perguntar por modelos arquiteturais do sistema, era informado que ele ~~era inexistente~~ estava desatualizado. Depois de algum tempo nesse contexto, me juntei ao grupo de profissionais que acreditam que um bom código fonte e algumas linhas de comentário são suficientes enquanto documentação.

A realidade no domínio de embarcados é bem diferente. Entidades que regulamentam sistemas que, em caso de falha, causarão danos à pessoas ou ao meio-ambiente (mais conhecidos como sistemas safety-critical), exigem que as empresas que constroem esses sistemas sigam rigidamente as etapas dos processos de desenvolvimento, e gerem artefatos de documentação extremamente detalhados.

No caso de sistemas aviônicos, o DO-178B – Software Considerations in Airborne Systems and Equipment Certification, por exemplo, define processos rígidos para (i) Planejamento, (ii) Desenvolvimento, (iii) Requisitos, (iv) Design, (v) Codificação e Integração, (vi) Teste e Verificação, (vii) Gerencia de configuração, e (viii) Gerenciamento de qualidade. Para se ter uma ideia geral das etapas e artefatos, recomendo uma olhada na seguinte apresentação: Introduction to Avionic Systems Development.

Um dos artefatos exigidos pelo DO-178B é a documentação arquitetural dos vários sistemas que compõe um sistemas aviônico: diagramas de componentes, diagramas comportamentais de tempo-continuo e de estados, dentre outros.

Alem de servir para documentação, esses modelos são usados como base para geração de código funcional. Essa historia de geração automática de código soava um tanto quanto utópica para mim também, até que, certa vez, o chefe da engenharia de uma grande empresa de aviação me disse que não confiava em códigos escritos por desenvolvedores, mas sim em códigos gerados a partir de especificações arquiteturais. Tentando entender o que se passava na cabeça desse cidadão, comecei a me inteirar mais sobre o assunto, e me convenci do quão poderosos mecanismos de geração de código podem ser quando utilizados apropriadamente. Para uma visão prática sobre o assunto, recomendo conhecerem um pouco sobre ferramentas como OpenArchitectureware e Acceleo.

Esses modelos são também peças-chave nos processos de garantia de qualidade, que vão desde testes baseados em modelos à técnicas formais de Model-Checking (sim, estou falando de assuntos relacionados a métodos formais. Eles são amplamente utilizados na industria aviônica). Toda essa amarração exigida pelas normas regulatórias implica em lentidão no desenvolvimento, e, quando não gerido adequadamente, pode gerar atrasos consideráveis na entrega do produto (ver caso do Boeing 787 Dreamliner). No entanto, empresas que desenvolvem esses produtos muitas vezes optam por atrasos aceitáveis no time-to-markt, mas assegurar que os produtos são feitos como manda a norma; caso contrário, o prejuízo financeiro será ainda maior, e a reputação da empresa desaparece.

Aí vai um recado para turma do “anti-modelos-e-apenas-código-escrito-é-o-que-conta”: Sistemas dessa natureza não podem falhar! Não existe possibilidade de reiniciar o sistema de navegação ou de propulsão de uma aeronave enquanto ela voa a 900Km/h a uma altitude de 30000 pés. O custo de voltar a versão de um software depois que ele já foi inserido em uma família de jatos tem um custo que pode comprometer o projeto como um todo. Não estamos tratando de sistemas web; também não quero dizer que estes sejam menos complexos ou de menor importância; digo apenas que as restrições de domínio são mais rígidas, levando em conta as catástrofes causadas se um sistema desse falhar.