导读：车上现在五花八门的功能应接不暇，这些功能是如何从文字版需求变成用户可以感受到的功能呢？趁疫情在家，闲来无事聊聊软件需求话题。
首先是需求的来源，对于车载控制器而言，需求的来源通常有两个大途径，一个是供应商内部，比如内部各模块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
