SWC 流程 - 技术栈

一个arxml 存储SWC （可以存多个，也可以一个arxml存一个SWC）
一个arxml 存储 composition （只能存一个）
一个arxml 存储 system description (通过import dbc自动生成system)

存储SWC和composition的arxml文件分开，有效的实现了swc的复用。因为SWC的创建只是依赖于interface。【不依赖与Implementation data type，所以不用担心】所以拿着 SWC的arxml 和定义 Interface的arxml这两个文件，就可以在任意的project里面复用了。【创建composition可以直接import该SWC】

1. AUTOSAR自带文件

新建AUTOSAR project的时候，就会自己创建文件

"ISOLAR_PlatformTypes.arxml"

Implementation Data Type
BaseType
DataConstr

这个文件就干了一件事，通过BaseType和DataConstr，把IDT定义了，可以直接在c文件里面直接用【有了长度和符号，就可以被编译器识别了】

2. 预先准备的输入

系统工程师会自己创建一个文件

"01_TypesAndInterface.arxml"

Application Data Types
Interfaces

这个文件里面的ADT还没有与上面提到的IDT链接起来，这时只是名字而已（会在之后的SWC过程中link起来？）

Interfaces 下面创建了3个Sender-Receiver Interface实体，每个Interface下面都分配了data element。data element的数据类型是由ADT定义的

也就是说，我们是先有了需要这个三个通信接口的需求，然后才开始在AUTOSAR project里面去创建SWC的【可以把每个 Interface看作是函数吗，data element是函数的输入输出】

至此，用户的需求全部在 "01_TypesAndInterface.arxml" 文件中出现

3. 新建SWC

3.1 用户在ISOLAR内 create AXRML文件，用作存储之后创建的SWC的信息

然后右键arxml，即可创建SWC信息

注意，这个package是AUTOSAR很重要的概念

可以看到：每个arxml文件下只能有一个package，且各个arxml的package name不能一样。也就是说，不管是SWC还是BSW模块，他们的信息都是挂靠在package下面。

这个可以类别为c project， package就是c文件【这就是为什么package不能重名】，SWC/BSW可以看作是函数，可以放在任意的c文件下

3.2 用户在package下面创建SWC，并添加相应信息给该SWC

Port
- Interface - (Data Element + Application Data Type) 【一个SWC下面可以有多个port】
Internal Behavior
- Runnable Entity 【函数：一个SWC下面可以有多个runnable】
  - DataAccessPoint 【函数参数】
  - Timing Event 【函数的周期】
- DataTypeMapping 【Application Data Type 到 Implementation Data Type】

SWC是功能模块而不是函数的抽象，所以一个功能模块（SWC）下面一开始就要声明好要多少port，是输入还是输出port，有哪些data element参与传输【这样high level的抽象总结，方便接下来在system 级别确定/规划接口怎么跟外界连】【swc可用看作是.c文件，port定义可用看作是对应的.h文件】
SWC跟外界通讯的port定义完成以后，接下来就是SWC内部的函数定义了【函数名 + 参数 + 运行周期】。Runnable Entity就是函数名， Runnable Entity下面的DataAccessPoint 就是函数参数【通过分配之前port下面的interface下面的data element实现】
每个package下面都要有DataTypeMapping，或者说每个SWC下面都要有DataTypeMapping，可用看作SWC是.c文件，而转换ADT - IDT的DataTypeMapping就是对应的**.h 文件**

一个port下面只能有一个Interface

port只做一件事情，确定传输方向是输入还是输出

一个arxml下面可以有多个SWC，但是为了复用最好还是一个SWC一个arxml文件

过程是怎样，在哪个界面操作的不重要，重要的是理解，tool给我们提供了哪些可用的功能

Port是SWC最重要的概念

可创建的Port 只有 Pport 和 Rport 两种，用来表示方向，是send还是receive 数据

而可以被分配到Port下面的Interface则分为 sender/receiver 和 clien/server 两种【Interface已经在"01_TypesAndInterface.arxml"文件里面事先被system engineer定义好了，我们在接下来的步骤中不会涉及到新建或者修改Interface的定义】

可以将SWC看作是一堆函数集合抽象出来的一个统一实体，比如将雨刷控制器的所有相关函数统一放在一个SWC里面。而给SWC分配Interface，就是让SWC里面的函数可以通过interface下面的data element与外界通信【外界指其他SWC或者com来的CAN signal】

sender/receiver 和 client/server 接口的区别，以及生成的code的区别：

All the Runnables of an SWC只能被map到同一个core上（对多核ecu而言）

4. 新建一个Composition

，并将之前创建的多个SWC之间的port连接起来

新建一个arxml文件，【以及对应的package，用来存储这个composition的所有信息】右键arxml，即可创建composition

在composition里面把需要的SWC全部添加进来，然后再assembly connector里面可以把port连接上

5. 导入CAN dbc

，包括了Signal，PDU，ECU等系统信息

通过import dbc文件，tool会自动生成一个或多个arxml，自动将dbc文件里面的Signal，PDU，ECU等信息转换到这些arxml文件内，用来以AUTOSAR的格式存放dbc的信息，相当于一个DLL库【并且会生成COM module，里面有各个CAN signal】

6. 新建一个system description

，system level的核心配置都在这个文件里面进行

右键新建system，会自动生成一个arxml，此为system description

system description是 system level配置的核心文件，有两大功能

SWC to ECU mapping: 将 composition的那些SWC分配到各个ecu【system description相当于库文件，里面的ECU等信息会被自动识别出来等待被调用】
System Data mapping: 将SWC的port里面的需要和外界通讯的data element与刚才system extract里面的CAN signal连起来【system description相当于库文件，里面的system signal等信息会被自动识别出来等待被调用】

每次更改过system description，都要运行 Create Ecu Extract 来重新生成 EcuExtract.arxml，使改动生效

7. EcuExtract生成RTE

，将之前在SWC中创建的Runnable Entity分配到Task上

EcuExtract.arxml是在对system extract.arxml文件执行Create Ecu Extract操作之后，自动生成的。

RTE editor里面包含RunnableToTaskMapping的界面

新建 Task，设置period
将unmapping runnable拖拽分配到Task下面

至此实现了

函数名的创建
函数参数的创建
函数的周期性调度

不配置DataTypeMapping，就会导致c code里面只有函数框架，没有对应的data read/data write。因为ISOLAR不知道这些变量正确的implementation data type是什么，从而无法生成

IDT和base type相连，相当于用IDT给c data type重命名了一下，从而满足了MISRA的要求

从c语言的角度去理解，SWC的创建是是什么样的

这个右键component，直接生成code真好用，要好好利用上

RTE实际生成的文件是什么？

生成RTE之前，需要做什么，先生成 system extract 和 ecu extract吗？

OSNeeds.arxml 是干什么的

我现在有一个SWC，已经生成函数了

为什么我在EthSwt_CDD里面新建了port，但是在system extract的System data mapping里面根本就没有对应的port可以和system signal相连起来？

我想验证的是，对component右键生成代码的时候会不会把我在函数里面手写的code覆盖掉？

答：不会 tool在生成代码的时候，/* PROTECTED REGION */ 里面的code不会被覆盖掉

从c代码的角度，SWC的创建分两种

在函数内读取变量（其他SWC内部的变量）
在函数内调用函数（其他SWC内部的函数）

通过 sender/receiver interface，实现了第一点：【RTE传输对象是Interface下面的DataElement】

在各自的SWC的runnable里面添加对应的Pport或者Rport【不要忘了在data mapping里面将ADT和IDT对应起来】，即可右键component生成下入所示的runnable函数框架（存储在src/asw文件夹下的一个.c文件里面，跟rte没有关系.）。【右键生成代码的时候不会覆盖掉PROTECTED REGION里面的code】

然后在composition的assembly connector里面将两个port下面的dataelement连接起来，生成RTE的时候rte.c里面就会生成这些个Rte_IRead, Rte_Write函数实体，从而实现数据传输【RTE只会生成rte.c，不会生成/更新上面的component.c 文件】

通过 client/server interface, 实现了第二点: 【RTE传输对象是interface下面的Operation(Event)】

原理其实是client runnable内部通过set event，来触发server runnable的运行。

实现分三步

client SWC的runnable里面设置server call point来调用client/server interface下面的Operation【其实就是event】
server SWC里面设置runnable为OperationInvokeEvent出发
然后在composition的assembly connector里面将两个SWC的interface下的Operation连起来即可

函数调用想传递参数的话，通过ArgInOut实现【定义interface的时候，Operation本来就跟Arguement绑定好了，所以是全自动的，不需要在ISOLAR里面额外操作】

只要保证两个SWC的port下面添加的是同一个interface，composition里面就能把这两个Operation(event)连接起来

1 需求

传输 data 和调用函数

2 为满足需求创造的概念： interface

operation: 调用函数

data element：传输data

想想创建一个diagnostic SWC的流程