ASIL B车载ECU功能安全软件开发要点

翟辉

摘  要：随着E/E系统在当代汽车中应用比重的增加，E/E系统的安全问题引起广泛关注，占据E/E系统中主要位置的软件更是成为焦点。ISO国际标准化组织已经颁布了功能安全、信息安全以及预期功能安全（SOTIF）相关的标准ISO26262、ISO21434以及ISO21448。本文结合本公司十几年为欧美OEM供应功能安全相关车载ECU的经验，主要总结针对功能安全ASIL B级车载ECU软件开发的经验。

关键词：功能安全;ISO26262;GB/T34590;车载ECU软件;ASIL B

中图分类号：U461.91     文献标识码：A     文章编号：1005-2550（2021）04-0043-05

Key points of software development for ASIL B automotive ECU

ZHAI Hui

（ ALPS System Integration （Dalian） Co.， Ltd. Dalian 116023， China ）

Abstract： With the increasing proportion of E/E system application in modern automobile， the safety problem of E/E system has aroused widespread concern， and the software occupying the main position in E/E system has become the focus. ISO has issued ISO 26262， ISO 21434 and ISO 21448 on functional safety， information security and intended functional safety. Based on our company's experience in supplying functional safety related on-board ECU for European and American OEMs for more than ten years， this paper mainly summarizes the experience in software development of ASIL B automotive ECU for functional safety.

1    前言

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

2    功能安全软件开发流程

2.1   ASPICE

汽车行业的软件开发基本采用ASPICE（Automotive Software Process Improvement and Capability dEtermination）模型框架，作为研发流程改善及供应商能力评价的标准。该标准是SPICE（ISO15504 ）在汽车行业的应用。多数汽车OEM 要求供应商的软件开发能力要达到Level 3以上。车载ECU供应商一般会基于该标准，在第三方咨询公司的帮助下，结合本公司实际情况建立适合本公司的流程体系，以明确产品开发中的各种活动，活动的输入输出，参与活动的各种角色以及应采用的模板、指南和检查清单等辅助工具。我司 与集团母公司一起早在2006年即基于ASPICE建立了自己的品质管理系统，并在为某欧系OEM的产品开发中取得了Level3的认证。该系统不仅包含了软件开发活动，同时也弥补了ASPICE的不足将系统及硬件开发活动也纳入了该系统。这与功能安全标准的思路一样，从产品开发的整体上明确了流程和技术要求，如图1所示：

2.2   功能安全标准的软件开發要求

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

这些活动从流程上与ASPICE的要求没有本质区别。在技术应用上，功能安全标准针对各活动定义了一些具体的措施。本文结合ISO26262-2018 的最新要求，针对ASIL B的要求对各活动的措施加以说明。

2.2.1 计划阶段应考虑的内容

软件开发项目启动时应考虑采用何种开发手段和方法，例如采用何种开发语言，是否采用基于模型的开发，是否需要遵守MISRA-C标准等。但这些手段和方法不应在项目计划时临时考虑，应该作为组织开发流程的一部分明确定义并作为组织过程资产积累。表1规定了ASIL B需要满足的具体要求。如果组织采用基于模型的开发手段，如MATLAB，Rhapsody等，并建立了统一的建模及命名规范，而且实施规范化的满足MISRA-C的代码解析活动，即可充分满足这些要求。

2.2.2 需求定义

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

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

2.2.3 框架设计

经过需求分析之后，获得了分解的需求点，这些需求点需要部署给某一软件单元来实现。框架设计就是要结合需求点设计软件结构，明确构成软件的单元有哪些。然后在评审阶段充分验证结构及接口的合理性。软件开发组织应建立标准的开发指南，将表3中要求的设计原则转换为明确的设计要求。

车载嵌入式软件的结构会根据是否采用操作系统等SEOOC组件而不同，这在项目企划阶段就应决定，并在采购SEOOC时明确安全级别。在框架设计阶段需根据构成软件的所有组件的安全特性决定是否采用分区（Partition）机制。近几年采用AUTOSAR 分层结构的ECU产品越来越多，在采购AUTOSAR软件包时应注意提前考虑安全相关需求。

另外，安全分析是框架设计阶段的重点工作，具体实施方法可参照本文第3章3.2节的描述。

2.2.4 单元设计及实现

构建完软件框架，进行单元设计时，应遵循表5和表6中的要求。这些要求应转换为设计指南、编码规范中的具体规则，且应用于组织中所有软件开发项目。

此阶段的重点工作是实现软件安全需求以及安全分析后定义的各种安全机制，常用的安全机制可参考本文第3章3.1节的描述。软件单元的具体实现方法与QM级别软件的实现并无本质区别，但采用的工具应满足对应安全级别的工具可信度等级（TCL）要求。

2.2.5 单元验证

在设计单元测试用例时应充分实施等价类划分等方法，并利用Bullseye、TestWell CTC++等覆盖率分析工具检查测试用例的有效性。对于ASIL B需至少满足语句和分支覆盖要求。

本司的单元测试采用CUnit框架，并在模拟环境和目标环境同时实施。

2.2.6 集成验证

集成验证阶段的测试方法包括常规的需求分析，接口测试，同时遵循MISRA-C的代码解析是必要且有效的手段。Helix QAC及CodeSonar这样的工具被广泛使用，一些嵌入式IDE的编译器也支持基本的MISRA规则检查。

另外，ROM、RAM及堆栈使用情况，任务执行时间等需要确认，以确保集成后软件的性能。

具体的用例设计时，等价类划分及边界值测试也是必要手段。

2.2.7 功能验证

供应商的功能验证因为没有整车环境，一般在模拟环境（如HIL硬件在环）下进行。最终整车OEM会在整车环境进行验证。实施功能验证时充分利用组织过程资产中历史问题是重要的手段，避免同类重大问题的再发。用例设计同样采用需求分析及等价类划分这样的常规手段。另外，结合嵌入式软件运行模式及情景（如启动时、诊断时、降级时、掉电时、休眠时、标定时、EOL下线检查时、软件更新时的相关行为）的分析方法也是有效的。

3    软件组件的安全分析及相关故障分析

安全分析及相关故障分析应该在软件架构层面实施。本节将介绍软件组件典型的安全相关的故障，实际ASIL B系统常用的安全机制，以及如何进行安全和相关故障分析。

3.1   软件组件的无干涉设计

引起软件组件间相互干扰，从而违反安全需求的故障有三类，即时序、存储和通信。

3.1.1 时序

时序故障指发生以下问题：

A）执行被阻塞

B）死锁

C）活锁

D）执行时间错误

E）同步错误

可以采用的安全机制包括周期性调度，固定优先级调度，时间触发调度，执行时间监视，程序顺序监视及到达率监视等。

针对ASIL B系统，常通过窗口型看门狗、时钟监视、任务时间监视等设计实现上述安全机制。

3.1.2 存储

存储故障指发生以下问题：

A）内容损坏

B）数据不一致（如数据更新过程中被读取）

C）堆栈溢出

D）对其他软件组件存储区读写访问

可以采用的安全机制包括存储包含，奇偶校验，错误纠正码（ECC），错误检查码（EDC），循环冗余校验（CRC），冗余保存，存储区訪问限制，静态解析，静态分配等。

针对ASIL B系统，常通过堆栈上下溢出监视、RAM/ROM ECC/EDC、关键模块或数据的同质/异质冗余等设计来实现上述安全机制。

3.1.3 通信

通信故障指发生以下问题：

A）信息重复

B）信息丢失

C）信息延迟

D）信息插入

E）信息伪装

F）信息的不正确寻址

G）信息次序不正确

H）信息损坏

I）从发送方传送到多个接收方的信息不对称

J）发送方发送的信息只能被部分接收方接收

K）通信信道阻塞

针对ASIL B系统，常通过数据ID、Alive/Sequence counter、CRC、超时判断等设计来实现上述安全机制。AUTOSAR已经将这些设计进行了明确定义且广泛被整车OEM采用，可参考文献[3]。

另外，不同的通信协议（如LIN/CAN等）本身，会有信息回读、基于优先级的仲裁等机制，同样可以作为保证安全的手段使用。

3.2   FMEA与HAZOP结合

上一节我们明确了软件组件的故障种类，本节将说明如何分析软件是否会发生这些故障。

软件框架设计阶段，构建好构成软件的单元之后，会针对每个单元是否能够实现安全需求以及是否会发生这些故障进行分析。业界几乎都采用FMEA和HAZOP引导词相结合的方式同时进行安全分析和相關故障分析。

FMEA的模板一般采用表格的形式，其中一般需包含以下内容：

常见的HAZOP引导词包括：

借助这些引导词的提示，激发想象思维，通过提问过程，识别软件单元中的故障。各组织可以根据自己的业务特性构建适用于自己的引导词。

分析的具体步骤如下：

①框架设计构建出软件单元;

②针对每个单元，借助引导词，识别故障模式;

③确认该故障模式是否违反安全需求（如不违反则该单元的分析结束）;

④分析每个故障的可能原因;

⑤针对每个原因，从流程、软件及硬件角度导出对策;

⑥如有必要更新安全需求;

4    结束语

本文结合本公司的经验，描述了安全相关车载嵌入式软件的一般开发流程，介绍了软件组件间相互干扰的主要故障类型，重点说明了ASIL B软件常用的安全机制，并简单说明了安全分析和相关故障分析的方法和步骤。希望对安全相关车载软件开发提供些许参考。

参考文献：

[1]GB/T 34590.3-2017道路车辆 功能安全 第6部分：产品开发：软件层面.

[2]ISO 26262.6-2011， Road vehicles — Functional safety —Part 6： Product development at the software level.

[3]ISO 26262.6-2018， Road vehicles — Functional safety —Part 6： Product development at the software level.

[4]AUTOSAR Specification of SW-C End-to-End Communication Protection Library AUTOSAR_SWS_ E2ELibrary.

[5]E2E Protocol Specification， AUTOSAR FO Release 1.5.1.

翟   辉

工学硕士，现就职于阿尔卑斯系统集成（大连）有限公司，任主任工程师，主要研究方向为车载嵌入式软件开发，从事车载嵌入式软件开发工作已有14年。