CP Autosar 核间通讯

核间通讯

目录



IOC overview

IOC ：inter OS-Application COmmunicator

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

[img=552.010009765625,274.9999694824219]https://mmbiz.qpic.cn/sz_mmbiz_png/Vgbm9ibpszia6q9ABofo7KlkVIPcdUQut2qTUWkYciafr2Felia1W3lVm60hCLbsPtMprjaGUSpXXDT1OBMDcAXzfQ/640?wx_fmt=png[/img]

IOC overview         

IOC General purpose

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

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

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

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

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

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

[img=552.010009765625,231.0]https://mmbiz.qpic.cn/sz_mmbiz_jpg/Vgbm9ibpszia6q9ABofo7KlkVIPcdUQut2DAHeB5Re2eh41szwcXHIagCibc0yN8kbGc9vhCf42DkhmDlNWwTrD3A/640?wx_fmt=jpeg[/img]

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 通信。

[img=529.010009765625,219.0]https://mmbiz.qpic.cn/sz_mmbiz_png/Vgbm9ibpszia6q9ABofo7KlkVIPcdUQut2Tug8LTVXZZam3mjzulQibHt9SXaP5FzxTy8pSx4B0Yy6G40ZjJjtGeA/640?wx_fmt=png[/img]

IOC         
   

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

[img=552.010009765625,331.010009765625]https://mmbiz.qpic.cn/sz_mmbiz_png/Vgbm9ibpszia6q9ABofo7KlkVIPcdUQut27kn0mvutOe8pTWGyafwQIic6r8Mkzg6SjMsjsum9pSdbtADNeibfDMBg/640?wx_fmt=png[/img]

IOC without notification         

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

[img=552.010009765625,228.0]https://mmbiz.qpic.cn/sz_mmbiz_png/Vgbm9ibpszia6q9ABofo7KlkVIPcdUQut2YW4nfUNIm3lSXnxOa7B0wqcVsClSvUhj64P716kzhdcVF2ZFre7BlQ/640?wx_fmt=png[/img]

last is best         

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

[img=552.010009765625,322.0]https://mmbiz.qpic.cn/sz_mmbiz_png/Vgbm9ibpszia6q9ABofo7KlkVIPcdUQut2pXGzWDnapoUWOjibgK71j1twT7wxvD8YF6v4BqcINfgY6ibYHiaP5R1fw/640?wx_fmt=png[/img]

有queue带有通知的ioc         

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

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

[img=455.010009765625,438.010009765625]https://mmbiz.qpic.cn/sz_mmbiz_png/Vgbm9ibpszia6q9ABofo7KlkVIPcdUQut2xfYxl46cH3icGFW8d5r9fWxb58iaprTQoEZuFicB9uz5KpX5EJp3BhKhQ/640?wx_fmt=png[/img]

iocNeeds.arxml         

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

[img=348.0099792480469,236.0]https://mmbiz.qpic.cn/sz_mmbiz_png/Vgbm9ibpszia6q9ABofo7KlkVIPcdUQut24Gibt7roxbLTT5oKfvCiaOM7KR4olQ1uHDiavMhAw2Wo0iaaoyCMTyuBIw/640?wx_fmt=png[/img]

gen os         

通知 notification

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

[img=552.010009765625,328.010009765625]https://mmbiz.qpic.cn/sz_mmbiz_png/Vgbm9ibpszia6q9ABofo7KlkVIPcdUQut2oy4vB4CJboRFOHiaHiaYv24tTrRVCWD1LuYOdFCs4m392Jm2axibHW9fg/640?wx_fmt=png[/img]

IOC with notification by RTE         

1中断

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

1任务轮询

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

IOC 实现

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

[img=552.010009765625,245.0]https://mmbiz.qpic.cn/sz_mmbiz_png/Vgbm9ibpszia6q9ABofo7KlkVIPcdUQut2a9Lz8wZZtg6Gk2UFYdNY6NAJuFCo9cCILob66hjPssBKtUPtEaa87Q/640?wx_fmt=png[/img]

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

[img=552.010009765625,241.0]https://mmbiz.qpic.cn/sz_mmbiz_png/Vgbm9ibpszia6q9ABofo7KlkVIPcdUQut24gXVFbLRVmZvAs0PT17DDnnLQe5sdjTric3GKrGoWoGekWxiaMP6Zbzg/640?wx_fmt=png[/img]

RPC

RPC ：remote process call

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

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

我们来举个例子。

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

[img=552.010009765625,229.0]https://mmbiz.qpic.cn/sz_mmbiz_jpg/Vgbm9ibpszia6q9ABofo7KlkVIPcdUQut20qliakPZEicws4pOXMmpluJCqAVZQeZZMx0yQ2HN01NKpUGsNGUrMlVA/640?wx_fmt=jpeg[/img]

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

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

Satellite

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

[img=404.010009765625,460.010009765625]https://mmbiz.qpic.cn/sz_mmbiz_png/Vgbm9ibpszia6q9ABofo7KlkVIPcdUQut2PrutGjmL5tYUibUqG3CPp8cFzc9CqSpYuQ9esvrfOsr19jGsw9XaUjQ/640?wx_fmt=png[/img]

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

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

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

Proxy

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

[img=552.010009765625,284.0]https://mmbiz.qpic.cn/sz_mmbiz_jpg/Vgbm9ibpszia6q9ABofo7KlkVIPcdUQut2ppTiaZGOImibAo9xFFhu8rFw1dhTTLep4RzJzweD09dLX6YeLXoiczduQ/640?wx_fmt=jpeg[/img]

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