【工作生活】汽车ECU开发内容简介

note2: 先抓主线，然后在整体框架上去看模块某个具体的功能是怎么是实现的！– 以COM模块为例，主线就是Co m的收发机制，底部收到CAN数据到COM层怎么更新数据；COM层怎么发送数据；COM和RTE的交互实现。搞清楚这个主线之后，在去分析COM模块中的Seque nc e Con tr ol或者Up date-Bits是怎么实现的！

以CAN协议栈为例。分析CAN TRANCEIVE–&g t;CAN DRIVER–&g t;CANIF–&g t;PDUR / CANTP/CANNM/CANSM整个协议栈，形式上从文档出发，结合开源源码和工具分析CAN协议栈的具体实现和使用，然后最好能以Demo的形式给出示例。

复杂驱动：

电控类项目（BMS, BCM, VCU）如BMS的单体采样控制、车身域/BCM的高低驱输出控制，动力域/VCU的刹车或上下电控制以及整个ECU的电源管理对采样的精度和电源的可靠性要求很高，都会使用特殊的芯片来实现。而对这些特殊芯片的操作AUTOSAR没有定义规范，就需要复杂驱动来实现。

对于复杂驱动，正向功能的开发当然很重要，但是对于其诊断和自恢复功能的实现也特别重要（VCU要是突然异常掉电了，要是没有证据证明不是自己的问题，那你就完蛋了。。。）。而对于复杂驱动的学习，最重要的就是看Datasheet，然后多和硬件工程师讨论，最后疯狂的测试。

对于这部分的学习，将结合具体的应用场景从Datasheet出发，一步一步的实现一个可用的复杂驱动，最后最好能总结出一个驱动框架。

网络管理：

网络管理最重要的功能就是保证整车上的所有ECU同睡同醒，最大程度上的节约用电（理想很丰满，现实很骨感，一旦一个ECU的网络管理出现问题，整车所有的ECU都不会休眠或掉电。。。）。而网络管理一般用OSEK网络管理和AUTOSAR网络管理，目的都是一样。对于这部分的学习，将从概念到源码再到实践，要在仿真器上实现OSEK网络管理建环，AUTOSAR网络管理睡眠。

诊断UDS：

诊断部分最重要的两个协议就是传输层ISO-15765协议和应用层ISO-14229协议，协议实现的载体一般是CAN通信服务。传输层实现数据的类型校验和数据的上传下达、流控的实现、各种定时器的实现。应用层则实现具体的服务，比如DTC的读写，IO的诊断控制，诊断刷写升级ECU等。

将从CAN邮箱中断收到物理寻址或功能寻址报文开始，一步一步分析整个UDS协议栈的具体实现。

Bo o tLoa de r:

Bo o tLoa de r最重要的功能就是实现ECU的升级。一般独立的ECU（BMS，VCU…）使用CAN诊断的0x27协议实现刷写更新程序，而MCU和SOC共存的ECU会通过串口UART使用X/YMod el 协议实现ECU的升级。而其中最主要的指标就是刷写的成功率，以及失败后的应急方案。

ECU升级一般要求得99.99%以上的成功率，不然一旦ECU刷写失败会导致很多的异常问题。通过双分区的办法来保证刷写失败后ECU能回退到刷写前的版本。其中的具体实现还有很多的细节考虑，比如刷写数据的校验机制，异常断电导致失败的重新刷写机制，以及防异常的写Flas h代码拷贝机制等等。

EOL:

EOL也就是End Of Lin e下线检测，对于汽车ECU一般在单件工厂会有一次下线检测，在整车集成后的整车下线也会有一次下线检测。而下线检测的内容一般是常见的DTC清除，各种外设的正常输入输出等等。一般会制定一个详细的下线检测流程，也就是对已经实现的功能增加一个诊断Se ss ion的功能来接管控制操作一下，看是不是我们想要的输入输出。

EOL看似简单，就是对已实现的功能的检测，但是涉及生产无小事，因为一旦生产出问题，整个产品线就会停滞，BOSS可不会管你的，劈头盖脸的质量人员就会招呼来了。。。

标定：

标定，顾名思义就是对一些我们不能确定的参数通过实际路试情况统计得出并写到ECU的ROM当中。一般采用XCP协议实现，协议载体一般还是CAN通信协议栈。对于标定协议和具体应用我们可以思考一下的几个问题：

— 标定的数据具体怎么定义？如果不使用Matlab定义标定数据怎么样生产A2L文件？

— 怎么样修改我们的链接文件给我们的标定数据开闭一块特定的标定数据域？

— 使用什么样的上位机来实现数据标定？

— 整个XCP协议在AUTOSAR工具中是怎么配置的？

这些都是我们应该学习和考虑清楚的。

功能安全：

功能安全属于属于锦上添花的事情，和装修房子一样你想花多少钱（时间/精力/复杂度）都可以。通俗的来讲就是通过头脑风暴的方式得出各种工况下的异常场景，然后通过具体规则划分优先级和必要性，最后指定具体的异常处理措施，将软件的可靠性做到更优。

开发流程：

小公司可能就是一个人在战斗，基本没有开发流程这回事。但是大公司，这个还是很重要的，一旦涉及到多人开发，没有一个成熟的开发流程，各种浑水摸鱼已经异常问题就出现。

对于汽车电子产品，常见的开发流程关键词为：自上而下，自下而上，V字型，ASPICE等等。

不管使用哪一种，有几个关键点都是一样的：

— 各个阶段（ET阶段，PT阶段，SOP阶段）的详细开发计划（一级，二级，三级）

— 开发计划下的每个功能的具体负责人，及dealine时间

— 开发节点应该提交的输出物（需求文档，需求文档评审/修改记录，详细设计文档，详细设计文档评审/修改记录，代码，测试报告）

— 功能增长表（风险分析控制表）

— BUG管理和追踪

— 项目代码管理和提交/修复追踪，版本管理控制等

3.1.2项目：

项目很多，我们要学会以不变应万变，摸索一套能够套用的项目开发流程。以车身域控制器开发为例，我们首先从公司的第一级开发计划中筛选出二级部门计划，然后软硬件芯片选型，根据已有资源工具和人力制定详细的三级ECU开发计划。

从功能上划分，第一层可分为ASW应用层功能需求和BSW基础软件功能需求。第二层ASW需求又可分为车身控制系统、无钥匙进入启动系统、智能配电系统、热管理控制系统。BSW需求又可分为MCALL需求、IOHWAB需求、CDD需求、NVM需求、UDS需求、COM需求、OS需求、Watc hDog需求、ECUM需求等。第三层ASW需求就是具体的应用实现功能。

完成了具体的功能模块需求后，ASW需要根据具体的开发设计输入文档进行架构设计，输出ARXML文件，导入Matlab进行应用层需求开发。

BSW需求则使用BSW工具根据具体需求开始配置，CDD功能和IOHWAB功能需要根据实际情况调用MCAL接口手动实现。

3.1.3开发测试工具：

Dav inc e:

MCAL工具配置生成动态MCAL配置代码，不同芯片配置成统一的MCAL驱动程序接口。每一个MCAL接口，AUTOSAR文档已经明确定义，但每一个接口的具体实现不同的芯片又不一样，以MCU模块为例，要配置MCU模块就得对芯片的时钟十分清楚，因为MCU模块会调用统一的MCAL接口完成时钟的初始化。MCAL的配置会影响硬件的特性，这就需要我们对芯片特性和MCAL需求特别熟悉，不然就会产生很多奇怪的问题。

ISOLAR:

ISOLAR包括四个部分的功能，BSW的配置，OS的配置，RTE的配置，ASW的配置。BSW主要配置通信协议栈，存储协议栈，诊断协议栈。OS配置任务调度表，优先级等。RTE配置SWC之间及SWC与BSW间的运行时环境。ASW配置各个SWC的接口。如果是自底向上的开发流程，需要在ISOLAR当中完成SWC的架构配置，生成ARXML文件导入到simulink进行应用层开发。

MATLAB：

使用MATLAB/SIMULINK功能开发应用程序。使用AUTOSAR BLOKSET进行AUTOSAR架构的应用层软件开发。使用自定向下的开发模式的话，直接导入各个SWC的ARXML文件，生成模型进行应用层软件的开发。使用MBD的开发模式，模型配置，代码生成配置，模型验证配置也需要熟练掌握。

Vector 系列工具：

CANoe可以进行多ECU仿真分析，CAN报文纳秒级的分析，实车数据录制，在分析问题的时候，几乎无可替代。

CANape完成标定功能。

CANlalyzer是CANoe的简化版。

3.2 硬件 平台

现在行业内都在鼓吹软件定义汽车，其实某种程度上来看硬件才是定义汽车的基础。强大计算力的GPU才能支持复杂计算的自动驾驶，车载以太网的量产才能使SOA落地。而硬件中的核心就是MCU/CPU。每款芯片都会有自己IP核（ARM，PowerPc，X86）和指令集，围绕IP核各大厂商就会集成自己的外围设备生产特定功能用途的芯片（S32K, RH850等）。我们学习硬件平台需要了解从板子上电后从哪里运行第一条指令？在跑到main 函数前我们的CPU到底做了哪些准备工作？这些准备工作是必须的吗？我们在项目开发过程中会去修改这些地方吗，如何修改？连接器脚本到底是怎么回事？这些都需要我们去探索实践发现。