基于ISO26262的功能安全分析和设计示例
- 前言
- 一、示例场景
- 二、概念设计阶段
- 2.1 危害分析和风险评估（HARA）
- 2.2 安全目标（SG）
- 2.3 功能安全概念（FSC）
- 三、产品开发阶段
- 3.1 硬件
- 3.2 软件
- 3.3 总结
- 四、测试和验证
前言
ISO26262标准体系定义了E-E系统功能安全的整体框架、分析方法和技术措施。但是，ISO26262标准体系本身有一定的复杂性，里面包括了10余篇标准文本，仅从标准文本出发，很难将功能安全的整个过程串成一条线。而如果去看某个实际产品的功能安全相关文档，又会陷入到复杂的技术细节中，也很难理清核心脉络。为此，本文采用一个示例，并以此为基础，对如何进行危害分析和风险评估，安全目标是怎么确定的，软硬件设计和开发中通常采用哪些关键技术，测试和验证环节中需要重点关注哪些问题进行探讨，帮助大家把标准由厚读薄，进而举一反三。
一、示例场景
InValue1
InValue2
InValue3
Out_Value
传感器1
ECU
传感器2
传感器3
执行器
在该示例场景中，控制器（ECU）接受3种传感器的输入值，根据输入值（In_Value）进行计算，得到输出值（Out_Value）。输出值直接输入给执行器，对系统功能具有重要意义。如果输出值计算错误，将使车辆出现失控等严重异常，危及人身安全。我们的目标，就是针对ECU开展功能安全分析、设计、开发和测试验证，确保由ECU产生的失效受到有效控制。
二、概念设计阶段
在概念设计阶段，主要做3件事情：危害分析和风险评估（HARA）、安全目标（SG）和功能安全概念（FSC）。当然，标准中还提及了项目定义，这部分内容本文就不讨论了。
2.1 危害分析和风险评估（HARA）
下面结合示例，来看危害分析和风险评估主要包括哪些步骤和内容：
- 第一步：分析失效场景。示例：在Out_Value值计算错误的情况下，会使系统产生意外动作，给人员造成严重伤害，危及人员生命。
- 第二步：危害事件分类。这一步主要依据标准26262-3给出的方法进行，需要综合考虑严重性（Severity）、暴露率（Exposure）和可控性（Controllability）3个因素。接着第一步中的示例，在该示例中：由于危及人员生命，所有严重度等级应为最高S3；人员必然暴露在危害中，暴露率也应为最高E4；失效发生后，人员没有控制手段，可控性应为最高C3。
通过以上，我们就得出了一条HARA分析结果：在Out_Value值计算错误的情况下，会使系统产生意外动作，给人员造成严重伤害，危及人员生命。该场景的危害事件分类是S3/E4/C3。
2.2 安全目标（SG）
通过安全目标确认，就可以得出一个失效场景对应于何种安全等级（ASIL）。这一步主要依据26262-3中的Table-4：
结合HARA分析结果，示例失效场景的危害事件分类是S3/E4/C3，查Table-4，对应于安全完整性等级ASIL-D，即最高安全级别。
综合以上，我们可以得出一条具体的安全目标：
安全目标：防止系统产生危及人员生命的意外动作。
确保执行器不能产生意外动作，这会使车辆偏离人员驾驶意图，进而危及人员生命。该失效场景可能来源于ECU故障或者Out_Value值计算错误。
安全完整性等级：ASIL-D。
这里有1个点需要注意：并不是所有的失效场景都要定为ASIL-D，即便是安全关键系统。从Table-4我们也可以看出，只有S/E/C都达到最高，才能定为ASIL-D。更高的安全完整性等级，意味着更为复杂的设计和实现，也就意味着更高的成本。
2.3 功能安全概念（FSC）
ISO26262对FSC的定义比较模糊，我们可以这样理解：既然有了失效场景和对应的安全目标，那么，应该采取哪些安全机制来达到安全目标？FSC的作用就是回答这个问题。ISO26262没有定义FSC应该包含什么内容，通常来说，FSC至少应该包括功能安全需求（FSR）。从HARA/SG到FSR，有一些方法论，这里我们不展开。我们仅就示例场景罗列出部分安全需求，以便和产品开发阶段所引入的技术相关联：
- ECU必须采用冗余校验机制确保Out_Value计算的正确性：
1）ECU通过主通道计算Out_Value值；
2）ECU通过监控通道独立计算Out_Value值；
3）主通道和监控通道必须采用独立的输入获取In_Value值；
4）ECU需要对主通道和监控通道计算出的Out_Value进行比较，如果不一致，则进入安全模式。 - ECU必须采用监控通道，监控执行器的执行状态，如果执行状态异常，则进入安全模式。
- 系统必须具备电源监控、ECU错误监控、看门狗等功能，确保ECU运行状态正确性，在出现异常时，可执行系统恢复过程。
在这里，用到了功能安全领域的最常用方法：冗余和监控。这些方法在标准中也有定义，具体可参考26262-6。
三、产品开发阶段
为实现概念设计阶段中的功能安全需求，我们首先要搞清楚采用哪些技术，至于写架构设计、详细设计等文档，都是水到渠成的事情。下面，我们从硬件和软件两个方面展开讨论。
3.1 硬件
由于示例失效场景的安全完整性等级是ASIL-D，所以，主要芯片应达到ASIL-D等级。在该示例中，假设ECU包含一颗MCU，用于接收传感器给出的In_Value，并计算Out_Value。那么这颗MCU应选用ASIL-D等级的产品，例如MPC5643L。采用ASIL-D等级的MCU，同时可以获得芯片厂商所提供的功能安全认证资料包，对于系统过功能安全认证具有重要意义。
除主芯片以外，还需要选择ASIL-D等级的SBC芯片，承载电源监控、ECU错误监控、看门狗等功能。例如飞思卡尔MC33907。
为满足Out_Value值计算的独立性，必须采用两路独立的传感器，独立给出In_Value值。之所以要采用两路独立的传感器，是因为要避免由单路传感器所带来的共因失效（CCF）。
3.2 软件
- 选用ASIL-D等级的实时操作系统。
1）由于需要引入多个任务并发来实现主通道和监控通道，所以必须采用具备多任务调度能力的操作系统；
2）由于需要满足进入安全状态的实时性要求，需要操作系统具备实时性，能够实现高优先级任务抢占调度，确保中断处理的优先级等功能；
3）ASIL-D等级的操作系统具备内存分区、时间分区等功能，可以在同一芯片上运行多个不同ASIL等级的应用（任务和中断）。这对于功能较为复杂的系统具有重要意义。
对于MCU，可直接使用AUTOSAR CP，它里面定义的OS具备多任务调度能力，具有很强的实时性，具有内存保护、时间保护等关键安全功能，可满足相关要求。
- 需要实现Out_Value主从通道冗余计算、执行器监控等安全功能。
- 在编码过程中，需要注意以下几点：
1）需要对编程语言采用安全编码规范，满足编程语言的安全子集要求。例如，如果采用C语言，则需要引用Misra C安全编程规范。Misra C对C语言的特性进行了限制和裁剪，避免由语言本身引入某种缺陷。例如，无限制得使用指针造成的野指针问题。26262-6 Table-9也给出了具体说明： - 2）所采用的编译器也有要求，这是经常被忽视的一点。在26262-8中，对所使用的工具也给出了置信度分级，即TCL1、TCL2、TCL3和TCL4。工具的置信度分级主要用于指导工具鉴定。但对于工具的选型来说，只要掌握以下原则：
第一，对于项目管理工具、需求管理工具等，对于源代码和编译出的可执行文件没有影响的，只需要选择最低等级，即TCL1等级的工具即可；
第二，对于单元测试工具，由于它影响源代码，所以需要选择通过了TCL2等级认证的工具；
第三，对于编译器，由于它可以直接影响源代码和最终可执行文件，可以在编译过程中插入不可控的二进制代码，所以，编译器需要达到最高等级的鉴定要求。如果采用商用编译器，则需要确认商用编译器是否满足该要求，并提供功能安全认证资料包；如果采用开源编译器，如GCC，则需要实施编译器验证，以确保编译器行为的安全性。
3.3 总结
通过对软件和硬件的设计，我们可以描绘出以下安全架构：
再总结一下设计要点：
1、选用ASIL-D等级的主芯片；
2、选用ASIL-D等级的SBC芯片，承载电源监控、ECU错误监控、看门狗等安全功能；
3、对安全关键输出量设计冗余架构，通过独立的监控任务对输出量实现冗余计算；
4、安全关键输出量的主计算通道和监控通道必须采用2路独立输入，避免由单一输入通道带来的共因失效；
5、对执行器进行冗余监控；
6、采用ASIL-D等级的安全实时操作系统，实现多任务调度，确保任务实时性，进一步满足不同ASIL等级的应用集成需求。
四、测试和验证
测试和验证环节主要包括了单元测试、集成测试和系统测试等关键步骤，所包含的内容很多，这里只给出几个关键点：
- 单元测试需要满足26262-6 Table-14的要求：
ASIL-D需要满足行覆盖率、分支覆盖率以及MC/DC覆盖率均达到100%。 - 单元测试建议使用满足TCL2等级的商用工具，如TestBed、Contata等。这类工具均具备自动化生成单元测试用例的功能，通过自动生成的用例就可以达到行覆盖率和分支覆盖率100%，测试人员再手动调整部分用例即可满足要求，可大大提高单元测试效率。
- 需要关注全流程关联性，即需要体现出HARA->SG->FSC->概要设计->详细设计->单元测试用例->集成测试用例->系统测试用例全过程的关联性。 这可以使用需求管理工具建立全过程链接，也可以采用Excel表格的形式体现出关联性，当年采用工具是最为推荐的方式。
本篇完结
