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里也有很大一部分手写的代码。