版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
方法论概述
一、一些必要的概念
1、供应链上的称呼
想必大家经常都在说OEM、TIER1、TIER2这些名称，在大厂工作的童鞋可能相对比较了解一些。这里为了确保大家都能理解，所以还是先解释一下：
| 简称 | OEM | TIER1 | TIER2 |
|---|---|---|---|
| 中文名 | 代工厂（整车厂） | 一级供应商 | 二级供应商 |
| 例子 | 奔驰、宝马、奥迪等（主要做整车的装配工作） | 大陆、博世等（主要给OEM供应ECU、钣金件等） | 英飞凌、NXP等（主要给TIER1供应零件，比如ECU上的芯片、MOS管和电路板等） |
而TIER1生产制造ECU，就需要受到OEM的一系列的规定和约束，才能提供OEM所需要的ECU设备。而我们的AutoSAR也是将一辆汽车设计ECU软件的几乎所有流程都囊括在内了
2、什么是方法论
仍然通俗的说就是：搭建符合AutoSAR架构的ECU软件的详细工作流程 （也不知道AutoSAR咋就取了这么让人无法理解的名称）
举个例子：方法论就像一本菜谱 ，我们只需要按照菜谱上写好的原料、工具和步骤，就能做出一道好菜
方法论主要规定了以下内容：
- 具体工作流程（做菜的步骤）： 从OEM开始设计汽车电子架构开始，到各TIER1完成每个ECU的软件设计的一整套流程，马上我们将讲解到
- 具体的交换文件（做菜的原料）： OEM和TIER1之间、TIER1内AutoSAR底层和应用层之间和MCAL与BSW之间都是需要文件交互的。但我们不可能用word来交换这些信息，比如OEM想要告诉TIER1车辆的CAN报文有哪些这个内容。使用word的话，OEM编辑起来费时费力，TIER1阅读起来也费事费力；所以AutoSAR规定了一种新的文件格式：.arxml，这种格式基于.xml文件，加上AutoSAR的缩写ar就成了arxml。用它的好处就是可以由DaVinci等软件自动生成。比如整车厂用一套软件设计好了整车的CAN通信矩阵，直接导出.arxml，然后发给TIER1；TIER1在Davinci中打开，所有的内容一目了然，并且自动将CAN、CAN IF、PUDR等模块配置好了。（是不是很方便！不过现在很多厂商还仍然沿用的是DBC文件，其实也都差不多，不过AutoSAR建议使用arxml文件）
- 具体的工具链（做菜的工具）： 符合AutoSAR的工具链，就比如DaVinci、ETAS这种，这个不再赘述
二、工作流程
1、普通流程
（目前大部分车企还停留在这个阶段）
- OEM通过一些软件设计出整车的通信矩阵，并导出DBC、FIBEX或LDF文件
- OEM将这些文件发送给TIER1
- TIER1如果有DaVinci这样的软件，可以导入进去直接自动配置Communication的大部分功能
2、AutoSAR标准流程
（目前能做到这个程度的太少了）
- 列出需求：OEM设计整车需要哪些ECU、需要哪些功能、要哪些SWC，在这一步先列出来。仍然是之前控制车顶灯的例子：OEM需要两个ECU（车门ECU和车顶灯ECU）、需要7个SWC。（还记得下面这张图吗）
- 分配需求：OEM将所有列出来的SWC分配到各ECU中。（这里可以看出车门ECU和车顶灯ECU之间是有通信的，这里就是通过总线传输的，所以这里也是包含了通信矩阵的信息，只不过下图中的例子比较简单，只有一条线）
- 将需求交给TIER1实现：OEM将各个ECU的需求（通信矩阵、需要哪些SWC这些信息）生成对应的arxml文件，交给TIER1。（每个arxml中只包含该ECU需要的内容，比如车门ECU拿到的arxml中就不会有执行器SWC的内容）
- TIER1拿到需求后，导入到DaVinci中，然后自动配置好了AppL层，Communication的那些内容。然后将SWC填上具体实现的代码，再配置一下其他必要内容，就搞定了
附：返回总目录的传送门如下
->返回总目录<-