文章目录

• ​​1.SWC（Software Component）​​
• ​​2.Runnable Entity​​
• ​​3.Port​​
• ​​4.Interface​​
• ​​APL和CDD​​

1.SWC（Software Component）

SWC是最常见到的一个概念了，细说的话还可以分成Atomic SWC和Composition SWC。

• 一般单独说的SWC指的是Atomic SWC。
• SWC最形象的对比就是一个.C文件了，那么Composition SWC顾名思义就是.C文件的集合，体现在代码上，就是保存.C文件的文件夹。

2.Runnable Entity

可运行实体，其实就是.c文件内的函数而已。

• 一个SWC可以包含多个Runnable Entity，就是一个.C文件可以包含多个函数，每个函数可以执行一个特定的操作。
• 并且Runnable Entity必须要挂在Task上，就像函数如果只是放在那里没有被调用的话，也不起作用，总归是要挂在某个Task上才会被运行

3.Port

Port是依附在SWC上的概念，比如配置工具配置SWC后，需要配置这个SWC的Port。

• 其实也好理解，如果一个.C文件孤零零的放在那里，与别的C文件没有任何数据交互，那么作为一套代码中的一个C文件，根本没法发挥作用，所以必然在SWC上需要配置上或者输入（R-Port）的或者输出（P-Port）的Port。

但是如果只是Port这个概念的话，实在是太难以理解了，但是如果顺着SWC等于C文件这个思路考虑的话，当C文件之间进行数据交互会是用什么方式呢？

• 那么最简单的方法就是“全局变量”。实际上，在配置好的代码中，可以发现，如果我为SWC1和SWC2之间配置了一个SR的interface的话，SWC1中会有一个函数Rte_Write()，里面会对一个全局变量进行赋值。而另一边SWC2的里面会有一个Rte_Read()的函数，来读取这个全局变量。通过这种方式，达到了数据的交互。

4.Interface

在配置RTE的时候经常会出现这个词，在使用工具配置的时候，如果不太清楚Interface和Port等等的概念的话，即便机械的按照流程配置下来，也依旧不理解，甚至会导致换了一个配置工具后，因为不明白原理结果寸步难行。

通过我自己的配置经验，我觉得Interface是一个抽象的概念，是一个无法直接在代码中对应的概念。

• SWC可以比较准确的对应为.C文件，Interface在配置工具的语境下包含了输入输出Port，以及两个Port之间的连接关系的一个集合。
• 在工具中，会为一个Interface命名，再将输入输出Port连接到这个Interface上，这样RTE层内部如何实现两个Port之间的代码维度的连接，就是工具在生成的了，这个时候内部生成的不管是全局变量抑或是宏定义等等，都会基于这个Interface的元名称进行扩展。正因此，才会需要在工具层面上具象化Interface，并给他一个命名。

总而言之，SR-Port（Sender-Reciever）主要是进行数据的传输，而另一方面CS-Port（Client-Server）则是调用另一个SWC中的服务，或者理解成调用另一个函数。

• 具体在代码中就会变成，SR是对一个全局变量的操作，当然如果只涉及SWC内部的传输的话，就变成Static变量了。
• CS的则是在函数中调用另一个函数，特别是另一个SWC的函数才会需要经过RTE来调用，这个另一个SWC可以是本ECU内部的，也可以是跨ECU的。不过对于调用方的SWC，跨不跨ECU并没有什么区别。

APL和CDD

如果说什么是APL的话，我觉得最直观的说法就是APL中包含了所有的SWC，或者说SWC组成了APL。- 但是CDD的存在又比较特殊，原因在于CDD虽然在BSW层中，但是实际上是没有被AutoSar实现的部分放在了CDD中，CDD里也有很大一部分手写的代码。

• CDD与RTE的交互也是通过AutoSar接口，也有人说可以将CDD看成是比较特殊的SWC。
• 参考：什么是SWC，Runnable，Port 和 Interface