小鹏汽车官网
当前位置:首页 > 资讯 > 技术 > 正文

汽车软件需求:如何从文字版需求变成用户可以感受到的功能?

发布日期:浏览量:2905

导读:车上现在五花八门的功能应接不暇,这些功能是如何从文字版需求变成用户可以感受到的功能呢?趁疫情在家,闲来无事聊聊软件需求话题。

首先是需求的来源,对于车载控制器而言,需求的来源通常有两个大途径,一个是供应商内部,比如内部各模块log的存储方案、任务调度策略、参数管理等;另一个是主机厂,这是需求的大头,有来自法规对车辆的要求,也有来自于为了满足用户的驾驶需求,还有来自于各试验场测试反馈问题的变更需求。

主机厂的兄弟通过与系统工程师(需求工程师)反复开会澄清需求,并以正式的方式输入。然后需求工程师从中提取真正的软件需求,并且将需求输入到需求管理系统,比如常用的西门子的Polarion、IBM的Doors等。

为了减少系统工程师与软件开发工程师、测试工程师之间的反复扯皮,一份合格的需求必须具备以下特性:

1、软件需求只包含必要描述性、定义性的信息,而不能包含解释性的内容。

2、每条需求都必须是组成某个功能的最基本单元,不能够再继续分解。

3、每条软件需求都必须具备可测试性,意味着有明确的输入输出。

一份清晰而又准确的需求文档是一个项目是否优秀的基石。

系统工程师需求写好之后,开始召集相关的软件开发工程师、测试工程师,进行需求的宣导,并且对齐各方对需求的理解偏差。这样需求就交接给他们了。软件工程师在收到需求后,开始编码进行功能实现,为了使编码符合编码规范,一方面团队会有一份编码规范文档,在入职会进行宣贯,以及考试验收,第二通常会在IDE中集成静态代码检查工具来执行MISRA C/C++静态代码检查,保证代码的质量。另外在开发过程中,难免还需要与系统工程师反复地确认需求。

当开发工程师完成开发后,就开始反复地测试、优化过程了。

首先开发工程师会进行自测,如果是模型开发,会有模型在环MIL、软件在环SIL等仿真测试。然后会在单板离线环境进行功能的自测。

这些测试OK之后,团队内有个内部的测试小组,会对每条需求进行硬件在环HIL测试,以及老化测试,测试后会将结果反馈给开发工程师,工程师对FAIL项进行确认和修复,然后继续测试,直到所有的需求都测试通过。

团队内部测试OK之后,会出具测试报告,然后将测试报告和软件包交给独立的测试部门,进行测试。这里又会有一个反复的过程,比如测试部测完之后,如果有测试FAIL项,会将测试结果反馈给开发团队,团队的开发和测试小组会进行FAIL项的确认、分析和修复。团队内部测试OK之后,再次提交给测试部测试。

当测试部测试完成之后,会整理测试报告和测试结果,将软件释放给主机厂。这其实就是汽车行业传统的V模型开发模式。

图片来源网络

主机厂收到软件包之后,会进行简单的验收测试,验收OK之后,将软件功能描述、供应商测试报告、验收报告汇总成一份汇报PPT,在部门会议上进行汇报,主要目的是申请将测试软件释放到测试车辆和测试台架上。

会议同意释放之后,软件包和测试报告以及会议记录会发布至主机厂内部的测试团队,他们会将软件更新到各个测试车辆进行测试。

在车型开发过程中,都会有大量的测试车辆在全国各地跑功能、耐久、道路适应性测试。另外还有大量的测试件在环境仓、测试台架进行持续的测试。

除此之外,还有每年夏季和冬季的标定测试,比如夏季去温度最高的吐鲁番以及海南、进行为期几个月的测试,同时还会其青海、昆仑山等进行高原测试,冬季则去大东北,漠河或者内蒙,进行为期几个月的冬季测试。

当功能在这些大量的测试下测试OK之后,才会真正的将功能释放给用户车辆。

这种长期的测试和验收流程,保证了车辆软件以及功能的可靠性,也是软件bug少的原因,另外这也是为什么汽车软件更新很慢的原因,不像手机软件,一周给你推送一个版本,甚至还会推送开发者版本给客户提前尝鲜,这种对车辆上核心的驾驶功能控制器来说,这是不可能的。

来源: 汽车ECU开发 eng2mot 

版权说明:“华夏EV网”转载作品均注明出处,本网未注明出处和转载的,是出于传递更多信息之目的,并不意味着赞同其观点或证实其内容的真实性。如转作品侵犯署名权,或有其他诸如版权、肖像权、知识产权等方面的伤害,并非本网故意为之,在接到相关权利人通知后将立即加以更正。

文章标签:

本文网址:http://www.evinchina.com/newsshow-1410.html

分享到:
相关文章
查看更多