人类喜欢看的是EXCEL/WORD/图片这种直观的表达方式。
计算机喜欢看的是XML/JSON格式固定的数据。
EXCEL虽然灵活机动，但是格式很难保证，实际项目里面一个EXCEL模板发出去，千千万万个EXCEL模板回来，事实证明只要有人类干涉的数据，很难保证一致性，所以最好在数据传递过程中人类别参与修改和填写。
1.1没有AUTOSAR定义的软件架构之前的工作流是怎么的呢：
OEM>DBC/EXCEL矩阵>嵌入式工程师手撸代码
EXCEL矩阵示例
这种工作流的好处是灵活性强，工程师很全能。对小的控制器供应商很友好，毕竟AUTOSAR协议栈不便宜呢。
1.2基于AUTOSAR定义的软件架构的工作流：
OEM>ARXML>Supplier>基于AUTOSAR配置工具自动生成代码<例如Rte_xx.h>
这种工作流的好处是减轻了代码编写和维护的工作量，有点像麦当劳，味道基本是一致的。
坏处是使得嵌入式工程师的稀缺性降低，参与的公司玩家所需门槛不低。
从上面的工作流可以看到，最开始的嵌入式工程师的软件架构都在自己脑子里，一千个嵌入式工程师就会形成一千种软件架构，对于OEM来说基本接触不到软件架构。
AUTOSAR标准的出现，使得OEM在软件设计之初就能够参与到软件开发中，从而慢慢提高了对于整车开发的掌控力，对应的也削弱了供应商的话语权。
02AUTOSAR中的软件架构
AUTOSAR的软件类型中从大类上来分只有两种SWC：AtomicSWC和Compostion
AtomicSWC：SWC是原子级SWC，不可再拆分，每一个AtomicSWC都会生成对应的一套.c/.h代码文件。
Compostion：起到管理和组织SWC的作用，本身不会生成代码
AtomicSWC可以分类为Application，Sensor/Acutator，Calibration等，目前的设计工作中，大部分还是用的前面两种。
AtomicSWC的Port上需要定义PortInterface，只有持有相同PortInterface的Port才能够进行对话。
Port和PortInterface也是有种类的，下面两种是用得最多的：
AtomicSWC分了两级，一个是SWCType，另一个是SWCPrototype。SWCType的意义是提高软件的复用度。不同项目里面的可以用同一个SWCType（也就是代码框架完全一样），不用重复造轮子了。
下图中，左边SWCType需要定义SWC+Port(准确来说应该是PortPrototype，因为SWCType上，没有PortType，这个不细看标准还真看不出来)+PortInterface(它会关联DataElement+Adt/Idt)
右边是将SWCType被实例化为SWCPrototype，对于DoorSig这个SWCType，它被实例化了两次，分别成为FrontDoorSig和RearDoorSig。
以上红色字体代表PortInterface；橙色字体代表PortName
以Sender/Receiver为例，工具会自动生成相应的应用层代码，生成的规则如下：
PorvidePort:Rte_Write_
_
ReceiverPort：Rte_Read_
基于上面的信息，在蓝色块DoorControl的两个ReceiverPort会生成如下代码
上面只是考虑到SWCType之间的连接关系，那么Compostion一般是怎么用到呢。
对于某一个控制器，由于AtomicSWC的不可拆分特性，所以至少需要一个Composition将其AtomicSWC包裹住，如下图所示。
总结：
AUTOSAR标准的诞生是基于无数工程师的踩坑得来的，在汽车如此大量代码的情况下，我认为软件架构设计是至关重要的，即便没有AUTOSAR，肯定也需要其他架构标准来规范代码开发。