Guia de Desenvolvimento de Hardware ISO 26262-5: Requisitos, Métricas e Testes

• AutorJohnny Liu (CEO da Dowway Vehicle)
• Data7 de julho de 2026
• CategoriaSegurança Funcional Automotiva / Engenharia de Hardware

Os carros modernos são repletos de componentes eletrônicos complexos. À medida que construímos veículos mais inteligentes, as placas de circuito e os componentes de silício em seu interior precisam ser extremamente confiáveis.

Passei anos trabalhando com hardware automotivo. Sei o quão difícil pode ser o processo de conformidade com a segurança funcional. Este guia irá orientá-lo nesse processo. ISO 26262-5 (desenvolvimento em nível de hardware) Utilizando etapas claras e práticas, abordaremos tudo, desde os requisitos até métricas como SPFM, LFM e PMHF.

1. As três atividades principais de segurança de hardware

Para garantir a segurança dos sistemas automotivos, não podemos simplesmente esperar que o hardware funcione. Devemos projetá-lo para lidar com falhas.

A norma ISO 26262-5 descreve três atividades principais que você deve realizar:

1. Incorpore o conceito de segurança técnica ao hardware.
2. Analise possíveis falhas de hardware e determine seus efeitos.
3. Coordenar de perto com a equipe de software.

A lógica por trás da cláusula 8 e da cláusula 9

A norma utiliza duas cláusulas distintas para medir o nível de segurança do seu hardware:

• Cláusula 8 (Métricas de Arquitetura de Hardware)Esta cláusula utiliza duas porcentagens — a Métrica de Falha de Ponto Único (SPFM) e a Métrica de Falha Latente (LFM) — para medir a eficácia do projeto de hardware e dos mecanismos de segurança no tratamento de falhas físicas aleatórias.
• Cláusula 9 (Avaliação de falhas aleatórias de hardware)Esta cláusula analisa o risco geral. Ela utiliza um cálculo de probabilidade com forte componente matemática (PMHF) ou uma análise de conjunto de corte para verificar se o risco de violar uma meta de segurança é suficientemente baixo.

2. Configurando seus Requisitos de Segurança de Hardware (HSR)

Seu Requisitos de segurança de hardware (HSR) deve derivar diretamente dos seus Requisitos Técnicos de Segurança (RTS) em nível de sistema. Você também precisa escrever uma descrição detalhada. Interface Hardware-Software (HSI) Especificação para mostrar como as partes físicas e o código interagem.

Seu HSR deve abranger cinco áreas principais:

1) Controle de falhas internas

Seus requisitos devem especificar como lidar com falhas internas em suas unidades de hardware. Isso inclui maneiras de detectar falhas temporárias (problemas transitórios) usando ferramentas como watchdogs e temporizadores.

2) Resistência a falhas externas

O hardware deve sobreviver a falhas que ocorram fora de sua própria placa. Por exemplo, se uma Unidade de Controle Eletrônico (ECU) externa falhar, as entradas da sua ECU devem lidar com problemas como circuitos abertos ou curtos-circuitos na linha de alimentação (KL30).

3) Correspondência entre unidades

Garanta que seus requisitos de segurança sejam compatíveis e funcionem bem com os requisitos de segurança das unidades de hardware vizinhas no carro.

4) Detecção e sinalização de falhas

Seu projeto precisa detectar e reportar falhas rapidamente. Você deve escrever requisitos para detectar falhas físicas comuns, incluindo:

• Pinos abertos
• Curto-circuito para o terra
• Curto-circuito para potência

5) Regras de Verificação de Projeto

O HSR não deve obrigá-lo a adotar um mecanismo de segurança específico. Em vez disso, deve definir as regras que você usará para verificar o projeto posteriormente. Essas regras incluem:

• Limites ambientaisTemperatura, vibração e interferência eletromagnética (EMI).
• Condições de funcionamentoFaixas de tensão da fonte de alimentação e expectativa de vida útil (perfis de missão).
• Regras específicas do componenteRequisitos para microchips ou drivers de potência específicos.

3. Projeto de Hardware: Da Arquitetura aos Esquemas

O projeto de hardware parte da arquitetura geral e chega aos esquemas de circuitos propriamente ditos.

Arquitetura de Visão Geral

Seu diagrama de arquitetura mostra todas as suas unidades de hardware e como elas se conectam.

• Herança ASILCada unidade de hardware deve atender aos requisitos de segurança do nível mais alto de Integridade de Segurança Automotiva (ASIL) atribuído a ela.
• A rastreabilidade é crucial.Você deve ser capaz de rastrear seus requisitos desde o HSR de alto nível até o menor bloco de circuito funcional em sua placa. Essa rastreabilidade bidirecional é a regra fundamental tanto da ISO 26262 quanto do ASPICE.
• Mantenha a simplicidadePara evitar erros de design, crie um layout modular, mantenha os blocos com tamanhos razoáveis ​​e evite complexidade desnecessária.
• Estresse ambientalÉ preciso considerar fatores do mundo real, como calor, vibração, umidade, poeira e ruído elétrico (EMI) proveniente de outros componentes do veículo. Essas considerações devem ser incluídas nos testes do seu Plano de Verificação de Projeto (DVP) (testes de EMC, elétricos e ambientais do ciclo de vida).

Projeto esquemático detalhado

Ao começar a desenhar linhas no seu esquema, siga estas regras:

1. Aprenda com o passadoSiga a cultura de segurança da sua empresa e utilize as lições aprendidas em projetos anteriores (consulte a norma ISO 26262-2:2018, cláusula 5.4.7).
2. Prevenir o Sobrecarga FísicaProjete seus circuitos para resistir a ruídos elétricos, calor e umidade.
3. Respeite os limitesCertifique-se de que todas as peças operem dentro dos limites ambientais especificados.
4. Utilize métodos robustosUtilize práticas confiáveis ​​de gerenciamento da qualidade (GQ) no projeto. Isso inclui a seleção conservadora de componentes, a redução da capacidade nominal dos componentes (operando as peças abaixo de seus limites máximos) e a Análise de Pior Caso de Circuito (WCCA).

4. Análise de Segurança de Hardware: Classificação de Falhas

Para descobrir onde seu hardware pode falhar, você deve realizar uma análise de segurança. Essa análise é baseada em Cláusula 8 da norma ISO 26262-9:2011.

Essa análise ajuda você a refinar seu projeto desde o início e a verificar seu trabalho posteriormente. É obrigatória para sistemas destinados a ASIL (B), C ou D.

Sua análise de segurança deve considerar três tipos de falhas:

• Falhas SegurasFalhas que não violam diretamente seus objetivos de segurança.
• Falhas pontuais únicas (SPF) / Falhas residuais (RF).
• Falhas em múltiplos pontos (MPF) (incluindo falhas percebidas, detectadas e latentes).

Na maioria dos projetos reais, você pode limitar sua análise multiponto a falhas de dois pontos (Duas falhas independentes ocorrendo simultaneamente). Não é necessário analisar todas as combinações possíveis de duas peças com falha. Em vez disso, concentre-se nas combinações em que uma falha afeta um componente de hardware essencial e a segunda falha compromete o mecanismo de segurança que deveria proteger esse componente.

Falhas de Ponto Único (SPF)

Uma SPF (Falha de Segurança) é uma falha física em um único componente de hardware que não é detectada por nenhum mecanismo de segurança e faz com que o sistema viole diretamente um objetivo de segurança.

Para comprovar que você mitigou os SPFs para sistemas ASIL (B), C ou D, você deve demonstrar:

• A) Mecanismos de segurança confiáveisVocê possui mecanismos de segurança que podem manter o sistema seguro ou alterná-lo para um estado seguro. Isso deve ocorrer dentro dos sistemas. Intervalo de tempo tolerante a falhas (FTTI).
• B) Alta cobertura diagnósticaVocê precisa calcular quantas falhas residuais seu sistema de diagnóstico consegue detectar.

Regras de projeto essenciais para espumas de poliuretano expandido (SPF):

• A Regra FTTISe o seu teste de diagnóstico demorar muito tempo para ser executado, ou se o mecanismo de segurança demorar muito tempo para responder, e o tempo total for maior que o seu FTTI, o mecanismo não é válido.
• Verificações de inicializaçãoSe uma falha só puder ser detectada na inicialização, você deve executar os autotestes imediatamente após ligar o veículo, antes de começar a dirigir.
• Ferramentas AnalíticasUtilize a Análise de Modos de Falha e Efeitos (FMEA) ou a Análise de Árvore de Falhas (FTA) para comprovar seus cálculos.
• Nível de avaliaçãoDependendo dos componentes, você pode analisar o chip como um todo ou examinar detalhadamente os modos de falha de pinos individuais.

Falhas latentes

Uma falha latente é uma falha em múltiplos pontos que não é detectada pelos mecanismos de segurança e não pode ser percebida pelo motorista. Com o tempo, essas falhas ocultas se acumulam e podem causar falhas repentinas no sistema quando uma segunda peça quebra.

Para comprovar que você se protegeu contra falhas latentes, você deve demonstrar:

• A) Notificação ao motoristaO sistema consegue detectar a primeira falha e alertar o condutor dentro de um prazo aceitável, antes que ocorra uma segunda falha.
• B) Cobertura medidaVocê deve avaliar e calcular sua cobertura de diagnóstico para essas falhas ocultas.

Regras de projeto essenciais para falhas latentes:

• Se o intervalo de teste de diagnóstico somado ao tempo de resposta for maior que o período definido para detecção de falhas em múltiplos pontos, a falha é considerada não coberta (latente).
• Utilize FMEA ou FTA quantitativa para construir seu modelo matemático.

Verificação: A relação entre 3a/3b e 1a/1b

Durante a verificação do projeto, métodos padrão são utilizados. 3a e 3b Atuam como verificações específicas dos princípios de design robusto e ambiental. Utilize-as para complementar e fortalecer seus métodos básicos de verificação. 1a e 1b.

5. Métricas de arquitetura de hardware e taxas de falha

Para comprovar a segurança do seu projeto perante auditores externos, você deve calcular suas métricas arquitetônicas.

Onde encontrar dados de taxa de falha (FIT)

Não é possível inventar taxas de falha. Você deve obter seus dados de Falhas ao Longo do Tempo (FIT) de uma destas três fontes:

Fonte 1: Normas reconhecidas do setor

Esta é a maneira mais comum de encontrar as taxas de falha de componentes. Você pode usar:

• SN 29500 (Padrão Siemens, amplamente utilizado na indústria automotiva).
• IEC/TR 62380 ou IEC 61709.
• Aviso MIL HDBK 217 F 2 ou RIAC HDBK 217.
• UTE C80-811.
• NPRD95.
• EN 50129:2003 Anexo C ou IEC 62061:2005 Anexo D.
• RIAC FMD97 ou MIL HDBK 338.

Fonte 2: Dados de retorno de campo

Você pode usar dados reais de veículos em circulação, mas seus dados devem ter um alto nível de confiabilidade.

Fonte 3: Julgamento de Especialistas Estruturado

Caso não existam dados disponíveis, você pode utilizar avaliações estruturadas de especialistas em engenharia. É imprescindível registrar os motivos e critérios exatos utilizados para a avaliação.

Metas de métricas para níveis ASIL

Para ser aprovado em uma auditoria, seu projeto deve atender aos seguintes requisitos mínimos:

Métrica	ASIL B	ASIL C	ASIL D
Métrica de Falha de Ponto Único (SPFM)	$\ge 90\%$	$\ge 97\%$	$\ge 99\%$
Métrica de Falha Latente (LFM)	$\ge 60\%$	$\ge 80\%$	$\ge 90\%$
Probabilidade de falha aleatória de hardware (PMHF)	$< 10^{-7} \text{ h}^{-1}$ (100 FIT)	$< 10^{-7} \text{ h}^{-1}$ (100 FIT)	$< 10^{-8} \text{ h}^{-1}$ (10 FIT)

6. Fechando o Ciclo: Testes de Segurança de Hardware

Não se pode confiar apenas em documentos e cálculos. É preciso testar fisicamente o hardware para encontrar quaisquer falhas de projeto remanescentes.

Para verificar seus mecanismos de segurança, escreva casos de teste com base nestes três métodos de teste:

A. Testes Funcionais

Este teste comprova que sua placa funciona conforme o esperado em condições normais. Você fornece entradas normais e verifica se as saídas correspondem às suas especificações. Se algo parecer fora do normal, você deve analisar o motivo.

B. Teste de Injeção de Falhas

Este teste comprova que seus mecanismos de segurança realmente funcionam quando algo dá errado. Você danifica fisicamente ou simula uma falha na placa (como curto-circuitar um pino ao terra) e observa como o sistema reage. Esta é a melhor maneira de verificar os tempos de reação de segurança.

C. Testes Elétricos

Este teste verifica seu projeto em toda a sua faixa de tensão operacional. Você submete a placa a alta tensão, baixa tensão e picos repentinos de tensão para garantir que ela permaneça estável.

Testes de estresse ambiental

Você também deve testar o desempenho do hardware sob estresse físico externo. Isso inclui executar a placa durante testes de alta vibração, testes de ciclo térmico (de congelamento profundo a condições de alta temperatura) e testes de ruído eletromagnético (EMC) intenso.

Considerações finais

A segurança funcional é um processo iterativo. Começa-se com os requisitos, projetam-se os circuitos, analisam-se com FMEAs e cálculos e, em seguida, verifica-se tudo com testes físicos. Se os testes revelarem fragilidades, retorna-se, atualiza-se o projeto e testa-se novamente. Seguindo esse ciclo, construímos veículos verdadeiramente seguros e robustos.

Perguntas frequentes

P1: O que acontece se o teste de diagnóstico e a resposta de segurança demorarem mais do que o Intervalo de Tempo Tolerante a Falhas (FTTI)?

Resposta curtaO mecanismo de segurança é inválido porque não consegue proteger o sistema a tempo.

DetalhesSe ocorrer uma falha e o diagnóstico demorar muito para detectá-la, o sistema poderá travar ou apresentar comportamento perigoso antes que o mecanismo de segurança entre em ação. O tempo total de reação — desde o momento em que a falha física ocorre até o momento em que o sistema atinge um estado seguro — deve ser sempre menor que o FTTI.

Q2: Qual é a relação entre os métodos de verificação 3a/3b e 1a/1b na norma ISO 26262-5?

Resposta curtaOs métodos 3a e 3b são verificações específicas e direcionadas que você usa para apoiar e fortalecer suas verificações básicas de projeto 1a e 1b.

DetalhesOs métodos 1a (verificação dos limites ambientais) e 1b (utilização de regras de projeto como redução de potência e WCCA) são as práticas fundamentais de projeto. Os métodos 3a e 3b atuam como uma segunda camada de verificação. Eles se concentram em pontos de falha física específicos e condições ambientais para garantir que nada tenha sido negligenciado no projeto inicial.

P3: Por que o padrão SN 29500 é tão popular para calcular taxas de falha de hardware?

Resposta curtaÉ o banco de dados de taxas de falha mais confiável e amplamente aceito na cadeia de suprimentos automotiva.

DetalhesEmbora normas como MIL-HDBK-217F ou IEC/TR 62380 sejam úteis, a SN 29500 (desenvolvida pela Siemens) fornece taxas de falha altamente realistas e atualizadas para chips de silício modernos e componentes passivos. Utilizá-la garante que seus cálculos estejam em conformidade com o que as montadoras e fornecedores de primeiro nível esperam durante as auditorias de segurança funcional.