本文要点
在上文EPB功能安全笔记(5)：EPB系统软件接口定义中基于EPB系统初步的系统框架，在框架中定义的各个模块的功能基础上，细化了各个模块间的信号接口，得到一个更加具体的EPB系统架构。
定义接口后的EPB系统架构
另一方面，开发的本质实际上是实现需求。对于EPB系统功能安全开发而言，如何将Safety Goal转化成EPB系统架构中要素的的安全要求，是EPB系统功能安全开发的核心之一。对应到ISO 26262中，这一工作包括了功能安全概念开发（Functional Safety Concept Development）和技术安全概念开发（Technical Safety Concept Development）。
在实际的功能安全开发过程中，功能安全概念和技术安全概念有着很强的因果关系，联系非常紧密，甚至有些公司习惯性地将其合称为“Safety Concept Development”。不过，对于刚接触功能安全的朋友来说， ISO 26262将对功能安全概念和技术安全概念的说明分别放在了part3和part4中，容易导致读者先入为主地对两者进行了概念上的分割；于此同时，ISO 26262对这两部分的说明中密集地充斥着贯穿ISO 26262始终的关键概念，造成了一定程度上的理解障碍。
鉴于此，笔者在对EPB系统的安全概念开发进行举例说明前，插入这篇侧重于理论说明的总结，旨在强调功能安全概念和技术安全概念的要点，希望能给读者提供一些参考。
1.概念辨析
在ISO 26262的part3和part4中，反复提到了以下几个关键的专有名词：
- 安全目标（Safety Goal）
- 功能安全概念（Functional Safety Concept）
- 功能安全要求（Functional Safety Requirement）
- 技术安全概念（Technical Safety Concept）
- 技术安全要求（Technical Safety Requirement）
当独立地看各个概念的定义时，理解起来没有什么难度；但是当这些概念同时出现时，却有些分不清彼此。接下来对这些概念进行对比和辨析。
1.1.安全目标与功能安全要求
安全目标是怎么得到的呢？前文提到，通过对整车进行危害分析和风险评估，识别出需要防止、减轻或控制的危害和危害事件，为每个危害事件制定安全目标，并将汽车安全完整性等级(ASIL)与每个安全目标关联。比如：
整车应避免非预期减速， ASIL C
而当所研究的对象（即相关项）有造成某条安全目标所对应的危害事件的可能时，相关项就需要考虑这一条安全目标。如EPB系统有导致整车非预期减速的接口时，EPB就继承了这一条安全目标：
EPB应避免非预期减速， ASIL C
这样一来，安全目标变成了EPB系统最高层级的功能安全要求。
反过来，ISO 26262, part3, 8.4中对功能安全要求的定义又指出：
如果适用,应考虑以下几点来定义每项功能安全要求:
a)运行模式;
b)故障容错时间间隔;
c)安全状态;
d)紧急运行时间间隔;及
e)功能冗余(例如故障容错)。
也就是说，功能安全要求除了ASIL等级以外，还包含部分或者全部a) - e)的属性。既然安全目标是最高层级的功能安全要求，那么安全目标必然也还包含部分或者全部a) - e)的属性。
总结：
- 安全目标是相关项最高层级的功能安全需求。
- 安全目标和功能安全需求一样，包含ASIL等级、FTTI、safe state等属性。
1.2.功能安全要求与技术安全要求
通过上一节的说明读者可以发现，安全目标和功能安全要求的口吻像是甲方，“我需要功能实现XX”，从这个角度，技术安全要求就是那个要满足甲方需求的乙方，需要回答“功能应该怎么做实现XX”。
ISO 26262, part3中说明功能安全要求的导出时提到：
功能安全要求应由安全目标和安全状态导出，并考虑初步架构设想。
功能安全要求应分配给初步架构设想中的要素。
而在ISO 26262, part4中提到：
技术安全要求应根据功能安全概念、相关项的初步架构设想和如下系统特性来定义:
a) 外部接口，如通讯和用户接口，如果适用；
b) 限制条件，例如环境条件或者功能限制；
c) 系统配置要求。
想必这已经很好理解，身为“甲方”的功能安全要求只需要根据大致的架构便可确定“我需要功能实现XX”；而身为“乙方”的技术安全要求则必须知道明确的细化的系统架构，才能够回答“功能应该怎么做实现XX”。
另一方面，技术安全要求如何实现功能安全要求呢？关键是定义必要的安全机制（safety mechanism）。
安全机制是ISO 26262中另一个非常重要的概念，其定义为：
为了达到或保持某种安全状态，由电子电气系统的功能或要素或其他技术来实施的技术解决方案，以探测故障、控制失效。
简而言之，安全机制即为实现安全所定义的措施。这些措施包括但不限于：
a)与系统自身故障相关的探测、指示和控制措施；
注1: 包括系统或者要素的自身监控，用于探测随机硬件故障，以及，如果适用，探测系统性失效。
注2：包括对通讯通道(例如:数据接口、通讯总线、无线射频链接)失效模式的探测和控制的措施。
b)涉及探测、指示和控制与本系统有相互影响的外部设备中所发生故障的措施；
示例: 外部设备包括其他的电控单元、电源或者通讯设备。
c)使系统实现或者维持在安全状态下的措施；
注3：包括在安全机制冲突时的优先和仲裁逻辑。
d)细化和执行报警和降级概念的措施；
e)防止故障潜伏的措施。
关于如何定义安全机制，2018版的ISO 26262对此进行了更新，个人认为更加准确和更加便于理解了。因此在这里附上2018版的英文说明。
For each safety mechanism that enables an item to achieve or maintain a safe state, the following shall be specified:
a) the transition between states;
NOTE 1 This includes the requirements to control the actuators.
b) the fault handling time interval with respect to the timing requirements apportioned from the appropriate architectural level; and
NOTE 2 This sub-requirement aims to achieve a consistent timing within the boundary of the fault handling time interval) FTTI which is specified for each Safety Goal.
c) the emergency operation tolerance time interval, see ISO 26262-1:2018, 3.45, if the safe state of the item cannot be reached within the FTTI.
NOTE 3 In-vehicle testing and experimentation can be used to determine the emergency operation tolerance time interval.
EXAMPLE 1 Duration of the degraded operation prior to the safe state.
EXAMPLE 2 A safety mechanism for a brake-by-wire application, which depends on the power supply, can include the specification of a secondary power supply or storage device (capacity, time to activate and operate, etc.).
总结：
- 安全目标和功能安全要求均不表述为技术解决方案，而表述为功能目的。
而技术安全要求侧重于解释“如何做”。
- 技术安全要求通过定义具体的安全机制来实现“如何做”。
1.3.功能安全概念与技术安全概念
个人认为实际上功能安全概念和技术安全概念都可以用一句话概括：
- 功能安全概念：为了实现功能安全目标，把功能安全要求分配给相关项中的初步架构要素或外部措施的一切活动的总和。
- 技术安全概念：为满足功能安全要求而设计系统架构和技术安全要求的一切活动的总和。
基于此，我们可以说，定义功能（技术）安全要求的过程就是在进行功能（技术）安全概念开发的过程，一些公司习惯性地合称为“安全概念开发，Safety Concept Development”。
按照这个解释，Safety Concept Development看起来是在定义可落地的系统方案和要求，与术语中给人空中楼阁之感的“Concept”一词有点违和。但是，如果鸟瞰整个功能安全开发，Safety Concept Development是属于系统层的开发，输出为对系统最底层的要素——软件和硬件的要求，而在完成了Safety Concept Development之后，只有当最底层的要素满足了功能安全要求时，才可以说产品满足了功能安全。从这个角度看，这里的“Concept”一词还是挺准确的。
功能安全开发鸟瞰
2.从安全概念开发看主机厂和供应商的合作
主机厂和供应商的合作关系即为甲方和乙方的关系。主机厂的主要职责之一是定义整车系统E/E架构，并基于E/E架构对各个ECU的供应商提出要求，包括功能安全要求。而各个ECU对主机厂来说是黑盒，原则上主机厂只需要关心ECU的输出，而不需要去了解ECU的具体的系统架构；供应商也不会对主机厂开放。
某主机厂某款车型的整车E/E架构图，1为ESP
从这个角度讲，主机厂是在整车层做功能安全概念开发（Functional Safety Concept Development），递交给供应商的要求为功能安全要求（Functional Safety Requirement）。供应商拿到功能安全要求后，会基于ECU具体的系统架构对系统中的软件和硬件分配技术安全要求（Technical Safety Requirement），完成技术安全概念开发（Technical Safety Concept Development）。
这种在安全概念开发上的合作模式是当前国内主机厂和供应商间的主流合作模式，尤其是与保密性高的国外供应商间的合作模式。但是现在也可以看到的是，随着国内一些研发实力较强的主机厂对供应商的产品了解程度越来越高，要求也越来越细，而且有能力去推动供应商调整系统架构设计。在这种情况下，主机厂给供应商递交的可以是技术安全要求而不是功能安全要求。这种合作模式实际上在国外的主机厂和供应商之间已经很成熟，同时也从侧面说明了国内主机厂研发实力正在逐年提高。
下篇预告
下一期将基于EPB系统框架以及接口定义，以前文分析确定的Safety Goal为目标，举例阐述如何进行安全概念开发，得出技术安全要求。