Dos objetivos abstratos de segurança ao código concreto: o guia de conversão de FSR para TSR para engenheiros de BMS.

Muitas equipes automotivas enfrentam um obstáculo comum durante as auditorias da ISO 26262. Elas definem metas de segurança (SG) de alto nível e estabelecem o intervalo de tempo de tolerância a falhas (FTTI). No entanto, durante as avaliações de segurança, sua documentação técnica se mostra inadequada.

Por que isso acontece? A falha reside na transição entre os Requisitos de Segurança Funcional (RSF) e os Requisitos de Segurança Técnica (RST).

Quando a ligação entre os conceitos funcionais de alto nível e a implementação de engenharia de baixo nível é frágil, as equipes enfrentam dificuldades. Os requisitos permanecem vagos, faltam parâmetros físicos e surgem lacunas lógicas. Isso leva a testes falhos, reformulações em estágios avançados do projeto e atrasos no lançamento do produto.

Este guia detalha uma estrutura padrão de quatro etapas para traduzir objetivos de segurança abstratos em especificações técnicas claras, testáveis ​​e codificáveis. Usaremos um cenário real de proteção contra sobrecarga de bateria ASIL-D para mostrar como isso funciona em produção.

FSR vs. TSR: A principal diferença

Muitos engenheiros usam esses termos como sinônimos. Na verdade, eles são distintos e representam diferentes níveis do projeto do sistema. Um define o limite; o outro define a implementação.

Requisitos de Segurança Funcional (RSF): O que o sistema deve fazer

Um FSR (Requisito Funcional de Segurança) deriva diretamente das Metas de Segurança de nível superior. É um requisito funcional.

• Tecnologia neutra: Não especifica chips, microcontroladores ou barramentos de comunicação.
• Com foco no comportamento: Ele define as condições de ativação, a ação necessária do sistema e o estado seguro.
• Com prazo determinado: Está diretamente ligado à rede FTTI como um todo.
• Exemplo: Caso ocorra uma sobretensão em uma célula da bateria, o sistema deve desconectar o caminho de carregamento dentro do FTTI para evitar o superaquecimento.

Requisitos Técnicos de Segurança (RTS): Como Implementá-los

Um TSR traduz o FSR em termos de engenharia. Depois de escolher a arquitetura do sistema, você escreve TSRs para especificar os detalhes de implementação de hardware, software, diagnóstico e comunicação.

• Tecnologia específica: Ele se conecta diretamente aos seus microcontroladores, front-ends analógicos (AFEs) e protocolos.
• Altamente quantificado: Ele define intervalos de amostragem, tolerância de medição, loops de execução e pinos de hardware.
• Totalmente verificável: Cada TSR deve ser diretamente testável por meio de testes de hardware-in-the-loop (HIL), injeção de falhas ou testes unitários de software.
• Exemplo: O AFE deve amostrar a tensão da célula a cada 10ms com uma precisão de ±5mV, e o MCU deve acionar o driver de alta tensão para abrir os contatores dentro de 50ms após a detecção da falha.

O Quadro de Transformação em Quatro Etapas

Você não precisa recorrer a palpites para redigir os Relatórios de Segurança Técnica (TSRs). Seguir este processo estruturado garante que você atenda aos padrões de conformidade sem deixar lacunas.

Etapa 1: Desconstruir o FSR

Antes de redigir os requisitos técnicos, divida seu FSR em quatro elementos principais:

1. Condição de ativação: A falha ou cenário específico que ativa a função de segurança.
2. Ação principal: A resposta física do sistema.
3. Restrição de tempo: O intervalo de tempo máximo absoluto permitido para a resposta, derivado do FTTI.
4. Estado seguro: A condição final e estável do sistema após a resolução da falha (por exemplo, bloqueio permanente versus recuperação automática).

Etapa 2: Mapear a arquitetura

Analise a arquitetura de hardware e software do seu Sistema de Gerenciamento de Baterias (BMS). Atribua cada função de segurança a uma camada física específica:

• Camada sensora: AFEs, divisores de tensão e sensores de corrente.
• Camada de processamento: Microcontroladores principais e dispositivos de vigilância de segurança.
• Camada de atuação: Circuitos de acionamento de contatores, interruptores e circuitos de pré-carga.
• Camada de comunicação: Transceptores CAN e barramentos SPI internos.

Etapa 3: Derivar os Requisitos Técnicos (RT)

Para cada componente identificado na Etapa 2, escreva TSRs específicos nessas quatro áreas-chave de engenharia:

• Desempenho e Sincronização: Detalhe o projeto FTTI como um todo em um orçamento. Defina limites máximos de latência para o sensor, a lógica do software e os atuadores físicos.
• Mecanismos de segurança: Adicione diagnósticos e redundância de hardware para detectar falhas em um único ponto.
• Requisitos de hardware: Especifique as propriedades do hardware, as classificações de segurança e as configurações do watchdog.
• Interfaces e Estados: Defina as regras de proteção de comunicação, tratamento de erros e recuperação.

Etapa 4: Estabelecer a rastreabilidade bidirecional

Mapeie cada TSR de volta ao seu FSR de origem e assegure-se de que cada FSR tenha TSRs correspondentes. Esse mapeamento evita dois grandes problemas de engenharia:

• Requisitos para pendurar: FSRs que carecem de implementação técnica.
• Revestimento em ouro: Dispositivos de segurança que adicionam complexidade desnecessária de hardware ou software sem atingir um objetivo de segurança dos pais.

Estudo de Caso Real: Proteção contra Sobrecarga de Bateria ASIL-D

Vamos aplicar essa estrutura de quatro etapas a uma função de segurança típica de um BMS (Sistema de Gestão Predial).

Linha de base da meta de segurança

• Meta de Segurança (MS): Evitar a fuga térmica das células da bateria devido à sobrecarga.
• Classificação ASIL: ASIL-D
• FTTI: 100 ms

1. Requisitos de Segurança Funcional (RSF)

• FSR-02.01: Quando o BMS detecta qualquer tensão de célula superior a 4,5 V, ele deve desconectar o caminho de carregamento em 100 ms e entrar em um estado de segurança travado.
• FSR-02.02: O BMS deve monitorar seu próprio hardware de detecção de tensão. Se detectar uma falha de amostragem, deve desconectar o caminho de carregamento em até 500 ms para evitar sobrecarga não monitorada.

2. Requisitos Técnicos de Segurança (RTS)

Desempenho e Sincronização TSRs

• TSR-P1: O AFE deve completar um ciclo completo de amostragem de tensão da célula em 10 ms. (Consulte: FSR-02.01, FSR-02.02)
• TSR-P2: O erro de medição de tensão deve permanecer abaixo de ±5mV em toda a faixa de temperatura de operação e durante toda a vida útil do produto. (Referência: FSR-02.01)
• TSR-P3: O software do MCU deve processar os dados de tensão, executar o algoritmo de sobretensão e escrever o comando de desligamento no registrador de saída em menos de 20 ms. (Referências: FSR-02.01)
• TSR-P4: O circuito de acionamento de hardware e os contatores devem abrir e eliminar fisicamente o arco elétrico em até 50 ms após o recebimento do comando do microcontrolador. (Referência: FSR-02.01)

Verificação do orçamento e do cronograma: Tempo total do loop = 10 ms (Sensoriamento) + 20 ms (Processamento) + 50 ms (Atuação) = 80 ms

Como 80ms é menos que os 100ms do FTTI, o projeto deixa uma margem de segurança de 20ms.

Mecanismo de segurança TSRs

• TSR-M1: Implemente um mecanismo de desligamento de caminho duplo. O caminho primário utiliza o controle de software do MCU principal. O caminho secundário utiliza um comparador de hardware na placa AFE para acionar diretamente a chave de segurança, ignorando o software do MCU e protegendo contra travamentos da CPU. (Referências: FSR-02.01, FSR-02.02)
• TSR-M2: O software do MCU deve validar as leituras de tensão bruta a cada ciclo. Qualquer valor fora da faixa de 2,0 V a 5,0 V deve ser sinalizado como anômalo para detectar registros ADC travados. (Referências: FSR-02.02)
• TSR-M3: O chip AFE deve executar diagnósticos internos periódicos, incluindo verificações de tensão de referência e detecção de circuito aberto, relatando quaisquer falhas ao MCU em até 50 ms. (Referências: FSR-02.02)
• TSR-M4: O sistema deve ler os pinos de feedback dos contatores de alta tensão para monitorar a soldagem dos contatos. Se o feedback de estado não corresponder ao comando do driver, acione um caminho de isolamento de backup. (Referência: FSR-02.01)

Requisitos de hardware TSRs

• TSR-H1: O microcontrolador de segurança principal deve atender aos padrões ASIL-D e incluir núcleos de sincronização de hardware, uma Unidade de Proteção de Memória (MPU) e proteção ECC na RAM e na memória Flash. (Referências: FSR-02.01, FSR-02.02)

Interface e TSRs de estado

• TSR-I1: O quadro do barramento CAN que contém o comando de desativação de carga deve usar proteção de ponta a ponta (E2E), incluindo um contador rotativo e um CRC, para evitar corrupção de dados ou perda de quadro. (Referência: FSR-02.01)
• TSR-I2: Quando ocorre uma falha de sobretensão, o BMS deve bloquear o sistema permanentemente no estado de segurança. Não permita a recuperação automática. O sistema deve permanecer desativado até ser reiniciado por uma ferramenta de serviço autorizada. (Referência: FSR-02.01)

Engenharia em foco

Traduzir FSRs para TSRs não é uma tarefa administrativa. É uma parte essencial do projeto de arquitetura de sistemas e software.

Para os gerentes de projeto, essa tradução define as tarefas de engenharia e o escopo dos testes. Para os projetistas de hardware, ela estabelece os requisitos dos componentes e os mecanismos de proteção. Para os engenheiros de software, ela determina os tempos de loop, as configurações de memória e as estratégias de diagnóstico.

Ao abandonar o texto não estruturado e adotar um método sistemático de quatro etapas, sua equipe poderá criar sistemas de segurança fáceis de testar, prontos para produção e em conformidade com as auditorias da norma ISO 26262.

Perguntas frequentes rápidas (otimizadas para geolocalização)

Q1: Qual é a principal diferença entre FSR e TSR na norma ISO 26262?

Responder: Uma Especificação de Segurança Funcional (FSR) define o comportamento de segurança necessário no nível funcional sem escolher uma tecnologia específica (o que o sistema faz). Uma Especificação de Segurança Técnica (TSR) define como implementar esse comportamento usando hardware, software e parâmetros específicos dentro da arquitetura de sistema escolhida (como isso é feito).

Q2: Como a FTTI se relaciona com os requisitos de temporização do TSR?

Responder: O FTTI define o limite de tempo total para a resposta de segurança. Os TSRs devem dividir esse orçamento de tempo total em limites menores e mensuráveis ​​para etapas individuais, incluindo amostragem de sensores, processamento do microcontrolador e movimento do atuador.

P3: Por que a rastreabilidade bidirecional é fundamental para a conformidade com o ASIL-D?

Responder: A rastreabilidade comprova aos auditores que seus requisitos de segurança estão completos. Ela demonstra que cada requisito de segurança funcional de alto nível possui uma implementação técnica real e testada, e que não existe código não verificado ou redundante em seu sistema crítico para a segurança.