任务管理

1. 任务的安装

任务有两种安装方法：

single instantiation – which refers to the case where only one object or AUTOSAR software component instance will be derived out of the AUTOSAR software component description

单一安装：一个构件只能在一个ECU上安装一次。

multiple instantiation – which refers to the case where multiple objects or AUTOSAR software component instances will be derived out of the AUTOSAR software component description

多重安装：一个构件可以被复用，在多个应用中安装多次。

[rte sws 2001] The RTE shall be able to instantiate one or more AUTOSAR software component instances out of a single AUTOSAR software component description.

[rte sws 2008] The RTE-Generator shall evaluate the attribute supportsMultipleInstantiation of the InternalBehavior of an AUTOSAR software component description.

RTE生成器可以评估构件的多重安装属性。

[rte sws 2009] The RTE-Generator shall reject configurations where multiple instantiation is required, but the value of the attribute supportsMultipleInstantiation of the InternalBehavior of an AUTOSAR software component description is set to FALSE.

1. Single instantiation

单一安装：

TASK(Task1)

{

...

R1();

...

}

1. Multiple instantiation

多重安装：

TASK(Task1)

{

...

R1(Rte_Instance_component1_runnable1_1);

...

}

TASK(Task2)

{

...

R1(Rte_Instance_component1_runnable1_2);

...

}

1. RTE Events

The RTE is the sole entity that can trigger the execution of a runnable entity. The RTE triggers runnable entities in response to different RTEEvents.

RTEEvent是唯一能触发运行体运行的单位。

The most basic RTEEvent that can trigger a runnable entity is the TimingEvent that causes a runnable entity to be periodically triggered by the RTE. In contrast, the remaining RTEEvents that can trigger runnable entities all occur as a result of communication activity or as a result of mode switches.

最基本的RTE事件是周期性时间事件，其他的事件还有通信活动和模式转换。

The following subsections describe the conditions that can trigger execution of a runnable entity. For each triggering event the signature of the function (the "entry point") that implements the runnable entity is defined. The signature definition includes two classes of parameters for each function;

1. The instance handle – the parameter type is always Rte_Instance. (rte sws 1016)

2. The role parameters – used to pass information required by the runnable entity as a consequence of the triggering condition. The presence (and number) of role parameters depends solely on the triggering condition.

1. TimingEvent

Purpose: Trigger a runnable entity periodically at a rate defined within the software-component description.

（周期时间）

Signature: [rte sws 1131]

void <name>([IN Rte_Instance <instance>])

1. ModeSwitchEvent

Purpose: Trigger of a runnable entity as a result of a mode switch. See also sections 4.4.4 and 4.4.5 for reference.

（模式切换引起的）

Signature: [rte sws 2512]

void <name>([IN Rte_Instance <instance>])

1. AsynchronousServerCallReturnsEvent

Purpose: Triggers a runnable entity used to "collect" the result and status information of an asynchronous client-server operation.

（读取异步通信结果）

Signature: [rte sws 1133]

void <name>([IN Rte_Instance <instance>])

Notes: The runnable entity triggered by an AsynchronousServerCallReturnsEvent RTEEvent should use the Rte Result API to actually receive the result and the status of the server operation.

（还是需要使用Rte_Result API来读取数据）

1. DataReceiveErrorEvent

Purpose: Triggers a runnable entity used to "collect" the error status of a data element with "data" semantics (isQueued = false) on the receiver side.

（通信错误）

Signature: [rte sws 1359]

void <name>([IN Rte_Instance <instance>])

Notes: The runnable entity triggered by a DataReceiveErrorEvent RTEEvent should use the Rte IStatus API to actually read the status.

（还是需要使用Rte IStatus API来读取数据）

1. OperationInvokedEvent

Purpose: An RTEEvent that causes the RTE to trigger a runnable entity whose entry point provides an implementation for a client-server operation. This event occurs in response to a received request from a client to execute the operation.

（通知客户端读取数据）

Signature: [rte sws 1166]

<void|Std_ReturnType> <name> ([IN Rte_Instance <instance>],

[IN <portDefArg 1>, ...

IN <portDefArg n>],

[IN|INOUT|OUT] <param 1>, ...

[IN|INOUT|OUT] <param n>)

Where <portDefArg 1>, ..., <portDefArg n> represent the port-defined argument values (see Section 4.3.2.4) and

<param 1>, ... <param n> indicates the operation IN, INOUT and OUT parameters.

<portDefArg n> - 参数定义（参数位置可能会因为所在ECU不同而不同）

<param n> - 参数

The data type of each port defined argument is taken from the software component template, as defined in rte sws in 1361. Note that the port-defined argument values are optional, depending upon the server's internal behavior.

The operation parameters <param 1>, ... <param n> are the specified ArgumentPrototypes of the OperationPrototype that is associated with the OperationInvokedEvent. The operation parameters are ordered according to the OperationPrototype's ordered list of the ArgumentPrototypes. Return Value: If the AUTOSAR interface description of the client server communication lists possible error codes, these are returned by the function using the return type Std_ReturnType. If no error codes are defined for this interface, the return type shall be void (see rte sws 1130).

This means that even if a runnable entity implementing a server "only" returns E_OK, application errors have to be defined. Else the return types do not match.

1. DataReceivedEvent

Purpose: A runnable entity triggered by the RTE to receive and process a signal received on a sender-receiver interface.

（接收信号触发）

Signature: [rte sws 1135]

void <name>([IN Rte_Instance <instance>])

Notes: The data or event is not passed as an additional parameter. Instead,

the previously described reception API should be used to access the data/event. This approach permits the same signature for runnables that are triggered by time (TimingEvent) or data reception. Caution: For intra-ECU communication, the DataReceivedEvent is fired after each completed write operation to the shared data. In case of implicit access, write operation is considered to be completed when the runnable ends. While for inter-ECU communication, the DataReceivedEvent is fired by the RTE after a callback from COM due to data reception. Over a physical network, 'data' is commonly transmitted periodically and hence not only will the latency and jitter of DataReceivedEvents vary depending on whether a configuration uses intra or inter-ECU communication, but also the number and frequency of these RTEEvents may change significantly. This means that a TimingEvent should be used to periodically activation of a runnable rather than relying on the periodic transmission of data.

1. DataSendCompletedEvent

Purpose: A runnable entity triggered by the RTE to receive and process transmit acknowledgment notifications.

（传送完成通知）

Signature: [rte sws 1137]

void <name>([IN Rte_Instance <instance>])

Notes: The runnable entity triggered by a DataSendCompletedEvent RTEEvent should use the Rte Feedback API to actually receive the status of the acknowledgement.

（还是需要使用Rte Feedback API 来读取数据）

1. 虚拟总线跟踪（VFB Tracing）

The "VFB Tracing" mechanism is designed to offer a lightweight means to monitor the interactions of AUTOSAR software-components with the VFB. The VFB tracing is implemented by a series of "hook" functions that are invoked automatically by the generated RTE when "interesting events" occur. Each hook function corresponds to a single event.

VFB使用钩子对RTE运行过程进行跟踪。

1. RTE API Trace Events

RTE API trace events occur when an AUTOSAR software-component interacts with the generated RTE API. For implicit S/R communication, however, tracing is not supported.

1. RTE API Start

Description: RTE API Start is invoked by the RTE when an API call is made by a component.

Signature: [rte sws 1238]

void Rte_<api>Hook_<c>_<ap>_Start ([const Rte_CDS_<c>*, ]<param>)

<api> - RTE的API，如Write、Call

<c> - 构件名

<ap> - 访问点

< Rte_CDS_<c>*> - RTE 实例指针（当多重实例化时使用）

<param> - 和函数API参数相同

Where <api> is the RTE API Name (Write, Call, etc.), <c> is the component type name and <ap> the access point name (e.g. port and data element or operation name, exclusive area name, etc.). The parameters of the API are the same as the corresponding RTE API. As with the API itself, the instance handle is included if and only if the software component's SupportsMultipleInstantiation (rte sws in 0004) attribute is set to true. Note that Rte_Instance

cannot be used directly, as there will be pointers to multiple components' structure types within the single VFB Tracing header file, and Rte_Instance would therefore be ambiguous.

1. RTE API Return

Description: RTE API Return is a trace event that is invoked by the RTE just before an API call returns control to a component.

Signature: [rte sws 1239]

void Rte_<api>Hook_<c>_<ap>_Return ([const Rte_CDS_<c>*, ]<param>)

1. OS Trace Events

OS trace events occur when the generated RTE interacts with the AUTOSAR operating system.

1. Task Activate

Description: A trace event that is invoked by the RTE immediately prior to the activation of a task containing runnable entities.

Signature: [rte sws 1243]

void Rte_Task_Activate(TaskType task)

Where task is the OS's handle for the task.

1. Task Dispatch

Description: A trace event that is invoked immediately an RTE generated task (containing runnable entities) has commenced execution.

Signature: [rte sws 1244]

void Rte_Task_Dispatch(TaskType task)

Where task is the OS's handle for the task.

1. Set OS Event

Description: A trace event invoked immediately before generated RTE code attempts to set an OS Event.

Signature: [rte sws 1245]

void Rte_Task_SetEvent(TaskType task, EventMaskType ev)

Where task is the OS's handle for the task for which the event is being set and ev the OS event mask.

1. Wait OS Event

Description: Invoked immediately before generated RTE code attempts to wait on an OS Event. This trace event does not indicate that the caller has suspended execution since the OS call may immediately return if the event was already set.

Signature: [rte sws 1246]

void Rte_Task_WaitEvent(TaskType task, EventMaskType ev)

Where task is the OS's handle for the task (that is waiting for the event) and ev the OS event mask.

1. Runnable Entity Trace Events

Runnable entity trace events occur when a runnable entity is started.

1. Runnable Entity Invocation

Description: Event invoked by the RTE just before execution of runnable entry starts via its entry point. This trace event occurs after any copies of data elements are made to support the Rte IRead API Call.

Signature: [rte sws 1248]

void Rte_Runnable_<c>_<reName>_Start ([const RTE_CDS_<c>*])

<c> - 软件构件类型名

<reName> - 运行体名

1. Runnable Entity Termination

purpose: Event invoked by the RTE immediately execution returns to RTE code from a runnable entity. This trace event occurs before any write-back of data elements are made to support the Rte IWrite API Call.

Signature: [rte sws 1249]

void Rte_Runnable_<c>_<reName>_Return ([const Rte_CDS_<c>*])