目录
1. 目标
随着新能源汽车的快速崛起，汽车电子行业开始快速发展，而汽车软件对功能安全要求很高，对工程师的需求和要求也越来越大。且汽车ECU开发标准，规范众多，AUTOSAS这座大山更是望其项背，本人从0到1学习汽车ECU开发，深知其中的辛苦。基于这样的背景，想建立一个汽车电子软件知识系统分享的平台，从原理分析到代码分析最后再到实际项目应用，让初入行的汽车工程师少走弯路，同资深的工程师相互学习。作者也需要吃饭，部分内容付费，不喜勿喷！
2. 要分享什么
如上图所示，分享的内容包括汽车电子软件工程师所需要掌握的基础知识，硬件平台，行业知识，以及职业软实力知识。希望形成一条主线，在这条主线上删繁就简逐步建立属于自己的知识体系框架。
3.1 行业知识
3.1.1汽车电子行业知识：
AUTOSAR:这里先介绍Class Platform AUTOSAR，Adaptive Platform AUTOSAR还没接触过，暂不介绍。
对于车载或者电控MCU平台的项目，AUTSAR能够帮助我们快速开发和迭代项目。基于个人对AUTOSAR的学习经验，学习AUTOSAR不能只停留在文档阅读上面，一定要基于源码来阅读，然后付诸于实践，特别是在应用层使用AUTOSAR方法论（port,interface, composition,data type.....）的时候一定要基于实际项目来理解，这样才能真正掌握。
在学习当中要总结一套自己的阅读技巧，比如我开始学习的时候就记录了一下我的学习步骤：
step1: 总体预览下这个模块实现的功能，看文档的功能概述
step2: 浏览下模块中的各种概念定义
step3: 看代码的模块配置定义文件，对照着配置实现代码，不懂的概念到文档中查找理解
step4: 看懂所有的配置后再去看函数实现，文档有函数的功能说明。
note1: 对于每个模块，看它实现了什么功能，调用下层什么模块，被哪个上层模块在什么场景下使用。
note2: 先抓主线，然后在整体框架上去看模块某个具体的功能是怎么是实现的！-- 以COM模块为例，主线就是Com的收发机制，底部收到CAN数据到COM层怎么更新数据；COM层怎么发送数据；COM和RTE的交互实现。搞清楚这个主线之后，在去分析COM模块中的Sequence Control或者Update-Bits是怎么实现的！
以CAN协议栈为例。分析CAN TRANCEIVE-->CAN DRIVER-->CANIF-->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协议栈的具体实现。
BootLoader:
BootLoader最重要的功能就是实现ECU的升级。一般独立的ECU（BMS，VCU...）使用CAN诊断的0x27协议实现刷写更新程序，而MCU和SOC共存的ECU会通过串口UART使用X/YModel协议实现ECU的升级。而其中最主要的指标就是刷写的成功率，以及失败后的应急方案。
ECU升级一般要求得99.99%以上的成功率，不然一旦ECU刷写失败会导致很多的异常问题。通过双分区的办法来保证刷写失败后ECU能回退到刷写前的版本。其中的具体实现还有很多的细节考虑，比如刷写数据的校验机制，异常断电导致失败的重新刷写机制，以及防异常的写Flash代码拷贝机制等等。
EOL:
EOL也就是End Of Line下线检测，对于汽车ECU一般在单件工厂会有一次下线检测，在整车集成后的整车下线也会有一次下线检测。而下线检测的内容一般是常见的DTC清除，各种外设的正常输入输出等等。一般会制定一个详细的下线检测流程，也就是对已经实现的功能增加一个诊断Session的功能来接管控制操作一下，看是不是我们想要的输入输出。
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需求、WatchDog需求、ECUM需求等。第三层ASW需求就是具体的应用实现功能。
完成了具体的功能模块需求后，ASW需要根据具体的开发设计输入文档进行架构设计，输出ARXML文件，导入Matlab进行应用层需求开发。
BSW需求则使用BSW工具根据具体需求开始配置，CDD功能和IOHWAB功能需要根据实际情况调用MCAL接口手动实现。
3.1.3开发测试工具：
Davince:
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到底做了哪些准备工作？这些准备工作是必须的吗？我们在项目开发过程中会去修改这些地方吗，如何修改？连接器脚本到底是怎么回事？这些都需要我们去探索实践发现。
3.3 基础知识
《程序员的自我修养》中说到：CPU体系结构，汇编，C语言（包括C++）和操作系统，永远都是编程大师们的护身法宝，就如同少林寺的《易筋经》，是最为上乘的武功；学会了《易筋经》，你将无所不能。可见基础的重要性。
基础不牢，地动山摇。没有遇到问题前，可能都用不到，但是一旦发生问题了，好的基础知识就能帮你快速的定位问题。
基础牢固，学习新东西要快的多。如果你熟悉C++，学习Python基础简直就是砍瓜切菜一般。
何谓基础，有的前辈说每个行业的基础不一样，我们不讨论这个问题。我们将讨论如何巩固学习基础知识并用于实际项目。
C/C++，嵌入式行业的产品基本都是这C/C++写的，必须精通，这个精通包括语法知识的深入理解以及常用C/C++程序框架和技巧的熟练掌握。
OS操作系统，一般包括实时操作系统（RTA_OS）和非实时操作系统（Linux）。对于实时操作系统如RTA_OS，我们需要深入理解实时操作系统的调度机制、优先级实时响应机制、多核多任务间数据一致性、RTA_OS的Autosar概念的具体实现。对于非实时系统如Linux，我们起码要深入理解几个常见驱动框架（IIC, Uart, Spi）的具体实现。
计算机组成原理，汽车电子或者说嵌入式产品本身即是一个微型计算机，由存储单元，计算单元，传感器/执行器单元等物理器件构成。怎么理解这些物理器件间的功能区分又紧密合作就需要计算器组成原理来支撑。
算法与数据结构，复杂的树或者图数据结构用的很少，但常用的栈和队列以及链表在工作中用的很多，设计到一些策略实现的时候机会用得上。如果要分享OS的源码，数据结构和面向对象的编程思想必须数量掌握。
3.4 工作生活
梦想还是要有的，一直追求工作就是工作，生活就是生活，但随着生活角色的变化以及工作中承担的任务越来越重，二者完全解耦还是挺困难的。
我可以分享我们从初入职场的战战兢兢到面对问题后的宠辱不惊这一路成长的心路历程。
生活中角色的变化，怎么和工作达成最好的平衡？
何谓成长？跳入坑中叫挫折，爬出坑来叫成长。
新入公司，该怎么奠定江湖地位？
上面的每一句话都是亲身经历后思考的问题，后辈可以参考避坑，资深全当扯蛋瞎聊。
3. 我们是谁
投身于新能源汽车软件行业的打工人，就职于各大TOP OEM和Tier1。
