Resumo Técnico: Arquitetura de Testabilidade Conjunta (JTA) para Software de Segurança Crítica

1. Declaração do Problema

Em sistemas de software de segurança crítica (ex: controle de voo, condução autônoma), a adequação da validação é frequentemente dificultada não pela falta de casos de teste, mas pela incapacidade de construir cenários críticos de forma estável, organizar evidências de execução em formas prontas para veredito ou atribuir resultados anormais a fronteiras de engenharia acionáveis. A pesquisa tradicional de testabilidade foca primariamente no artefato de software em si, tratando a testabilidade como uma propriedade estática do código (controlabilidade e observabilidade). No entanto, essa visão centrada no artefato é insuficiente para cenários de segurança crítica que envolvem ativação de failsafe, migração de modo ou coordenação de múltiplos componentes. Ela falha em abordar se a capacidade conjunta do cenário, do sistema de teste e do sistema sob teste (SUT) é suficiente para suportar uma validação adequada. Consequentemente, "o código ser testável" não garante que a "validação baseada em cenários seja adequada".

2. Metodologia: A Arquitetura de Testabilidade Conjunta (JTA)

A JTA redefine a testabilidade como uma capacidade condicionada ao cenário de um sistema conjunto. Ela propõe uma arquitetura formal e um fluxo de análise de cinco etapas para identificar e preencher lacunas de capacidade.

2.1 Modelo Formal

A arquitetura é definida como $JTA = \langle D_\Sigma, D_T, D_S, BC, BO, BI, L \rangle$, compreendendo:

• Três Domínios:
  • Domínio do Cenário ($D_\Sigma$): Organiza objetivos de validação, restrições e criticidade.
  • Domínio do Sistema de Teste ($D_T$): Abrange capacidades de estimulação, coleta de evidências e geração de vereditos.
  • Domínio do Sistema Sob Teste ($D_S$): Inclui o comportamento funcional e os ganchos de validação expostos (pontos de controle, pontos de evidência, fronteiras de responsabilidade).
• Três Pontes: Padrões arquiteturais que conectam os domínios para resolver incompatibilidades de capacidade:
  • Ponte de Controle ($BC$): Traduz precondições de cenário em configurações de parâmetros reproduzíveis e injeções de falhas.
    • Ponte de Evidência ($BO$): Organiza logs brutos e estados em evidências estruturadas e temporalmente alinhadas para vereditos automatizados.
  • Ponte de Atribuição ($BI$): Mapeia resultados anômalos para fontes de gatilho específicas e fronteiras de responsabilidade para permitir a remediação.
• Ciclo Fechado ($L$): Um processo iterativo de análise, design, avaliação e refinamento.

2.2 Conceitos Centrais

• Sistema de Testabilidade Conjunta ($JTS_\sigma$): A unidade de análise não é o software isolado, mas o triplete $\langle \sigma, T_\sigma, S_\sigma \rangle$ representando um cenário específico, as capacidades de teste participantes e a fronteira relevante do SUT.
• Contratos de Cenário ($SC(\sigma)$): Uma especificação de oito tuplas $\langle g, p, u, e, o, r, \kappa, \Theta \rangle$ que define explicitamente o objetivo de validação, precondições, modo de estimulação, evidência mínima, regras de veredito, um conjunto de fontes de falha distinguíveis ($r$), criticidade e limiares mínimos para controlabilidade, observabilidade e isolabilidade.
• Avaliação de Capacidade Conjunta:
  • Controlabilidade ($C$), Observabilidade ($O$) e Isolabilidade ($I$): Medidas tanto para o SUT ($CS, OS, IS$) quanto para o Sistema de Teste ($CT, OT, IT$).
  • Capacidade Conjunta ($JTCap$): Definida como o mínimo das capacidades do SUT e do Sistema de Teste para cada dimensão (ex: $JC = \min(CS, CT)$), refletindo o princípio do "elo mais fraco".
  • Adequação ($Adeq$): Um cenário é adequado apenas se as três dimensões conjuntas atenderem aos limiares mínimos definidos no contrato.
  • Pontos Cegos: Cenários onde $Adeq(\sigma) = 0$.

2.3 Fluxo de Trabalho de Cinco Etapas

1. Identificar Cenários Críticos: Determinar o conjunto $\Sigma$ e atribuir pesos de criticidade.
2. Instanciar Contratos de Cenário: Definir explicitamente objetivos, requisitos de evidência e o conjunto de fontes de falha a serem distinguidas.
3. Avaliar Capacidades Bilaterais: Avaliar $Cap_S$ e $Cap_T$ contra os requisitos do contrato.
4. Calcular Lacunas e Identificar Pontos Cegos: Calcular o vetor de lacuna de capacidade $Gap(\sigma)$ e identificar cenários que falham na adequação.
5. Design de Pontes e Reavaliação: Mapear lacunas para ações de design específicas nas pontes de Controle, Evidência ou Atribuição, e então reavaliar.

3. Principais Contribuições

1. Modelo de Sistema de Testabilidade Conjunta ($JTS_\sigma$): Expande o objeto de validação de um artefato isolado para uma entidade conjunta instanciada por cenário, composta pelo cenário, sistema de teste e SUT.
2. Contratos de Cenário com Conjuntos de Fontes de Falha: Introduz um contrato formal que inclui um conjunto de fontes de falha distinguíveis ($r$), transformando a isolabilidade de um conceito genérico em uma restrição de design concreta para atribuição.
3. Método de Design Orientado a Pontes: Propõe um framework de "três domínios, três pontes e um ciclo fechado" que mapeia lacunas de capacidade diretamente para ações de design arquitetural executáveis (ex: adicionar um controlador de tempo para a Ponte de Controle ou extensões de código de causa para a Ponte de Atribuição).
4. Análise Ilustrativa do ArduPilot: Demonstra a aplicação da JTA na validação de failsafe do ArduPilot, identificando pontos cegos específicos em cenários de perda de link e anomalias de estimativa de estado.

4. Resultados: Estudo de Caso ArduPilot

Os autores aplicaram a JTA a três cenários de failsafe no projeto open-source ArduPilot: perda de link RC (S1), timeout de heartbeat do GCS (S2) e anomalias de estimativa de estado EKF (S3).

• S1 (Perda de Link RC): Classificado como Adequado (1). O sistema de teste e o SUT suportam conjuntamente o cenário, embora existam alguns gargalos na estruturação de evidências.
• S2 (Timeout de Heartbeat do GCS): Classificado como Inadequado (0). Embora o cenário possa ser disparado, a Ponte de Atribuição é fraca; os logs atuais não conseguem distinguir entre timeouts genuínos e erros do ferramental de teste.
• S3 (Anomalias de EKF): Classificado como Inadequado (0). Este cenário revela gargalos tanto na Controlabilidade (dificuldade em desacoplar a força da perturbação e o tempo) quanto na Isolabilidade (ambiguidade em distinguir entre falhas de saúde do EKF e degradação simultânea do GPS).

Métrica de Nível de Sistema: A cobertura de adequação ponderada pela criticidade ($JT(JTS)$) para os cenários analisados foi calculada em 28,6%, destacando que cenários de alta criticidade (como anomalias de EKF) permanecem como pontos cegos significativos de validação, apesar da infraestrutura madura para cenários mais simples.

Recomendações de Design: A análise gerou ações específicas de nível de ponte, tais como:

• Adicionar uma "visão de atribuição triádica" (evento de timeout – código de causa – status do link) para S2.
• Implementar templates de perturbação parametrizados e adaptadores de replay habilitados para injeção para S3 para melhorar a controlabilidade.

5. Significância e Alegações

O artigo afirma que a JTA fornece uma base arquitetural para modelar, projetar e avaliar a validação baseada em cenários, em vez de substituir as técnicas existentes de teste ou análise de segurança.

• Mudança de Perspectiva: Muda o foco de "o código é testável?" para "o sistema conjunto é capaz de validar este cenário específico?".
• Resultado Acionável: Transforma impressões vagas de engenharia de "difícil de testar" em lacunas de design rastreáveis por dimensão, localizáveis por objeto e executáveis por ação.
• Validação Proativa: Defende o tratamento da capacidade de validação como um atributo de qualidade arquitetural que deve ser projetado junto com a capacidade funcional, em vez de ser verificado apenas após a implementação.
• Complementaridade: A JTA complementa métodos existentes como o STPA (que identifica cenários) e a injeção de falhas (que constrói anormalidades) ao fornecer o elo perdido para a avaliação da adequação conjunta e convergência de atribuição.

Os autores mantêm a modéstia em relação às suas alegações, observando que o estudo de caso é ilustrativo e depende de avaliações ordinais (H/M/L) em vez de métricas de desempenho quantitativas, e que a aplicabilidade a sistemas industriais fechados com interfaces restritas requer validação adicional.