AUTOSAR中的软件架构思考

01  为什么需要软件架构

人类喜欢看的是EXCEL/WORD/图片这种直观的表达方式。

计算机喜欢看的是XML/JSON格式固定的数据。

EXCEL虽然灵活机动，但是格式很难保证，实际项目里面一个EXCEL模板发出去，千千万万个EXCEL模板回来，事实证明只要有人类干涉的数据，很难保证一致性，所以最好在数据传递过程中人类别参与修改和填写。

但是想要让XML文件成为大家都能识别的内容，就需要大家遵循相同的SCHEMA<语法标准>。ARXML文件就是AUTOSAR组织定义的一种标准XML文件，里面可以包含软件架构+通信信息等。所有利益相关者基于该标准可以方便地进行对话。

1.1 没有AUTOSAR定义的软件架构之前的工作流是怎么的呢：

OEM>DBC/EXCEL矩阵>嵌入式工程师手撸代码

EXCEL矩阵示例

这种工作流的好处是灵活性强，工程师很全能。对小的控制器供应商很友好，毕竟AUTOSAR协议栈不便宜呢。

坏处是代码质量和工程师能力强相关。有点像咱们的中餐馆，味道好的非常好，差的非常差。

1.2 基于AUTOSAR定义的软件架构的工作流：

OEM>ARXML>Supplier>基于AUTOSAR配置工具自动生成代码<例如Rte_xx.h>

这种工作流的好处是减轻了代码编写和维护的工作量，有点像麦当劳，味道基本是一致的。

坏处是使得嵌入式工程师的稀缺性降低，参与的公司玩家所需门槛不低。

从上面的工作流可以看到，最开始的嵌入式工程师的软件架构都在自己脑子里，一千个嵌入式工程师就会形成一千种软件架构，对于OEM来说基本接触不到软件架构。

AUTOSAR标准的出现，使得OEM在软件设计之初就能够参与到软件开发中，从而慢慢提高了对于整车开发的掌控力，对应的也削弱了供应商的话语权。

由于ARXML文件里面可以包含软件架构+通信信息，我们就需要去了解其对于软件架构的相关定义。

02  AUTOSAR中的软件架构

AUTOSAR的软件类型中从大类上来分只有两种SWC ：Atomic SWC和Compostion

Atomic SWC：SWC是原子级SWC，不可再拆分，每一个Atomic SWC都会生成对应的一套.c /.h代码文件。

Compostion：起到管理和组织SWC的作用，本身不会生成代码

Atomic SWC可以分类为Application，Sensor/Acutator，Calibration等，目前的设计工作中，大部分还是用的前面两种。

Atomic SWC的Port上需要定义Port Interface，只有持有相同Port Interface的Port才能够进行对话。

Port和Port Interface也是有种类的，下面两种是用得最多的：

Atomic SWC分了两级，一个是SWC Type，另一个是SWC Prototype。SWC Type的意义是提高软件的复用度。不同项目里面的可以用同一个SWC Type（也就是代码框架完全一样），不用重复造轮子了。

下图中，左边SWC Type需要定义SWC+Port(准确来说应该是PortPrototype，因为SWC Type上，没有Port Type，这个不细看标准还真看不出来)+Port Interface(它会关联Data Element+Adt/Idt)

右边是将SWC Type被实例化为SWC Prototype，对于Door Sig这个SWC Type，它被实例化了两次，分别成为Front Door Sig和Rear Door Sig。

以上红色字体代表Port Interface；橙色字体代表Port Name

以Sender/Receiver为例，工具会自动生成相应的应用层代码，生成的规则如下：

Porvide Port:Rte_Write_

_

Receiver Port：Rte_Read_

_

基于上面的信息，在蓝色块Door Control的两个Receiver Port会生成如下代码

上面只是考虑到SWC Type之间的连接关系，那么Compostion一般是怎么用到呢。

对于某一个控制器，由于Atomic SWC的不可拆分特性，所以至少需要一个Composition将其Atomic SWC包裹住，如下图所示。

总结：

AUTOSAR标准的诞生是基于无数工程师的踩坑得来的，在汽车如此大量代码的情况下，我认为软件架构设计是至关重要的，即便没有AUTOSAR，肯定也需要其他架构标准来规范代码开发。

我也特别希望有个工程师交流的相关标准出台，例如必须将问题写下来，如何写会议纪要，如何追踪问题等。不然一个问题口头描述半天都让人听不明白真的好累啊......。

参考:AUTOSAR_TPS_SoftwareComponentTemplate