Resumen Técnico: Arquitectura de Testabilidad Conjunta (JTA) para Software de Seguridad Crítica

1. Planteamiento del Problema

En los sistemas de software de seguridad crítica (por ejemplo, control de vuelo, conducción automatizada), la adecuación de la validación suele verse obstaculizada no por una falta de casos de prueba, sino por la incapacidad de construir escenarios críticos de manera estable, organizar la evidencia de ejecución en formas listas para el veredicto, o atribuir resultados anormales a límites de ingeniería accionables. La investigación tradicional sobre la testabilidad se centra principalmente en el artefacto de software en sí, tratando la testabilidad como una propiedad estática del código (controlabilidad y observabilidad). Sin embargo, esta visión centrada en el artefacto es insuficiente para escenarios de seguridad crítica que involucran la activación de mecanismos de falla segura (failsafe), migración de modos o coordinación de múltiples componentes. No aborda si la capacidad conjunta del escenario, el sistema de prueba y el sistema bajo prueba (SUT) es suficiente para soportar una validación adecuada. En consecuencia, que el "código sea testeable" no garantiza que la "validación basada en escenarios sea adecuada".

2. Metodología: La Arquitectura de Testabilidad Conjunta (JTA)

La JTA redefine la testabilidad como una capacidad condicionada por el escenario de un sistema conjunto. Propone una arquitectura formal y un flujo de trabajo de análisis de cinco pasos para identificar y cerrar las brechas de capacidad.

2.1 Modelo Formal

La arquitectura se define como $JTA = \langle D_\Sigma, D_T, D_S, BC, BO, BI, L \rangle$, que comprende:

• Tres Dominios:
  • Dominio del Escenario ($D_\Sigma$): Organiza los objetivos de validación, las restricciones y la criticidad.
  • Dominio del Sistema de Prueba ($D_T$): Abarca las capacidades de estimulación, recolección de evidencia y generación de veredictos.
  • Dominio del Sistema Bajo Prueba ($D_S$): Incluye el comportamiento funcional y los ganchos de validación expuestos (puntos de control, puntos de evidencia, límites de responsabilidad).
• Tres Puentes: Patrones arquitectónicos que conectan los dominios para resolver desajustes de capacidad:
  • Puente de Control ($BC$): Traduce las precondiciones del escenario en configuraciones de parámetros reproducibles e inyecciones de fallas.
  • Puente de Evidencia ($BO$): Organiza los registros (logs) brutos y estados en evidencia estructurada y temporalmente alineada para veredictos automatizados.
  • Puente de Atribución ($BI$): Mapea los resultados anómalos hacia fuentes de activación específicas y límites de responsabilidad para permitir la remediación.
• Bucle Cerrado ($L$): Un proceso iterativo de análisis, diseño, evaluación y refinamiento.

2.2 Conceptos Clave

• Sistema de Testabilidad Conjunta ($JTS_\sigma$): La unidad de análisis no es el software aislado, sino el triplete $\langle \sigma, T_\sigma, S_\sigma \rangle$ que representa un escenario específico, las capacidades de prueba participantes y el límite relevante del SUT.
• Contratos de Escenario ($SC(\sigma)$): Una especificación de ocho elementos $\langle g, p, u, e, o, r, \kappa, \Theta \rangle$ que define explícitamente el objetivo de validación, las precondiciones, el modo de estimulación, la evidencia mínima, las reglas de veredicto, un conjunto de fuentes de falla distinguibles ($r$), la criticidad y los umbrales mínimos de controlabilidad, observabilidad e isolabilidad.
• Evaluación de Capacidad Conjunta:
  • Controlabilidad ($C$), Observabilidad ($O$) e Isolabilidad ($I$): Medidas tanto para el SUT ($CS, OS, IS$) como para el Sistema de Prueba ($CT, OT, IT$).
  • Capacidad Conjunta ($JTCap$): Definida como el mínimo de las capacidades del SUT y del Sistema de Prueba para cada dimensión (por ejemplo, $JC = \min(CS, CT)$), reflejando el principio del "eslabón más débil".
  • Adecuación ($Adeq$): Un escenario es adecuado solo si las tres dimensiones conjuntas cumplen con los umbrales mínimos definidos en el contrato.
  • Puntos Ciegos: Escenarios donde $Adeq(\sigma) = 0$.

2.3 Flujo de Trabajo de Cinco Pasos

1. Identificar Escenarios Críticos: Determinar el conjunto $\Sigma$ y asignar pesos de criticidad.
2. Instanciar Contratos de Escenario: Definir explícitamente los objetivos, los requisitos de evidencia y el conjunto de fuentes de falla a distinguir.
3. Evaluar Capacidades Bilaterales: Evaluar $Cap_S$ y $Cap_T$ frente a los requisitos del contrato.
4. Calcular Brechas e Identificar Puntos Ciegos: Calcular el vector de brecha de capacidad $Gap(\sigma)$ e identificar escenarios que fallan en adecuación.
5. Diseño de Puentes y Reevaluación: Mapear las brechas a acciones de diseño específicas en los puentes de Control, Evidencia o Atribución, y luego reevaluar.

3. Principales Contribuciones

1. Modelo de Sistema de Testabilidad Conjunta ($JTS_\sigma$): Expande el objeto de validación de un artefacto aislado a una entidad conjunta instanciada por el escenario, que comprende el escenario, el sistema de prueba y el SUT.
2. Contratos de Escenario con Conjuntos de Fuentes de Falla: Introduce un contrato formal que incluye un conjunto de fuentes de falla distinguibles ($r$), transformando la isolabilidad de un concepto genérico en una restricción de diseño concreta para la atribución.
3. Método de Diseño Orientado a Puentes: Propone un marco de "tres dominios, tres puentes y un bucle cerrado" que mapea las brechas de capacidad directamente a acciones de diseño arquitectónico ejecutables (por ejemplo, añadir un controlador de tiempo al Puente de Control o extensiones de códigos de causa al Puente de Atribución).
4. Análisis Ilustrativo de ArduPilot: Demuestra la aplicación de JTA en la validación de failsafe de ArduPilot, identificando puntos ciegos específicos en escenarios de pérdida de enlace y anomalías de estimación de estado.

4. Resultados: Caso de Estudio ArduPilot

Los autores aplicaron JTA a tres escenarios de failsafe en el proyecto de código abierto ArduPilot: pérdida de enlace RC (S1), tiempo de espera de latido (heartbeat) de GCS (S2) y anomalías de estimación de estado EKF (S3).

• S1 (Pérdida de Enlace RC): Calificado como Adecuado (1). El sistema de prueba y el SUT soportan conjuntamente el escenario, aunque existen algunos cuellos de botella en la estructuración de la evidencia.
• S2 (Tiempo de Espera de Latido de GCS): Calificado como Inadecuado (0). Aunque el escenario puede activarse, el Puente de Atribución es débil; los registros actuales no pueden distinguir entre tiempos de espera genuinos y errores de la herramienta de la cadena de herramientas de prueba.
• S3 (Anomalías de EKF): Calificado como Inadecuado (0). Este escenario revela cuellos de botella tanto en la Controlabilidad (dificultad para desacoplar la fuerza de la perturbación y el tiempo) como en la Isolabilidad (ambigüedad al distinguir entre fallas de salud del EKF y la degradación concurrente del GPS).

Métrica a Nivel de Sistema: La cobertura de adecuación ponderada por criticidad ($JT(JTS)$) para los escenarios analizados se calculó en 28.6%, resaltando que los escenarios de alta criticidad (como las anomalías de EKF) siguen siendo puntos ciegos de validación significativos a pesar de contar con una infraestructura madura para escenarios más simples.

Recomendaciones de Diseño: El análisis produjo acciones específicas a nivel de puente, tales como:

• Añadir una "vista de atribución triádica" (evento de tiempo de espera–código de causa–estado del enlace) para S2.
• Implementar plantillas de perturbación parametrizadas y adaptadores de reproducción habilitados para la inyección para S3 para mejorar la controlabilidad.

5. Significado y Reivindicaciones

El artículo sostiene que la JTA proporciona una base arquitectónica para modelar, diseñar y evaluar la validación basada en escenarios, en lugar de reemplazar las técnicas existentes de prueba o análisis de seguridad.

• Cambio de Perspectiva: Desplaza el enfoque de "¿es el código testeable?" a "¿es el sistema conjunto capaz de validar este escenario específico?".
• Resultado Accionable: Transforma las impresiones de ingeniería vagas de "difícil de probar" en brechas de diseño trazables por dimensión, localizables por objeto y ejecutables por acción.
• Validación Proactiva: Aboga por tratar la capacidad de validación como un atributo de calidad arquitectónica que debe diseñarse junto con la capacidad funcional, en lugar de verificarse solo después de la implementación.
• Complementariedad: La JTA complementa métodos existentes como STPA (que identifica escenarios) y la inyección de fallas (que construye anormalidades) al proporcionar el eslabón perdido para evaluar la adecuación conjunta y la convergencia de la atribución.

Los autores mantienen la modestia respecto a sus afirmaciones, señalando que el caso de estudio es ilustrativo y depende de evaluaciones ordinales (H/M/L) en lugar de métricas de rendimiento cuantitativas, y que la aplicabilidad a sistemas industriales cerrados con interfaces restringidas requiere una validación adicional.