AI 摘要 · 由英文经 AI 翻译
JTA: Joint Testability Architecture for Scenario-Based Validation of Safety-Critical Software
Wenyao Xue, Jiandi Wang, Yichen Wang
TL;DR
现有可测试性研究大多以工件为中心，而安全关键软件的验证还取决于场景构建、证据对齐和故障归因。JTA将场景、测试系统和被测系统放在一起分析，采用能力维度和面向桥接关系的设计。在ArduPilot示例中，链路丢失验证相对成熟，而GCS超时和EKF异常场景仍存在较大的盲区。
问题
现有可测试性研究通常将软件工件作为分析对象，对场景、测试系统和被测系统之间联合的场景化验证能力关注不足。
出处：§1 · p. 1, §2.4 · p. 2方法
JTA将场景、测试系统和被测系统建模为一个联合实体，并运用场景契约、三个能力维度和面向桥接关系的行动来评估并弥补差距。
出处：§1 · pp. 1–2, §3.3 · p. 3, §3.7 · p. 5结果
ArduPilot评估表明，现有测试资产对RC链路丢失的覆盖尚可，但GCS超时和EKF异常场景仍存在显著的联合充分性盲区。
出处：S3 EKF · p. 8启示与局限
案例表明，验证难度可能源于场景需求、测试系统能力与系统开放接口之间的不匹配，且瓶颈因场景而异。
出处：§5.5 · p. 9这项工作属于方法与架构研究，并未报告实施桥接行动后的改进效果；其中示例性的H/M/L评级包含工程判断。
出处：§6.3 · p. 9
Abstract
from arXiv · showhide
Validation adequacy in safety-critical software depends on more than the system under test. Critical scenarios must be constructed under controlled conditions, execution evidence must be aligned into verdict-ready form, and abnormal outcomes must be attributable to actionable causes. Existing testability research remains largely artifact-centric and offers little architectural support for reasoning about the combined capability of the scenario, the test system, and the system under test. Joint Testability Architecture (JTA) addresses this gap by treating those three elements as a single object of analysis and design. It characterizes validation capability along three dimensions--controllability, observability, and isolability--and organizes them through three domains, three bridges, and an analysis-design-evaluation-refinement loop. JTA also introduces scenario contracts, joint capability assessment, validation blind-spot identification, and bridge-oriented design actions that map capability gaps to concrete improvements in control points, evidence organization, and attribution boundaries. An illustrative analysis of ArduPilot failsafe validation shows that link-loss scenarios are comparatively mature, whereas state-estimation anomaly scenarios remain harder to validate because evidence alignment and attribution semantics are weaker. JTA is not a replacement for existing testing or safety-analysis techniques; it provides an architectural basis for modeling, designing, and assessing scenario-based validation in safety-critical software.
1. 引言
安全关键软件的验证不只取决于是否有测试用例：还必须构造场景、整理证据以形成判定，并将异常结果归因到可采取行动的边界。JTA 将场景、测试系统和被测系统视为一个受场景约束的联合能力对象，用于评估和改进。
1. 引言
- 验证难点往往在于如何稳定地构造场景、整理可用于判定的证据，并实现可采取行动的归因，而非单纯缺少测试用例。论文将这些视为系统级能力，并指出它们由场景、测试系统和被测系统共同塑造。出处：§1 · p. 1
- 仅从工件角度研究可测试性，无法判断现有系统能否充分验证故障保护及其他安全关键场景。论文探讨测试系统、脚本、仿真和开放接口能否协同支持基于场景的验证。出处：§1 · p. 1
- 研究问题包括如何统一场景、测试系统和被测系统，如何将三项能力维度转化为可操作的评估方式，以及如何将能力缺口转化为设计行动。这三项维度是可控性、可观测性和可隔离性。出处：§1 · p. 1
- JTA 将联合可测试性系统定义为由场景实例化、包含场景、测试系统和被测系统的实体。这使验证对象不再局限于孤立的软件工件。出处：§1 · p. 1
- JTA 将场景契约、联合充分性评估与面向桥接关系的设计行动结合起来，并通过 ArduPilot 故障保护验证加以说明。这些行动针对控制、证据和归因桥接关系；案例揭示了链路故障和状态估计异常场景中的验证盲点。出处：§1 · p. 2
2. 背景与相关工作
已有研究涉及工件层面的可测试性、安全场景分析和显式测试建模，但未能联合评估场景、测试系统和被测系统的能力。JTA作为一种架构性应对方案，旨在将充分性评估落到实处，并将验证盲点映射为设计行动。
2.1 以工件为中心的可测试性研究
- 以工件为中心的可测试性研究强调可控性、可观测性和设计干预，但通常将软件工件作为分析对象。相关基础包括早期可测试性研究 、ISO/IEC 25010 、设计层面的工作 、、，以及 MBSE/DFT 。出处：§2.1 · p. 2
2.2 安全关键系统验证与故障驱动评估
- 安全验证方法关注危害、场景和证据，但无法直接判定现有测试系统与软件能否共同支持充分验证。JTA被定位为一种互补方案：故障注入可以构造异常，但本身并不能确保证据结构化或归因收敛。出处：§2.2 · p. 2
2.3 测试架构、基于模型的测试与 UTP
- MBT、UTP、标准和基于契约的验证对测试工件或活动进行建模；JTA则针对联合能力缺口和架构行动。UTP可以提供一种表示路径，但建模表示法的完备性并非 JTA 方法论的核心。出处：§2.3 · p. 2
2.4 研究定位
- JTA通过联合分析场景、测试系统和被测系统，将充分性评估落到实处，并把验证盲点映射为架构行动，以应对上述研究缺口。该研究定位指出，现有方法未能同时满足这三项要求。出处：§2.4 · pp. 2–3
3. 架构与形式化模型
JTA 将基于场景的验证建模为一种联合架构，涵盖场景、测试系统和被测系统，并据此评估能力缺口、指导桥接层面的设计行动。其契约和评审规程使可控性、可观测性和可隔离性能够依据场景需求进行评估。
3.1 架构定义
- JTA 将该架构形式化为三个域、三座桥接，以及一个涵盖分析、设计、评估和改进的闭环。这些域分别表示场景意图、测试系统能力和被测系统暴露情况；桥接用于连接各域。出处：§3.1 · p. 3, §3.7 · p. 5
3.2 联合可测试性系统
- 对于关键场景，联合可测试性系统包括参与其中的测试能力和相关的被测系统边界，而非孤立的软件制品。在项目层面，该系统由关键场景集、测试系统和被测系统共同界定。出处：§3.2 · p. 3
3.3 场景契约
- 场景契约规定目标、约束、激励、最低证据要求、判定规则、需区分的故障源以及能力阈值。明确纳入故障源集合，可将可隔离性设为设计约束，并与归因义务和可操作证据相挂钩。出处：§3.3 · p. 3
3.4 三个能力维度的操作化
- JTA 将场景所需义务与系统暴露出的控制点、证据点和归因点进行比较，以评估可控性、可观测性和可隔离性。可观测性关注能否看到相关事实；可隔离性关注这些事实能否区分候选故障源，并将其归结为可采取行动的原因。出处：§3.4 · pp. 3–4
3.5 评分与评审规程
- 追踪矩阵评审提取所需点和已暴露点，将系统侧覆盖情况映射为 H/M/L 评级，并确保专家判断可审计。评级标准为：覆盖率达到 80% 或以上且无关键点缺失时评为 H；覆盖率为 50–80% 或覆盖情况存在部分歧义时评为 M；覆盖率低于 50% 或存在关键点缺失时评为 L。出处：§3.5 · p. 4, Table I · p. 4
3.6 联合能力、场景充分性与验证盲区
- 联合能力取测试系统和被测系统能力中的较低值，因此较弱的一方会成为瓶颈；充分性和能力缺口用于识别验证盲区。项目层面的度量汇总了关键场景中按关键性加权的充分性覆盖情况。出处：§3.6 · pp. 4–5
3.7 三个域、三座桥接与闭环
- 场景域组织契约和需求，测试系统域提供验证功能，被测系统域则暴露控制点、证据点和责任点。JTA 为控制、证据和归因桥接赋予不同职责，因为跨边界的不匹配需要不同的设计应对。出处：§3.7 · p. 5
- 桥接行动针对已识别的缺口：控制机制产生可重复的激励，证据机制使证据与判定规则相匹配，归因机制则使来源、原因和边界相互对应。分析—设计—评估—改进闭环会在新增桥接后重新检查充分性，并将剩余缺口纳入下一轮建模。出处：§3.7 · p. 5
4. 方法论
该方法论用于识别关键场景、评估其联合能力与缺口，并将缺口映射为面向桥接机制的设计措施。它既支持对现有系统进行改造，也支持在系统设计阶段协同构建。
4.1 五步分析工作流
- 五步工作流用于识别并确定关键场景的优先级、实例化场景契约、评估测试系统与被测系统的能力、计算缺口，并通过重新评估落实桥接设计。存在非零能力缺口的场景进入设计阶段；持续重新评估，直至满足最低要求，或明确说明剩余风险。出处：§4.1 · pp. 5–6
4.2 能力缺口与桥接设计模式
- Table III 将三类能力缺口的典型症状映射到相应的设计模式。工作流依据缺口构成，选择针对控制桥、证据桥或归因桥的措施。出处：§4.2 · p. 6, §4.1 · p. 6
4.3 两种采用模式
- JTA 可围绕现有系统中的关键场景改造桥接机制，也可在早期运用场景契约约束系统设计。文中案例研究采用改造方式，但该方法支持这两种采用模式。出处：§4.3 · p. 6
5. 案例：ArduPilot
ArduPilot 案例使用按场景划分的资产、序数能力评估和桥接层改进路径，将 JTA 应用于三个失效保护场景。结果表明，链路相关验证相对成熟，而 GCS 超时和 EKF 异常场景仍存在各自的能力缺口。
5.1 案例目标与分析流程
- 本案例采用统一的 H/M/L 评估标准评估失效保护相关资产，并报告能力判断和设计路径，而非采取措施后的性能增益。出处：§5.1 · pp. 6–7
5.2 场景契约实例化
- 每份场景契约记录其目标、激励方式、最低证据要求和明确的故障源集合；EKF 异常的关键性权重更高（κS3 = 1.5; κS1 = κS2 = 1.0）。出处：§5.2 · p. 7
S2 GCS
- 对于 GCS 心跳超时，核心缺口在于归因：日志和原因语义无法可靠地区分真实超时与测试工具链控制错误。出处：§5.3 · p. 7
S3 EKF
- EKF 异常需要更精细的扰动控制和跨组件语义归因，暴露出可控性与可隔离性瓶颈。出处：§5.3 · p. 7, S3 EKF · p. 8
5.3 联合能力评估
- RC 链路丢失达到最低充分性，而 GCS 超时和 EKF 异常场景仍存在明显的联合能力盲区。出处：§5.3 · p. 7, Table V · p. 8, S3 EKF · p. 8
5.4 代表性能力缺口与桥接设计措施
- 面向桥接的措施使能力缺口能够追溯到工程改动；对于 S3，重点是构造可控异常并明确责任边界，而非不加区分地记录日志。出处：§5.4 · p. 8, Table VI · p. 9
5.5 发现与讨论
- 本案例将验证难度与场景要求、测试系统能力和可用接口之间的不匹配联系起来，支持按场景设定条件，而非采用单一系统级可测试性评估。出处：§5.5 · p. 9
6. 讨论
JTA 的新意在于开展场景条件化的联合充分性审查，将故障源相关要求纳入其中，并把能力缺口映射为桥接层面的设计措施。它推动验证转向主动式架构设计，但本研究仍局限于示例性评估和 ArduPilot 案例。
6.1 创新点与研究定位
- JTA 的新意在于开展场景条件化的联合充分性审查，将故障源相关要求纳入其中，并把能力缺口映射为控制、证据和归因桥接措施。其贡献不只是追踪故障源，还在于将这项工作用于对场景、测试系统和 SUT 的联合审查。出处：§6.1 · p. 9
6.2 对安全关键软件工程的启示
- JTA 将验证视为架构问题，通过场景契约主动组织测试系统、证据和责任边界。论文将这一转变与保障论证工程、左移验证、跨团队协作以及面向生命周期的 V&V 联系起来。出处：§6.2 · p. 9
6.3 局限性与有效性威胁
- 本研究展示了 JTA 的分析与设计组织方式，并未证明实施桥接措施后能够提升性能或带来认证收益。场景边界和最低证据集的定义仍依赖研究者判断。出处：§6.3 · pp. 9–10
- 当前的 H/M/L 评估是示例性离散化；控制接口、日志和原因代码指标仍有待进一步自动化。论文将这些指标的自动化列为未来工作。出处：§6.3 · p. 10
- ArduPilot 的开放程度和测试基础设施成熟度高于许多工业项目，因此案例结论难以直接推广。要验证其对控制接口、日志或证据披露受限的封闭系统是否适用，还需开展更多基于案例的研究。出处：§6.3 · pp. 9–10
- JTA 是一种中观层次的架构方法，可补充而非取代形式化验证、认证流程和具体测试框架。它为统筹这些领域的验证能力提供了统一视角。出处：§6.3 · p. 10
7. 结论
JTA 将可测试性视为由场景、测试系统和 SUT 共同具备、受场景条件约束的能力，并将能力缺口映射为桥接层面的设计行动。对 ArduPilot 的分析揭示了链路相关场景与 EKF 异常场景各自不同的瓶颈，说明验证应采取联合视角，而非仅关注代码。
7. 结论
- JTA 定义了联合可测试性系统、场景契约、能力评估、充分性、盲点识别，以及针对控制、证据和归因缺口的桥接导向行动。该框架通过三个域、三个桥接关系以及一个闭环来组织这些内容。出处：§7 · p. 10
- 链路相关场景的瓶颈在于证据组织和明确的原因语义，而 EKF 异常场景则面临异常构造和跨组件归因方面的缺口。ArduPilot 分析阐述了不同场景类型各自的瓶颈。出处：§7 · p. 10
- 分析表明，安全关键软件的测试难点不只在代码层面，还涉及场景需求、测试基础设施与系统暴露接口之间的不匹配。出处：§7 · p. 10
- 未来工作将通过更多工业案例细化能力指标，验证桥接行动的效益，并探索与 UTP、保证论证和模型驱动工程的集成。出处：§7 · p. 10