为了便于诊断管理（包括诊断触发和故障响应等），根据临界故障 / 非临界故障，诊断测试时机等因素进行分组。上电时如果检出临界故障（Critical fault），比如：核故障（Core Fault）、易失性存储器测试故障（Ram Test Fault）等，这时故障响应可以选择处在一个静默状态处理（如：MCU 处在连续复位状态）。

图4.1-9 “功能安全诊断框架”与“功能安全诊断控制流”

E-Gas 三层监视框架的 Level1(function level） 及 Level2(function monitoring level） 位于 AS- W(application software, 即 : 图 4.1-9 中 的 SWC) 层，Level3(controller monitoring level） 位 于BSW(basic software) 层。“诊断框架” 同样也位于 BSW 层，如上文所述主要覆盖诊断测试、故障响应过程 ( 图 4.1-9)，下文对其构成和工作过程展开介绍：

·  BswM、EcuM 主要负责上下电管理，在 STARTUP、UP、SHUTDOWN 阶段分别进行上电时、运行时、下电时的诊断测试

·  ASW-Level1（E-Gas Level1）覆盖功能输入 / 输出的诊断；ASW-Level2（E-Gas Level2）一般实现为 ASW-Level1 功能的冗余算法，实现 ASW-Level1 ASIL 等级的分解；TestLib（E-Gas Level3）监视ECU、MCU 层面的硬件失效（建议参考 ISO26262(2018)-Part5 Annex D 及 MCU 安全手册），覆盖 Level1 和 Level2 共因失效的诊断，并和 “监视控制器” 实现用于逻辑及时间独立性诊断的问答看门狗机制

·  TestManager 负责对 TestLib 安全机制的诊断测试触发及相应测试结果的收集

·  DEM 收集 E-Gas Level1/2/3 的测试结果，诊断事件去抖，标记故障码及通过 NvM 进行故障信息存储。FiM 根据 DEM 诊断测试结果（去抖后）标记已配置的功能，功能软件（ASW-Level1） 根据标记来决定对功能的抑制

4.1.3  内存分区静态分析技术解读

内存分区静态分析技术是静态分析层面的 Safety Checker 技术，用于静态分析各软件要素之间实际上是否实现有效的隔离，达到免于干扰的目的。

在应用软件这个层面上，软件要素可以认为具有控制流或数据流的属性。如果要证明不同分区的两个软件要素互相不干扰，必须展示它们之间有不允许控制流或者数据流交互的机制。Safety Checker 技术基于软件要素的控制流和数据流进行分析，可以用于源代码或者目标文件，在软件的构建阶段进行内存的干扰检测。该技术以软件分区的设计文档或者需求文档为输入，检测实际的软件代码是否真正符合设计的需求，对于防止内存干扰的设计进行验证，形成一个软件开发到分析检测的闭环。

图4.1-10 Safety Checker的使用方式

静态分析之前，首先需要定义软件安全级别分类（如：ASIL A/B/C/D 等），接下来需要分配不同安全级别间的分区访问权限（读，写，执行），最后将程序中的符号和资源（代码，变量，存储空间等）分配相应的安全级别。上图是 Safety Checker 进行代码静态分析的方法和流程。部分或者全部的源代码都可以使用该技术进行内存干扰的分析，将配置好的内存分区信息文件（partitioning.saf）和源文件作为输入，就可以获得分析结果。根据软件设计或者需求文档，可以通过软件分区信息文件 partitioning.saf 对于整个工程用脚本的形式做一些规则的编辑，这些规则包括以下内容：

·  软件安全级别

·  分区间访问权限

·  关键函数和数据对象（变量、数组、指定内存空间）的安全级别

内存分区可以有效解决免于内存干扰问题，Safety Checker 技术则是对这个方案的有效补充，该技术能够分析位于 ECU 上的所有软件的行为，找出软件分区间干扰和分区内干扰。在软件的开发阶段发现违背设计目标的内存干扰项，可以减少测试验证阶段的压力，缩短项目的开发周期。

4.1.4  工具链的功能安全要求

开发符合功能安全要求的软件，使用的软件工具链同样需要符合功能安全要求。ISO 26262-8 第 11 章讨论确定了软件工具的置信度水平（TCL），并提供了对工具进行资格认证的方法，以创建证据来证明软件工具适合用于功能安全相关软件开发 ( 图 4.1-11 和图 4.1-12)。

图4.1-11 工具置信度活动的概览

图4.1-12 工具评估与鉴定流程

工具影响等级和工具错误探测等级两个维度，共同决定了工具的置信度水平。

其中工具影响（TI）等级反应的是软件工具的异常，可引入或者不能探测开发中安全相关项或要素中错误的可能性。

·  有论据表明没有这样的可能性，确保软件工具的异常不会引入到安全相关软件要素，应选择 TI1；

·  其他所有的情况下，都选择 TI2。

工具错误探测（TD）等级，反应的是用于预防软件工具功能异常并产生相应错误输出的措施的置信度， 或用于探测软件工具存在功能异常并已产生相应错误输出的措施的置信度。

·  当对预防或探测出功能异常及其相应错误输出具有高置信度时，应选择 TD1；

·  当对预防或探测出功能异常及其相应错误输出具有中等置信度时，应选择 TD2；

·  在所有其他情况下应选择 TD3。

如果对 TI 或 TD 选择的正确性是不清楚的或可疑的，宜对 TI 和 TD 进行保守评估，即选择最高级。基于为 TI 和 TD 等级确定的值，按照下表 4.1-2 确定所要求的软件工具的置信度水平。

表4.1-2 软件工具的置信度水平

其中针对 TCL1 等级的软件工具无需进行认证，针对 TCL2 和 TCL3 的软件还需要结合实际的功能安全需求进行下一步的认证。下表 4.1-3 中总结了 TCL2 和 TCL3 等级的软件工具在不同 ASIL 等级的要求。可以看出，两者仅在 ASIL-C 等级鉴定要求有所不同。

表4.1-3 TCL2和TCL3等级的软件工具鉴定

注：++ 表示该方法被强烈建议用于所对应的 ASIL，+ 表示该方法被建议用于所对应的 ASIL。标准中提供四种方法来鉴定软件工具：

·  使用中积累置信度。顾名思义，在之前的开发中，对于软件的使用积累了足够的数据和经验，对于当前所应用的项目，软件工具具有相似的使用案例、相似的运行环境和相似的功能约束。

·  工具开发流程评估。就是用于开发软件工具的流程应当满足适当的标准，同时提供该流程被应用的证据。例如，ASPICE 或者 CMMI 的认证。

·  软件工具确认。确认措施应提供软件工具符合分类中指定用途的特定要求的证据；应对确认中发 生的软件工具功能异常及其相应错误输出、其可能的后果信息及避免或探测它们的措施进行分析；应检查软件工具对异常运行条件的响应。

·  按照安全标准开发。安全标准如 ISO 26262、IEC61508、GB/T 34590-XXXX、GB/T 20438、EN50128 等，并不完全适用于软件工具的开发，可从安全标准中选择相关的一组要求。

至此，结合我们项目中 ASIL 的需求，以及软件工具的 TCL 等级，可以选择适当的方法鉴定软件工具。对于前两种方法，只适合 ASIL-A、ASIL-B 以及软件工具被鉴定为 TCL2 的 ASIL-C 的项目应用。

对于 ASIL-C（TCL3）和 ASIL-D 等级的项目，只有后两种方法适用。在汽车软件工具领域，普遍采用 “软件工具确认” 的方法。从本质上讲，“软件工具确认” 意味着使用验证措施来证明软件工具满足其目的的指定要求。

有两种不同的方式被用来实现 ISO 26262 的 “软件工具确认” 要求。

一种是软件工具供应商进行 “软件工具确认” ，邀请合格评估机构来对软件工具进行鉴定，并提供证明符合 ASIL-C 乃 ASIL-D 的认证证书。在这种情况下，软件工具的客户将会得到经过认证的软件工具以及一个安全手册。客户只需要应用安全手册中的指导方针，以证明它的用例与合格的用例是兼容的。

另外一种方式是软件工具的使用方，按照软件工具确认的方法，自行去寻找合适的评估机构对软件工具进行鉴定，证明工具符合 ASIL-C 或 ASIL-D 等级要求。工具鉴定的方法通常是经过认证的，工具鉴定的内容可以总结为：

• 指定用例，以定义工具需要满足的需求

• 选择适当的测试来验证这些需求

• 执行测试

• 分析测试结果

• 生成安全文档

• 应用安全文档中的指导

  
  

后一种方式的缺点是存在相当多的隐性成本，例如：学习资格认证方法和相关工具，必要的测试套件许可，执行工具验证过程，与验证者交互，最后如果测试失败如何处理。

4.2  信息安全与基础软件

4.2.1  相关标准介绍