Programa de Pós-Graduação em Ciência da Computação PUCRS

1. Confiabilidade de Sistemas Prof. Eduardo Bezerra Non-intrusive Software-Implemented Fault Injection in Embedded Systems Guilherme Guindani Programa de Pós-Graduação em Ciência da ComputaçãoPUCRS

2. SUMÁRIO • Introdução • Definições de Injeção de Falhas • Injeção de falhas de HW • Injeção de falhas de SW • Injeção de falhas baseadas no Nexus • Técnica de injeção de falhas utilizada • Estudo de caso: ECU de um carro • Conclusões

3. Introdução • A avaliação da dependabilidade envolve o estudo de erros e defeitos • Realizadas experimentações nas fases de • Conceito • Projeto • Operacional • Diferentes técnicas de injeção de falhas são usadas em diferentes fases do projeto • Técnicas empregadas são baseadas em: • Simulação (baixo custo)‏ • Protótipo (alta precisão)‏

4. Definições • Ambiente de Injeção de falhas:

5. Definições • Método de implementação • Hardware (HWIFI)‏ • Software (SWIFI)‏ • HWIFI: • Open • Bridging • Bit-flip • Corrente espúria • Surto de tensão • Stuck-at • SWIFI: • Corrupção dos dados (registradores, memoria e disco)‏ • Corrupção na comunicação (barramento, NoC ou rede)‏ • Manifestação de erros no software (nível de máquina ou superiores)‏

6. HW Fault Injection • Com contato direto • Pinos do chip • Sockets • Produzem falhas a nível de tensão e/ou corrente • Probes ativos → Utilizados em falhas stuck-at e bridging • Inserção de sockets → entre o chip e sua placa de circuito impresso (PCB)‏ • Stuck-at, open ou demais falhas mais complexas • Boa controlabilidade das falhas • Pouca ou nenhuma pertubação no sistema alvo

7. HW Fault Injection • Sem contato • Fonte externa de falhas • Pulsos eletromagnéticos (EMP)‏ • Radiação • Imitam fenômenos naturais os quais os circuitos podem estar sujeitos • Difícil de controlar • Local • Tempo • Ferramentas de injeção em HW: • Messaline • FIST

8. SW Fault Injection • São atrativos pois não requerem HW adicional (encaresse o teste)‏ • Alvos: • Aplicações • Sistemas operacionais • Desvantagens: • Não insere falhas em áreas inacessíveis ao SW • Pode atrapalhar a carga de trabalho do software em teste e/ou modificar sua estrutura original • Baixa resolução temporal → causar problemas de fidelidade no teste

9. SW Fault Injection • Injeção em tempo de compilação • Modifica a estrutura do programa antes de ser carregado e executado • Falhas no código objeto • Emulam falhas de HW, SW e transientes • Injeção em tempo de execução • Mecanismos de ativação da inserção de falhas • Time-out • Exceção/Trap • Inserção de código • Ferramentas de injeção em SW: • Ferrari • Ftape • Doctor • Xception

10. Nexus Fault Injection • Nexus → Padrão de debug de sistemas embarcados • Definido pelo Nexus 5001 Forum • Hitachi, Infineon, Motorola, National e ST • Dividido em 4 classes • Portabilidade → Debugging universal, utilizando uma porta específica “Nexus port” • Sobrecarga temporal introduzida pelo SWIFI • Seleção do momento de iserir as falhas (trigger)‏ • Corrupção dos locais de memória de sistema (injeção da falha)‏

11. Nexus Fault Injection • Nexus Watchpoints • Parte do circuito de debug do Nexus • Utilizados para sinalizar eventos nas aplicações, sem parar a execução da aplicação • Eventos nas aplicações: • Execução de uma dada instrução • Acesso à uma palavra de memória pré-determinada

12. Nexus Fault Injection • Acesso à memória em tempo de execução • Resolve o problema de inserir falhas sem interferir na execução normal do sistema em teste • Inserir falhas em uma parte da memória antes que esta seja utilizada • Observabilidade do SWIFI Nexus • Mensagens de rastreamento (traces)‏ • Saltos (branches)‏ • Dados (data)‏ • Grafo do fluxo de controle da aplicação • Monitoramento das operações de escrita e leitura na memória (inserção de falhas)‏

13. Injeção de Falhas Empregada • Aplicações de um SoC são aplicações que estão sendo executadas em um chip • Problemas: • Observabilidade • Controlabilidade • Presença ou não de falhas • Injeção de falhas em SoCs • Complexidade • Escala de integração dos componentes

14. Injeção de Falhas Empregada • Nesta seção serão respondidas as seguintes perguntas: • Quais são os conjuntos de falhas que a técnica consegue inserir? • Como é determinado o momento em que a falha deverá ser inserida? • Quais são os passos que devem ser seguidos para inserir uma falha?

15. Injeção de Falhas Empregada • Quais são os conjuntos de falhas que a técnica consegue inserir? • Modelo de falhas utilizado: Falhas de HW • Stuck-at • Bit-flip (representa a maior parte das falhas)‏ • Inserindo falhas de bit-flip (3 passos): • Ler o conteúdo da memória alvo (posição/registrador)‏ • Alterar seu conteúdo (XOR com uma máscara)‏ • Re-escrita do novo valor no mesmo local • Inserindo falhas stuck-at: • Monitoramento contínuo de um local alvo • Quando este local for utilizado, é inserida a falha • Stuck-at '1' • Stuck-at '0'

16. Injeção de Falhas Empregada • Como é determinado o momento em que a falha deverá ser inserida? • Definidos dois esquemas de disparo de falhas: • Temporal • Espacial • Temporal: • A inserção da falha é dada em um certo parâmetro de tempo associado à execução do sistema • Espacial: • A falha é inserida quando a aplicação atinge certo estado ou condição • Instrução específica ou ativação de um evento (exception)‏

17. Injeção de Falhas Empregada • Utilização separada ou combinada

18. Injeção de Falhas Empregada • Quais são os passos que devem ser seguidos para inserir uma falha? Inserção de falhas é feita em tempo de execução • Não pára a aplicação • Não altera sua estrutura original Durante a configuração inicial 2 endereços de memória são definidos • Sincronização do fluxo de execução com a inserção da falha (A)‏ • Indica o endereço de memória em que será inserida a falha (B)‏ Wacthpoint é configurado em A (trigger espacial)‏ • Quando oprograma atingir este endereço dispara um contador interno/externo (trigger temporal)‏ Expirando o contador a falha é inserida em B

19. Estudo de Caso: ECU • Unidade de Controle Eletrônico (ECU) de um motor à Diesel • 2 processos distintos, porém fisicamente casados • Inserção de combustível • Gerenciamento de ar • Controlados por: • Reguladores integrais-proporcinonais (PI)‏ • Controladores liga-desliga • Configurados por tabelas de parâmetros • Comportamento do motor é modelado

20. Estudo de Caso: ECU • Gráfico dos laços de controle da ECU

21. Estudo de Caso: ECU • Para estudar o comportamento da ECU na presença de falhas • INERTE (Integrated NExus-based Real-Time fault injection tool for Embedded systems)‏

22. Estudo de Caso: ECU • Experiment Generator Module (EGM)‏ • Entradas: • As faixas de endereço de memória onde as falhas serão inseridas • Número de falhas a serem inseridas • Distribuição das falhas (uniforme, normal ou erlang)‏ • Saída: • Arquivos de configuração (CF) para o insersor de falhas

23. Estudo de Caso: ECU • Fault Injector (FI)‏ • Implementado como um script Nexus • Entrada: • Arquivo de configuração de falhas (CF)‏ • Gerado pelo EGM • Após a inicialização do ECU (reset): • O FI insere as falhas e espera a sua ativação • O FI coleta informações de rastramento (traces)‏

24. Estudo de Caso: ECU • Analysis Tool (AT)‏ • Parser que compara os relatórios dos traces com dados de execuções sem falhas (golden-runs)‏ • Extrai informações temporais das falhas • Avalia se as falhas dispararam errors e se estes foram detectados • Verifica se foram produzidos defeitos

25. Estudo de Caso: ECU • Procedimento experimental

26. Estudo de Caso: ECU • Resultados: • 3000 experimentos • 1000 segmentos de memória do tipo read-only • 1000 segmentos de memória do tipo read-write • 1000 memória de código • 12% das falhas inseridas foram ativadas • 88% dos experimentos as falhas não afetaram o comportamento do motor

27. Estudo de Caso: ECU • Resultados: • 16% dos erros ficaram dormentes • Não acarretaram em um defeito no motor • Dos erros que afetaram o funcionamento do motor: • 37% provocaram um defeito no motor • 44% foram detectados pelo mecanismo de detecção de erros empregado: MPC565 buit-in exceptions • 3% foram detectados tarde demais, levando à uma falha do motor

28. Conclusões • Bom sistema de injeção de falhas em SoCs • Não provoca sobrecargas no sistemas • Realizado em tempo de execução • Dependente do padrão Nexus • Baixa inter-portabilidade • Escalável? • MPSoCs

29. Non-intrusive Software-Implemented Fault Injection in Embedded Systems Obrigado! Perguntas?! Guilherme Guindani Programa de Pós-Graduação em Ciência da ComputaçãoPUCRS