编号	文档
Ref [1]	UL 4600: UL Standard For Safety Evaluation of Autonomous Products
Ref [2]	ISO 26262- 4 : Road vehicles- - Functional safety - -Part 4 : Product development at the system level
Ref [3]	ISO 26262-8: Road vehicles- Functional safety- Part 8: Supporting processes
Ref [4]	ISO 26262-9: Road vehicles- Functional safety- Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses
Ref [5]	ISO 13400 : Diagnostic communication over Internet Protocol
Ref [6]	ISO 11452 : ‌ Road vehicles — Component test methods for electrical disturbances from narrowband radiated electromagnetic energ y.

2.2 国内标准和技术规范

本规范参考的国内标准和技术规范如表 3 所示。

表 2.2 规范性引用文件

编号	文档
Ref [1]	GB/T 34590.1: 道路车辆功能安全第 1 部分：术语
Ref [2]	GB/T 34590.2: 道路车辆功能安全第 2 部分：功能安全管理
Ref [3]	GB/T 34590.4 : 道路车辆功能安全第 4 部分：产品开发：系统层面
Ref [4]	GB/T 34590.8 : 道路车辆功能安全第 8 部分：支持过程
Ref [5]	GB/T 43267: 道路车辆预期功能安全
Ref [6]	GB/T 20438 : 电气 / 电子 / 可编程电子安全相关系统的功能安全
Ref [7]	GB/T 44495 ：汽车整车信息安全技术要求
Ref [8]	GB/T 21434 ：道路车辆信息功能安全

3 术语缩写与定义

3.1 缩写

表 3.1 列出了本规范中专有名词的英文全称及相应的中文。

表 3.1 缩写

缩写	含义
ASIL	Automotive Safety Integrity Level ( 汽车安全完整性等级 )
GnuC	GNU Compiler Collection ( 类 Unix 操作系统 )
HIL	Hardware-in-the-Loop ( 硬件在环仿真 )
SIL	Safety Integrity Level ( 安全完整性等级 )
ODD	运营设计域 ODD ( Operational Design Domain )
MCDC	Minimum/Minimal Condition Decision Coverage ( 最小条件组合覆盖测试 )
V2X	vehicle to everything ( 车对外界信息交换 )
FMEA	Failure Mode and Effects Analysis ( 失效模式及后果分析 )
TARA	Threat Analysis and Risk Assessment ( 威胁分析与风险评估 )
NASA-TLX	NASA Task Load Index ( 工作量进行多维度评估的流程和标准 )
EMI	Electromagnetic Interference ( 电磁干扰 )
TLS	Transport Layer Security ( 传输层安全性协议 )
HSM	Hardware Security Module ( 硬件安全模块 )
MFA	Multi Factor Authentication ( 多因子认证 MFA )
PAM	pulse amplitude modulation( 脉幅调制 )
OBD	On-Board Diagnostics ( 车载自动诊断系统 )
API	Application Programming Interface ( 程序之间的接口 )
HMI	Human Machine interface ( 人机交互 )

3.2 术语和定义

陷阱

当异常或中断发生时，处理器捕捉到一个执行线程，并将控制权转移到操作系统中某一个固定地址的机制。

技术安全

在技术领域内,保护系统、网络、数据不受破坏、泄露、丢失或未经授权访问的一系列措施。

压力测试

对系统、设备或软件进行负载测试,以确定其在正常和异常工作情况下的性能和稳定性。

测试数据库

指在软件开发过程中,为了检验软件的功能和性能,而专门创建的一个数据库环境。

回归测试

修改旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

故障注入测试

通过人为地引入各种故障或异常情形，以验证系统在面对错误条件时的稳定操作能力 ‌。

模糊测试

通过向目标系统提供非预期的输入并监视异常结果来发现软件漏洞的方法。

资源使用测试

‌ 对系统在运行过程中对各种资源 ( 如CPU、内存、磁盘、网络等 ) 的使用情况进行监测和评估的过程。

安全论据

在论证安全性时所依据的理由、证据或标准。

渗透测试

通过模拟恶意黑客的攻击手段来评估计算机网络系统的安全性。

界面认知负荷

针对某一特定认知任务，记忆系统对其进行加工和保持信息过程中所承受的负荷总量。

易用性期望

用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。

变异性场景

在特定情境或环境中，各种变量或因素发生变化和差异的不同情况或表现形式。

集成策略

在管理和决策过程中，针对复杂的问题和挑战，将不同领域或不同层面的策略方法融合在一起，提供综合性的解决方案。

评审会议

由相关人员组成的，针对特定项目或工作成果进行评估、审议并给出反馈和建议的会议。

3.3 约定术语

本文档中使用了下列术语：

 “强制性”：表示不允许出现安全案例偏差

 “需要”：表示仅当通过提示证明提示元素与项目和/或其安全案例本质上不兼容时，才允许发生安全案例偏离。

 “强烈推荐”：表示是应该遵循的最佳实践，但可以省略，尤其是对于低风险项目。安全案例中明确指出了遗漏，并提供了合理的支持理由，以提供一个根源，以便将根本原因分析追溯到这些遗漏。只要以合理的理由记录了这些遗漏，就可以认为该安全案例是可以接受的。

 “推荐”：表示这些是可选的提示元素，记录了良好做法和/或有用技术的建议。

 “注”或“示例”：表示的信息仅用于辅助理解或阐明相关要求，不应作为要求本身且不具备完备性。

4 集成开发与验证融合安全概述

4.1 集成开发与验证融合安全概述

本规范的目的是 :

a) 确保集成开发与验证的总体安全要求得以实行。 ( 请参阅第 5 章 )

b) 确保集成开发与验证的各项过程可以在安全限度内进行。 ( 请参阅第 6 章 )

c) 确保相关项所包含的每一个要素的软硬件集成安全。 ( 请参阅第 7 章 )

d) 确保构成一个完整系统的一个相关项的所有要素的集成安全。 ( 请参阅第 8 章 )

e) 确保相关项与车辆上其他系统的集成以及与整车的集成安全。 ( 请参阅第 9 章 )

f) 确保车辆系统与整车层面的验证场景要求在安全标准的容许范围内。 ( 请参阅第 10 章 )

图 4 .1 集成开发与验证融合原理图

5 集成开发与验证总体要求

5.1 集成开发与验证总体要求概述

本章节的目的是:

a) 明确集成验证与测试所应涉及到的有关方法，并未安全案例的使用提供依据。 ( 请参阅第 5.2 节 )

b) 应全面考虑集成开发与验证应涉及到的安全相关故障。 ( 请参阅第 5.3 节 )

c) 确定集成开发与测试验证的所涉及的项目在允许的覆盖范围内。 ( 请参阅第 5.4 节 )

图 5.1 图集成开发与验证总体要求结构图

5.2 集成开发与验证方法

5.2.1 应识别所使用的特定验证与测试的方法类别：

a) 同行评审

b) 静态分析

1) 识别静态分析技术

注 : 这可以采用识别工具和工具功能的形式。

2) 证明静态分析的严谨性

注 : 这包括证明选择的工具和使用的工具配置是可接受的

示例 : 尽管有标志名，将标志 “-Wall” 添加到 GnuC 编译器仍会提供相对较弱的静态分析，因为它无法启用大量经常相关的静态分析功能 ( 例如，可能包含在 “-Wextra” 和其他配置中的那些功能 ) 标志 )

c) 软件单元测试

1) 陷阱 : 由于可控制性和可观察性的限制，过大的软件单元的单元测试易于丢失缺陷。

d) 坚固性和 / 或压力测试

e) 软件资格测试

示例 : 符合 IEEE 12207 标准的软件要求

f) 项目资格测试

示例 : 符合 IEEE 12207 标准的软件要求

g) 失效模式和影响测试

h) 具有环境条件变化的功能和组件测试与 ODD 的行业最佳实践一致

示例 : EM ，震动和烘烤，温度循环，加速寿命测试

i) 发行前回归测试是否有更新

j) 每车调试测试

k) 封闭课程项目测试

示例 : 专用测试设施，对公共空间的使用进行控制

l) 对部署数据进行日志分析以补充发布前的 V &V 。

5.2.2 并对如下的测试方法的内容进行补充，保证所应用的测试或验证方法是可接受的，并尽可能处于人类安全监督中：

a) 自动化测试框架

b) 持续集成

c) 动态分析

d) 整合测试

e) 形式方法

f) 其他分析方法

g) 软件在环 (HIL) 测试

1) 记录了环境工作量

2) 模拟环境工作量

3) 具有实时环境工作量

h) 硬件在环 (SIL) 测试

1) 记录了环境工作量

2) 模拟环境工作量

3) 具有实时环竣工作是

i) 压方测试

j) 项目测试

1) 记录了环境工作量

2) 模拟环境工作量

3) 具有实时环境工作量

示例 : 封闭课程测试

k) 持续进行人类安全整督的公共道路测试。

l) 少于持续的人类安全监督的公共道路测试

m) 试行公共道路

n) 对任何形式的测试或部署的运行时监视 ( 指定哪个 )

0) 诊断测试以复制现场问题报告

p) 使用任何适应性数据进行现场测试

q) 现场车辆在役测试

示例 : 年度检查能力和性能测试

r) 进行任何其他类型的测试

陷阱 : 将手动断点调试用于单元测试容易导致测试结果不致和测试范围受限。

注 : 断点调试通常涉及使用调试器手动设置变量值 , 观察控制流以及观察完全编译的项目映像中单元的计算结果。在实践中，很难确保可重复的结果 , 并且由于手动方法固有的非自动化回归测试的时问和费用，测试范围受到限制。

5.2.3 只要涵盖了所需方法中的所有类别就可以鼓励对测试类型进行更精细的分类 ( 如果未明确包括任何所需类别，则可追溯性分析的文档覆盖范围 ) 。

5.2.4 将需要使用许多枚举类型的测试来创建令人满意的安全案例。将它们作为非强制性内容包括在内是为了在整个测试方法中提供灵活性。特别是，对于物品的生命攸关方面，通常应使用多种测试与验证技术。

5.2.5 安全案例中应该记录每种验证或测试方法提供证据的依据，应考虑：

a) 考虑可能不确定的组件和项目行为对 V &V 结果的影响。

示例 : 使用多种方法的统计显着性 ( 或其他方法 ) ，以确保不确定性项目行为已通过测试过程进行了表征。

b) 对于支持第 5.2.1 ～ 5.2.2 节记录的每种 V &V 方法，结果应都与安全案例中的特定论点相关。

c) 测试数据和操作环境的统计性质对 V &V 结果的影响。

5.3 集成开发与验证安全相关故障

5.3.1 验证与测试应提供与设计阶段相关的安全相关故障的可接受范围：

a) 系统设计缺陷。

b) 传感器数据中的故障，损坏，数据丢失和完整性丢失的设计考虑。

c) 需求差距 / 遗漏和需求缺陷。

d) 对违反要求假设的回应。

示例 : 应对卓越的运营环境

e) 标识和描述预期的 ODD 。

f) 可接受的缓解已定义故障模型的各个方面以及项目其他方面的方面。

5.3.2 明确集成开发设计过程中所涉及的安全相关故障或设计缺陷、功能不足等也在 5.3.1 的可接受范围内。

a) 维护程序定义。

注意 : 尽管维护是在生命周期中进行的，但程序的定义需要与设计要求和设计中有关维护的假设相对应。

b) 操作过程定义 ( 包括启动和关闭 ) 和操作模式。

c) 来自外部源的数据中的故障，损坏，数据丢失和完整性丢失。

d) 与特殊情况相关的故障和故障会削弱降低风险的功能。

e) 硬件和软件勘误表以及其他第三方组件设计缺陷。

f) 安全相关功能，组件设计和其他设计属性中的其他故障。

5.3.3 验证与测试应提供与每个项目实例的构造相关的安全相关故障的可接受范围：

a) 项目实例与设计的一致性。

b) 执行安全相关功能的能力。

c) 风险缓解功能和方法的有效性。

d) 配置数据故障。

示例 : 校准数据不正确，校准数据损坏，校准数据丢失。

e) 集成到项目中的组件中的故障和故障。

f) 损害可编程组件完整性的故障和故障。

5.3.4 应保证集成要素的组件，数据，制造程序的版本兼容并且正确，供应链应满足组件的要求。

注意 : 应排除质量褪色，不兼容的组件，假冒的组件，过度老化的组件

5.3.5 验证与测试应提供与产品生命周期相关的安全相关故障的可接受范围：

a) 安全相关功能的损害。

b) 能够影响项目预期操作的安全相关方面的故障和失败。

c) 在项目使用寿命期间指定故障模型的覆盖范围。

d) 用于维护计划的可靠性和寿命终止估计的准确性。

e) 在以下期间的故障和失败 :

1) 与制造相关的操作

2) 运输

3) 存储

4) 与销售和业务相关的运营

5) 修复性维修

6) 中年升级

7) 崩溃和其他损坏修复

5.4 集成开发与验证覆盖范围

5.4.1 验证与测试应提供可接受的 ODD 覆盖范围：

a) 确定的 ODD 的覆盖范围。

b) 涵盖 ODD 违规情况。

c) 定义的 ODD 子集的覆盖范围。

5.4.2 验证与测试应提供可接受的项目结构和预期操作的覆盖范围：

a) 安全相关项目硬件组件的覆盖范围。

b) 安全相关项目软件组件的覆盖范围。

c) 安全相关系统接口的覆盖范围。

示例 : 传感器，执行器，人机界面，电子通讯接口

d) 安全相关项目功能的覆盖范围。

e) 安全相关的功能外特性的涵盖范围 :

1) 实时表现

2) 软件稳定性

3) 绩效边际

4) 可靠性

6 集成验证测试与监控管理

6.1 集成验证测试与监控管理概述

本章节的目的是 :

a) 明确集成验证与测试所应涉及到的有关方法，并未安全案例的使用提供依据。 ( 请参阅第 6.2 节 )

b) 应全面考虑集成开发与验证应涉及到的安全相关故障 ( 请参阅第 6.3 节 )

c) 确定集成开发与测试验证的所涉及的项目在允许的覆盖范围内。 ( 请参阅第 6.4 节 )

d) 确定集成开发与测试验证的所应考虑的回归测试。 ( 请参阅第 6.5 节 )

e) 确定集成开发与测试验证的所应考虑的故障注入测试。 ( 请参阅第 6.6 节 )

f) 应保证集成验证与测试的整个流程，均处在安全管控的状态下。 ( 请参阅第 6.6 节 )

1736068492093

图 6.1 集成开发与验证总体要求结构图

6.2 集成验证测试计划

6.2.1 测试计划应形成文件，并遵循测试数据作为证据。

注意：测试是验证和确认的一种形式。如果测试未涵盖项目的每个方面的整个故障模型，则可以使用 V &V 的其他方面来完成 V &V 的覆盖范围。

a) 捕获被测项目元素的硬件，软件和其他配置信息的有条理的方法

b) 可接受的测试计划文档 :

1) 每个测试程序的描述。

2) 测试设置，测试环境和测试仪器的描述。

3) 独立得出预期的测试结果。

4) 通过 / 失败标准的描述。

5) 进行中的测试运行的文档，包括与测试计划的任何偏离并有正当理由。 6) 每个安全性相关测试的可追潮性至测试功效的论点。

7) 每种安全相关测试对相关要求或风险缓解方法的可追溯性。

8) 考虑项目行为的不确定性。

c) 项日安全相关方面的覆盖范围

1) 测试计划充分性的争论

2) 正常功能的安全操作

3) 通过启动，操作条件序列，关闭和其他瞬态功能进行安全过渡

4) 元素和子系统故障与失败响应

5) ODD 的覆盖范围，至少包括 :

i) 操作环境

ii) 对象和事件

iii) 演习

iv) 项目级故障和失败响应

d) 考虑基于软件的功能的脆弱性

1) 对异常条件的压力测试响应

2) 随机或其他变化的操作参数和方案

3) 自主脆性评估

e) 可能影响测试有效性和 / 或代表性的因素包括 :

1) 环境条件

2) 设备状况

3) 物品对初始条件微小变化的敏感性

6.2.2 应对涉及的测试方法从测试计划的全过程，多个角度进行考虑，并且尽可能全面的描述测试的各个环节：

a) 同行评审测试计划

b) 陷阱 : 具有模糊或临时成功标准的测试容易无法发现缺陷

注 : 当测试人员寻找声明已通过测试的原因时，一个确认因素就是确认偏差。

c) 陷阱 : 具有多种变化的或未记录的项日配置或参数的测试执行容易使测试有效性和测试可重复性失效

注 : 在没有可接受的被测项目版本文档的情况下进行测试，并且测试条件是否符合测试计划不能提供足够的证据来满足测试要求。

d) 确保测试重复性的考虑

示例 : 初始项目条件，时间，测试仪器校准。

e) 描述用于识别意外测试结果来源的监视方法和过程

f) 测试结果评估和异常结果的根本原因分析

1) 源于测试监视工具的错误

2) 测试行为中的错误

3) 测试 oracle 缺陷

4) 测试设置错误

5) 测试程序缺陷

6) 错误观察和记录测试结果

7) 错误地得出预期的测试结果

g) 陷阱 : 在测试活动中纠正软件缺陷很容易使该活动先前的测试结果无效

注意 : 这意味着在通过测试活动的中途进行错误修复后，已经通过的测试将重新运行，这可能会由于变更影响分析而受到限制。

h) 陷阱 : 对不确定性函数的单个测试由于偶然性而容易通过，而不是作为正确性的确认。

6.2.3 应对不需要作为证据的测试 ( 例如效率或乘坐舒适性测试 ) 不需要追溯到论点，但出于同样的原因，在评估安全案例时也将其忽略。

6.3 集成验证测试预案

6.3.1 应对每个测试的测试预案形成文件，测试预案应包括可接受的测试设置，过程和测试用例顺序、通过 / 失败标准的描述、定义合格 / 不合格标准的方法：

注 : 与创建自动数据库结果和 / 或手动生成的预期测试结果相关的描述。

a) 争论预言的正确性，如果使用自动预言

b) 在进行测试之前定义测试数据库

c) 陷阱 : 在测试之后定义测试通过标准会导致错误的结果合理化，而不是测试失败。

6.3.2 应安全相关测试的主要目的是为安全论证提供证据支持。考虑到这一点，将创建测试数据库

示例：如果常规的软件健壮性测试的目的是生成不太可能发生软件崩溃的证据，那么对于执行的每个测试，其预言可能会 “ 没有崩溃 ” 而不是详细的数据值结果。可以执行其他非正式测试，但是没有使用具有可接受的关键性的数据库进行的测试不足以支持安全性论证。尤其是，导致安全关键功能的错误负测试结果的预兆缺陷会在安全情况下造成生命关键缺陷。

6.4 集成验证测试范围

6.4.1 每组与安全相关的测试证据均应具有确定的覆盖率指标，以支持验证测试活动的进行。

a) 测试范围包括 :

1) 计划覆盖。

2) 取得覆盖。

5) 关于已识别故障模型的覆盖范围。

3) 标称条件的涵盖范围。

4) 覆盖非标称条件。

b) 对每组测试证据至少使用以下覆盖率指标之一 :

1) 软件白盒指标

示例：代码覆盖率，分支覆盖率， MCDC 覆盖率

2) 硬件白盒指标

示例：行使每个硬件组件上的每个重要功能，行使每个芯片上的每个 IP 块，行使每个接口信号，行使集成电路中的每个门，行使数据存储设备的每个位

3) 黑匣子指标

示例：需求范围，设计可追溯性

4) 与正在使用的机器学习模型及其数据有关的指标

5) 与测试输入覆盖 ODD 的方式有关的指标

c) 对不确定性功能覆盖范围的量化置信度

示例：统计分析技术

d) 陷阱 : 使用一组固定的测试重复进行测试倾向于仅消除测试计划旨在查找的特定缺陷，并不意味着最终的软件没有缺陷。

6.4.2 软件内部的状态信息应支持不确定性测试结果的有效性

示例：由于模块行为的内部自我报告与预期的测试方案匹配，因此测试通过。

6.5 回归测试

6.5.1 回归测试和验证测试应用于验证项目更改

a) 对项目进行任何更改后进行的回归测试。

b) 对回归测试进行任何更改后进行的回归测试。

6.5.2 应对回归测试的对与项目的矫正与更改后对安全功能造成的影响进行测试，并应全面考虑验证活动中的缺陷问题。

a) 每个校正的与安全相关的缺陷都跟踪到至少一个测试，以验证回归测试套件中的校正。

注意 : 这样做的目的是随着时间的推移形成一个回归测试套件，该套件会累积针对安全相关项目元素的所有缺陷校正的测试。

b) 对与安全相关的故障包含区域的任何更改都会对所有受影响的故障包含区域内的安全功能进行全面测试。

注意 : 这很可能会导致针对每个与安全相关的 FCR 中驻留的全部功能的完整测试计划和测试活动，包括恰好驻留在该 FCR 中的与安全无关的功能。即使更改本身与安全无关，整个 FCR 测试计划也会根据相关 FCR 中的每次更改执行。

c) 回归测试套件涵盖的缺陷更正包括在 V &V ，试点部署和大规模运营中发现的任何缺陷。

d) 缺陷的非代码贡献者，这些缺陷被用作连续过程改进活动的输入。

示例：同行评审检查表遗漏错误，测试计划遗漏错误。

6.5.3 应按 6.5.1 ～ 6.5.2 小节中的要求，对回归测试的实施，设定如下要求：

a) 通过影响分析提供的回归测试。

b) 执行所有回归测试，无论影响分析如何。

示例：所有回归测试都会定期运行，而不考虑更改的影响分析结果，但是仅对完整运行之间的微小更改的影响分析做出响应。

c) 对与安全相关功能接口的非安全相关功能进行回归测试。

6.5.3 缺陷的非代码贡献者不一定会导致额外的回归测试，而是可能导致过程更改以确保过程缺陷不会再次发生。

示例：由遗漏的需求引起的缺陷需要采取纠正措施，以减少其他类似类型需求缺口的可能性。这可能会导致需求审查清单的更改以及对有风险的需求的重新审查。如果没有对代码进行任何更改，也没有对测试计划进行更改，那么重新运行回归测试可能没有意义。

6.6 故障注入测试

6.6.1 应使用故障注入测试来提供可接受的减轻故障的证据。

a) 故障注入测试到可接受的覆盖范围。

b) 涵盖已识别故障模型的所有方面。

1) 可行的故障注入。

2) 证明故障模型的其他方面已被其他技术覆盖。

c) 对于认为故障模型的某个方面不可行的每种情况 :

1) 证明为什么故障注入测试不切实际。

2) 论证和证据证明故障模型的相关方面已得到缓解。

注意 : 涵盖了已识别故障模型内所有故障的所有方面。优先考虑实际的故障注入测试，而不是分析。

6.6.2 应确定故障注入测试的应用范围，并考虑采取的注入方法。

a) 故障注入方法的侵入性评估和最小化。

b) 带有中到高概率故障对的故障注入。

c) 在仿真中执行故障注入。

d) 在单元级别进行故障注入测试。

e) 在子系统级别进行故障注入测试。

f) 在车辆级别进行故障注入测试。

6.6.3 应根据故障的类型及其对系统的影响，注入故障的不同方法可能更有效。可以通过组合故障注入策略来实现覆盖，而不必包括通过不同的故障注入方法来复制特定故障。

注：如果故障响应不正确，则在操作产品中注入一些故障可能会导致潜在的危险故障。这不是忽略安全故障响应确认的充分借口，以避免在部署过程中发生丢失事件，而是通过在受控条件下进行仿真和实际测试来激发故障响应有效性的初步确认。

6.7 集成验证监控管理

6.7.1 应对集成验证过程中的与安全相关的操作过程进行监控，并应确定在活动进行过程中的监视策略以及应满足的功能，包括：

a) 安全相关操作故障的发生和正确性

示例 : 硬件操作故障

b) 对可能由设计故障引起的安全相关事件的响应的发生和正确性

示例 : 看门狗定时器意外跳闸，意外重置，意外项目行为

c) 运行时监视，至少检测以下内容 :

1) 安全论证中假设的有效性

2) 基于历史数据的证据的有效性用作安全性论证的基础

3) 确认监视过程中 ODD 内部正在使用系统

注 : ODD 外部的操作数据不一定提供有用的证据来证明 ODD 内部的安全性

d) 记录安全相关的运行时监视器和故障检测

注 : 记录保真度支持可接受的现场工程反馈。对于某些项目，这可能是带有详细时间戳记的日志而对于非生命攸关的项目，可以使用最近激活的诊断故障代码列表。

e) 验证运行时监视功能

注 : 运行时监视的实现取决于软件质量以及数据安全性

f) 监视追溯到安全案例的故障模型和证据要求，而不是仅仅基于在实施中似乎便于监视的内容

g) 在最大范围内对故障的发生和响应进行运行时监视，包括与安全无关的故障。

6.7.2 应对测试和部署中的项目进行运行时监视可以帮助确保故障模型完整，故障以预期的速率发生以及项目按预期处理故障。

注 : 可以结合使用车载监控来触发报告和对数据日志进行离线分析。开发人员可以自行决定数据带宽与车载处理能力之间的权衡。

6.7.3 应展示对运行时监视结果的可接受分析，以根据安全论据识别和解决危害，设计缺陷和过程缺陷。

a) 及时收集数据并分析运行时监视日志

1) 包括在项目级测试期问获取的日志

b) 分析旨在识别新的危害

c) 识别不正确的安全案例假设

d) 识别错误分析的发生率 :

1) 可接受的风险

2) 减轻故障

3) 未缓解但可检测的故障

4) 未缓解，未发现的故障

注意 : 这可能需要通过观察事件，异常和其他间接检测方法来推断。

e) 识别不正确的对象或事件分类

f) 识别对象 / 事件分类中的基本模糊性，不确定性和 / 或抖动

6.7.4 应考虑监视项目性能以检测与安全相关的设计参数规格的偏差，例如 :

a) 数据网络误码率

b) 设计操作行为的差异

示例 : 与预期的缓冲区距离值相比，最接近障碍物的点的分布。

c) 预测值与实际结果相差太大

示例 : 对象行为预测。

d) 监控危害检测和缓解性能

示例 : 检测和报告 ODD 违规事件以及对这些事件的项目响应。

7 集成开发与验证 -- 组件层面

7.1 集成开发与验证--组件层面概述

本章节的目的是 :

a) 确保相关项所包含组件的每一个要素的软硬件集成安全。 ( 请参阅第 7.2 节 ) 。

b) 确保组件层级的集成与验证活动的完整性。 ( 请参阅第 7.3 节 ) 。

c) 确保组件层级的 ( 请参阅第 7.4 节 ) 。

d) 确保组件层面的验证包含有明确的测试目标与测试方法。 ( 请参阅第 7.5 节 ) 。

图 7.1 集成开发与验证 -- 组件层面结构图

7.2 相关项软硬件集成

7.2.1 应对按照规范开发的硬件和按照规范开发的软件进行集成 , 作为表 7.1 ～表 7.7 中测试活动的对象。

表 7.1 导出集成测试案例的方法

方法		ASIL 等级
方法		A	B	C	D
1a	需求分析	＋＋	＋＋	＋＋	＋＋
1b	外部接口和内部接口分析	＋	＋＋	＋＋	＋＋

1c	软硬件集成等价类的生成和分析	＋	＋	＋＋	＋＋
1d	边界值分析	＋	＋	＋＋	＋＋
1e	基于知识或经验的错误猜测法	＋	＋	＋＋	＋＋
1f	功能的相关性分析	＋	＋	＋＋	＋＋
1g	相关失效的共有限制条件、次序及来源分析	＋	＋	＋＋	＋＋
1h	环境条件和操作用例分析	＋	＋＋	＋＋	＋＋
1i	现场经验分析	＋	＋＋	＋＋	＋＋

7.2.2 该要求适用于 ASIL C 和 D 等级 : 应以适当的覆盖率测试软硬件接口 (HSI) 要求 , 同时考虑 ASIL 等级或应给出没有关于 HSI 遗留问题的理由。

注 : 首选使用用于生产的硬件和软件。如必要 , 特定测试技术可以使用修改的硬件或者软件。

7.3 组件层级集成与验证活动

7.3.1 集成和验证活动应验证组件的实施和集成是否符合规定的融合安全开发规范。

7.3.2 应考虑规定融合安全规范的整合和验证活动。

a)) 在开发阶段与网络安全有关的部分。

b)) 拟用于批量生产的配置，如果适用。

c)) 有足够的能力来支持所定义的融合安全规范中规定的功能。

注 1 ：这可以包括车辆集成和验证。

注 2 ：核查的方法可以包括：

a) 基于要求的测试

b) 接口测试

c) 资源使用评估

d) 验证控制流和数据流

e) 动态分析

f) 静态分析

注 3 : 如果采用测试验证，可以选择测试用例和测试环境，考虑 :

a) 测试的整合程度，以实现验证目标。

b) 根据对所选测试环境的分析，例如，由于最终集成的目标处理器的数据字和地字的位宽与处理器仿真或开发环境不同在随后的集成活动中进行额外测试的必要性。

注 4: 推导测试用例的方法可以包括 :

a) 对需求的分析

b) 等价类的生成和分析

c) 边界值分析

d) 基于知识或经验的错误猜测

7.3.3 如果采用测试验证，应使用定义的测试覆盖率指标评估测试覆盖率，以确定测试活动的充分性。

注：标准的测试覆盖率指标对网络安全来说可能是不够的，例如，软件的声明覆盖率。

7.3.4 应进行测试，以确认组件中剩余的未识别的弱点和漏洞被最小化。

注 1 ：不必要的功能可能包含一个弱点。

注 2 ：测试方法可以包括 :

a) 功能测试

b) 漏洞扫描

c) 模糊测试

d) 渗透测试

7.4 验证和确认策略

7.4.1 定义验证和确认策略 , 以提供实现目标的论据 , 以及如何实现确认目标。验证和确认策略涵盖了车辆的全部预期功能 , 包括电气 / 电子要素和其他被认为与实现 SOTIF 相关的技术要素。

注：验证和确认策略也支持对 SOTIF 相关的外部来源的数据进行监控。

7.4.2 对于从表 6.2 或其他来源中选择的每个方法 , 定义了适当的开发工作 ( 例如累积测试长度、分析深度 ) 。提供了定义每项工作的理由。这可能包括场景的数量或分布、试验数量或仿真持续时间。

表 7.2 导出集成测试案例的方法

方法
A	需求分析
B	外部和内部接口分析
C	等价类的生成与分析
D	边界值分析
E	基于知识或经验的错误猜测法
F	功能的相关性分析
G	共同限制条件和次序的分析
H	环境条件和操作用例分析
I	现场经验和教训分析
J	系统架构 ( 包括冗余 ) 分析
K	传感器设计及其已知潜在局限性分析
L	算法及其决策路径以及各自的已知局限性分析
M	系统和部件老化分析
N	触发条件分析
O	性能目标分析
P	危害分析中可测量参数的分析
Q	边界值中极端场景和边缘场景的分析
R	现有系统的 SOTIF 相关更新的分析
S	使用包含收集到的测试用例和场景的数据库
T	场景和用例的优先度子集分析和使用
U	接受准则的分析
V	事故场景数据分析
W	执行器中已知潜在限制的分析

7.5 测试目标与测试方法

7.5.1 为了发现系统设计中的系统性故障 , 在软硬件集成过程中 , 对于按照表 6.2~ 表 6.6 得出的测试目标 , 应使用对应表中给出的可行的测试方法来实现。

注 : 基于系统已实施的功能、功能复杂性或分布特性 , 如有足够的理由 , 将测试方法用于其他集成的子阶段是合理的。

7.5.2 技术安全要求在软硬件层面的正确执行 , 应使用表 7.3 中给出的可行的测试方法进行论证。

表 7.3 技术安全要求在软硬件层面的正确执行

方法		ASIL 等级
方法		A	B	C	D
1a	基于需求的测试 a	＋＋	＋＋	＋＋	＋＋
1b	故障注入测试 b	＋	＋＋	＋＋	＋＋
1c	背靠背测试 c	＋	＋	＋＋	＋＋
a 基于需求的测试是指针对功能性和非功能性要求的测试。 b 故障注入测试使用特殊的方法向运行中的测试对象注入故障。这可以通过特殊的测试接口在软件中完成 , 或通过特殊准备的硬件完成。该方法经常用于提高安全要求的测试覆盖率 , 因为在正常运行中安全机制不会被调用。 c 背靠背测试对比测试对象和仿真模型对相同激励的反应 , 以发现模型和其实现的表现差异。

注 : 表 7.2 和表 10 的条目 1b 的工作量差异 , 是由系统层的故障注入测试的工作量引起的。

7.5.3 安全机制在软硬件层的正确功能性能、准确性和时序 , 应使用表 6.3 中给出的可行的测试方法进行论证。

表 7.4 安全机制在软硬件层的正确功能性能、准确性和时序

方法		ASIL 等级
方法		A	B	C	D
1a	背靠背测试 a	＋	＋	＋＋	＋＋
1b	性能测试 b	＋	＋＋	＋＋	＋＋
a 背靠背测试对比测试对象和仿真模型对相同激励的反应 , 以发现模型和其实现的表现差异。 b 性能测试可验证在整个测试对象环境中的性能 ( 如任务调度、时序、功率输出 ), 也可验证目标控制软件与硬件同时运行的能力。

7.5.4 外部和内部接口在软硬件层执行的一致性和正确性 , 应使用表 7.5 中给出的可行的测试方法进行论证。

表 7.5 外部和内部接口在软硬件层执行的一致性和正确性

方法		ASIL 等级
方法		A	B	C	D
1a	外部接口测试 a	＋	＋	＋＋	＋＋
1b	内部接口测试 a	＋	＋＋	＋＋	＋＋
1c	接口一致性检查 a	＋	＋＋	＋＋	＋＋
a 测试对象的接口测试包括模拟和数字输入输出的测试、边界测试和等价类测试 , 用来完整的测试被测对象的特定接口、兼容性、时序及其他特定等级。对于 ECU 内部接口的测试 , 可以用静态测试检测软件和硬件兼容性 , 也可用动态测试检测串行外设接口 ( SPI ) 或集成电路 ( IC ) 通信或 ECU 其他要素间的任意接口。

7.5.5 对于硬件失效探测机制在软硬件层面上与故障模型有关的诊断覆盖率的有效性 , 应使用表 7.6 中给出的可行的测试方法进行论证。

表 7.6 安全机制在软硬件层面的诊断覆盖率的有效性

方法		ASIL 等级
方法		A	B	C	D
1a	故障注入测试 a	＋	＋	＋＋	＋＋
1b	错误猜测法测试 b	＋	＋	＋＋	＋＋
a 故障注入测试使用特殊的方法向运行中的测试对象注入故障。这可以通过特殊的测试接口在软件中完成 , 或通过特殊准备的硬件完成。该方法经常用于提高安全要求的测试覆盖率 , 因为在正常运行中安全机制不会被调用。 b 错误猜测法测试使用专家知识和经验教训中收集的数据来预测被测对象的错误。然后设计一组包括适当的测试设备的测试以检查这些错误。如果测试者有相似测试对象的经验时 , 错误猜测法是一种有效的方法。

7.5.6 要素在软硬件层的鲁棒性水平 , 应使用表 7.7 中给出的可行的测试方法进行论证。

表 7.7 在软硬件层的鲁棒性水平

方法		ASIL 等级
方法		A	B	C	D
1a	资源使用测试 a	＋	＋	＋＋	＋＋
1b	压力测试 b	＋	＋	＋＋	＋＋
a 资源使用测试可静态的完成 , 或通过运行监控来动态的完成。示例 : 通过检查编码量或分析关于中断使用的编码 , 目的是验证最恶劣案例的情况不会耗尽资源。 b 压力测试验证测试对象在高运行负荷或高环境要求下能否正确运行。因此 , 测试可以通过施加高负荷、或异常的接口负荷、或一些值 ( 总线负载、电击等 ) 完成 , 也可以是极限的温度、湿度或机械冲击测试。

8 集成开发与验证 -- 系统层面

8.1 集成开发与验证--系统层面概述

本章节的目的是 :

a) 确保构成一个完整系统的一个相关项的所有要素的集成安全。 ( 请参阅第 8.2 节 )

b) 确保满足系统层级的集成测试要求。 ( 请参阅第 8.3 节 )

c) 确保系统层级的集成与验证活动。 ( 请参阅第 8.4 节 )

d) 确保系统层面的验证包含有明确的测试目标与测试方法。 ( 请参阅第 8.5 节 )

1739500733733

图 8.1 集成开发与验证 -- 系统层面结构图

8.2 系统层级集成要素

8.2.1 组成系统的各个要素应按照系统设计进行集成 , 并按照本文档 8.5 节规定的系统集成测试进行测试。

注 : 测试目的是提供证据证明各个系统要素正确交互、符合技术和功能安全要求 , 并为没有可能导致违背安全目标的非预期行为提供足够的置信度水平。

8.2.2 应避免遗漏关键功能（如感知、决策、控制）或接口，确保各模块之间的逻辑关系和数据流符合设计预期。

示例 : 感知模块的输出是否能够正确传递给决策模块。

8.2.3 应全面识别集成要素，可以在早期发现潜在的设计问题（如接口不兼容、资源冲突）。

8.2.4 应充分考虑传感器（摄像头、雷达、激光雷达等）、计算平台（ ECU ）、执行器（转向、制动、油门控制）、软件模块（感知、定位、决策、规划、控制）、通信网络（ CAN 、以太网）、电源管理、人机交互（ HMI ）以及云端服务等系统集成要素。

8.2.5 应采取符合需求的集成策略，如下表 8.1 所示：

表 8.1 系统集成策略

	集成策略	策略定义
1a	自底向上集成	从最底层的硬件和软件模块开始，逐步向上集成到子系统，最终形成完整系统
1b	自顶向下集成	从系统顶层功能开始，逐步向下集成底层模块
1c	增量式集成	将系统划分为多个增量模块，逐步集成和测试
1d	混合式集成	结合自底向上和自顶向下的策略，根据系统特点灵活选择集成顺序
1e	分层集成	按照系统架构的层次（如硬件层、操作系统层、应用层）逐层集成
1f	基于接口的集成	以接口为核心，确保各模块的接口兼容性和数据一致性
1g	持续集成（ CI ）	通过自动化工具频繁集成和测试代码变更
1h	基于模型的集成	使用模型（如 Simulink 、 SysML ）描述系统行为和接口，通过仿真验证集成
1i	基于场景的集成	根据实际使用场景逐步集成和测试系统功能

8.2.6 建议采取分层集成策略，从硬件层面与软件层面进行逐步集成，并将硬件和软件统一部署到目标平台，验证软硬件协同工作的实时性和资源分配（如算力、内存占用）：

a) 硬件层集成

1) 将传感器（摄像头、激光雷达、毫米波雷达等）、计算单元（ ECU ）、执行机构（转向、制动、油门等）通过通信总线（ CAN 、以太网）连接。

2) 验证物理接口兼容性（如电源、信号电平、机械安装）及通信协议一致性（如 CAN 报文格式、周期和优先级）。

a) 软件层集成

1) 按照模块化设计，依次集成感知、定位、决策、规划、控制等算法模块。

2) 确保软件组件间的接口 (API 、中间件如 ROS/DDS) 兼容，数据格式 ( 点云、图像、控制指令 ) 正确传递。

8.3 系统集成测试验证要求

8.3.1 应识别使用的测试与验证方法，至少包括每种方法 :

a) 每种测试与验证方法

示例 : 同行评审，静态分析，单元测试，模拟，项目测试，形式证明，检查，审阅者分析

b) 描述活动如何进行以及活动产生什么工作产品。

c) 识别覆盖率指标

示例 : 对新代码和代码修改进行同行评审，对修改后的代码进行单元测试。

d) 追溯策略

注 : 此项要求确定 V &V 活动与其他设计活动之间的关系，以及在适当情况下最终项目的性能。这并不是要求每种 V &V 技术在部署项目操作方面都必须高度现实，而是要求说明正在为整个 V &V 活动做出贡献的属性或条件。在某些情况下，与最终项目操作的关系可能是间接的，例如确保实现满足其设计目标。

8.3.2 应对实物测试做出限制，确保其在符合条件的覆盖范围内进行。

示例 : 封闭课程测试， HIL 测试，公共道路测试

注 1: 物理测试至少可以起到两个作用。一种是验证项目。另一个是收集可能包含意外操作环境数据的其他数据。这是两个单独的目的，在某些情况下，可以通过分别解决这两个目的来改进论点一个特定的意图是，如果没有某种形式的确认性物理测试，则不会将包括软件，数据，配置，校准或硬件更新在内的所有内容部要到项目中。

注 2: 就非参与者暴露于潜在项目故障的影响而言，公共道路测试存在独特的风险。可接受的测试安全方法是必不可少的，但超出了本标准的范围。

8.3.3 具体测试与验证内容可参考如下进行：

a) 同行评审

b) 静态分析

1) 识别静态分析技术

注 1: 这可以采用识别工具和工具功能的形式

2) 证明静态分析的严谨性

注 2: 这包括证明选择的工具和使用的工具配置是可接受的

d) 坚固性和 / 或压力测试

e) 软件资格测试

示例 : 符合 IEEE12207 标准的软件要求

8.3.4 有关性能验证测试的要求可参考如下进行：

a) 系统必须在规定时间内完成数据处理和响应。

1) 端到端延迟 ( 如从传感器采集到执行器响应的总时间 ≤ 200ms ) 。

2 ) 关键任务周期 ( 如控制指令更新频率 ≥100Hz ) 。

b) 硬件资源 ( CPU 、 GPU 、内存 ) 和通信带宽占用不得超过设计阈值

1) 监控计算平台的实时资源消耗。

2) 压力测试 ( 如高密度交通场景下的算力负载测试 ) 。

c) 系统在极端条件下 ( 如高负载、低电量、信号干扰 ) 仍能稳定运行

1) 注入噪声或干扰 ( 如传感器数据抖动、通信延迟 ) 。

2) 测试系统在资源不足时的降级策略 ( 如算力超限时关闭非关键功能 ) 。

8.3.5 有关测试过程与文档的要求可参考如下进行：

a) 保证测试过程的可追溯性

1) 测试用例需与需求、设计文档和风险分析关联。

注 1: 使用需求管理工具 ( 如 DOORS 、 Jama ) 建立双向追溯矩阵。

b) 实现测试自动化

1) 提高测试效率和重复性，支持持续集成 ( CI/CD ) 。

注 1: 自动化测试框架（如 Robot Framework 、 ROS 测试工具。

注 2: CI/CD 平台 ( 如 Jenkins 、 GitLab CI ) 。

b) 记录测试报告与问题管理

1) 记录测试结果、缺陷和修复验证。

注 1: 生成详细测试报告（包括通过率、性能指标）。

注 2: 使用问题跟踪系统（如 JIRA 、 Bugzilla ）管理缺陷闭环。

8.4 系统层级验证与确认活动

8.4.1 定义验证和确认策略 , 以提供实现目标的论据 , 以及如何实现确认目标。验证和确认策略涵盖了车辆的全部预期功能 , 包括电气 / 电子要素和其他被认为与实现 SOTIF 相关的技术要素。

注：验证和确认策略也支持对 SOTIF 相关的外部来源的数据进行监控。

8.4.2 对于从其他来源中选择的每个方法 , 定义了适当的开发工作 ( 例如累积测试长度、分析深度 ) 。提供了定义每项工作的理由。这可能包括场景的数量或分布、试验数量或仿真持续时间。

8.4.3 考虑到集成层面 , 验证和确认策略 ( 例如 , 集成测试用例、分析 ) 的规范可使用适当的方法组合导出 , 如表 8.2 所示。

表 8.2 验证和确认活动的导出方法

方法
A	需求分析
B	外部和内部接口分析 a
C	等价类的生成与分析
D	等价类的生成与分析
E	基于知识或经验的错误猜测法
F	功能的相关性分析
G	共同限制条件和次序的分析
H	环境条件和操作用例分析 b
I	现场经验和教训分析 c
J	系统架构 ( 包括冗余 ) 分析
K	传感器设计及其已知潜在局限性分析
L	算法及其决策路径以及各自的已知局限性分析
M	系统和部件老化分析 d
N	触发条件分析
O	性能目标分析 e
P	危害分析中可测量参数的分析
Q	边界值中极端场景和边缘场景的分析 f
R	现有系统的 SOTIF 相关更新的分析
S	使用包含收集到的测试用例和场景的数据库
T	场景和用例的优先度子集分析和使用
U	接受准则的分析
V	事故场景数据分析
W	执行器中已知潜在限制的分析
a 如适用如果可以的话 , 还包括 V2X 、地图。 b 包括系统或其要素潜在危害行为的已知来源。 c 这考虑了各种驾驶条件、驾驶风格、驾驶环境和终端用户要求。 d GB / T34590 ( 所有部分 ) 通常会考虑导致失效的半导体老化效应。与 SOTIF 相关的半导体老化效应 , 即影响标称性能的老化效应 , 都在本文件的范围内。 e 性能目标可以在不同的抽象层面上指定 , 例如传感器层面 ( 雷达的探测范围、摄像头的角分辨率 ) 以及系统层面 ( 例如目标探测的误报率 ) 。 f 极端场景是指两个或两个以上的参数值都在系统的能力范围内 , 但共同构成了挑战其能力的罕见情况。边缘场景指由于系统处于极值状态 , 或者系统的一个或多个参数导致挑战系统能力的情况。

8.4.4 应保证系统层级的验证与确认 (V &V) 活动可以确保系统满足功能、性能等方面要求，涵盖从需求到实际场景的全生命周期验证，并确保系统设计、实现与用户需求、功能需求、安全需求完全一致 :

a) 需求可追溯性

1) 建立需求双向追溯矩阵（从系统需求到设计模块、测试用例）。

2) 使用需求管理工具（如 DOORS 、 Jama ）确保无遗漏。

b) 需求覆盖性

1) 验证需求覆盖所有用户场景（正常、异常、极端场景）。

2) 例如：用户需求 “ 高速路自动驾驶 ” 需覆盖车道保持、自动变道、前车跟随等子功能。

c) 需求一致性

1) 检查需求间的逻辑一致性，避免冲突（如功能优先级矛盾）。

2) 通过需求评审会议（如 FMEA ）识别潜在冲突。

8.5 测试目标与测试方法

8.5.1 为了发现系统集成过程中的系统性故障 , 对于按照 8.5.2~8.5.6 得出的测试目标 , 应使用对应表中给出的适当的测试方法来实现。

注 : 基于系统已实施的功能、功能复杂性或分布特性 , 如有足够的理由 , 将测试方法用于其他集成的子阶段是合理的。

8.5.2 功能和技术要求在系统层面的正确执行 , 应使用表 8.3 中给出的可行的测试方法进行论证。

表 8.3 功能安全和技术安全要求在系统层面的正确执行

方法		ASIL 等级
方法		A	B	C	D
1a	基于需求的测试 a	＋＋	＋＋	＋＋	＋＋
1b	故障注入测试 b	＋	＋	＋＋	＋＋
1c	背靠背测试 c	o	＋	＋	＋＋
a 基于需求的测试是指针对功能性和非功能性要求的测试。 b 故障注入测试使用特殊的方法向系统注入故障。这可以通过特殊的测试接口、或特殊准备的要素、或通讯设备在系统内完成。该方法经常用于提高安全要求的测试覆盖率 , 因为在正常运行中安全机制不会被调用。 c 背靠背测试对比测试对象和仿真模型对相同激励的反应 , 以发现模型和其实现的表现差异。

8.5.3 该要求适用于 ASIL(A) 、 B 、 C 和 D 等级 : 安全机制在系统层的正确功能性能行为、准确性和时序 , 应使用表 8.4 中给出的可行的测试方法进行论证。

表 8.4 安全机制在系统层的正确功能性能、准确性和时序

方法		ASIL 等级
方法		A	B	C	D
1a	背靠背测试 a	o	＋	＋	＋＋
1b	性能测试 b	o	＋	＋	＋＋
a 背靠背测试对比测试对象和仿真模型对相同激励的反应 , 以发现模型和其实现的表现差异。 b 性能测试可验证相关系统安全机制的性能。示例 1 ：执行器速度或强度。示例 2 ：整个系统的响应时间 .

8.5.4 外部和内部接口在系统层面执行的一致性和正确性 , 应使用表 8.5 中给出的可行的测试方法进行论证。

表 8.5 外部和内部接口在系统层面执行的一致性和正确性

方法		ASIL 等级
方法		A	B	C	D
1a	外部接口测试 a	＋	＋＋	＋＋	＋＋
1b	内部接口测试 a	＋	＋＋	＋＋	＋＋
1c	接口一致性检查 a	o	＋	＋＋	＋＋
1d	通讯和交互测试 b	＋＋	＋＋	＋＋	＋＋
a 系统的接口测试包括模拟和数字输入输出的测试、边界测试和等价类测试 , 用来完整的测试系统的特定接口、兼容性、时序及其他特定参数。对于系统内部接口的测试 , 可以用静态测试 ( 如接插件的匹配 ), 也可用总线通信或系统其他要素间任意接口相关的动态测试。 b 通讯和交互测试包括系统要素间及被测系统和车辆其他运行系统间，针对功能性和非功能性要求的通讯测试。

8.5.5 该要求适用于 ASIL (A) 、 (B) 、 C 和 D 等级 : 安全机制在系统层面的失效覆盖率的有效性 , 应使用表 8.6 中给出的可行的测试方法进行论证。

表 8.6 安全机制在系统层面的失效覆盖率的有效性

方法		ASIL 等级
方法		A	B	C	D
1a	故障注入测试 a	＋	＋	＋＋	＋＋
1b	错误猜测法测试 b	＋	＋	＋＋	＋＋
1c	来自现场经验的测试	o	＋	＋＋	＋＋
a 故障注入测试使用特殊的方法向系统注入故障。这可以通过特殊的测试接口、或特殊准备的要素、或通讯设备在系统内完成。该方法经常用于提高安全要求的测试覆盖率 , 因为在正常运行中安全机制不会被调用。 b 错误猜测法测试使用专家知识、经验教训中收集的数据和现场经验预测系统中的错误。然后设计一组包括适当的测试设备的测试以检查这些错误。如果测试者有相似系统的经验时 , 错误猜测法是一种有效的方法。

8.5.6 系统层面的鲁棒性水平应使用表 8.7 中给出的可行的测试方法进行论证。

表 8.7 系统层面的鲁棒性水平

方法		ASIL 等级
方法		A	B	C	D
1a	资源使用测试 a	o	＋	＋＋	＋＋
1b	压力测试 b	o	＋	＋＋	＋＋
1c	特定环境条件下的抗干扰性和鲁棒性测试 c	＋＋	＋＋	＋＋	＋＋
a 系统层面的资源使用测试通常在动态环境中进行 [ 如 : 试验室车辆模型 ( labcar ) 或原型车 ] 。测试的问题包括功耗和总线负荷。 b 压力测试验证在高运行负荷或高环境要求下系统能否正确运。因此 , 测试可以通过在系统上施加高负荷、或极限的用户输入、或来自于其他系统的极限要求完成 , 也可以是极限的温度、湿度或机械冲击测试。 c 在特定环境条件下的抗干扰性和鲁棒性测试 , 是一种特殊的压力测试 , 包括电磁兼容性 ( EMC ) 和静电放电 ( ESD ) 测试。

8.5.7 应验证集成到整车中的系统的鲁棒性和可控性 , 以及系统组件的正确交互的方法 , 如表 8.8 所示。

表 8.8 集成系统验证

方法
A	验证系统鲁棒性 ( 例如通过噪声注入测试 ) a
B	在整车集成环境或系统测试台架上进行的基于需求的测试 ( 示例 : 性能目标和行为特征 , 可测量参数、范围、精度、分辨率、时序约束、带宽 )
C	对选定的 SOTIF 相关用例和场景 , 结合已确定的触发条件进行在环测试 ( 例如 : SIL 、 HIL 、 MIL )
D	不同环境条件下的系统测试 ( 示例 : 低温、潮湿、光照、能见度条件、干扰条件 )
E	验证系统老化影响 ( 示例 : 加速寿命测试 )
F	定向随机输入测试 b
G	对选定的 SOTIF 相关用例和场景 , 结合已识别的触发条件进行实车测试
H	可控性测试 ( 包括可合理预见的误用 )
I	验证内部和外部接口
J	车载传感系统特性验证 c
K	验证架构属性 , 包括触发条件的独立性 ( 如果适用 )
L	通过对已知危害场景进行回注仿真 , 来验证已实施的风险缓解机制的效果
a 这还包括整个 ODD 和 OEDR 的鲁棒性的验证 , 以及包括超出 ODD 在内的最小风险状态策略的稳健执行的验证。 b 预期的现实世界场景通常很难重现 , 因此随机输入测试可以作为替代 , 例如如下情况 : —— 图像传感器添加翻转图像或更改的图像块 ; —— 雷达传感器添加虚假目标以模拟多路径返回 ; —— 雷达传感器因多车雷达干扰增加虚假目标或丢失检测目标。 c 这包括不同传感器在不同运行条件下的工作和传感器位置的误差。 ( 示例 : 当一种传感器技术的能力不足时 , 如雾或挡风玻璃反射率影响摄像头、保险杠 / 标志的形状和油漆类型影响雷达 )

注 1: 对于非确定性系统的验证 , 可能使用统计方法或风险管理技术进行已知危害场景的评估。

示例 : 驾驶策略行为依赖于对道路参与者的假设 , 特别是在存在遮挡时 , 在某些情况下遵循已知的非危害行为可能会导致碰撞。

9 集成开发与验证--整车层面

9.1 集成开发与验证--整车层面概述

本章节的目的是 :

a) 明确整车层面的验证测试内容，对智能驾驶车辆整车进行全覆盖测试。 ( 请参阅第 9.2 节 )

b) 针对智能驾驶信息与网络安全风险评估的安全目标，进行安全验证 ( 请参阅第 9.3 节 )

c) 提出针对整车层面的测试目标与测试方法，保证三个功能安全层面的统一性。 ( 请参阅第 9.4 节 )

d) 应针对典型车辆上所集成的元素的安全目标进行确认 ( 请参阅第 9.5 节 )

1739322264140

图 9.1 集成开发与验证 -- 整车层面结构图

9.2 整车层面测试定义

9.2.1 应将相关项集成到整车上 , 并完成整车集成测试。

9.2.2 应对相关项与车内通讯网络以及车内供电网络的接口规范进行验证。

9.2.3 应建立整车层面的功能测试体系，包含模块验证矩阵和相应的测试方法，例如：

a) 模块验证矩阵

1) 感知系统

多传感器融合精度（激光雷达 ±2cm/ 相机识别率 ≥99.5% ）。

2) 决策规划

路径规划响应时间＜ 200ms ，变道成功率＞ 98% 。

3) 执行控制

转向精度 ±0.5° ，制动距离偏差 ≤5% 。

4) 典型场景库

包含 200+ 标准化场景（ ODD 内）。

5) 极端场景

最小跟车距离 0.5m 急刹、 15% 坡度启停。

b) 测试方法

1) SIL 平台

200 万公里虚拟场景验证。

2) 封闭场地

V2X 通信时延＜ 10ms 。

3) 影子模式

5000 小时真实路况数据回灌。

9.2.4 应建立完整的整车层面安全性测试框架，从融合安全角度，完善测试工具链，多维度保证验证测试的全覆盖性，例如：

a) 多维度验证：

1) 功能安全

单点故障覆盖率＞ 90% ， ASIL D 级要求。

2) SOTIF

长尾场景识别率提升 30% 。

3) 网络安全

渗透测试覆盖 CAN/LIN/ 以太网所有接口。

4) 故障注入

2000+ 故障模式库，包括传感器失效、 ECU 宕机等。

b) 测试工具链

1) 失效模式影响分析 (FMEA) 工具。

2) 威胁分析与风险评估 (TARA) 平台。

3) ISO/SAE 21434 合规性检查系统。

9.2.5 应建立完善的人机交互测试要求，应包含相应的核心指标以及常用或突发的交互测试场景，确保智能驾驶系统在不同场景下能够提供直观、可靠且符合人类认知习惯的交互体验，例如：

a) 核心指标：

1) 接管请求 (TOR)

响应时间 3 秒内完成率＞ 95%.

2) 报警误报率

误报率＜ 0.1 次 / 千公里。

3) 界面认知负荷

NASA-TLX 评分＜ 50 。

4) 驾驶员监控

疲劳检测准确率＞ 98% 。

b) 测试场景：

1) 三级预警体系（提示 / 警告 / 紧急接管）。

2) 多模态交互验证（语音 / 触觉 / 视觉协同）。

3) 跨文化差异测试（符号识别全球适配）。

9.2.6 应建立完善的环境适应性测试，极端条件下的感知系统性能（如目标识别率、感知距离衰减）、决策规划响应时间、执行控制精度（如转向、制动）以及系统整体功能的正常运行能力，同时还需模拟隧道明暗交替、沙尘、冰雪等复杂场景，确保系统能够在全球范围内适应多样化的地理、气象和电磁环境，满足车规级可靠性要求，如下表所示：

表 9.1 环境适应性测试 ( 部分 )

	环境维度	测试参数	验收标准
1a	气象	暴雨 (100mm/h)	感知距离衰减＜ 20%
1b	光照	10^5lx 强逆光	目标识别率＞ 90%
1c	电磁	200V/m 干扰场强	系统误动作率 =0
1d	地理	海拔 5000m 工况	动力响应延迟＜ 300ms
验证方法： 1) 四立柱环境舱： -40℃~85℃ 温变测试。 2) 光学暗室：模拟隧道明暗交替（ 0-80000lx ）。 3) EMI 实验室： ISO 11452 系列标准测试。

9.3 网络信息安全验证

9.3.1 应明确整车层面的网络安全目标内容，确保系统在设计、开发、运行及维护全生命周期中具备抵御网络攻击的能力，保障车辆功能安全、数据隐私及用户信任：

a) 通信安全

注： 1) 实现通信协议加密（如 TLS 1.3 ）与认证（如 MAC 地址绑定）。

2) 验证防重放攻击机制，确保数据包不可被恶意重复利用。

3) 测试总线通信抗干扰性，满足 ISO 13400 等标准。

b) 数据安全

注： 1) 验证数据存储安全（如 HSM 硬件加密）。

2) 测试数据传输加密（如 AES-256 ）与差分隐私技术。

3) 防范数据篡改风险，确保数据完整性校验机制有效。

c) 车载 ECU 安全

注： 1) 验证 ECU 固件签名校验与安全启动（ Secure Boot ）。

2) 测试运行时防护机制（如内存隔离、代码签名）。

3) 抵御非法刷写与代码注入攻击。

d) 无线接口攻击

注： 1) 覆盖无线接口漏洞扫描（如 OWASP Top 10 ）。

2) 模拟中间人攻击、 DoS 攻击等场景，验证防护机制有效性。

e) OTA 更新安全

注： 1) 验证升级包签名校验与传输加密（双向认证）。

2) 测试回滚机制，确保升级失败后可安全恢复。

f) 入侵检测与相应

注： 1) 测试 IDS 系统对异常流量（如 CAN 总线洪水攻击）的识别率（＞ 95% ）。

2) 验证响应时效（＜ 500ms ），确保攻击被及时阻断。

9.3.2 应明确当网络安全事故发生时，可采取及时措施，企业能够通知保险公司、提供充分的证据、配合调查、了解保险条款等，确保网络安全索赔的有效性：

a) 建立完善的事件响应机制

1) 制定网络安全事件应对手册，明确各部门职责和响应流程。

2) 定期进行模拟演练，确保团队熟悉应对流程。

b) 加强数据记录和证据保存

1) 建立网络日志和事件记录系统，确保在事件发生时能够快速收集和整理证据。

2) 使用不可篡改的备份系统，确保数据的完整性和可追溯性。

c) 优化网络安全防护措施

1) 实施多因素身份验证（ MFA ）、网络分段、特权访问管理（ PAM ）等技术，降低网络攻击风险。

2) 定期进行漏洞扫描和修复，减少攻击面。

d) 选择合适的网络安全保险

1) 根据企业需求选择覆盖范围广、条款清晰的保险产品，确保涵盖数据泄露、业务中断、法律费用等风险。

2) 在购买保险前，评估企业的网络安全状况，确保符合保险公司的要求。

e) 与保险公司保持良好沟通

1) 在事件发生后，及时与保险公司沟通，了解索赔流程和要求。

2) 在索赔过程中，保持透明和合作态度，避免因信息不对称导致索赔失败。

9.3.3 智能驾驶系统在真实或模拟的硬件、软件、网络及外部交互环境中，应具备能够稳定运行并抵御安全威胁的能力。

a) 硬件平台可靠性

1) 物理接口安全：验证 ECU 、传感器、执行器等硬件接口（如 USB/OBD-II ）的抗物理攻击能力（如电压毛刺注入、信号干扰）。

2) 硬件可信根：确保安全启动（ Secure Boot ）依赖的硬件信任锚（如 TPM 2.0 芯片）不可篡改，支持密钥安全存储与加密运算

3) 环境适应性：测试硬件在极端温度（ -40℃~85℃ ）、振动（ 5Hz~2000Hz ）、电磁干扰（ 200V/m ）下的抗失效能力。

b) 软件运行环境完整性

1) 操作系统安全：验证实时操作系统（如 QNX 、 AutoSAR ）的权限隔离（如进程沙箱）、内存保护（如 ASLR ）及内核漏洞修复。

2) 容器化隔离：测试软件模块在虚拟化环境（如 Docker 容器）中的隔离性，防止恶意代码跨容器传播。

3) 固件更新验证：确保 OTA 固件升级后，软件版本与数字签名匹配，且无残留漏洞。

c) 网络架构合规性

1) 车内网络隔离：验证以太网与 CAN/LIN 网络间的网关防火墙规则（如仅允许白名单信号通过）。

2) 通信协议健壮性：测试通信协议（如 SOME/IP 、 DoIP ）的抗 DoS 攻击能力，确保总线负载率＜ 70% 时功能正常。

3) 外部接口防护：验证 V2X 、蓝牙、 Wi-Fi 等接口的访问控制策略（如 MAC 地址过滤、会话超时机制）。

d) 外部交互环境模拟

1) 恶意设备接入测试：模拟攻击者通过 OBD 端口或充电桩接入车载网络，验证入侵检测系统（ IDS ）的阻断能力。

2) 云端交互安全：测试车云通信（如远程控制指令）的双向认证（如 TLS 1.3 ）与数据加密（如 AES-256 ）。

3) 第三方服务集成：验证地图、语音助手等第三方 API 的权限最小化原则，防止数据越权访问。

e) 实时性与资源约束

1) 安全功能响应时效：确保加密算法（如 ECC ）的执行时间＜ 10ms ，不影响车辆控制实时性。

2) 资源占用监控：测试安全模块（如防火墙、 IDS ）的 CPU/ 内存占用率（＜ 15% ），避免因资源耗尽导致系统崩溃。

9.4 测试目标与测试方法

9.4.1 为了探测整车集成期间的系统性故障 , 由 9.4.2 ～ 9.4.6 得出的测试目标 , 应使用对应表格中所给出的适当的测试方法来实现。

注 : 基于系统已实施的功能、能复杂性或分布特性 , 如有足够理由 , 将测试方法用于其他集成的子阶段是合理的。

9.4.2 功能安全要求在整车层面的正确的执行 , 应使用表 9.2 中给出的可行的测试方法进行论证。

表 9.2 功能安全要求在整车层面上的正确执行

方法		功能安全完整性等级
方法		A	B	C	D
1a	基于需求的测试 a	＋＋	＋＋	＋＋	＋＋
1b	故障注入测试 b	＋＋	＋＋	＋＋	＋＋
1c	长期测试 c	＋＋	＋＋	＋＋	＋＋
1d	实际使用条件下的用户测试 c	＋＋	＋＋	＋＋	＋＋
a 基于需求的测试是指针对功能性和非功能性要求的测试。 b 故障注入测试使用特殊的方法向相关项注入故障。这可以通过特殊测试接口 , 或者特别准备的要素或通讯设备 , 在相关项内部完成。该方法经常用于提高安全要求的测试覆盖率 , 因为在正常运行中安全机制不会被调用。 c 长期测试和实际使用条件下的用户测试 , 类似于来自现场经验的测试 , 但使用更大的样本量 , 将普通用户当作测试者 , 并不局限于之前规定的测试场景 , 而是在日常生活现实条件下执行。为确保测试人员的安全 , 如果有必要 , 这类测试会有限制 , 例如带有额外的安全措施或停用执行器。

9.4.3 该要求适用于 ASIL(A) 、 (B) 、 (C) 和 (D) 等级 : 安全机制在整车层面的正确功能性能、准确性和时序 , 应使用表 9.3 中给出的可行的测试方法进行论证。

表 9.3 安全机制在整车层面的正确功能性能、准确性和时序

方法		ASIL 等级
方法		A	B	C	D
1a	性能测试 a	＋	＋	＋＋	＋＋
1b	长期测试 b	＋	＋	＋＋	＋＋
1c	实际使用条件下的用户测试 b	＋	＋	＋＋	＋＋
a 性能测试可以验证有关相关项的安全机制的性能。示例 : 故障出现时的故障容错时间间隔和车辆的可控性。 b 长期测试和实际使用条件下的用户测试 , 类似于来自现场经验的测试 , 但使用更大的样本量 , 将普通用户当作测试者 , 并不局限于之前规定的测试场景 , 而是在实际使用条件下执行。为确保测试人员的安全 , 如果有必要 , 这类测试会有限制 , 例如带有额外的安全措施或停用执行器。

9.4.4 该要求适用于 ASIL(A) 、 (B) 、 (C) 和 (D) 等级 : 整车层面外部接口实现的一致性和正确性 , 应使用 9.4 中给出的可行的测试方法进行论证。

表 9.4 整车层面内外部接口实现的一致性和正确性

方法		ASIL 等级
方法		A	B	C	D
1a	外部接口的测试 a	o	＋	＋＋	＋＋
1b	通讯和交互测试 b	o	＋	＋＋	＋＋
a 整车层面的接口测试 , 是对整车系统接口的兼容性测试。这些测试可以通过验证值域、额定值或几何尺寸静态的完成 , 也可以在整车运行过程中动态的完成。 b 通讯和交互测试包括车辆系统在运行期间内针对功能性和非功能性要求的交互测试。

9.4.5 该要求适用于 ASIL(A) 、 (B) 、 (C) 和 (D) 等级 : 安全机制在整车层面的失效覆盖率的有效性 , 应使用表 9.5 中给出的可行的测试方法进行论证。

表 9.5 安全机制在整车层面的失效覆盖率的有效性

方法		功能安全完整性等级
方法		A	B	C	D
1a	故障注入测试 a	o	＋	＋＋	＋＋
1b	错误猜测法测试 b	o	＋	＋＋	＋＋
1c	来自现场经验的测试 c	o	＋	＋＋	＋＋
a 故障注入测试使用特殊的方法向车辆注入故障。这可以通过特殊测试接口 , 或者特别准备的硬件或通讯设备 , 在车辆内部完成。该方法经常用于提高安全要求的测试覆盖率 , 因为在正常运行中安全机制不会被调用。 b 错误猜测法测试使用专家知识和经验教训中收集的数据来预测整车错误。然后设计一组包括适当的测试设备的测试以检查这些错误。如果测试者有相似车辆的应用经验时 , 错误猜测法是一种有效的方法。 c 来自现场经验的测试采用从现场收集到的经验和数据。分析错误的车辆行为或者新发现的运行工况 , 并针对这些新发现设计一组测试来检查车辆。

9.4.6 该要求适用于 ASIL(A) 、 (B) 、 (C) 和 (D) 等级 : 整车层面的鲁棒性水平 , 应使用表 9.6 中给出的可行的测试方法进行论证。

表 9.6 整车层面的鲁棒性水平

方法		功能安全完整性等级
方法		A	B	C	D
1a	资源使用测试 a	o	＋	＋＋	＋＋
1b	压力测试 b	o	＋	＋＋	＋＋
1c	特定环境条件下的抗干扰性和鲁棒性测试 c	o	＋	＋＋	＋＋
1d	长期测试 d	o	＋	＋＋	＋＋
a 相关项层面的资源使用测试通常在动态环境中进行 [ 如 : 试验室车辆模型 ( labcar ) 或原型车 ] 。测试的问题包括相关项内部资源、功率消耗或者其他整车系统的有限资源。 b 压力测试验证在高运行负荷或高环境要求下整车能否正确运行。因此 , 测试可以通过在整车上施加高负荷、或极限的用户输入、或来自于其他系统的极限要求完成 , 也可以是极限的温度、湿度或机械冲击测试。 c 在特定环境条件下的抗干扰性和鲁棒性测试 , 是一种特殊的压力测试 , 包括电磁兼容性 ( EMC ) 和静电放电 ( ESD ) 测试。 d 长期测试和实际使用条件下的用户测试 , 类似于来自现场经验的测试 , 但使用更大的样本量 , 将普通用户当作测试者 , 并不局限于之前规定的测试场景 , 而是在实际使用条件下执行。

9.5 安全确认计划

9.5.1 应在整车层面确认相关项的安全目标 , 通过评估 :

a) 可控性 ;

注 : 使用运行场景确认可控性 , 包括预期用途和可预见的误用。

b) 用于控制随机失效和系统性失效的安全措施的有效性 ;

c) 外部措施的有效性 ; 及

d) 其他技术要素的有效性。

9.5.2 应基于安全目标、功能安全要求和预期用途 , 按计划执行整车层面的确认 , 使用 :

a) 包括详细的通过 / 未通过准则的每个安全目标的确认流程和测试案例 ;

b) 应用范围。可包括例如配置、环境条件、驾驶场景和操作用例等。

注 : 可创建操作用例 , 以助于将安全确认集中在整车层面上。

9.5.3 应使用以下方法的适当组合 :

a) 已定义了测试流程、测试案例和通过 / 未通过准则的可重复性测试 ;

示例 : 功能和安全要求的正向测试、黑盒测试、仿真、边界条件下的测试、故障注入、耐久测试、压力测试、高加速寿命测试、外部影响模拟。

b) 分析 ;

示例 : FMEA 、 FTA 、 ETA 、仿真。

c) 长期测试 , 例如车辆驾驶日程安排和受控测试车队 ;

d) 实际使用条件下的用户测试、抽测或盲测、专家小组 ; 及

e) 评审。

10 系统与整车层集成验证场景要求

10.1 系统与整车集成验证场景要求概述

本章的目的是实现以下目标：

a) 应尽可能多的包含不同类别的场景，尤其是不同场景要素的验证。 ( 请参阅第 10.2 节 )

b) 应对进行场景测试的所选方法提供充分性理由。 ( 请参阅第 10.3 节 )

c) 应定义场景的验证测试活动，充分覆盖有关安全的场景空间。 ( 请参阅第 10.4 节 )

d) 应定义潜在危害场景的的验证和确认策略 , 包括确认目标等。 ( 请参阅第 10. 5 节 )

1739322802009

图 10.1 系统与整车集成验证场景要求结构图

10.2 验证场景类别定义

10.2.1 集成和验证活动应验证组件的实施和集成是否符合规定的融合安全开发规范。

10.2.2 应考虑规定融合安全规范的整合和验证活动。

a) 在开发阶段与网络安全有关的部分。

b) 拟用于批量生产的配置，如果适用。

c) 有足够的能力来支持所定义的融合安全规范中规定的功能。

注 1 ：这可以包括车辆集成和验证。

注 2 ：核查的方法可以包括：

d) 基于要求的测试

e) 接口测试

f) 资源使用评估

g) 验证控制流和数据流

h) 动态分析

10.2.3 应完全考虑实际车辆运行环境下的各种可能场景，确保智能驾驶系统在真实使用中的稳定性和可靠性，并提前暴露潜在问题，降低因未测试场景导致的系统失效或安全事故：

a) 功能场景

测试车道保持、自适应巡航控制和自主泊车等功能。

注：确保每个功能按预期独立或组合运行。

b) 环境场景

模拟各种天气条件（如雨、雪、雾）和道路表面。

注：评估系统在不同光照条件和地理环境中的表现。

c) 交通场景

评估与其它车辆、行人的互动及对交通规则的遵守。

注：测试对不可预测的交通情况和紧急车辆的反应。

d) 系统故障场景

评估传感器故障、通信故障和软件错误情况下的系统韧性

注：确保有安全的降级机制。

e) 人机交互场景：

测试用户界面的直观性和响应性，包括触摸屏、语音命令和触觉反馈。

注：验证系统与驾驶员的有效沟通能力。

f) 法规和标准场景

确保符合当地和国际法规，包括安全标准和交通法规。

注：满足自主系统的认证要求。

g) 特殊场景

应对罕见或极端条件，如穿越施工区域或应对紧急情况。

注：测试系统适应独特和具有挑战性的情况的能力。

h) 仿真与实际测试场景

利用仿真软件高效测试广泛场景。

注：在测试轨道和公共道路上进行实际测试，验证实际条件下的性能。

i) 网络安全场景

保护系统免受黑客攻击和数据泄露。

注：确保安全的通信和数据保护机制到位。

j) 长期运行场景

评估系统在长时间运行中的耐用性和性能。

注：测试硬件老化和软件更新的兼容性。

k) 用户体验场景

评估用户的舒适度、满意度和易用性。

注：确保系统满足用户的舒适性和易用性期望。

l) 学习与适应场景

测试系统利用机器学习算法学习和适应不同驾驶风格和条件的能力。

m) 基础设施交互场景

评估车辆与基础设施（ V2I ）通信对交通管理和系统性能的影响。

n) 区域性变异性场景

应对交通规则、道路条件和驾驶行为的区域差异。

注：在普遍化场景中考虑当地具体特点。

10.3 验证场景细化与需求定义

10.3.1 应将智能驾驶所面临的各种复杂交通场景进行更深入、更具体的分类和描述，以便智能驾驶系统能更好地理解和应对不同情况，提升驾驶的安全性和可靠性。

10.3.2 应对智能驾驶系统可能遇到的各种情况进行归类，以便更好地进行需求定义和测试，可参考 10.2.3 条的大类划分：

a) 功能场景

1) 高速公路驾驶：包括但不限于车道保持、自适应巡航、自动变道、匝道合并与分离等。

2) 城市道路驾驶：涵盖交通灯识别与响应、行人检测与避让、拥堵跟车、路口转弯等。

3) 泊车：自动泊车入位、泊车出位、多层停车场导航等。

4) 乡村道路驾驶：应对不规则道路、有限的交通标志和不常见的交通参与者等。

b) 逻辑场景

1) 跟车：在不同速度、不同距离下的跟车行为。

2) 变道：在不同交通密度、不同车道数量下的变道决策。

3) 避障：应对突然出现的障碍物，如行人、自行车、其他车辆等。

4) 紧急情况处理：如爆胎、前车急刹车等。

c) 具体场景

1) 雨天高速行驶：考虑雨量大小、能见度、路面湿滑程度等。

2) 夜间城市道路驾驶：考虑光照条件、行人和非机动车行为等。

3) 施工路段行驶：考虑道路封闭、临时标志、车道减少等。

10.3.3 应具体描述每个涉及场景的静态和动态元素以及环境条件。

a) 静态元素

1) 道路结构：车道数、车道宽度、道路坡度、弯道半径等。

2) 交通标志与标线：限速标志、禁止超车标志、车道线类型等。

3) 建筑物与障碍物：路边建筑、隔离带、路障等。

b) 动态元素

1) 其他车辆：数量、速度、行驶方向、加减速行为等。

2) 行人与非机动车：位置、速度、行进方向、突然变道等。

3) 天气条件：晴天、雨天、雪天、雾天等。

4) 光照条件：白天、夜晚、黎明、黄昏等。

c) 环境条件

1) 路面状况：干燥、湿滑、结冰、泥泞等。

2) 交通密度：低密度、中密度、高密度等。

3) 特殊事件：交通事故、道路施工、紧急车辆通行等。

10.3.4 应建立适当的场景库，包含大量的场景数据和模型，以帮助系统进行算法训练与优化、提升决策能力与效率、实现安全评估与测试：

a) 数据收集

1) 实车测试数据：通过搭载传感器的测试车辆在真实道路上收集数据。

2) 仿真工具生成数据：使用仿真软件生成虚拟场景数据。

3) 公开数据集：利用已有的公开数据集，如 Kitti 、 Waymo Open Dataset 等。

b) 场景建模

1) 三维建模：使用仿真工具创建高精度的三维场景模型。

2) 行为建模：为动态元素（如其他车辆、行人）定义行为模型，模拟其在场景中的行为。

3) 环境建模：模拟不同的天气、光照、路面条件等。

c) 场景管理

1) 场景分类与标注：对场景进行分类和标注，便于检索和使用。

2) 场景库更新：定期更新场景库，加入新的场景和数据。

10.3.5 应保证智能驾驶系统的安全需求在各种情况下都能实现，应包含功能安全、预期功能安全、信息安全与未分类安全目标的实现。

注 1 ：需确定系统在检测到故障时的应对策略，如降级模式、安全停车等。

注 2 ：可通过仿真、测试等手段验证智能驾驶系统的安全性。

10.3.6 为保证智能驾驶系统达到所规定的安全目标需求，应验证其是否具有满足安全目标需求的能力，包含测试用例设计、验证方法、验证指标：

a) 测试用例设计

1) 基于场景的测试用例：根据场景库中的场景设计测试用例。

2) 基于需求的测试用例：根据功能需求和性能需求设计测试用例。

3) 基于故障的测试用例：模拟各种故障情况，验证系统的故障处理能力。

b) 验证方法

1) 仿真测试：在仿真环境中进行测试，验证系统在虚拟场景中的表现。

2) 封闭场地测试：在封闭场地中进行实车测试，验证系统在可控环境中的表现。

3) 开放道路测试：在实际道路上进行测试，验证系统在真实环境中的表现。

c) 验证指标

1) 成功率：系统在测试用例中的成功比例。

2) 故障率：系统在测试过程中的故障频率。

3) 响应时间：系统对特定事件的响应时间。

10.4 验证场景实施要求

10.4.1 应通过科学、系统的验证场景实施要求，保证智能驾驶技术的快速发展和安全落地。

a) 测试用例设计合理性

注：测试用例应基于场景库和系统需求设计，确保覆盖所有功能和性能需求。

1) 每个测试用例应有明确的输入、执行步骤和预期输出。

2) 测试用例应包含正向测试（验证系统在正常条件下的表现）和负向测试（验证系统在异常条件下的表现）。

3) 测试用例应具有可重复性和可追溯性。

b) 测试环境真实性

注：测试环境应尽可能接近真实驾驶环境。

1) 仿真环境：使用高精度仿真工具（如 CARLA 、 Prescan ）模拟真实道路和交通条件。

2) 封闭场地：在封闭测试场地中搭建真实道路场景（如交叉路口、环形道路等）。

2) 开放道路：在实际道路上进行测试，验证系统在真实交通环境中的表现。

c) 测试执行规范性

注：测试执行过程应严格按照测试计划和测试用例进行。

1) 测试前应进行设备检查和环境确认。

2) 测试过程中应实时监控系统状态和数据记录。

3) 测试后应进行数据备份和设备维护。

10.4.2 应保证智能驾驶系统集成与测试的验证场景实施要求覆盖技术性能、安全性、法规合规性及场景覆盖度等多个维度，并结合实际应用场景和标准规范进行系统化规定。

a) 标准化场景建模与参数化

1) 制定统一的场景描述格式（如 ASAM OpenX 系列标准），支持场景的编码、复用与共享。

2) 参数化设计关键要素（如车流量、信号灯时序），实现场景灵活调整与组合。

b) 场景数据库与分类管理

1) 建立典型场景数据库，涵盖中国交通特征（如混合交通流、特殊气候），并按风险等级、功能模块分类存储。

2) 结合真实交通数据与仿真生成数据，确保场景的真实性与覆盖性。

c) 测试工具链的验证与认证

1) 对仿真工具链（如传感器模型、车辆动力学模型）进行保真度验证，确保其与物理测试的一致性。

2) 参考 ISO 34502 等标准，制定虚拟测试平台的认证流程。

d) 法规与行业标准协同

1) 遵循国内外标准（如 ISO 34503 、 GB/T 34590 ）和法规要求，确保测试合规性。

2) 参与团体标准（如 CAICV 场景标准子体系）制定，推动行业统一测试框架。

e) 动态更新与反馈机制

基于测试结果与路测数据，持续优化场景库，覆盖新技术迭代与新风险场景。

10.5 验证场景评估与改进

10.5.1 为保证确保智能驾驶系统安全性和可靠性的闭环，需要对验证的场景的评估基于测试结果、数据分析与行业标准动态优化，以下是基本流程 ( 可根据具体场景添加或删减 ) ：

a) 数据收集与预处理

1) 数据来源

i) 仿真测试数据（逻辑场景、参数化场景）；

ii) 实车测试数据（真实道路、封闭场地）；

iii) 历史事故数据与行业共享场景库（如 PEGASUS 、中国 C-ASAM OE 场景库）。

2) 预处理要求

i) 清洗无效数据（如传感器噪声、重复场景）；

ii) 标准化数据格式（遵循 ASAM OpenDRIVE/OpenSCENARIO ）；

iii) 标注关键指标（如碰撞风险、系统响应时间）。

b) 场景有效性分析

1) 覆盖度评估：

i) 统计场景对运行设计域（ ODD ）的覆盖比例，例如城市道路、高速场景是否覆盖所有设计参数（车流量、天气条件等）；

ii) 识别未被覆盖的 “ 长尾场景 ” （如道路施工、动物闯入）。

c) 风险等级分类：

1) 按 ISO 21448 （ SOTIF ）要求，将场景分为：

i) 已知安全场景（已通过测试）；

ii) 已知风险场景（需优化）；

iii) 未知风险场景（需新增测试用例）。

d) 性能指标量化

1) 核心指标：

i) 功能指标：目标识别准确率、路径规划合理性、控制响应延迟；

ii) 安全指标：碰撞避免率、最小风险操纵（ MRM ）触发成功率；

iii) 鲁棒性指标：极端环境下的性能衰减率（如暴雨中感知失效概率）。

2) 量化方法：

i) 基于统计学方法（如蒙特卡洛模拟）评估指标分布；

ii) 使用关键性能指标（ KPI ）评分卡（如 1-5 分制）横向对比不同场景的表现。

e) 评估报告生成

1) 报告内容：

i) 场景覆盖度分析图（如雷达图、热力图）；

ii) 高风险场景列表及具体失效模式（如感知误检、决策超时）；

iii) 改进建议优先级排序（基于风险等级与修复成本）。

1) 输出要求：

i) 符合 ISO 34502 标准中的测试报告规范；

ii) 提供可追溯性矩阵（ Traceability Matrix ），关联场景需求与测试结果。

10.5.2 为保证智能驾驶系统能够应对真实世界中复杂多变的驾驶环境，提升系统的安全性、鲁棒性和可靠性应通过不断优化和新增测试场景，可以发现并修复潜在风险，避免未知场景导致的失效。

a) 问题优先级排序

1) 风险评估模型：

i) 采用风险矩阵量化场景的严重性与发生概率；

ii) 优先处理高严重性（如可能导致碰撞）或高频率问题（如常见天气下的控制偏差）。

2) 技术可行性分析：

i) 评估改进方案的开发周期与成本（如是否需要升级传感器或算法）。

b) 场景优化与新增

1) 参数调整：

i) 针对失效场景调整参数（如增加极端天气的能见度范围、提高动态障碍物速度阈值）；

ii) 利用强化学习生成更复杂的交互场景（如多车博弈）。

2) 新增边缘场景：

i) 通过真实交通数据挖掘（如路口加塞、行人突然横穿）；

ii) 采用对抗性测试（ Adversarial Testing ）生成极端案例（如传感器信号被干扰）。

c) 改进方案验证

1) 回归测试：

i) 对优化后的场景进行全量或增量测试，确保改进不影响原有功能；

ii) 使用 A/B 测试对比优化前后的性能差异（如刹车距离缩短 20% ）。

2) 多层级验证：

i) 虚拟仿真：快速验证逻辑合理性；

ii) 硬件在环（ HIL ）：验证控制器与传感器信号的兼容性；

iii) 实车测试：在封闭场地或真实道路验证闭环性能。

d) 闭环管理与迭代

1) 更新场景库：

i) 将改进后的场景纳入主场景库，并标注版本与生效条件；

ii) 建立场景生命周期管理机制（如定期淘汰过时场景）。

2) 持续监控：

i) 通过 OTA （远程升级）收集量产车运行数据，发现新风险场景；

ii) 结合用户反馈与事故数据动态更新测试用例。

10.5.3 为保证验证场景评估与改进满足智能驾驶系统安全要求，应对评估方法、场景动态迭代等方面提出实施要求：

a) 标准化评估方法

1) 统一指标定义：避免主观评价，例如 “ 系统响应延迟 ” 需明确从传感器输入到执行器输出的时间阈值（如 ≤100ms ）。

2) 工具链兼容性：确保评估工具（如 MATLAB/Simulink 、 CarMaker ）支持数据无缝对接。

b) 场景动态迭代机制

1) 自动化更新：通过脚本自动将新场景注入测试流程（如 Jenkins 持续集成）；

2) 版本控制：使用 Git 等工具管理场景库版本，记录每次迭代的变更内容。

c) 跨团队协作

1) 多角色参与：

i) 测试工程师（执行评估）；

ii) 算法团队（优化决策逻辑）；

iii) 法规团队（确保符合最新标准）。

2) 数据共享：建立企业级场景数据平台，支持仿真、测试、路采数据的统一调用。

d) 合规性要求

1) 符合功能安全标准：改进方案需通过 ISO 26262 的 ASIL 等级验证；

2) SOTIF 合规：针对未知风险场景的改进需满足 ISO 21448 中的 “ 可接受风险 ” 阈值。

2.1 国际标准和技术规范

2.2 国内标准和技术规范

3 术语缩写与定义

3.1 缩写

3.2 术语和定义

4 集成开发与验证 融合安全概述

5 集成开发与验证总体要求

6 集成验证测试与监控管理

6.2 集成验证测试计划

7 集成开发与验证 -- 组件层面

8 集成开发与验证 -- 系统 层面

9 集成开发与验证--整车层面

10 系统与整车层集成验证场景要求

4 集成开发与验证融合安全概述

8 集成开发与验证 -- 系统层面