汽车电子软件功能安全开发要点

概述

安全环保已成为当今社会对汽车产品的重要价值取向，在汽车中占有最重要位置的E/E系统的安全性自然成为焦点。国际标准化组织于2011年在IEC61508 E/E系统功能安全标准的基础上制定并发布了第一版道路车辆功能安全标准集ISO26262，并在2018年更新了第二版。我国也于2017年发布了相应的标准集GB/T34590，本文中统称为功能安全标准。这些标准基于“东西总会坏、人总会犯错误”的假设，针对随机硬件故障和系统性故障，从产品开发流程和技术应用两个维度提出了要求。作为业界功能安全的最高准则（state of the art），被广大汽车OEM所采用，作为安全相关车载ECU产品的开发标准。该标准集的第六部分描述了对于车载E/E系统中软件开发的相关要求。

功能安全软件开发流程

ASPICE

汽车行业的软件开发基本采用ASPICE（Automotive Software ProcessImprovement and Capability dEtermination）模型框架，作为研发流程改善及供应商能力评价的标准。该标准是SPICE（ISO15504）在汽车行业的应用。多数汽车OEM要求供应商的软件开发能力要达到Level 3以上。车载ECU供应商一般会基于该标准，在第三方咨询公司的帮助下，结合本公司实际情况建立适合本公司的流程体系，以明确产品开发中的各种活动，活动的输入输出，参与活动的各种角色以及应采用的模板、指南和检查清单等辅助工具。

ISO26262的定义

功能安全标准的第六部分描述了对软件开发的要求，主要活动包括需求定义，框架设计，单元设计及实现，单元验证，集成验证，功能验证等活动，如图1、2所示。

图1 ISO26262系列标准概览

图2 软件开发参考模型

这些活动从流程上与ASPICE的要求没有本质区别。在技术应用上，功能安全标准针对各活动定义了一些具体的措施。

计划阶段应考虑的内容

软件开发项目启动时应考虑采用何种开发手段和方法，例如采用何种开发语言，是否采用基于模型的开发，是否需要遵守MISRA-C标准等。但这些手段和方法不应在项目计划时临时考虑，应该作为组织开发流程的一部分明确定义并作为组织过程资产积累。表1规定了ASIL B需要满足的具体要求（注：本文以下各节中表格的内容也是以ASIL B为例从ISO26262标准中抽出的，因此表中各项目的序号可能不连续。）。如果组织采用基于模型的开发手段，如MATLAB等，并建立了统一的建模及命名规范，而且实施规范化的满足MISRA-C的代码解析活动，即可充分满足这些要求。

表1 建模和编码指南涵盖的通则

1a	强制低复杂性
1b	语言子集的使用
1c	强制强类型
1f	无歧义图形化表示的使用
1g	风格指南的使用
1h	命名规范的使用

需求定义

OEM在整车层次进行相关项定义时明确了系统功能和边界，然后进行HARA（危害分析及风险评估），确定安全目标（Safety Goal）及相应ASIL等级。进而制定FSC/FSR和TSC/TSR，提供给供应商作为输入。不同OEM，不同项目提供的安全需求形式可能不同，作为供应商要积极从OEM获取或配合OEM制定明确的安全需求，做好跟踪管理，确保设计检证活动对需求的充分覆盖。

通过对OEM安全需求的解读，制定系统/子系统级的技术安全需求，并分配给硬件即软件组件。对于分配给软件的安全需求，应明确定义以下内容，并记录到软件安全需求文档中。