月博

随着自动驾驶技术的发展，在保证高安全性的同时
，也需要满足高可用性的需求
，这对功能安全设计提出了更高的要求

。预期功能安全和信息安全作为“安全” 的重要部分
，提升了车辆的整体安全性。如何将预期功能安全、信息安全、功能安全三者融合，并在芯片层级助力其实现
，也是未来需要思考和解决的问题。

1.    汽车电子功能安全标准简介

随着汽车中电子器件占比的不断提升，由于电子器件失效而造成危害的概率也在不断上升。通过遵循一定的设计开发流程，同时在原有功能设计中加入保证安全性的额外功能，已成为业内普遍采用的方式
，从而有效降低风险发生的概率，保证人员安全。以上方法的目的是保证“预期功能”的安全性，将风险降低到可接受的范围内
，也即本文中讨论的“功能安全”的概念

。

功能安全要求由来已久
，在汽车电子行业开始重视功能安全设计的同时
，它在工业控制、航空航天以及铁路轨道交通等领域也在普遍被采用。下图总结了不同行业中功能安全相关标准的基本信息和要求
。

图1 不同行业中功能安全相关标准的基本信息

汽车电子行业中普遍使用的功能安全标准ISO 26262是基于工业行业功能安全标准IEC 61508演化而来，其更加适用于汽车行业实际情况。ISO 26262标准目前主要包含两个版本
：ISO 26262:2011版和ISO 26262:2018版，其中ISO 26262:2018版是在ISO 26262:2011版基础上修订的版本，较2011版在原有基础上增加了半导体功能安全章节和摩托车功能安全相关章节，同时修订了2011版中部分内容，使得标准内容更加明晰。此外，我国也发布了道路车辆功能安全国家标准GB/T 34590，第一版国标于2017年发布，第二版功能安全国标目前正在审批中，预计近期即可正式发布
。

无论是功能安全国际标准还是国家标准，其均为非强制标准
。但是随着功能安全概念和要求的不断普及和深入
，从行业范畴看其已经成为一定意义上的“强制”标准和准入门槛了
。

2.    汽车电子功能安全开发要求

根据ISO 262626:2018的要求，汽车电子功能安全开发需要遵循以下V模型进行开发和验证。在V模型的左侧侧重于设计开发要求

，而V模型的右侧侧重于验证与确认。ISO 26262:2018标准概览如下图所示
。

图2 ISO 26262:2018标准概览

依照ISO 262626:2018的要求
，汽车电子功能安全主要针对系统性失效和随机硬件失效进行避免或控制。对于系统性失效
，通常通过遵循一定的开发流程来避免

，典型的示例如软件开发过程中遵循A-SPICE或者CMMI流程进行开发
。对于随机硬件失效，则是依靠设计安全架构来对其进行探测和控制的，典型示例如通过冗余设计保证高安全性。

图3 失效的分类和避免/控制方法

按照功能安全标准中的要求
，对于系统性失效，通常没有定量的指标去衡量；而对于随机硬件失效
，则需要按照以下表格同时满足三个指标的要求。

表1 硬件随机失效度量指标要求

对于功能安全设计的正确性和完整性，需要进行验证和确认，二者的目的和执行层级通常会有所不同。

验证（verification）的目的是确定检查对象是否满足其特定要求，典型的验证活动可以分为以下几类
：

-     验证评审，走查，检查

；

-     验证测试
；

-     仿真模拟
；

-     原型样机；及

-     分析（安全分析
、控制流分析
、数据流分析等）。

确认（validation）的目的是基于检查和测试，确保安全目标是充分的，并已达到且具有足够的完整性等级。

需要注意的是，与传统质量体系不同的是，功能安全本身更强调技术层面的要求
。虽然为了控制系统性失效，功能安全整体要求中规定了对于流程体系的要求，并且其中很多规定是与ISO 9000以及IATF 16949质量体系中的要求基本一致，但功能安全更加突出了对于随机硬件失效的探测和处理要求
，这就需要从技术和设计层面加以重点考虑
，这也是功能安全与质量体系之间较为突出的区别。

总体来看，如果想要达成功能安全的要求，不仅需要搭建和落地相应流程体系，还需要从技术层面上（包括硬件方面和软件方面）进行功能安全设计
，最终满足定性和定量两个角度的要求。

3.    汽车电子功能安全开发概览

汽车电子功能安全开发的最终目的是保证由于E/E系统失效造成整车级别危害的概率降低到可接受的范围内
，因此无论是在整车级别设计功能安全，还是在控制器ECU层级以及在芯片层级设计功能安全，其均是为了达成前述目标。

从整车、控制器至芯片层级的需求和技术开发路径抽象概括如下图所示
。

图4 概念安全需求和技术开发路径抽象图示

整车层级功能安全开发活动对应于ISO 262626:2018标准Part 3概念阶段内容，整车厂通过HARA分析等一系列手段确定相关项（Item）的安全目标（Safety Goal），并进一步分解为功能安全需求（Functional Safety Requirement）下发给零部件供应商
。

零部件供应商在获取的安全目标和/或功能安全需求的基础上将开展系统开发以及硬件/软件开发，对应于ISO 262626:2018标准Part 4系统阶段
、Part 5硬件阶段和Part 6软件阶段开发活动
。这个阶段是零部件供应商能力和经验的体现
，也是设计的核心。虽然获取的上层功能安全需求一致，但是受限于能力区别
，不同的零部件供应商的实现方案通常会有不小的差别，这也造成了产品成本和技术指标的不同
。随着控制器复杂度的不断提升，其对芯片的依赖程度也在逐步增加
，想要设计一个符合特定功能安全等级要求的系统
，所使用的核心芯片（如微控制器芯片）就需要首先符合分配的安全等级，否则对控制器的开发会带来巨大的额外工作量。在这种情况下

，零部件供应商在选择系统中使用的核心复杂芯片时，为了节省自身工作量，通常第一选择是符合安全等级要求的芯片（ISO-Compliant）
，这样也造成了芯片供应商对自身芯片产品功能安全要求的不断提升
。

对于芯片供应商而言，除了要设计满足高性能且可靠的芯片外，还需要使其满足功能安全的要求。虽然这部分不是法规的要求


，但是目前来看已经成为部分类型车规芯片“上车”的一个门槛了
。作为车规芯片功能安全开发的起始，安全需求的定义至关重要
。芯片供应商为了使其研发的芯片在更广阔的市场和应用中被采用，芯片产品通常基于SEooC（Safety Element out of Context）的方式进行开发
，芯片顶层安全需要来自不同目标应用对于芯片安全需求的集合与抽象总结
。虽然可能无法完美匹配某一应用的要求
，但是其更好的适配了多种应用的多数通用需求
，具备了更好的应用前景和潜在用量
。

在假设了芯片顶层安全需求后
，需要将需求进一步细化和分解，并伴随芯片开发不同阶段进行需求实现和验证
。下图是芯片开发过程中采用的一种需求分解细化推导示例（不同类型芯片以及不同设计者会有不同方法
，也存在不同的需求命名方法
，此处仅作为参考示例）
。

图5 芯片层级功能安全需求逐级推导示例

从上图可以看出
，与控制器ECU相比，芯片本身其实一个更加复杂，集成度更高的系统

，因此上图所示分析方法其实是将功能安全标准的不同阶段与芯片开发阶段进行了对应与融合。作为组成芯片系统的关键单元，IP的功能安全设计尤为重要，是芯片功能安全设计中需要重点攻关的工作内容
。

在芯片层级功能安全开发中，除了硬件部分以外
，底层软件功能安全开发也是必须要考虑的活动。以微控制器芯片为例，涉及到的底层软件包含（但不限于）固件程序
，MCAL以及安全库（如有），这些软件组件的安全等级通常与芯片假设的安全等级对应。由于这些软件组件与芯片设计紧密相关，所以通常是由芯片供应商来提供给用户
，进而降低用户使用芯片的工作量
，提升芯片易用性。

4.    高性能微控制器芯片（MCU）实例

基于汽车电子不同应用的需求
，月博推出了满足ASIL D等级要求的THA6系列高性能微控制器芯片。

在功能安全开发过程中，芯片基于SEooC方式进行开发，从安全需求定义
、安全架构和安全机制设计
、定性/定量安全分析、功能安全验证/确认等不同阶段和角度保证了功能安全得到有效实施。在安全机制设计过程中
，设计人员充分考虑了安全性和用户易用性的要求，并且尽可能的提升芯片的可用性
，使其更符合汽车电子的独特要求。

目前此系列芯片已经通过了第三方认证机构功能安全流程体系认证和功能安全产品认证。

5.    结论与展望

随着汽车电子系统功能安全要求的不断提升，在满足可靠性的同时，对安全性的需求也在不断加强
，其中符合功能安全要求已经成为了很多车规产品“必需”的属性，尤其对于车规芯片产品。汽车电子复杂度的提升也带来了对于芯片的更高要求
，如何设计生产出高安全性车规芯片是亟需解决的问题，这就需要对技术难关进行攻克，并不断总结和积累经验。

此外，随着自动驾驶技术的发展，在保证高安全性的同时，也需要满足高可用性的需求
，这对功能安全设计提出了更高的要求。预期功能安全和信息安全作为“安全” 的重要部分，提升了车辆的整体安全性
。如何将预期功能安全、信息安全
、功能安全三者融合，并在芯片层级助力其实现，也是未来需要思考和解决的问题

。