Desenvolvimento de Software para Sistemas Críticos de Segurança Baseado em Requisitos
Sistemas computacionais estão cada vez mais presentes em nosso cotidiano, assumindo controle de atividades de alta criticidade, como procedimentos médicos, transporte de pessoas, sistemas aeroespaciais e de defesa, e gerenciamento de energia. Em muitas dessas situações, a confiabilidade e a segurança desses sistemas são primordiais, pois falhas podem ter consequências devastadoras para vidas humanas. Para mitigar esses riscos, o conceito de segurança funcional e seus respectivos padrões foram estabelecidos há décadas, visando incorporar e gerenciar os aspectos de segurança intrínsecos ao desenvolvimento de hardware e software.
1. Introdução
A segurança funcional refere-se ao processo de garantir que os sistemas operem corretamente em resposta às suas entradas, atendendo de forma eficaz aos requisitos funcionais especificados. Isso é particularmente crucial em setores como automotivo e industrial, onde falhas de sistema podem resultar em sérios incidentes de segurança. Os padrões mais relevantes para essas áreas são a IEC 61508 e a ISO 26262, respectivamente.
1.1. Segurança Funcional
A segurança funcional é o pilar que sustenta a operação confiável de sistemas em cenários de risco. Ela se concentra em garantir que, mesmo diante de falhas, o sistema reaja de maneira previsível e segura, minimizando o potencial de danos. A aderência a padrões como a IEC 61508 e a ISO 26262 é um requisito indispensável para sistemas que operam em ambientes onde a segurança humana é uma preocupação.
1.2. Padrão IEC 61508
A IEC 61508 é um padrão fundamental de segurança funcional aplicável a todas as indústrias. Ela estabelece métodos para a aplicação, projeto, implantação e manutenção de sistemas elétricos/eletrônicos/eletrônicos programáveis (E/E/PE ou E/E/PES) relacionados à segurança. O objetivo principal é assegurar que qualquer sistema relacionado à segurança opere corretamente ou falhe de maneira previsível e segura.
1.3. Padrão ISO 26262
A ISO 26262 é uma adaptação da IEC 61508, desenvolvida especificamente para atender às necessidades do setor automotivo em relação a sistemas elétricos e/ou eletrônicos (E/E) em veículos rodoviários. Este padrão é amplamente adotado pelos principais fabricantes de automóveis. Ele oferece uma abordagem estruturada para a avaliação da segurança funcional, categorizando as funções do veículo com base em seu impacto na segurança. Cada função é atribuída a um Nível de Integridade de Segurança Automotiva (ASIL - Automotive Safety Integrity Level), que dita o rigor das medidas de segurança. Níveis ASIL mais altos exigem mecanismos de segurança mais robustos, como redundância, detecção de falhas e reações de falha segura. Esse método sistemático garante o funcionamento confiável dos sistemas do veículo e previne acidentes, mitigando riscos com mecanismos de segurança adequados.
2. Processo de Desenvolvimento
Na indústria automotiva, o ciclo de vida do desenvolvimento de produtos abrange desde a concepção do veículo, passando pelo projeto de sistemas, hardware e software, até a implementação, verificação e validação de cada fase. Este processo é conhecido como Modelo V. Essa abordagem sistemática garante que todos os requisitos necessários sejam definidos antes do início do desenvolvimento, assegurando a completa especificação e validação de cada aspecto do sistema. Este artigo foca nas fases de concepção e projeto do desenvolvimento de software dentro do Modelo V.
2.1. Modelo V
O ciclo de desenvolvimento do Modelo V é uma extensão do modelo cascata. As etapas após a fase de codificação se curvam para cima, em vez de seguir linearmente para baixo, formando uma característica forma de 'V'. As relações entre cada fase de desenvolvimento e sua fase de teste correspondente são claramente representadas. Análises de segurança devem ser realizadas em cada etapa para identificar desvios ou dependências que possam levar a situações perigosas ou violar requisitos de segurança definidos em fases anteriores do ciclo de desenvolvimento.
O Modelo V, conforme ilustrado na Figura 1 (referência ao diagrama original), demonstra o processo de desenvolvimento de software de acordo com a ISO 26262, com ênfase nas fases de concepção, projeto, teste e verificação. Os eixos horizontais representam o tempo ou a conclusão do projeto, enquanto os eixos verticais indicam o nível de abstração.
As principais etapas das fases de concepção e projeto, desde a Análise de Perigos e Avaliação de Riscos (HARA) até a especificação de requisitos de segurança de software (SSR), são detalhadas na Figura 2 (referência ao diagrama original).
2.2. Conceito Funcional de Segurança
A Conceituação Funcional de Segurança (FSC - Functional Safety Concept) é a etapa final e o resultado da fase de concepção, de acordo com a ISO 26262. Ela envolve a definição do que o sistema deve fazer, a identificação de funções críticas, a avaliação dos riscos associados a cada função e, subsequentemente, o estabelecimento de objetivos ou requisitos de segurança para mitigar esses riscos. Todas essas atividades são passos anteriores do processo que utilizam métodos estruturados, como a definição do item e a análise HARA, conforme o padrão. A fase de concepção estabelece a base para a abordagem sistêmica do padrão, definindo os limites dentro dos quais ocorrerão as atividades subsequentes de projeto e validação.
Os aspectos chave da fase de concepção incluem:
- Definição das Funções do Sistema: Identificar o que o sistema deve realizar e suas funções críticas.
- Avaliação de Riscos: Avaliar os perigos potenciais associados a cada função, considerando sua severidade e probabilidade de ocorrência. Determinar os níveis ASIL.
- Estabelecimento de Requisitos de Segurança: Definir objetivos ou medidas de segurança com base nos riscos avaliados, garantindo a operação segura do sistema sem falhas perigosas.
2.3. Conceito Técnico de Segurança
A Conceituação Técnica de Segurança (TSC - Technical Safety Concept) é o processo de derivar requisitos técnicos de segurança (TSR - Technical Safety Requirements) específicos a partir dos requisitos funcionais de segurança (FSR - Functional Safety Requirements) do sistema e projetar a arquitetura do sistema com base neles para atender à Conceituação Funcional de Segurança. Este processo envolve a adição e integração de mecanismos de segurança adicionais na arquitetura do sistema, necessários para atender aos requisitos funcionais de segurança, e a atualização da arquitetura inicial da fase FSC. Isso inclui mecanismos como detecção, prevenção e mitigação de falhas. Os TSRs devem ser alocados na arquitetura do sistema em alocações específicas ou em elementos individuais (hardware, software).
2.4. Requisitos de Segurança de Software
Os Requisitos de Segurança de Software (SSR - Software Safety Requirements) são requisitos de baixo nível, implementáveis em software, que são derivados de um nível menos detalhado de TSRs alocados ao software. Os principais objetivos da fase SSR são:
- Derivar SSRs a partir de TSRs e da arquitetura do sistema.
- Definir funcionalidades e propriedades de software relacionadas à segurança.
- Refinar os requisitos de interface entre hardware e software.
Outras características e propriedades essenciais dos SSRs incluem:
- Claros, precisos, inequívocos e compreensíveis.
- Implementáveis, verificáveis, rastreáveis e sob controle de configuração.
- Rastreáveis aos TSRs.
- Garantindo baixa complexidade.
2.5. Projeto da Arquitetura de Software
O projeto da arquitetura de software é a última etapa da fase de projeto antes do início da implementação e é essencial para garantir que todos os SSRs possam ser implementados com o ASIL exigido. Uma arquitetura de software bem projetada deve ser compreensível e consistente, sem erros de projeto internos, simples e clara, com comportamento previsível, além de ser verificável e testável. Todos esses atributos podem ser alcançados se a arquitetura for construída de forma modular. A Figura 3 (referência ao diagrama original) apresenta uma arquitetura modular bem projetada.
Os aspectos estáticos chave do projeto da arquitetura incluem:
- Estrutura do software, incluindo seus níveis hierárquicos.
- Interfaces externas dos componentes de software.
- Restrições nas fronteiras da arquitetura.
- Tipos de dados e suas características.
- Variáveis globais.
Os aspectos dinâmicos chave do projeto da arquitetura incluem:
- Fluxo de dados através de interfaces e variáveis globais.
- Fluxo de controle e paralelismo de processos.
- Cadeia funcional de eventos e comportamento.
- Sequência lógica de processamento de dados.
2.6. Rastreabilidade
De acordo com a ISO 26262, a rastreabilidade de requisitos é necessária para alcançar os requisitos de segurança esperados do sistema durante o processo de desenvolvimento, a fim de garantir e demonstrar isso. A Figura 4 (referência ao diagrama original) ilustra a rastreabilidade de requisitos esperada desde a fase de concepção, passando pela fase de projeto, até o início da implementação.
A rastreabilidade refere-se a:
- Cada fonte de requisito no próximo nível hierárquico superior.
- Cada requisito derivado no próximo nível hierárquico inferior.
- Especificação de verificação.
A rastreabilidade também suporta:
- Eficiência da análise de impacto.
- Consistência entre requisito, sua implementação e verificação.
- Realização de medidas de confirmação, como a avaliação de segurança funcional.
3. Exemplos
A tabela abaixo ilustra a relação entre um Objetivo de Segurança, Requisitos Funcionais de Segurança (FSR), Requisitos Técnicos de Segurança (TSR) e Requisitos de Segurança de Software (SSR) para um sistema ADAS (Advanced Driver-Assistance Systems).
| Categoria | Descrição |
|---|---|---|
| Objetivo de Segurança | Estado Seguro do Unidade de Controle Eletrônico ADAS (ADCU)
Prevenir a ocorrência de torque não intencional no Sistema Avançado de Assistência ao Condutor (ADAS) (dentro das capacidades funcionais do ADAS)
Desativar a função ADAS que pode controlar a condução. |
| FSR | O sistema "ADCU" deve "entrar em estado seguro SE o valor da solicitação de cálculo de aceleração for maior que o limite de aceleração". |
| TSRs | ADCU deve limitar o sinal ADCU_ACC_Ax_Req, calculado pela função de Controle de Cruzeiro Adaptativo (ACC), a um valor mínimo.
A solicitação de aceleração do ACC será substituída pelo valor de limite mínimo permitido se a solicitação for menor que o limite.
When rqAcclACC_L2iaVUC < thldMinAcclRq_L2caIUC <br> Then rqAcclACC_L2caVUC = thldMinAcclRq_L2caIUC
ADCU deve limitar o sinal ADCU_ACC_Ax_Req, calculado pela função ACC, a um valor máximo.
A solicitação de aceleração do ACC será substituída pelo valor de limite máximo permitido se a solicitação exceder o limite.
When rqAcclACC_L2iaVUC > thldMaxAcclRq_L2caIUC <br> Then rqAcclACC_L2caVUC = thldMaxAcclRq_L2caIUC
ADCU deve gerar um flag de erro se o cálculo da solicitação de aceleração/desaceleração for incorreto.
O flag de solicitação de erro do ACC deve ser definido como "Verdadeiro" se a solicitação de aceleração do ACC estiver fora dos limites mínimo ou máximo.
When rqAcclACC_L2iaVUC < thldMinAcclRq_L2caIUC or rqAcclACC_L2iaVUC > thldMaxAcclRq_L2caIUC <br> Then flgRqACCFlt_L2caVUC = 1 ("True") |
| SSRs | (Exemplos de SSRs seriam derivados dos TSRs, detalhando a lógica de implementação em software, como a comparação de valores, atribuição de variáveis e controle de fluxo.) |
4. Resumo
Em suma, a fase de concepção da ISO 26262 consiste em definir os requisitos de segurança em nível de veículo e estabelecer uma abordagem sistêmica para garantir que os sistemas automotivos sejam projetados de forma segura desde o início. Isso também serve como base para garantir que todas as atividades subsequentes de projeto e validação priorizem a segurança. A fase de concepção envolve a identificação de funções críticas, a avaliação de riscos e o estabelecimento de objetivos de segurança. Essa abordagem baseada em requisitos enfatiza a importância da integração da segurança em todos os níveis de desenvolvimento, diferenciando-a de metodologias que podem priorizar a funcionalidade sobre a segurança. Conclui-se que essa abordagem é essencial para a criação de software robusto e seguro em ambientes críticos de segurança.
5. Lista de Referências
[1] TÜV SÜD Akademie GmbH. https://www.tuvsud.com/ [2] Norma ISO 26262:2018.
Autor: Andres Silva, Engenheiro Líder de Segurança Funcional ADAS na Atom
Tags: sistemas, segurança, rastreabilidade, requisitos, ISO 26262, automotivo, software
Hubs: Blog da Empresa ATOM, Segurança da Informação, Análise e Projeto de Sistemas
