道路车辆功能安全标准（FuSa）基础(八)
在实际评级中，安全工程师会制定详细的E、C、S值量化评分表，于是对于任意一项需求，都可以对照评分表得出其E、C、S的值。其中，确定E值的过程叫做Risk Assessment，而确定C值和S值的过程叫做 Hazard Analysis。有了E、C、S值， 再对照ASIL评级图，就可以得出这项需求的ASIL 评级了。
前面说了那么多各种概念，现在来谈一下为什么说执行ISO26262后一定能保证功能安全。
根据ISO26262， 对于任何一项需求，其功能安全大致可以通过以下几个步骤来保证：
1）进行HazardAnalysis 和 Risk Assessment。前文已叙，这个步骤是为了获得需求的E、C、S值。
2）评出此需求的ASIL评级并建立Safety Goal。Safety Goal 是一个具体的、定性的安全目标，比如转向助力那个例子中， “助力方向一致” 这个需求一定是ASIL D级，故障后会有相当大的安全风险。其SafetyGoal就是把故障风险降低至可容忍风险以下。Safety Goal继承对应需求的ASIL评级。
3) 将SafetyGoal 进一步分解为 Functional Safety Concept 和Technical Safety Concept。还举前例，要怎样降低 “助力方向一致”故障的风险呢？一个可行的办法是进行冗余计算：用两套不同的算法计算助力方向，保证结果的正确性。或者，把助力电机的力矩限制在一个较小的值也是个好办法，因为这样一来即便助力方向错误，由于助力有限，驾驶员还是可以控制汽车。
这些解决方法就是FunctionalSafety Concept。把Functional Safety Concept进一步在技术上具体化，就是Technical Safety Concept。它们将继承步骤2）评出的ASIL等级。不同的ASIL等级对FunctionalSafety Concept 和 Technical Safety Concept有不同的要求。
4）由TechnicalSafety Concept 形成Software Safety Requirements 和 Hardware Safety Requirements。这些就是非常具体的安全需求了，可以直接作为软/硬件设计的依据。这些需求也继承了相同的ASIL等级。
5）根据4）步得到的安全需求，结合其ASIL 等级制定测试与验证方案。对于不同等级的安全需求，ISO26262对测试方案有着硬性的要求。比如ASIL D级需求除了进行MISRA、PolySpace等测试外，还要进行完备的功能测试和覆盖率100%的MCDC测试，并对Traceability （可追溯性）也有相应要求。
FUSA-028
在进行这套流程的同时，还需配合FMEA和 DRBFM 对系统设计进行分析和评价。可以说，全套流程结束以后，功能安全能够得到有效的保障。
下面举几个例子进行说明：
EPB（ElectricalPark Brake）电子手刹，EPB较传统的驻车制动器，除了驻车功能，还有动态起步辅助功能、紧急制动功能以及自动驻车功能等。这里我们以以电子手刹的驻车功能为例，当驻车时，驾驶员通过按钮或者其他方式触发制动请求，EPB在汽车的后轮上施加制动力，以防止车非期望的滑行。该系统的危害有非期望的制动失效，非期望的制动启动。相同的危害在不同场景下风险也是不一样的，因此我们也要对不同场景进行分析。
为了简化问题，这里我们仅对”非预期制动失效”这种功能故障进行风险评估。下表给出了EPB风险评估表，在该表中我们考虑的驾驶场景是车停在斜坡上，驾驶员不在车上。如果驾驶员在车上的话，驾驶员可通过踩刹车控制汽车滑行，可控性增加，那么所评估的ASIL等级会比表中的ASIL D低，但是对于同一个安全目标，如果评估的ASIL等级不同的话，要选择ASIL等级最高的那个。根据如上分析，得出了EPB系统的安全目标为：防止非期望的制动，ASIL等级为D。
根据上面的分析，不难得出其它例子的ASIL等级，比如：功能安全目标的分解通过上危害分析和风险评估，我们得出系统或功能的安全目标和相应的ASIL等级，当ASIL等级确定之后，就需要对每个评定的风险确定安全目标，安全目标是最高级别的安全需求。安全目标确定以后就需要在系统设计，硬件，软件等方面进行设计和实施，验证。从安全目标可以推导出开发阶段的安全需求，安全需求继承安全目标的ASIL等级。如果一个安全需求分解为两个冗余的安全需求，那么原来的安全需求的ASIL等级可以分解到两个冗余的安全需求上。因为只有当两个安全需求同时不满足时，才导致系统的失效，所以冗余安全需求的ASIL等级可以比原始的安全需求的ASIL等级低。
ISO 26262标准的第9章给出了ASIL分解的原则。ISO 26262中提出了在满足安全目标的前提下降低ASIL等级的方法——ASIL分解，这样可以解决上述开发中的难点。ASIL 分解的一个最重要的要求就是独立性，如果不能满足独立性要求的话，冗余单元要按照原来的ASIL等级开发。
所谓的独立性就冗余单元之间不应发生从属失效（DependentFailure），从属失效分为共因失效（Common Cause Failure）和级联失效(Cascading Failure) 两种。共因失效是指两个单元因为共同的原因失效，比如软件复制冗余，冗余单元会因为同一个软件bug导致两者都失效，为了避免该共因失效，我们采用多种软件设计方法。级联失效是指一个单元失效导致另一个单元的失效，比如一个软件组件的功能出现故障，写入另一个软件组件RAM中，导致另一个软件组件的功能失效。
具体降解的方法如下所示，比如应按照下列之一对一个ASIL D 的要求进行分解：
1) 一个ASIL C(D)的要求和一个ASIL A(D)的要求；
2) 一个ASIL B(D)的要求和一个ASIL B(D)的要求；
3) 一个ASIL D(D)的要求和一个QM(D)的要求，
以上简单的介绍了下功能安全的定义，以及ASIL等级的评定和分解。
关于功能安全的介绍， 可以参考前文：
关于BMS的基础知识，可以点击下面链接访问：
关于自动驾驶的基础知识， 可以点击下面链接访问：
关于ADC和DAC转换器电路的基本知识
- 用户评论
