💻 computer science

JTA: Joint Testability Architecture for Scenario-Based Validation of Safety-Critical Software

本文介绍了联合可测试架构（JTA），这是一种将场景、测试系统和被测系统统一为一个以可控性、可观测性和可隔离性为特征的单一设计对象的创新框架，旨在通过场景契约、能力评估和面向桥接的设计动作来增强安全关键软件的验证充分性。

原作者： Wenyao Xue, Jiandi Wang, Yichen Wang

发布于 2026-08-07

📖 1 分钟阅读☕ 轻松阅读

原作者： Wenyao Xue, Jiandi Wang, Yichen Wang

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正试图证明一辆自动驾驶汽车是否安全到足以驶上公路。你不能仅仅写下一堆“如果……怎么办”的问题，然后指望汽车能正确回答它们。你需要一个完整的团队协同工作：汽车本身（软件）、测试人员（运行测试的人和计算机）以及场景（特定的、棘手的状况，比如突如其来的暴雨或突然跳出的行人）。

在安全关键型软件领域——例如飞机、火车和自动驾驶汽车背后的智能大脑——这些成员经常脱节。汽车可能准备好了，但测试人员无法创造出那场精确的暴雨。或者，测试人员可以创造出风暴，但汽车无法清晰地“开口说话”，告诉他们为什么停了下来。这篇由北航大学研究人员撰写的论文解决了一个大问题：我们如何确保汽车、测试人员和测试场景都在同一个频道上？他们引入了一种新的思维方式，称为联合可测试性架构（Joint Testability Architecture, JTA）。JTA 不再孤立地观察软件代码，而是将这三者视为一个相互连接的整体系统。它针对每一个测试提出了三个简单而强大的问题：我们能否控制局面？我们能否观察到正在发生的事情？以及如果出了问题，我们能否精准定位究竟是谁或什么原因造成的？

问题所在：断裂的信任链

把测试安全关键型软件想象成试图在一个黑暗的房间里破解谜案。你有一个侦探（测试系统）、一个嫌疑人（被测系统，即软件）以及一个你需要重现的特定犯罪现场（场景）。

过去，研究人员主要关注嫌疑人。他们问：“代码的编写方式是否易于测试？”但本文作者认为，这就像是在没有检查侦探是否有手电筒，或者犯罪现场是否搭建正确的情况下，去询问嫌疑人是否容易受审。如果侦探无法打开灯（可观测性/Observability），或者如果犯罪现场过于混乱而无法重现（可控性/Controllability），那么世界上最好的代码也无济于事。

论文指出，“可测试性”不仅仅是代码的一个属性，它是代码、工具与场景之间关系的一种属性。如果这三个环节中的任何一个环节薄弱，整个验证过程就会失败。

解决方案：“三座桥梁”

为了解决这个问题，作者提出了一个名为**联合可测试性架构（JTA）**的蓝图。想象一下，场景、测试系统和软件是三个岛屿。为了让它们协同工作，你需要三座桥梁将它们连接起来。

控制桥（The Control Bridge）： 它连接测试系统与软件。它问道：“我们真的能迫使软件进入这种特定情况吗？”如果你想测试无人机失去远程信号时会发生什么，测试系统能否在准确的时刻可靠地切断该信号？如果这座桥断了，你甚至无法开始测试。
证据桥（The Evidence Bridge）： 它将软件连回测试系统。它问道：“我们能看到正在发生什么吗？”当无人机失去信号时，它是否以一种测试系统能理解的方式发出求救信号？它留下的是清晰的日志，还是仅仅是一堆混乱的数据？
归因桥（The Attribution Bridge）： 这是最关键的一个。它问道：“如果出了问题，我们知道为什么吗？”如果无人机坠毁了，是因为信号被切断了（真实问题），还是因为测试系统不小心过早切断了信号（虚假问题）？这座桥确保我们能够区分真实的故障与测试过程中的失误。

秘密武器：“场景契约”

论文引入了一个聪明的工具，叫做场景契约（Scenario Contract）。可以将它看作是针对每一次测试的严格清单或规则手册。在运行测试之前，你先写下你确切需要的东西：

测试什么？（目标）
如何触发它？（控制）
我们需要看到什么样的证据？（证据）
如果失败了，谁负责？（归因）

通过预先填写这份契约，你可以在浪费时间运行测试之前发现“盲点”。如果契约要求你区分两种类型的故障，但你的软件没有办法将它们区分开来，契约会立即揭示这一差距。

案例研究：ArduPilot 无人机

为了验证这个想法是否奏效，作者在 ArduPilot 上进行了测试，这是一个广泛用于无人机和机器人的开源飞行控制系统。他们观察了三个特定的“灾难”场景：

丢失遥控器： 无人机失去了与飞控手的连接。
丢失地面站： 无人机失去了与地面计算机的连接。
大脑混乱： 无人机的内部传感器（用于推测位置的传感器）开始提供错误数据。

他们的发现如下：

好消息： “丢失遥控器”场景表现得相当不错。测试系统可以轻松切断信号，且无人机有清晰的日志显示发生了这种情况。“控制”和“证据”两座桥梁都很稳固。
坏消息： “大脑混乱”场景简直是一团糟。测试系统难以创造出一个真实的“大脑混乱”情境（控制桥薄弱），即使做到了，无人机的日志也过于模糊，无法分辨这种混乱是来自传感器错误还是 GPS 故障（归因桥薄弱）。

作者计算了整个系统的“安全得分”。由于“大脑混乱”场景非常危险（高关键性），它的失败将整个系统的得分拉低到了仅 28.6%。这意味着，虽然无人机在处理简单的信号丢失方面做得很好，但目前很难证明它在面对复杂的传感器错误时是安全的。

核心启示

这篇论文并不声称已经“解决”了无人机安全问题，也没有修复了 ArduPilot 的代码。相反，它提供了一种新的诊断问题的方法。它表明，困难之处不仅在于代码难以编写，更在于整个测试系统处于失调状态。

通过使用“三座桥梁”和“场景契约”，工程师可以停止猜测测试失败的原因。他们可以查看清单并说：“啊，我们在归因桥上有一个缺口。我们需要添加一个特定的代码标签，以便区分传感器错误和 GPS 错误。”

简而言之，JTA 将“这很难测试”这种模糊的感觉，转化为了一个具体的、可操作的任务清单。它将讨论的核心从“代码好不好？”转向了“我们的整个测试团队是否已准备就绪，以证明代码是安全的？”对于任何构建旨在保护人类生命之软件的人来说，这是一个非常重大的转变。

技术摘要：面向安全关键软件的联合可测试性架构 (JTA)

1. 问题陈述

在安全关键软件系统（如飞行控制、自动驾驶）中，验证的充分性往往受限于并非缺乏测试用例，而是无法稳定地构建关键场景、无法将执行证据组织成可用于判定（verdict-ready）的形式，或无法将异常结果归因于可操作的工程边界。传统的测试性研究主要侧重于软件制品本身，将测试性视为代码的一种静态属性（可控性和可观测性）。然而，对于涉及失效保护激活、模式迁移或多组件协同的安全关键场景，这种以制品为中心的观点是不充分的。它未能解决场景、测试系统与被测系统（SUT）之间的“组合能力”是否足以支持充分验证的问题。因此，“代码具有可测试性”并不保证“基于场景的验证是充分的”。

2. 方法论：联合可测试性架构 (JTA)

JTA 将测试性重新定义为一种场景约束下的联合系统能力。它提出了一个正式的架构和一个五步分析工作流，用于识别并弥补能力差距。

2.1 形式化模型

该架构定义为 $JTA = \langle D_\Sigma, D_T, D_S, BC, BO, BI, L \rangle$ ，包含：

三个领域：
- 场景领域 ( $D_\Sigma$ )： 组织验证目标、约束和关键度。
- 测试系统领域 ( $D_T$ )： 涵盖刺激、证据收集和判定生成能力。
- 被测系统领域 ( $D_S$ )： 包括功能行为以及暴露的验证钩子（控制点、证据点、责任边界）。
三个桥梁： 连接各领域以解决能力失配的架构模式：
- 控制桥 ($BC$)： 将场景前置条件转化为可复现的参数设置和故障注入。
- 证据桥 ($BO$)： 将原始日志和状态组织成结构化的、时间对齐的证据，以支持自动化判定。
- 归因桥 ($BI$)： 将异常结果映射到特定的触发源和责任边界，以实现修复。
闭环 ( $L$ )： 一个由分析、设计、评估和改进组成的迭代过程。

2.2 核心概念

联合测试性系统 ( $JTS_\sigma$ )： 分析单元不再是孤立的软件，而是代表特定场景、参与测试的能力以及相关 SUT 边界的三元组 $\langle \sigma, T_\sigma, S_\sigma \rangle$ 。
场景契约 ( $SC(\sigma)$ )： 一个八元组规范 $\langle g, p, u, e, o, r, \kappa, \Theta \rangle$ ，明确定义了验证目标、前置条件、刺激模式、最小证据、判定规则、一组可区分的故障源 ( $r$ )、关键度，以及对可控性、可观测性和可隔离性的最小阈值。
联合能力评估：
- 可控性 ( $C$ )、可观测性 ( $O$ ) 和可隔离性 ( $I$ )： 分别针对 SUT ($CS, OS, IS $) 和测试系统 ($ CT, OT, IT$) 进行测量。
- 联合能力 ($JTCap$)： 定义为 SUT 和测试系统在每个维度上的最小能力（例如， $JC = \min(CS, CT)$ ），体现了“木桶效应”（短板原则）。
- 充分性 ($Adeq$)： 只有当所有三个联合维度都满足契约中定义的最小阈值时，场景才是充分的。
- 盲点： 满足 $Adeq(\sigma) = 0$ 的场景。

2.3 五步工作流

识别关键场景： 确定集合 $\Sigma$ 并分配关键度权重。
实例化场景契约： 明确定义目标、证据要求以及待区分的故障源集。
评估双边能力： 根据契约要求评估 $Cap_S$ 和 $Cap_T$ 。
计算差距并识别盲点： 计算能力差距向量 $Gap(\sigma)$ 并识别不满足充分性的场景。
桥梁设计与再评估： 将差距映射到控制桥、证据桥或归因桥的具体设计动作上，然后进行再评估。

3. 主要贡献

联合测试性系统模型 ( $JTS_\sigma$ )： 将验证对象从孤立的制品扩展为由场景、测试系统和 SUT 组成的场景实例化的联合实体。
带有故障源集的场景契约： 引入了一个包含可区分故障源集 ( $r$ ) 的正式契约，将“可隔离性”从一个通用概念转变为用于归因的具体设计约束。
面向桥梁的设计方法： 提出了一个“三领域、三桥梁及一闭环”的框架，将能力差距直接映射到可执行的架构设计动作（例如，在控制桥中添加定时控制器，或在归因桥中添加原因码扩展）。
ArduPilot 阐释性分析： 展示了 JTA 在 ArduPilot 失效保护验证中的应用，识别了链路丢失和状态估计异常场景中的具体盲点。

4. 结果：ArduPilot 案例研究

作者将 JTA 应用于开源项目 ArduPilot 的三个失效保护场景：遥控器 (RC) 链路丢失 (S1)、地面站 (GCS) 心跳超时 (S2) 以及 EKF 状态估计异常 (S3)。

S1 (RC 链路丢失)： 被评定为 充分 (1)。测试系统与 SUT 共同支持该场景，尽管在证据结构化方面存在一些瓶颈。
S2 (GCS 心跳超时)： 被评定为 不充分 (0)。虽然可以触发该场景，但其 归因桥 较弱；当前的日志无法区分真实的超时与测试工具链错误。
S3 (EKF 异常)： 被评定为 不充分 (0)。该场景揭示了 可控性（难以解耦扰动强度与时序）和 可隔离性（难以区分 EKF 健康故障与并发的 GPS 退化）方面的瓶颈。

系统级指标： 分析场景的关键度加权充分性覆盖率 ($JT(JTS)$) 计算为 28.6%，这表明尽管对于简单的场景已有成熟的基础设施，但高关键度场景（如 EKF 异常）仍然存在显著的验证盲点。

设计建议： 分析产生了具体的桥梁级行动建议，例如：

为 S2 添加“三元归因视图”（超时事件–原因码–链路状态）。
为 S3 实现参数化扰动模板和支持注入的重放适配器，以提高可控性。

5. 意义与主张

本文主张 JTA 为建模、设计和评估基于场景的验证提供了一个架构基础，而非取代现有的测试或安全分析技术。

视角转变： 它将关注点从“代码是否可测试？”转向“联合系统是否能够验证这个特定场景？”
可操作的输出： 它将模糊的工程直觉（如“难以测试”）转化为维度可追踪、对象可定位且动作可执行的设计差距。
主动验证： 它倡导将验证能力视为一种架构质量属性，应与功能能力一同进行设计，而不是仅在实现后才进行检查。
互补性： JTA 通过提供评估联合充分性和归因收敛性的缺失环节，与 STPA（识别场景）和故障注入（构建异常）等现有方法形成互补。

作者对其主张保持了谦逊的态度，指出案例研究具有阐释性，且依赖于定序（高/中/低）评估而非定量性能指标，并指出 JLA 在接口受限的封闭工业系统中的适用性仍需进一步验证。