AUTOSAR SWC设计概述

1.SWC概述        

        SWC，全称Sofeware Components，运行在RTE之上，属于应用算法逻辑这一层，如下图：

编辑

        由1.AUTOSAR的架构及方法论中我们了解到该框架的提出就是为了减少平台移植成本、加快研发效率；这也就是说在AUTOSAR框架下，SWC作为组件是需要被重用的，意味着一个成熟的软件功能组件可以被打包成一个库，然后哪里需要哪里搬。

        做个类比，把SWC这个东西想象成乐高积木，可以按照我的想法任意使用SWC来构建我想要的系统；我不用管SWC里面具体是什么材料构成的（具体建模细节），只需要知道他有什么功能，就可以用来拼接，这样极大地减轻了开发工作量。（当然，最开始SWC里的建模是必不可少的，具体详见 Create AUTOSAR Software Component in Simulink）

        但是光有这个思想和框架还不够，为什么呢？再做个类比，带兵打仗临时东拼西凑一队人马，这一对人想象成SWC，但是有可能他们语言不通呀，怎么办？大家协商一个易于理解并且简单的口令或者手势，这样一有紧急情况，通过这个口令或手势就可以快速行动。这里的口令或手势就引出了我们今天要重点讨论的基于RTE的SWC 通信机制与ports。

2.SWC通信机制和Port详解

        在AUTOSAR_EXP_VFB的Spec 3.1章节，明确提出，每一个SWC都有所谓的“ports”，用于与其他SWC进行交互。

        根据port的输入输出方向，又分为Provide-Port(PPort)、Require-Port(RPort)和PRPort；这么说起来有点抽象，还是以一个图说明：

        PPort与RPort相连接，通常是P-Port提供数据或者服务，R-Port接收数据或者请求服务；数据很好理解，这里不讲；关于服务会在后面具体讲解，这里简单说即是一个SWC（Client）通过某种方式去调用另一个SWC（Server）的服务，Server处理完后会返回结果。

        那么，AUTOSAR中定义了多少port类型呢？如下表：

Port类型	用途	PPort	RPort	PRPort
Sender-receiver	用于数据传输交互，可以一对多，也可以多对一	编辑	编辑	编辑
Client-server	server提供服务，多个client可以调用其服务	编辑	编辑	编辑
Parameter Interface	主要是用于标定的接口（实际开发好像没用到）	编辑	编辑
Non-volatile Data INterface	提供NvRam block中元素级别的访问	编辑	编辑	编辑
Trigger Interface	SWC可以触发另一个SWC里的某些功能执行	编辑	编辑	编辑
Mode Switch Interface	同步当前Ecu的模式，或者更新模式	编辑	编辑	编辑

       那么一个座椅加热的SWC有可能就长如下这样：

        此外，对于上述每一种类别，在图标上都有很多变体，具体大家可以详见AUTOSAR_EXP_VFB 3.3章节；这里就以sender-receiver为例简单说明：

编辑	RPort	读取或者使用数据元素的具体值
编辑	PPort	提供数据元素的具体值
编辑	RPort	从一个AUTOSAR service中获取数据元素的具体值
编辑	PPort	给一个AUTOSAR service提供具体值

        AUTOSAR Sevice就是我们通常意义的BSW这一层的内容，基本上看到图标底色是黑的，多半都是AUTOSAR Sevice。从这里，我们就可以看到AUTOSAR的精细之处，即使数据来源也是进行了分层和解耦，如下：

编辑

        既然数据、服务等都可以通过port来获取，那么我们就要来看看SWC里面是怎么用这些数据和服务的，这又引出了今天的第二个话题 Runnable

3.SWC内部行为--Runnable

        其实，对于做过AUTOSAR基础软件的朋友来讲，Runnable就是由软件开发人员写的代码或者模型生成的代码，需要周期调度或者事件触发，如下：

Runnable通常属于一个SWC，但是需要在工具里配置它的RTE触发事件。

        那么具体有哪些方式可以触发Runnable呢？

        通常包含时间周期触发、Data-Received触发、服务调用触发等。

        到这里其实对于SWC的概述就已经结束了，但是我原来在做Devoloper配置时经常被里面的数据类型搞晕，比如说IDT、ADT等等；所以这里再衍生一节（其实是为了达成3000字目标，哈哈哈）

4.RTE 数据类型解惑

         我们还是以S/R(Sender-Receiver)接口为例，它是用于传输数据元素的具体值的，那么这个值是必有数据类型定义的，如下图：

        你看，speed数据类型是SpeedType，odo是DistanceType。这是给应用层看的，但实际它 传到BSW上应该是什么类型呢？这里就引出了AUTOSAR的三种数据类型

• ApplicationDataType

        用于RTE上设计SWC的应用类型，一个抽象概念，简称ADT。

• ImplementationDataType

        相当于C代码级别的数据类型，有点类似typedef，简称IDT；

        ADT必须映射到一个IDT上面

• SwBaseType 

       ImplementationDataType对应的实际平台支持的数据类型

5.SWC定义

        有了上述基本概念，我们现在来看如何定义一个SWC。

        首先我们要有这个思路：SWC开发者应该使用ADT这样抽象概念来定义数据类型；因此很有可能不同供应商的SWC内部使用的数据类型是不一样的，因为有可能A用float类型来定义车速，B却用32bit整形来定义车速。

        有了这个前提，我们来定义ADT。

        如定义ADT：开关状态SwitchSts，值为On/Off；IDT使用Boolean类型；但是这个ADT实际上不会出现在生成的C代码中。

        定义好了开关量，接下来就要使用port将两个SWC连接起来，如下：

        因为我已经给SWC定义了S/R接口，使用SwitchSts 。我们就可以在arxml里看到如下定义：

        最后我们来定义SWC这个组件的属性，包括SWC名字、Port定义、Runnable、触发事件、数据类型映射等，arxml模板如下：

        当然，我们不会使用arxml去编辑，那就太low了，通常配置工具是Vector的DaVinci Develpoer或者ETAS的 RTA-RTE等。但是arxml、SWC和代码的联系我们还是要略懂一二：

编辑

        PS：最后，突然想到我们经常在配置中看到的SR通讯的Implicit\Explicit，总结如下：

编辑

         从具体代码来看：

Implicit：直接给数据的地址

编辑

 Expllicit：通过API去访问，相当于一个搬运的过程编辑

6.小结

        上面几节，对SWC的通信机制、port类型和数据类型进行描述，有了这些基本概念，基本上在配置RTE的时候我觉得是够用了。

        就这样吧，晚安！