符合ISO 26262的驾驶辅助系统产品线集成与验证

在汽车行业，产品变体和功能数量不断增加的趋势表明，改进规范制定、分析和测试技术，是驾驶辅助系统开发和验证过程中提升效率的关键因素。制定适用于整个产品系列的单一通用功能规范，能显著节省成本并缩短产品上市时间。同样，制定只需稍作修改就能在全系列目标平台上执行的通用测试用例规范，也能进一步节省成本和时间。然而，在系统制造商的电子开发流程中引入产品线方法是一项具有挑战性的任务，容易出现人为错误，且存在单一故障扩散到整个产品变体平台的风险。

此外，在汽车系统开发中引入诸如 ISO 26262 之类的安全标准，提高了对针对产品特性和汽车安全完整性等级（ASIL）的高效且可追溯的验证与确认方法的需求。尽管在航空电子或铁路等具有开发安全关键型系统悠久传统的行业中，已经应用过此类标准以及验证与确认方法，但我们发现在汽车系统开发中应用这些标准和方法仍面临挑战，这在很大程度上是由于大众产品在竞争激烈的市场中面临更短的产品上市时间和成本压力。

为了在满足紧迫的成本和时间目标的同时，符合新兴的安全标准，我们确定了三个提升系统集成和验证效率的关键因素，这些因素目前已在汽车制造商的驾驶辅助开发项目中引入或应用：

a) 提高规范的可测试性和可追溯性；

b) 在测试用例规范制定过程中引入变体管理；

c) 引入新的系统化、基于模型的分析和测试技术。

因此，我们介绍了在需求分析过程中处理大量变体的方法和经验，并提出了一种利用基于模型的分析技术提高流程效率和规范文档质量的方法。我们对这些方法进行了扩展，提出了一种测试设计与管理的集成方法，该方法能够高效处理和追踪大量产品变体的测试用例及结果。

本文在这些方法的基础上进一步扩展，提出了一种从功能规范中高效导出测试用例的概念，以验证产品在符合 ISO 26262 标准要求下与 ASIL 相关的质量特性。我们展示了一系列系统化、基于模型、组合式和基于搜索的测试方法，这些方法目前已在一家德国汽车制造商的功能集成中应用和评估。本文介绍的方法和流程得到了相关文献所述的 MERAN 工具套件的支持，该工具套件是某德国汽车制造商新测试管理系统的基础，该系统作为 IBM Rational DOORS 的插件实现。本文还提出了一种根据特定产品特性和所需 ASIL 调整集成与验证流程的概念和方法，并通过一个简单的驾驶辅助系统示例进行了说明。我们对新解决方案的应用经验进行了分析和讨论，探讨了其效率以及对 ISO 26262 标准的符合性。基于这些经验，我们确定了进一步的改进方向，并对这些改进方向以及当前正在进行的相关工作进行了讨论。

驾驶辅助系统（FAS）是汽车中的一种机电设备，用于在特定驾驶场景下为驾驶员提供支持，其核心通常聚焦于安全方面，或旨在优化驾驶舒适性、经济性和减少排放。驾驶辅助系统通常会监控车辆动力学的特定方面，对危险驾驶状态发出预警，或通过调节干预驾驶状态（例如为了避免事故）。因此，许多驾驶辅助系统被视为安全关键型应用，对其安全性和可靠性有着极高的要求。此外，驾驶辅助系统的开发还受到小型化趋势、巨大的创新压力和成本压力的影响，并且通常是针对车辆平台而非单个车型进行跨平台开发。

图 1：跨平台需求与测试管理

功能集成应实现以下总体目标：

· 经证实，集成后的功能需满足所有对其提出的功能和非功能需求；

· 经证实，集成后的功能不会对车辆中安装的其他功能造成干扰；

· 功能集成应尽可能高效地进行。

相关文献中提出的跨平台测试管理，能够高效地制定针对某一车辆平台的测试用例规范，并自动生成特定车型的测试规范。此外，相关文献中提出的产品线需求管理也已成功应用。在一家德国汽车制造商的功能集成过程中，正采用图 1 所示的跨平台测试管理方式。实现与测试管理紧密结合的跨平台需求管理，对于提高系统开发流程的效率具有巨大潜力。

图 2：驾驶辅助系统的抽象示例

驾驶辅助系统的集成包括两方面：a) 验证驾驶辅助系统子组件（见图 2）功能的完整性和正确性；b) 验证该系统与车辆中其他已安装系统之间无干扰的交互以及资源分配情况（见图 3）。

图 3：车辆中集成的驾驶辅助系统抽象示例

例如，泊车系统的集成首先要验证在包含执行器和传感器的情况下，需求是否得到正确且完整的实现（a 步骤）。该步骤可通过仿真或专门的测试装置完成。在第二步中，将泊车功能集成到整个系统中，并验证其与其他功能之间无干扰的交互以及资源分配（如执行器和传感器的资源分配）情况（b 步骤）。此集成步骤通常在配备特定领域电子组件的测试装置（如舒适性、底盘、信息和娱乐硬件在环（HiL）测试台）以及为此准备的车辆（参考测试平台）上进行。

ISO 26262 标准的推出也对驾驶辅助功能的功能集成设计产生了影响，因为这些功能往往具有安全关键性（ASIL 等级 A 至 D）。除了在安全关键型系统的分析、设计和实现过程中需格外谨慎外，测试还应进行系统化规划、规范制定、执行、评估和记录。作为本文提出方法应用的基本前提，ISO 26262 的这些通用要求必须通过成熟的测试管理流程完全满足。图 1 所示的跨平台需求与测试管理流程有助于满足这些要求。本文将不深入探讨 ISO 26262 中通用的测试管理要求。驾驶辅助系统功能集成的关键要求主要可在 ISO 26262 第 4 部分中找到，简而言之，在项目集成与测试阶段，需根据集成步骤（a）和（b）（见图 2 和图 3）进行功能集成，并根据相应的 ASIL 等级提供符合规范要求的证明。

本文提出了一种解决方案，旨在根据驾驶辅助系统的 ASIL 等级，并考虑跨平台开发方法，实现符合 ISO 26262 标准的驾驶辅助系统功能集成。为此，本文以表格形式提供了规划和决策辅助工具，旨在将 ISO 26262 对功能集成的要求具体化，帮助实际工作人员规划和实施验证工作。此外，本文还介绍了用于集成和测试的方法，并讨论了这些方法满足相应 ASIL 等级要求的适用性，同时展示了通过各种方法积累的经验。最后，本文对这些方法进行了评估和讨论，并指出了改进空间。

在本节中，我们提出了一系列系统化且基于模型的分析与测试方法，根据经济和技术标准，可从中组合出适合驾驶辅助系统功能 ASIL 特定集成测试的有效方案。本节将简要说明这些方法：

评审与审查（Reviews und Inspektionen）

这是一种静态的人工方法，用于对功能开发过程中产生的文档（如规范、程序代码或测试用例）进行目视检查。在功能集成过程中，会产生测试用例规范、测试计划、测试和验证模型以及结果报告和验证报告，这些文档同样可通过评审或正式审查的形式进行静态分析。评审和审查往往是对测试的有益且必要补充，尤其是当需要验证的产品特性属于非功能性特性，或实际测试难以有效验证时。该方法的经济性和结果质量取决于形式化程度，通常形式化程度越高，有效性和效率也会相应提高。从整体来看，全面推行正式审查可能耗时较长，但在功能集成过程中，对于工作步骤的检查，也建议采用相对简单但效果稍弱的评审方式。ISO 26262 明确推荐采用评审和审查的方式来验证产品特性。

错误推测（Error Guessing）

错误推测是一种非形式化的测试方法，其测试用例的选择基于用户的个人经验和对系统的了解。该方法不要求制定测试用例的固定体系，因此其经济性和测试结果在很大程度上依赖于用户经验。ISO 26262 明确建议在验证概念中纳入专家知识（通过错误推测的方式）。

序列枚举（Sequenz-Enumeration）

序列枚举是一种将自然语言规范形式化的系统化方法。通过序列枚举，可得到完整、规范的系统行为描述，该描述可用于测试或进一步的基于模型的分析步骤。测试用例的选择以规范的系统描述为基础，能够为系统行为的可验证完整性覆盖提供支持。此外，在该过程中，需求会经过严格的形式化分析，从而在测试用例设计阶段就能发现规范中的错误和漏洞。该方法的结果受用户经验的影响相对较小，但其经济性在很大程度上依赖于用户经验和合适的工具支持。在 ISO 26262 标准框架下，序列枚举既是一种用于规范验证的形式化方法，也是一种基于需求的形式化测试方法。

统计测试（Statistischer Test）

统计测试方法属于基于模型的方法，通常适用于验证功能和非功能需求。测试用例的选择和规范是基于运行剖面（例如以马尔可夫模型的形式），通过随机过程完全自动完成的。该方法的工作量和应用复杂度主要体现在模型构建上，而模型构建可作为序列枚举的附加成果完成。其经济性在很大程度上取决于模型构建的工作量和用户经验。此方法适用于验证非功能需求，例如可用性、可靠性或平均响应时间。在 ISO 26262 标准体系中，统计测试是一种基于需求的形式化测试方法，可用于验证功能和非功能需求。

分区测试（Partitionen Test）

分区测试方法是一种系统化方法，其测试用例的选择以需求规范和接口描述为依据，将所需的系统行为划分为具有特定特征的区域（分区）。针对每个分区，会系统地设计测试用例，以验证其是否得到正确实现。该方法适用于验证功能需求。通过将测试任务系统地分解为更小的子任务，可实现良好的经济性。在 ISO 26262 中提及的常用分区方法包括等价类测试和边界值分析。

组合测试（Kombinatorischer Test）

组合测试方法是一类系统化方法，其测试用例的选择通过对参数化测试场景进行排列组合来实现。采用该方法前，需先完成测试场景的定义步骤（例如通过分区测试或序列枚举）。此方法有助于显著提高功能需求的覆盖范围，并发现关键的应用场景，同时也非常适合用于测试诊断和错误处理机制。该方法的经济性和测试结果依赖于用户经验。在 ISO 26262 标准下，组合测试可作为一种实现需求覆盖以及测试诊断和错误处理的方法。

基于搜索的测试（Suche-basierter Test）

基于搜索的测试方法属于基于模型的方法，特别适合用于分析系统在极端情况下的行为。测试用例的选择以规范模型为基础，并通过完全自动的搜索过程来完成。搜索过程由测试目标（例如最大化响应时间）引导。该方法的工作量和应用复杂度主要体现在测试目标的形式化以及使用大量生成数据执行测试上，适用于验证非功能需求。在 ISO 26262 标准框架下，基于搜索的方法可作为基于需求的分析和测试方法，同时也是验证系统性能的适用方法。

以下介绍的方法虽不直接用于功能集成测试，但对提高效率和有效性具有重要作用：

模型检查（Model-Checking）

模型检查是一种对规范行为模型（如状态图）进行静态分析的形式化方法，也可用于从相应模型中生成测试用例。当将规范模型用于验证或测试目的时，该验证方法可用于验证模型中需求的实现情况，并为测试提供支持。该方法的工作量和结果质量在很大程度上依赖于用户的专业知识。将基于模型的测试与通过模型检查进行的形式化验证相结合，有助于提高规范制定和测试用例评估过程的效率。某些系统特性只能通过模型检查来验证。该方法需要模型检查工具的支持，例如用于时间关键型系统的 UPPAAL 模型检查器。尽管 ISO 26262 未明确推荐将模型检查用于系统集成，但我们仍建议将该方法用于验证集成测试用例生成所使用的模型，并作为集成测试的补充手段进行形式化静态验证。特别是将基于模型的测试与通过模型检查进行的形式化验证相结合，有助于显著提高系统集成的效率，同时通过形式化方法验证，大幅提升以往抽样测试的可信度。

背对背测试（Back-to-Back Test）

在汽车行业中广泛应用且得到 ISO 26262 推荐的背对背测试，是一种特殊的测试配置，用于对产品不同开发阶段的版本进行相互测试。通常，背对背测试并非用于验证产品特性，而是用于验证产品开发过程中所使用的工具（如代码生成器、编译器或硬件在环测试台）。例如，在缺乏经过认证的工具时，通常会采用背对背测试的方式，将用于代码生成的模型与生成的代码进行对比测试。具体而言，就是将执行模型所产生的输出与执行生成代码所产生的输出进行比较。该方法的一个系统性缺陷在于，对于两个开发阶段版本中都存在的错误，由于它们会产生相同的输出，因此该方法无法检测到这类错误。对于驾驶辅助系统的功能集成，我们建议定期采用背对背测试的方式，将所使用的测试和仿真技术（如模型在环（MiL）、软件在环（SiL）或硬件在环（HiL））与车辆中的目标平台进行对比验证。在背对背测试中，通常会使用已有的测试用例来执行测试。该方法的工作量取决于所使用的测试技术以及测试结果等效性验证的实现方式，但总体而言，预期工作量相对较低。测试结果的准确性则取决于所执行测试用例的范围以及等效性验证的详细程度。

故障注入测试（Fault-Injection Test）

为了测试诊断和错误处理功能，需要在系统中人为模拟诊断规范中包含的故障状态。在设计用于测试诊断和错误处理功能的测试用例时，通常会基于诊断规范和系统故障模型，采用基于需求的测试方法。组合方法也非常适合用于设计测试用例，通过组合规则，能够简洁高效地描述传感器中频繁出现的故障状态。

通常而言，对于任何质量保障计划，从技术和经济角度出发，组合运用静态分析和系统化测试都是合理且推荐的做法。与之不同的是，ISO 26262 仅将经济因素视为次要考量，其核心目的是基于技术标准，为功能安全功能的保障设定最低要求。本文旨在为驾驶辅助系统功能集成的质量保障策略提供工业化实施的规划工具，助力平衡实际应用中的经济与技术需求，以及 ISO 26262 的规范性要求。

基于此目的，我们结合实践经验，为前文所述方法提出以下评估标准：

· 基于功能覆盖率和详细程度的准确性；

· 应用复杂度，即实施某一验证方法所需的专业知识水平；

· 总体经济性，即采用某一方法实现目标所需的工作量指标。

ISO 26262 第 4 部分 “项目与集成测试” 章节中，包含了针对驾驶辅助系统功能集成的特定要求。为了以适合驾驶辅助系统功能集成的方式开展实际工作，我们对 ISO 26262-4 第 8 章节中提及的目标进行了总结，并在表 2 中与表 1 所示的验证方法建立了对应关系。从表 2 中可以看出，要全面覆盖所有源自 ISO 26262-4.8 的验证目标，仅依靠单一验证方法无法实现，必须组合运用多种验证方法。理论上，多种方法可形成大量有效组合，但在实际应用中，不同组合会产生差异显著的技术与经济结果。由于不同方法在所需工作量、可实现的验证准确性及测试深度上存在较大差异，下文将基于驾驶辅助功能的 ASIL 等级，提供补充性的方法选择指南。

表 1：验证方法概述

表 2：源自 ISO 26262-4 第 8 章节的验证目标对应的验证方法（++- 非常适用，+- 适用，(+)- 辅助作用）

表3 中的评估结果反映了各方法在准确性、应用复杂度和经济性方面，与不同 ASIL 等级的适配程度。实践经验进一步表明，高 ASIL 等级所需的高准确性，通常意味着更高的工作量和应用复杂度；而对于低 ASIL 等级，由于低准确性方法具有更优的经济性，因此更适合采用这类方法。

表 3：基于 ASIL 等级的验证方法选择（++- 必需，+- 推荐，(+)- 辅助）

相关文献提出的跨平台开发驾驶辅助系统的功能集成概念，需针对 ISO 26262 标准的应用进行扩展。与特定产品开发的驾驶辅助系统不同，跨平台开发方法能够以极高的效率对整个平台的需求进行验证。图 4 展示了跨平台开发方法下的可行验证路径。基于平台需求，可通过一个可选模型制定跨平台、参数化的测试用例。借助参数替换和特定产品选择，能够自动生成特定产品的需求与测试用例。测试用例针对需求的完整性验证，可在平台层面或产品层面开展。平台层面的完整性指标通常用于项目进度衡量，而产品层面的完整性指标则用于产品质量验证。

图 4：跨平台验证概念

对于高 ASIL 等级的验证或测试，特别推荐使用模型，因为更高的形式化程度有助于提升验证的准确性。即便对于非关键应用，通过共用模型开展分析与测试，也能以更经济、更可靠的方式完成验证。从原则上讲，无论开发是否采用跨平台方式，都必须针对特定产品的安全需求进行验证。但在多数情况下，可对某一平台下多个产品的部分需求进行联合验证，或将平台层面的测试结果应用于多个产品，从而节省工作量与时间。

在实际应用中，部分需求无法通过测试验证，若采用形式化分析方法验证则需投入极高成本，因此对于所有应用场景，均推荐采用评审与审查的方法。此外，当测试数据量较大时，评审与审查在结果评估方面往往具有经济性和有效性优势，因此可用于所有验证目标的验证工作。

在离散系统中，若全面应用序列枚举方法，则分区测试与组合测试的作用会大幅减弱，因为通过这两种测试方法设计的测试用例，大多已被序列枚举方法覆盖，难以发现新的有效测试用例。但在某些情况下，针对特定测试方面采用序列枚举方法，同时通过系统化方法覆盖剩余需求，这种组合应用方式仍具有实际意义。此外，序列枚举方法在模拟系统中的适用性，目前仍是研究热点。对于模拟系统，建议采用分区分析方法（如等价类分析、边界值分析、时间分区）对系统接口进行离散化处理。通过组合使用分区测试与序列枚举方法，能够以极高的准确性完成混合系统与模拟系统的集成和测试。即便对于低 ASIL 等级，也推荐采用序列枚举方法，因为该方法能够生成可追溯的完整结果，有助于提升开发流程的效率。

此外，可通过基于模型的故障注入方法进行优化，从而更精准、全面地验证诊断与错误处理功能。对于低 ASIL 等级和中 ASIL 等级的稳健性测试，推荐组合使用组合测试、分区测试与故障注入方法。基于搜索的测试方法尤其适用于极端场景（如负载测试、压力测试）下的系统行为分析与验证，或用于发现和分析关键应用场景，因此特别推荐作为高 ASIL 等级的补充测试方法。目前正在开发的一种测试方法，结合了基于搜索和统计的测试方法，旨在识别存在故障的安全关键型系统配置，并根据测试结果评估未发现的故障安全关键型系统配置的存在概率。

本文提出了一种解决方案，旨在简化驾驶辅助系统功能集成流程在 ISO 26262 标准下的实际实施。除 ISO 26262 标准要求外，本文还充分考虑了工业实践中的经济因素，在方法选择中赋予其合理权重。此外，基于典型的工业批量开发流程，本文提出了产品线开发的验证概念。

尽管文中所述方法已积累了一定的实践经验，部分方法也已成功应用于实际工作，但借助文中提供的工具，尚未完全实现 ISO 26262 标准的全面落地。这主要是因为目前 ISO 26262 标准仍处于高级草案阶段，尚未正式发布。此外，序列枚举与基于搜索的测试等基于模型的方法，对用户的专业知识要求极高，也限制了其广泛应用。

目前正在开展的研究与开发工作，聚焦于方法简化与工具优化，旨在显著降低方法的应用难度。对于 ISO 26262 标准的后续完善，本文建议进一步明确和细化功能集成推荐采用的验证方法。该标准在驾驶辅助系统功能集成方面的一个不足，是对所用测试系统的验证不够充分。为此，本文建议定期采用自动化背对背测试方法，将测试系统与车辆环境进行对比验证。文中提出的规划工具，是 ISO 26262 标准在驾驶辅助系统功能集成中应用的一种解读与解决方案。