📜 完整步骤：主动唤醒 (Active Startup)
初始状态 ：COMM_NO_COM_NO_PENDING_REQUEST
ECU 深度休眠，无任何通信能力，无挂起请求。
步骤 1：用户请求全通信
-
接口 ：
ComM_RequestComMode(Std_ReturnType, ComM_UserHandleType, ComM_ModeType)
(图中 Request COMM_FULL_COMMUNICATION) -
发起者：上层用户（User），通常是 EcuM 或 BswM 动作。
-
含义：用户向 ComM 请求"完全通信模式"。
步骤 2：alt 分支 ------ 检查是否存在活跃诊断
条件：[Active diagnostic]
这是一个嵌套的 alt 片段 ，ComM 根据 DCM 是否已通过 ComM_DCM_ActiveDiagnostic 通知了活跃诊断，来决定走哪条分支。
分支 A：[Active diagnostic] 为真 ------ 有活跃诊断
-
接口 ：
DCM_ActiveDiagnostic(NetworkHandle)（图中IComM_DCM_ActiveDiagnostic） -
来源 ：DCM → ComM（这是一个已经发生的状态通知，图示在此处表示判断该项是否为真）
-
行为：
-
ComM 进入
COMM_NO_COM_REQUEST_PENDING状态。 -
设置
WaitforCommunicationAllowed = true。 -
ComM 暂停 后续硬件请求，被动等待 DCM 的释放或授权信号（
ComM_DCM_ActiveDiagnosticReleased或ComM_DCM_RequestCommunication，图中未画出这两个回调，但按规范是必须的）。 -
收到 DCM 授权后，清除等待标志，继续执行步骤 3。
-
分支 B：[Active diagnostic] 为假 ------ 无活跃诊断
- 行为 ：直接跳过等待，继续执行步骤 3。
步骤 3：请求底层硬件进入全通信模式
-
接口 ：
CanSM_RequestComMode(NetworkHandle, ComM_Mode := COMM_FULL_COMMUNICATION) -
发起者：ComM → CanSM
-
含义：无论有无诊断等待，最终 ComM 都会在允许时，要求 CanSM 配置 CAN 控制器和收发器进入完全通信。
步骤 4：ComM 内部切换到网络请求态
-
新状态 ：
COMM_FULL_COM_NETWORK_REQUESTED -
注意 ：在完整图中，这一状态切换紧跟在
CanSM_RequestComMode(...) = E_OK之后。
步骤 5：alt 分支 ------ 网络管理变体选择 (NMVariant)
条件：根据网络管理类型。
分支 A：[Full] ------ 主动网络管理
-
接口 ：
Nm_NetworkRequest(NetworkHandle) -
发起者：ComM → Nm
-
Nm 调用
NM_NetworkRequest(...) = E_OK。 -
回调 ：
ComM_Nm_NetworkMode(Channel)，Nm 通知 ComM 网络已激活。
分支 B：[Passive] ------ 被动唤醒
-
回调 ：
ComM_Nm_NetworkMode(Channel) -
来源：Nm → ComM
-
注意 ：被动唤醒时，ComM 不调用
Nm_NetworkRequest，直接收到网络模式回调，进入COMM_FULL_COM_READY_SLEEP。
分支 C：[None/Light] ------ 无或轻量 NM
- 动作 ：
ComM启动ComMTMinFullComModeDuration定时器，保持通信至少一段时间。
步骤 6：底层硬件确认全通信就绪
-
回调 ：
ComM_BusSM_ModeIndication(Channel, ComMode := COMM_FULL_COMMUNICATION) -
来源：CanSM → ComM
-
位置 ：在完整图中，此回调画在
alt NM Variant框的下方 ，但根据 AUTOSAR 规范，它实际上是 CanSM 完成硬件配置后的异步确认 ，可能发生在 NM 激活之前或之后，具体取决于实现。这里的关键是：这是硬件闭环确认，ComM 必须收到它，才认为硬件真正就绪。