面向汽车自动驾驶安全软件的开发流程*

吕颖 厉健峰 杨斯琦 董小瑜

（1.中国第一汽车股份有限公司智能网联开发院，长春130013；2.汽车振动噪声与安全控制综合技术国家重点实验室，长春130013）

主题词：ASPICE 敏捷开发 预期功能安全 软件开发流程 自动驾驶

缩略语

SOTIF Safety Of The Intended Functionality

ASPICE Automotive Software Process Improvement and Capacity Determination

CMMI Capability Maturity Model Integration

ASD Adaptive Software Development

FTA Fault Tree Analysis

HiL Hardware in the Loop

1 引言

自动驾驶汽车开发越来越重视性能、质量和性价比，自动驾驶口碑成为新技术应用取得市场成功的关键，而口碑的建立依赖于相关软件开发流程、周期、时间和质量。一家汽车企业只有拥有或者其软件开发供应商具有成熟的软件开发团队、软件开发流程、可复用的软件流程资源库，才能在日益激烈的自动驾驶产业竞争中获得一席之地[1]。

目前，国际上应用于汽车行业的软件开发成熟度评估标准主要有能力成熟度模型集成（Capability Ma⁃turity Model Integration,CMMI）和汽车软件过程改进及能力评定模型框架（Automotive Software Process Im⁃provement and Capacity Determination,ASPICE）[2]。CMMI拥有全球公认的软件、产品和系统开发优良实践过程改进模型，能够帮助组织提升绩效，具有普适性，而ASPICE标准基于软件过程评估国际标准ISO 15504，主要针对汽车行业软件开发过程框架，是现今汽车企业主要依据的过程评估标准。与典型传统软件开发过程，例如线性瀑布模型相比，以V开发模式为导向的ASPICE软件过程域[3]，从客户需求、系统架构、软件需求、软件架构、软件详细设计、单元构建到测试验证之间都存在一致性与双向追溯性关系，从最初的系统需求分析开始，测试人员就参与进行对应验证标准的设计，将设计和测试在项目开始初期就关联起来，在整个软件开发生命周期都有着重要的指导意义[4]。

传统软件开发重视业务过程和文档，若软件开发人员完全按照设计文档进行程序开发，经过很长的开发周期后提交软件程序，会导致早期错误可能要等到开发过程后期才能发现，风险与修正成本不可控制[5]。敏捷软件开发模式强调沟通[6]，通过各子项目的集成和运行，构建成上层软件项目，软件开发成员拥有充分的自主权，可自行寻找最佳工作方式完成工作，不必拘泥于设计文档。开发过程循环迭代，开发人员针对前期需求，尽可能早地提交一个完整可独立运行的源程序，供测试验证，发现问题后提出需求变更请求，开发人员再次按照新需求开发并提交源程序，如此循环直至软件从整体构架至各个细节完全符合需求，从而实现完美的人机结合[7-8]。

敏捷方法主要包括：Scrum方法[9]，自适应软件开发(Adaptive Software Development，ASD)，水晶方法，以及最重要的极限编程（eXtreme Programming，XP)。Scrum偏重于过程，XP则偏重于实践，实际开发中，两者经常结合一起应用。

由于汽车自动驾驶软件的复杂性与专业性，一味遵循敏捷开发，专注市场变化和客户反馈，会对整个软件的架构、开发、测试造成很大的波动。控制不好，会使得项目失控，造成严重的质量问题，比如Bug多，架构不合理，易用性差，性能不佳等。除此之外，汽车软件项目开发周期很长，很难保证开发的人员不更换，而没有规范体系文档就会造成在交接的过程中出现很大的困难。因此，采取有效方法保证过程质量，对于提高产品质量具有十分重要的意义[10-11]。

为满足自动驾驶车辆的安全性需求，根据ISO PAS 21448标准[12]，智能驾驶系统本身传感器/控制器/执行器的设计不足、性能局限在遇到一定的场景触发条件（如环境干扰或人员误用）时，将可能导致整车级失效危害，进而威胁人身安全。究其根本，应在软件开发阶段充分降低预期功能安全SOTIF危害事件的潜在风险、提高软件安全性能、明确安全边界。因此，本文在结合传统与敏捷开发流程基础上，融入SOTIF对部件软件层级的安全需求与测试验证，合理控制软件已知/未知风险，开发自动驾驶软件流程，促进自动驾驶车辆系统安全提升和顺利发布。

2 汽车安全软件开发流程定义

设计智能驾驶软件产品开发流程[13-14]如图1所示。主要由8个阶段构成，即包括软件需求分析、软件架构设计、软件敏捷设计、软件详细设计和单元构建、软件单元验证、软件敏捷集成、软件集成和集成测试及软件合格性测试。增加软件敏捷设计与集成活动，以应对实际软件开发项目中开发周期短，软件需求预开发架构的问题[15-16]。

图1 汽车自动驾驶安全软件开发流程

第1阶段（Step-01），软件需求分析：

主要工作内容：根据项目目标与计划，承接系统需求，SOTIF危害分析与项目内各专业确认软件需求，进行需求评审。

第2阶段（Step-02），软件架构设计：

主要工作内容：识别软件需求，形成软件架构设计说明，并进行软件架构设计评审。

第3阶段（Step-03），软件敏捷设计：

主要工作内容：识别软件敏捷设计需求，形成软件敏捷设计说明与计划，并进行软件敏捷设计评审。

第4阶段（Step-04），软件详细设计和单元构建：

主要工作内容：结合敏捷设计需求，根据软件需求和软件架构定义软件详细设计，包括任务设置、调度机制、优先级、时序、函数接口关系、数据定义、算法策略说明，根据软件详细设计进行软件单元构建工作，并进行软件详细设计和单元构建评审。

第5阶段（Step-05），软件单元验证：

主要工作内容：完成静态检查，编写软件单元测试需求文档、测试用例，自动或手动进行单元测试工作，并进行软件单元测试评审。

第6阶段（Step-06），软件敏捷集成：

主要工作内容：完成软件敏捷集成计划，形成软件敏捷集成说明，并进行软件敏捷集成评审。

第7阶段（Step-07），软件集成和集成测试：

主要工作内容：按照集成计划，完成软件单元集成，编写软件集成测试需求文档，自动或手动进行集成测试工作，并进行软件集成和集成测试评审。

第8阶段（Step-08），软件合格性测试：

主要工作内容：根据软件需求进行软件合格性测试，并进行软件合格性测试评审。

体现SOTIF分析与开发过程，具体开发活动如图2所示。

图2 汽车自动驾驶安全软件开发过程

3 汽车安全软件开发流程特点

3.1 双向追溯性

本软件开发过程体系具有ASPICE双向追溯[17]的特点：

（1）纵向/横向双向追溯性

从上到下的追溯，便于确认是否所有需求都执行；从左到右的追溯，便于确认是否所有需求都被测试；从下到上的追溯，便于发现哪些需求被错误的执行或曲解；从右到左的追溯，通过测试的过程发现问题或者缺陷来源于哪个需求。

（2）需求变更定位

在出现新的需求或者需求变更时，通过快速追溯便于V模型从上到下、从左到右准确的定位，发现从设计到测试整个工程开发中不同阶段需求变更具体位置。

（3）评估评审

通过需求的纵向和横向的追溯就可以知道该项目是否严格按照ASPICE标准流程执行开发过程。

3.2 敏捷开发与集成

将敏捷开发过程融入软件开发端与软件测试端[18-19]，软件敏捷集成与软件敏捷设计过程同样具有双向追溯性，并强调以下关键实践：

（1）以人为核心

敏捷开发注重人员与沟通，只有软件开发人员与业务人员达到事件的敏捷处理，整个软件开发过程才能实现敏捷化。

（2）迭代—增量开发

整个软件的开发过程通过迭代式开发分成若干阶段，开发人员根据优先级或风险高低选择需求，对程序进行增量的设计和开发。每次迭代完成对应一个经过测试的最终产品，开发团队通过它获得更多反馈，再继续完善软件产品。

（3）测试驱动开发

基本思想就是在明确要开发某个功能和在开发功能代码之前，先编写测试用例，思考如何进行功能测试，然后编写相关的代码满足这些测试用例，循环进行功能添加。直到完成全部功能开发。

（4）持续集成

持续集成的主要思路是为了增加集成测试效率，将软件开发过程后期的软件集成分摊到软件的全过程灵活进行。

3.3 软件层SOTIF开发

在软件设计与测试阶段，同步进行SOTIF开发活动，对软件开发起到安全约束的作用[20-21]，对应以下5项活动：

（1）识别和评估SOTIF潜在功能不足和触发条件

通过规范与设计文档的支撑，进一步确认软件设计不足及性能限制、人员误用等及其触发条件。利用FTA故障树分析得出导致软件层面上SOTIF相关整车级危害触发条件，包含感知模块、算法决策模块、执行模块及人员的合理可预见的误用。确认触发条件对SOTIF的可接受性，评审评估严重度（S）、可控性（C）以及触发条件的概率是否满足制定的可接受标准。

（2）功能修改以减少SOTIF相关风险

通过已分析得到的软件层级的设计不足及性能限制之处，制定针对SOTIF相关危害的改善措施，包含功能目标的更改、软件设计限制、改进和降级。将改善措施更新进入规范与设计文档。如果仍不能充分降低安全风险，需要定义接受准则并考虑相应的法规、该功能在目标市场的情况、人员暴露在风险下的可接受性。

（3）定义验证和确认策略

SOTIF的验证和确认过程主要是对未知的不安全场景和已知的不安全场景进行探测和转化的过程，针对软件系统提出验证与确认的要求。制定针对已识别SOTIF相关危害的验证策略，及针对残余风险的确认策略，编写集成测试规范，并说明所选验证和确认方法的基本原理。

（4）验证已知危害场景

针对已识别的SOTIF相关危害场景，基于所选的验证方法，对软件算法进行模拟仿真验证或硬件在环（HiL）验证，并进行集成测试，最终出具危害场景的验证报告。

（5）验证未知危害场景

为评估未知危害场景下的潜在风险，应设计测试用例进行风险测试，识别系统设计可能触发危险的运行情况，减少未知危险区域，以验证目标是否满足安全接受准则为评判依据。

4 应用实践

随着我国汽车企业智能驾驶产品逐步的自主化，由于缺乏经验，软件团队在实际项目开发中曾暴露出多项问题与流程漏洞，以往车型项目中存在过系统方案选型不合理，缺乏有效评审评估，导致系统方案选型与主流方案存在偏差，导致开发后期无法闭环控制，产生空间车位泊车精度不足等系列问题，项目后期难以解决。特别是由于软件开发系统功能需求规范不完善，在软件开发过程中反复修改需求，导致软件开发效率不高的问题。通过该流程的制定与实施，健全整个软件项目开发测试团队的软件开发流程体系，开展软件开发过程管控，完善软件质量管理和微流程规范化工作，制定软件开发规范和要求文档模板40个，严控评审把关，有效保证软件开发各个环节的规范化与标准化，质量问题明显减少，效率明显提升。

通过该流程实施解决AEB自动刹车辅助系统潜在危害的过程举例如下：

（1）潜在的交通状况：

在交通拥堵的路上行驶（如郊区道路）。

（2）潜在危害：

非预期的紧急制动可能致使与后面的车相撞。

驾驶员对危害不可控。后车驾驶员对危害的控制取决于两车之间的距离。

（3）触发事件：

特殊道路条件（如：井盖，管道，饮料罐）可能会生成雷达回波，有可能被理解为潜在障碍物。

不必要的紧急制动引发的后侧碰撞需要降低严重度，此SOTIF相关风险不可接受。为降低后碰的严重度，功能改进方向为对限制制动介入的时长或强度。

（4）改善后的功能描述：

该功能使用雷达传感器扫描前方障碍物的距离。若检测到即将到来的碰撞，则AEB将会触发。限制制动介入以减少或防止不需要的紧急制动带来的碰撞。

5 结束语

本文结合ASPICE过程模型与敏捷开发的各自优势，考虑了SOTIF安全需求，减少了危害事件，提出了一种融入软件敏捷开发环节的软件开发流程，兼顾了传统汽车软件开发控制、流程、文档和评审的方法，与敏捷开发的灵活主动、快速迭代的特性，以及安全约束。新制定的面向自动驾驶安全软件开发流程是在传统汽车软件开发过程基础上的一种改进和优化，合理平衡软件开发活动，实际项目实施效果证明了新开发的软件流程的有效性，对后续汽车自动驾驶安全软件的开发具有指导意义。