本文是作者在COVID-19封城之际写的文章，既是对从上班以来的一个总结和归纳，也可以帮助国内的工程师了解一下外国公司对ECU（ELECTRONIC CONTROL UNIT）的开发方式。
我在Q公司毕业实习6个月后（坐标法国），成功被部门经理以CONSULTANT留下，成为一名APPLICATION SOFTWARE EMBEDDED ENGINEER。从事EECU（发动机控制器）软件开发工作。接下来简单介绍一下Q公司的开发流程：
1. 需求
我们TEAM有7个SW engineer，2个 calibration engineer，1个system engineer，1个simulation engineer 和1个manager。团队负责delivery有质量保证的EECU软件，1个团队有不同的职业可以很好地保证这一点。我们使用JIRA(一个网页版TOOL)进行任务管理，让我们可以更好的应用AGILE的方式。我们TEAM所有的任务都编辑在JIRA内，每个SPRINT的beginning我们都会对JIRA进行一个大清理，比如上个SPRINT没有完成的任务需要进入下个SPRINT，以及显现需要在这个SPRINT开始处理的任务（一个SPRINT为3个星期，每3个SPRINT称为一个PI）。我们的任务一般来自其他团队/项目的demand或者反馈来的BUG，我们基本不和客户有直接联系。每个PI的刚开始，我们会有一个持续1天的会议，团队内的人自行分配由经理在上一个PI期间收集到的所有task，一般是根据自己的经验和对某些问题的了解程度进行任务选择。然后根据任务的priority/所需时间，和经理商量并把它们一一分配到每个SPRINT里去。一般的任务可能会需要system工程师的介入，进行系统方面的分析和与其他团队的协调。之后system工程师会在DIMENSION RM（一个requirement管理tool）创建SYSTEM LEVEL 2需求，软件工程师们可能会需要把这些需求分解成COMPONENT LEVEL REQUIREMENT和创建可以验证这些需求的TEST CASE。根据这些需求，当然也需要软件工程师和系统工程师和其他团队的沟通，就可以进行软件开发了。具体的关于为什么是SYSTEM LEVEL 2，同一个还是不同的软件工程师创建TEST CASE，取决于团队决策和很多其他因素，可能会在以后的文章中详细介绍。还有一些任务可能仅仅是修复一些BUG，这个时候就需要软件工程师自己进行investigation然后解决这个软件问题。
2. 软件开发
Q公司是欧洲极少数自己开发发动机控制器软件的automotive industry,这大大提高了它的竞争性。一般来说，EECU(发动机控制器)和TECU(传动/变速箱控制器)等软件开发会采用SIMULINK，也就是MBD（MODEL BASED DESIGNE）的方式，VECU（车辆主控制器）会选择C语言进行开发。MBD的方式提高了软件的可读性并且很好维护，特别重要的是方便calibration engineer（标定工程师）进行标定。EECU软件开发一般全部在一个版本（我们叫它BASELINE）中，但要注意的是，根据年代和CO2排放标准不同，也会有不同的BRANCH，有的BRANCH符合EUROPEAN EMISSION STANDARDS 5，有的符合EURO 6等等。之前说的BASELINE其实是说的在同一个BRANCH中，也就是说同一个BRANCH中只有一个开发的环境版本。举例来说，不是说车辆A开发一套软件，车辆B开发另外一套软件，而是一个版本可以manage成百上千，各种不同CONFIGURATION的车辆。方法就是比如说车辆A使用BASELINE中A模块+B模块，车辆B使用BASELINE中B模块+C模块。有专门的CONFIGURATION MANAGER负责这方面。EECU（发动机控制器）内APPLICATION（应用层）开发主要有三个部分：扭矩控制，尾气排放处理和点火燃烧控制。我们团队主要负责扭矩控制，具体来说就是计算每个时刻应该给发动机提供多少扭矩。具体的Function介绍可能也需要下次讲解。要知道现在很多外国公司都在开发/改进一些策略让车辆整体耗油量更少。EECU内还有PLATFORM开发,这个就比较偏硬件了，比如CAN信号的传递，控制器Pin的分配，传感器的信号获取，一般会用C语言进行编程。我们负责的EECU内主要模块包括：加速器控制，巡航控制，怠速控制，限制器控制等等。众所周知，function一般包括Trim和Controller。Trim负责对“各种信息”的选择，过滤，Fallback Mode处理，策略决定，function activation/deactivation条件计算等等，最终计算一个可靠正确的set point，这里的“各种信息”可能是Sensor得到的数据，其他控制器通过CAN总线传输到EECU的数据等等。Controller负责将set point转化成扭矩，进而提供给发动机。一般使用开环或者闭环控制器以及前馈控制。传统的SIMULINK中的PID控制器不可能用在这里，因为过于简单。我们一般选择自行计算/选取P,I，D的数值，然后通过数学方程计算得到扭矩。
3. 软件测试
除了专业的HIL团队，整车测试团队对软硬件进行测试，我们团队在每次修改，创建新的模块时，也都会对软件进行MIL，SIL，HIL等多方面测试，确保自己的development符合需求并且对已存在的软件没有造成影响（No regression）。接下来介绍一下我们团队通常采取的测试方法和测试级别：
Test Equipment：
MIL：新建SIMULINK空白页，在SIMULINK环境内对修改/新建的SIMULINK模型进行功能测试。SIL ：类似MIL，但是需先将所有TARGETLINK模型转化成C语言，然后再创建 .DLL（DYNAMIC LINK LIBRARY，类似于在控制器上的.vst文件，.DLL可以使用电脑的processor来执行）。Q公司有自己开发的SIMULINK LIBRARY，使得SIMULINK支持 .DLL BLOC，其实它类似一个SIMULNK BLOC，但其中包括所有转化成C语言的模型。对于测试者来说相当于Black Box。VECUtest ：使用.DLL进行自动化测试，可以Override input然后比较output是否为期待数值。Mini HIL：团队自主开发了CANalyzer中的CAPL文件，并配备一个专门的box，可以很好地进行crank并且进行基本的闭环/开环测试。通常将compiler的.vst文件和和合适的.cal/.dcm（calibration file）文件烧到控制器中，使用ATI Vision和CANalyzer进行测试。比如可以模拟点火启动发动机，踩加速器踏板，设定巡航速度，道路坡度等等。VEHICLE：将.vst文件和和合适的.cal/.dcm（calibration file）文件烧到车辆的EECU控制器中去，在真车上进行测试。
Test Level：
V1 SW Component test：通常使用MIL，VECUtest，Mini HILV2 SW Module test：通常使用MIL，VECUtest，Mini HILV3.a SW Functional regression test：VECUtestV3.b SW Integration test：Mini HILV4.a System test ：VEHICLE我们团队的测试要求比较严苛，所以每次developement之后都要使用上述方法进行不同级别的测试保证万无一失。我们团队也正在开始运用ISO26262，之后会慢慢介绍。
4. 软件集成（INTEGRATION）
DIMENSION CM是很好进行verison control的软件，文件类型一般为：mdl,m,xml,cpp等。每次的development，对应DIMENSION CM中的一个task number，比如PD1_TASK_SW_24945。其中有对应的修改/添加的文件，但同时我们还需要对这个task进行document。我们有相应的模板，每次要解释新建这个任务的原因和解决方法，修改了哪些软件以及测试的方法和结果等等（随着ISO26262的普及，我们慢慢地在把测试方法和结果转移到DIMENSION RM中）。这个文档仅仅是方便同事review和traceability。在给同事review之前，还需要将自己的任务push to JENKINS进行Pre integration检测，如果没有问题，接下来同事可以进行review，如果同事review也觉得OK，那么他可以将这个任务push to“integration approval”。最后部门经理将进行最后一次检验，他会简单查看任务对应的document，如果他觉得开发的方法和测试结果也没问题，他会push to“integration ”。一般来说，如果任务稍微比较复杂，我们需要对stakeholders做一个software demonstration，也就是做一个简单的PPT然后介绍一下任务的状态：需求是什么然后我实现了什么，测试结果怎么样，软件有没有integrated等等。如果他们都很满意，那么恭喜，你成功完成了一个任务，在JIRA任务管理中，相应的任务可以push to "Done"。上述的所以都是简约版的，具体的内容需要大篇幅讲解。也欢迎同行，前辈，高手一起进行探讨。感兴趣的可以关注我的知乎（法国工程师在流浪）
