存储SWC和composition的arxml文件分开,有效的实现了swc的复用。因为SWC的创建只是依赖于interface。【不依赖与Implementation data type,所以不用担心】 所以拿着 SWC的arxml 和定义 Interface的arxml这两个文件,就可以在任意的project里面复用了。【创建composition可以直接import该SWC】
新建AUTOSAR project的时候,就会自己创建文件
“ISOLAR_PlatformTypes.arxml”
这个文件就干了一件事,通过BaseType和DataConstr,把IDT定义了,可以直接在c文件里面直接用 【有了长度和符号,就可以被编译器识别了】
系统工程师会自己创建一个文件
“01_TypesAndInterface.arxml”
这个文件里面的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.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
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而言)
,并将之前创建的多个SWC之间的port连接起来
新建一个arxml文件,【以及对应的package,用来存储这个composition的所有信息】右键arxml,即可创建composition
在composition里面把需要的SWC全部添加进来,然后再assembly connector里面可以把port连接上
,包括了Signal,PDU,ECU等系统信息
通过import dbc文件,tool会自动生成一个或多个arxml,自动将dbc文件里面的Signal,PDU,ECU等信息转换到这些arxml文件内, 用来以AUTOSAR的格式存放dbc的信息,相当于一个DLL库 【并且会生成COM module,里面有各个CAN signal】
,system level的核心配置都在这个文件里面进行
右键新建system,会自动生成一个arxml,此为system description
system description是 system level配置的核心文件,有两大功能
每次更改过system description,都要运行 Create Ecu Extract 来重新生成 EcuExtract.arxml,使改动生效
, 将之前在SWC中创建的Runnable Entity分配到Task上
EcuExtract.arxml是在对system extract.arxml文件执行Create Ecu Extract操作之后,自动生成的。
RTE editor里面包含RunnableToTaskMapping的界面
至此实现了
不配置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的创建分两种
通过 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的运行。
实现分三步
函数调用想传递参数的话,通过ArgInOut实现【定义interface的时候,Operation本来就跟Arguement绑定好了,所以是全自动的,不需要在ISOLAR里面额外操作】
只要保证两个SWC的port下面添加的是同一个interface,composition里面就能把这两个Operation(event)连接起来
1 需求
传输 data 和 调用 函数
2 为满足需求创造的概念: interface
operation: 调用函数
data element: 传输data
想想创建一个diagnostic SWC的流程