求一种基于功能安全的车载计算平台系统开发方案-电子发烧友网

相对于功能安全概念阶段，系统阶段更专注于产品的详细设计，涉及系统工程、安全工程和架构设计等不同技术领域。同时，系统阶段也经常扮演着供应链上、下游功能安全的DIA交互阶段，是功能安全中非常重要且考验技术水平的阶段。

应用环境

车载智能计算平台，作为自动驾驶的主要部件，其应用环境参考如图。

车载智能计算平台应用环境参考示意图

车载智能计算平台的应用环境主要包含用于环境感知（如摄像头、激光雷达、毫米波雷达、超声波雷达等）和位置定位（如GNSS、高精度地图等）的传感器，整车底盘域、动力域以及车身域的执行器，人机交互的HMI，以及外部互联与通信的T-Box和OBD等。随着自动驾驶等级的不断提高，车载智能计算平台对应用环境中的传感器、执行器、人机接口和外部互联通信有更高的功能要求及功能安全要求。

功能划分

车载智能计算平台按照功能可以分为传感器接入及管理、AI计算、通用计算、通信、存储和车控等。不同的功能依赖不同的系统模块实现。传感器接入与管理单元提供丰富的软硬件接口，使能传感器接入及管理。AI计算提供深度神经网络算法加速计算能力。通用计算主要是指面向常规算法的计算能力。

车载智能计算平台内部通信提供车载智能计算平台内部各个要素之间通信能力。V2X通信提供车载智能计算平台连接车辆外部设备能力。存储功能提供诸如高精度地图存储及服务能力。车控提供车控下发能力，对接车辆执行器。

车载智能计算平台功能单元参考ASIL等级

安全分析

系统安全分析的目的是识别功能或系统设计中存在的违背安全目标的失效（包括单点失效或异常）和相关性失效（如共因失效和级联失效）等。ISO 26262对此提及两种安全分析方法：

归纳分析（Inductive analysis）：是一种以自上向下的分析方式，从已知影响结果入手逐步向下分析找到失效原因的方法；

演绎分析（Deductive analysis）：是一种以自下而上的分析方式，从已知的失效原因入手推导出影响结果的方法。

演绎分析方法是针对ASIL等级为C/D的功能安全开发所使用的方法，具体常用的方法有故障树分析（FTA）、可靠框图（RBD）、系统理论与过程分析（STPA）等。归纳分析方法是针对所有ASIL等级的功能安全开发都强烈推荐使用的方法，具体常用的方法有失效模式与影响分析（FMEA）和事件树分析（ETA）等。

另外，安全分析包括定量分析与定性分析，在系统阶段的安全分析用于辅助系统设计，因此，这个阶段定性的安全分析就足够了。在系统阶段的安全分析过程中，除了上面提及的分析方法，还包括危险和可操作性分析（HAZOP）、接口安全分析（ISA）。

安全策略

自动驾驶功能目前的系统安全策略大体分为两种，即Fail-Safe（失效-安全）以及Fail-Operational（失效-可操作）。Fail-Safe要求系统监控关键的部件以达到失效后系统关断的目的。但是对于L3及以上的功能，驾驶员处于脱眼、脱手的状态，系统的关闭并不能保证可靠地完成驾驶权的转移。

例如，高速公路场景中，车辆紧急停止在本车道是一种潜在的风险状态，很容易发生高速追尾。Fail-Operational安全策略解决了这一问题，即使在主功能系统失效的情况下，仍然有备份系统可以保证车辆进行降级操作，让车辆转移到安全区域。

系统设计

系统安全架构，业内常使用的是E-Gas三层监控架构。E-Gas监控概念源于奥迪、宝马、戴姆勒、保时捷、大众等成员一起通过工作组的形式开展的针对复杂车载控制系统的安全监控架构设计指导性文档，涉及系统架构、软件和硬件的设计理念，广泛应用于传统燃油车和新能源汽车监控与诊断设计领域。

E-Gas监控概念的核心是三层安全架构设计。整体设计分为Level1、Level2和Level3，其定义如下：

E-Gas三层安全架构（带锁步核）

Level1：功能层，包括扭矩的解析、功能的诊断等，最直接的理解就是能够实现设计基本功能的软件及相关硬件资源的组合；

Level2：功能监控层，负责监控功能层的输出结论，简单理解来看，就是软件的冗余校验，但是，由于不想消耗太多资源及避免算法共因，所以基于功能结果的监控；

Level3：硬件监控层，负责确保Level1和Level2的运行的硬件环境是正常工作的，异常的运行环境会导致Level2的设计起不到很好效果，因此，Level3在整体的监控架构中作用是不可替代的。

车载智能计算平台的安全策略可以是独立的监控模块或冗余的系统设计。独立的监控模块实时监控功能实现模块的软硬件故障，一旦检测到有安全相关故障，车辆即进入安全状态，如需要可先进入紧急运行模式（Emergency Operation）。例如，功能降级、当前车道停车、安全地点停车等。

冗余的系统设计是指两个或多个功能模块互为备份。例如，车载智能计算平台可以采用“主处理单元+辅处理单元”双处理架构，以确保L3及以上自动驾驶车辆的安全。在该架构下，主处理单元对车辆的运动轨迹进行规划和控制，辅处理单元的作用是监控主处理单元。同时两个单元不断地进行交叉检查，当两个通道在规划轨迹和控制策略存在较大偏差时，系统就会进入降级模式。主处理单元和辅处理单元可以按照ASIL-B设计开发，仲裁模块可以按照ASIL-D设计开发。

在系统阶段进行设计时，需要考虑不同系统单元的故障以及对应的处理策略，具体包括传感器接入能力失效，比如丢帧、乱序等；通用计算能力或AI计算能力失效，比如代码跑飞、执行超时等；内部或V2X通信能力失效，比如超时等；存储失效，比如高精度地图数据损坏等；车控失效，比如非预期发送车控等；电源失效；时钟失效。

技术安全概念

技术安全概念是车载智能计算平台系统设计中安全策略与安全设计的集合。技术安全概念的内容主要包含基于系统架构的功能安全分析，基于上级功能安全要求与功能安全分析导出的技术安全要求，最终集成安全设计的系统架构，以及后续生产过程中需要采取的安全措施。

技术安全要求需要定义具体的安全机制并分配到相应的架构要素中，以确保在下一级的开发过程中，安全机制可以被进一步细化与实施。在车载智能计算平台的开发过程中，技术安全概念可能针对于某一系统或子系统，因而技术安全要求涉及的架构层级可以不止一层。功能安全概念规定了系统的安全目标，以及系统所需要的安全功能以实现这些安全目标。而技术安全概念则需要实现以下两部分内容：

①进一步细化安全概念提出的安全功能，也就是从做什么转化为怎么做，得出安全功能的实现技术方案；

②分析安全功能的实现路径，找到系统或技术方案中引起安全功能失效的单点故障、潜伏故障和多点故障，并提出安全措施或安全机制来覆盖这些故障。

具体而言，从功能安全需求（FSR，Functional Safety Requirement）/功能安全概念（FSC，Functional Safety Concept）导出到技术安全需求（TSR，Technical Safety Requirement）以及技术安全概念（TSC, Technical Safety Concept）的步骤如下：

步骤1：针对每一条FSR/FSC，详细制订该条FSR/FSC的实现技术方案，也可以理解为FSR/FSC在系统初始架构要素中的功能执行路径，从传感器→控制器→执行器的实现路径；

步骤2：FSR/FSC的实现技术方案为对象，进行FTA或FMEA分析，识别出该实现技术方案中违背该条FSR/FSC的单点故障和双点故障；

步骤3：针对单点故障，设计相应的具体诊断机制或安全措施；

步骤4：针对双点故障，设计相应的避免潜伏故障的诊断机制或安全措施；

步骤5：汇总上述技术实现方案、针对单点的诊断机制和避免潜伏的诊断机制，形成TSR；

步骤6：将导出的TSR分配到具体实现要素如硬件和软件，优化系统架构设计，即TSC；

步骤7：针对较复杂或多层系统，可重复步骤1—6过程进行迭代设计，直至完成整个系统的TSR/TSC开发。

在车载智能计算平台的技术安全要求中，若采取多层次的技术安全要求，其基本原则不变，即技术安全要求要与架构层级相映射并最终被分配到软件与硬件中，以保证软件与硬件的功能安全开发有明确和完整的输入。

测试验证

系统测试内容与方法从软硬件层面、系统层面与整车层面提出了要求，相应的测试内容、测试方法以及ASIL等级要求如表。

系统测试内容与方法列表

车载智能计算平台在功能安全概念阶段开发或假设了上层的安全目标和功能安全要求，安全要求在之后各个阶段被逐渐细化和实现。最终完成硬件层面及软件层面开发和集成的车载智能计算平台能否正确实现安全要求，以及是否存在非预期的功能，需要通过系统层面的集成测试进行验证。系统层面的测试验证，一方面需要确保安全要求能够被正确地使能，另一方面还需要确保车载智能计算平台不会因为安全要求非预期使能而导致系统可用性降低。

制定有序的系统层面测试计划，并进行持续的过程跟踪管理，是保障车载智能计算平台测试验证工作有序可靠进行的必要途径。开发测试团队应重点考虑项目整体时间计划、测试验证的人员安排与责任分工、测试方法、测试环境、测试工具等方面的内容，综合评估和确认之后形成测试计划。

基于SEooC模式开发的车载智能计算平台实际应用到目标车型时，系统集成测试和整车集成测试是发现系统性故障不可或缺的安全活动。在系统集成测试和整车集成测试活动中，需重点验证目标车型的功能安全要求是否得到正确实现，集成真实的传感器和执行器等其他其它要素之后的系统响应是否满足安全机制的要求，车载智能计算平台与目标车型其他要素之间的接口与交互过程是否正确，以及安全要求在外界严苛的环境条件和运行工况下能否正常实现。

系统开发常用工具介绍

依据ISO26262的要求，为实现系统设计满足如图所示的原则，一般可使用半形式化如SysML语言+自然语言实现。行业内用得比较多的、支持系统设计的工具有Medini Analyze、IBM Rhapsody和Enterprise architect等。Medini Analyze与ISO 26262要求更加契合，IBM Rhapsody和Enterprise architect的系统工程建模则更加强大。

系统设计原则

a、Medini Analyze

Medini Analyze是Ansys公司开发的一款支持ISO26262开发活动的工具，它提供一系列绑定在模型化环境中的先进分析方法，包括：

•针对电子电气系统和软件控制功能的安全分析和设计，以及适用于ISO26262、IEC61508、ARP4761和MIL-STD-882E的特定模板；

•将架构/功能设计与质量、可靠性和功能安全分析方法进行集成；

•可支持运行情境分析、危险与风险分析（HARA）、功能性风险评估（FHA）、FTA、FMEA、FMEDA、FMECA概率可靠性分析以及硬件失效指标；

•依照SAEJ1739、VDA质量手册、AIAG等标准进行产品设计及相关流程的质量分析；

•完整的端到端可追溯功能；

•工作成果和文档的定制化生成；

•团队协作支持，包含模型化高级对比和合并技术；

•集成Ansys SCADE Architect、IBM Rational DOORS、IBM Rational Rhapsody、Enterprise Architect、MATLAB/Simulink、State flow、PTC Integrity、Microsoft Office、Tortoise SVN、IBM Rational ClearCase、Jama Software等工具。

Medini Analyze驱动集成安全分析

b、IBM Rhapsody

IBM Rhapsody是IBM公司基于UML/SysML的模型驱动开发集成环境，用于嵌入式和实时系统的系统设计开发工具。

Rhapsody的主要功能如下：

•使用行业标准建模语言：UML、SysML、DoDAF等；

•支持可视化模型仿真；

•支持C、C++、Java等语言开发环境，做到模型平台无关性；

•支持常用的嵌入式实时操作系统，如VxWorks、嵌入式Linux、Android、OSEK、QNX等；

•基于Jazz平台与DOORS、RTC、RQM无缝集成。

c、Enterprise architect

Enterprise architect是Sparx Systems公司的旗舰产品。它覆盖了系统开发的整个周期，除了开发类模型之外，还包括事务进程分析、使用案例需求、动态模型、组件和布局、系统管理、非功能需求、用户界面设计、测试和维护等。该工具特点：

•高价值、端到端的建模，支持软件和系统工程的完整的建模生命周期；

•建模、管理和跟踪需求；

••强大的文档生成能力；

•源代码的生成和反向工程；

•先进的模型驱动架构，包括C#、DDL、EJB、Java、Junit、NUnit、WSDL、XSD的建模转化；

•支持SysML系统工程和仿真；

•业务流程建模；

•基于UML2.4.1语言；

•高效的项目管理；