小柴带你学AutoSar系列三、标准和规范篇（3）ModeManagement

ModeManagementGuide

2 Overall mechanisms and concepts

2.1 Declaration of modes

2.2 Mode managers and mode users

2.3 Modes in the RTE

2.4 Modes in the Basic Software Scheduler

2.5 Communication of modes

3 Configuration of the Basic Software Modemanager

3.2 Semantics of BswM Configuration: Interfaces and behavioral aspects

3.3 ECU state management

3.4 Communication Management

3.5 Diagnostics

ModeManagement

1 Scope of Document

4 Requirements Specification

4.1 ECU State Manager (EcuM)

4.2 Watchdog Manager

4.3 Communication Manager

4.4 Basic Software Mode Manager

ECUStateManager

1 Introduction and Functional Overview

7 Functional Specification

7.1 Phases of the ECU Manager Module

7.2 Structural Description of the ECU Manager

7.3 STARTUP Phase

7.4 SHUTDOWN Phase

7.5 SLEEP Phase

7.6 UP Phase

7.7 Shutdown Targets

7.8 Alarm Clock

7.9 MultiCore

7.10 EcuM Mode Handling

7.11 Advanced Topics

7.12 ErrorHook

7.13 Error classification

9 Sequence Charts

9.1 State Sequences

9.2 Wakeup Sequences

BSWModeManager

1 Introduction and functional overview

5 Dependencies to other modules

7 Functional specification

9 Sequence diagrams

flechazohttps://www.zhihu.com/people/jiu_sheng

小柴带你学AutoSar总目录https://zhuanlan.zhihu.com/p/694169456

ModeManagementGuide

2 Overall mechanisms and concepts

A mode can be seen as the current state of an ECU1 wide, global variable, which is maintained by the RTE respectively the Schedule Manager.

一个代表ECU当前状态的全局变量是由RTE和调度管理器维护

Modes can be used for different purposes. First of all modes are used to synchronize Software Components and Basic Software Modules. Via modes specified triggers can be enabled and disabled, and consequently the activation of Executable Entitys can be prevented. Also Executable Entitys can be triggered explicitely during a Mode Switch. On the other hand mode switches can explicitly trigger executable entities during transition from one mode to another. For example the RTE can activate an OnEntry ExecutableEntity to initialize acertain resource before entering a specific mode. In this mode the triggers of this ExecutableEntity are activated. If the mode is left the OnExit ExecutableEntity is called, which could execute some cleanup code and the triggers would be deacti vated.

模式管理有如下几个目的：

可以同步SWC和BSW
通过使能和失能特殊的触发器来执行或禁止相应的运行实体
此外运行实体在模式切换期间显示触发

这里对自己写代码也有一些感触了，就是代码写好之后，通过模式切换来触发函数，这样架构师就可以将代码分配给Coder，之后架构师通过模式管理来组织代码的执行。当然啦，初始化也是一个状态切换哦！

2.1 Declaration of modes

例如：

ECU state management there may exist the ModeDeclarations

STARTUP
RUN
POST_RUN
SLEEP

2.2 Mode managers and mode users

两个模式：管理者模式和用户模式

Responsible for switching modes are Mode managers, which are the only instances able to change the value of the global variable.

也就是说要单独将模式管理做成软件组件的形式

2.3 Modes in the RTE

每个组件都有模式管理接口

添加图片注释，不超过 140 字（可选）

2.4 Modes in the Basic Software Scheduler

Another possibility for a Basic Software Module acting as a Mode user to get informed about mode switches, is to register a BSW Module Entry, which is triggered by a Mode Switch Event (see also [3]).

这里也有另一种设想，模式的切换的逻辑都是固定的，那么是否可以将模式和模式的入口出口都通过注册的机制来处理，这样就无需再多写模式切换的逻辑了。说干就干之后会设计一个注册机制的模式管理框架

添加图片注释，不超过 140 字（可选）

2.5 Communication of modes

分为：

Mode Switch
Mode Request

添加图片注释，不超过 140 字（可选）

3 Configuration of the Basic Software Modemanager

3.2 Semantics of BswM Configuration: Interfaces and behavioral aspects

In general the BswM can be seen as a state machine, which is defined by its interface and a behavioral description. The input actions of this state machine are mode requests. Each mode request is described in the ECU configuration of the BswM as a BswMModeRequestSource. These mode requests can be of different types (C-API calls, mode requests via RTE, mode notifications via RTE, etc.) but internally they are treated in the same way. If a mode is requested the internal mirror of this BswMModeRequestSource is updated and depending on the configuration a rule evaluation is triggered, which results in the execution of predefined action lists. Action lists group Actions. Typically an action is a triggering of a mode switch in the RTE or Schedule Manager, but there are also predefined actions which change the status of some Basic Software Module.

总的来说，BswM可以被看作是一个状态机，它由其接口和行为描述定义该状态机的输入操作是模式请求。每个模式请求在BswM的ECU配置中作为BswMModeRequestSource进行描述。这些模式请求可以是不同类型(C-API调用，通过RTE发送的模式请求，通过RTE发送模式通知等)，但它们在内部以相同的方式处理。如果请求模式，则此 BswMModeRequestSource的内部镜像将进行更新并且根据配置触发规则评估，从而导致执行预定义的动作列表。动作列表将动作分组。通常，动作是触发 RTE或调度管理器中的模式切换，但也有预定义的动作，可以更改某些基本软件模块的状态。

Interface of the BswM

The interface is defined by the BswMModeRequestSource and the BswMActionListItem containers.

BswM的接口有两个

BswMModeRequestSource
BswMActionListItem

Mode Requests

BswMModeRequestSource是一个可选的容器

Available Actions

伪代码

EcuM_SetState(EcuM_StateType State) modeGroup EcuM_StateType { ECUM_STATE_STARTUP, ECUM_STATE_APP_RUN, ECUM_STATE_APP_POST_RUN, ECUM_STATE_SHUTDOWN, ECUM_STATE_SLEEP }

后面又一堆无聊的伪代码

Configuration of the BswM behavior

The behavior of the BswM is specified via rules and action lists. A rule is a logical expression, which combines the current values of ModeRequestTypeMaps. The evaluation of each rule either results in the execution of its true or false action lists.

BswM的行为是通过规则和操作列表来指定的。规则是一个逻辑表达式，它结合了ModeRequestTypeMaps的当前值。对每个规则的评估要么导致其真或假操作列表的执行。

添加图片注释，不超过 140 字（可选）

The ModeControlContainer contains these ActionLists. An ActionList can consist of a set of atomic actions, other “nested” ActionLists or it can reference (nested) rules which are then evaluated in the context of this Actionlist.

ModeControlcontainer包含这些ActionLists。ActionList可以由一组原子操作、其他“嵌套ActionLists或引用(嵌套)规则组成，然后在此Actionlist的上下文中进行评估。

添加图片注释，不超过 140 字（可选）

3.3 ECU state management

During startup and shutdown the task of the BswM is to initialize all basic software modules in a similar way as it is done by the ECUM in older AUTOSAR releases. To achieve this the following ModeDeclarationGroup is defined, which indicates the overall state of the ECU to application software components and is used for internal rule arbitration.

在启动和关闭期间，BswM的任务是初始化所有基本软件模块，其方式与早期AUTOSAR版本中的ECUM类似。为了实现这一点定义了以下ModeDeclarationGroup，它指示ECU对应用软件组件的总体状态，并用于内部规则仲裁。

modeGroup MDG_EcuMode { ECU_RUN, ECU_APP_RUN, ECU_APP_POST_RUN, ECU_GO_SLEEP, ECU_GO_OFF_ONE, ECU_SLEEP, ECU_GO_OFF_TWO, ECU_STARTUP_ONE, ECU_STARTUP_TWO, ECU_RESET_READY } interface modeSwitch MSIF_EcuMode { mode MDG_EcuMode ecuMode }

添加图片注释，不超过 140 字（可选）

3.4 Communication Management

Besides parts of the ECU state management, the BswM is also responsible for parts of the communication management. This section describes the functionality of the BswM, which is related to the Communication Stack of AUTOSAR. This covers but is not restricted to the following uses cases.

Starting and stopping of IPDU Groups in general
Partial Networking
Diagnostic use cases which influence the communication of an ECU. e.g. it might be necessary to set the FlexRay State manager to passive mode via FrSm_SetEcuPassive() when requested by an application.
Service Discovery Control for Appplication SWCs

To fulfill the requested functionality the BswM has ModeRequestSources to

the Communication Manager
the bus state managers
AUTOSAR COM
Service Discovery

除了ECU状态管理的一部分外，BswM还负责通信管理的一部分。本节描述了BswM的功能，该功能与AUTOSAR的通信堆栈有关。这包括但不限于以下用例。

Partial Network Cluster

A Partial Network Cluster (PNC) is a (logical) group of ECUs which have to be active at the same time to realize some distributed functionality. A PNC can be assigned to one or multiple users (configuration in ComM) and specific software components can request or release communication for a PNC by requesting the communication mode of a user mapped to the PNC. ComM implements a state machine for each partial network cluster (PNC) and each PNC has its own state. For a simple mapping, the PNC state definitions are related to the states of ComM.

部分网络集群(PNC)是(逻辑)ECU组，这些ECU必须同时处于活动状态才能实现某些分布式功能。PNC可以分配给一个或多个用户(在ComM中进行配置)，特定的软件组件可以通过请求映射到PNC的用户通信模式来请求或释放PNC的通信。ComM为每个部分网络集群(PNCS)实现一个状态机，每个PNC都有自己的状态。对于简单的映射，PNC状态定义与ComM的状态相关。

添加图片注释，不超过 140 字（可选）

The status of all PNCs on the nodes of a system channel is exchanged within the so-called PNC bit vector via a network management message (NM message).

系统信道节点上的所有PNC的状态通过网络管理消息(NM消息)在所谓的PNC位矢量内交换。

Each PNC uses a dedicated bit position within a bit vector (PNC bit vector) transferred by a NM message on CAN, FlexRay and Ethernet. If a PNC is requested by a local ComM user on the node, the node sets the corresponding PNC bit in the PNC bit vector to 1. If the PNC is not requested anymore; the node sets the corresponding PNC bit in the PNC bit vector to 0. (Please note: If the optional feature "Synchronized PNC shutdown" is used and a PN shutdown messages has to be transmitted, the PNC bits are set to 1 for the PNCs which are released and the remaining PNC bits are set to 0). The Nm extract the PNC bit vector from a received NM-PDU and forward the PNC bit vector to the NM interface. The Nm interface module collects and aggregates PNC requests.

每个 PNC 在由 CAN、FlexRay和以太网上的 NM 消息传输的位向量(PNC位向量)中都使用一个专用位。如果节点上的本地ComM用户请求PNC，则节点将 PNC 位向量中的相应 PNC 位设置为 1。如果不再需要 PNC，则节点会将 PNC 位向量的相应 PNC位设为0。(请注意:如果使用了可选功能“同步 PNC 关闭”并且必须发送PN关闭消息，则已释放的PNC的PNC位将设置为 1，其余的 PNC位将设为0)。Nm从接收到的NM-PDU中提取PNC位向量并将PNC位矢量转发到NM接口。Nm接口模块收集和汇总PNC请求。

Each PNC uses the same bit position in the PNC bit vector on every system channel within the NM message. ComM uses 3 types of PNC bit vector named External and Internal Request Array (EIRA), External Request Array (ERA) and Internal Request Array (IRA) to exchange PNC status information with NM interface and Nms.

有三种类型

External and Internal Request Array (EIRA)外部中断请求阵列
External Request Array (ERA)外部请求阵列
Internal Request Array (IRA)内部请求阵列

Partial networking is supported on the bus types CAN, FlexRay and Ethernet. Activation and deactivation of the I-PDU groups of the PNCs on a CAN, FlexRay and Ethernet node is required to control the communication capabilities considering the current state of the PNC and to avoid false timeouts in the system.

部分网络支持 CAN、FlexRay和以太网总线类型。在CAN、Flex-Ray和以太网节点上，需要对 PNC的I-PDU组进行激活和失活，以控制通信能力，考虑到PNC的当前状态，并避免系统中的错误超时。

Starting and stopping of I-PD groups in COM are handled in BswM. I-PDU-Groups shall be started if the corresponding PNC is internally or externally requested. As soon as a PNC is neither internally norexternally requested, the corresponding I-PDU-Group shall be stopped.

COM 中的I-PDU组启动和停止由BswM 处理。如果相应的 PNC内部或外部请求，则应启动相应的I-PDU-Group，一旦 PNC既没有内部请求也没有外部请求，则应停止相应的I-PDU群组。

Internal PNC requests indicate communication needs locally on the ECU and are also called "active PNC request". External PNC requests indicate communication needs of a remote ECU in the network and are also called "passive PNC request".

内部 PNC 请求指示 ECU 上的本地通信需求，也称为“主动 PNC 请求”。

外部PNC 请求指示网络中远程 ECU 的通信需求，也称为“被动 PNC 请求”。

The logic to control I-PDU-Groups is handled as interaction between ComM and BswM. ComM indicates the current state of a particular PNC state machine to BswM.

控制I-PDU-群的逻辑是作为ComM和BswM之间的交互处理的。ComM向BswM表示特定PNC状态机的当前状态。

The BswM controls the corresponding I-PDU groups by means of mode arbitration and mode control. Please note, deactivation of single FlexRay ECUs is not possible.

BswM通过模式仲裁和模式控制来控制相应的I-PDU组。请注意，单个FlexRayECU是不可用的。因为FlexRay是严格基于时间传输的，需要至少两个节点才可以正常通信。

The PNC Gateway feature is used to span (logical) partial network clusters across bus / communication channel boundaries, "gatewaying" PNC requests from one bus/net work to the others.

PNC网关功能用于跨越总线/通信信道边界的(逻辑)部分网络集群，将PNC请求从一个总线/网络“网关化”到其他网络。

The PNC Gateway collects PNC requests from all of its multiple active channels (which are called active since it actively keeps them awake, if required) and aggregates them.

PNC网关从其所有多个活动通道(这些通道被称为活动通道，因为如果需要，它会主动保持它们处于清醒状态)收集PNC请求并对其进行汇总。

The PNC Gateway sends the aggregated PNC state in the network to all its active channels, which causes all nodes to have the same view on the global PNC request state as the gateway.

PNC网关将网络中聚合的PNC状态发送到其所有活动信道，这使得所有节点对全局PNC请求状态具有与网关相同的视图。

If the PNC Gateway is not the topmost PNC Gateway in the network hierarchy, the PNC Gateway will also send the aggregated PNC request state of all subordinate nodes, plus its own internal request state, to its superior PNC coordinator, which is connected via the so-called connector type "passive".

如果 PNC网关不是网络层次结构中的最高 PNC网关，则 PNC网关还将发送所有子节点的聚合 PNC请求状态以及它自己的内部请求状态到其上级 PNC协调器，该协调器通过所谓的“被动”连接器类型连接。

The superior PNC coordinators will aggregate the subordinate coordinators PNC request states, so the top-level coordinator will know about all active PNC requests in the network, and send that info to the subordinate nodes.

上级 PNC 协调器将聚合下属协调器的 PNC请求状态，因此顶级协调器将了解网络中所有活动的 PNC请求，并将该信息发送到子节点。

添加图片注释，不超过 140 字（可选）

Aggregation of internal and external Partial Network Cluster

内部和外部的网络集群的聚合

This feature is used by every ECU that is member of a Partial Network Cluster (PNC).

Active PNC requests are forwarded by the ComM via the Nm to the Nms.
Passive PNC requests are received by the Nms and forwarded to the Nm.

作为部分网络集群(PNC)成员的每个ECU都使用此功能。

主动PNC请求由ComM通过Nm转发到Nm。
Nm接收被动PNC请求并将其转发给Nm。

Nm handles received PNC request with respect to a so-called PN filter mask. The PN filter mask define which of the received PNC requests are relevant. Nm collects and maintains internal and external PNC requests.

Nm处理接收到的与PN过滤器掩码相关的PNC请求。PN过滤器掩码定义了哪些接收到的PNC请求是相关的。Nm收集和维护内部和外部PNC请求。

The aggregation of internal and external requested PNCs is called "External Internal Request Array (EIRA)".

内部和外部请求的PNC的汇总称为“外部内部请求阵列(EIRA)

Changes of the EIRA are forwarded by Nm to ComM. ComM needs this information to handle changes in the corresponding PNC state machines.

EIA 的更改由 Nm 转发到 ComM。ComM 需要此信息来处理相应 PNC状态机中的更改。

The provided information of a request change (PNC request changed from requested to released and vice versa) to ComM at (almost) the same time on every ECU, results to switch the I-PDU-Groups synchronously on all direct connected ECUs.

在每个ECU上(几乎)同时向ComM提供的请求更改(PNC请求从请求变为释放反之亦然)信息导致在所有直接连接的ECU上同步切换I-PDU组。

Therefore the Nm maintain timers (so-called PNC reset timer) of each PNC request in the EIRA.

因此，Nm在EIRA中维护每个PNC请求的定时器(即PNC复位定时器)

The PNC reset timer is restarted every time the corresponding PNC is requested within received PNC bit vector and every time the corresponding PNC request is transmitted.

每次在接收到的PNC位矢量内请求对应的PNC以及每次发送对应的 PNC 请求时，都会重新启动PNC复位定时器。

Aggregation of external Partial Network Cluster

外部的网络集群的聚合

This feature is used by the ECUs where the PNC Gateway functionality is enabled to collect the external PNC requests per channel.

此功能由启用PNC网关功能的ECU使用，以收集每个通道的外部PNC请求。

The external PNC requests have to be coordinated across all affected channels. The logic of the PNC coordination is provided by ComM.

外部PNC请求必须通过所有受影响的通道进行协调。PNC协调的逻辑由ComM提供。

There, for each channel it is configured if it is actively or passively coordinated.

对于每个通道，如果它是主动协调还是被动协调，都会进行配置。

On actively coordinated channels, external PNC requests are mirrored back to the channel where the PNC request was received and also forwarded to all other coordinated channels (either passively or actively coordinated) where this PNC is assigned to.

在主动协调的通道上，外部 PNC请求被镜像回接收 PNC请求的通道，并转发到分配有该 PNC的所有其他协调通道(无论是被动协调还是主动协调)。

On passive coordinated channels external PNC requests are forwarded to other actively coordinated channels where this PNC is assigned to without mirroring back on the channel from where the external PNC request was received. This avoids endless mirroring of partial network cluster requests,

在被动协调通道中，外部 PNC请求被转发到其他主动协调通道，该PNC 也会被分配给主动协调通道，而不会在接收外部 PNC请求的通道中镜像回来。这避免了部分网络集群请求的无休止的反射。

if 2 ECUs have PNC Gateway functionality enabled and are connected to the same channel. The Nm module provides the information if PNCs are externally requested or released to ComM and manages the PNC timer handling for each relevant PNC and per channel. The aggregated state of the external requested PNCs is called "External Request Array" (ERA).

如果两个ECU启用了PNC Gateway功能并连接到同一信道，则Nm模块会在外部向ComM请求或释放PNC时提供这些信息，并管理每个相关PNC和每个信道的PNC定时器处理。外部请求的PNC的聚合称为“外部请求阵列”(ERA)

Synchronized PNC shutdown

PNC shutdown的同步

In order to avoid timeout failure on application level, the PNC shall shutdown in a synchronized way (all nodes in the PNC will shutdown at the same point in time).

为了避免应用层的超时故障，PNC应以同步方式关闭(PNC中的所有节点将在同一时间点关闭)。

The synchronized PNC shutdown is a functionality which is a cooperation of ComM, Nm and Nm to ensure a synchronized PNC shutdown at almost the same point in time across the whole PN topology.

同步 PNC 关闭是一个由 ComM、Nm和总线Nm 共同实现的功能，可确保在整个 PN拓扑中几乎相同的时间点同步 PNC关断。

A synchronized PNC shutdown is handled by ECUs in role of a top-level PNC coordinator or intermediate PNC coordinator if the PNC Gateway is enabled.

如果 PNC 网关处于启用状态，则由 ECU 充当顶级 PNC协调器或中间 PNC 协调器处理同步 PNC关闭。

If the ComM of an ECU in the role of a top-level PNC coordinator detects that a PNC is released (PNC is no longer internally or externally requested), the ComM requests a synchronized PNC shutdown.

如果充当顶级PNC协调整个 ECU 的 ComM 检测到 PNC释放(PNC内部或外部请求不再存在)，则ComM 请求同步 PNC关闭

The Nm module stores all requests and handles them in the context of the Nm_Mainfunction. The Nm module indicates the affected Nms regarding an activated PNC shutdown process.

Nm模块存储所有请求，并在Nm_Mainfunction函数中处理它们。Nm模块指示与已激活的PNC关机过程有关的受影响的Nm。

The Nms call the Nm module to provide the aggregated requests for a synchronized PNC shutdown as PNC bit vector per given NM-Channel.

Nms调用Nm模块，以便以每个给定的NM信道的PNC位向量的形式提供对同步PNC关机的聚合请求。

The Nms use the provided PNC bit vector to assemble a NM-PDU as PN shutdown message and transmit this message on the according NM channel.

Nm使用提供的PNC位矢量来组装NM-PDU作为PN关闭消息，并在相应的NM通道上传输该消息。

If a PN shutdown message is received by an ECU in the role of an intermediate PNC coordinator, the Nms extract the PNC bit vector from the received PN shutdown message and forwards the information by calling the callback function Nm_ForwardSynchronizedPncShutdown.

如果中间 PNC协调器角色中的 ECU接收到 PN关闭消息，则Nms从接收到的 PN 关闭消息中提取 PNC 位向量，并通过调用回调函数 Nm_ForwardSynchronizedPncShutdown 来转发该信息。

The callback function will immediately forward the indication to ComM by calling ComM_Nm_ForwardSynchronizedPncShutdown. ComM will immediately request a synchronized PNC shutdown of all actively PNC coordinated (coordinated by a PNC gateway) ComMChannels.

回调函数将立即通过调用ComM_Nm_ForwardSynchronizedPncShutdown将指示转发到ComM。ComM将立即请求所有积极PNC协调(由PNC网关协调)的ComMChannels的同步 PNC 关闭。

The requests for a synchronized PNC shutdown are forwarded to the Nm module per NM-Channel and handled in the same way as described in the previous section. If a PNC leaf node receives a PN shutdown message, then it will handle the message as a usual NM message (update the local PN info and reset PN reset time).

同步 PNC关闭请求通过 NM 通道转发到 Nm 模块，处理方式与前一节所述相同。如果 PNC叶节点接收到 PN 关闭消息，则它将像处理常规 NM 消息一样处理该消息(更新本地 PN 信息并重置 PN 复位时间)

Scheduling of main functions

Since state changes of communication channels or PNCs are generally processed in the context of the main processing functions, it is important to properly consider the scheduling and the order of execution for the main processing functions for the modules involved in the communication and network management (ComM, Nm, Nms).

由于通信信道或 PNC的状态变化通常在主处理功能的上下文中进行处理，因此正确考虑涉及通信和网络管理(ComM、Nm、Nms)的模块的主处理功能的调度和执行顺序非常重要。

ComM generally coordinates the activities considering the events in the system and triggers the required actions (by calling the relevant APIs) of the lower layers.

ComM通常会考虑系统中的事件来协调活动，并触发下层所需的动作(通过调用相关的API)。

Events in the system causing specific actions required to be triggered by ComM can be internal requests of users (internal requests for channels or PNCs), passive/external requests for channels or PNCs or synchronized PNC shutdown messages received on the bus.

系统中导致需要由ComM触发特定操作的事件可以是

用户的内部请求(对信道或 PNC 的内部请求)、
对信道或 PNC 的被动/外部请求
或在总线上接收到的同步 PNC 关闭消息。

External events may be caused by wakeup events, reception of cyclic NM messages or synchronized shutdown messages.

外部事件可能由

唤醒事件、
周期性NM消息的接收
或同步关机消息引起。

ComM receives and processes all internal and external requests

ComM接收和处理所有内部和外部请求

and triggers required actions

并触发必要的动作

that will lead to state changes in the state machines for communication and network management modules

这将引导通信和网络管理模块状态机的状态变化

and consequently the transmission of cyclic NM messages or synchronized shutdown messages on the bus.

从而在总线上传输循环NM消息或同步关闭消息。

During integration of the modules, it must be considered that the processing of specific requests is done asynchronously in the basic software (e.g. transmission requests,some requests from the application)

在集成模块时，必须考虑特定请求的处理在基本软件中异步完成(例如传输请求、来自应用程序的某些请求)

and also that specific actions may be processed decoupled in the context of the main processing cycle of the involved modules (e.g.transmission in the Nms, processing of timers, state changes and notificationsto upper layers).

并且特定操作可能在所涉及模块的主要处理周期的上下文中脱钩处理(例如在Nms中的传输、处理定时器、状态更改和通知给上层)。

I-PDU Group Switching

For the I-PDU group switching it is expected that dedicated I-PDU groups for outgoing and incoming I-PDUs in COM exist for each channel or partial network.

对于I-PDU组交换，预计每个通道或部分网络都存在用于COM中传入和传出I-PDUs的专用I-PDU组。

AUTOSAR COM takes care that an I-PDU is active (started) if at least one I-PDU group containing this I-PDU is active.

AUTOSAR COM确保如果至少一个包含此I-PDU的I-PDU组处于活动状态，则I-PDU处于活动状态(启动)

有两种组织方式

Channel related I-PDU Group Handling
PNC related I-PDU Group Handling

添加图片注释，不超过 140 字（可选）

Channel related I-PDU Group Handling

Listing 3.18: ComM reports FULL_COMMUNICATION

rule channel1requested initially false { if ( ComM_Mode_Channel1 == COMM_FULL_COMMUNICATION ) { actionlist channel1requestedActions/* channel 1 */ } } actions channel1requestedActions on condition { /* channel 1 */ PduGroupSwitch { init true enable ArMmExample.EcuC.MyCom.CAN1IPDUS_TX, ArMmExample.EcuC.MyCom.CAN1IPDUS_RX } } rule channel2requested initially false { if ( ComM_Mode_Channel2 == COMM_FULL_COMMUNICATION ) { actionlist channel2requestedActions/* channel 2 */ } } actions channel2requestedActions on condition {/* channel 2 */ PduGroupSwitch { init true enable ArMmExample.EcuC.MyCom.CAN2IPDUS_TX, ArMmExample.EcuC.MyCom.CAN2IPDUS_RX } }

Listing 3.19: ComM reports SILENT_COMMUNICATION

Listing 3.20: ComM reports NO_COMMUNICATION

PNC related I-PDU Group Handling

/* PNC 1 */ rule pnc1requested initially false { if ( PNC1 == PNC_REQUESTED || PNC1 == PNC_READY_SLEEP ) { actionlist pnc1requestedActions } } actions pnc1requestedActions on condition { PduGroupSwitch { init true enable ArMmExample.EcuC.MyCom.PNC1IPDUS_TX, ArMmExample.EcuC.MyCom.PNC1IPDUS_RX } } /* PNC 2 */ rule pnc2requested initially false { if ( PNC2 == PNC_REQUESTED || PNC2 == PNC_READY_SLEEP ) { actionlist pnc2requestedActions } } actions pnc2requestedActions on condition { PduGroupSwitch { init true enable ArMmExample.EcuC.MyCom.PNC2IPDUS_CH1_TX, ArMmExample.EcuC.MyCom.PNC2IPDUS_CH1_RX, ArMmExample.EcuC.MyCom.PNC2IPDUS_CH2_TX, ArMmExample.EcuC.MyCom.PNC2IPDUS_CH1_RX } } /* PNC 3 */ rule pnc3requested initially false { if ( PNC3 == PNC_REQUESTED || PNC3 == PNC_READY_SLEEP ) { actionlist pnc3requestedActions } } actions pnc3requestedActions on condition { PduGroupSwitch { init true enable ArMmExample.EcuC.MyCom.PNC3IPDUS_TX, ArMmExample.EcuC.MyCom.PNC3IPDUS_RX } }