基于ASPICE与ISO26262标准融合的汽车软件开发过程研究

本文基于Aspice模型中V流程开发模式，从汽车控制系统的需求分析、架构设计、软硬件需求分析、代码/模型开发实现、系统测试及验证整个V模型各阶段，结合ISO 26262功能安全标准在各阶段的要求，提出一种Aspice与ISO 26262相融合的汽车控制系统开发流程，并结合实践开展过程，阐明各开发过程使用的开发工具配置情况。

【资料图】

随着汽车行业电动化、智能化、网联化的发展以及客户对整车舒适性及安全性要求日益提高，整车上电子电气系统数量也随着增多。在软件定义汽车大背景下，整车上电子电气系统的开发过程和品质保证过程都应有相关的标准和流程作为风向标，国际和国家标准化组织陆续制定颁布相关功能安全标准ISO 26262及GB/T34590。截至目前国内有部分软件企业已经按照Aspice模型这一专门针对汽车软件开发的规范及实践来指导汽车软件开发[1]。但近年来由于车辆中嵌入式电子系统复杂性的增加，来自于软件系统损坏以及随机硬件损坏的风险也在日渐上升，将ISO 26262的功能安全规范要求纳入车辆软件开发过程中，也能改善车辆系统软件开发产品品质、开发工作效率，提升产品开发过程的稳定性。因此本文基于Aspice模型中V流程开发模式，从汽车控制系统的技术需求分析、架构设计、软硬件需求分解、代码/模型设计及实现、测试验证等各阶段，结合ISO 26262标准对各阶段的开发要求，提出一种多标准相融合的汽车控制系统开发流程，同时结合工程实践，阐明各阶段使用的开发工具配置情况。

一、Aspice简介及软件开发流程

1.1 Aspice简介

SPICE是Software Process Improvement and Capability Determination的缩写简称，是由ISO、IEC、JTC这3家国际机构共同提出的标准，根据此标准，行业分别派生出了各种更具体的规范，包括医药设备领域制订的Medi SPICE、航天领域制订的SPICE for SPACE，而汽车行业建立了Automotive SPICE，即Aspice[2]。Aspice是汽车行业开展软件产品研发过程的最佳模型，用以衡量汽车软件开发组织的开发实力和组织流程的管理能力，指导汽车软件开发团队开展软件开发，从而改善软件品质和提高开发效率。

1.2 Aspice软件开发流程

Aspice作为汽车行业软件开发过程最佳模型，规定了V开发流程和支持过程各阶段开展的研发内容及输入输出交付规定，如图1所示。

图1 V模型流程

二、ISO 26262软件开发流程

ISO 26262适用对象是道路车辆的功能安全，对产品项目的安全管理、产品开发、生产、运行、服务、报废、支持过程整个生命周期明确了要求。其中产品开发包括系统层级、软件层级、硬件层级三方面。功能安全开发流程总览如图2所示，产品开发的系统、硬件和软件的研发过程如图3所示[3]。

图2 ISO 26262标准概览

图3 产品开发系统、软硬件要求

三、Aspice和ISO 26262融合的开发研究

结合Aspice与ISO 26262功能安全的要求，将产品开发各阶段进行融合研究，并将各层面技术要求结合工程实践进行阐述，融合的产品开发框架如图4所示。各阶段开发工作描述如下。

图4 Aspice与ISO26262相融合的产品开发框架

1）概念设计。概念设计阶段确定干系人要求，并确认这种要求可以被正确理解，同时对相关项目做出界定，辨识由相关项目中的功能异常表现导致的危险事项，提出避免危险事项出现和降低危险程度的安全目标并确定基于关联项目的可能危险事项，对关联项目做出评价。对重大危险事项实施系统性评价，并明确了安全目标以及ASIL级别。其中，危险辨识与危险性的评价可采用FMEA、HAZOP、头脑风暴等方式，而ASIL级别则按照严重程度、暴露机率与可控性等三种原因设定，三因素级别详见表1~表3。根据安全目标分解出相应ASIL等级的安全需求，此阶段输出相关项定义、HARA分析报告及干系人需求说明书，其中干系人需求说明书涵盖安全需求。干系人需求通过需求管理工具PTC Integrity进行需求记录，同时管理需求状态及实现情况。

表1 严重度等级

表2 关于运行场景的暴露概率等级

表3 可控性等级

2）技术需求分析。技术需求分析阶段需根据干系人需求说明书进行需求分析，将干系人需求和安全需求分解成技术需求、定义安全机制，用于探测故障并防止或减轻出现在系统输出端的违反功能安全要求的失效，形成系统需求和建立系统架构。在系统需求分析过程中，对需求进行分类分析，明确功能需求、非功能需求和接口需求，组织专家评审并确定需求的正确性和可验证性；对系统需求的优先级进行分析，明确系统需求实现的顺序；同时建立客户需求和系统需求的双向追踪关系。系统架构建立后将安全要求分配给系统的各要素，进行需求安全等级分解，明确各条目需求的ASIL等级。同时对子系统进行安全分析，避免系统性失效。技术需求分析方法采用结构分析法，从系统顶层向下设计、逐层分解设计，明确系统各组件之间的程序流和数据流。此阶段输出系统需求、系统架构及系统独立失效分析报告。其中系统架构安全设计分析方法参见表4。架构设计采用ENTERPRISE ARCHITECT。

表4 系统架构设计分析

3）软硬件需求分析。软硬件需求分析阶段将系统需求和安全需求分别转变为硬件需求、软件需求。在软件需求分析过程中，分析软件需求之间的依赖关系，保证需求的正确性、技术可行性及可验证性；同时构建与系统需求的一致性和可追溯性。根据相应的软硬件需求，开发满足软硬件安全要求和其他软硬件要求的软件架构设计和硬件架构设计，指导软硬件的详细设计开发，同时对软件架构进行安全分析。此阶段输出软件需求、硬件需求、软件架构及架构安全分析报告。其中软件架构和硬件架构设计原则见表5和表6。软硬件需求记录、分析及状态跟踪通过PTC Integrity。

表5 软件架构设计原则

表6 硬件架构设计原则

4）详细设计及代码开发。详细设计及代码开发阶段将根据软硬件需求进行硬件设计、软件详细设计、代码开发，其中代码设计遵循原则见表7。代码开发时利用模块化设计思路，将程序软件划分成独立子功能的模块，然后将模块集成形成整体软件程序，从而满足客户的需求。代码和模型开发采用MATLAB/Simulink。

表7 软件单元设计和实现的设计原则

5）单元测试及硬件调试。定义软件单元测试规范，明确单元测试的技术和方法，制定单元测试验证计划模板及测试报告模板。软件单元测试包括静态测试和动态测试，静态测试主要是对代码静态分析和模型代码审核，代码静态分析借助常用工具，如Model Analysis、QAC。而模型代码审核依据则是由专家已编写的代码或模型Checklist。动态测试前为设计测试案例，即基于设计说明或设计模型期望输入输出信号，测试案例设计过程根据需求分析、等价类的生成和分析、边界值分析、经验等进行开展，测试类型主要包括基于需求的试验、接口测试、故障注入试验和背靠背的试验等，并在此阶段输出单元测试报告。硬件调试阶段包括对硬件模块实施调试，并按照调试清单进行调试，其中调试清单中的项目和模块均由硬件设计相关专家编写，最后产出硬件调试报告。

6）集成及测试验证。将各应用层和基础层模型及代码集成嵌入式软件，根据软件架构设计说明进行集成测试。集成测试通过后，根据软件需求开展嵌入式软件功能测试，输出嵌入式软件测试报告。根据系统需求编写系统测试用例，编制系统测试计划，通过HILL台架或者发动机试验台架开展系统测试，输出系统测试报告。根据客户需求编写整车验证用例，编制整车验证计划，利用整车资源开展整车验证，输出整车验证报告。其中测试验证方法见表8。

表8 测试验证

四、结束语

目前汽车控制系统研发过程中，Aspice模型在实际应用中具有重要的价值，将ISO 26262功能安全标准的要求融入Aspice汽车软件开发流程中，并以此指导汽车软件开发实践，会大幅改善汽车软件开发品质、开发效率以及提高产品的安全性。

参考文献