CP Autosar 核间通讯

admin 2024年3月8日22:33:33评论9 views字数 2173阅读7分14秒阅读模式

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

CP Autosar 核间通讯

01

IOC overview

IOC :inter OS-Application COmmunicator

负责os application 之间的通信,特别是跨核或者内存保护边界的通信。其实现与os 和 rte 有着紧密的关系。

CP Autosar 核间通讯

IOC overview

02

IOC General purpose

IOC 必须保证在OS-Application 之间,或者 core 之间通信时数据的一致性。为了达到这个目的。我们会对IOC 提出几个要求。

  • 在队列中,通信操作的顺序应该保持不变。在N:1 通信情况下,来自不同源头的消息的顺序是必须有保证的;

  • 在一次通信操作中,发送的所有数据内容保持不变,也就是说每次通信操作都被视为 原子操作;

  • 锁机制,这是IOC 用来保证数据一致性的标准。

一般来说,保证数据的操作原子性,是通过下图的spinlock 来实现的。在系统设计的时候,原则来说当spinlock 激活的时候,两个core, 只有当前写入,或者读取的任务是可以操作这个内存的。一般通过关闭中断的方式来实现。 

也就是说,如果有大量的spinlock的存在,会导致系统的运行实时性受损。

CP Autosar 核间通讯

03

IOC features

IOC 有两个重要的features

数据收发 communication

IOC 仅仅提供数据收发( signal passing)。在RTE 与 BSW 的标准模块中,会把 C/S 接口,转化为S/R 的通信。简单地说 比如core1想调用core0 的BSW 服务。实际上是让core0 执行完,通过SR 把数据返回给core1. 这个具体的我们会在后面说到。

IOC 有 1:1, N:1, N:M 通信。

CP Autosar 核间通讯

IOC 本身不需要知道数据本身的类型和具体内部的数据。只是提供了buffer. 需要知道数据的地址与数据的长度即可。

CP Autosar 核间通讯

IOC without notification

在一次操作中传输多个数据项 也支持1:1通信,在这种情况下, IOC函数必须使用多个类型的内存地址。与顺序的IOC 调用相比,它的优点是打开内存保护边界和通知接收的机制只需要执行一次。并且所有的数据都保证是一致的。因为操作的过程是原子操作。

CP Autosar 核间通讯

last is best

IOC 也提供了非排队,这意味着有的数据是会丢失的。所以原则是 last is best的原子。如果是queue的呢,就是先进先出,first in first out. 在这种通信方式,IOC 需要配置队列的长度。

CP Autosar 核间通讯

有queue带有通知的ioc

在设计的角度来说,IOC 是在 iocNeeds.arxm   中体现,这个文件又是RTE generation的过程生成的。

RTE generation 根据具体的runnable mapping 关系,和使用的变量,interface 得知 signal 所属的os-application 与 core. 比如下图

CP Autosar 核间通讯

iocNeeds.arxml

在生成os的时候,需要添加这个文件,如下。

CP Autosar 核间通讯

gen os

04

通知 notification

一旦传输的数据可以在接收端访问,IOC 通过通知的方式,接收端来执行相对应的回调。一般有下面两种实现方式。 

CP Autosar 核间通讯

IOC with notification by RTE

中断

实现触发2类中断,从接收端的ISR 调用回调函数,或者使用trap, 回调函数需要设计的紧凑,时间短,因为他是中断的内容。

任务轮询

在接收端,任务轮询SR 接口的变化,当有变化的时候,调用相对应的函数。

05

IOC 实现

通过上面autosar 对IOC 的需求约束。工具厂商提供了三种实现机制。

CP Autosar 核间通讯

网上找一张把三种机制都画出来的图。我们根据前任的经验,来总结一下三种机制的过程与具体的细节。

CP Autosar 核间通讯

06

RPC

RPC :remote process call

从autosr 内存保护的角度来说,不同的core 是不允许互相调用的,细节可以翻一下我这边之前的文章,描述保护机制的。

但是从上图来看,RPC 的接口是C/S 的接口 弧形+圆形。

我们来举个例子。

application3 想通过SWC b 调用 系统的 dcm 的接口 

CP Autosar 核间通讯

这样有个优点就是架构很清晰,表面上就是core1 直接调用了core0 的服务。实际上内部RTE 做了大量的spinlock 以及 中断激活 任务,来实现同步的机制。有大量的时间资源被消耗掉。

如果是异步的机制,可以不使用中断。而是通过任务的轮询方式来执行服务端的任务。

07

Satellite

这种方式BSW 模块,也就是工具厂商实现好了不同的core / os-application 里面有一定的BSW 映射,相当于独立的core 调用独立的bsw 模块来实现的机制。    

CP Autosar 核间通讯

但是最终走的还是core0 的硬件资源接口,只是BSW 协议栈给自己提供了一条快速通道。

可以说这样的操作,可以方便应用层的部署与配置。但是对于mcu 硬件资源本身的角度来说,没有改变(其实三种方式都没有改变,只是运行的资源有所改变)。

所以这种方式我给出的结论是 内存消耗较大。

08

Proxy

这种方式,就是比较传统的把CS 变成 SR. 什么意思呢。我们举个例子。

CP Autosar 核间通讯

就是说core1的swc想调用系统接口。但是呢 core1上面没有,需要到core0。这时候,我们可以在core0 上做出来 core0的bsw的接口,通过swc a 来帮 core1上面的swc 来调用。然后以SR的接口传给 core1. 这就叫做proxy。

 精品活动推荐 

CP Autosar 核间通讯
CP Autosar 核间通讯
CP Autosar 核间通讯

原文始发于微信公众号(谈思实验室):CP Autosar 核间通讯

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2024年3月8日22:33:33
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   CP Autosar 核间通讯http://cn-sec.com/archives/2560859.html

发表评论

匿名网友 填写信息