摘 要

ISO26262道路车辆功能安全标准已经制定实践了多年，主要目标是应对车辆的电子和电气（E/E）系统失效。该方法践行至今，有些系统功能安全方法已经成熟，例如电池管理系统（BMS），并且已经制定相应功能安全标准GBT 39086，但是，仍有很多人对标准的执行有模糊之处。为此，我们用一个例子来说明功能安全整体方法。

1 导言

汽车系统虽然相对复杂，但考虑其风险，不得不被描述为安全关键系统，除了功能要求外，还必须满足安全要求。更具体地说，安全要求描述了系统为了安全所必须具备的特征，它是必须确保避免或减轻任何潜在不可接受的危险事件的关键属性。如果不遵守安全要求，系统将面临各种可能危及用户安全的漏洞。因此，在汽车系统的设计和开发过程中考虑安全要求，以减少危险事件发生的风险是非常重要的。汽车行业已经在使用安全分析、验证和验证技术来提高车辆安全性。此外，ISO 26262是一项功能安全标准，它为汽车制造商提供了适当的开发流程、要求和安全完整性级别。

2 背景

ISO 26262是一项功能安全标准，其主要目的是提供指南和最佳实践，以提高车辆E/E系统的安全性。它涵盖了整个汽车安全生命周期，包括规范、设计、实施、集成、验证和确认。ISO 26262侧重于E/E系统的危害及其相关风险。然后将相关风险指定为汽车安全完整性等级（ASIL）。ASIL可分为质量管理（QM1）、ASIL A、ASIL B、ASIL C和ASIL D，其中ASIL D需要最高的风险降低工作。下表显示了ISO 26262中与本文相关的条款。

3 处理汽车系统功能安全要求的整体方法

ISO 26262标准，主要考虑车辆的E/E系统，对于机械、液压等其他系统仅在风险分析时作为原因考虑，不能分配ASIL等级（有企业分配了等级，但笔者认为不尽可行）。整体方法的基础过程包括七项主要活动。活动1, 2, 3、4和7分别基于ISO 26262条款C.3-4、C.3-6、C.3-7、C.4-6和C.4-9。活动5和6分别基于第C.5-6条和第C.6-6条。

1-项目定义是流程的第一项活动，其目的是根据项目的主要功能、接口、已知危害、依赖性以及与环境的相互作用来定义项目。在我们的方法中，该活动被扩展为考虑作为项目的一个组成部分的驱动程序，即，在项目的定义期间，也考虑了驱动程序（组件）和项目的网络和物理组件之间的依赖关系和交互。该活动的结果是项目定义。

2-危险分析和风险评估（HARA），当项目定义被认为是完整的时，可以开始。HARA活动可分为两个相关子活动，1-危害分析，其中项目定义用于识别可能的危害事件。由于驱动程序被视为项目的组成部分，因此该活动应考虑可能由于其行为和与项目的其他组件的相互作用/依赖性而产生的危害。2-风险评估，根据三个变量对已识别的危害事件进行分类。1-严重性，衡量每个危险事件的潜在危害，范围从S0到S3，其中S0表示无伤害，S3表示危及生命的伤害。2-暴露，测量项目处于危险事件中描述的运行状态的概率，范围从E0到E4，其中E0表示最低发生概率，E4表示高概率。3-可控性，衡量通过相关人员的及时反应避免特定伤害/损害的能力，范围从C0到C3，其中C0表示一般可控，C3表示难以控制或无法控制。

根据这三个参数，为每个危险指定ASIL。ASIL是一种必要的风险降低措施，其级别范围为QM、ASIL a、ASIL B、ASIL C和ASIL D，其中ASIL D最高。然后，按照ISO 26262的要求，将至少一个安全目标（SG）3分配给ASIL A、B、C或D级危险。这些SGs可用于推导功能安全要求（FSR），其中规定了缓解其相应危险所需的功能。这项活动的结果是SGs。

3-功能安全概念，该活动的主要目标是通过从SGs中推导FSR，然后将FSR分配给项目的元素，来发展功能安全概念。根据ISO 26262，FSR是独立于实施的安全行为/安全措施的规范，包括其安全相关属性。因此，FSR用于定义物品的安全功能，而不指定如何实现这些功能。与ISO 26262不同，该活动应规定FSR，并考虑驱动程序的行为，特别强调其与项目其他组件的交互/依赖性，这有助于在以后的活动中将FSR分配给项目的元素。

4-技术安全概念旨在从FSR中得出技术安全要求（TSR）。特别是，FSR可能处于较高的抽象级别，需要将其细化为更详细的技术需求。与活动4类似，该活动应指定TSR，以提供有关驾驶员行为及其与项目其他组件的交互/依赖关系的更详细信息。请注意，完成整套TSR被认为足以确保该项目符合其功能安全概念。

5-硬件安全要求规范（HWSR）旨在从可分配给硬件的TSR中衍生出HWSR-HWSR是与项目物理硬件相关的安全要求。根据ISO 26262，HWSR应包括与功能安全相关的每个硬件要求的信息，包括安全机制的相关属性，以（a）控制元件硬件的内部故障；（b） 控制或容忍元件外部的故障；（c） 遵守其他要素的安全要求；以及（d）检测内部或外部故障并发出信号。此外，应在该活动中规定该项目硬件元件的设计规范和验证标准。

6-软件安全需求规范（SWSR）旨在从可分配给软件的TSR中衍生出SWSR-SWSR是与项目软件功能相关的安全要求。根据ISO 26262，SWSR应从TSR中衍生出来，考虑到软件所需的安全相关功能和属性，其故障可能导致违反分配给软件的技术安全要求。然后，SWSR可用于定义软件设计规范。

7-安全验证旨在1-提供安全目标充分的证据，2-提供在车辆级别实现安全目标的证据，3-提供安全概念适用于项目功能安全的证据。

摘 要

ISO26262道路车辆功能安全标准已经制定实践了多年，主要目标是应对车辆的电子和电气（E/E）系统失效。该方法践行至今，有些系统功能安全方法已经成熟，例如电池管理系统（BMS），并且已经制定相应功能安全标准GBT 39086，但是，仍有很多人对标准的执行有模糊之处。为此，我们用一个例子来说明功能安全整体方法。

4 该方法在MAS示例中的应用

1.项目定义。

MAS的主要功能是当车辆以50 km/h以上的速度行驶时，允许/防止驾驶员的预期/非预期操作动作。MAS依靠传感器收集有关驾驶员的信息提示：

• 头部姿势和运动，可用于识别驾驶员的视觉方向，并预测一些驾驶员的动作，例如：头部运动可能先于动作；
• 手/脚位置和运动，可用于预测一些驾驶员的动作。此外，MAS依赖于激光雷达和雷达，它们可以提供有关周围车辆/物体的信息。此外，MAS将包括一个软件系统，该系统能够在适当的时间内分析所有提示信息， 以确定驾驶员的操纵是有意的，即它是需求、欲望和/或动机的结果，还是无意的，即没有执行此类操纵的需求、欲望和/或动机。最后，MAS依靠锁执行器来防止驾驶员的意外操作。

2-危害分析和风险评估。该活动有两个子活动：

2.1-危险识别。它分析了项目定义，主要关注项目组件的行为及其相互作用和依赖性可能导致的危险事件。已确定与MAS相关的两个主要危险：

• H1：当车辆以超过50 km/h的速度行驶时，将预期操纵归类为非预期操纵，这会阻止驾驶员执行预期操纵。
• H2：当车辆以50 km/h以上的速度行驶时，将非预期操纵归类为预期操纵，从而允许执行非预期操纵。

2.2-风险评估。根据其严重性、暴露和可控性对每个已识别的危险进行分类。

H1的发生使驾驶员无法执行预期的操作，这可能导致危及生命的伤害甚至死亡。因此，选择最高严重性级别（S3）。选择暴露水平E3（中等概率）是因为有几个原因可能导致将预期动作归类为非预期动作（例如，关于头部姿势和运动、手/脚位置的错误信息提示）。最后，选择最高可控性级别C3，因为驾驶员没有必要的时间执行任何纠正措施以避免潜在伤害。根据H1的严重程度（S3）、暴露（E3）和可控性（C3），确定该危险的ASIL C。

类似地，H2的发生具有最高的严重程度（S3），因为允许进行非预期操作可能会导致危及生命的伤害甚至死亡。暴露水平为中等概率（E3），因为识别非预期的可能会由于错误的信息提示而出错。此外，选择最高可控性级别C3是因为驾驶员可能不知道此类操纵，无法执行任何纠正措施以避免潜在伤害/损害。因此，ASIL C是针对这种危险确定的。按照我们的方法，至少应为每个ASIL A、B、C或D级危险指定一个安全目标（SG）。为此，我们分别为危险H1和H2指定以下两个安全目标（SG1和SG2）：

SG1：当车辆行驶速度超过50 km/h时，不应阻止驾驶员进行预期操纵。

SG2：当车辆行驶速度超过50 km/h时，应防止驾驶员意外操纵。

3-功能安全概念。

根据之前活动中确定的SGs，我们得出了相关的功能安全要求（FSR）。特别是，我们从SG1中得出以下FSR：

FSR1-1：当车辆行驶速度超过50 km/h时，应激活MAS。

FSR1-2：MAS应能够收集所有相关线索信息，以确定是否需要机动。

FSR1-3：MAS应能够收集所有相关提示信息，以确定驾驶员是否有进行机动的愿望或动机。

FSR1-4：MAS应能够验证驾驶员的操作是否在适当的时间内进行。

FSR1-5：MAS不应阻止预期的操纵。

根据SG2，我们得出以下FSR：

FSR2-1:MAS应能在适当时间内识别驾驶员的非预期操纵。

FSR2-2:MAS应防止意外操作。

4-技术安全要求。

本活动的主要目的是将之前活动中确定的FSR细化为更详细的技术要求。推导TSR的过程与从SGs推导FSR的过程类似，但ISO 26262不要求每个FSR至少定义一个TSR-它只要求TSR应按照FSR进行规定。根据之前活动中确定的FSR，我们得出以下TSR：

TSR1-1.1:MAS应依靠可靠的传感器来识别车速，并在车辆以高于/低于50 km/h的速度行驶时激活/停用MAS。

TSR1-1.2:MAS应依赖于可靠的技术（如传感器、激光雷达、雷达），以便预测所需的动机。

TSR1-1.3:MAS应取决于可靠的技术（例如，头部姿势和运动、手和脚的位置和运动），以便预测预期和/或有动机的动作。

TSR1-1.4:MAS应能够在适当的时间内验证是否需要驾驶员的操作操作。

TSR1-1.5:MAS应能在适当时间内验证驾驶员的战术机动是否符合要求和/或动机。

TSR1-1.6:MAS不得阻止所需的操作操作。

TSR1-1.7:MAS不得阻止期望的和/或有动机的战术演习。

TSR1-2.1:MAS应依赖于可靠的技术，允许识别不必要的操作动作。

TSR1-2.2:MAS应依赖于可靠的技术，该技术允许识别非期望和/或无动机的战术机动。

TSR1-2.3:MAS应防止不必要的操作操作。

TSR1-2.4:MAS应防止意外和/或无动机的战术机动。

5.硬件安全要求（HWSR）规范。

在确定TSR列表后，可分配给该项目物理硬件的TSR用于推导HWSR的规范。根据之前活动中确定的TSR，考虑标准对于HWSR的要求，我们得出以下HWSR：

HWSR-001：MAS的每个硬件组件（如传感器、执行器、雷达等）应通过其硬件安全要求和安全机制的相关属性来描述，以控制内部故障。

HWSR-002：MAS的每个硬件组件/与之相关的硬件组件应通过其硬件安全要求和安全机制的相关属性来描述，以控制或容忍元件外部的故障。

HWSR-003：MAS的每个硬件组件/与MAS相关的硬件组件应通过其硬件安全要求和安全机制的相关属性进行描述，以符合其他元件的安全要求。

HWSR-004：MAS的每个硬件组件/与MAS相关的硬件组件应能够处理其输入上的任何干扰/噪声。

HWSR-005：MAS的每个硬件组件/与MAS相关的硬件组件的输出不允许出现任何意外信号。

HWSR-006：MAS的每个硬件组件/与MAS相关的硬件组件应通过其硬件安全要求和安全机制的相关属性进行描述，以检测和发出内部或外部故障信号。

HWSR-007：应识别MAS硬件组件之间或与MAS相关的硬件组件之间的任何通信错误/丢失。

HWSR-008：应通过诊断其输入/输出信号来识别由于错误、故障或故障可能导致的MAS的每个硬件组件/与之相关的任何异常行为。

HWSR-009：MAS的每个硬件组件/与MAS相关的硬件组件应在符合其可能运行的真实环境的环境中进行测试。

HWSR-010：MAS硬件组件之间的通信和依赖关系应在符合其可能运行的真实环境的环境中进行测试。

6.软件安全要求（SWSR）规范。

在确定TSR列表后，可分配给项目软件功能的TSR用于推导SWSR规范。根据之前活动中确定的TSR，同时考虑标准中SWSR的要求，我们得出以下SWSR：

SWSR-001:MAS应能够检测并适当传达从其相关组件（如传感器、致动器、雷达等）接收到的信号中的任何错误。

SWSR-002:MAS应能够检测从其相关组件接收到的信号中的任何延迟、丢失和损坏。

SWSR-003:MAS应能够检测其任何相关组件是否没有响应和/或在适当的时间内没有响应。

SWSR-004:MAS应实施缓解计划，以适当处理从其相关组件接收到的信号中的任何错误、延迟、丢失和损坏。

SWSR-005:MAS应能够检测可能导致故障的相关组件中的错误、故障和故障。

SWSR-006:MAS应实施缓解计划，以适当处理其相关组件中的错误、故障和故障，以避免潜在故障。

SWSR-007:MAS应为每个错误、故障、故障等指定一个特殊代码，以便于识别和区分。

SWSR-008:MAS安全相关软件功能和与及时响应相关的属性应在符合其可能运行的真实环境的环境中进行测试。

SWSR-009:MAS安全相关软件功能和属性（例如，对错误输入的鲁棒性、软件的容错能力等）应在符合其可能运行的相同真实环境的环境中进行测试。

7.安全验证。

该活动的主要目的是确保安全目标充分且已在检查和测试的基础上实现，并提供可靠证据，证明已在车辆层面实现了确定的安全目标。这种验证只能在拟议系统的完整实现上进行，这超出了本文的范围。在我们的方法中，我们通过手动查看衍生的HWSR、SWSRs和SCSRs列表来验证结果，如果适当实现，这些列表可以满足TSR-反过来，完成整套TSR被认为足以确保该项目符合其功能安全概念。

5 结论

我们讨论了一种基于ISO 26262标准的整体方法。我们根据其主要活动描述了该方法，并通过将其应用于汽车领域的一个示例来说明这一方法。

未来，基于车辆系统的有限性，会有越来越多的系统按照这一方法规范化、标准化，这也将给汽车功能安全工作带来莫大的支持。