怎么确保很低的bug发生率在汽车行业的嵌入式软件开发中呢
车上此时五花八门的功能应接不暇，这些功能是如何从文字版需求变成用户能够感受到的功能呢？趁疫情在家，闲来没事聊聊软件需求话题。首先是需求的来源，对于车载控制器而言，需求的来源通常有两个大途径，一个是供给商内部，假如内部各模块log的存储方案、任务调度策略、参数管理等；另一个是主机厂，这是需求的大头，有来自法规对车辆的要求，也有来自于为了满足用户的驾驶需求，还有来自于各试验场测试反应问题的变更需求。
///插播一条：我自己在今年年初录制了一套还比较系统的入门单片机教程，想要的同学找我拿就行了免費的，私信我就可以哦~点我头像黑色字体加我地球呺也能领取哦。最近比较闲，带做毕设，带学生参加省级或以上比赛///
正文开始：
主机厂的兄弟通过与系统工程师(需求工程师)反复开会澄清需求，并以正式的方式输写。然后需求工程师从中提取真正的软件需求，并且将需求输写到需求管理系统，假如常用的西门子的Polarion、IBM的Doors等。为了减少系统工程师与软件开发工程师、测试工程师之间的反复扯皮，一份合格的需求必需具备以下特性：1、软件需求只包含必要描述性、定义性的信息，而不能包含解释性的内容。2、每条需求都必需是组成某个功能的最根本单元，不能够再继续分解。3、每条软件需求都必需具备可测试性，意味着有明确的输写输出。一份清晰而又精确的需求文档是一个项目是否优秀的基石。系统工程师需求写好之后，初始召集相关的软件开发工程师、测试工程师，进行需求的宣导，并且对齐各方对需求的了解偏差。这样需求就交接给他们了。软件工程师在收到需求后，初始编码进行功能实现，为了使编码合乎编码规范，一方面团队会有一份编码规范文档，在入职会进行宣贯，以及考试验收，第二通常会在IDE中集成静态代码检查工具来执行MISRAC/C++静态代码检查，保证代码的质量。另外在开发过程中，难免还须要与系统工程师反复地确认需求。当开发工程师完成开发后，就初始反复地测试、优化过程了。首先开发工程师会进行自测，假如是模型开发，会有模型在环MIL、软件在环SIL等仿真测试。然后会在单板离线环境进行功能的自测。
这些测试OK之后，团队内有个内部的测试小组，会对每条需求进行硬件在环HIL测试，以及老化测试，测试后会将结果反应给开发工程师，工程师对FAIL项进行确认和修复，然后继续测试，直到所有的需求都测试通过。团队内部测试OK之后，会出具测试报告，然后将测试报告和软件包交给独立的测试部门，进行测试。这里又会有一个反复的过程，假如测试部测完之后，假如有测试FAIL项，会将测试结果反应给开发团队，团队的开发和测试小组会进行FAIL项的确认、分析和修复。团队内部测试OK之后，再次提交给测试部测试。当测试部测试完成之后，会整理测试报告和测试结果，将软件释放给主机厂。这其实就是汽车行业传统的V模型开发模式。
没论软件是从没到有还是你所做的软件维护工作，其实都是要依照V模型的流程进行开发与测试。这里说一下基于功能需求的软件开发。
1、提取软件功能需求
为什么要做软件变更或者说为什么要开发一套新的软件，是由于一个相应的功能需求。这个需求可能来自于法律法规对于车辆安全的要求，可能来自于为了满足终端客户的驾驶需求，也可能来自于标定工程师对于整车驾驶性的需求。这些需求最终汇集到软件功能需求工程师的桌面上，他须要对这些需求进行拆分，提取出最终的软件功能需求，并将其作为新需求记录在册（我见到比较多的需求管理软件是IBMDoors.）
2、定义功能层面的测试
软件需求工程师定义好功能需求之后，须要在功能层面上定义测试这个需求的详细测试流程和步骤。例如测试应在什么工况下进行？汽车的速度，档位，温度的详细要求？在测试中要有什么详细操作？测试应出现什么结果？等等
3、与软件开发工程师的交接
优秀的软件功能需求应是简洁、易懂、可操作的。每条软件功能需求应力求简明避免长篇大论，为软件开发者和后人提供可读性。可操作是指这条需求是能够被转化为代码写入软件的。因此在交接这一步上尤为重要，软件需求工程师和开发者应对需求进行探讨，验证每条需求，而这一过程也应在之后的软件开发实施中不断反复。
就这一点曾与国内某OEM的同行做过交流，他作为软件开发者拿到的需求常常艰涩难懂，而且与需求工程师没法面对面沟通，导致工作很难正常展开。在我们这边，软件开发也是由另一个组来完成，但是他们被外派到我们组，这样至少保证了面对面沟通的可能性，每天的早会也给大家提供了交流的平台。
4、软件编码层面
软件开发工程师应在软件层面反复步骤1和2，定义软件代码层面的需求和测试过程，进行编码，之后对代码进行测试并评价分析，最终软件包返回需求工程师。
5、软件功能测试
需求工程师依据自己编写的测试步骤对软件进行功能测试，最终完成软件包，交付需求提出者验证。
以上就是大致的基于需求的软件开发流程。回到题主的问题，这套开发流程是怎样尽可能确保很低的bug发生率的：
1、我认为最重要的一点就是测试，包括依据最初软件需求的测试，在软件开发中针对软件代码层面的测试和评价，当然还有最后系统集成后对整个系统的测试。在我所在的公司，每个项目标标定工程师做了一辈子的标定，50多岁的严谨德国工程师，经历十分丰盛，他们通过每个VCycle对汽车驾驶性的测试，不断为我们注入新的软件需求，使得我们能够对软件不断进行bugfix以及软件拓展.一个从0到1的软件，不会到了1就立刻拿出量产，而是还要经过2、3、4。。。的循环才最终进入量产。。
2、第二点就是每个功能需求必须记录在册，这为之后的软件维护提供了极大的便利。人类总是在利益面前高估自己的水平，最初的软件开发图快图方便，扔几行代码进去发现功能实现了，就这样留在那里。汽车软件发展了这么些年，汽车控制器里面的软件模型都一万多页，若是有人想知道这几行代码当初为什么会出现，早已无人知晓。
3、在代码层面，软件开发者需要写出简洁明了的代码。可以用几个if，else就解决的问题不要用状态机（statemachineorstateflow）。越简洁的代码，出错的概率越小。
4、前面所说的测试，不需要所有都上车测试。为了节省资源和成本，直到软件功能需求工程师甚至标定工程师的工作前期，许多测试工作都可以在模拟环境中进行，比如SiL（SoftwareintheLoop）,HiL(HardwareintheLoop)。最理想的情况下，每一条需求都可以利用额外的软件测试工具将测试流程进行编码，利用工具在仿真环境下自动对需求进行逐条测试。
5、当然人类的能力也是有限的，对于一条需求可能想不全在所有的工况下进行全面检验。因此才会有冬测，夏测，高原测，山路测，各种测。这些测试就是想尽可能全面的在整车系统层面对软件进行检查，尽可能降低bug存在的可能性。
主机厂收到软件包之后，会进行简单的验收测试，验收OK之后，将软件功能描述、供应商测试报告、验收报告汇总成一份汇报PPT，在部门会议上进行汇报，主要目的是申请将测试软件释放到测试车辆和测试台架上。会议同意释放之后，软件包和测试报告以及会议记录会发布至主机厂内部的测试团队，他们会将软件更新到各个测试车辆进行测试。在车型开发过程中，都会有大量的测试车辆在全国各地跑功能、耐久、道路适应性测试。另外还有大量的测试件在环境仓、测试台架进行持续的测试。除此之外，还有每年夏季和冬季的标定测试，比如夏季去温度最高的吐鲁番以及海南、进行为期几个月的测试，同时还会其青海、昆仑山等进行高原测试，冬季则去大东北，漠河或者内蒙，进行为期几个月的冬季测试。
当功能在这些大量的测试下测试OK之后，才会真正的将功能释放给用户车辆。
这种长期的测试和验收流程，保证了车辆软件以及功能的可靠性，也是软件bug少的原因，另外这也是为什么汽车软件更新很慢的原因，不像手机软件，一周给你推送一个版本，甚至还会推送开发者版本给客户提前尝鲜，这种对车辆上核心的驾驶功能控制器来说，这是不可能的。
