前面

主要以开发ECU角度来说明，这里不以整车开发角度。

工具链

主流有Vector、ETAS、EB，这里以Vector和ETAS工具链为例说明。
Vector Developer用于应用层架构设计，Vector Configurator 用于BSW+RTE配置;
ETAS ISOLAR系列（RTA-RTE RTA-OS）全套开发融合；
MCAL目前主要还是使用EB的 Tresos工具。
好用度或自动化程度上，Vector>ETAS，价格反之。
由于Vector系列占主流，因此以Vector工具链作主要说明，而关键点时也会提到ETAS。

流程

以下以开发一个ECU为例说明：

客户输入

CAN矩阵（DBC文件），诊断表（CDD文件或ODX文件）以及客户需求表（SOR文件等）。

ODX(Open Diagnostic Data Exchange)是一种开放式的诊断数据格式标准，用于描述与诊断相关的ECU数据。车辆，ECU和测试仪制造商可以使用ODX格式描述和交换诊断数据。 ODX被设计为用于数据交换的开放格式。 CDD(Complex Device Driver or Complex Driver)是复杂设备驱动/复杂驱动的缩写。 SOR是Specification Of Requirements 指顾客方针对供应商发出的产品规格要求，一般是一个项目启动后，在供应商招标时发给供应商，其中包含产品的价格、质量、数量等各方面比较详细的要求。

第一步 配置MCAL

根据HSI（软硬件接口），在EB Tresos中配置好MCAL，配置好后可以导出Arxml，方便下一步集成到Vector或ETAS工具。

第二步 将MCAL集成到Autosar工程

将MCAL集成到Autosar工程中，这一步的目的就是将OS依赖芯片相关的内容（计数器、时间等）集成进来，当然也包含一些其他的依赖MCAL的内容，如CAN驱动、EEprom/模拟EEprom、Spi、看门狗等，这些建议在EB工具下配置，自动化程度会好一些（不管是ETAS还是Vector兼容第三方工具都不是特别好）。

第三步 BSW所需的模块

将BSW所需的模块加入到Autosar工程，如BswM、EcuM、WdgM、NvM、Dem、Dcm、Com等所需的的模块加入都工程。

第四步 DBC文件和CDD文件导入Autosar工程

将DBC文件和CDD文件导入Autosar工程（这一步Vector和ETAS最新工具链都是支持的），这一步会将Com协议栈的大部分配置项和Dcm、Dem的大部分配置项生成，可是Vector和ETAS在这里都没有做到完美，很多配置项都需要手动调整。

第五步 协议栈配置

调整COM协议栈以及UDS协议栈配置项，配置NvM/MemIf/FEE/Fls、配置WdgM/WdgIf/Wdg、配置Xcp等。

第六步 配置ECUC、OS，RTE

配置ECUC、OS，RTE，ECUC主要涉及到分区，以及Core Hardware定义等，OS主要涉及Task、Counter、Application等配置，方便后续Mapping，这里说明一下ETAS中OS的管理用的另外一个工具RTA-OS，其一致性做的不够好。

第七步 配置应用层SWC

配置应用层SWC，当然这一步也可以在第一步开始的时候执行，主要配置应用层的组件、接口、函数等。

第八步 连线+Mapping

连线+Mapping，这里主要是将需要调度的Mapping到Task或中断（中断手动放入入口函数），还有就是PRPort口之间的连线（包括SWC与SWC，SWC与BSW组件）。

第九步 集成

至此，Autosar工程基本部署完成，后续只需将MCAL+BSW+RTE+ASW的代码集成到一起即可，说实话，这里的集成过程目前由于工具链的问题，效率自动化程度都不高，尤其是ETAS需要写很多脚本支持。
当然，这里还有两个概念提及一下，IO抽象以及CDD，本质上他们就是SWC。

第十步 MBD开发

此外ASW配置完后，其实就是一个代码框架，或者就是这个ASW的架构信息，可以导出Arxml文件，供后续进行MBD开发。

内容来源：一个学霸师兄