Garantindo Timing Confiável em Sistemas Embarcados Multicore Críticos de Segurança

Veículos e aeronaves modernos não dependem mais apenas de componentes mecânicos. Sua segurança e performance dependem de software embarcado que roda em processadores multicore heterogêneos complexos, gerenciando tudo de controle de voo a direção hidráulica com deadlines de nível de microssegundos.

Em um ambiente multicore, o tempo de execução de uma tarefa é influenciado não apenas por seu próprio código mas também por outras tarefas compartilhando os mesmos recursos de hardware. Esta interferência pode empurrar um sistema além de suas margens de segurança.

Desenvolver software embarcado crítico de segurança demanda esforço de multi-milhões de euros e multi-anos. Desde os estágios iniciais de design, a segurança deve ser enraizada na arquitetura e o comportamento de timing de cada tarefa deve ser rigorosamente compreendido para garantir que deadlines sejam cumpridos.

Resolvendo o Quebra-Cabeça de Análise de Timing Multicore

Enquanto processadores multicore prometem performance maior, eles também introduzem contenção por recursos compartilhados como barramentos, memória, caches e aceleradores. Uma tarefa rodando em um core pode desacelerar tarefas em outros cores, criando variações de timing imprevisíveis.

Questões-chave surgem: Como quantificar o impacto de tal interferência? Como analisar, testar e documentar que software crítico de segurança sempre terminará dentro de seus deadlines em uma plataforma multicore?

Líderes da indústria — Barcelona Supercomputing Center (BSC), Rapita Systems Ltd (RPT), Raytheon Technologies (RTRC) e Marelli Europe (MAR) — gastaram anos abordando esses desafios. BSC e Rapita estão agora entregando um conjunto de soluções que será em breve adotado em setores aeroespacial e automotivo. O sucesso depende de tooling especializado, automação e uma metodologia orientada a requisitos e segurança.

Este trabalho fundamenta o projeto MASTECS, uma iniciativa de P&D multidisciplinar financiada pela Comissão Europeia lançada em dezembro de 2019. MASTECS amadurecerá as tecnologias e fornecerá uma abordagem comprovada para certificar sistemas avionicos e automotivos, com estudos de caso da RTRC e MAR ilustrando impacto real.

Ferramentas de Ponta

Ferramentas comerciais se destacam para análise de single-core mas lutam com a complexidade de certificação multicore. As limitações incluem:

• Ferramentas de análise de timing estático [1] batem em uma parede de complexidade, incapazes de modelar hardware sofisticado ou software extremamente complexo.
• Soluções baseadas em medição — embora prevalentes em teste de single-core (ex: toolset RVS da Rapita) — carecem de metodologia de especialista em hardware para produzir limites de timing confiáveis para cargas de trabalho multicore com rastreabilidade adequada.

Até o momento, nenhuma ferramenta comercial fora do esforço de desenvolvimento MASTECS oferece análise abrangente de timing multicore que alinha com padrões de segurança e requisitos de certificação emergentes.

Análise e Controle de Interferência em Ação

A pedra angular de nossa abordagem é uma metodologia de teste estruturada que mescla expertise de hardware e software para gerar evidência de comportamento de timing multicore. A tecnologia de micro-benchmark multicore (MμBT) da BSC, comercializada pela Rapita como RapiDaemons, permite que designers criem cenários de interferência que estressam recursos compartilhados específicos.

Micro-benchmarks — snippets de código minúsculos de baixo nível — operam na interface hardware-software para impor pressão quantificável em um recurso alvo. Eles revelam o efeito de canais de interferência e podem ser adaptados para induzir, medir ou validar contenção. Atributos-chave incluem:

1. Pressão direcionada e quantificável em um recurso compartilhado.
2. Comportamento verificável através de monitores de evento.
3. Alinhamento com requisitos de timing específicos, como testar eficácia de mitigação.

Uma biblioteca diversificada de micro-benchmarks existe para corresponder níveis de interferência desejados, maximizar impacto de recurso ou atuar como testes "vítima" sensíveis.

Ao analisar interferência, emparelhamos MμBT com um Modelo de Contenção de Tarefa (TCM) que fornece estimativas iniciais de atrasos de contenção. RapiTest e RapiTime da Rapita automatizam criação e execução de teste no target embarcado.

Metodologia de Design

Seguindo um processo de sete passos integrado ao ciclo de vida de software em modelo V (veja Figura 2), engenheiros ganham insight profundo em efeitos de interferência:

1. Configuração de hardware & identificação de canal de interferência. Especialistas em hardware identificam configurações críticas, caminhos de interferência e opções de mitigação, enquanto selecionam monitores de evento para verificação.
2. Definir requisitos de timing. Capturar necessidades específicas do usuário, riscos e restrições de segurança, e avaliar estratégias de isolamento de hardware.
3. Design de caso de teste. Criar descrições de teste que validem hipóteses, especificando micro-benchmarks necessários para análise de interferência sob condições isoladas e estressadas.
4. Implementar procedimentos de teste. Montar framework de teste, micro-benchmarks e sondas de medição. Atualmente manual, isso será automatizado dentro do MASTECS.
5. Coletar evidência. Executar testes na plataforma target, coletando dados que se vinculam diretamente a requisitos de verificação.
6. Analisar resultados. Especialistas técnicos revisam outcomes contra requisitos. Por exemplo, a Figura 3 mostra breakdown de tempo de execução do RapiTime.
7. Validar & documentar. Revisão final, geração de relatório e artefatos de qualificação prontos para submissões de certificação.

Expertise em Hardware e Processo de Análise de Timing

Insight de hardware é vital desde o início. Envolvimento inicial inclui:

1. Identificar configurações multicore que moldam comportamento funcional e de timing, e determinar mecanismos de isolamento que reduzem contenção.
2. Identificar canais de interferência navegando manuais complexos de processador e consultando vendors para detalhes faltantes.
3. Selecionar monitores de evento que capturam atividade de tarefa em canais de interferência, e validá-los com micro-benchmarks dedicados [2].
4. Colaborar com analistas de timing para derivar requisitos e desenhar testes que carregam canais de interferência específicos.

Em estágios posteriores, especialistas em hardware avaliam resultados de teste, refinam hipóteses e propõem testes adicionais conforme necessário.

O Quadro Maior

O processo de design de sete passos é parte de uma metodologia mais ampla de verificação multicore (veja Figura 2). Entrega rastreabilidade total — de evidência e resultados de volta a requisitos e design — suportando tanto CAST-32A quanto ISO 26262. CAST-32A, lançado pela Certification Authorities Software Team (CAST) em 2016, delineia objetivos para avionics multicore seguros, incluindo bounding de interferência. EASA e FAA estão trabalhando em uma adaptação unificada AMC/AC (AMC 20-193) esperada para ainda este ano.

Expertise Não Pode Ser Automatizada

Dinâmicas de interferência são complexas; ferramentas automatizadas só podem complementar, não substituir, engenheiros experientes. Especialistas multicore trazem conhecimento profundo de configurações de hardware e canais de interferência, enquanto analistas de software traduzem requisitos em testes rigorosos. Insight humano é essencial para validar suposições, interpretar resultados e iterar em designs.

Referências

1. Reinhard Wilhelm. Mixed Feelings about Mixed Criticality. Workshop on Worst‑Case Execution Time Analysis, 2018.
2. Enrico Mezzetti, Leonidas Kosmidis, Jaume Abella, Francisco J. Cazorla. High‑Integrity Performance Monitoring Units in Automotive Chips for Reliable Timing V&V. IEEE Micro 38(1): 56‑65 (2018).
3. EASA and FAA to issue further guidance on multicore certification this year.