Por Ann Keffer, Arun Gogineni e James Kim

Os carros que implementam recursos ADAS e AV dependem de sistemas digitais e analógicos complexos para executar aplicações críticas em tempo real. O grande número de falhas que precisam ser testadas nesses projetos automotivos modernos torna impraticável a realização de verificação de segurança usando uma única tecnologia.

No entanto, desenvolver uma metodologia de segurança otimizada com listas de falhas específicas direcionadas automaticamente para simulação, emulação e formal é um desafio. Outro desafio é consolidar os resultados da resolução de falhas de várias execuções de injeção de falhas para o cálculo da métrica final.

A boa notícia é que a interoperabilidade dos motores de injeção de falhas, as técnicas de otimização e um fluxo automatizado podem efetivamente reduzir o tempo geral de execução para fechar rapidamente o ciclo da análise de segurança à certificação de segurança.

A Figura 1 mostra algumas das técnicas de otimização em um fluxo de segurança. Metodologias avançadas, como análise de segurança para otimização e eliminação de falhas, simulação de falhas simultâneas, emulação de falhas e análise formal podem ser implantadas para validar os requisitos de segurança para um SoC automotivo.

Figo 1: Culpa Lista otimização técnicas.

Prova de conceito: um SoC automotivo

Usando um caso de teste de nível SoC, demonstraremos como esse fluxo automatizado e multimotor lida com o grande número de falhas que precisam ser testadas em projetos automotivos avançados. O design do SoC que usamos neste caso de teste tinha aproximadamente três milhões de portas. Primeiro, usamos mecanismos de injeção de falhas de simulação e emulação para concluir com eficiência as campanhas de falhas para as métricas finais. Em seguida, realizamos a análise formal como parte da conclusão da injeção geral de falhas.

Figo 2: Automotivo SoC nível superior quadra diagrama.

A Figura 3 é uma representação do bloco de ilha de segurança da figura 2. As áreas codificadas por cores mostram onde simulação, emulação e motores formais foram usados ​​para injeção e classificação de falhas.

Figo 3: Detalhado ilha de segurança quadra diagrama.

A injeção de falhas usando simulação consumia muito tempo e recursos para o núcleo da CPU e os blocos de memória cache. Esses blocos foram direcionados para injeção de falhas com um mecanismo de emulação para maior eficiência. O núcleo da CPU é protegido por uma biblioteca de testes de software (STL) e a memória cache é protegida por ECC. A interface do barramento requer proteção ponta a ponta onde a injeção de falta com simulação foi considerada eficiente. A unidade de gerenciamento de falhas não fez parte deste experimento. A injeção de falhas para a unidade de gerenciamento de falhas será concluída usando tecnologia formal como próximo passo.

A Tabela 1 mostra a contagem de registros dos blocos da ilha de segurança.

Tabela 1: Contagem de registros de blocos.

As listas de falhas geradas para cada um desses blocos foram otimizadas para focar nos nós críticos de segurança que possuem mecanismos/proteção de segurança.

SafetyScope, uma ferramenta de análise de segurança, foi executada para criar as listas de falhas para os FMs tanto para o aplicativo Veloce Fault (emulador de falhas) quanto para o simulador de falhas e gravou as listas de falhas no banco de dados de segurança funcional (FuSa).

Para os blocos de CPU e memória cache, o emulador insere os blocos sintetizados e redes de injeção/detecção de falhas (FIN/FDN). Em seguida, executou o estímulo e capturou os estados de todos os FDNs. Os estados foram salvos e usados ​​como referência “ouro” para comparação com execuções de injeção de falha. Para cada falha listada na lista de falhas otimizada, o comportamento da falha foi emulado e os FDNs foram comparados com os valores de referência gerados durante o golden run, e os resultados foram classificados e atualizados no banco de dados de falhas com atributos.

Figura 4: Cluster de CPU. (Fonte da https://developer.arm.com/Processors/Cortex-R52)

Para cada uma das subpartes mostradas no diagrama de blocos, geramos uma lista de falhas otimizada usando o mecanismo de análise. As listas de falhas são salvas em sessões individuais no banco de dados FuSa. Usamos a amostragem estatística aleatória nas falhas gerais para gerar a amostra aleatória do banco de dados FuSa.

Agora vamos ver o que acontece quando pegamos uma amostra aleatória durante toda a injeção de falha usando emulação. Porém, para que isso fechasse completamente na injeção de falha, processamos N amostras.

mesa 2: Detectado falhas by segurança mecanismos.

A Tabela 3 mostra que a distribuição geral de falhas para o total de falhas está alinhada com a distribuição de falhas das falhas amostradas aleatoriamente. A tabela captura ainda o total de falhas detectadas de 3125 de um total de 4782 falhas. Também conseguimos modelar as falhas detectadas por subparte e fornecer uma taxa geral de falhas detectadas de 65.35%. Com base nas falhas na amostra aleatória e na nossa meta de cobertura de 90%, calculamos que a margem de erro (MOE) é de ±1.19%.

mesa 3: Resultados da injeção de falhas na CPU e na memória cache.

O total de 3125 falhas detectadas (observadas + não observadas) fornece uma classificação clara de falhas. As observações não detectadas também fornecem uma classificação clara para falhas residuais. Fizemos análises adicionais de falhas não detectadas, não observadas e não injetadas.

mesa 4: Culpa classificação depois de culpa injeção.

Usamos muitas técnicas de depuração para analisar as 616 falhas não detectadas e não observadas. Primeiro, utilizamos análise formal para verificar o cone de influência (COI) dessas falhas UU. As falhas que estavam fora do COI foram consideradas seguras, e houve cinco falhas que foram posteriormente retiradas da análise. Para as falhas que estavam dentro do COI, usamos julgamento de engenharia com justificativa de várias configurações como ECC, temporizador, memória flash relacionada, etc. Finalmente, usando julgamento formal e de engenharia, fomos capazes de classificar ainda mais 616 falhas UU em falhas seguras e restantes. Falhas UU em falhas residuais conservadoras. Também revisamos as 79 falhas residuais e conseguimos classificar 10 falhas em falhas seguras. As falhas não injetadas também foram testadas contra o modelo de simulação para verificar se algum estímulo adicional é capaz de injetar essas falhas. Como nenhum estímulo foi capaz de injetar essas falhas, decidimos retirá-las de nossa consideração e, consequentemente, contra a margem de erro. Com esta mudança nosso novo MOE é de ±1.293%.

Paralelamente, o simulador de faltas extraiu as listas de faltas otimizadas para os modos de falha do bloco de barramento e executou simulações de faltas utilizando estímulos de verificação funcional. O conjunto inicial de estímulos não forneceu cobertura suficiente, então estímulos de maior qualidade (vetores de teste) foram preparados e campanhas de falhas adicionais foram executadas nos novos estímulos. Todas as classificações de falhas foram gravadas no banco de dados FuSa. Todas as execuções foram paralelas e simultâneas para eficiência geral e alto desempenho.

A análise de segurança usando SafetyScope ajudou a fornecer mais precisão e reduzir a iteração da simulação de falhas. CPU e cache mem após a emulação em vários testes resultaram em um SPFM geral de mais de 90%, conforme mostrado na Tabela 5.

mesa 5: No geral resultados.

Neste momento nem todos os testes do bloco BUS (proteção fim a fim) que fazem a simulação de falta foram concluídos. A Tabela 6 mostra que o primeiro teste inicial foi capaz de resolver as falhas de 9.8% muito rapidamente.

mesa 6: Porcentagem de falhas detectadas no bloco BUS pelo E2E SM.

Estamos integrando mais testes com alto tráfego no BUS para imitar o estado de operação do SoC em tempo de execução. Os resultados dessas injeções de falhas independentes (simulação e emulação) foram combinados para o cálculo das métricas finais nos blocos acima, com os resultados mostrados na Tabela 7.

mesa 7: Pós-análise da classificação final da falha.

Conclusão

Neste artigo, compartilhamos os detalhes de uma nova metodologia de segurança funcional usada em um caso de teste automotivo de nível SoC e mostramos como nossa metodologia produz um fluxo de trabalho de segurança escalável e eficiente usando técnicas de otimização para injeção de falhas usando mecanismos formais, de simulação e de verificação de emulação. . A realização da análise de segurança antes de executar a injeção de falhas foi muito crítica e economizou tempo. Portanto, a interoperabilidade para utilização de múltiplos motores e leitura dos resultados de um banco de dados FuSa comum é necessária para um projeto desta escala.

Para obter mais informações sobre esse fluxo de segurança funcional altamente eficaz para projetos automotivos ADAS e AV, baixe o whitepaper da Siemens EDA Mecanismos de segurança complexos exigem interoperabilidade e automação para validação e fechamento métrico.

Arun Gogineni é gerente de engenharia e arquiteto de segurança funcional de IC na Siemens EDA.

James Kim é líder técnico da Siemens EDA.

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
• PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
• PlatãoESG. Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
• PlatoHealth. Inteligência em Biotecnologia e Ensaios Clínicos. Acesse aqui.
• Fonte: https://semiengineering.com/interoperability-and-automation-yield-a-scalable-and-efficient-safety-workflow/