Autosar OS IOC

背景和基本原理

The IOC implementation shall be part of the Operating System

IOC和操作系统紧密相关，是操作系统实现的一部分

The IOC is a third type of communication, in addition to
Intra OS-Application communication: Always handled within the RTE
Inter ECU communication: Already available via well defined interfaces to the
communication stack (COM)

IOC 是除了Intra OS-Application communication，Inter ECU communication之外的第三种通信方式

In systems with only one core, the IOC can be omitted completely, if just one OSApplication is available, or if no OS-Application uses memory protection
mechanisms

在单核系统中，如果只有一个OsApplicationn或者没有使用内存保护，那么可以把IOC模块去除。

General purpose

The IOC provides communication services which can be accessed by clients which
need to communicate across OS-Application boundaries on the same ECU

IOC提供同一个ECU上跨OSApplicatiion的通信服务。

The RTE uses IOC services to communicate across such boundaries. All
communication must be routed through the RTE on sender (or client) and on receiver
(or server) side

Direct access to IOC services by clients other than the RTE is currently not
supported, but possible, if the client (e.g. a CDD) provides a hand written or
generated IOC Configuration Description as specified and specific callback functions
if necessary. Only sender/receiver communication is supported however by the IOC

IOC通过RTE的sender/receiver来实现。

Software Components and/or BSW modules located in the same OS-Application
(and hence on the same core) should not communicate by invoking IOC services.
This would be less efficient than communication via RTE only. However, in case of
IOC supported N:1 communication, if not all of the senders and the receiver are in
the same OS-Application the IOC must be used

同一个OSApplication的模块不要通过IOC通信，效率较低。当然，如果不是所有的senders和receiver在同一个OSApplication内的情况除外。

The IOC has to guarantee data consistency in inter OS-Application and inter core
(Multi-Core systems) communication,

IOC要负责数据一致性。

IOC functionality

Communication

1:1, N:1 and N:M (unqueued only) communication are supported by the IOC

The IOC allows the transfer of one data item per atomic communication operation. A
data item can either be a value for atomic basic data types or a reference for
complex data structures. The data structure must be implemented as a single
memory block, however. This way the data item can be transmitted in one piece. The
IOC does not need to know the internal data structure. The basic memory address
and length (which can be calculated from the type of the data item) is sufficient. The
IOC does, e.g., not support a conversion of endianness between cores.

IOC 允许每一次原子通信操作传输一个数据，这个数据可以是原子数据类型，或者一个复杂数据结构的引用，这个数据结构必须是一个单独的内存块，每次传输的时候只需要知道内存块的地址和长度就行了。

Transferring more than one data item in one operation is also supported for 1:1
communication only. In this case several types and memory addresses have to be
used by the IOC function. The advantage compared to sequential IOC calls is that
mechanisms to open memory protection boundaries and to notify the receiver have
to be executed just once. Additionally, all data items are guaranteed to be consistent,
because they are transferred in one atomic operation

IOC只有在1:1的通信中才允许一个传输多个数据。这种通信方式可以降低额外的通信开销，也可以保证数据的一致性。

The IOC provides both, unqueued (Last-is-Best, data semantics) or queued (First-InFirst-Out, event semantics) communication operations. If present, the IOC internal
queue has a configurable length.

IOC提供了unqueued和queued两种通信操作。

Each atomic communication operation gets specified individually by its own
description block in a Configuration Description with regard to sender, receiver, data
type(s), notification, and queuing

每一个原子通信操作都有自己的配置。

Notification

The IOC optionally notifies the receiver as soon as the transferred data is available
for access on the receiver side, by calling a configured callback function which gets
provided by the user of the communication.

当传输的数据可用时，IOC调用配置的callback function来通知receciver。

A possible implementation is to trigger an interrupt (Cat. 2) mechanism to invoke the
callback function from the ISR on receiver side, or to use a microcontroller supplied
trap. The callback function shall be efficient and compact, because it is called from
within the ISR.

Notification 的实现方式可以在receiver侧通过二类中断触发callback function，或者通过微控制器提供的trap来实现方式。callback function应该是高效的，因为它是通过中断调用的。

IOC interface

The interface between RTE and IOC shall be similar to the interface between
Software Components and the RTE, i.e. by generating specific interfaces for each
communication operation instead of providing a generic API.

RTE和IOC的接口和RTE和SWC的接口类型。

There is a unique set of IOC service APIs (at least to send and receive data) for each
data communication specified in the IOC Configuration Description. Each service API
gets generated and can be identified by a unique Id for each data communication. In
case of N:1 communication, each sender must use its own API.

每组通信都必须要有自己的唯一的API。

The same IOC service API and hence the same 1:1 communication can get used by
more than one runnable inside the same SWC both on sender and on receiver side.
However, the IOC functions are not reentrant, because otherwise e.g. spinlock errors
could occur in case the IOC uses spinlocks in Multi-Core systems. The same IOC
API must therefore only be called sequentially. This is no problem, if all runnable
entities are scheduled within the same TASK, otherwise the caller is responsible to
guarantee that the same IOC API is not called again before it returns from a different
invocation

由于IOC函数是不可重入的，所以在多核系统中有可能会出现自旋锁错误。

Software Components may access the IOC only via RTE. Only the RTE decides
which communication services to use to support the communication needs of
Software Components.

SWC可能通过RTE来访问IOC。RTE决定为SWC使用哪种通信方式。

Direct access to IOC services by BSW modules is not supported, but allowed for
CDDs and other modules, if unavoidable. The clients have to provides a hand written
or generated IOC Configuration Description as specified

BSW直接访问IOC服务是不支持的，CDD和其他的模块是允许的，但是要手写IOC配置描述。