AUTOSAR EcuM规范解析（一）

持续更新中…

1 引言和功能概述

本文档所规范的ECU管理器模块（ECU State Manager）是一个基础软件模块（参见参考文献[1]），用于管理ECU（电子控制单元）状态的通用方面。具体而言，ECU管理器模块具备以下功能：

• 初始化和反初始化操作系统（OS）、BSW调度器（SchM）、BSW模式管理器（BswM）以及部分基础软件驱动模块。
• 按请求将ECU配置为睡眠（SLEEP）和关机（SHUTDOWN）状态。
• 管理ECU上的所有唤醒事件。

ECU管理器模块提供唤醒验证协议，用于区分“真实”唤醒事件和“异常”唤醒事件。

此外，该模块还支持以下特性：

• 部分或快速启动：ECU以有限功能启动，之后根据应用程序的判断逐步完成后续启动步骤。
• 交错启动：ECU先进行最小化启动，随后尽快启动运行时环境（RTE）以执行软件组件（SW-Cs）的功能，同时继续启动更多BSW和软件组件，实现BSW功能与应用程序功能的交错执行。
• 多种运行状态：ECU拥有不止一种运行（RUN）状态。这一特性细化了从睡眠状态到运行状态的范围概念，形成了从经典运行状态（完全运行）到深度睡眠状态（处理器暂停）的连续运行状态谱系。
• 多核ECU支持：在多核ECU中，启动（STARTUP）、关机（SHUTDOWN）、睡眠（SLEEP）和唤醒（WAKEUP）过程在所有核心上协同进行。

灵活的ECU管理功能基于以下模块提供的通用模式管理机制：

• 运行时环境（RTE）与BSW调度器模块[15]已合并为一个模块，该模块支持可自由配置的BSW模式和应用模式及其模式切换功能。
• BSW模式管理器模块[22]：该模块通过可配置的规则和动作列表，评估ECU模式切换条件并执行必要的切换动作。

在灵活的ECU管理机制中，大多数ECU状态不再由ECU管理器模块自身实现。通常，当通用模式管理机制不可用时，ECU管理器模块接管控制，具体场景包括：

• 启动阶段初期；
• 关机阶段末期；
• 睡眠阶段（此时调度器已锁定模式管理机制）。

在ECU管理器模块的运行阶段（UP Phase），BSW模式管理器负责后续操作。而ECU管理器模块会仲裁来自软件组件的运行（RUN）和运行后（POST_RUN）请求，并向BSW模式管理器通知模式状态。

1.1 与先前ECU管理器模块版本的兼容性

若配置得当，灵活的ECU管理功能与先前的ECU管理器版本具备向后兼容性。

有关兼容性配置的详细信息，可参见《模式管理指南》[23]。

2 定义和缩写

本节定义对 EcuM具有特殊意义的术语以及相关模块的缩写。

Term	Description
回调（Callback）	回调函数
调用点（Callout）
集成代码（Integration Code）
模式（Mode）
被动唤醒（Passive Wakeup）
模式（Mode）	模式是车辆中运行的各种状态机（不仅是 ECU 管理器的状态机）的特定状态集合，与特定实体、应用程序或整个车辆相关。
被动唤醒（Passive Wakeup）	由连接的总线引起的唤醒，而非定时器或传感器活动等内部事件。
阶段（Phase）	ECU 管理器的动作和事件的逻辑或时间组合，例如启动（STARTUP）、运行（UP）、关机（SHUTDOWN）、睡眠（SLEEP）等。阶段可以包含子阶段，子阶段通常称为序列（Sequences），主要用于将执行的动作序列分组为逻辑单元。本文中的阶段并非指 AUTOSAR 方法学中的阶段。
关机目标（Shutdown Target）	ECU 在进入睡眠、断电或复位之前必须先关机。因此，睡眠（SLEEP）、关闭（OFF）和复位（RESET）是有效的关机目标。通过选择关机目标，应用程序可以向 ECU 管理器模块传达其对 ECU 下次关机后行为的期望。
状态（State）	状态是各自基础软件组件的内部状态，因此对应用程序不可见，仅由基础软件的内部状态机使用。ECU 管理器内部的状态构成阶段，从而处理模式。
唤醒事件（Wakeup Event）	导致唤醒的物理事件。CAN 消息或 IO 线的切换都可能是唤醒事件。同样，内部软件表示（如中断）也可称为唤醒事件。
唤醒原因（Wakeup Reason）	唤醒原因是导致上次唤醒的实际唤醒事件。
唤醒源（Wakeup Source）	处理唤醒事件的外设或 ECU 组件称为唤醒源。

Acronym	Description
BswM	基础软件模式管理器（Basic Software Mode Manager）
DEM	诊断事件管理器（Diagnostic Event Manager）
DET	默认错误跟踪器（Default Error Tracer）
EcuM	ECU 管理器（ECU Manager）
GPT	通用定时器（General Purpose Timer）
ICU	输入捕获单元（Input Capture Unit）
ISR	中断服务程序（Interrupt Service Routine）
MCU	微控制器单元（Microcontroller Unit）
NVRAM	非易失性随机存取存储器（Non-volatile random access memory）
OS	操作系统（Operating System）
RTE	运行时环境（Runtime Environment）
VFB	虚拟功能总线（Virtual Function Bus）

3 相关文档

3.1 输入文档

[1] 基础软件模块列表 AUTOSAR_TR_BSWModuleList.pdf
[2] 分层软件架构 AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] 基础软件模块的通用要求 AUTOSAR_SWS_BSWGeneral.pdf
[4] 基础软件模块的通用要求 AUTOSAR_SRS_BSWGeneral.pdf
[5] 模式管理的要求 AUTOSAR_SRS_ModeManagement.pdf
[6] ECU 配置规范 AUTOSAR_TPS_ECUConfiguration.pdf

3.2 相关标准和规范

无

3.3 相关 AUTOSAR 软件规范

[7] 词汇表 AUTOSAR_TR_Glossary.pdf
[8] 通信管理器规范 AUTOSAR_SWS_COMManager.pdf
[9] 看门狗管理器规范 AUTOSAR_SWS_WatchdogManager.pdf
[10] MCU 驱动规范 AUTOSAR_SWS_MCUDriver.pdf
[11] SPI 处理器 / 驱动规范 AUTOSAR_SWS_SPIHandlerDriver.pdf
[12] EEPROM 接口规范 AUTOSAR_SWS_EEPROMDriver.pdf
[13] 闪存接口规范 AUTOSAR_SWS_FlashDriver.pdf
[14] 操作系统规范 AUTOSAR_SWS_OS.pdf
[15] 运行时环境规范 AUTOSAR_SWS_RTE.pdf
[16] 虚拟功能总线规范 AUTOSAR_EXP_VFB.pdf
[17] 诊断事件管理器规范 AUTOSAR_SWS_DiagnosticEventManager.pdf
[18] 默认错误跟踪器规范 AUTOSAR_SWS_DefaultErrorTracer.pdf
[19] CAN 收发器驱动规范 AUTOSAR_SWS_CANTransceiverDriver.pdf
[20] C 实现规则 AUTOSAR_TR_CImplementationRules.pdf
[21] 基础软件模块描述模板 AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[22] 基础软件模式管理器规范 AUTOSAR_SWS_BSWModeManager.pdf
[23] 模式管理指南 AUTOSAR_Guide_ModeManagement.pdf
AUTOSAR 提供了基础软件模块的通用规范 [4]（SWS BSW General），该规范同样适用于 ECU 状态管理器。因此，SWS BSW General 规范应被视为 ECU 状态管理器的附加和必要规范。

4 约束和假设

4.1 局限性

ECU 并非总能完全关闭（即零功耗）。
理由：只有使用 ECU 专用硬件（如电源保持电路）才能达到关机目标 OFF。如果没有此硬件，本规范建议改为执行复位。不过，也允许其他默认行为。

4.2 硬件要求

在本节中，术语 “EcuM RAM” 指为 EcuM预留的一块 RAM。
当 ECU 时钟关闭时，EcuM RAM 必须保留关键数据的内容。
理由：此要求是实现第 7.5 节睡眠状态所必需的。
EcuM RAM 应提供一个在复位周期内保持内容的不初始化区域。
EcuM RAM 的不初始化区域（参见 EcuM2869）仅在加电事件（clamp 30）时初始化。
系统设计者负责为 ECU RAM 的不初始化区域制定初始化策略。

4.3 对汽车领域的适用性

EcuM适用于所有汽车领域。

5 与其他模块的依赖关系

以下各节概述了与其他模块的重要关系，还包含这些模块为与 EcuM正确协作必须满足的一些要求。
如果向基础软件模块传递数据指针，该地址必须指向内存空间的共享部分。

5.1 SPAL 模块

5.1.1 MCU 驱动

MCU 驱动是 EcuM初始化的第一个基础软件模块。当 MCU_Init 返回时（参见 SWS_EcuM_02858），MCU 模块和 MCU 驱动模块未必完全初始化，可能需要额外的 MCU 模块特定步骤来完成初始化。EcuM提供了两个调用点，可在其中放置此额外代码。详情参见 7.3.2 节 StartPreOS 序列中的活动。

5.1.2 驱动依赖和初始化顺序

基础软件驱动可能相互依赖。一个典型示例是看门狗驱动，它需要 SPI 驱动来访问外部看门狗。这一方面意味着驱动可能是分层的（与 EcuM无关），另一方面意味着被调用的模块必须在调用模块之前初始化。
系统设计者负责在配置时在 EcuMDriverInitListZero（参见 ECUC_EcuM_00114）、EcuMDriverInitListOne（参见 ECUC_EcuM_00111）、EcuMDriverRestartList（参见 ECUC_EcuM_00115）和 EcuMDriverInitListBswM（参见 ECUC_EcuM_00226）中定义初始化顺序。

5.2 具有唤醒能力的外设

唤醒源必须由驱动处理和封装。
这些驱动必须遵循本文档提出的协议和要求，以确保无缝集成到 AUTOSAR 基础软件中。该协议基本如下：
驱动必须调用 EcuM_SetWakeupEvent（参见 SWS_EcuM_02826）以通知 EcuM检测到未处理的唤醒事件。驱动不仅要在 ECU 在睡眠阶段等待唤醒事件时调用 EcuM_SetWakeupEvent，还要在驱动初始化阶段以及 EcuM_MainFunction 运行的正常操作期间调用。
驱动必须提供一个显式函数，将唤醒源置于睡眠状态。该函数应将唤醒源置于节能且低活动的操作模式，并重新激活唤醒通知机制。
如果唤醒源可能产生虚假事件，则以下任一组件必须为唤醒事件提供验证调用点或调用 EcuM的验证函数：
驱动；
使用该驱动的软件栈；
其他适当的基础软件模块。
如果不需要验证，则此要求不适用于相应的唤醒源。

5.3 操作系统

EcuM启动和关闭 AUTOSAR 操作系统。EcuM定义了操作系统启动前和关闭后的控制处理协议。

5.4 BSW 调度器

EcuM初始化 BSW 调度器，并且 EcuM包含 EcuM_MainFunction（参见 SWS_EcuM_02837），该函数被调度为定期评估唤醒请求并更新闹钟。

5.5 BSW 模式管理器

ECU 状态通常实现为 AUTOSAR 模式，基础软件模式管理器负责监控 ECU 中的变化，并在适当情况下对 ECU 状态机进行相应更改。有关 AUTOSAR 模式管理的讨论，请参见虚拟功能总线规范 [16]；有关 ECU 状态机实现细节以及如何配置基础软件模式管理器以实现 ECU 状态机的指南，请参见模式管理指南 [23]。
基础软件模式管理器仅在模式管理可用后（即调度器初始化后，直至调度器反初始化或暂停前）才能管理 ECU 状态机。当基础软件模式管理器不可用时，由 EcuM控制 ECU。
因此，EcuM在 ECU 启动后立即接管控制，并在初始化调度器和基础软件模式管理器后将控制交给基础软件模式管理器。
基础软件模式管理器在锁定操作系统和处理唤醒事件时，将 ECU 控制权交回 EcuM。
基础软件模式管理器还在关机时操作系统停止前将控制权交回 EcuM。
在验证唤醒源时，EcuM通过模式切换请求向基础软件模式管理器指示唤醒源状态变化。

5.6 软件组件

EcuM处理以下 ECU 范围的属性：
关机目标。
本规范假设软件组件通过 AUTOSAR 端口设置这些属性，通常由软件组件中特定于 ECU 的部分完成。ECU 管理器不阻止软件组件覆盖其他软件组件设置的配置，相关策略必须在更高层级定义。
以下措施可能有助于解决此问题：
软件组件模板可包含一个字段，用于指示该软件组件是否设置关机目标。
生成工具可仅允许一个软件组件访问关机目标的配置。

5.7 文件结构

5.7.1 代码文件结构

本规范未完全定义代码文件结构。
[SWS_EcuM_02990]⌈EcuM实现应提供一个单独的 EcuM_Callout_Stubs.c 文件，其中包含本实现中实现的调用点存根（参见 8.6 节调用点定义，了解可能实现的调用点列表）⌋()
EcuM_Callout_Stubs.c 是否可手动编辑或仅由其他生成文件组成，取决于具体实现。

5.7.2 头文件结构

另请参见第 8.7 节预期接口，了解与其他模块的依赖关系。

6 需求可追溯性

略

7 功能规范

第1章介绍了一种新的、更灵活的ECU状态管理方法。
然而，这种灵活性是有代价的，即需要承担相应的责任。不存在标准的ECU模式或状态。ECU的集成者必须确定所需的状态并进行配置。

当使用ECU模式处理(ECU Mode Handling)时，标准状态RUN和POST_RUN由运行请求协议(RUN Request Protocol)进行仲裁，并传播到BswM。系统设计者必须确保通过BswM actions设置EcuM模式时，相应状态的前置条件得到满足。

需要注意的是，无论是BSW还是SW-Cs都不能依赖特定的ECU模式或状态，尽管早期版本的BSW在很大程度上也不依赖这些模式或状态。

本文档仅规定了ECU管理器模块中保留的功能。要全面了解ECU状态管理，请参考其他相关模块的规范，即运行时环境（RTE）和基础软件调度器模块[15]以及基础软件模式管理器模块[22]。

有关ECU状态的一些示例用例以及相关BSW模块之间的交互，请参见《模式管理指南》[23]。

ECU管理器模块对唤醒源状态的管理方式与过去相同。用于设置、清除、验证唤醒事件的API保持不变，但值得注意的是，这些API是回调函数。

唤醒源处理始终不仅在唤醒期间进行，还与所有其他EcuM活动并行持续进行。如今，此功能通过模式请求与ECU管理的其他部分完全解耦。

7.1 EcuM的阶段(Phases)概念

EcuM规范的早期版本对 ECU 状态(State)和 ECU 模式(Mode)进行了区分。

ECU 模式是 ECU 较长时间的运行活动周期，应用程序可感知这些模式并以此为导向，例如启动、关机、进入睡眠和唤醒。
EcuM状态通常是 EcuM操作的连续序列，这些序列会一直持续，直到满足外部条件才终止。例如，Startup1 包含操作系统启动前的所有基础软件（BSW）初始化操作，当操作系统将控制权交回 EcuM时，启动序列终止。

对于当前的Flexible EcuM，存在状态（States）、模式（Modes）和阶段（Phases），这些在“定义和缩写”部分已有定义。

此处，ECU状态机作为通用模式在BSW模式管理器模块的控制下实现。这带来了术语上的问题：原来的ECU状态（States）现在成为可通过RTE_Mode端口接口可见的模式（Modes），而原来的ECU模式（Modes）则成为阶段（Phases）。

由于虚拟功能总线（VFB）所定义且在运行时环境（RTE）中使用的模式（Modes）仅在运行阶段（UP phase，此时EcuM处于被动状态，因为此时控制权在OS）可用，因此将术语从“模式（Modes）”改为“阶段（Phases）”是有必要的，否则两个mode的概念容易混淆了。

图1展示了Flexible EcuM的各阶段概览。启动阶段（STARTUP phase）持续到模式管理功能运行为止。从根本上来说，启动阶段包含启动模式管理所需的最低限度活动：初始化底层驱动程序、启动操作系统（OS）以及初始化BSW调度器和BswM模块。同样，关机阶段（SHUTDOWN phase）是启动阶段的逆过程，在此阶段模式管理功能被反初始化。

运行阶段（UP phase）包含了未详细展开的各种模块状态。在该阶段，ECU会按照集成者定义的状态机，在不同状态和模式之间切换。

若使用ECU模式处理（ECU Mode Handling），运行阶段包含默认模式。这些模式之间的转换通过EcuM与BswM的协作完成。

需要注意的是，运行阶段包含一些以前的睡眠状态。从操作系统调度器被锁定以防止其他任务在睡眠中运行开始，到ECU退出MCU低功耗睡眠模式为止，这段时间内模式管理功能不运行。而EcuM在此期间提供唤醒处理支持。

7.1.1 启动阶段（STARTUP Phase）

启动阶段的目的是将基础软件模块初始化到通用模式管理功能( Generic Mode Management)可运行的状态。这一阶段包含一系列初始化步骤，从最底层的硬件初始化到上层软件组件的准备，最终为 ECU 进入正常运行状态奠定基础。详细初始化过程参见 7.3 节。

7.1.2 运行阶段（UP Phase）

运行阶段始于 BSW Scheduler 启动且 BswM_Init 被调用之时。在该阶段初期，内存管理、通信栈、SWC支持（RTE）等可能尚未完全初始化，SWC也未启动。系统会从配置的启动后模式开始运行，通过运行相应的runnable（如 BSW MainFunctions）持续处理各类任务，并根据模式切换规则动态调整 ECU 状态。

从 EcuM的角度来看，此时 ECU 处于 “UP/运行中” 状态。BswM会启动模式仲裁，后续的 BSW 初始化、RTE 启动以及SWC的启动等操作，均由 BswM 的动作列表控制或通过模式依赖调度触发，实际由集成者掌控。

例如，NvM 的初始化和 NvM_ReadAll 的调用也属于集成代码的范畴。这意味着集成者需负责在 NvM_ReadAll 完成时触发 Com、DEM 和 FIM 的初始化，NvM 会在 ReadAll 完成后通知 BswM。

需要注意的是，RTE 可在 NvM 和 COM 初始化后启动，且通信栈无需完全初始化即可初始化 COM。在运行阶段，系统会按任意顺序初始化 BSW 模块和启动SWC，直至 ECU 达到满负荷运行状态，且这种动态调整会持续影响 ECU 的能力。

最终，模式切换会停止SWC并反初始化 BSW，使 ECU 退出运行阶段，进入可断电状态。因此，对 EcuM而言，BSW 和SWC会持续运行，直至 ECU 准备好进入关机或睡眠状态。

有关模式驱动的 ECU 管理设计及 BSW 模式管理器配置指南，参见《模式管理指南》[23]。

7.1.3 关机阶段（SHUTDOWN Phase）

[SWS_EcuM_03022]⌈关机阶段负责控制基础软件模块的有序关闭，最终使 ECU 进入选定的关机目标状态（OFF 或 RESET）。⌋(SRS_ModeMgm_09072)

7.1.4 睡眠阶段（SLEEP Phase）

ECU 在睡眠阶段节省能源。通常情况下，此阶段不执行代码，但仍保持供电；若配置得当，ECU 在该状态下可被唤醒。EcuM提供一组可配置的（硬件）睡眠模式，这些模式通常在功耗和 ECU 重启时间之间存在权衡。

EcuM会响应有意或无意的唤醒事件唤醒 ECU。由于无意的唤醒事件应被忽略，因此模块提供了唤醒验证协议，该协议规定了处理唤醒源的驱动模块与 EcuM之间的协作流程（参见 7.6.4 节 “WakeupValidation 序列中的活动”）。

7.1.5 关闭阶段（OFF Phase）

当 ECU 断电时，进入关闭状态。在该状态下，ECU 可能仍可通过具备集成电源控制的唤醒源被唤醒，但无论如何，ECU 必须能够通过复位事件启动。

7.2 EcuM的结构描述

EcuM与其他 BSW 模块的接口关系如图 2 所示。在大多数情况下，EcuM仅负责初始化其他模块，但部分模块与 EcuM存在功能上的关联，下文将对此进行说明。

7.2.1 标准化的 AUTOSAR 软件模块

部分基础软件驱动模块由 EcuM初始化、关闭，并在唤醒时重新初始化。

OS由 EcuM初始化和关闭。

OS初始化后，EcuM会执行额外的初始化步骤，之后将控制权交给 BswM。BswM 会在操作系统关闭前立即将执行控制权交回 EcuM。详情参见 7.3 节 “启动阶段” 和 7.4 节 “关机阶段”。

7.2.2 软件组件/SWC

SWC包含 AUTOSAR ECU 的应用代码。
SWC通过 AUTOSAR port与 EcuM交互。（注：SWC可以直接调用EcuM API，或者EcuM port包装成RTE接口供SWC调用）

7.3 启动阶段/STARTUP Phase

启动阶段的概述描述参见 7.1.1 节。

图3展示了ECU的启动行为。当通过EcuM_Init调用时，EcuM接管ECU的启动过程。在调用StartOS时，EcuM暂时放弃控制权。用户必须为OS配置一个自动运行的Os Task，并在该Task里调用EcuM_StartupTwo()，这样才能继续完成StartPost OS sequence的工作。

7.3.1 EcuM_Init 之前的活动

EcuM假设，在调用 EcuM_Init（参见 SWS_EcuM_02811）之前，MCU 已完成最小化初始化，以便设置栈并执行代码，同时变量的 C 初始化也已完成。

7.3.2 StartPreOS 序列中的活动

[SWS_EcuM_02411]⌈表 1 列出了 StartPreOS 序列中的活动及其在 EcuM_Init 中应执行的顺序(参加SWS_EcuM_02811)

表1 – StartPreOS序列

初始化活动	说明	可选性4
调用点EcuM_AL_SetProgrammableInterrupts	在具有可编程中断优先级的ECU上，必须在操作系统启动前设置这些优先级。	是
调用点EcuM_AL_DriverInitZero	初始化块0：此调用点只能初始化不使用构建后配置参数的基础软件（BSW）模块。该调用点不仅可包含驱动初始化代码，还可包含任何类型的OS启动前底层初始化代码。详见7.3.5 驱动初始化	是
调用点EcuM_DeterminePbConfiguration	该调用点应返回一个指向完全初始化的EcuM_ConfigType结构体的指针，该结构体包含ECU管理器模块及所有其他BSW模块的构建后配置数据。	否
检查配置数据一致性	若检查失败，则调用EcuM_ErrorHook。有关一致性检查的详细信息，详见7.3.4 检查配置一致性	否
调用点EcuM_AL_DriverInitOne	初始化块1：此调用点不仅可包含驱动初始化代码，还可包含任何类型的OS启动前底层初始化代码。详见7.3.5 驱动初始化	是
获取复位原因	复位原因通过调用Mcu_GetResetReason函数，并结合通过EcuMWakeupSource配置容器定义的映射关系推导得出。详见8.5.1.2 EcuM_SetWakeupEvent和8.3.5.3 EcuM_GetValidatedWakeupEvents（参见SWS_EcuM_02830）	否
选择默认关闭目标	参见SWS_EcuM_02181	否
调用点EcuM_LoopDetection	若启用循环检测功能，则每次启动时都会调用此调用点	是
启动操作系统（Start OS）	启动AUTOSAR操作系统，参见SWS_EcuM_02603	否

⁴ 可选活动可通过配置开启或关闭。有关详细信息，详见10.1 通用容器和配置参数。

[SWS_EcuM_02623]⌈EcuM应记住由复位原因转换得到的唤醒源（参见表 1）。⌋()
SWS_EcuM_02623 的理由：唤醒源必须由 EcuM_MainFunction 验证（参见 7.6.4 节 “WakeupValidation 序列中的活动”）。

[SWS_EcuM_02684]⌈当调用 EcuM_Init 函数（参见 SWS_EcuM_02811）时，EcuM应执行 StartPreOS 序列中的活动（参见表 1 “StartPreOS 序列”）。⌋()

StartPreOS序列旨在为ECU初始化操作系统做好准备，且应应尽可能精简。在可能的情况下，驱动程序应在运行阶段（UP phase）进行初始化，调用点也应保持简洁。此序列期间不应使用中断。如果必须使用中断，StartPreOS序列中仅允许使用I类中断。

EcuM并未严格规定驱动程序和硬件抽象模块的初始化方式。提供了两个调用点EcuM_AL_DriverInitZero（参见SWS_EcuM_02905）和EcuM_AL_DriverInitOne（参见SWS_EcuM_02907）来定义初始化块0和初始化块I。这些块包含与StartPreOS序列相关的初始化活动。

MCU_Init并未提供完整的MCU初始化。此外，还必须执行与硬件相关的步骤，这些步骤必须在系统设计阶段确定。这些步骤应在EcuM_AL_DriverInitZero（参见8.6.2.2节“EcuM_AL_DriverInitZero”、SWS_EcuM_02905）或EcuM_AL_DriverInitOne调用点（参见8.6.2.4节“EcuM_AL_DriverInitOne”、SWS_EcuM_02907）中执行。详细信息可参见《MCU驱动规范》[10]。

[SWS_EcuM_02181]⌈EcuM应使用配置的默认关机目标（参见7.7节“关机目标”和EcuMDefaultShutdownTarget ECUC_EcuM_00105）调用8.3.5.3节中的EcuM_GetValidatedWakeupEvents（参见SWS_EcuM_02822）。⌋()

[SWS_EcuM_02603]⌈StartPreOS序列应初始化启动操作系统所需的所有基础软件模块。⌋()

7.3.3 StartPostOS 序列中的活动

表2 – StartPostOS序列

初始化活动	说明	可选性6
启动BSW调度器（Start BSW Scheduler）	-	否
初始化BSW模式管理器（Init BSW Mode Manager）	-	否
初始化BSW调度器（Init BSW Scheduler）	初始化BSW模块用于临界区的信号量	否
启动调度器计时（Start Scheduler Timing）	启动BSW/软件组件（SW-Cs）的周期性事件	否

⁶ 可选活动可通过配置开启或关闭。有关详细信息，参见10.1 通用容器和配置参数。

[SWS_EcuM_02932] ⌈当调用 EcuM_StartupTwo 函数（参见 SWS_EcuM_02838）时，EcuM应执行 StartPostOS 序列中的活动（参见表 2 - StartPostOS 序列）。⌋(SRS_ModeMgm_09113)

7.3.4 检查配置一致性

7.3.4.1 ECU管理器中检查配置一致性的必要性

在AUTOSAR ECU中，多个配置参数在不同时间设置并写入ECU。预编译参数被设置、插入生成的源代码并编译为目标代码。源代码编译完成后，链接时参数被设置、编译，并与先前配置的目标代码链接成镜像文件写入ECU。最后，构建后参数在不同时间被设置、编译、链接并写入ECU。所有这些参数必须匹配才能获得稳定的ECU。

配置工具可自行检查配置时参数的一致性。编译器可能在编译时检测参数错误，链接器可能在链接时发现其他错误。但遗憾的是，发现构建后参数中的配置错误非常困难。这只能通过以下方式实现：

• 编译代码时使用的预编译和链接时参数设置
• 必须与配置和编译构建后参数时使用的预编译和链接时参数设置完全相同。

这只能在运行时完成。

SWS_EcuM_02796的解释：ECU管理器模块在初始化第一个BSW模块之前检查一致性，以避免在不同BSW模块中分散多次检查。

这还意味着：
[SWS_EcuM_02796] ⌈ECU管理器模块不仅要检查自身参数的一致性，还要在初始化第一个BSW模块之前检查所有可构建后配置的BSW模块的一致性。⌋()

ECU管理器配置工具必须对所有BSW模块的所有预编译和链接时配置参数计算哈希值，并将该值存储在链接时ECUM_CONFIGCONSISTENCY_HASH（参见ECUC_EcuM_00102）配置参数中。哈希值的必要性有两点：一是预编译和链接时参数在运行时不可访问；二是运行时的检查必须非常高效，比较数百个参数会导致ECU启动过程出现不可接受的延迟。

ECU管理器模块配置工具必须将计算出的ECUM_CONFIGCONSISTENCY_HASH值放入EcuM_ConfigType结构体中包含所有构建后配置参数根的字段中。

[SWS_EcuM_02798] ⌈ECU管理器模块应在EcuM_Init（参见SWS_EcuM_02811）中检查该结构体中的字段是否等于ECUM_CONFIGCONSISTENCY_HASH的值。⌋()

通过在配置时计算哈希值并在运行时进行比较，EcuM代码可以非常高效，而且不依赖于特定的哈希计算算法。这允许使用复杂的哈希计算算法，例如加密强度高的哈希函数。

请注意，相同的哈希算法可用于生成EcuM_ConfigType结构体中构建后配置标识符的值。此时，哈希算法应用于构建后参数，而不是预编译和链接时参数。

[SWS_EcuM_02799] ⌈用于对所有BSW模块的所有预编译和链接时配置参数计算哈希值的哈希计算算法，对于相同的配置数据集，无论XML文件中配置参数的顺序如何，都应生成相同的哈希值。⌋()

7.3.4.2 哈希计算算法示例

注：本章为非规范性内容，描述了一种可能的哈希值计算方法。

对配置参数值进行简单的CRC校验并非良好的哈希算法。它只能检测全局变化（例如，一个参数从1变为2），但如果另一个参数从2变为1，CRC可能保持不变。

此外，哈希算法不仅要考虑配置参数的值，还要考虑它们的名称。一种可能的方法是构建一个文本文件，包含配置参数和容器的名称，使用分隔符（如冒号）将名称与值分开，并将每个参数作为一行放入文本文件中。

如果存在多个相同类型的容器，每个容器名称可附加一个数字，例如“_0”、“_1”等。

为了使哈希值不依赖于参数写入文本文件的顺序，必须对文件中的行进行字典排序。

最后，可对文本文件运行加密强度高的哈希函数（如MD5）以生成哈希值。这些哈希函数对于略有变化的输入文件会生成完全不同的哈希值。

7.3.5 驱动初始化

驱动在初始化过程中的位置很大程度上取决于其实现和目标硬件设计。

驱动可由ECU管理器模块在启动阶段的初始化块0（Init Block 0）或初始化块1（Init Block 1）中初始化，或在唤醒重启序列（WakeupRestart Sequence）的EcuM_AL_DriverRestart调用点中重新初始化。驱动也可在运行阶段（UP phase）由BSW模式管理器（BswM）初始化或重新初始化。

本章适用于那些由ECU管理器模块（而非BswM）处理其初始化和重新初始化的AUTOSAR基础软件驱动（SchM和BswM除外）。

[SWS_EcuM_02559] ⌈ECU管理器模块的配置应指定初始化块0和初始化块1内部的初始化调用顺序（参见EcuMDriverInitListZero ECUC_EcuM_00114和EcuMDriverInitListOne ECUC_EcuM_00111）。⌋(SRS_BSW_00416,SRS_ModeMgm_09234)

[SWS_EcuM_02730] ⌈ECU管理器模块应使用从驱动的EcuMModuleService配置容器（参见ECUC_EcuM_00124）派生的参数调用每个驱动的初始化函数。⌋(SRS_ModeMgm_09234)

[SWS_EcuM_02947] ⌈对于唤醒重启期间的重新初始化，集成者应使用EcuMDriverRestartList（参见ECUC_EcuM_00115）在EcuM_AL_DriverRestart（参见SWS_EcuM_02923）的集成代码中集成一个重启块⌋(SRS_ModeMgm_09234)

[SWS_EcuM_02562] ⌈EcuMDriverRestartList（参见ECUC_EcuM_00115）可包含作为唤醒源的驱动。EcuM_AL_DriverRestart（参见SWS_EcuM_02923）应重新激活这些驱动的“唤醒检测”回调的触发机制（参见7.6.4节“唤醒重启序列中的活动”）。⌋()

[SWS_EcuM_02561] ⌈ECU管理器模块应以初始化块0和初始化块1的组合列表中的相同顺序初始化EcuMDriverRestartList中的驱动。⌋()

SWS_EcuM_02561提示：EcuMDriverRestartList通常只包含初始化块0和初始化块1的组合列表中的一个子集。

表3展示了初始化块0和初始化块I的一种可能（且推荐）的活动序列。根据硬件和软件配置，可添加或省略BSW模块，也可采用其他序列。

初始化活动	说明
初始化块0 7
默认错误跟踪器（Default Error Tracer）	这应始终是第一个初始化的模块，以便其他模块可以报告开发错误。
诊断事件管理器（Diagnostic Event Manager）	预初始化
访问构建后配置数据所需的任何驱动	这些驱动不应依赖于构建后配置或操作系统功能。
初始化块I 8
MCU驱动（MCU Driver）
端口驱动（Port Driver）
通用定时器（General Purpose Timer）
看门狗驱动（Watchdog Driver）	仅限内部看门狗，外部看门狗可能需要SPI
看门狗管理器（Watchdog Manager）
ADC驱动（ADC Driver）
输入捕获单元驱动（ICU Driver）
PWM驱动（PWM Driver）
输出比较单元驱动（OCU Driver）

表3 - 驱动初始化详情（示例配置）

7 初始化块0中的驱动在EcuMDriverInitListZero配置容器中列出。
8 初始化块I中的驱动在EcuMDriverInitListOne配置容器中列出。

7.3.6 DET初始化

默认错误跟踪器（DET）模块是一个用于调试的基础软件模块。DET必须先通过调用Det_Init进行初始化，再通过调用Det_Start启动后才能正常运行。详情参见《默认错误跟踪器规范》[18]。

在生产环境中，不得编译DET模块；在开发环境中，至少有一个模块必须在DET初始化前使用它，其初始化才与系统相关。

[SWS_EcuM_02783] ⌈如果至少有一个模块被配置为跟踪开发错误，ECU管理器模块必须在StartPreOS序列中（参见7.3.2节“StartPreOS序列中的活动”）在所有其他驱动之前初始化DET。⌋()

SWS_EcuM_02783的理由：其他模块在DET初始化前无法报告开发错误。

[SWS_EcuM_02634] ⌈ECU管理器模块默认不应启动DET。⌋()

SWS_EcuM_02634的理由：系统设计者必须配置DET的启动点，最好是在EcuM_AL_DriverInitOne调用点（参见SWS_EcuM_02907）中。DET的最佳启动点取决于其实现和行为。

7.3.7 BSW初始化

其余的基础软件模块由BSW模式管理器通过ECU管理器的一个配置函数（EcuMDriverInitCalloutName ECUC_EcuM_00227）进行初始化，该函数由配置的初始化函数列表（EcuMDriverInitListBswM ECUC_EcuM_00226）生成。

[SWS_EcuM_04110]⌈ECU管理器模块的配置应指定BSW初始化内部的初始化调用顺序（参见EcuMDriverInitListBswM ECUC_EcuM_00226）。⌋()

7.4 关机阶段（SHUTDOWN Phase）

参见7.1.3节“关机阶段”对关机阶段的概述。带有关机目标RESET或OFF的EcuM_GoDownHaltPoll会启动关机阶段。

[SWS_EcuM_02756]⌈如果在关机阶段发生唤醒事件，ECU管理器模块应完成关机并立即重启。⌋()

7.4.1 OffPreOS序列中的活动

[SWS_EcuM_03021] ⌈

OffPreOS序列活动	说明	可选9
反初始化BSW模式管理器		否
反初始化BSW调度器		否
检查未处理的唤醒事件	目的是检测在关机期间发生的唤醒事件	否
如果检测到未处理的唤醒事件，将关机目标设置为RESET（将使用EcuMDefaultResetModeRef（ECUC_EcuM_00205）的默认复位模式）	仅当检测到未处理的唤醒事件时执行此操作，以便立即启动	否
关闭操作系统（ShutdownOS）	此操作系统任务中的最后一项操作	否

表4 - OffPreOS序列
⌋(SRS_ModeMgm_09127)

[SWS_EcuM_02952] ⌈作为最后一项活动，ECU管理器模块应调用ShutdownOS函数。⌋(SRS_ModeMgm_09104)

操作系统在其关机结束时调用关机钩子（shutdown hook）。

[SWS_EcuM_02953] ⌈关机钩子应调用EcuM_Shutdown（参见SWS_EcuM_02812）以终止关机过程。EcuM_Shutdown（参见SWS_EcuM_02812）不应返回，而是关闭ECU电源或触发复位。⌋(SRS_ModeMgm_09104)

7.4.2 OffPostOS序列中的活动

OffPostOS序列实现操作系统关闭后到达关机目标的最终步骤。EcuM_Shutdown（参见SWS_EcuM_02812）会启动该序列。

关机目标可以是ECUM_SHUTDOWN_TARGET_RESET或ECUM_SHUTDOWN_TARGET_OFF，其中特定的复位方式由复位模式决定。详见7.7节“关机目标”。

关机活动	说明	可选
调用点EcuM_OnGoOffTwo		否
调用点EcuM_AL_Reset或调用点EcuM_AL_SwitchOff	取决于所选的关机目标（RESET或OFF）	否

表5 - OffPostOS序列

[SWS_EcuM_04074] ⌈当关机目标为RESET时，ECU管理器模块应调用EcuM_AL_Reset调用点。详情参见8.6.3.4节“EcuM_AL_Reset（SWS_EcuM_04065）”。⌋()

[SWS_EcuM_04075] ⌈当关机目标为OFF时，ECU管理器模块应调用EcuM_AL_SwitchOff调用点。详情参见8.6.3.3节“EcuM_AL_SwitchOff（SWS_EcuM_02920）”。⌋()

9 可选活动可通过配置开启或关闭。系统设计者可选择ECU设计中是否编译某个模块。详见10.1节“通用容器和配置参数”。

7.5 睡眠阶段（SLEEP Phase）

参见7.1.4节“睡眠阶段”对睡眠阶段的概述。带有关机目标SLEEP的EcuM_GoDownHaltPoll会启动睡眠阶段。

根据所选的睡眠模式（由EcuMSleepModeSuspend参数决定），带有关机目标SLEEP的EcuM_GoDownHaltPoll会启动两个控制流，它们在实现睡眠的机制上存在结构性差异，但在准备睡眠和从睡眠恢复的序列上是相同的。

另一个模块（推测是 BSW 模式管理器（BswM），不过也可能是软件组件（SW-C））必须确保在调用 EcuM_GoDownHaltPoll 之前，已选择合适的 ECUM_STATE_SLEEP 关机目标

7.5.1 GoSleep序列中的活动

在GoSleep序列中，ECU管理器模块为即将到来的睡眠阶段配置硬件，并为下一次唤醒事件做好准备。

[SWS_EcuM_02389] ⌈为了将唤醒源设置为下一个睡眠模式，ECU管理器模块应对每个在目标睡眠模式的EcuMWakeupSourceMask（参见ECUC_EcuM_00152）中配置的唤醒源执行EcuM_EnableWakeupSources调用点（参见SWS_EcuM_02546）。⌋(SRS_ModeMgm_09100)

[SWS_EcuM_02951] ⌈与关机阶段不同，ECU管理器模块在进入睡眠阶段时不应关闭操作系统。睡眠模式（即EcuM睡眠阶段与MCU模式的组合）应对操作系统透明。⌋()

[SWS_EcuM_03010] ⌈在多核ECU上运行时，ECUM应为每个核心预留一个专用资源（RES_AUTOSAR_ECUM），该资源在GoSleep期间分配。⌋()

7.5.2 Halt序列中的活动

[SWS_EcuM_02960] ⌈ECU管理器模块应在使微控制器暂停的睡眠模式中执行Halt序列。在这些睡眠模式下，ECU管理器模块不执行任何代码。⌋()

[SWS_EcuM_02863] ⌈ECU管理器模块应在暂停微控制器之前调用EcuM_GenerateRamHash调用点（参见SWS_EcuM_02919），在处理器从暂停状态恢复后调用EcuM_CheckRamHash调用点（参见SWS_EcuM_02921）。

在多核应用且存在“从核”EcuM的情况下，此检查应仅在“主核”EcuM上执行。“主核”EcuM根据其可访问的所有数据生成哈希值，“从核”EcuM的私有数据不在此范围内。⌋()

SWS_EcuM_02863的理由：当ECU处于睡眠模式较长时间时，RAM内存可能会损坏。因此，应检查RAM内存的完整性以防止意外行为。系统设计者可选择合适的校验和算法来执行此检查。

[SWS_EcuM_02961]⌈ECU管理器模块应调用EcuM_GenerateRamHash（参见SWS_EcuM_02919），系统设计者可在此处设置RAM完整性检查。⌋()

7.5.3 Poll序列中的活动

[SWS_EcuM_02962] ⌈ECU管理器模块应在降低微控制器功耗但仍能执行代码的睡眠模式中执行Poll序列。⌋()

[SWS_EcuM_03020] ⌈在Poll序列中，EcuM应在一个阻塞循环中调用EcuM_SleepActivity()和EcuM_CheckWakeup()，直到检测到未处理的唤醒事件。⌋()

7.5.4 退出Halt或Poll状态

[SWS_EcuM_02963] ⌈如果ECU在Halt或Poll状态时发生唤醒事件（如唤醒线触发、CAN总线上的通信等），ECU管理器模块应重新获得控制权，并通过执行WakeupRestart序列（参见7.5.5节“WakeupRestart序列中的活动”）退出睡眠阶段。

中断服务程序（ISR）可能被调用来处理唤醒事件，但这取决于硬件和驱动的实现。⌋()

[SWS_EcuM_04001] ⌈如果ECU在Halt或Poll状态时发生异常事件（硬件复位或电源循环），ECU管理器模块应在启动阶段重启ECU。⌋()

7.5.5 WakeupRestart序列中的活动

唤醒活动	说明	可选
恢复MCU正常模式	选定的MCU模式在配置参数EcuMNormalMcuModeRef中配置
获取未处理的唤醒源
调用点EcuM_DisableWakeupSources	禁用当前未处理的唤醒源，但保持其他唤醒源处于激活状态，以便后续唤醒
调用点EcuM_AL_DriverRestart	初始化需要重启的驱动
解锁调度器	从此时起，所有其他任务可再次运行

表6 - WakeupRestart活动

ECU管理器模块调用EcuM_AL_DriverRestart调用点（参见SWS_EcuM_02923），该调用点用于重新初始化驱动。其中，具有唤醒源的驱动通常需要重新初始化。有关驱动初始化的更多详情，参见7.3.5节“驱动初始化”。

在重新初始化过程中，驱动必须检查其分配的唤醒源中是否有一个是上一次唤醒的原因。如果检查结果为真，驱动必须调用其“唤醒检测”回调（参见《CAN收发器驱动规范》[19]中的示例），该回调进而必须调用EcuM_SetWakeupEvent函数（参见SWS_EcuM_02826）。

驱动实现应仅调用一次唤醒回调，之后在通过显式函数调用重新激活之前，不应再次调用该回调。因此，必须重新激活驱动以再次触发回调。

[SWS_EcuM_02539]⌈如果在WakeupRestart序列完成时，ECU管理器模块有一个唤醒源候选列表，那么ECU管理器模块应在EcuM_MainFunction中验证这些唤醒源候选。参见7.6.4节“WakeupValidation序列中的活动”。⌋()

[SWS_EcuM_04066]⌈

⌋()

7.6 运行阶段（UP Phase）

在运行阶段，EcuM_MainFunction会定期执行，其主要功能有三个：

• 检查是否有唤醒源已触发唤醒，并在必要时启动唤醒验证（参见7.6.4节“WakeupValidation序列中的活动”）
• 更新闹钟计时器
• 仲裁运行（RUN）和运行后（POST_RUN）的请求与释放

7.6.1 闹钟处理

实现细节参见8.2.1节“运行阶段中的EcuM时钟时间”。

[SWS_EcuM_04002]⌈当闹钟服务存在时（参见EcuMAlarmClockPresent ECUC_EcuM_00199），EcuM_MainFunction应更新闹钟计时器⌋()

7.6.2 唤醒源状态处理

唤醒源的处理不仅在唤醒期间进行，还与所有其他EcuM活动并行持续进行。此功能在EcuM_MainFunction中运行，通过模式请求与ECU管理的其他部分完全解耦。

[SWS_EcuM_04091]⌈
唤醒源可处于以下状态：

状态	描述
NONE	未检测到唤醒事件或已清除唤醒事件
PENDING	已检测到唤醒事件但尚未验证
VALIDATED	已检测到唤醒事件且验证成功
EXPIRED	已检测到唤醒事件但验证失败
⌋(SRS_ModeMgm_09136)

图15展示了唤醒源状态之间的关系以及引发状态变化的条件函数。为便于理解，此处额外展示了“禁用（Disabled）”和“验证（Validation）”两个超级状态。

当ECU管理器的操作导致唤醒源的状态发生变化时，ECU管理器模块应向BSW模式管理器（BswM）发出模式请求，将唤醒源的模式切换为新状态。

用于传达这些唤醒源状态的类型是EcuM_WakeupStatusType（参见SWS_ECUM_04041）。

当ECU管理器模块处于运行阶段时，唤醒事件通常不会触发状态变化，但会触发Halt和Poll子阶段的结束。之后，ECU管理器模块会自动执行WakeupRestart序列，然后返回运行阶段。

由集成者在BswM中配置规则，使ECU对唤醒事件做出正确反应，因为反应完全取决于当前的ECU（非ECU管理）状态。

如果唤醒源有效，BswM会使ECU返回运行状态；如果所有唤醒事件都回到NONE或EXPIRED状态，BswM会再次准备BSW进入睡眠或关闭状态，并调用EcuM_GoDownHaltPoll。

总之：每个未处理的事件都会被独立验证（如果已配置），EcuM将结果作为模式请求发布给BswM，进而由BswM触发EcuM的状态变化。

7.6.3 唤醒状态的内部表示

ECU管理器模块提供以下接口来确定这些唤醒源的状态：

• EcuM_GetPendingWakeupEvents
• EcuM_GetValidatedWakeupEvents
• EcuM_GetExpiredWakeupEvents

并通过以下接口操作唤醒源的状态：

• EcuM_ClearWakeupEvent
• EcuM_SetWakeupEvent
• EcuM_ValidateWakeupEvent
• EcuM_CheckWakeup
• EcuM_DisableWakeupSources
• EcuM_EnableWakeupSources
• EcuM_StartWakeupSources
• EcuM_StopWakeupSources

ECU管理器模块最多可管理32个唤醒源。在上述EcuM接口中，唤醒源的状态通常通过EcuM_WakeupSourceType位掩码表示，其中每个唤醒源对应一个固定的位位置。有5个预定义的位位置，其余可通过配置分配。详见8.2.4节“EcuM_WakeupSourceType”。

一方面，ECU管理器模块管理每个唤醒源的模式；另一方面，ECU管理器模块假设存在“内部变量”（即EcuM_WakeupSourceType实例），用于跟踪哪些唤醒源处于特定状态（特别是NONE（已清除）、PENDING、VALIDATED和EXPIRED）。ECU管理器模块在相应的接口定义中使用这些“内部变量”来定义接口的语义。

因此，这些“内部变量”是否真的被实现并不重要。它们仅用于解释接口的语义。

7.6.4 唤醒验证序列中的活动

由于唤醒事件可能是非故意产生的（例如CAN总线上的EVM尖峰信号），因此在ECU恢复全面运行之前，有必要对唤醒进行验证。这一验证过程可确保ECU仅在真实有效的唤醒源触发下才进行状态切换，避免因误触发导致不必要的能耗或异常运行，是保障ECU稳定高效工作的重要环节。

所有唤醒源的验证机制都是相同的。当唤醒事件发生时，ECU会从睡眠状态被唤醒，并在MCU驱动的MCU_SetMode服务中恢复执行12。当唤醒重启序列完成后，ECU管理器模块会得到一个待验证的未处理唤醒事件列表（参见SWS_EcuM_02539）。随后，ECU管理器模块会释放BSW调度器和所有BSW主函数；在这种情况下，最值得注意的是，EcuM主函数可以恢复处理工作。

12 参见《MCU驱动规范》[10]中关于MCU_SetMode的描述。

实现提示：由于在StartPostOS序列和WakeupRestart序列结束时，SchM（调度器管理器）将处于运行状态，因此可能出现以下情况：EcuM_MainFunction会启动对某个唤醒源的验证，但该唤醒源对应的协议栈尚未初始化。集成者应配置适当的模式以指示协议栈不可用，并相应地禁用EcuM_MainFunction（参见[15]）。

[SWS_EcuM_02566]⌈ECU管理器模块应仅对配置要求验证的唤醒源执行唤醒验证。如果未配置验证协议（参见EcuMValidationTimeout ECUC_EcuM_00150），则调用EcuM_SetWakeupEvent（参见SWS_EcuM_02826）应同时意味着调用EcuM_ValidateWakeupEvent（参见SWS_EcuM_02829）。⌋()

[SWS_EcuM_02565]⌈ECU管理器模块应为每个需要验证的未处理唤醒事件启动验证超时。超时时间应针对具体事件（参见EcuMValidationTimeout ECUC_EcuM_00150）。⌋()

SWS_EcuM_02565的实现提示：对于一种实现而言，仅提供一个计时器就足够了，当有新的唤醒事件被报告时，可将该计时器延长至最大超时时间。

[SWS_EcuM_04081]⌈当某个未处理唤醒事件的验证超时时间到期时，EcuM_MainFunction应通过（OR运算）在内部已过期唤醒事件变量中设置相应的位（参见7.6.3节“唤醒状态的内部表示”）。⌋()

[SWS_EcuM_04082]⌈当某个未处理唤醒事件的验证超时时间到期时，EcuM_MainFunction应调用BswM_EcuM_CurrentWakeup，传入的EcuM_WakeupSourceType位掩码参数中需设置与该唤醒事件对应的位，状态值参数需设置为ECUM_WKSTATUS_EXPIRED。⌋()

BSW模式管理器（BswM）将被配置为通过ECU管理器发出的模式切换请求来监控唤醒验证情况，这些请求会在唤醒源被验证或计时器到期时产生。如果最后一个验证超时（参见SWS_EcuM_02565）在未经过验证的情况下到期，那么BswM应认为唤醒验证失败。如果至少有一个未处理事件通过了验证，那么整个验证应视为通过。

未处理事件通过调用EcuM_ValidateWakeupEvent（参见SWS_EcuM_02829）来进行验证。该调用必须放在驱动程序中或驱动程序之上的消费协议栈中（例如处理程序）。具体放置位置取决于硬件和软件设计。另请参见7.6.4.4节“带唤醒源的驱动程序要求”。

7.6.4.1 通信通道的唤醒

如果通信通道上发生唤醒事件，相应的总线收发器驱动程序必须通过调用EcuM_SetWakeupEvent（参见SWS_EcuM_02826）函数来通知ECU管理器模块。关于此通知的要求在5.2节“具有唤醒能力的外设”中描述。

[SWS_EcuM_02479]⌈ECU管理器模块应在调用EcuM_SetWakeupEvent（参见SWS_EcuM_02826）函数时，按照本章后续7.6.4.2节“唤醒源与ECU管理器的交互”执行唤醒验证协议。⌋()

7.6.4.2 唤醒源与ECU管理器的交互

ECU管理器模块应以相同方式处理所有唤醒源。流程如下：
当唤醒事件发生时，相应的驱动程序应将该唤醒事件通知给ECU管理器模块。这种通知最可能的方式有：
 退出Halt或Poll序列后。在这种情况下，ECU管理器模块调用EcuM_AL_DriverRestart（参见SWS_EcuM_02923）来重新初始化相关驱动程序，而这些驱动程序进而有机会扫描其硬件（例如扫描未处理的唤醒中断）。
 如果唤醒源实际上处于睡眠模式，驱动程序必须自主扫描唤醒事件，可通过轮询或等待中断的方式。

[SWS_EcuM_02975]⌈如果唤醒事件需要验证，那么ECU管理器模块应调用验证协议。⌋()

[SWS_EcuM_02976]⌈如果唤醒事件不需要验证，ECU管理器模块应发出模式切换请求，将该事件的模式设置为ECUM_WKSTATUS_VALIDATED。⌋()

[SWS_EcuM_02496]⌈如果唤醒事件通过了验证（无论是立即验证还是通过唤醒验证协议验证），ECU管理器模块应通过EcuM_GetValidatedWakeupEvents（参见SWS_EcuM_02830）函数提供该事件是当前ECU唤醒源的相关信息。⌋()

7.6.4.3 唤醒验证超时

[SWS_EcuM_04004]⌈ECU管理器模块应提供一个唤醒验证超时计时器，或者为每个唤醒源各提供一个计时器。⌋()

以下要求适用：
[SWS_EcuM_02709]⌈当调用EcuM_SetWakeupEvent（参见SWS_EcuM_02826）时，ECU管理器模块应启动唤醒验证超时计时器。⌋()
[SWS_EcuM_02710]⌈EcuM_ValidateWakeupEvent应停止唤醒验证超时计时器（参见SWS_EcuM_02829）。⌋()
[SWS_EcuM_02712]⌈如果后续针对同一唤醒源调用EcuM_SetWakeupEvent（参见SWS_EcuM_02826），ECU管理器模块不应重启唤醒验证超时。⌋()

如果仅使用一个计时器，建议采用以下方法：
如果在同一唤醒周期内，针对某个尚未触发的唤醒源调用EcuM_SetWakeupEvent（参见SWS_EcuM_02826），则ECU管理器模块应延长该唤醒源的验证超时时间。

唤醒超时通过配置进行定义（参见ECUC_EcuM_00148）。

7.6.4.4 带唤醒源的驱动程序要求

当检测到唤醒事件时，驱动程序必须调用一次EcuM_SetWakeupEvent（参见SWS_EcuM_02826），并提供一个EcuM_WakeupSourceType参数，该参数用于标识唤醒源（参见SWS_EcuM_02165、SWS_EcuM_02166），具体如配置中所规定（参见EcuMWakeupSourceId，ECUC_EcuM_00151）。

[SWS_EcuM_02572]⌈ECU管理器模块应检测在驱动程序初始化之前发生的唤醒，无论是来自Halt/Poll状态还是OFF状态的唤醒。⌋()

驱动程序必须提供一个API，用于为睡眠状态配置唤醒源、启用或禁用唤醒源，以及使相关外设进入睡眠状态。仅当硬件具备这些功能时，此要求才适用。

驱动程序应在其初始化函数中启用回调调用。

7.6.5 唤醒验证的要求

如果唤醒源需要验证，验证可由基础软件中任何一个合适的模块执行，但仅限一个模块。该模块可以是驱动程序、接口、处理程序或管理器。

通过调用EcuM_ValidateWakeupEvent（参见SWS_EcuM_02829）函数进行验证。

[SWS_EcuM_02601]⌈如果ECU管理器无法确定MCU驱动程序返回的复位原因，则ECU管理器应改为为默认唤醒源ECUM_WKSOURCE_RESET设置一个唤醒事件。⌋()

7.6.6 唤醒源与复位原因

ECU管理器模块API仅提供一种类型（EcuM_WakeupSourceType，参见8.2.4节“EcuM_WakeupSourceType”），该类型可描述ECU启动或唤醒的所有原因。

[SWS_EcuM_02625]⌈ECU管理器模块绝不应对以下唤醒源执行验证：

• ECUM_WKSOURCE_POWER（电源）
• ECUM_WKSOURCE_RESET（复位）
• ECUM_WKSOURCE_INTERNAL_RESET（内部复位）
• ECUM_WKSOURCE_INTERNAL_WDG（内部看门狗）
• ECUM_WKSOURCE_EXTERNAL_WDG（外部看门狗）。
  ⌋()

7.6.7 带集成电源控制的唤醒源

睡眠状态可由一个控制MCU电源的系统芯片实现。典型示例是带集成电源的CAN收发器，它可根据应用请求关闭电源，并在检测到CAN活动时开启电源。

其结果是，在这类硬件上，对于ECU管理器模块而言，睡眠状态看起来就像关闭状态（OFF）。这种区别更多是理论上的，并无实际重要性。

实际影响是，CAN上的被动唤醒对ECU而言就像一次上电复位。因此，ECU在唤醒事件后将继续执行启动（STARTUP）序列。尽管如此，仍需要进行唤醒验证，系统设计者必须考虑以下事项：

• CAN收发器在其中一个驱动程序初始化块中进行初始化（默认情况下由BswM控制）。这是经过配置或生成的代码，即处于系统设计者控制之下的代码。
• CAN收发器驱动程序API提供相关函数，用于查明是否是CAN收发器因被动唤醒而启动了ECU。系统设计者有责任检查CAN收发器的唤醒原因，并通过使用EcuM_SetWakeupEvent（参见SWS_EcuM_02826）和EcuM_ClearWakeupEvent（参见SWS_EcuM_02828）函数将该信息传递给ECU管理器模块。

这些原则可应用于所有带集成电源控制的唤醒源。CAN收发器仅作为示例。

7.7 关机目标

“关机目标”是对ECU所有无代码执行状态的描述性术语。之所以称为关机目标，是因为它们是状态机在退出运行阶段（UP phase）后将进入的目标状态。以下状态属于关机目标：

• 关闭（Off）¹³
• 睡眠（Sleep）
• 复位（Reset）

需要注意的是，确定关机目标的时间不一定是关机的开始时间。由于BSW模式管理器（BswM）现在控制着大多数ECU资源，它将决定设置关机目标的时间，并直接或间接进行设置。因此，BswM必须确保例如在调用EcuM_GoDownHaltPoll之前，将关机目标从默认值更改为ECUM_STATE_SLEEP。

在ECU管理器模块的早期版本中，睡眠目标被特殊处理，因为ECU中实现的睡眠模式取决于ECU的能力。这些睡眠模式依赖于硬件，通常在时钟设置或硬件提供的其他低功耗功能上有所不同。这些不同的功能可通过MCU驱动程序以所谓的MCU模式访问（参见[10]）。

复位的执行方式也有多种，由不同模块控制或触发：

• Mcu_PerformReset（MCU执行复位）
• WdgM_PerformReset（看门狗管理器执行复位）
• 通过DIO/SPI切换I/O引脚

ECU管理器模块提供了一种机制，通过跟踪先前复位的时间和原因来管理这些复位方式。各种复位方式将被视为复位模式，使用与睡眠模式相同的模式机制。

有关关机管理机制的接口定义，请参见8.3.4节“关机管理”。

7.7.1 睡眠

[SWS_EcuM_02188]⌈在睡眠阶段（SLEEP phase）不得遗漏任何唤醒事件。如果在进入睡眠序列（GoSleep sequence）中发生了唤醒事件，则不得进入暂停（Halt）或轮询（Poll）序列。⌋()

[SWS_EcuM_02957]⌈ECU管理器模块可定义一组可配置的睡眠模式（参见EcuMSleepMode ECUC_EcuM_00131），其中每种模式本身就是一个关机目标。⌋()

[SWS_EcuM_02958]⌈ECU管理器模块应允许将MCU睡眠模式映射到ECU睡眠模式，从而允许将它们作为关机目标进行访问。⌋()

[SWS_EcuM_04092]⌈睡眠关机目标（ShutdownTarget Sleep）应使所有内核进入睡眠状态。⌋()

7.7.2 复位

[SWS_EcuM_04005]⌈ECU管理器模块应定义一组可配置的复位模式（参见EcuMResetMode ECUC_EcuM_00172和8.2.7节“EcuM_ResetType（SWS_EcuM_04044）”），其中每种模式本身就是一个关机目标。该组至少应包含以下目标对应的模式：

• Mcu_PerformReset（MCU执行复位）
• WdgM_PerformReset（看门狗管理器执行复位）
• 通过DIO/SPI切换I/O引脚⌋()

[SWS_EcuM_04006]⌈ECU管理器模块应允许为复位目标定义别名（参见EcuM180_Conf）。⌋()

[SWS_EcuM_04007]⌈ECU管理器模块应定义一组可配置的复位原因（参见EcuMShutdownCause ECUC_EcuM_00175和8.2.8节“EcuM_ShutdownCauseType（SWS_EcuM_04045）”）。该组至少应包含以下目标对应的原因：

• ECU状态机进入关机状态
• 看门狗管理器（WdgM）检测到故障
• 诊断通信管理器（DCM）请求关机
  以及复位发生的时间。⌋()

[SWS_EcuM_04008]⌈ECU管理器模块应向BSW模块和软件组件（SW-Cs）提供以下机制（参见8.3.4节“关机管理”）：

• 记录关机原因
• 获取一组最近的关机原因⌋()

¹³ 关闭状态（OFF state）要求ECU具备自行关闭的能力。并非所有硬件设计都支持这一点。