功能安全的开发始于概念阶段，对应 ISO 26262 标准的 Part 3，概念阶段的主要工作包括：(1)相关项定义，(2)通过执行危害分析和风险评估(HARA)来评估该项目的潜在风险，(3)确定每个危害事件的ASIL，(4)将高级别的功能安全要求定义为安全目标，(5)推导出功能安全概念(FSC)，该概念涵盖了所有相关的安全措施，以实现相关项定义的功能安全。下文将描述每一种方式，并将详细地讨论相关步骤。

01相关项定义

该活动包括相关项的定义、所需的功能、预期的行为、与车辆其他项目/系统的交互以及与车辆外部环境的交互。ISO 26262旨在成为汽车专用功能安全标准，它应能用于汽车的任何一种E/E系统。如果超出具体项目的范围，情况会略有不同。例如，如果我们比较高压电池系统等混合动力传动系统部件与高速公路辅助系统（MWA）的自动驾驶系统，则可得知机动车道辅助系统包含更复杂和网络化的功能，必须与外部项目(如其他车辆)和环境系统(如交通标志)协调，并进一步与与车辆基本平台功能相关的车辆内部功能协调。

在概念阶段，功能抽象对系统有一个抽象的看法。功能安全涉及项目的意外行为。在该阶段应进行安全分析，以确定项目的潜在危害(如HAZOP或概念FMEA)，然后再进行风险评估。

以下为在 HARA 期间的具体步骤，包括有关 ADS 功能的 HARA 分析，该部分为进一步扩展的建议，以粗体字表示。

Step 1：阐述危害事件

-驾驶场景(如在十字路口)

-基础设施(如汽车与环境之间的通信)

-环境条件(如天气)

-车辆的运行模式(如加速)

-涉及的交通参与者(如行人)

-驾驶员在场（例如，驾驶员在环/不在环）

-从故障角度

-到故障行为

-到危害

-综合考虑驾驶情况和危害因素

-在面临风险时，对特定交通参与者群体造成伤害的潜在原因

Step 2：危害事件的分类

驾驶员在场和可控性分类。在HARA期间，危害事件按风险参数可分为严重度(S)、暴露度(E)和可控度(C)。参数C表示驾驶员或其他潜在风险人员对危害事件可控性的估计。可控度等级为C0～C3，其中C0为 "一般可控"，C3为 "难以控制或不可控"。在自动驾驶功能风险评估中，参数取决于驾驶员在具体驾驶情况下的作用，这也是为什么应该在潜在的危害事件中确定 ASIL 的原因。对于 ADAS 和部分自动化功能，驾驶员必须始终能够在规定的反应时间内接管车辆的控制权。关于功能，对于高度或完全自动化的功能，不要求驾驶员监控驾驶情况。因此，驾驶员不可能考虑到车辆的任何形式的可控度。这就产生了C3分类，C3分类指出现ASIL C/D 这种最坏情况。

接下来的步骤涉及 ASIL 的评级和安全目标的定义：

Step 3：根据风险参数得出 ASIL

Step 4：制定安全目标

定义安全目标属性。安全目标是最高级别的安全要求。我们要避免发生任何潜在危害事件的不合理风险（如 "不会发生非预期的加速"）。安全目标不是用技术方案来表达，而是用功能目标来表达。如果安全目标可以通过过渡到一个或多个安全状态或维持一个或多个安全状态来实现，则应规定相应的安全状态。关于安全目标的相关参数有：安全状态、故障容忍时间间隔(FTTI)、诊断测试时间间隔(DTI)、故障反应时间(FRT)和安全容忍时间(STT)。这些参数用于在可能的危害发生之前保持车辆的安全(见图5)。

如果 FRT 需要由系统或驾驶员处理关键驾驶情况以维持规定的安全状态，则这些参数的定义非常重要（例如，ADS 功能级别2将安全状态定义为“驾驶员接管控制”）。

图5：FRT 和 FTTI

明确安全状态的其他影响因素。安全状态的定义必须考虑驾驶情况的复杂性。ISO 26262中关于安全状态的另一个重要要求是 "8.4.2.4 如果在可接受的时间间隔内不能通过过渡达到安全状态，应规定紧急操作"。

在这一要求的基础上，必须考虑的其他制约因素有：

表2列出了不同影响因素的概况。

功能安全概念（FSC）为了实现安全目标，定义功能安全要求及相关信息，并将要求分配到架构要素上，以及定义要素之间的必要交互。

FSC 必须解决以下方面问题：

下面将详细讨论最后三个方面：

容错机制是指故障不会直接导致违反安全目标。无论是否出现任何类型的退化，该机制都能将功能维持在安全状态。

故障检测和驾驶员警告很重要，可以将风险暴露时间缩短到可接受的区间（如发动机故障指示灯、ABS故障警告灯）。

仲裁逻辑需要从不同功能同时产生的多个请求中选择最合适的控制请求，对于自动驾驶系统的交互功能尤为重要。

但是，并非所有的这些方面都始终与每个系统相关。有些系统不提供任何容错，有些系统不需要任何仲裁逻辑。有关错误检测、驾驶员警告和过渡到安全状态的相关安全措施是该阶段必须考虑的重要问题。

—不同自动驾驶系统级别的FSC实例

根据自动化的类型和程度，有几种不同的策略可以确保在相关系统出现故障的情况下仍能安全运行。图6佐证了此观点。根据图6可以看出，错误发生后展开了三个潜在事件序列。按照从上到下的原则，这些事件可以描述如下：

图6：过渡到安全状态的不同概念

对于辅助或部分自动功能，无法再相信其能发挥全部功能。因此，系统会提醒驾驶员（重新）控制车辆。在交接过程中和交接后，可通过完全停用该功能来防止部分自动功能处于不安全工作状态。

例子：由于检测到错误，系统停用巡航控制。巡航控制由于检测到错误而被停用。系统通知驾驶员并控制车辆的纵向运动。

高度或完全自动化的功能确定，由于检测到错误，驾驶员需要接管车辆。系统告知驾驶员系统需要移交车辆控制权。由于预计交接时间相对较长，自动功能需要继续完全或基本完全运行一段时间。

注意：移交控制权意味着当自动功能仍在完全或基本完全运行时，系统才开始交接。

例子：自动驾驶系统检测到一个错误，该错误表明一个额外的(后续)故障可能会导致不安全的系统行为。系统告知驾驶员去控制车辆。

完全自动化的功能，如果驾驶员不可能接管控制，系统则决定在规定的时间间隔内停止车辆，以避免发生危险。与前一种情况一样，这意味着，当自动功能仍然完全或基本完全运行时，就开始交接。

例子：自动驾驶系统检测到一个错误，表明有一个其他的（后续的）故障可能会导致不安全的系统行为，因此自动功能会在几分钟或可能在几秒钟内将车辆安全停下。

对于上述第二种和第三种情况，可查阅图6结尾部分的内容。我们可以看出，在错误发生后的几秒钟内，自动功能需要完全或基本完全运行。如果没有驾驶员来接管，则该功能必须保持运行，尽管完全控制的程度会降低，但过程要持续数分钟。因此，这种高度或完全自动化功能的实现需要具有容错性，那就是即使在系统发生故障时，也可以实现全部或降级的功能。

—驾驶员在FSC中的重要作用

ISO 26262规定了有关错误检测、驾驶员警告和驾驶员反应的要求。对于今天的汽车E/E系统来说，可以说，驾驶员的作用是以一种合作的方式被覆盖。驾驶员必须能够在每次行驶中控制车辆（在欧洲，可参见《维也纳公约》）。与此相反，自动车辆如何以标准化的方式运行，以及如何以标准化的方式处理安全关键方面的问题，都没有明确规定。

因此，驾驶员需要熟悉不同的具体自动驾驶系统，因为车辆不同，车辆表现运行可能也不同。针对具体的自动驾驶系统功能，需要对驾驶员进行培训，确保驾驶员在规定的反应时间内能做出正确的反应。

这里还必须考虑到另外一个问题，那就是 "习惯效应"，即ADAS和自动驾驶系统功能的引入会改变驾驶体验，对驾驶员的技能要求不同。在HARA中，可控性的参数C可能会变为'不可控'。在不久的将来，驾驶员可能会因为缺乏经验而无法在规定的反应时间内处理没有辅助系统的危急车辆情况。那就可能要执行自动驾驶系统的特殊驾驶执照的规定。但是，车主大概率不会接受这种情况，因此，客户习惯问题会成为引进这种系统的最大障碍。

目前，我们并没有对驾驶员进行培训，使其能够应对制动系统完全失效或转向能力完全丧失的情况。因为没有培训驾驶员，因此，当前的制动系统和转向系统都是非常安全可靠的，所以驾驶员根本不需要担心这样的问题。另一种解决方案是让未来的自动驾驶系统变得非常安全可靠，让驾驶员在任何时候都能完全依赖它们。

未完更新中，敬请期待！