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】

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

1. 在函数内读取变量（其他SWC内部的变量） 
2. 在函数内调用函数 （其他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的运行。

实现分三步

1. client SWC的runnable里面设置server call point来调用client/server interface下面的Operation【其实就是event】
2. server SWC里面设置runnable为OperationInvokeEvent出发
3. 然后在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的流程