在汽车行业的嵌入式软件开发怎么确保很低的bug发生率?

本人现在主要从事量产ECU软件的测试和维护工作,正常的开发流程是按照具体功能变更的点按照V模型做测试,因为我们现在主要做功能增加和变更,实际代码量很小。我的问题是在ECU软件开发从0到1的阶段,或者说代码量比较大的阶段是如何做测试的呢?同时国内现在很多公司开始做新能源汽车他们是怎么做测试的呢?会按照流程严格执行吗?
一个kebab   (常驻欧洲,去过30个国家)     512018-09-02 21:56:52

目前在软件开发中保证软件质量,包括保证低bug发生率的最佳解决方案,就是遵照ASPICE Level3 的质量标准来制定软件开发流程。

Automotive SPICE的具体内容可以参考以下文档:

automotivespice.com/fil

目前以我的经验来看,全球范围内在ASPICE流程应用上做得最好的是德系厂商,德国人的死板可能也就在这里最有用了。之后鱼龙混杂的是美国厂商和欧洲其他厂商,一些比较差的所谓的“老牌欧美车企”在流程上实话说还不如我们领先的自主车企。

最后在流程上进步最快的是国内的自主车企。大概五年前当我首次参与和国内主机厂合作的时候他们还完全没有流程的概念,讲究的只是短期的研发成本和时间,什么软件版本管理,软件变更管理只是单靠邮件和本地文件编号。

而五年后的今天,最近和一些主机厂的管理层聊过,他们现在专门设立了软件流程管理的专家职位和对应的流程工程师团队,支付百万年薪招人来建立遵循ASPICE标准的软件开发流程。


ASPICE的标准本身读起来会和ISO 26262一样晦涩,关键流程遍布在V模型从左到右,从设计到测试再到项目支持的所有角落。Automotive SPICE告诉了你他的审核标准,也就是告诉车企应该实现什么样的V模型,展现的是一张最终效果图。但是和ISO 26262一样SPICE没有告诉你的是这些流程具体是什么样的,也就是怎么实现的问题。这也是为什么不同的车企,有类似的V模型构架,根据SPICE的要求,但是构架中的流程以及流程管理方法却不尽相同。

截取自ASPICE标准

我个人总结了一下,应用的时候简略来说只需要记住三个分解之后的V模型。

一个是遵循ASPICE的组织构架上的“倒V"

如果要满足ASPICE Level3的要求,我们不仅要有一套完整的软件开发流程,还必须有这个流程的监督者和流程的管理者。

  • PM和PM所领导的所有软件工程师将是这个流程的使用者,会将所有相关的流程,比如Concern&Change Mangement, Configuration Management 从始至终应用在项目中。
  • QM和QM所领导的QA将是这个流程的监督者,他们将会监督是否小到每个软件的变更到每版可以用于公共道路测试的软件都是按照相关的流程来严格实现的。比如是否有对应的软件修改分析文档,是否有具体的修改细节记录,是否有对应的测试报告,是否有具体的版本追溯,是否和需求闭环,是否有层层Review。在整车开发中每次过”质量门“的时候都是QM和QA集中检查流程应用是否合规的重要节点。
  • Process manager和Process Engineer将是整个流程的制定和维护者。满足ASPICE Level3要求的流程不仅需要有流程本身,还需要有一个管理流程的流程(是不是听起来很拗口)。这就需要有一个专门管理软件开发流程的部门,负责制定一套管理流程的方法论。比如如何改进流程,如何接收流程使用者PM和流程监督者QM的反馈。

第二个V也是ASPICE软件开发流程中最重要的部分,就是具体可以被应用在软件开发过程中的每个细分"流程”:

可以是每个软件开发步骤需要遵循的指导文档,也可以是软件开发每个步骤会用到的模板。

上图中我举例了一下流程,比如:

我们用的最多的流程是软件修改流程。

在任何一个或大或小的软件修改或者新软件的编写过程中我们都必须经过关键的几步:软件修改前的分析(会用到具体的分析文档) ---> 是否进行软件修改的决策(会有具体的决策者定义和具体的审批流程) ----> 软件修改流程 (会有具体的基于模型设计的语法规范,以及具体的Review模板) ----> 软件修改之后的测试流程(会有具体的测试步骤,每个测试结束需要使用的测试报告模板),等等。。。

上面提到的这个,只是众多流程中的一个非常细小的部分。


第三个V,也是最为“技术”的一部分,就是和上面第二个V搭配的各种软件工具。

我们会在软件开发流程中定义具体每一步需要使用哪些工具,生成具体哪些内容。

  • 在软件开发的初始阶段,我们需要使用DOORS或者Integrity来生成软件需求。
  • 在基于模型的软件设计阶段我们会根据具体软件类型和应用需求使用Simulink+Simulink Coder,或者Simulink+Targetlink或者ASCET来编写软件。
  • 而在软件编写之后,测试之前,我们会用Simulink V&V,以及MXAM这样的工具来做静态代码检查。
  • 最后在软件测试阶段,我们又会有具体的基于Simulink的仿真测试以及SiL测试,还有有基于PiL台架或者HiL台架的实时测试,或者基于整车使用INCA和CANape,CANalyzer的整车测试。

最后要回答题主的一个细节问题,就是理论上来说,不论是从0开始设计的软件,还是简单的软件变更,都需要严格依照上面提到的三个"V"来操作。

这样做的好处非常明显:可以保证软件质量,避免量产后的产品缺陷和各种昂贵的召回。但是短期的缺点却更加显眼:需要比所谓的“快速开发”多花两倍到三倍的人力物力财力和时间,量产项目中绝对无法“速成"。

至于现在众多公司在流程上的应用情况,以我个人的经验,就是最为严谨的老牌车企也很难做到100%严格按照流程办事,哪怕流程本身已经满足ASPICE要求。而国内自主车企虽然上升速度快,但是对于流程的管理和实现大多还处在没有认证的试探阶段。至于专注新能源的新车企,国内的先不说了,我曾经接触过一个欧美的新能源车企,目前属于专心让车型上市,对于流程暂时有心无力的阶段。

其他关于软件流程的内容,也可以参考我以前的一场Live:

车载控制软件设计:从需求到量产

如果有细节问题的可以在评论中继续讨论。年底前如果有时间的话我也会再单独组织ASPICE和ISO 26262这两个标准具体实现步骤和应用细节的Live,敬请关注。