Garantindo o comportamento de temporização do software em sistemas embarcados críticos baseados em vários núcleos

Chegar a algum lugar com segurança depende de mais do que apenas bons freios, lanternas traseiras funcionando e alguém com excelentes reflexos ao volante. Cada vez mais, os componentes que mantêm seu carro na estrada e seu avião no ar não são apenas humanos, ou mesmo apenas mecânicos. Eles são peças sofisticadas de software embutido rodando em complexos processadores multicore heterogêneos, controlando tudo, desde o sistema de gerenciamento de vôo até a direção hidráulica, e executando até prazos estritos de cronometragem medidos em microssegundos.

Aqui está o desafio. O comportamento de temporização do software em um sistema multicore é afetado não apenas pelo software executado nele e suas entradas, mas também pelo outro software executado em outros núcleos.

Sistemas embarcados críticos requerem um imenso esforço e investimento (milhões de euros / dólares e anos de esforço de engenharia) para serem desenvolvidos. A segurança deve estar no centro da arquitetura e do design, desde os primeiros estágios do processo de desenvolvimento de software. Em particular, os projetistas de sistemas devem compreender o comportamento do tempo de seu software, para garantir que ele possa ser executado dentro de prazos seguros.

Resolvendo o quebra-cabeça da análise de tempo multicore (MTA)

Embora a incrível capacidade de computação de um processador multicore deva (em teoria) tornar os sistemas embarcados mais poderosos e eficientes, o software em execução em um núcleo pode retardar a execução do software em execução nos outros núcleos. Nessa situação, o software pode demorar mais para ser executado devido à interferência causada pela contenção de recursos compartilhados, como barramentos, memória, caches, dispositivos, FPGAs e GPUs que são compartilhados com tarefas em execução em outros núcleos.

Como você quantifica os efeitos dessa interferência? Como você analisa, testa e fornece evidências concretas de que seu software crítico de segurança, quando executado em uma plataforma de vários núcleos, sempre pode ser executado dentro dos prazos?

Os especialistas do Centro de Supercomputação de Barcelona (BSC), da Rapita Systems Ltd (RPT), da Raytheon Technologies (RTRC) e da Marelli Europe (MAR) vêm investigando as respostas a essas perguntas há muitos anos. A BSC e a Rapita estão desenvolvendo uma solução que em breve será implementada nas indústrias aeroespacial e automotiva. Ferramentas especializadas e automação, combinadas com uma metodologia baseada em requisitos e focada na segurança, foram as chaves para resolver o quebra-cabeça.

Este trabalho formou a base do projeto MASTECS, um projeto multidisciplinar de pesquisa e desenvolvimento financiado pela Comissão Europeia e lançado em dezembro de 2019. O projeto MASTECS irá amadurecer as tecnologias e apoiar seu uso para a certificação de sistemas aviônicos e automotivos. Uma parte importante do projeto MASTECS é fornecer uma demonstração da abordagem em duas indústrias por meio de estudos de caso implantados pela RTRC e MAR.

Ferramentas de última geração

As ferramentas comercialmente disponíveis para dar suporte à análise de tempo são eficazes para eletrônicos simples (núcleo único), mas não se adaptam para atender aos novos requisitos e recomendações de certificação específicos para múltiplos núcleos.

• As soluções de análise de temporização estática [1] enfrentam uma parede complexa e não podem modelar com eficácia o hardware cada vez mais complexo, nem lidar com as características estruturais e sintáticas de funcionalidades de software excepcionalmente complexas.
• As soluções baseadas em medição alcançaram um bom nível de penetração no mercado de análise de núcleo único (o conjunto de ferramentas RVS da Rapita Systems está entre os de maior sucesso). No entanto, tais ferramentas ainda não são capazes de suportar totalmente os desafios trazidos pela introdução de multicores. Eles normalmente se concentram em cenários de medição conforme determinado por estratégias de teste funcional consolidadas, mas falta uma metodologia baseada em conhecimento de hardware que ajude a derivar limites de tempo confiáveis ​​para tarefas em execução em vários núcleos com a evidência de suporte necessária e um nível adequado de rastreabilidade.

Até onde sabemos, nenhuma ferramenta comercial disponível no mercado, além daquela em estágio de maturação em MASTECS, é capaz de analisar o timing de software em plataformas multicore, com forte enfoque nos padrões de segurança aplicáveis ​​e requisitos de certificação emergentes.

Análise e controle de interferência em ação

A chave para entender a interferência é uma metodologia de teste estruturada, usando especialistas em hardware e software para produzir evidências sobre o comportamento de temporização de vários núcleos. Uma tecnologia especializada da BSC (conhecida como tecnologia de micro-benchmark multicore ou MμBT, comercializada pela Rapita como RapiDaemons) permite que os projetistas de sistema analisem e quantifiquem os efeitos da interferência em uma aplicação baseada em multicore criando cenários de interferência adicionais para testar diferentes partes de o processador multicore.

Micro-benchmarks, no coração do MuBT, são pedaços de código bem elaborados que operam na interface mais baixa entre hardware e software para enfatizar um recurso compartilhado específico. Micro-benchmarks expõem o impacto dos canais de interferência no tempo do software. Para fazer isso, micro-benchmarks podem ser implantados para causar uma pressão configurável e quantificável em um aplicativo específico. Micro-benchmarks são projetados especificamente para exibir um comportamento único e claramente definido com efeito antecipado em um recurso de hardware específico, evitando ao máximo a geração de contenção em outros canais de interferência. Os principais recursos de micro-benchmark incluem o seguinte:

1. Eles colocam uma pressão quantificável sobre um recurso compartilhado específico.
2. Seu comportamento pode ser verificado por meio de monitores de eventos.
3. Eles capturam requisitos específicos relacionados ao tempo, por exemplo, se as ações de mitigação que você implementou para controlar a contenção são eficazes.

clique para ampliar a imagem

Figura 1:Uso de micro-benchmarks em análise de interferência. (Fonte:Autores)

Uma ampla gama de micro-benchmarks foi desenvolvida para ter funções específicas, incluindo combinar um nível desejado de interferência, maximizar a interferência no recurso ou simplesmente ser muito sensível à contenção ("vítimas").

Ao analisar os efeitos da interferência, o uso de MμBT é compatível com um modelo de contenção de tarefa (TCM) que fornece estimativas iniciais do atraso de contenção que as tarefas podem sofrer. As ferramentas de automação e teste de software RapiTest e RapiTime desenvolvidas pela Rapita são usadas para escrever testes e executá-los no destino incorporado.

Metodologia de design

Seguindo um processo de design de teste de sete etapas ao longo do processo de desenvolvimento de software 'V' padrão (Figura 2), os engenheiros podem entender mais completamente o impacto da interferência.

1. Definição de configuração crítica do processador multicore, canal de interferência e análise do monitor de evento. Os especialistas em hardware ajudam a identificar as definições de configuração críticas para definir a estrutura na qual os canais de interferência também são identificados junto com as medidas de mitigação. A identificação de monitores de eventos de hardware também é instrumental para fornecer um meio de verificação para todas as etapas seguintes.
2. Identifique os requisitos de tempo. Ajude o usuário final a identificar suas necessidades específicas, requisitos de tempo, riscos e questões de segurança para o sistema. Por exemplo, verifique o desempenho de qualquer abordagem de isolamento de hardware para minimizar a interferência.
3. Design de caso de teste. Desenvolva casos de teste específicos (descrição de um teste) para verificar o conjunto de hipóteses de suporte aos requisitos do usuário, incluindo a definição dos itens MμBT que serão necessários para fornecer evidências na análise do canal de interferência. Isso envolve a execução isolada (sem interferência), execução contra micro-benchmarks para avaliar o tempo de execução do aplicativo e a sensibilidade do hardware à interferência em diferentes cenários de estresse quantificáveis.
4. Implementação de procedimentos de teste. Atualmente, um processo manual a ser automatizado em MASTECS, esta etapa constrói os procedimentos de teste consistindo em uma estrutura de teste, micro-benchmarks e sondas de medição para registrar / rastrear os resultados.
5. Coleta de evidências (teste). Os procedimentos de teste são executados na plataforma para reunir evidências de teste. Atualmente envolvendo algum trabalho manual, isso será automatizado em MASTECS usando a estrutura de automação RapiTest para executar esses testes e vinculá-los de volta aos requisitos de verificação.
6. Análise de resultados. Uma revisão dos resultados do teste por especialistas técnicos para verificar como os resultados do teste verificam (ou não) os requisitos de verificação. Por exemplo, a Figura 3 mostra uma captura de tela do RapiTime nos tempos de execução relatados para diferentes funções de um programa.
7. Validar resultados e gerar documentação. Revisão final dos requisitos, geração de documentação e resultados de qualificação para apoiar o argumento de segurança do sistema. O cliente pode usar o conjunto completo de relatórios e artefatos de análise diretamente para a certificação do software executado em multicore.

clique para ampliar a imagem

Figura 2:Etapas do MTA no processo de desenvolvimento de software do modelo V. (Fonte:Autores)

Conhecimento de hardware e o processo de análise de tempo

A experiência em hardware de injeção (multicore) é um traço chave na abordagem de MTA proposta para seu sucesso em multicores complexos modernos. Durante os primeiros estágios de desenvolvimento de software:

1. Os especialistas em hardware identificam configurações multicore (definições de configuração críticas no jargão da aviônica), pois desempenham um papel fundamental na determinação do comportamento funcional e de tempo do software e afetam amplamente a quantidade de tarefas de contenção que geram umas às outras. Como um exemplo ilustrativo, os processadores atuais implementam mecanismos de isolamento e segregação que, se implantados corretamente, podem reduzir significativamente a contenção.
2. Os especialistas em vários núcleos desempenham um papel fundamental na identificação dos recursos nos quais a contenção de tarefas pode surgir (são chamados de canais de interferência na aviônica). A capacidade dos especialistas em hardware de navegar pelos manuais de referência técnica do processador de milhares de páginas e formular as perguntas apropriadas sobre as informações ausentes nos manuais para os fornecedores de chips é fundamental para conduzir um processo de MTA apropriado.
3. Uma vez que os canais de interferência são identificados, os especialistas em hardware identificam os monitores de eventos que podem ser usados ​​para rastrear a atividade que as tarefas geram nesses canais de interferência como uma métrica proxy para limitar a contenção que as tarefas podem sofrer. A exatidão desses monitores de eventos também deve ser verificada [2] para os quais um conjunto especializado de micro-benchmarks foi projetado.
4. Finalmente, os especialistas em hardware trabalham lado a lado com os especialistas em análise de tempo para derivar, a partir dos requisitos do usuário, requisitos de alto e baixo nível e testes específicos para validar as hipóteses de suporte aos requisitos do usuário. Cada teste instancia um ou vários programas de micro-benchmark projetados por especialistas em hardware para colocar o nível desejado de carga no (conjunto de) canal (is) de interferência alvo.

Durante as fases finais do projeto:

1. Os especialistas em hardware contribuem com a análise dos resultados do teste para avaliar se eles confirmam ou rejeitam as hipóteses.
2. Os especialistas em hardware também contribuem para estabelecer novas hipóteses e os testes correspondentes, caso sejam necessários, com base nos resultados obtidos na etapa anterior.

clique para ampliar a imagem

Figura 3:Análise dos resultados (RapiTime). (Fonte:Autores)

A imagem maior

O processo de design de teste de 7 etapas é apenas uma parte de uma metodologia de verificação multicore mais ampla mostrada anteriormente na Figura 2. Esta metodologia, que continuará a ser amadurecida como parte do projeto MASTECS, é projetada para alcançar rastreabilidade total, a partir de evidências abrangentes e resultados de volta aos requisitos e designs correspondentes. A metodologia é projetada para atender aos objetivos definidos no CAST-32A, o documento de orientação principal emitido pelas autoridades de certificação aeroespacial. Também está especificamente alinhado com a ISO 26262, o padrão de segurança para o setor automotivo, que defende a liberdade de interferência.

O CAST-32A foi publicado pela Equipe de Software das Autoridades de Certificação (CAST) em 2016 e identifica os fatores que afetam a segurança, o desempenho e a integridade dos sistemas de software aerotransportados em execução em processadores multicore. Se você deseja usar hardware multicore em um sistema aviônico, este é o documento obrigatório. Ele fornece objetivos destinados a orientar a produção de sistemas aviônicos multicore seguros, incluindo objetivos relacionados à identificação e limitação do impacto dos canais de interferência. Veja o documento de posição CAST-32A aqui. A EASA e a FAA estão trabalhando em uma adaptação do CRI genérico multicore em um material AMC / AC comum (AMC 20-193). Espera-se que seja publicado “ainda este ano” [3].

Experiência não pode ser automatizada

Os efeitos de interferência são complexos. Para desvendar seus mistérios, você precisa de especialistas que entendam tanto os componentes da arquitetura multicore quanto os sistemas de programação e alocação de recursos do software. A colaboração entre especialistas em hardware e software será uma característica central do projeto MASTECS à medida que continua no futuro. Mas enquanto a colaboração leva a grandes avanços em ferramentas de software e automação, é importante lembrar que você não pode automatizar todas as etapas de um processo de validação - especialmente quando a análise de tempo multicore está envolvida.

Você precisa de engenheiros experientes que conheçam os sistemas em detalhes. Por exemplo, durante os estágios iniciais, os especialistas em vários núcleos podem identificar as configurações do processador (também conhecidas como configurações críticas de hardware) que determinam o comportamento funcional e de temporização do software, bem como os canais de interferência em potencial. Quando se trata de analisar os resultados do teste, nada supera a entrada de um especialista humano experiente para revisitar e avaliar as suposições originais feitas sobre a plataforma e usar seu conhecimento para alimentar um novo ciclo de teste.

Referências

[1] Reinhard Wilhelm. Sentimentos mistos sobre crítica mista. Workshop sobre análise do tempo de execução do pior caso, 2018.

[2] Enrico Mezzetti, Leonidas Kosmidis, Jaume Abella, Francisco J. Cazorla. Unidades de monitoramento de desempenho de alta integridade em chips automotivos para cronometragem confiável V&V. IEEE Micro 38 (1):56-65 (2018).

[3] https://www.aviationtoday.com/2020/02/28/easa-and-faa-to-issue-further-guidance-on-multicore-certification-this-year/