下载掌阅APP，畅读海量书库
立即打开
2.8节提到功能安全中安全需求的追溯链，该追溯链简要提到通过HARA活动来得到SG需求。SG需求作为顶层的安全需求，是主机厂在概念阶段的工作成果之一。要想获得SG需求，需要分析人员具备一定的整车系统架构知识及车辆动力学知识，从整车层级视角审视相关项的风险问题。
如果你所在的组织是汽车零部件供应商，那么你可能会经常听到HARA这一术语，但很可能没有实际操作过，因为这部分活动不在零部件供应商的责任范围内。如果你所在的组织是主机厂，那么你可能会接触并参与部分分析活动，但你的组织是否认真、完整地做过HARA，这可能要打个问号。
不管你所在的组织在供应链中是什么角色，如果你想了解如何通过这项活动来实现安全目标，那么请跟随本章的内容来看一看如何实施HARA活动，以及如何从HARA活动的成果中进一步分解得到FSR，然后FSR又是如何分配到相关项层面的系统要素，进而得到相关项层面的安全设计，从而得到FSC的。
在讲解HARA活动之前，我们有必要了解其涉及的一些基本概念以及分析所需的输入信息。
Q：HARA是什么？HARA活动的目的是什么？
下面摘取了标准对HARA的定义。
标准原文hazard analysis and risk assessment:method to identify and categorize hazardous events of items and to specify safety goals and ASILs related to the prevention or mitigation of the associated hazards in order to avoid unreasonable risk.
（参考ISO 26262-1:2018，3.76）
标准提到的HARA活动的目的如下。
a）to identify and to classify the hazardous events caused by malfunctioning behaviour of the item；
b）to formulate the safety goals with their corresponding ASILs related to the prevention or mitigation of the hazardous events，in order to avoid unreasonable risk.
（参考ISO 26262-3:2018，6.1）
解读 从标准给出的定义可以看出，HARA的基本方法论是首先通过分析识别并整理出相关项的危害事件，再根据这些危害事件定义出SG及对应的ASIL等级。HARA活动的目的是明确相关项在功能安全方面需要达到或实现的目标。
Q：HARA活动的输入是什么？换句话说，实施HARA活动需要哪些信息？
标准对HARA活动的输入有如下描述。
标准原文This definition serves to provide sufficient information about the item to the persons who conduct the subsequent sub-phases:“Hazard analysis and risk assessment”（see Clause 6）and“Functional safety concept”（see Clause 7）.
（参考ISO 26262-3:2018，5.2）
The following information shall be available：
——item definition in accordance with 5.5.1.
The hazard analysis and risk assessment shall be based on the item definition .
（参考ISO 26262-3:2018，6.3.1）
从以上标准提到的信息中可以看到，HARA活动的输入都指向 相关项定义（Item Definition） 这一输出物。
那么问题来了，“相关项定义”是一份什么样的输出物呢？它需要具备哪些信息，以供开展HARA活动？
1.3.2节提到过“Item”（相关项）这个词条的概念，可以简单理解为要开发的对象及其所在的系统。比如，如果你要开发的是电动助力转向系统（Electric Power Steering，EPS），那么EPS就是对应的相关项。让我们先来学习标准对“相关项定义”的一些介绍和要求。
标准原文
a）to define and describe the item，its functionality，dependencies on，and interaction with，the driver，the environment and other items at the vehicle level；
b）to support an adequate understanding of the item so that the activities in subsequent phases can be performed.
（参考ISO 26262-3:2018，5.1）
解读 相关项定义需要明确描述该相关项在整车层级的功能，以及它与驾驶员、环境和其他相关项之间的交互、依赖关系。这是为了使分析人员充分理解该相关项的功能及其与整车其他相关项的交互、依赖关系，更高效地开展后续的活动，包括HARA和FSC分析。这也可以看出功能安全活动与基本设计密切相关，脱离产品本身功能来谈功能安全都是不切实际的。你不能期望功能安全工程师在对产品及其功能一无所知的情况下，做好分析并明确提出安全需求。
Q：相关项定义要包含哪些内容？或者说，怎么写相关项定义？
标准原文
The requirements of the item shall be made available，including：
a）legal requirements，national and international standards；
b）the functional behaviour at the vehicle level，including the operating modes or states；
c）the required quality，performance and availability of the functionality，if applicable；
d）constraints regarding the item such as functional dependencies，dependencies on other items，and the operating environment；
e）potential consequences of behavioural shortfalls including known failure modes and hazards，if any；
f）the capabilities of the actuators，or their assumed capabilities.
（参考ISO 26262-3:2018，5.4）
解读 从上述要求来看，要将相关项定义做好确实需要一些功夫。相关项定义不仅要清楚地讲解相关项在整车层面的功能，还要描述该相关项与整车其他相关项之间的交互、依赖关系。另外，要满足的法规和标准（国标和ISO）要求、功能限制、运行环境、识别出的功能不足导致的潜在后果也需要详细描述。相关项在整车层级的初始架构、架构中的构成要素及接口信息、运行模式等都应有所描述。
根据以上介绍，相关项定义的内容框架可参见图3-1。
图3-1 相关项定义的内容框架示例
下面是一个相关项定义简化示例。
以具有一个执行器的系统为示例，驾驶员通过仪表板上的开关来触发此执行器。执行器在车速为零时提供舒适功能，但在车速超过15km/h时被激活，并可能导致危害事件发生。
相关项的初步架构如下。
❑由一个专门的ECU（本示例中称之为“AC ECU”）读取仪表板开关的输入信息，该ECU通过一个专门的电源线为执行器供电。
❑搭载本相关项的车辆同时也配备了一个能提供车速信息的ECU（本示例中称之为“VS ECU”）。假定此ECU能按照ASIL C的要求提供车速是否超过15km/h的信息。
根据以上描述，该相关项的架构如图3-2所示。
图3-2 相关项的架构示例
将相关项定义输出之后，分析人员对产品有了基础认知。接下来，我们谈谈如何实施HARA活动。
从HARA的中文名称“危害分析及风险评估”可以看出，HARA活动由两部分组成：首先进行“危害分析”，然后进行“风险评估”。我将HARA活动归纳为以下几个步骤，简称“HARA四步法”，如图3-3所示。
第一步 危害分析： 根据相关项定义整理出相关项在整车层级的功能，分析功能异常可能导致的潜在危害。
第二步 场景识别： 从运行模式、运行场景和环境条件3个维度综合识别出可能导致危害事件的场景。
第三步 风险评估： 结合第一步得到的“潜在危害”及第二步识别到的“场景”，分析出危害事件，并根据严重度（S）、暴露率（E）、可控性（C）3个评价指标评估危害事件的影响等级。
第四步 分析整理： 根据第三步的评估结果收集，整理出SG、ASIL等级、安全状态。
图3-3 HARA四步法
接下来，我们按照“HARA四步法”来详细探讨每一步在项目实践中的具体应用。
标准原文
The hazards shall be determined systematically based on possible malfunctioning behaviour of the item.
（参考ISO 26262-3:2018，6.4.2.2）
Hazards caused by malfunctioning behaviour of the item shall be defined at the vehicle level.
（参考ISO 26262-3:2018，6.4.2.3）
Hazards resulting only from the item behaviour，in the absence of any item failure，are outside the scope of this document.
（参考ISO 26262-3:2018，6.4.2.1 Note 2）
解读 危害是指相关项在整车层级上的功能异常表现。在这个阶段，不需要关注功能异常的原因，而是应依据在整车层级上能观察到的条件或行为来定义危害。在做危害分析和风险评估时，不应考虑将要实施或已经在之前相关项中实施的安全机制。
Q：那么，如何识别出相关项在整车层级的危害呢？
标准提到的方法：FMEA approaches and HAZOP are suitable to support hazard identification at the item level. These can be supported by brainstorming，checklists，quality history，and field studies .
（参考ISO 26262-3:2018，6.4.2.2，NOTE 1）
FMEA将在后面的安全分析章节中详述。我们先来谈谈危害及可操作性分析（Hazard and Operability，HAZOP）。
1.什么是HAZOP
标准原文HAZOP is an explorative type of analysis where applicable guidewords are applied to each of the functions of an item to postulate malfunctioning behaviors. HAZOP facilitates a structured and systematic examination of the operation of the item within the vehicle. It may be used to identify and evaluate malfunctioning behaviors of an item that could lead to hazards that create the potential for harm to the occupants of the subject vehicle，to other vehicles and their occupants，or other persons at risk such as pedestrians，pedalcyclists in the vicinity of the subject vehicle or maintenance personnel.
（参考SAE J2980，4.1）
解读 简单来说，HAZOP是一种基于关键字/引导词的系统性、结构化的分析系统功能危害的方法。
2.如何实施HAZOP活动
首先至少得有相关项的基本功能列表及描述，通过对这些功能应用引导词来实施HAZOP活动。SAE J2980中用以下引导词举例说明如何开展HAZOP活动。
1.Loss of Function-function not provided when intended ⇒功能丧失
2.Function provided incorrectly when intended⇒功能不正确
a. Incorrect Function-More than intended⇒过大/大于/多于/晚于
b. Incorrect Function-Less than intended⇒过小/小于/少于/早于
c. Incorrect Function-Wrong direction⇒反向
3.Unintended Activation of Function-Function provided when not intended⇒功能非预期
4.Output Stuck at a Value-Failure of the function to update as intended⇒输出卡滞
解读 上述引导词用于帮助引出功能的故障模式。引导词本身具有泛指的含义。我们需根据功能的特性来识别对应的引导词是否适用。例如，引导词“More than”对应的功能异常有时可能是输出过大，有时可能是输出过晚，有时则不适用。这需要基于具体的功能特性进行拓展，要具体情况具体分析。
基于上述方法论，表3-1展示了转向辅助功能和刹车控制功能的HAZOP示例之失效模式。
表3-1 HAZOP示例之失效模式
以上转向辅助功能和刹车控制功能异常可能导致的整车层级的危害如表3-2所示。
表3-2 HAZOP示例之整车层级的危害
关于上述提到的整车层级的危害描述，如“非预期的车辆横向运动/非预期偏航”，这涉及车辆运动控制的一些概念。从整车动力学的角度来看，汽车的运动轨迹可以被图3-4中的运动坐标系完全包含。
根据图3-4中的整车运动坐标系，表3-3列出了可能导致车辆沿轴线运动或绕轴线运动的相关项故障。该表可在HARA活动期间用于将相关项的危害与整车层级的危害事件对应起来。
根据上述介绍，得出关于VCU挡位管理功能的HAZOP示例，如表3-4所示。
通过上述步骤分析得到相关项功能异常导致的整车层级的危害后，接下来进行场景识别。
图3-4 整车运动坐标系
表3-3 整车对应坐标系的相关项故障模式
表3-4 HAZOP示例之VCU挡位管理
（续）
注：N/A表示不适用。
场景识别是从运行模式、运行场景和环境条件3个维度综合识别可能导致危害事件的场景。
关于“运行模式”和“运行场景”，标准有以下要求。
标准原文
The operational situations and operating modes in which an item’s malfunctioning behaviour will result in a hazardous event shall be described；both when the vehicle is correctly used and when it is incorrectly used in a reasonably foreseeable way.
Operational situations describe conditions within which the item is assumed to behave in a safe manner.
（参考ISO 26262-3:2018，6.4.2.1）
解读 在识别相关项的运行模式和运行场景时，既要考虑车辆的正确使用情况，也要考虑合理且可预见的不正确使用情况。例如，踩刹车后点火是整车的启动流程；而点火之后挂到D挡但电子驻车（EPB）制动系统忘记释放，踩加速踏板试图驱动车辆，这属于比较常见的合理且可预见的不正确使用情况。此外，在场景识别这一步，所考虑的场景需具有合理性，即在你识别的场景下，假定相关项能够以安全的方式运行。例如，若你选择的场景是车水马龙的闹市区，而运行场景是车辆高速行驶并深踩油门，这种场景组合就不合理。
标准原文It shall be ensured that the chosen level of detail of the list of operational situations does not lead to an inappropriate lowering of the ASIL.
解读 这是在开展HARA活动过程中实际会遇到的问题，即场景（操作、交通）及环境条件是分得越细越好，还是怎样更好。其实，这没有标准答案，但至少要覆盖所有典型场景。场景越细，可能越利于描述危害事件造成的影响，也越利于评估严重度（S）和可控性（C），但由于还要和环境条件组合以最终选择合适的综合性场景，如果场景太细，可能得不出一个合理的危害事件，因为组合后的场景暴露率（E）太低，导致对应的ASIL等级也被无形地降低了。
在实际场景识别过程中，大家常常思考如何建立并丰富场景库的问题。例如，自动驾驶面临的一些场景难以完全列举，需要通过仿真测试和长期的路测来累积场景数据，从而不断丰富驾驶数据库。表3-5列举了基于VDA 702的一些典型场景，读者可以在此基础上结合各地区的具体情况来扩充自己的场景库。
表3-5 基于VDA 702的典型场景
（续）
表3-6展示了VCU在HARA活动过程中的场景识别示例，其形式供参考。
表3-6 HARA活动过程中的场景识别示例
在风险评估过程中，假设相关项的故障行为将导致危害事件发生。同样地，在进行风险评估前，首先要弄清楚什么是风险，标准中是如何定义风险的。
风险评估流程可以参考图3-5。
如此，风险评估便转化为如下几个活动的组合。
图3-5 HARA活动中风险评估流程
3.3.3.1 确定严重度（S）
评估危害事件对驾驶员、乘客、车辆周围人员或周边车辆中人员可能造成的潜在伤害，从而确定相应的严重度等级。
如果经过危害事件分析，确定相关项的故障行为只会造成物质损坏而不涉及对人员的伤害，则该危害事件的严重度等级可为S0。如果一个危害事件的严重度等级为S0，则无须分配ASIL等级。（参考GB/T 34590-3:2022，6.4.3.4）
关于严重度等级的评估应注意以下几点。
❑严重度等级的评估可以基于对多个伤害的综合考量，但相比只考虑单一伤害的评估结果而言，这样可能会导致较高的严重度等级。
❑对被评估的场景，严重度等级评估需要考虑事件发生的合理顺序。
❑严重度等级的确定基于目标市场中具有代表性的个体样本。
Q：什么是“代表性”样本？
对于每一个危害事件，应基于确定的理由来评估潜在伤害的严重度，如表3-7所示。
表3-7 严重度等级评估
关于严重度等级中伤害程度的划分，标准参考的是简明损伤定级（Abbreviated Injury Scale，AIS）。AIS等级分为7个级别。
❑ AIS 0 ：无伤害。
❑ AIS 1 ：轻伤，例如皮肤表面伤口、肌肉疼痛、鞭打样损伤等。
❑ AIS 2 ：中度伤害，例如深度皮肉伤、脑震荡引起的长达15min无意识、单纯性长骨骨折、单纯性肋骨骨折等。
❑ AIS 3 ：严重但未危及生命的伤害，例如无脑损伤的颅骨骨折、没有脊髓损伤的第四颈椎以下脊柱错位、没有呼吸异常的多根肋骨骨折等。
❑ AIS 4 ：严重伤害（危及生命，有存活的可能），例如伴随或不伴随颅骨骨折的脑震荡引起的长达12h昏迷、呼吸异常。
❑ AIS 5 ：危险伤害（危及生命，存活不确定），例如伴随脊髓损伤的第四颈椎以下脊柱骨折、肠道撕裂、心脏撕裂、伴随颅内出血的超过12h昏迷等。
❑ AIS 6 ：极度危险或致命伤害，如伴随脊髓损伤的第三颈椎以上脊柱骨折、极度危险的体腔（胸腔和腹腔）开放性伤口等。
根据上述AIS等级描述，表3-8提供了一个严重度等级划分示例。
表3-8 严重度等级划分示例
尽管有了AIS等级描述作为参考，但对碰撞的实际严重度等级划分通常取决于多个因素，这些因素如下。
1）碰撞类型，例如平面碰撞（如正碰、后碰、侧碰）。
2）碰撞参与者之间或单车事故发生时的相对速度。
3）相关车辆的相对尺寸、高度和结构完整性（即碰撞兼容性）。
4）碰撞事故产生的冲击力下的车辆乘员和非乘员的健康和年龄。
5）车辆乘员是否使用安全保护设备（如安全带、儿童约束装置）。
6）快速紧急援助（急救队）的可用性和响应速度。
影响严重度等级划分的因素有很多，在实际操作分析中可以保守地按照最坏情况来划分，整体分析完成后再通过多人多维度的评审来确定最终的等级。
关于碰撞类型与严重度等级划分的原则可参考表3-9。
表3-9 碰撞类型与严重度等级划分的原则
3.3.3.2 确定暴露率（E）
标准中对暴露的定义是：一种处于特定运行场景的状态，在该运行场景中，如果发生HARA中所分析的失效模式，可能会导致危害。
解读 从“暴露”的概念可知，暴露率的评估是对运行场景出现频率的评估，因此，在评估时应聚焦于运行场景。
暴露率等级评估准则参见表3-10。
表3-10 暴露率等级评估准则
暴露率的确定需注意以下几点。
❑暴露率的确定基于目标市场中具有代表性的运行场景样本。
❑评估暴露率时，不应考虑装备该相关项的车辆数量。
❑暴露率的评估可以基于暴露出现的频率和持续时间两种方式展开。
Q：想想评估暴露率时为什么不应考虑车辆是否装配了要分析的相关项？
关于两种暴露率评估方式的选择，SAE J2980中有如下描述。
标准原文Exposure based on duration: An Exposure class is selected based on the duration of a vehicle operational situation for cases where the malfunctioning behavior directly causes the hazardous event.
Exposure based on frequency: An Exposure class is specified not only for vehicle operational situationsin which a considered malfunctioning behavior can directly cause the hazardous event（duration of the situation is relevant），but also for those situations where the situationor condition can initiate the hazardous event，as a result of a fault in the system that has already occurred at an earlier point of time and remained latent. Thus，the occurrence of such a situation will directly initiate the hazardous event because of its combination with the pre-existing fault regardless of its duration
解读 在评估暴露率时，选择基于暴露出现的频率还是基于持续时间要看导致危害的直接触发因素是功能故障还是场景。如果无论场景如何，只要功能故障发生就会直接导致危害，则应基于持续时间评估暴露率；如果功能故障已经发生，但需要结合特定场景才会导致危害，则应基于频率评估暴露率。简单来说，“先场景后故障”导致的危害基于持续时间评估，“先故障后场景”导致的危害基于频率评估。
根据以上描述，图3-6展示了一个选择暴露率评估方式的简化原则。
图3-6 选择暴露率评估方式的简化原则
标准中基于持续时间的暴露率评估示例如表3-11所示。
标准中基于频率的暴露率评估示例如表3-12所示。
在进行风险评估中的场景识别时，应考虑以下因素。
1）车辆的使用场景，包括高速行驶、城市驾驶、停车场。
2）环境条件，如路面摩擦、侧风等。
3）合理预见的驾驶员使用和误用。
4）操作系统之间的相互作用。
表3-11 基于持续时间的暴露率评估示例
表3-12 基于频率的暴露率评估示例
图3-7提供了一些典型的整车运行场景供分析参考，可在此基础上进行扩充。
图3-7 典型的整车运行场景
3.3.3.3 确定可控性（C）
对于每一个危害事件，应基于确定的理由评估驾驶员或其他潜在处于风险的人员对该危害事件的可控性，如表3-13所示。
表3-13 可控性等级评估
关于可控性评估，应注意以下几点。
❑可控性评估是对驾驶员或其他可能面临风险的人员能够有效控制危害事件以避免特定伤害的概率的评估。HARA分析过程中对于可控性的评估一般是假设驾驶员在正常条件下驾驶（例如：不疲劳），经过相关的驾驶培训（如持有驾照），并遵守所有适用的法律法规。
❑当危害事件与车辆方向、速度的控制无关时，例如肢体卡在运动部件中，可控性是对涉险人员能够自行脱离或被该危害场景中的其他人员救出的概率。当评估可控性时，要注意涉险人员可能不熟悉相关设备的运行。
❑当危害事件涉及多个交通参与者的行为时，可以基于带有故障相关项的车辆的可控性，以及其他参与者的可能行为进行可控性评估。
可控性是指评估交通参与者在面对危害事件时，控制或避免其导致伤害的可能性。这不仅涉及故障车辆及其司机，还涉及在危害事件发生时的交通参与者。
图3-8展示了车辆溜坡事件的可控性评估示例。由于车内没有驾驶员，因此车辆本身的可控性等级被评为C3。当坡下方人员距离坡较近时，这些人员对危害的可控性也很低，因此综合评估该危害事件的可控性等级为C3。
图3-8 车辆溜坡事件的可控性评估示例
标准中可控性评估示例可参考表3-14。
表3-14 可控性评估示例
3.3.3.4 确定ASIL等级
每个危害事件的ASIL等级应根据严重度（S）、暴露率（E）和可控性（C）这三个参数确定，如表3-15所示。
表3-15 ASIL等级确定
相关项的某一功能故障导致危害事件的ASIL等级可能会与既存系统的ASIL等级不一致，此时需要对比检查新旧系统的风险评估过程，如果存在不一致的地方，则需对分析进行更新迭代，这说明HARA也是一项动态的活动。
风险评估完成后，应整理对应的危害事件并确定其ASIL等级。根据危害事件整理出相应的安全目标，并将整理后的ASIL等级分配给对应的安全目标。
整理过程中需注意以下要求。
❑应为具有ASIL等级的每个危害事件确定一个安全目标，该ASIL等级从危害分析中得出。如果所确定的安全目标是类似的，可将其合并为一个安全目标。（参考GB/T 34590-3:2017，7.4.4.3）
❑应将为危害事件所确定的ASIL等级分配给对应的安全目标。如果将类似的安全目标合并为一个安全目标，应根据上一条将最高的ASIL等级分配给合并后的安全目标。（参考GB/T 34590-3:2017，7.4.4.4）
❑如果一个安全目标可以通过转移或保持一个或多个安全状态来实现，则应明确说明相应的安全状态。（参考GB/T 34590-3:2017，7.4.4.5）
另外，安全目标的描述也是一项有些讲究的工作，描述方式既可以是正向的，也可以是反向的，颗粒度可以是粗略的，也可以是细致的，只要能够清楚地描述在整车层级上要实现的安全目标即可。因此，安全目标的描述往往是在整车层级上的功能性和目的性的描述。
通过“HARA四步法”可以比较准确地分析出相关项在整车层级的安全目标，读者可以根据“HARA四步法”结合项目实例动手试试。
最后来看一个简化的VCU的HARA示例——提供驱动扭矩功能。示例中功能定义如表3-16所示。
表3-16 功能定义
FUNC_01（提供请求的驱动扭矩）的危害分析如表3-17所示。
表3-17 FUNC_01（提供请求的驱动扭矩）危害分析
以FUNC_01-1a非预期加速（未失稳）为例，对应的HARA如表3-18所示。
到这里，我们已经通过案例形式逐步介绍完HARA的步骤。相信大家对于HARA方法及其应用已经有了全面的认识。不过，方法是有了，但还需要加以实践才能对该方法论有深刻的理解。
ASIL B和ASIL D在功能安全架构和具体实现上会有些差异。ASIL D的架构独立指标比ASIL B的高出一个数量级，对于ASIL D的功能安全诊断和冗余更加密集，这是因为ASIL D的功能安全架构需要覆盖更多的功能故障（失效模式），以达到所需的诊断覆盖率。ASIL D的功能安全架构几乎需要使用处理器自带的安全机制，而ASIL B的功能安全架构可以基于系统层面的设计进行一定的裁剪。针对不同ASIL等级，ISO 26262没有给出指定的架构，只要能满足标准要求即可。如果想了解不同ASIL等级的架构设计上的差异，可以参考ISO 13849里针对不同性能等级（PL）的指定架构，或IEC 61508中关于 M oo N 的架构。
表3-18 FUNC_01-1a非预期加速（未失稳）对应的HARA示例
以上仅是两者差异的简化定性描述。接下来，我们看看ISO 26262标准对ASIL B和ASIL D等级在具体活动上的差异的描述。
1.ASIL B和ASIL D等级对应第2部分功能安全管理活动的差异
这两者在功能安全管理活动中的差异可参考表3-19。
表3-19 ASIL B与ASIL D等级对应第2部分功能安全管理活动的差异
针对相关工作成果的认可措施实施，ASIL D的独立性要求更高。对于ASIL B，认可措施需要由另一人实施，此人可以是工作成果所在团队的成员；而对于ASIL D，要求由另一个团队或组织的成员执行相关认可措施。针对软件工具的鉴定、功能安全的审核和评估，ASIL B是推荐实施，而ASIL D是要求实施，并且必须由另一个部门（或团队、组织）的成员完成。
2.ASIL B和ASIL D等级对应第7部分生产、运营、服务和报废活动的差异
由于第7部分基本符合质量管理的要求，适用统一的标准流程要求和组织自定义的售后服务流程，如IATF 16949、ISO 9001。因此，ASIL B和ASIL D在这一部分的活动没有特别的差异。
3.ASIL B和ASIL D对应第8部分支持过程活动的差异
两者在支持过程中的相关活动的差异见表3-20。
表3-20 ASIL B与ASIL D对应第8部分支持过程活动的差异
ASIL B和ASIL D相关的活动在支持过程的差异主要体现在需求的描述方式、工具鉴定方式及系统可靠性要求上。对于通用的支持活动，如变更管理、配置管理、文档化管理等，两者不存在差异。
4.ASIL B和ASIL D等级对应第9部分安全分析活动的差异
两者在安全分析中的相关活动的差异见表3-21。
表3-21 ASIL B与ASIL D对应第9部分安全分析活动的差异
在安全分析活动方面，ASIL B和ASIL D的差异主要体现在需要实施的安全分析类型上。ASIL B只需进行定性和归纳分析，而ASIL D则要求定量和演绎分析，以使整个系统的分析更加全面。
5.ASIL B与ASIL D在具体实施上的一些差异
两者相关活动在具体实施过程中的差异如表3-22所示。
表3-22 ASIL B与ASIL D在具体实施过程中的差异
以上就是ASIL B与ASIL D在对应部分安全活动上的差异，这些差异实际上源自标准，标准本身对此有定义。
综上所述，ASIL D相较于ASIL B在安全相关活动的流程、具体实现、定量和定性验证方面都有更为严格的要求，这是从标准角度上讲的。但这并不能代表有ASIL D工作经验的人员就一定比ASIL B项目的人员更胜一筹。正如本章开篇所述，不管是ASIL B还是ASIL D，能够有效实施的都值得肯定。项目中能够完美落地的安全措施才是组织及安全负责人能力最具说服力的证明。
前文详细介绍了“HARA四步法”，了解了相关项定义和HARA之间的关系，以及SG的导出及安全需求追溯链。
SG作为相关项顶层的安全需求，是相关项最终要达成的安全目标。要实现这些目标，就需要将顶层的安全需求逐级分解，直到分解出在零部件层级用于实施的需求。
了解完概念阶段的HARA，就如同开启了功能安全“万里长征”的旅程，接下来是安全需求的“万里长征”第一步——从SG到FSC。要迈出这一步，需要先了解概念阶段的另一个重要工作产出物——功能安全概念（Functional Safety Concept，FSC）。
本节将从FSR开始逐步了解FSC，具体内容如下。
❑什么是FSR。
❑如何获取FSR。
❑什么是FSC。
先从标准的术语定义及相关要求来认识FSR。关于FSR的定义及要求参考如下。
标准原文Functional Safety Requirement:specification of implementation-independent safety behaviour or implementation-independent safety measure including its safety-related attributes.
（参考ISO 26262-1:2018，3.6.9）
标准原文The functional safety requirements shall be derived from the safety goals，considering the system architectural design.
（参考ISO 26262-3:2018，7.4.2.1）
标准原文At least one functional safety requirement shall be derived from each safety goal.
（参考ISO 26262-3:2018，7.4.2.1）
解读 由FSR的定义可知，FSR定义了相关项在整车层级的安全行为和安全措施。根据上方标准要求，FSR由SG分解而来，这个分解需要考虑系统架构中要素之间的交互关系。SG属于相关项系统顶层的安全需求，是站在整车的角度对相关项提出“要怎样/不要怎样”的需求，非常抽象，因此需要基于SG进行分解细化，导出相关项层级相对具体的需求。由于SG层级依然要考虑整车电子电气系统架构，所以这个层级的需求仍是偏功能性的描述。
例如，VCU的一个安全目标是“SG01_防止车辆非预期加速”。基于VCU的相关项定义及初始架构信息，可以分解出此目标下的功能安全需求之一：“VCU需对驱动扭矩进行监控”。这意味着需要描述实现该目标的初始功能要求。
另外，FSR要从安全目标中导出并分配给相关项系统层面的架构要素。SG与FSR的层级关系可参考图3-9。
图3-9 SG与FSR的层级关系
需求分解及编写过程中，各位必然会遇到两个老生常谈的问题——颗粒度和完整性。说一千道一万，大家还是会疑惑FSR写到什么程度才算合适，具体可参考2.8节的内容。
对于那些非常成熟且量产多年的产品，专注于该产品多年的系统工程师可能确实拥有一套非常完整的产品需求规范，这是长期积累和完善的结果。但安全相关的需求不一定是完善的，安全相关的需求也不建议直接从安全目标导出，因为编写安全需求需要基于相应的分析，分析又要与架构对应，这是一个逐步细化、循序渐进的过程。如果没有“一步到位”的能力，那么还是要一步一个脚印地逐层分解。
因此，在导出安全需求时，安全分析这一过程是不可或缺的。不仅如此，我们还必须非常细致地执行这一活动，尽管烦琐，但绝不能简化任何细节。
从SG到直接导出详细的设计需求流程是不合规的。需求分析本身需要对设计进行验证，并产生相应的过程输出物作为证据。直接从安全目标跳到细化的可用于设计实现的安全需求，相当于省略了这些中间过程，缺乏过程证据，这将导致功能安全相关的审核难以顺利通过。
Q：那么，FSR该从哪些方面入手？或者说，FSR应包含哪些内容呢？
关于如何从SG导出FSR，先来回顾标准对FSR的内容框架提出了哪些要求，这可以作为FSR导出的一个参考。
标准对FSR内容框架有以下要求。
1）如适用，功能安全要求（FSR）应为以下内容定义策略。
a）故障避免。
b）故障探测和对故障导致的功能异常表现的控制。
c）如果适用，从一个安全状态转换到另一个安全状态。
d）故障容错。
e）故障情况下的功能降级及其与f或g要求的交互。
f）缩短风险暴露时间。
g）增加驾驶员可控性所需的警告（例如发动机功能异常指示灯、ABS故障报警灯）。
h）满足整车层级的时间要求，即定义故障处理时间间隔，以满足故障容错要求。
i）避免或减轻对不同功能的多个控制请求进行不当仲裁而导致的危害事件。
2）如适用，应考虑以下内容来定义每项功能安全要求。
a）运行模式。
b）故障容错时间间隔。
c）安全状态。
d）紧急运行时间间隔。
e）功能冗余（例如故障容错）。
（参见ISO 26262-3:2018，7.4.2.3）
从上述标准的要求来看，FSR要包含的内容还不少，但所有的安全要求都可以从事前、事中、事后3个方面去考虑，FSR也不例外。
概括来说，FSR中需要定义的安全要求如下。
1）预防型要求（事前）： 从预期功能的意图出发，为尽可能避免系统性和硬件相关的失效，系统中的各组成要素应该具备或实现哪些功能，例如应避免扭矩突变。
2）探测型要求（事中/事后）： 如果系统发生失效，系统需及时探测、控制并提示故障，及时向驾驶员发出警示，让驾驶员进行干预，或将车辆系统控制至安全状态，以防危害事件的发生。
除了内容框架方面的要求外，标准对FSR还提了以下要求。
1）每个SG至少分配一个FSR，同一个FSR可以对应多个SG，并且继承最高的ASIL等级。
2）如果在这个阶段存在ASIL分解，则需满足ISO 26262-9:2018第5章中关于独立性的要求。
3）对于探测型的FSR，需要定义相应的安全状态和FTTI。如果在可接受的时间内不能过渡到安全状态，应该定义紧急运行及紧急运行时间间隔（EOTTI）。
4）FSR需要分配到系统架构中相应的组成要素，作为FSC的一部分。
解读 上面提到的FSR的内容框架看似复杂，其实FSR本质上是需求。通常由主机厂从整车角度对相关项提出安全要求，围绕安全目标探讨系统层面如何满足这些要求。这些安全要求更偏向功能性描述，此阶段不需要考虑具体实现的问题，但强调安全功能的闭环，如“VCU应正确获取加速踏板行程”。至于如何正确获取或使用何种方式获取，可以在零部件层级进行分析导出。
Q：说了这么多，FSR到底该如何导出？有没有什么可操作的方法？
2.8.3节已谈到如何编写需求，安全需求的导出需要经过安全分析，就像最初通过HARA方法得到SG一样，从SG到FSR也需要经过一番安全分析。
标准关于FSR的导出提到以下一条备注。
NOTE This activity can be supported by safety analyses（e.g. FMEA，FTA，HAZOP）in order to develop a complete set of effective functional safety requirements.
（参考ISO 26262-3:2018，7.4.2.4）
解读 FSR的导出可以通过安全分析方法（例如FMEA、FTA或HAZOP）实现。FMEA和FTA是ISO 26262以及其他可靠性相关标准推荐的分析方法。其中，FMEA（Failure Mode and Effects Analysis，失效模式与影响分析）和FTA（Fault Tree Analysis，故障树分析）是功能安全开发中最常用的两种安全分析方法。
❑ FMEA： 典型的归纳分析法，用于定性分析，所有ASIL等级的功能都推荐实施。这是一种自下而上，从原因到结果的分析方法，即从潜在的故障原因出发，分析可能的危害结果，专注于单一故障因素。
❑ FTA： 典型的演绎分析方法，可用于定性和定量分析，推荐在ASIL C及以上的功能中实施，是一种自上而下，从结果到原因的分析方法，即从危害结果或事件，分析可能导致其产生的原因。
这两种方法具有一定的互补性，在需求分解的过程中采用哪种方法没有绝对的答案，具体取决于组织的开发流程定义及其成熟度。如果可能，建议同时实施这两种方法。
对于从SG到FSR导出，FTA方法可能会比较合适，因为SG是顶层的安全要求，而FTA是从顶层事件出发逐层导出故障原因。流程和分析逻辑上与从SG到FSR比较契合。
这两种分析方法将在第10章至第13章系统地分享给大家。
2.8.5节提到过FSC包含FSR，而且还定义了不同FSR的交互关系、需求的一些描述性信息以及FSR如何分配到架构要素，即FSC把FSR和架构的关系进行了对应。
标准对于FSC的总体要求如下。
To comply with the safety goals，the functional safety concept contains safety measures，including the safety mechanisms，to be implemented in the item’s architectural elements and specified in the functional safety requirements.
（参考ISO 26262-3:2018，7.2）
解读 简单来说，FSC包含了FSR及其分配到架构要素中的信息，涉及初始的安全架构设计，还包括FSR与SG的追溯信息，同时定义了从FSR识别出的安全措施，以及对交通参与者和与相关项目有信息交互的其他系统设计的要求。所有这些信息构成了FSR在相关项系统层级如何实现安全目标（SG）的解决方案。
Q：上述要求提到的安全措施，与安全机制有何区别？
根据上方的提示，FSC内容框架可以概括性地表示如图3-10所示。
图3-10 FSC内容框架
关于FTTI（故障容错时间间隔），可以通过仿真计算、实际测试等方式得到。实际操作过程中，如果计算不具备可操作性，可以先按照最坏情况预估一个值，然后对典型的危害事件模拟危害场景进行试车测试，根据测试结果与预先定义的确认准则来判断预估的FTTI值是否合理，最终以实测数据进行适当调整。
关于安全状态，在1.3.2节中提到，安全状态是一种运行模式，是在失效发生后的一种安全运行模式。对于定义安全状态，需根据相关项的具体功能特性、潜在危害及系统的运行模式来确定。安全状态可以是在发生失效时于规定时间内进入的关闭、锁定、车辆静止并保持或功能降级等运行模式。
将FSR分配到架构是架构设计中的一个关键步骤。需求是对功能的细化，功能需要通过架构中的各个组成要素来实现。因此，分配过程实际上是对设计本身的验证，因为你需要明确哪些模块承载哪些需求，从而实现相应的功能，这也是实现双向可追溯的过程之一。如果将需求分配给了错误或不合适的模块，最终在下游的功能实现中必然会出现问题。
至于FSC应该以什么文档形式呈现，标准没有特别要求。无论是用Excel还是Word，只要能满足标准对输出物的要求，用什么形式输出由组织自行决定。
本章从HARA方法谈起，详细描述如何通过HARA方法得到安全目标，然后谈到如何从SG得到FSR。概念阶段是功能安全需求追溯链的起点，包括SG和FSR，两者是需求上下游的关系，最终都要体现在FSC中。