浅谈智驾软件的ASPICE开发流程
[TOC]
ASPICE在目前汽车智能驾驶软件的开发中很火,几乎成为汽车行业的通用标准和准则.本文浅谈一下ASPICE是什么,其意义,基本内容,以及算法/功能开发工程师需要关心的点,后面会追更更多心得.本文的内容糅合了很多个人在实践中的感悟,因此可能与标准文档内容有差别,希望大家先看官方文档注意甄别.
ASPICE是什么?
ASPICE的全称是Automotive SPICE,是由SPICE发展而来.而SPICE是由国际标准化组织ISO,国际电工委员会IEC,信息技术委员会JTC1发起制定的ISO15504标准.其项目名为”软件过程改进和能力测定”(Software Process Improvement and Capability dEtermination),简称SPICE.ASPICE的官方文档下载地址,有中文版.
ASPICE的发展历史如下图:
意义
目前我的岗位是算法开发工程师,因此它的意义主要是从这个岗位的角度来看的.
- 明确职责分工
智能驾驶软件的实现是个较大的工程,单靠几个人的小团队是很难实现复杂且困难的整个过程,因此需要多部门多团队甚至多公司的配合才能完成.人多起来,每个人每个岗位的职责以及每个岗位在什么时间完成什么交付物都需要有个依据,这个依据便是流程.在日产本部工作的两年时间里,接触的最多的便是开发流程,即日产的V-3P开发流程,配合上按照功能/零件域的组织架构,让每个人都成为很容易被替代的螺丝钉,当然做好一个优秀最后甚至不可替代的螺丝钉也不是一件容易的事情.但对于工程化,量产化的开发而言,流程能减少因为人员变动,公司管理效率,沟通效率,供应链管理效率等问题导致的成本提升,并且明确的上下游交付以及时间节点的合理制定也保证了量产产品的质量.从个人的角度而言,干确定边界的事情,总是令人心安的(干超出边界的事情则会带来成长的成就感以及…人缘),也减少了推卸责任扯皮消耗的情绪成本.同时可以在某个方向上深入研究提升自己的不可替代性.同样地理解其他环节的职责也有助于项目的协调前进.
- 输入与质量依据
试想一下如果有人告诉你开发一个俄罗斯方块游戏,只在口头告诉你大概交付给你的用户界面与功能,你要怎么实现它,并且保证实现的质量？写代码之前,我们肯定要确定很多东西,游戏跑在什么硬件上,人机交互怎么实现的(延迟之类的),有没有其他软件功能,实现什么样的特效,谁来验证游戏,毕竟你只是写代码的,最终的游戏效果还有其他很多因素能决定.口头上的东西,事一多就会印象混乱,到时候谁对谁错就说不准了.这些都是通过流程里的每个环节的输入输出文档以及验证文档来实现的.闭着眼睛就写代码的结果可能是要推倒重来N多次才能开发出来Boss/用户满意的产品.这个过程会多痛苦不言而喻.有了流程的明确规定,开发工程师就有源头,不再是瞎试.
- 知道自己应该获得哪些资源
这个主要是通过对其他环节的了解得到的.例如,需要仿真验证算法,仅仅进行代码的单元测试甚至是SIL(软件在环测试)是肯定不够的,硬件平台与传感器的差异会让许多bug无法复现.但是仿真验证以及最终的实车验证的环境搭建,完善与提升也是一门很大的学问与艺术,算法开发是没有如此多的精力实现.这个时候就需要专门的岗位完成这些,供算法开发实现代码更多的验证.同时,传感器的软件的更新刷写,物料的协调等工作也需要项目管理或者是供应商管理的同事提供协助.虽然用资源这个说法有些自私,但对于完成一项工作而言这也是必须的.
- 认定的公信力加成
从外部来看,算法没法评价毕竟代码是不能公开的,能评价的只有最终展现给用户的功能.ASPICE作为业界内认可度比较高的标准,得到其较高的评价标准也往往意味着质量的基础以及整体开发过程的透明,确定,稳定,经济.这从侧面认定了算法.
- 回溯与重构
试想一下,你正在开发的某项功能突然要改动,因为竞争对手企业用另一种思路实现获得了巨大成功,如何改？如果流程运转地到位,就像git 一样,每个环节都有迹可循回溯到某个 commit 上重开一个branch即可.而不是混乱与冲突.
- 方便与与整车其他部分的开发流程配合
整车的开发一般同样是基于V型模型进行开发的.这样不管是从人员职责的配合还是项目日程的配合都会容易很多.如下图所示,可以很方便地与机械工程,硬件工程等流程很好地配合(官方称插件式地).
- 至于从其他角色/更高维度来看的益处就不越俎代庖了
缺点,如果所有的流程,肯定都是死板,容易僵化的,例如车上检查一根线的情况,按照经验能独立解决的情况下,测试工程师非要等到供应商确认(只是举例没有贬低测试工程师的意思).
所以在ASPICE流程的基础上使用技术手段来打通僵化,串联各端,通过提供趁手的,可视化性强的工具与理念加速ASPICE流程的一轮轮地推进的想法很重要.
这就涉及到DevOps的思维了.后面有机会展开讲.
基本内容
ASPICE包含两部分：过程评估模型与过程参考模型.
过程评估模型关系如下图:
使用过程评估模型来确定过程能力的概念是基于一个二维框架.第一个维度是由过程参考模型(过程维度)定义的过程来提供.第二个维度是由进一步细分到过程属性的能力等级(能力维度)所构成.过程属性提供了过程能力可度量的特性.本文不展开讲.
下图是过程参考模型,核心在于由系统过程组与软件工程组构成的V型开发模型.流程是从SYS.1环节开始逐级设计实现然后由V字右侧的验证测试环节验证设计直到SYS.5环节.
下图为对应设计与验证的V字图细节:
ASPICE强调一致性和双向可追溯性也就是说不仅要满足上游们的输入还要保证双方能够实现互相对应,追溯验证.
算法/功能开发
算法/功能开发在V字模型中需要完成的环节为SWE.3软件详细设计和单元构建,SWE.4软件单元验证.需要满足的上游输入是SWE.1软件需求分析,SWE.2软件架构设计.先看输入.
输入
- SWE.1软件需求分析
软件需求分析过程的目的是:将系统需求中与软件相关的部分转化为一组软件需求.
结果是:
- 定义了系统中分配给软件要素的软件需求及其接口；
- 将软件需求进行分类,并分析了其正确性和可验证性；
- 分析了软件需求对运行环境的影响；
- 定义了软件需求实现的优先级；
- 根据需要更新了软件需求；
- 在系统需求与软件需求之间,在系统架构设计与软件需求之间建立了一致性和双向可追溯性；
- 从成本,进度和技术影响来评估软件需求；
- 约定了软件需求,并与所有受影响方沟通.
总结来看对算法开发而言,软件需求分析应该正确地把系统需求转化为软件需求,很好地分类,定义优先级,保证可验证性可行性,并且如果算法开发有反馈,软件需求需要与之沟通并保持更新的可能性.
软件需求需要充分理解系统架构与需求,在了解软件能力边界的基础上实现功能的映射,需要较强的大局观.
- SWE.2软件架构设计
软件架构设计过程的目的是: 建立软件架构设计,识别将哪些软件需求分配 给软件的哪些要素,并依照定义的准则来评估软件架构设计.
结果是:
- 定义了识别软件要素的软件架构设计；
- 软件需求分配给软件的要素 ；
- 定义了每个软件要素的接口 ；
- 定义了软件要素的动态行为和资源消耗目标；
- 建立了软件需求与软件架构设计之间的一致性和双向可追溯性 ；
- 约定了软件架构设计,并与所有受影响方沟通.
总结来看对算法开发而言,软件架构需要定义软件要素(例如runnable,进程等),接口,动态行为(运行周期,程序调度,异常处理,故障诊断等),资源消耗目标(CPU占用率,内存占用率,线程数目等),保持更新的沟通.
同时如果结合常用的汽车ECU软件AUTOSAR架构以及嵌入式RTOS的操作系统甚至汽车电气架构的特点,我觉得软件架构是个非常具有挑战性的工作,需要完成的工作非常多,并且对不仅对算法(区分要素,安排资源)要非常熟悉还要熟悉操作系统,嵌入式等很多方面的知识.
本职
SWE.3软件详细设计和单元构建
软件详细设计和单元构建过程的目的是：为软件组件提供经过评估的详细设计,并定义和生成软件单元.
结果是:
- 开发了描述软件单元的详细设计；
- 定义了各软件单元的接口；
- 定义了软件单元的动态行为；
- 建立了软件需求与软件单元之间的一致性和双向可追溯性；建立了软件架构设计与软件详细设计之间的一致性和双向可追溯性；建立了软件详细设计与软件单元之间一致性和双向可追溯性；
- 约定了软件详细设计及该设计与软件架构设计的关系,并和所有受影响方沟通；
- 生成了软件详细设计所定义的软件单元.
输出工作产品:
- 软件详细设计 → [成果 1, 2, 3]
- 软件单元 → [成果 6]
- 沟通记录 → [成果 5]
- 评审记录 → [成果 4]
SWE.4软件单元验证
软件单元验证过程的目的是：验证软件单元,以提供软件单元符合软件详细设计和非功能性软件需求的证据.
结果是:
- 制订了包括回归策略在内的软件单元验证策略,以验证软件单元；
- 根据软件单元验证策略,制订了软件单元验证准则,以适于提供软件单元符合软件详细设计及非功能性软件需求的证据；
- 根据软件单元验证策略及软件单元验证准则,验证了软件单元并记录了结果；
- 建立了软件单元,验证准则及验证结果之间的双向可追溯性和一致性；
- 总结了单元验证结果,并与所有受影响方沟通.
输出工作产品：
- 测试规范 → [成果 2]
- 测试计划 → [成果 1]
- 沟通记录 → [成果 5]
- 评审记录 → [成果 3, 4]
- 追溯记录 → [成果 4]
- 验证结果 → [成果 3, 5]
- 测试结果 → [成果 3, 5]
- 分析报告 → [成果 3]
这里可以看到单元测试阶段需要输出的文档还是比较多的.这里的验证策略还是非常考验算法工程师的软件工程能力的.能用最合适的测试框架,最效率的测试用例还是非常具有挑战性的.
其他感触TBC.
浅谈智驾软件的ASPICE开发流程