AUTOSAR_SWS_ECUStateManager
Specification of ECU State Manager
简介和功能概述
EcuM 模块（如本文档中所述）是一个基本软件模块（参见 AUTOSAR_TR_BSWModuleList.pdf），用于管理 ECU 状态的常见方面。具体来说，ECU 管理器模块：
- 初始化和取消初始化 OS、SchM 和 BswM 以及一些基本软件驱动模块
- 根据请求将 ECU 配置为休眠和关机
- 管理 ECU 上的所有唤醒事件
ECU 管理器模块提供唤醒验证协议来区分
- “真实”唤醒事件
- “不稳定”唤醒事件
此外：
- 部分或快速启动
- 其中 ECU 以有限的功能启动。
- 然后根据应用程序的决定，继续逐步启动。
- 交错启动
- ECU 以最低限度启动，然后启动 RTE 以尽快执行软件组件中的功能。
- 然后它继续启动其他 BSW 和软件组件，从而交错 BSW 和应用程序功能。
- 多个运行状态
- 其中 ECU 具有多个运行状态。
- 除其他外，这改进了从休眠状态到运行状态的频谱概念。
- 现在可以有一系列运行状态，从经典运行（完全运行）到最深的休眠（处理器停止）。
- 多核 ECU
- 启动、关机、休眠和唤醒在 ECU 的所有核心上协调。
灵活的 ECU 管理采用以下模块提供的通用模式管理设施：
- RTE 和 BSW 的调度模块（参见 AUTOSAR_SWS_RTE.pdf）现在合并为一个模块：
- 该模块支持自由配置的 BSW 和应用程序模式以及切换模式功能。
- BSW 模式管理器模块（参见 AUTOSAR_SWS_BSWModeManager.pdf）：
- 该模块实现可配置规则和操作列表，以评估切换 ECU 模式的条件并实施必要的操作。
因此，通过灵活的 ECU 管理，大多数 ECU 状态不再在 ECU 管理器模块中被实现。通常，只有当通用模式管理设施在以下情况下不可用时，ECU 管理器模块才会接管控制：
- 早期启动阶段
- 后期关机阶段
- 休眠阶段（设施被调度程序锁定）
在 ECU 管理器模块的启动阶段，BSW 模式管理器负责进一步的操作。而 ECU 管理器模块则仲裁来自软件组件的 RUN 和 POST_RUN 请求，并通知 BswM 有关模式的状态。
向后兼容先前版本的 ECU 管理器模块
如果进行了相应配置，灵活的 ECU 管理可以向后兼容以前的 ECU 管理器版本。
有关兼容性配置的更多信息，请参阅“模式管理指南”（参见 AUTOSAR_EXP_ModeManagementGuide.pdf）。
首字母缩略词和缩写
定义
缩写
约束和假设
约束
ECU 不能总是关闭（即零功耗）。
原理：只有使用 ECU 特殊硬件（例如电源保持电路）才能达到关断目标 OFF。如果此硬件不可用，本规范建议将关断行为改为发出重置。除此之外，其他默认行为是允许的。
假设
ECU 管理器模块适用于所有汽车领域。
对其他模块的依赖
如果需要将数据指针传递给 BSW 模块，则指针地址指向的位置需要位于内存空间共享部分中的某个位置。
MCU 驱动程序
MCU 驱动程序是 ECU 管理器模块初始化的第一个基本软件模块。
- 然而，当 MCU_Init 返回时（参见 [SWS_EcuM_02858]），MCU 模块和 MCU 驱动程序模块不一定完全初始化。可能需要额外的 MCU 模块特定步骤来完成初始化。
- ECU 管理器模块提供了两个可以放置这些附加代码的回调接口。有关详细信息，请参阅第 7.3.2 节 StartPreOS 序列中的活动。
驱动程序依赖性和初始化顺序
BSW 驱动程序可能相互依赖。典型示例是看门狗驱动程序，它需要 SPI 驱动程序来访问外部看门狗。这意味着，一方面驱动程序可能被堆叠（与 ECU 管理器模块无关），另一方面必须在初始化调用模块之前初始化已被调用的模块。
系统设计人员负责在配置时在
- EcuMDriverInitListZero
- EcuMDriverInitListOne
- EcuMDriverRestartList
- EcuMDriverInitListBswM
中定义初始化顺序。
具有唤醒功能的外设
唤醒源必须由驱动程序处理和封装。
这些驱动程序必须遵循本文档中介绍的协议和要求，以确保无缝集成到 AUTOSAR BSW。基本上，协议如下：
- 驱动程序必须调用 EcuM_SetWakeupEvent（参见 [SWS_EcuM_02826]）来通知 ECU 管理器模块已检测到待处理的唤醒事件。驱动程序不仅需要在 ECU 处于休眠阶段并等待唤醒事件时调用 EcuM_SetWakeupEvent，还必须在驱动程序初始化阶段和 EcuM_MainFunction 运行时的正常运行期间调用 EcuM_SetWakeupEvent。
- 驱动程序必须提供显式函数来使唤醒源进入休眠状态。该函数应使唤醒源进入节能和惰性运行模式，并重新启动唤醒通知机制。
如果唤醒源能够生成虚假事件1，那么
- 驱动程序
- 使用驱动程序的软件堆栈
- 另一个适当的 BSW 模块
必须为唤醒事件提供验证调用或调用 ECU 管理器模块的验证功能。
如果不需要验证，则此要求不适用于相应的唤醒源。
操作系统
ECU 管理器模块可启动 AUTOSAR OS 或将其关闭。ECU 管理器模块定义了
- 在 OS 启动之前
- 在 OS 关闭之后
如何处理控制的协议。
BSW 调度器
ECU 管理器模块初始化 BSW 调度程序，并且包含 EcuM_MainFunction（参见 [SWS_EcuM_02837]），该函数被定期调度执行以评估唤醒请求并更新闹钟。
BSW 模式管理器
ECU 状态通常以 AUTOSAR 模式实现，BSW 模式管理器负责监控 ECU 中的变化并根据需要影响与 ECU 状态机有关的相应变化。
- 有关 AUTOSAR 模式管理的讨论，请参阅虚拟功能总线规范（AUTOSAR_EXP_VFB.pdf）。
- 有关 ECU 状态机实现细节以及如何配置 BSW 模式管理器以实现 ECU 状态机的指南，请参阅模式管理指南（AUTOSAR_EXP_ModeManagementGuide.pdf）。
BSW 模式管理器只能在模式管理运行后（即从 SchM 初始化开始，直到 SchM 取消初始化或停止后）管理 ECU 状态机。
- 当 BSW 模式管理器不运行时，ECU 管理器模块将接管 ECU 的控制权。
- 因此，ECU 管理器模块在 ECU 启动后立即接管控制权，并在 SchM 和 BswM 完成初始化后将控制权交给 BSW 模式管理器。
- BswM 将 ECU 的控制权交还给 ECU 管理器模块，以锁定操作系统并处理唤醒事件。
- 在操作系统关机停止之前，BswM 还会立即将控制权交还给 ECU 管理器。
- 当验证唤醒源时，ECU 管理器模块通过模式切换请求向 BswM 指示唤醒源状态变化。
软件组件
ECU 管理器模块处理以下 ECU 范围的属性：
- Shutdown 目标
本规范假设软件组件通过 AUTOSAR 端口设置这些属性，通常由软件组件的某些 ECU 特定部分来设置。ECU 管理器不会阻止软件组件覆盖软件组件所做的设置。这个策略必须在上层定义。
以下措施可能有助于解决这一问题。
- 软件组件模板可能包含一个字段来指示软件组件是否设置了 Shutdown 目标。
- 生成工具可能只允许有一个软件组件访问 Shutdown 目标的配置。
代码文件结构
本规范并未完整定义代码文件结构。
[SWS_EcuM_02990]
[ ]
- ECU 管理器模块实现应提供一个 EcuM_Callout_Stubs.c 文件，其中包含在此实现中实现的回调函数的临时代码。
另请参阅第 8.5 节回调定义，了解可能实现的回调列表。
EcuM_Callout_Stubs.c 是否可以手动编辑或仅由其他生成的文件组成取决于实现。
头文件结构
另请参阅第 8.7 章预期接口，了解与其他模块的依赖关系。
需求可追溯性
功能规格
第 1 章介绍了 ECU 状态管理的更新、更灵活的方法。
然而，这种灵活性是以牺牲责任为代价的，因为没有标准的 ECU 模式或状态。ECU 集成商必须决定哪些状态是需要的并对其进行配置。
当使用 ECU 模式控制时，标准状态 RUN 和 POST_RUN 通过 RUN 请求协议来仲裁并被传递到 BswM。系统设计人员必须确保在通过对 BswM 的操作来设置 EcuM 的模式时满足相应状态的前提条件。
请注意，BSW 和软件组件都不能对某些 ECU 模式或状态有依赖，尽管 BSW 的先前版本基本上对它们没有依赖。
本文档仅指定了在 ECU 管理器模块中被保留的功能。
有关 ECU 状态管理的完整信息，请参阅其他相关模块的规范，即 RTE 和 BSW 调度程序模块（AUTOSAR_SWS_RTE.pdf）和 BSW 模式管理器模块（AUTOSAR_SWS_BSWModeManager.pdf）。
请参阅模式管理指南（AUTOSAR_EXP_ModeManagementGuide.pdf），了解一些 ECU 状态的示例用例以及所涉及的 BSW 模块之间的交互。
ECU 管理器模块通过与过去相同的方式来管理唤醒源的状态。设置/清除/验证唤醒事件的 API 保持不变，但显著的区别在于现在这些 API 是回调。
对唤醒源的处理始终是既定的，不仅在唤醒期间进行，而且在唤醒之后也持续进行，与所有其他 EcuM 的活动并行存在。此功能现在通过模式请求的方式与其余 ECU 管理完全分离。
ECU 管理器模块的阶段
ECU 管理器模块规范的早先版本已经区分了 ECU 状态和 ECU 模式。
ECU 模式是 ECU 活动的长持续时间运行周期，这些活动对应用程序可见并为其提供导向，即启动、关闭、休眠和唤醒。
ECU 管理器状态通常是 ECU 管理器模块多个操作的连续序列，通过等待外部条件被满足的方式来退出。例如，启动1 包含 OS 启动之前的所有 BSW 初始化操作，并在 OS 将控制权返回给 ECU 管理器模块时退出。
对于当前的灵活 ECU 管理器，存在在定义和缩略词中定义的几种状态、模式和阶段。
在这里，在 BSW 模式管理器模块的控制下，ECU 状态机作为通用模式被实现。这会产生一个术语问题，因为旧的 ECU 状态现在变成了可通过 RTE_Mode 端口接口看到的模式，而旧的 ECU 模式变成了阶段。
由于 VFB 定义的模式（并在 RTE 中被使用）仅在 UP 阶段（ECU 管理器处于被动状态）可用，因此有必要将术语从模式更改为阶段。
图 7.1 显示了灵活 ECU 管理器模块的各个阶段的概览。
在模式管理设施运行之前，STARTUP 阶段将一直持续。基本上，STARTUP 阶段由启动模式管理所需的最少活动组成：
- 初始化低级驱动程序
- 启动操作系统
- 初始化 BSW 调度程序和 BSW 模式管理器模块
同样，SHUTDOWN 阶段是 STARTUP 阶段的反向阶段，在此阶段模式管理将被取消初始化。
UP 阶段由所有未突出显示的状态组成。在此阶段，ECU 会根据集成器定义的状态机的指示从一个状态转到另一个状态，从一个模式转到另一个模式。
如果使用 ECU 模式控制，UP 阶段包含默认模式。这些模式之间的转换由 ECU 状态管理器模块和 BSW 模式管理器模块之间的协作完成。
请注意，UP 阶段包含一些以前的休眠状态。从“OS 调度程序被锁定以防止其他任务在休眠中运行”到“退出使 ECU 进入休眠状态的 MCU 模式”，模式管理设施不会运行。ECU 管理器模块此时⽀持处理唤醒的功能。
STARTUP 阶段
STARTUP 阶段的目的是初始化基础软件模块，使通用模式管理设施可以运行。有关初始化的更多详细信息，请参阅第7.3 章。
UP 阶段
本质上，当 BSW 调度器启动并调用 BswM_Init 时将进入 UP 阶段 。此时：
- 内存管理尚未初始化
- 没有通信堆栈
- 没有软件组件⽀持 (RTE)
- 并且软件组件未启动
处理过程以某种模式（配置的启动后的下一个模式）开始，并带有相应的可运行函数，即 BSW MainFunctions，然后以任意组合的模式变化继续进行，这会导致 BswM 将执行操作并触发和禁用相应的可运行函数。
但是，从 ECU 管理器模块的角度来看，ECU 处于“启动”状态。
然后，BSW 模式管理器模块将启动模式仲裁，并且启动所有进一步的 BSW 初始化过程，启动的 RTE 和（隐式地）启动的软件组件将变为在集成器的控制下生效的：
- 在 BswM 的操作列表中被执行的代码
- 或由与模式相关的调度驱动的代码
因此，初始化 NvM 并调⽤ NvM_ReadAll 也将成为集成代码的一部分。
这意味着集成器负责在 NvM_ReadAll 结束时触发 COM、DEM 和 FIM 的初始化。
当 NvM_ReadAll 完成调用时，NvM 会通知 BswM 模块。
请注意，在 NvM 和 COM 完成初始化后，可以启动 RTE。并请注意，在 COM 可被初始化之前，无需完全初始化通信堆栈。
这些变化会初始化 BSW 模块并以任意顺序启动软件组件，直到 ECU 达到满负荷状态，此后这些变化还会继续影响 ECU 的能力。
最终，模式开关将使软件组件停止运行并逆初始化 BSW，以便当 ECU 达到可以下电的状态时，UP 阶段结束。
因此，就 ECU 管理器模块而言，BSW 和软件组件会一直运行，直到他们为 ECU 进入关闭或休眠状态的情况做好准备。
有关如何设计模式驱动的 ECU 管理以及如何相应地配置 BSW 模式管理器的指导，请参阅模式管理指南（AUTOSAR_EXP_ModeManagementGuide.pdf）。
SHUTDOWN 阶段
[SWS_EcuM_03022]
[SRS_ModeMgm_09072]
- SHUTDOWN 阶段处理的是基础软件模块的受控 Shutdown，最终导致所选的 Shutdown 目标，OFF 或者 RESET。
SLEEP 阶段
ECU 在休眠阶段将节省能源。通常，不执行任何代码（某些 ECU 设计实际上确实需要执行代码来实现休眠状态（以及唤醒功能）。对于这些 ECU，时钟速度通常会大幅降低。这些功能可以通过休眠状态中的小循环来实现），但仍有电源供应，如果进行了相应配置，ECU 即可在此状态下被唤醒。
ECU 管理器模块提供了一组可配置的（硬件）休眠模式，这些模式通常是在功耗和 ECU 启动时间之间做权衡。
ECU 管理器模块会根据预期或非预期的唤醒事件唤醒 ECU。由于需要忽略非预期唤醒事件，因此 ECU 管理器模块提供了一个协议来验证唤醒事件。
该协议指定了处理唤醒源的驱动程序和 ECU 管理器之间的协作过程（请参阅第 7.6.4 节）。
OFF 阶段
ECU 在断电时进入 OFF 状态。ECU 可能在此状态下被唤醒，但仅限于具有集成电源控制的唤醒源。在任何情况下，ECU 都必须为可启动的（例如通过复位事件）。
ECU 管理器结构描述
图 7.2 说明了 ECU 管理器模块与其他 BSW 模块接口的关系。在大多数情况下，ECU 管理器模块仅负责初始化（准确地说，“初始化”也可能意味着逆初始化）。但是，有些模块与 ECU 管理器模块具有功能关系，这将在以下段落中解释。
标准化的 AUTOSAR 软件模块
一些基础软件驱动模块在被 ECU 管理器模块唤醒时被初始化、关闭并重新初始化。
OS 由 ECU 管理器初始化和关闭。
OS 初始化后，ECU 管理器模块将执行其他初始化步骤，然后将控制权移交给 BswM。BswM 在 OS Shutdown 前立即将执行控制权交还给 ECU 管理器模块。详细信息请参阅第 7.3 章 STARTUP 和第 7.4 章 SHUTDOWN。
软件组件
软件组件包含 AUTOSAR ECU 的应用程序代码。
软件组件使用 AUTOSAR 端口与 ECU 管理器模块交互。
STARTUP 阶段
有关 STARTUP 阶段的概述描述请参见第 7.1.1 章。
图 7.3 显示了 ECU 的启动行为。当通过 EcuM_Init 调用时， ECU 管理器模块将控制 ECU 启动过程。通过调用 StartOS，ECU 管理器模块暂时放弃控制权。要重新获得控制权，集成器必须实现一个自动启动的 OS 任务，并调用 EcuM_StartupTwo 作为其第一个操作。
EcuM_Init 之前的活动
ECU 管理器模块假定在调用 EcuM_Init （参见 [SWS_EcuM_02811] ）之前已经进行了 MCU 的最小初始化，堆栈已设置完成并可以执行代码，并且已经执行了变量的 C 初始化。
StartPreOS 序列中的活动
[SWS_EcuM_02411]
[ ]
- 表格 StartPreOS 序列显示了 StartPreOS 序列中的活动以及它们在 EcuM_Init 中被执行的顺序（参见 [SWS_EcuM_02811] ）。
对“Opt.”列的注释：可以通过配置打开或关闭的可选活动。详情请参阅 10.1 节常用容器和配置参数。
[SWS_EcuM_02623]
[ ]
- ECU 管理器模块应记住由重置原因转换导致的唤醒源（参见表格 StartPreOS 序列）。
[SWS_EcuM_02623] 的理由：唤醒源必须由 EcuM_MainFunction 进行验证（参见第 7.6.4 节“WakeupValidation 序列中的活动”）。
[SWS_EcuM_02684]
[ ]
- 当通过 EcuM_Init（参见 [SWS_EcuM_02811] ）函数被激活时，ECU 管理器模块应执行 StartPreOS 序列中的操作（参见表 StartPreOS 序列）。
StartPreOS 序列旨在让 ECU 准备好初始化操作系统，并且应尽可能简短。驱动程序应尽可能在 UP 阶段完成初始化，回调也应保持简短。
不应在此序列中必须使用中断。如果必须使用中断，则只能在 StartPreOS 序列 1 中使用 I 类中断（类别 II 中断需要运行的操作系统，而类别 I 中断则不需要。
AUTOSAR OS 要求每个中断向量需要被专门放入一个类别中）。
驱动程序和硬件抽象模块的初始化并没有严格地由 ECU 管理器定义。
两个回调
- EcuM_AL_DriverInitZero（参见 [SWS_EcuM_02905]）
- EcuM_AL_DriverInitOne（参见 [SWS_EcuM_02907]）
被提供用于初始化块 0 和 1。这些块包含与 StartPreOS 序列相关的初始化活动。
MCU_Init 不提供完整的 MCU 初始化。此外，必须执行与硬件相关的步骤，并且他们必须在系统设计时被定义。
应该在
- EcuM_AL_DriverInitZero（参见 EcuM_AL_DriverInitZero， [SWS_EcuM_02905] ）
- EcuM_AL_DriverInitOne（参见EcuM_AL_DriverInitOne， [SWS_EcuM_02907] ）
中采取这些步骤。
详情可参见 MCU 驱动程序规范（AUTOSAR_SWS_MCUDriver.pdf）。
[SWS_EcuM_02181]
[ ]
- ECU 管理器模块应使用配置的默认关闭目标（EcuMDefaultShutdownTarget）调用EcuM_GetValidatedWakeupEvents 。
参见 7.7 节关闭目标。
[SWS_EcuM_02603]
[ ]
- StartPreOS 序列应初始化所有启动操作系统所需的基础软件模块。
StartPostOS 序列中的活动
对“Opt.”列的注释：可以通过配置打开或关闭可选的活动。
详情请参阅 10.1 节常用容器和配置参数。
[SWS_EcuM_02932]
[SRS_ModeMgm_09113]
- 当通过 EcuM_StartupTwo 回调被激活时（参见 [SWS_EcuM_02838] ），ECU 管理器模块应执行在 StartPostOS 序列中的操作（见表7.2）。
在 ECU 管理器中检查配置一致性的必要性
在 AUTOSAR ECU 中，需要设置多个配置参数并在不同的时间将其放入 ECU。设置预编译参数，将其插入生成的源代码并编译为目标代码。
源代码编译完成后，链接时参数被设置，编译并与先前配置的目标代码一起被链接成需要被放入 ECU 的镜像。
最后，在不同时间点，后构建参数被设置，编译、链接并被放入 ECU。所有这些参数必须匹配才能获得稳定的 ECU。
配置工具可以自行检查配置时参数的一致性。编译器可以在编译时检测参数错误，而链接器可以在链接时发现其他错误。
不幸的是，在后构建参数中查找配置错误非常困难。这只能通过检查
- “在编译代码时”使用的预编译和链接时参数的设置
与
- “在配置和编译后构建参数时”使用的预编译和链接时参数的设置
是否一致来实现。
这只能在运行时被完成。
[SWS_EcuM_02796] 的解释： ECU 管理器模块在初始化第一个 BSW 模块之前会检查一次一致性，以避免多次检查分散在不同的 BSW 模块上。
这也意味着：
[SWS_EcuM_02796]
[ ]
- 管理器模块不仅应检查其自身参数的一致性，还应检查在初始化第一个 BSW 模块之前的所有后构建可配置 BSW 模块。
ECU 管理器配置工具必须计算所有 BSW 模块的预编译和链接时配置参数的哈希值，并将值存储在链接时 ECUM_CONFIGCONSISTENCY_HASH（参见EcuMConfigConsistencyHash）配置参数。
哈希值是必要的，原因有两个。
- 首先，预编译和链接时参数在运行时不可访问。
- 其次，检查运行时必须非常高效。
比较数百个参数会导致 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 文件中配置参数的顺序如何。
哈希计算算法示例
注意：本章不是规范性的。它描述了一种计算哈希值的可能的方法。
对配置参数值进行简单的 CRC 校验并不是一个好的哈希算法。它只能检测全局变化，例如，一个参数从 1 变为 2。但如果同时另一个参数从 2 变为 1，则 CRC 可能保持不变。
此外，在哈希算法中，不仅要考虑配置参数的值，还要考虑它们的名称。
一种可能性是建立一个包含配置参数和容器名称的文本文件，使用分隔符（例如冒号）将它们与值分开，并将每个参数作为一行放入文本文件中。
如果有多个相同类型的容器，则每个容器名称可以附加一个数字，例如“_0”，“_1”等等。
为了使哈希值独立于写入文本文件的参数的顺序，现在必须按字典顺序对文件中的行进行排序。
最后，可以在文本文件上运行加密性强的哈希函数（例如 MD5）来生成哈希值。
这些哈希函数对于略有变化的输入文件会产生完全不同的哈希值。
驱动程序初始化
驱动程序在初始化过程中的位置在很大程度上取决于它的实现方式和电路板的硬件设计。
驱动程序可由 ECU 管理器模块在 STARTUP 阶段的初始化块 0 或初始化块 1 中完成初始化，或在 WakeupRestart 序列的 EcuM_AL_DriverRestart 调用中进行重新初始化。
驱动程序也可由 BswM 在 UP 阶段进行初始化或重新初始化。
本章适用于除 SchM 和 BswM 之外的 AUTOSAR 基础软件驱动程序，其初始化和重新初始化由 ECU 管理器模块而不是 BswM 处理。
[SWS_EcuM_02559]
[SRS_BSW_00416]
[SRS_ModeMgm_09234]
- ECU 管理器模块的配置应指定初始化块 0 和初始化块 1 内的初始化调用顺序。（参见EcuMDriverInitListZero 和 EcuMDriverInitListOne ）。
[SWS_EcuM_02730]
[SRS_ModeMgm_09234]
- ECU 管理器模块应使用派生自驱动程序的 EcuMModuleService 配置容器的参数来调用每个驱动程序的初始化函数。
[SWS_EcuM_02947]
[SRS_ModeMgm_09234]
- 对于 WakeupRestart 期间的重新初始化，集成器应使用 EcuMDriverRestartList 将重启代码块集成到 EcuM_AL_DriverRestart 的集成代码中（参见 [SWS_EcuM_02923] ） 。
[SWS_EcuM_02562]
[ ]
- EcuMDriverRestartList 可能包含将作为唤醒源的驱动程序。EcuM_AL_DriverRestart 应重新启动这些驱动程序的回调（“检测到唤醒”时触发）的触发机制。
参见第 7.5.5 节“WakeupRestart 序列中的活动”。
[SWS_EcuM_02561]
[ ]
- ECU 管理器模块应按照与列表（初始化块 0 和初始化块 1 的组合列表）相同的顺序初始化 EcuMDriverRestartList 中的驱动程序。
[SWS_EcuM_02561] 提示： EcuMDriverRestartList 通常只包含初始化块 0 和初始化块 1 驱动程序的组合列表的子集。
表 7.3 显示了初始化块 0 和 1 的一种可能（且推荐）的活动的序列。根据硬件和软件配置，可以添加或省略 BSW 模块，也可能采用其他序列。
初始化块 0 中的驱动程序在 EcuMDriverInitListZero 配置容器中列出。
初始化块 1 中的驱动程序在 EcuMDriverInitListOne 配置容器中列出。
BSW 初始化
其余的 BSW 模块由 BSW 模式管理器初始化，该操作通过使用 ECU 管理器 ( EcuMDriverInitCalloutName [ECUC_EcuM_00227] ) 的配置函数来完成，ECU 管理器从配置的初始化函数列表( EcuMDriverInitListBswM ) 中被创建。
[SWS_EcuM_04142]
[ ]
- ECU 管理器模块的配置应指定在 BSW 初始化内部的初始化调用顺序（参见 EcuMDriverInitListBswM ）。
SHUTDOWN 阶段
有关 SHUTDOWN 阶段的概述，请参阅第 7.1.3 节 SHUTDOWN 阶段。
带有 Shutdown 目标 RESET 或 OFF 的 EcuM_GoDownHaltPoll 将启动 SHUTDOWN 阶段。
[SWS_EcuM_02756]
[ ]
- 当 SHUTDOWN 阶段发生唤醒事件时，ECU 管理器模块应完成关机并立即重新启动。
OffPreOS 序列中的活动
[SWS_EcuM_03021]
[SRS_ModeMgm_09127]
- 请参阅表 7.4。
可选列的注释：可选活动可以通过配置来打开或关闭。它应由系统设计人员选择在 ECU 设计中是否将模块编译到最终产物中。有关详细信息，请参阅第 10.1 章“通用容器和配置参数”。
[SWS_EcuM_04151]
[SRS_ModeMgm_09104]
- 在 OffPreOS 中，如果配置参数 EcuMIgnoreWakeupEvValOffPreOS 被设置为 True，则只应考虑不需要验证的唤醒事件，所有其他唤醒事件都应被忽略。
[SWS_EcuM_04152]
[SRS_ModeMgm_09104]
- 在 OffPreOS 中，如果配置参数 EcuMIgnoreWakeupEvValOffPreOS 设置为 False，则不需要验证的唤醒事件和需要验证的待处理唤醒事件应被考虑。
注意：由于在 OffPreOS 序列中 SchM 已经取消初始化，因此调度函数不会被执行，与此同时也无法再验证唤醒源。在 OffPreOS 中会被考虑的唤醒事件的范围取决于 EcuMIgnoreWakeupEvValOffPreOS 的设置。
[SWS_EcuM_02952]
[SRS_ModeMgm_09104]
- 作为其最后一个活动，ECU 管理器模块应调用 ShutdownOS 函数。
OS 在它 Shutdown 结束时调用 Shutdown 钩子。
[SWS_EcuM_02953]
[SRS_ModeMgm_09104]
- Shutdown 钩子应调用 EcuM_Shutdown （参见 [SWS_EcuM_02812] ）来终止 Shutdown 过程。EcuM_Shutdown （请参阅 [SWS_EcuM_02812] ）不应返回，但应关闭 ECU 或使其复位。
OffPostOS 序列中的活动
OffPostOS 序列在 OS 关闭后执行最后步骤以达到 Shutdown 目标。EcuM_Shutdown （参见[SWS_EcuM_02812 ] ）启动该序列。
关机目标可以是 ECUM_SHUTDOWN_TARGET_RESET 或 ECUM_SHUTDOWN_TARGET_OFF，具体复位方式由复位模式决定。详情请参阅 7.7 Shutdown 目标一节。
可选列的注释：可选活动可以通过配置来打开或关闭。它应由系统设计人员选择在 ECU 设计中是否将模块编译到最终产物中。有关详细信息，请参阅第 10.1 章“通用容器和配置参数”
[SWS_EcuM_04074]
[ ]
- 当 Shutdown 目标为 RESET 时，ECU 管理器模块应调用 EcuM_AL_Reset。
有关详细信息，请参阅第 8.5.3.4 节 EcuM_AL_Reset ( [SWS_EcuM_04065] )。
[SWS_EcuM_04075]
[ ]
- 当 Shutdown 目标为 OFF 时，ECU 管理器模块应调用 EcuM_AL_SwitchOff。
有关详细信息，请参阅第 8.5.3.3 节 EcuM_AL_SwitchOff ( [SWS_EcuM_02920] )。
SLEEP 阶段
有关 SLEEP 阶段的概述，请参阅第 7.1.4 节 SLEEP 阶段。带有 Shutdown 目标 SLEEP 的 EcuM_GoDownHaltPoll 将启动 SLEEP 阶段。
带有 Shutdown 目标 SLEEP 的 EcuM_GoDownHaltPoll 将启动两个控制流，具体取决于所选的休眠模式（EcuMSleepModeSuspend 参数），两者在实现休眠机制上有结构性的不同。但它们的“准备休眠“和”从休眠中恢复“序列是相同的。
另一个模块，BswM，尽管它也可能是软件组件，必须确保在调用 EcuM_GoDownHaltPoll 之前已选择了适当的 ECUM_STATE_SLEEP Shutdown 目标。
GoSleep 序列中的活动
在 GoSleep 序列中，ECU 管理器模块将配置硬件，使其为即将到来的休眠阶段做好准备，同时设置 ECU 使其为下一个唤醒事件做好准备。
[SWS_EcuM_02389]
[SRS_ModeMgm_09100]
- 为了为下一个休眠模式设置唤醒源，ECU 管理器模块应为每个唤醒源（在 EcuMWakeupSourceMask 中为目标休眠模式配置的）执行 EcuM_EnableWakeupSources （参见 [SWS_EcuM_02546] ） 。
[SWS_EcuM_02951]
[ ]
- 与 SHUTDOWN 阶段不同，ECU 管理器模块在进入休眠阶段时不应关闭操作系统。休眠模式（即 EcuM 休眠阶段和 MCU 模式的组合）对操作系统应是透明的。
[SWS_EcuM_03010]
[ ]
- 在多核 ECU 上运行时，EcuM 应为每个核心保留专用资源（RES_AUTOSAR_ECUM），该资源在 GoSleep 期间被分配。
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 完整性的代码。
轮询序列中的活动
休眠模式下的轮询序列可用于检查唤醒源。
[SWS_EcuM_03020]
[ ]
- 在轮询序列中，EcuM 应在会产生阻塞状态的循环中调用 EcuM_SleepActivity 和 EcuM_CheckWakeupHook（如果 EcuMWakeupSourcePolling 设置为 True) ，直到一个待处理/已验证的唤醒事件被上报。
退出 Halt 或 Poll
[SWS_EcuM_02963]
[ ]
- 如果在 ECU 处于 Halt 或 Poll 状态时发生唤醒事件（例如切换唤醒线路、CAN 总线上的通信等），则 ECU 管理器模块应通过执行 WakeupRestart 序列来重新获得控制权并退出休眠阶段。
- 可以调用 ISR 来处理唤醒事件，但这取决于硬件和驱动程序的实现。
参见 7.5.5 节“WakeupRestart 序列中的活动”。
[SWS_EcuM_04001]
[ ]
- 如果在 ECU 处于 Halt 或 Poll 状态时发生异常事件（硬件复位或电源循环），则 ECU 管理器模块应在 STARTUP 阶段重新启动 ECU。
WakeupRestart 阶段的活动
ECU 管理器模块调用 EcuM_AL_DriverRestart （参见 [SWS_EcuM_02923] ），用于重新初始化驱动程序。除其他外，具有唤醒源的驱动程序通常需要重新初始化。有关驱动程序初始化的更多详细信息，请参阅第 7.3.5 节“驱动程序初始化”。
在重新初始化期间，驱动程序必须检查其分配的唤醒源之一是否是之前唤醒的原因。如果检查结果为真，则驱动程序必须调用其“检测到唤醒”时触发的回调（例如，请参阅 CAN 收发器驱动程序规范（AUTOSAR_SWS_CANTransceiverDriver.pdf） ），而该回调又必须调用 EcuM_SetWakeupEvent （请参阅 [SWS_EcuM_02826] ）函数。
驱动程序应被实现为仅调用一次唤醒回调。此后，它不应再次调用唤醒回调，直到通过显式函数调用的方式重新启用它为止。因此，必须重新启用驱动程序才能再次触发回调。
[SWS_EcuM_02539]
[ ]
- 如果在 WakeupRestart 序列完成时，ECU 管理器模块有一个唤醒源候选列表，则 ECU 管理器模块应在 EcuM_MainFunction 中验证这些唤醒源候选。
参见 7.6.4 节 WakeupValidation 序列中的活动。
[SWS_EcuM_04066]
[ ]
[SWS_EcuM_04148]
[ ]
- 如果一个 WakeupEvent 被上报，EcuM 将退出休眠模式。
[SWS_EcuM_04149]
[ ]
- 如果所有 WakeupSource 的 CheckWakeupTimer 都已过期，则 EcuM 将转换到 GoSleep 状态并开始再次使 EcuM 进入休眠状态（Halt 或 Poll）。
注意：当 EcuM 从异步唤醒源恢复时，EcuM 必须执行 WakeupRestart 序列来重新启动主函数，以便与所用硬件（例如 SPI）建立异步通信。
[SWS_EcuM_04150]
[SRS_BSW_00452]
- 如果在信号唤醒发生后没有唤醒事件被设置，且相应的 CheckWakeupTimer 超时，则 EcuM 应报告运行时错误 ECUM_E_WAKEUP_TIMEOUT。
UP 阶段
在 UP 阶段， EcuM_MainFunction 会定期执行，它有三个主要功能：
- 检查唤醒源是否已唤醒，并启动唤醒验证，如果必要的话（参见 7.6.4 WakeupValidation 序列中的活动）
- 更新闹钟定时器
- 仲裁 RUN 和 POST_RUN 的请求和释放。
闹钟处理
有关实现细节，请参阅第 7.8.2 节 UP 阶段的 EcuM 时钟时间。
[SWS_EcuM_04002]
[ ]
- 当闹钟时钟服务存在时（参见 EcuMAlarmClockPresent ） EcuM_MainFunction 将更新闹钟时钟定时器。
唤醒源状态处理
唤醒源不仅在唤醒期间被处理，而且与所有其他 EcuM 活动并行且一直存在。此功能在 EcuM_MainFunction 中运行，并通过模式请求与 ECU 管理的其余部分完全分离。
唤醒源可以处于以下状态：
[SWS_EcuM_04091]
[SRS_ModeMgm_09136]
图 7.15 说明了唤醒源状态与引起状态变化的条件函数之间的关系。此处仅显示两个超级状态“Disabled”和“Validation”，以方便说明和理解。
[SWS_EcuM_04003]
[ ]
- 当 ECU 管理器操作导致唤醒源状态发生变化时，ECU 管理器模块应向 BswM 发出模式请求，以将唤醒源的模式更改为新的唤醒源状态。
为了传达这些唤醒源状态，使用类型 EcuM_WakeupStatusType （参见 [SWS_EcuM_04041]）。
当 ECU 管理器模块处于 UP 阶段时，唤醒事件通常不会触发状态变化。但它们会触发 Halt 和 Poll 的子阶段的结束。然后，ECU 管理器模块会自动执行 WakeupRestart 序列并返回到 UP 阶段。集成器需要在 BswM 中配置规则，以便 ECU 对唤醒事件做出正确反应，因为反应完全取决于当前 ECU（而非 ECU 管理）的状态。
如果唤醒源有效，BswM 将使 ECU 返回其 RUN 状态。如果所有唤醒事件都已恢复为 NONE 或 EXPIRED，BswM 将再次准备 BSW 以进入 SLEEP 或 OFF 状态，并调用 EcuM_GoDownHaltPoll。
总结：每个待处理事件都经过独立验证（如果已配置），并且 EcuM 将结果作为模式请求发布给 BswM，进而可以触发 EcuM 中的状态变化。
唤醒状态的内部表示
EcuM 管理器模块提供以下接口来确定这些唤醒源的状态：
- 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 位掩码，其中各个唤醒源对应于固定的 bit 位置。
有 5 个预定义的 bit 位置，其余的可以通过配置分配。有关详细信息，请参阅第 8.2.3 节 EcuM_WakeupSourceType。
一方面，ECU 管理器模块管理每个唤醒源的模式。另一方面，ECU 管理器模块假定存在“内部变量”（即 EcuM_WakeupSourceType 实例），用于跟踪哪些唤醒源处于特定状态（尤其是 NONE（即清除）、PENDING、VALIDATED 和 EXPIRED）。
ECU 管理器模块在各自的接口定义中使用这些“内部变量”来定义接口的语义。因此，这些“内部变量”是否确实被实现是次要的。它们只是用来解释接口的语义。
WakeupValidation 序列中的活动
由于唤醒事件可能是无意中生成的（例如 CAN 线上的 EVM 尖峰），因此有必要在 ECU 恢复完全运行之前验证唤醒。
所有唤醒源的验证机制是相同的。
当唤醒事件发生时，ECU 从其休眠状态中被唤醒，并在 MCU 驱动程序的 MCU_SetMode 服务中（实际上，要执行的第一个代码可能是 ISR，例如唤醒 ISR。但是，这取决于硬件和/或驱动程序的实现）恢复执行状态。
当 WakeupRestart 序列完成后，ECU 管理器模块将有一个要验证的待处理唤醒事件列表（参见 [SWS_EcuM_02539] ）。
然后，ECU 管理器模块释放 BSW 调度程序和所有 BSW 主函数。最值得注意的是，在这种情况下，EcuM 主函数可以恢复处理。
实施提示：由于 SchM 将在 StartPostOS 和 WakeupRestart 序列结束时运行，因此 EcuM_MainFunction 可能会启动对堆栈尚未被初始化的源的验证。
集成器应配置适当的模式以指示堆栈不可用，并相应地禁用 EcuM_MainFunction （参见 AUTOSAR_SWS_RTE.pdf ）。
[SWS_EcuM_02566]
[ ]
- ECU 管理器模块应仅在配置需要的唤醒源上调用唤醒验证。如果验证协议未被配置（参见 EcuMValidationTimeout ），则对 EcuM_SetWakeupEvent 的调用也意味着对 EcuM_ValidateWakeupEvent 的调用。
[SWS_EcuM_02565]
[ ]
- ECU 管理器模块应为每个需要验证的待处理唤醒事件启动验证超时。超时应特定于事件（请参阅 EcuMValidationTimeout ）。
[SWS_EcuM_02565] 的实施提示：实施只需提供一个计时器就足够了，当报告新的唤醒事件时，该计时器会延长至最大超时时间。
[SWS_EcuM_04081]
[ ]
- 当待处理唤醒事件的验证超时到期时， EcuM_MainFunction 将设置（或运算）内部过期唤醒事件变量中的 bit。
另请参阅第 7.6.3 节唤醒状态的内部表示。
[SWS_EcuM_04082]
[ ]
- 当待处理唤醒事件的验证超时到期时，EcuM_MainFunction 应使用 EcuM_WakeupSourceType 位掩码参数调用 BswM_EcuM_Current_Wakeup，其中与唤醒事件对应的位将被设置，且状态值参数被设置为 ECUM_WKSTATUS_EXPIRED。
BswM 将被配置为在
- 唤醒源得到验证时
或
- 计时器到期时
通过来自 EcuM 的模式切换请求来监控唤醒验证。
如果最后一次验证超时（参见 [SWS_EcuM_02565] ）且验证未通过，则 BswM 应认为唤醒验证失败。如果至少一个待处理事件验证通过，则整个验证通过。
通过调用 EcuM_ValidateWakeupEvent （参见 [SWS_EcuM_02829] ）来验证待处理事件。此调用必须放置在驱动程序中或驱动程序顶部的消费堆栈中（例如处理程序）。放置它的最佳位置取决于硬件和软件设计。另请参阅第 7.6.4.4 节“具有唤醒源的驱动程序的要求”。
通信通道的唤醒
如果通信通道上发生唤醒，则相应的总线收发器驱动程序必须通过调用 EcuM_SetWakeupEvent （参见 [SWS_EcuM_02826] ）函数通知 ECU 管理器模块。此通知的要求在第 5.2 节“具有唤醒功能的外设”中描述。
[SWS_EcuM_02479]
[ ]
- ECU 管理器模块应根据本章后面的唤醒源和 ECU 管理器的交互，在 EcuM_SetWakeupEvent （参见 [SWS_EcuM_02826] ）函数被调用时执行唤醒验证协议。
另请参阅 7.6.4.2 唤醒源和 ECU 管理器的交互。
唤醒源和 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 唤醒源。
唤醒验证超时
[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 管理器模块应延长该唤醒源的验证超时时间。
唤醒超时由配置定义（参见 EcuMValidationTimeout）。
具有唤醒源的驱动程序的要求
当检测到唤醒事件时，驱动程序必须调用一次 EcuM_SetWakeupEvent （参见[SWS_EcuM_02826] ），并提供一个 EcuM_WakeupSourceType 参数来标识唤醒源（参见[SWS_EcuM_02165]、 [SWS_EcuM_02166] ），如配置中所指定（参见EcuMWakeupSourceId ）。
[SWS_EcuM_02572]
[ ]
- ECU 管理器模块应检测在驱动程序被初始化之前发生的唤醒，无论是从 Halt/Poll 还是从 OFF。
驱动程序必须提供 API 来配置休眠状态的唤醒源、启用或禁用唤醒源以及使相关外设进入休眠状态。此要求仅在硬件提供这些能力时适用。
驱动程序应该在其初始化函数中启用回调调用。
[SWS_EcuM_04147]
[SRS_ModeMgm_09254]
- EcuMWakeupSource 分区分配应从引用它的模块配置中识别。
注意：唤醒源的唤醒验证调用和唤醒调用（启动/使能/禁用）应在分配了该唤醒源的核心上执行。（或者换句话说，在某个核心的执行上下文中，仅应处理分配给该核心分区的那些唤醒源）
唤醒验证要求
如果唤醒源需要验证，则可由基础软件中的任何一个适当模块（但只能由一个模块）来完成。该模块可能是驱动程序、接口、处理程序或管理器。
通过调用 EcuM_ValidateWakeupEvent （参见 [SWS_EcuM_02829] ）函数完成验证。
[SWS_EcuM_02601]
[ ]
- 如果 EcuM 无法确定 Mcu 驱动程序返回的重置原因，则 EcuM 将为默认唤醒源 ECUM_WKSOURCE_RESET 设置唤醒事件。
唤醒源和复位原因
ECU 管理器模块 API 仅提供了一种类型（ EcuM_WakeupSourceType ，参见 8.2.3
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
具有集成电源控制的唤醒源
SLEEP 可以通过控制 MCU 电源的系统芯片来实现。典型的例子是带有集成电源的 CAN 收发器，它根据应用程序请求关闭电源，并根据 CAN 活动打开电源。
结果是，在此类硬件上，对于 ECU 管理器模块来说 SLEEP 看起来就像 OFF 一样。这种区别相当哲学，并不具有实际意义。
实际影响是，CAN 上的被动唤醒对 ECU 来说就像是电源复位一样。因此，ECU 将在唤醒事件后继续执行 STARTUP 阶段。尽管如此，唤醒验证仍然是必需的，并且系统设计人员必须考虑以下问题：
- CAN 收发器在其中一个驱动程序初始化块中完成初始化（默认情况下在 BswM 控制下）。这是配置的或生成的代码，即在系统设计人员控制下的代码。
- 系统设计人员有责任在通过调用 EcuM_StartCheckWakeup（参见 [SWS_EcuM_04096]）检查潜在唤醒源之前防止 ECU 关闭，并检查 CAN 收发器是否存在唤醒原因，并使用 EcuM_SetWakeupEvent（参见 [SWS_EcuM_02826]）和 EcuM_ClearWakeupEvents（参见 [SWS_EcuM_02828]）函数将此信息传递给 ECU 管理器模块。
这些原则可应用于所有具有集成电源控制的唤醒源。CAN 收发器仅作为示例。
Shutdown 目标
“Shutdown 目标”是所有未执行任何代码的 ECU 状态的描述术语。它们之所以被称为 Shutdown 目标，是因为它们是状态机在离开 UP 阶段时将转变为的目标状态。以下状态是 Shutdown 目标：
- OFF
- OFF 状态要求 ECU 具有自行关闭的能力。并非所有硬件设计都具备此功能。
- SLEEP
- RESET
请注意，Shutdown 目标的“确切”或“可以被确定”的时间并不是 Shutdown 的开始时间。
由于 BswM 现在控制大多数 ECU 资源，它将确定应设置 Shutdown 目标的时间，并将直接或间接地设置它。
因此，BswM 必须确保，例如，在调用 EcuM_GoDownHaltPoll 之前，必须将 Shutdown 目标从其默认值更改为 ECUM_STATE_SLEEP。
在 ECU 管理器模块的先前版本中，休眠目标被特殊处理，因为 ECU 中实现的休眠模式取决于 ECU 的功能。
这些休眠模式取决于硬件，并且通常在时钟设置或硬件提供的其他低功耗功能方面有所不同。
这些不同的功能可通过 MCU 驱动程序访问，称为所谓的 MCU 模式（参见 AUTOSAR_SWS_MCUDriver.pdf ）。还有各种执行复位的方式，这些方式由不同的模块控制或触发：
- Mcu_PerformReset
- WdgM_PerformReset
- 通过 DIO/SPI 切换 I/O 引脚
ECU 管理器模块提供了一种设施来管理这些复位方式，方法是跟踪先前复位的时间和原因。
各种复位方式将被视为复位模式，使用与休眠相同的模式设施。
有关 Shutdown 管理设施的接口定义，请参阅第 8.3.4 节 Shutdown 管理。
SLEEP
[SWS_EcuM_02188]
[ ]
- 在 SLEEP 阶段不得错过任何唤醒事件。如果在 GoSleep 序列中发生了唤醒事件，则不得进入 Halt 或 Poll 序列。
[SWS_EcuM_02957]
[ ]
- ECU 管理器模块可以定义一组可配置的休眠模式（参见 EcuMSleepMode），其中每种模式本身都是一个 Shutdown 目标。
[SWS_EcuM_02958]
[ ]
- ECU 管理器模块应允许将 MCU 休眠模式映射到 ECU 休眠模式，从而允许将它们作为 Shutdown 目标进行处理。
[SWS_EcuM_04092]
[ ]
- Shutdown 目标休眠将使所有核心进入休眠状态。
Reset
[SWS_EcuM_04005]
[ ]
- ECU 管理器模块应定义一组可配置的复位模式（参见 EcuMResetMode 和 EcuM_ResetType ），其中每种模式本身都是一个 Shutdown 目标。该集合至少包含以下目标：
- Mcu_PerformReset
- WdgM_PerformReset
- 通过 DIO/SPI 切换 I/O 引脚
[SWS_EcuM_04006]
[ ]
- ECU 管理器模块应允许定义复位目标的别名（参见 EcuM180_Conf）。
[SWS_EcuM_04007]
[ ]
- ECU 管理器模块应定义一组可配置的复位原因（参见 EcuMShutdownCause 和 EcuM_ShutdownCauseType ）。该集合应至少包含以下目标：
- ECU 状态机进入 Shutdown 状态
- WdgM 检测到故障
- DCM 请求 Shutdown
[SWS_EcuM_04008]
[ ]
- ECU 管理器模块应为 BSW 模块和软件组件提供便利，以便
- 记录 Shutdown 原因
- 获取最近 Shutdown 原因的集合
另请参阅第 8.3.4 节 Shutdown 管理。
闹钟
ECU 管理器模块提供可选的持久时钟服务，即使在休眠期间也能保持“活动”状态。
- 它保证 ECU 将在未来的某个时间被唤醒（假设硬件没有故障）。
- 并为长期活动（即以小时到几天甚至几年为单位）提供时钟服务。
一般来说，该服务将通过 ECU 中可引发唤醒的计时器来实现。
- 在某些情况下，外部设备也可以使用常规中断线定期唤醒 ECU。
- 无论使用哪种机制，服务都会私下使用一个唤醒源。
- ECU 管理器模块维护一个主闹钟，其值决定 ECU 被唤醒的时间。
- ECU 管理器还管理一个内部时钟，即 EcuM 时钟，用于与主闹钟进行比较。
请注意，闹钟唤醒机制仅与 SLEEP 阶段相关。
软件组件和 BSW 模块可以在 UP 阶段（并且只能在 UP 阶段）设置和检索闹钟值。
- 并在 SLEEP 阶段使用这些值。
与可使用通用 ECU 管理器模块设施实现的其他计时/唤醒机制相比，闹钟服务在计时器到期之前不会启动 WakeupRestart 序列。
当 ECU 模块检测到其计时器已引发唤醒事件时，它会递增其计时器并立即返回休眠状态，除非计时时间已超过闹钟时间。
[SWS_EcuM_04069]
[ ]
- 当闹钟服务存在时（参见 EcuMAlarmClockPresent ），ECU 管理器模块应维护一个 EcuM 时钟，其时间应为自电池连接以来的秒数。
[SWS_EcuM_04086]
[ ]
- EcuM 时钟应跟踪 UP 和 SLEEP 阶段的时间。
[SWS_EcuM_04087]
[ ]
- 如果硬件允许，EcuM 时钟时间不得通过 ECU 重置的方式来重置。
[SWS_EcuM_04088]
[ ]
- 应有且仅有一个唤醒源被分配给一个 EcuM 时钟（参见 EcuMAlarmWakeupSource ）。
闹钟和用户
软件组件和 BSW 模块可以各自管理一个闹钟（用户闹钟 EcuMAlarmClock）。
- 每个用户闹钟（参见 EcuMAlarmClock）都与一个 EcuMAlarmClockUser 相关联。
- 后者（EcuMAlarmClockUser）标识相应的软件组件或 BSW 模块。
[SWS_EcuM_04070]
[ ]
- 每个 EcuM 用户（EcuMAlarmClockUser）最多可以拥有一个用户闹钟（EcuMAlarmClock）。
[SWS_EcuM_04071]
[ ]
- EcuM 用户（EcuMAlarmClockUser）不得设置其他用户（EcuMAlarmClockUser）的闹钟的值。
[SWS_EcuM_04072]
[ ]
- EcuM 模块应始终将主闹钟值设置为最早开始计时的用户闹钟的值。
这也意味着，当 EcuM 用户（EcuMAlarmClockUser）在其闹钟上发出中止信号，并且该用户闹钟确定当前主闹钟的值时，EcuM 模块应将主闹钟值设置为下一个最早开始计时的用户闹钟值。
[SWS_EcuM_04073]
[ ]
- 只有获得授权的 EcuM 用户（EcuMAlarmClockUser）才能设置 EcuM 时钟的时间（参见 EcuMSetClockAllowedUsers ）。
[SWS_EcuM_04073] 的理由：
- 通常，EcuM 用户（EcuMAlarmClockUser）不能设置 EcuM 时钟的时间。
- EcuM 时钟时间可以被设置为任意时间，以允许测试需要几天才能到期的超时。
EcuM 时钟时间
[SWS_EcuM_04089]
[ ]
- 如果底层硬件机制是基于滴答的，则 EcuM 应相应地“纠正（换算）”时间。
UP 阶段的 EcuM 时钟时间
EcuM_MainFunction 在 UP 阶段对 EcuM 时钟进行计数。
- 它使用标准 OS 机制（闹钟/计数器）来派生出其时间。
- 请注意计数器和 EcuM 时间之间的刻度差异，后者以秒为单位( [SWS_EcuM_04069] )。
SLEEP 阶段的 EcuM 时钟时间
根据选择的休眠模式（EcuMSleepModeSuspend 参数），有两种方法可以在休眠期间对 EcuM 时钟进行计数。
在 Halt 序列中（参见 7.5.2 Halt 序列中的活动）：
- 必须将 GPT 驱动程序置于 GPT_MODE_SLEEP 中，以便仅对时基所需的定时器通道进行配置。
- 它还要求 GPT 使用 Gpt_EnableWakeup API 来启用基于定时器的唤醒通道。
- 最好在 Gpt_StartTimer API 中将计数间隔设置为 1 秒。
- 但如果无法设置为 1 秒，则需要更频繁地唤醒 EcuM ，直到累积到 1 秒的时间间隔并增加时钟的值。
- 通过使用 EcuM_SetClock 函数，EcuM 时钟可以在 EcuM_SleepActivity 函数期间被定期更新，假设时间概念仍然可用。
- 只有当时间累计到 1 秒时，时钟计数值才可以被增加。
在这两种情况中，当时钟计数值在休眠期间被增加后，ECU 管理器模块必须评估主闹钟是否已过期。如果已过期，BswM 将启动全面启动或再次将 ECU 设置为休眠状态。
[SWS_EcuM_04009]
[SRS_ModeMgm_09187]
- 离开休眠状态时，ECU 管理器模块将中止任何活动的用户闹钟和主闹钟。这意味着由于其他事件引起的这两种闹钟被诱导并唤醒将导致所有闹钟被清除
[SWS_EcuM_04010]
[SRS_ModeMgm_09188]
- 在 StartPreOS 序列、WakeupRestart 序列和 OffPreOS 序列中，应取消用户闹钟和主闹钟。
多核心
本小节介绍了 BSW 模块在不同分区上的分布。
- 分区可以看作是映射到核心上的一个独立的部分。
- 因此，每个核心（无论是单核还是多核架构）都至少包含一个或任意数量的分区。
- 但是，任何分区的范围都不应超越一个核心。
BSW 模块可以分布在不同的分区上，即分布在不同的核心上。一些 BSW 模块（如 BswM）必须分布在每个分区中。
其他模块（如 OS 或 EcuM）已被包含在每个核心的某个分区中。
图 7.17 显示了一个示例。
图 7.17：ECU 内部的分区
在多核架构中，EcuM 必须以某种方式分布，即每个核心存在一个实例。
- 有一个指定的主核心，其中引导加载程序通过 EcuM_Init 启动主 EcuM。
- 主 EcuM 启动一些驱动程序，确定 Post Build 配置，并启动所有剩余的核心及所有核心附属的 EcuM。
每个 EcuM 现在启动核心本地 OS 和核心本地 BswM（每个分区中恰好有一个 BswM）。
- 如果在 ECU 的每个核心上执行相同的 EcuM 镜像，则 EcuM 的行为必须在不同的核心上有所不同。
- EcuM 可以首先通过测试它是在主核心还是从核心上，并采取适当的行动来实现这一点。
ECU 管理器模块支持在多核 ECU 上实现与其在传统 ECU 上实现的相同的阶段（即 STARTUP、UP、SHUTDOWN 和 SLEEP）。
如果安全机制被使用，ECU 管理器必须以完全信任的级别运行。
本节使用以前的 ECU 管理器术语来表示各种 ECU 状态，特别是 Run/PostRun。通过灵活的 ECU 管理，系统集成商可以决定 ECU 状态的名称和语义。但是，必须支持逆初始化阶段的方法。因此，此处使用的名称不是规范性的。
主核心
有一个显式的主核心。哪个核心是主核心由引导加载程序决定。
- 主核心的 EcuM 作为第一个 BSW 模块被启动并执行初始化操作。
- 然后启动所有其他的核心和所有其他的 EcuM。
- 当这些被启动时，它会与每个卫星 EcuM 一起初始化核心本地 OS 和 BswM。
从核心
每个从核心上都必须运行一个卫星 EcuM。
- 如果核心包含多个分区，则每个核心只能有一个 EcuM。
主核心 - 从核心信号通信
本节讨论关于哪些 BSW 可以进行核心间通信的一般机制。
它假定您对 RTE 中描述和指定的 SchM 有一定的了解。
BSW 级别
- OS 提供了在主核心和从核心上同步启动 OS 的基本机制。
- SchM 提供了跨分区边界的 BSW 模块通信的基本机制。
- 每个核心一个的 BswM 负责启动和停止 RTE。
请参阅模式管理指南（AUTOSAR_EXP_ModeManagementGuide.pdf），以获得更完整的解决方案描述，以及关于在它们之间进行选择时需要考虑的因素的讨论。
同步 SHUTDOWN 的示例
在调用 ShutdownAllCores 之前，主 EcuM 模块必须启动所有从 EcuM 模块的 Shutdown，并且必须等待直到所有 EcuM 模块都已完成取消初始化其负责的 BSW 模块并成功 Shutdown。
因此，主 EcuM 模块设置一个 Shutdown 标志，所有从 EcuM 模块都可以读取该标志。EcuM 随后为每个配置的从核心激活任务。从 EcuM 模块读取主例程内的 Shutdown 标志并 Shutdown（如果有必要）。
该任务名称为“EcuM_SlaveCore<X>_Task”，其中 X 为数字。任务需要由集成商配置。需要被激活的任务数可以通过统计 EcuMPartitionRef 实例数并减一来计算，因为主 EcuM 会占用一个 EcuMFlexPartitioRef。
示例：
- 配置了三个 EcuMPartitionRef 实例。然后在调用 EcuM_GoDownHaltPoll() 期间“EcuM_SlaveCore1_Task”和“EcuM_SlaveCore2_Task”将被启动。从 EcuM 模块读取主例程中的 Shutdown 标志并 Shutdown（如果有必要）。
OS 将 OSEK SetEvent 函数扩展到各个核心。一个核心上的任务可以等待另一个核心上设置的事件。
图 18 说明了这如何应用于在调用 ShutdownAllCores 之前同步核心的问题（其中省略了反初始化细节）。
Set/WaitEvent 函数接受一个 bit 掩码，该掩码可用于指示各个从核心上的 Shutdown 就绪状态。来自从 EcuM 模块的每个 SetEvent 调用都将解除主 EcuM 模块的等待。
因此，主 ECU 管理器模块必须跟踪各个从核心的状态，并设置等待时间，直到所有核心都已注册其准备就绪状态。
如果调用者已经占用资源或自旋锁，则可以用 GetEvent() 循环来替换 WaitEvent() 函数。
注意：
图 7.18 是主核心上的逻辑控制流的一个示例。需要在每个由 EcuM 管理的核心中都提供 API EcuM_GoDownHaltPoll。该函数在从核心上的行为是特定于实现的。
集成注意事项：
如果通过 SetEvent/WaitEvent 实现主核心和从核心之间的同步，则 EcuM_GoDownHaltPoll 将由 BswM 在其主要功能函数任务（模式仲裁的延迟处理）的上下文中被调用。这将产生额外需求：主要功能函数任务需要是一个扩展任务。
UP 阶段
从硬件角度来看，唤醒中断可能发生在所有核心上。然后整个 ECU 被唤醒，并且在该 ECU 上运行的 EcuM 将处理唤醒事件。
[SWS_EcuM_04011]
[ ]
- EcuM_MainFunction 应在所有 EcuM 实例中运行。
[SWS_EcuM_04012]
[ ]
- EcuM 模块的每个实例都应处理其核心上的唤醒事件。
与单核心情况一样，BswM（由集成商配置）负责控制 ECU 资源，确保本地核心可以被断电或挂起，以及在将控制权移交给其核心上的 EcuM 之前取消初始化相应的应用程序和 BSW。
STARTUP 阶段
EcuM 模块在所有核心上的功能几乎相同。也就是说，对于单核心情况，EcuM 模块执行 STARTUP 指定的步骤：最重要的是启动 OS，初始化 SchM 并启动核心本地 BswM。
主 EcuM 在调用初始化块 1 并执行重置/唤醒管理后激活所有从核心。被激活后，从核心将执行其 STARTUP 例程，该例程在其核心上调用 EcuM_Init。
[SWS_EcuM_04146]
[ ]
- 如果缺少 EcuMEcucCoreDefinitionRef，则初始化调用只能在主核心上执行。
注意：
如果您需要在多个核心上初始化模块，则必须将每个核心的模块添加到特定的初始化列表中。请注意，在这种情况下，init() 函数可能会在不同的核心中被并行调用，并且 init() 函数通常被定义为不可重入。
在每个 EcuM 在其核心上调用 StartOS 之后，OS 会在执行每个核心的单独的 STARTUP 挂钩（ StartupHook() ）之前同步核心，并在每个核心执行第一个任务之前再次同步核心。
StartPostOS 在每个核心上被执行，并且 SchM 在每个核心上被初始化 。所有核心本地 BswM 都由每个核心本地的 EcuM 初始化。
每个分区上的 BswM 必须为其核心启动 RTE。
[SWS_EcuM_04093]
[ ]
- EcuM 模块应在每个核心上启动 SchM 和 OS。
[SWS_EcuM_04014]
[ ]
- EcuM 模块应为 “在主核心和所有从核心上的” 所有 “核心本地 BswM” 调用 BswM_Init。
主核心 STARTUP
[SWS_EcuM_04015]
[ ]
[SWS_EcuM_04016]
[ ]
从核心 STARTUP
[SWS_EcuM_04145]
[ ]
- 每个核心上的 EcuM_Init 函数都应调用 EcuM_AL_DriverInitZero 和 EcuM_AL_DriverInitOne 函数。这些回调函数的实现应确保只有那些在当前活动核心上运行的 MCAL 模块才会被初始化。
[SWS_EcuM_04017]
[ ]
[SWS_EcuM_04018]
[ ]
SHUTDOWN 阶段
目前不支持单独 Shutdown 某个核心（即 ECU 的其余部分继续运行）。所有核心必须被同时 Shutdown。
当 ECU 需要被 Shutdown 时，主 EcuM 模块会调用 ShutdownAllCores，而不是以某种方式调用各个核心上的 ShutdownOS。ShutdownAllCores 会停止所有核心上的 OS，也会停止所有核心。
由于主核心可以在所有从核心完成处理之前发出 ShutdownAllCores，因此全部核心在进入 SHUTDOWN 之前必须被同步。
BswM（分布在所有分区上）确定 ECU 是否应被 Shutdown 并是否应与 ECU 中的每个 BswM 进行同步。所有 BswM 都会引发所有分区的 BSW、软件组件和 CDD 的逆初始化，并向其他 BswM 发送适当的信号以表明它们已准备好被 Shutdown。
对于 ECU 的 Shutdown，BswM（与主 EcuM 位于同一分区）最终会调用主核心上的 GoOff，并且主核心会将该请求传递给所有从核心。
- 主核心上的 EcuM 会逆初始化其 SchM 和 BswM。
- 从核心上的 EcuM 会逆初始化其 SchM 和 BswM。
- 并检查在 Shutdown 期间是否未发生唤醒事件（请参阅 [SWS_EcuM_04151] 和 [SWS_EcuM_04152]） 。
- 然后发送信号以表明核心已准备好进行 ShutdownOS（请参阅第 7.9.3 节“主核心 ‑ 从核心信号”了解详情）。
- 主核心上的 EcuM 等待来自每个从核心上的 EcuM 的信号。
- 然后在主核心上照常启动 Shutdown（主 EcuM 调用 ShutdownAllCores，并使用全局 Shutdown Hook 将 ECU 置于休眠状态）。
主核心 SHUTDOWN
[SWS_EcuM_04020]
[ ]
从核心 SHUTDOWN
[SWS_EcuM_04022]
[ ]
SLEEP 阶段
当请求 Shutdown 目标 SLEEP 时，所有核心都会同时进入休眠状态。
- MCU 必须对每个核心发出 Halt 指令。
- 由于任务的计时和优先级对于 OS 中的核心来说是属于本地的。
- 因此在 Halt 后，调度程序和 RTE 都不必被同步。
- 由于主核心可以在所有从核心完成处理前发出 MCU Halt 指令。
- 因此全部核心在进入 GoHalt 之前必须被同步。
BswM 确定应启动休眠后，会为每个核心分配适当的 ECU 模式。
- 从核心上的 BSW、软件组件和 CDD 必须由其分区中的本地 BswM 通知。
- 他们将被适当地逆初始化并向 BswM 发送适当的模式请求以表明其已准备就绪。
如果 ECU 被置于休眠状态。
- 则必须同步“Halt”，以便在主核心计算校验和之前 Halt 所有从核心。
- 主核心上的 EcuM 模块使用与在 GoOff 上同步核心时使用的相同的“信号”机制。
类似地，主核心上的 EcuM 模块必须在将从核心从 “Halt” 状态里释放之前验证校验和。
主核心 SLEEP
[SWS_EcuM_04023]
[ ]
[SWS_EcuM_04024]
[SRS_ModeMgm_09239]
[SWS_EcuM_04025]
[ ]
[SWS_EcuM_04026]
[ ]
从核心 SLEEP
[SWS_EcuM_04027]
[ ]
[SWS_EcuM_04028]
[ ]
[SWS_EcuM_04029]
[ ]
[SWS_EcuM_04030]
[ ]
可运行函数和入口点
内部行为
[SWS_EcuM_03018]
[ ]
- ECU 管理器模块的内部行为定义如下。此详细描述仅针对本地 RTE 的配置。
- InternalBehavior EcuStateManager {
// Runnable entities of the EcuStateManager
RunnableEntity SelectShutdownTarget
symbol "EcuM_SelectShutdownTarget"
canbeInvokedConcurrently = TRUE
RunnableEntity GetShutdownTarget
symbol "EcuM_GetShutdownTarget"
canbeInvokedConcurrently = TRUE
RunnableEntity GetLastShutdownTarget
symbol "EcuM_GetLastShutdownTarget"
canbeInvokedConcurrently = TRUE
RunnableEntity SelectShutdownCause
symbol "EcuM_SelectShutdownCause"
canbeInvokedConcurrently = TRUE
RunnableEntity GetShutdownCause
symbol "EcuM_GetShutdownCause"
canbeInvokedConcurrently = TRUE
RunnableEntity SelectBootTarget
symbol "EcuM_SelectBootTarget"
canbeInvokedConcurrently = TRUE
RunnableEntity GetBootTarget
symbol "EcuM_GetBootTarget"
canbeInvokedConcurrently = TRUE
RunnableEntity SetRelWakeupAlarm
symbol "EcuM_SetRelWakeupAlarm"
canbeInvokedConcurrently = TRUE
RunnableEntity SetAbsWakeupAlarm
symbol "EcuM_SetAbsWakeupAlarm"
canbeInvokedConcurrently = TRUE
RunnableEntity AbortWakeupAlarm
symbol "EcuM_AbortWakeupAlarm"
canbeInvokedConcurrently = TRUE
RunnableEntity GetCurrentTime
symbol "EcuM_GetCurrentTime"
canbeInvokedConcurrently = TRUE
RunnableEntity GetWakeupTime
symbol "EcuM_GetWakeupTime"
canbeInvokedConcurrently = TRUE
RunnableEntity SetClock
symbol "EcuM_SetClock"
canbeInvokedConcurrently = TRUE
RunnableEntity RequestRUN
symbol "EcuM_RequestRUN"
canbeInvokedConcurrently = TRUE
RunnableEntity ReleaseRUN
symbol "EcuM_ReleaseRUN"
canbeInvokedConcurrently = TRUE
RunnableEntity RequestPOSTRUN
symbol "EcuM_RequestPOST_RUN"
canbeInvokedConcurrently = TRUE
RunnableEntity ReleasePOSTRUN
symbol "EcuM_ReleasePOST_RUN"
canbeInvokedConcurrently = TRUE
// Port present for each user. There are NU users
SR000.RequestRUN -> RequestRUN
SR000.ReleaseRUN -> ReleaseRUN
SR000.RequestPOSTRUN -> RequestPOSTRUN
SR000.ReleasePOSTRUN -> RequestPOSTRUN
PortArgument {port=SR000, value.type=EcuM_UserType,
value.value=EcuMUser[0].User }
(...)
SRnnn.RequestRUN -> RequestRUN
SRnnn.ReleaseRUN -> ReleaseRUN
SRnnn.RequestPOSTRUN -> RequestPOSTRUN
SRnnn.ReleasePOSTRUN -> RequestPOSTRUN
PortArgument {port=SRnnn, value.type=EcuM_UserType,
value.value=EcuMUser[nnn].User }
shutDownTarget.SelectShutdownTarget -> SelectShutdownTarget
shutDownTarget.GetShutdownTarget -> GetShutdownTarget
shutDownTarget.GetLastShutdownTarget -> GetLastShutdownTarget
shutDownTarget.SelectShutdownCause -> SelectShutdownCause
shutDownTarget.GetShutdownCause -> GetShutdownCause
bootTarget.SelectBootTarget -> SelectBootTarget
bootTarget.GetBootTarget -> GetBootTarget
alarmClock.SetRelWakeupAlarm-> SetRelWakeupAlarm
alarmClock.SetAbsWakeupAlarm -> SetAbsWakeupAlarm
alarmClock.AbortWakeupAlarm -> AbortWakeupAlarm
alarmClock.GetCurrentTime -> GetCurrentTime
alarmClock.GetWakeupTime -> GetWakeupTime
alarmClock.SetClock -> SetClock
};
EcuM 模式处理
EcuM 为软件组件提供接口，以便选择性地请求和释放 RUN 和 POST_RUN 模式。
EcuMFlex 仲裁软件组件发出的模式请求和模式释放，并将结果传播给 BswM。
- EcuM 和 BswM 之间的合作是必要的，因为只有 BswM 才能决定转换何时发生。
- 由于 EcuM 没有自己的状态机，EcuM 依赖于 BswM 发起的状态转换。
- 因此，EcuM 不会自己请求状态转换。
- 此外，EcuM 会通知 BswM 关于当前所有请求的仲裁情况。
- 当 RTE 执行了属于某种模式的所有可运行实体时，BswM 会收到通知。
ECU 模式处理的架构组件
图 7.35 说明了 ECU 模式处理的架构组件。
[SWS_EcuM_04115]
[SRS_ModeMgm_09116]
- 当 EcuMModeHandling 被配置为 True 时，应应用 ECU 模式处理。
[SWS_EcuM_04116]
[SRS_ModeMgm_09116]
- 当 BswM 通过 EcuM_SetState 设置 EcuM 的状态时，EcuM 应向 RTE 指示相应的模式。
[SWS_EcuM_04117]
[SRS_ModeMgm_09116]
- 当最后一个 RUN 请求被释放后，EcuM 模块应使用
- BswM_EcuM_RequestedState(
- ECUM_STATE_RUN,
- ECUM_RUNSTATUS_RELEASED
- )
- 向 BswM 指示此情况。
如果软件组件在 POST_RUN 期间需要执行 POST RUN 行为（例如 Shutdown 准备），那么它必须在释放 RUN 请求之前请求 POST_RUN。否则不能保证这个软件组件有机会运行它的 POST_RUN 代码。
[SWS_EcuM_04118]
[SRS_ModeMgm_09116]
- 当 EcuM 不处于软件组件所请求的状态时，它应使用 API BswM_EcuM_RequestedState 向 BswM 通知有关请求的状态。
POST_RUN 状态为软件组件提供 POST RUN 阶段并允许它们保存重要数据或关闭外设。
[SWS_EcuM_04144]
[ ]
- 当收到第一个 RUN 或 POST_RUN 请求后，EcuM 模块应使用
- BswM_EcuM_RequestedState(
- ECUM_STATE_RUN,
- ECUM_RUNSTATUS_REQUESTED
- )
- 向 BswM 指示此情况。
[SWS_EcuM_04119]
[SRS_ModeMgm_09116]
- 当最后一个 POST_RUN 请求被释放时，EcuM 模块应使用
- BswM_EcuM_RequestedState(
- ECUM_STATE_POST_RUN,
- ECUM_RUNSTATUS_RELEASED
- )
- 向 BswM 指示这一点。
提示：
为了防止 ECU 模式的模式状态机实例落后于实际模式以及 EcuM 和 RTE 状态不同步，EcuM 可以使用确认回复作为模式切换的通知。
请注意，EcuM （自身）仅请求 RUN 和 POST_RUN 模式，SLEEP 模式必须由 BswM 设置，因为 EcuM 没有关于何时可以进入此模式的任何信息。
[SWS_EcuM_04143]
[ ]
- EcuM 应通过调用接口 BswM_EcuM_CurrentState(EcuM_StateType State) 来通知 BswM 当前的状态。当 RTE 通过确认端口给出其反馈时，EcuM 应设置新的状态。
高级主题
与引导加载程序（Bootloader）的关系
引导加载程序不是 AUTOSAR 的一部分。但是，应用程序需要一个接口来激活引导加载程序。为此，提供了两个函数：EcuM_SelectBootTarget 和 EcuM_GetBootTarget 。
引导加载程序，系统供应商的引导加载程序和应用程序是独立的程序镜像，在许多情况下，甚至可以被单独刷写。从一个镜像到另一个镜像的切换的实现方式只有重启。根据所选的启动目标，启动菜单将进入其中一个或另一个镜像。
与复杂驱动程序的关系
如果复杂驱动程序处理唤醒源，它必须遵循本文档中指定的协议来处理唤醒事件。
Startup 和 Shutdown 时的错误处理
[SWS_EcuM_02980]
[ ]
- EcuM 模块应忽略在初始化期间发生的所有类型的错误，例如由 init 函数返回的值。
初始化是一个配置问题（参见 EcuMDriverInitListZero、EcuMDriverInitListOne 和 EcuMDriverRestartList），因此无法被标准化。
BSW 模块负责将其初始化期间发生的错误直接报告给 Dem 模块或 Det 模块，如其 SWS 中所述。EcuM 模块不会报告错误。BSW 模块还负责采取任何特殊措施来应对其初始化期间发生的错误。
ErrorHook
[SWS_EcuM_04033]
[ ]
- 在表 7.9 第一列定义的不可恢复的错误情况下，EcuM 模块应调用 EcuM_ErrorHook，并将参数值设置为相应的相关错误代码。
对 [SWS_EcuM_04033] 的澄清：
- EcuM 应假定 EcuM_ErrorHook 不会返回（集成器的代码）。
对 [SWS_EcuM_04033] 的澄清：
- 如果需要 Dem 错误，则集成商有责任定义一个策略来处理它（例如：由于 EcuM 不直接调用 Dem，因此在重置恢复后设置 Dem 错误）。
[SWS_EcuM_04139]
[ ]
- 如果 OS 函数调用返回一个错误代码（E_OK 除外），EcuM 应调用 EcuM_ErrorHook，错误代码为 ECUM_E_OS_CALL_FAILED。
错误分类
开发错误
[SWS_EcuM_04032]
[SRS_BSW_00327]
[SRS_BSW_00337]
[SRS_BSW_00350]
[SRS_BSW_00385]
运行时错误
[SWS_EcuM_91003]
[ ]
API 规范
导入的类型
[SWS_EcuM_02810]
[ ]
[SWS_EcuM_03019]
[ ]
- ECUM_E_EARLIER_ACTIVE 和 ECUM_E_PAST 应为 Std_ReturnType 类型并表示以下值：
- ECUM_E_EARLIER_ACTIVE = 3
- ECUM_E_PAST = 4
类型定义
EcuM_ConfigType
[SWS_EcuM_04038]
[ ]
[SWS_EcuM_02801]
[ ]
- EcuM_ConfigType 类型定义的结构应包含 EcuM 模块的构建后配置参数以及指向所有由 EcuM 模块初始化的模块的 ConfigType 结构的指针。
EcuM 模块配置工具必须针对包括 ECU 配置在内的一组给定基础软件模块生成由 EcuM_ConfigType 类型定义的结构。该组基础软件模块源自相应的 EcuM 参数。
[SWS_EcuM_02794]
[ ]
- EcuM_ConfigType 类型中定义的结构应包含一个额外的构建后配置变体标识符（uint8/uint16/uint32 取决于计算标识符的算法）。
另请参阅章 7.3.4 检查配置一致性。
[SWS_EcuM_02795]
[ ]
- EcuM_ConfigType 类型定义的结构应包含一个附加哈希值，该哈希值根据配置参数EcuMConfigConsistencyHash 进行测试，以检查配置数据的一致性。
另请参阅第 7.3.4 节检查配置一致性。
对于每个给定的 ECU 配置，EcuM 模块配置工具必须生成此结构的实例，该实例填充了 EcuM 模块的构建后配置参数以及指向上述模块的配置结构体实例的指针。指针来自相应的 EcuM 参数。
EcuM_RunStatusType
[SWS_EcuM_04120]
[SRS_ModeMgm_09116]
[SWS_EcuM_04121]
[SRS_ModeMgm_09116]
- EcuM 模块应将运行请求协议的状态告知 BswM，各个状态在 EcuM_RunStatusType 中被列出。
EcuM_WakeupSourceType
[SWS_EcuM_04040]
[ ]
[SWS_EcuM_02165]
[ ]
- 附加唤醒源（对于预定义源）应通过配置单独分配给 bit 字段位置 5 至 31。bit 分配应由配置工具完成。
[SWS_EcuM_02166]
[ ]
- EcuMWakeupSource 容器中的 EcuMWakeupSourceId（参见 [ECUC_EcuM_00151]）字段应定义 EcuM_WakeupSourceType bit 字段所有实例中与该唤醒源相对应的位置。
EcuM_WakeupStatusType
[SWS_EcuM_04041]
[ ]
注意：此声明必须被更改为模式。名称必须被更改。
EcuM_ResetType
[SWS_EcuM_04044]
[ ]
EcuM_StateType
[SWS_EcuM_91005]
[SRS_BSW_00331]
[SWS_EcuM_02664]
[ ]
- EcuM 模块应定义在 EcuM_StateType 中被列出的所有状态。
函数定义
General
EcuM_GetVersionInfo
[SWS_EcuM_02813]
[SRS_BSW_00407]
[SRS_BSW_00411]
初始化和 Shutdown 序列
EcuM_GoDownHaltPoll
[SWS_EcuM_91002]
[ ]
EcuM_Init
[SWS_EcuM_02811]
[SRS_BSW_00358]
[SRS_BSW_00414]
[SRS_BSW_00101]
EcuM_StartupTwo
[SWS_EcuM_02838]
[ ]
[SWS_EcuM_02806]
[ ]
- EcuM_StartupTwo 注意事项：必须在作为 StartOS 的结果被直接启动的任务中调用此函数。也就是说，必须在自启动任务中调用 EcuM_StartupTwo 函数，或者必须在明确会被启动的任务中调用 EcuM_StartupTwo 函数。
对 [SWS_EcuM_02806] 的澄清：OS 提供了不同的机制来激活 Startup 时的任务。通常情况下，EcuM_StartupTwo 会被配置为默认应用程序模式下的自启动任务。
集成商可以配置 OS 以任何机制激活 EcuM_StartupTwo 任务，只要它在调用 StartOS 后立即被启动即可。该任务也可以在另一个任务中被激活，并且“另一个任务”可以是自启动任务。
将 EcuM_StartupTwo 作为自启动任务启动是一种隐式激活。其他机制将是显式激活。
EcuM_Shutdown
[SWS_EcuM_02812]
[SRS_ModeMgm_09114]
状态管理
EcuM_SetState
[SWS_EcuM_04122]
[ ]
[SWS_EcuM_04123]
[SRS_ModeMgm_09116]
- EcuM_SetState 函数应将 EcuM 状态设置为 State 参数的值。如果 State 参数不是有效值，则 EcuM_SetState 函数不应更改 EcuM 状态，并且如果启用了 EcuMDevErrorDetect，则 EcuM_SetState 函数还应向 Det 报告 ECUM_E_STATE_PAR_OUT_OF_RANGE。
EcuM_RequestRUN
[SWS_EcuM_04124]
EcuM_RequestRUN 的请求不能嵌套，即一个用户只能提出一个请求，不能提出更多请求。
[SWS_EcuM_04126]
[SRS_ModeMgm_09116]
- 实施必须跟踪 ECU 上每个已知用户的请求。RUN 请求特定于用户。
[SWS_EcuM_03024]
[ ]
- 如果启用了 EcuMDevErrorDetect，并且 EcuM_RequestRUN 检测到同一用户的多个请求，该函数应向 Det 报告 ECUM_E_MULTIPLE_RUN_REQUESTS。
EcuM_ReleaseRUN
[SWS_EcuM_04127]
[SRS_ModeMgm_09116]
[SWS_EcuM_03023]
[ ]
- 如果启用了 EcuMDevErrorDetect 并且 EcuM_ReleaseRUN 没有为提供的用户找到先前匹配的请求，则该函数应向 Det 报告 ECUM_E_MISMATCHED_RUN_RELEASE。
EcuM_ReleaseRUN 的配置：有关用户 ID 及其生成的更多信息，请参阅 EcuM_UserType。
EcuM_RequestPOST_RUN
[SWS_EcuM_04128]
[SRS_ModeMgm_09116)]
[SWS_EcuM_03025]
[ ]
- 如果启用了 EcuMDevErrorDetect，并且 EcuM_RequestPOST_RUN 检测到同一用户的多个请求，该函数应向 Det 报告 ECUM_E_MULTIPLE_RUN_REQUESTS。
8.3.3.2 EcuM_RequestRUN 的所有要求均适用于功能 EcuM_RequestPOST_RUN。
EcuM_RequestPOST_RUN 的配置：有关用户 ID 及其生成的更多信息，请参阅 EcuM_UserType。
EcuM_ReleasePOST_RUN
[SWS_EcuM_04129]
[SRS_ModeMgm_09116]
[SWS_EcuM_03026]
[ ]
- 如果启用了 EcuMDevErrorDetect，并且 EcuM_ReleasePOST_RUN 没有为提供的用户找到先前匹配的请求，则该函数应向 Det 报告 ECUM_E_MISMATCHED_RUN_RELEASE。
EcuM_ReleasePOST_RUN 的配置：有关用户 ID 及其生成的更多信息，请参阅 EcuM_UserType。
Shutdown 管理
EcuM_SelectShutdownTarget
[SWS_EcuM_02822]
[SRS_ModeMgm_09114]
[SRS_ModeMgm_09128]
[SRS_ModeMgm_09235]
[SWS_EcuM_00624]
[SRS_ModeMgm_09114]
[SRS_ModeMgm_09235]
- EcuM_SelectShutdownTarget 函数应将 Shutdown 目标设置为 shutdownTarget 参数的值。
[SWS_EcuM_02185]
[SRS_ModeMgm_09114]
- 函数 EcuM_SelectShutdownTarget 的参数 mode 应为休眠或复位模式的标识符。仅当 target 参数等于 ECUM_SHUTDOWN_TARGET_SLEEP 或 ECUM_SHUTDOWN_TARGET_RESET 时，才应使用 mode 参数。在所有其他情况下，应将其忽略。只有在配置时被定义并被存储在 EcuMCommonConfiguration 容器（参见 [ECUC_EcuM_00181]）中的休眠或复位模式才被允许作为参数。
[SWS_EcuM_02585]
[SRS_ModeMgm_09114]
- EcuM_SelectShutdownTarget 不会启动任何设置动作，而仅存储该值以供稍后在 SHUTDOWN 或 SLEEP 阶段使用。
实施提示：EcuM 模块未定义任何机制来解决因不同来源的请求而引起的冲突。Shutdown 目标应始终为最后被设置的值。
EcuM_GetShutdownTarget
[SWS_EcuM_02824]
[SRS_ModeMgm_09128]
[SRS_ModeMgm_09235]
[SWS_EcuM_02788]
[ ]
- 如果指向 shutdownMode 参数的指针为 NULL，EcuM_GetShutdownTarget 应忽略 shutdownMode 参数。如果启用了 EcuMDevErrorDetect，EcuM_GetShutdownTarget 应向 Det 报告 ECUM_E_PARAM_POINTER。
EcuM_GetLastShutdownTarget
[SWS_EcuM_02825]
[SRS_ModeMgm_09128]
[SRS_ModeMgm_09235]
[SWS_EcuM_02156]
[SRS_ModeMgm_09235]
- EcuM_GetLastShutdownTarget 应在 shutdownTarget 参数中返回上次唤醒或启动发生时的 ECU 状态。EcuM_GetLastShutdownTarget 应始终返回相同的值，直到下次 Shutdown。
[SWS_EcuM_02336]
[ ]
- 如果 EcuM_GetLastShutdownTarget() 调用在参数 shutdownTarget 中传递了 ECU_STATE_SLEEP，则在参数 shutdownMode 中它将返回一个休眠模式以表明实际选择了哪种配置的休眠模式。
- 如果 EcuM_GetLastShutdownTarget() 调用在参数 shutdownTarget 中传递了 ECU_STATE_RESET，则在参数 sleepMode 中它将返回一个重置模式以表明实际选择了哪种配置的重置模式。
[SWS_EcuM_02337]
[ ]
- 如果指向 shutdownMode 参数的指针为 NULL，则 EcuM_GetLastShutdownTarget 应忽略 shutdownMode 参数并返回最后一个 Shutdown 目标，无论它是否处于休眠状态。如果启用了 EcuMDevErrorDetect ，则 EcuM_GetLastShutdownTarget 应向 Det 报告 ECUM_E_PARAM_POINTER 。
[SWS_EcuM_02157]
[ ]
- EcuM_GetLastShutdownTarget 可能会在 STARTUP 阶段返回在上一个 SHUTDOWN 阶段后期设置的 Shutdown 目标。如果是这样，则应明确记录有关实施的特定限制。
[SWS_EcuM_02157] 的基本原理
EcuM_GetLastShutdownTarget 函数主要用于 ECU STARTUP 或 RUN 状态。为了简化实现，可以在后期 SHUTDOWN 阶段设置该值，以便在下次 STARTUP 时使用。
EcuM_SelectShutdownCause
[SWS_EcuM_04050]
[ ]
EcuM_GetShutdownCause
[SWS_EcuM_04051]
[ ]
唤醒处理
EcuM_CheckWakeup
[SWS_EcuM_91007]
[ ]
EcuM_GetPendingWakeupEvents
[SWS_EcuM_02827]
[SRS_ModeMgm_09126]
[SWS_EcuM_01156]
[ ]
- EcuM_GetPendingWakeupEvents 应返回已被设置为挂起但尚未被验证为在 EcuM_WakeupSourceType bit 掩码中被设置的 bit 的唤醒事件。
[SWS_EcuM_02172]
[ ]
- EcuM_GetPendingWakeupEvents 应该可以在中断上下文、OS 上下文和无 OS 上下文中被调用。
[SWS_EcuM_03003]
[ ]
- EcuM_GetPendingWakeupEvents 的注意事项：此函数仅返回状态为 ECUM_WKSTATUS_PENDING 的唤醒事件。
EcuM_ClearWakeupEvent
[SWS_EcuM_02828]
[SRS_ModeMgm_09126]
[SWS_EcuM_02683]
[ ]
- EcuM_ClearWakeupEvent 在内部挂起唤醒事件变量、内部已验证事件变量和内部已过期事件变量中清除在参数源（EcuM_WakeupSourceType 位掩码）中被设置的并以 bit 设置的方式被传递的所有挂起事件。
另请参阅第 7.6.3 节唤醒状态的内部表示。
[SWS_EcuM_02807]
[ ]
- EcuM_ClearWakeupEvent 应该可以在中断上下文、OS 上下文和无 OS 上下文中被调用。
集成注意事项：
唤醒源的清除应在 ECU Shutdown 期间，且在调用 Dem_Shutdown() 和 NvM_WriteAll() 之前进行。
这可以通过在 BswM 模块中配置 BswMRules 来实现，该模块包含类型为 BswMUserCallout 的 BswMActions，其 BswMUserCalloutFunction 参数被设置为“EcuM_ClearWakeupEvents(<sources>)”。
因此，<sources> 派生自 EcuM 配置中的 EcuMWakeupSourceIds 。然后必须以某种方式配置这些 BswMRules，使其在 ECU Shutdown 期间，且在调用 Dem_Shutdown() 和 NvM_WriteAll() 之前被触发。
EcuM_GetValidatedWakeupEvents
[SWS_EcuM_02830]
[SRS_ModeMgm_09126]
[SWS_EcuM_02533]
[ ]
- EcuM_GetValidatedWakeupEvents 应返回已在内部已验证事件变量中被设置为已验证的唤醒事件，该事件的存在形式为 EcuM_WakeupSourceType bit 掩码中的 bit 设置。
另请参阅第 7.6.3 节唤醒状态的内部表示。
[SWS_EcuM_02532]
[ ]
- EcuM_GetValidatedWakeupEvents 应该可以在中断上下文、OS 上下文和无 OS 上下文中被调用。
EcuM_GetExpiredWakeupEvents
[SWS_EcuM_02831]
[SRS_ModeMgm_09126]
[SWS_EcuM_04076]
[ ]
- EcuM_GetExpiredWakeupEvents 应返回已在内部已过期事件变量中被设置为已验证的唤醒事件，该事件的存在形式为 EcuM_WakeupSourceType bit 掩码中的 bit 设置。
另请参阅第 7.6.3 节唤醒状态的内部表示。
[SWS_EcuM_02589]
[ ]
- EcuM_GetExpiredWakeupEvents 应该可以在中断上下文、OS 上下文和无 OS 上下文中被调用。
闹钟时钟
EcuM_SetRelWakeupAlarm
[SWS_EcuM_04054]
[SRS_ModeMgm_09186]
[SRS_ModeMgm_09190]
[SWS_EcuM_04055]
[SRS_ModeMgm_09186]
- 如果从现在起的相对时间早于当前唤醒时间，EcuM_SetRelWakeupAlarm 将更新唤醒时间。
[SWS_EcuM_04056]
[SRS_ModeMgm_09186]
- 如果从现在起的相对时间晚于当前唤醒时间，则 EcuM_SetRelWakeupAlarm 不应更新唤醒时间并返回 ECUM_E_EARLIER_ACTIVE。
EcuM_SetAbsWakeupAlarm
[SWS_EcuM_04057]
[SRS_ModeMgm_09186]
[SRS_ModeMgm_09199]
[SWS_EcuM_04058]
[SRS_ModeMgm_09186]
- 如果时间参数早于当前唤醒时间， EcuM_SetAbsWakeupAlarm 应更新唤醒时间。
[SWS_EcuM_04059]
[SRS_ModeMgm_09186]
- 如果时间参数晚于当前唤醒时间，EcuM_SetAbsWakeupAlarm 不得更新唤醒时间并应返回 ECUM_E_EARLIER_ACTIVE。
[SWS_EcuM_04060]
[SRS_ModeMgm_09186]
- 如果时间参数早于现在时间， EcuM_SetAbsWakeupAlarm 不得更新唤醒时间并应返回 ECUM_E_PAST。
EcuM_AbortWakeupAlarm
[SWS_EcuM_04061]
[ ]
EcuM_GetCurrentTime
[SWS_EcuM_04062]
[ ]
EcuM_GetWakeupTime
[SWS_EcuM_04063]
[ ]
EcuM_SetClock
[SWS_EcuM_04064]
[SRS_ModeMgm_09194]
Miscellaneous
EcuM_SelectBootTarget
[SWS_EcuM_02835]
[ ]
[SWS_EcuM_02247]
[ ]
- 服务 EcuM_SelectBootTarget 应以与引导加载程序兼容的方式存储选定的目标。
[SWS_EcuM_02247] 的解释：这可能意味着格式和位置。实施者必须确保将启动目标信息放置在安全的位置，然后启动管理器可以在重置后对该位置进行评估。
[SWS_EcuM_03000]
[ ]
- EcuM_SelectBootTarget 函数注意事项：此服务可能取决于所使用的引导加载程序。此服务仅供与诊断（引导管理）相关的软件组件使用。
EcuM_GetBootTarget
[SWS_EcuM_02836]
[SRS_BSW_00172]
Callback 定义
来自唤醒源的 Callback
EcuM_SetWakeupEvent
[SWS_EcuM_02826]
[SRS_BSW_00359]
[SRS_BSW_00360]
[SRS_BSW_00440]
[SRS_ModeMgm_09098]
[SWS_EcuM_01117]
[ ]
- EcuM_SetWakeupEvent 设置（或操作）所有传递形式为在内部挂起唤醒事件变量中作为参数源（EcuM_WakeupSourceType）的 bit 设置（bit 掩码）的事件。
[SWS_EcuM_02707]
[ ]
- EcuM_SetWakeupEvent 应根据唤醒验证超时来启动唤醒验证超时计时器。
参见章节 7.6.4.3 唤醒验证超时。
[SWS_EcuM_02867]
[ ]
- 如果启用了 EcuMDevErrorDetect，并且参数“sources”包含未知（未配置）的唤醒源，则 EcuM_SetWakeupEvent 不应更新其内部变量，而应向 Det 报告 ECUM_E_UNKNOWN_WAKEUP_SOURCE。
[SWS_EcuM_02171]
[SRS_BSW_00333]
- EcuM_SetWakeupEvent 必须可以在中断上下文、OS 上下文和无 OS 上下文中被调用。
[SWS_EcuM_04138]
[ ]
- EcuM_SetWakeupEvent 应忽略在源参数中被传递的所有与所选休眠模式无关的事件。
EcuM_ValidateWakeupEvent
[SWS_EcuM_02829]
[SRS_BSW_00359]
[SRS_BSW_00360]
[SRS_BSW_00440]
[SWS_EcuM_04078]
[ ]
- EcuM_ValidateWakeupEvent 设置（或操作）所有传递形式为在内部已验证唤醒事件变量中作为参数源（EcuM_WakeupSourceType）的 bit 设置（bit 掩码）的事件。
另请参阅章节 7.6.3 唤醒状态的内部表示。
[SWS_EcuM_04079]
[ ]
- EcuM_ValidateWakeupEvent 应使用其源参数和状态值 ECUM_WKSTATUS_VALIDATED 来调用 BswM_EcuM_CurrentWakeup。
[SWS_EcuM_02645]
[ ]
- 如果配置了相应唤醒源的 EcuMWakeupSource 配置容器中的 EcuMComMChannelRef 参数（参见 [ECUC_EcuM_00101]），则 EcuM_ValidateWakeupEvent 应为每个唤醒事件调用 ComM_EcuM_WakeUpIndication。
[SWS_EcuM_02868]
[ ]
- 如果启用 EcuMDevErrorDetect 并且源参数包含未知（未配置）的唤醒源，则 EcuM_ValidateWakeupEvent 将忽略该调用并向 Det 报告 ECUM_E_UNKNOWN_WAKEUP_SOURCE 。
[SWS_EcuM_02345]
[SRS_BSW_00333]
- EcuM_ValidateWakeupEvent 应可在中断上下文和任务上下文中被调用。
[SWS_EcuM_02790]
[ ]
- 当 ECU 管理器模块处于 RUN 状态时，调用 EcuM_ValidateWakeupEvent 将不会对除通信通道之外的所有唤醒源产生影响。
[SWS_EcuM_02791]
[ ]
- 对于与通信通道相对应的唤醒源，EcuM_ValidateWakeupEvent 应在任何 ECU 阶段都对其产生影响（参见 [SWS_EcuM_02645]）。
[SWS_EcuM_04140]
[ ]
- 如果在相应唤醒源的 EcuMWakeupSource 配置容器中配置了至少一个 EcuMComMPNCRef 参数（参见 [ECUC_EcuM_00228]），则 EcuM_ValidateWakeupEvent 将为每个唤醒事件和每个引用的 PNC 调用 ComM_EcuM_PNCWakeUpIndication。
Callout 定义
调用（Callout）是 ECU 集成过程中必须被添加到 EcuM 模块的代码片段。大多数调用的内容都是手写代码。EcuM 模块配置工具会为某些调用生成默认实现，这些调用之后会由集成商手动编辑。从概念上讲，这些调用属于 ECU 集成代码。
通用 Callout
EcuM_ErrorHook
[SWS_EcuM_02904]
[ ]
EcuM 模块可以在所有阶段调用 EcuM_ErrorHook，EcuM_ErrorHook 类为强制类型。EcuM_ErrorHook 是集成代码，供应商可以自由定义其他单个错误码作为原因参数被传递。这些错误码不得与表 7.9 中定义的开发和生产错误码相冲突。
STARTUP 阶段的 Callout
EcuM_AL_SetProgrammableInterrupts
[SWS_EcuM_04085]
[ ]
EcuM_AL_DriverInitZero
[SWS_EcuM_02905]
[ ]
EcuM 模块在 PreOS 序列的早期调用 EcuM_AL_DriverInitZero（参见第 7.3.2 节 StartPreOS 序列中的活动）。
EcuM 模块配置工具必须通过在 EcuMDriverInitListZero 配置容器中定义的模块序列生成 EcuM_AL_DriverInitZero 调用 ([SWS_EcuM_02905]) 的默认实现（参见 [ECUC_EcuM_00114]）。另请参阅 [SWS_EcuM_02559] 和 [SWS_EcuM_02730]。
EcuM_DeterminePbConfiguration
[SWS_EcuM_02906]
[ ]
EcuM 模块在 PreOS 序列的早期调用 EcuM_DeterminePbConfiguration（参见第 7.3.2 节 StartPreOS 序列中的活动）。
EcuM_AL_DriverInitOne
[SWS_EcuM_02907]
[ ]
EcuM 模块在 PreOS 序列中调用 EcuM_AL_DriverInitOne（参见第 7.3.2 节 StartPreOS 序列中的活动）。
EcuM 模块配置工具必须依照在 EcuMDriverInitListOne 配置容器中定义的模块序列生成 EcuM_AL_DriverInitOne 调用的默认实现（参见 [ECUC_EcuM_00111]）。另请参阅
[SWS_EcuM_02559] 和 [SWS_EcuM_02730]。
除了驱动程序初始化之外，在此块中还应考虑以下初始化序列：根据 AUTOSAR_SWS_MCUDriver 第 9.1 章进行的 MCU 初始化。
EcuM_LoopDetection
[SWS_EcuM_04137]
[ ]
SHUTDOWN 阶段的 Callout
EcuM_OnGoOffOne
[SWS_EcuM_02916]
[ ]
EcuM 模块在进入 OffPreOS 序列时调用 EcuM_OnGoOffOne（参见 7.4.1 节 OffPreOS 序列中的活动）。
EcuM_OnGoOffTwo
[SWS_EcuM_02917]
[ ]
EcuM 模块在进入 OffPostOS 序列时调用 EcuM_OnGoOffTwo（参见 7.4.2 节 OffPostOS 序列中的活动）。
EcuM_AL_SwitchOff
[SWS_EcuM_02920]
[ ]
EcuM 模块调用 EcuM_AL_SwitchOff 作为在 OffPostOS 序列中的最后一个活动 （参见7.4.2 OffPostOS 序列中的活动）。
注意：在某些硬件/软件并发情况下，在 EcuM_AL_SwitchOff（无限循环）断电期间可能会发生某些硬件（例如 CAN 收发器）再次打开 ECU 的情况。在这种情况下，ECU 可能处于死锁状态，直到硬件看门狗重置 ECU。为了减少硬件看门狗修复此死锁的时间，作为最后操作，EcuM_AL_SwitchOff 中的集成器代码可以限制无限循环，并在足够长的时间后使用 MCU 平台的 Reset() 重置 ECU。
EcuM_AL_Reset
[SWS_EcuM_04065]
[ ]
SLEEP 阶段的 Callout
EcuM_EnableWakeupSources
[SWS_EcuM_02918]
[ ]
EcuM 模块在 GoSleep 序列中调用 EcuM_EnableWakeupSources（参见第 7.5.1 节 GoSleep 序列中的活动）。
[SWS_EcuM_02546]
[ ]
- EcuM 模块应从为当前休眠模式配置的 EcuMWakeupSource（参见 [ECUC_EcuM_00152]）的 bit 域中派生要启用的唤醒源（并用作 wakeupSource 参数）。
EcuM_GenerateRamHash
[SWS_EcuM_02919]
[ ]
EcuM 模块在使 ECU 物理上进入休眠状态之前，会在 Halt 序列中调用 EcuM_GenerateRamHash：（参见第 7.5.2 节 Halt 序列中的活动）。
EcuM_SleepActivity
[SWS_EcuM_02928]
[ ]
如果 MCU 未被挂起（即时钟被停止），则 EcuM 模块会在 Poll 序列期间定期调用 EcuM_SleepActivity（参见第 7.5.3 节 Poll 序列中的活动）。
注意：如果在 Poll 序列调用此函数，EcuM 会以最大频率在阻塞循环中调用此调用函数。调用函数的实现必须通过某种方式确定调用函数代码是否应以较低的周期执行。集成商可以选择任何方法来控制这一点，例如借助 OS 计数器、OS 闹钟或 Gpt 计时器。
EcuM_StartCheckWakeup
[SWS_EcuM_04096]
[ ]
EcuM_CheckWakeupHook
[SWS_EcuM_91006]
[ ]
注意：在 EcuM 以前的规范中，调用函数 EcuM_CheckWakeupHook 被命名为
EcuM_CheckWakeup（原为 [SWS_EcuM_02929]）。对于 R21-11，以前的调用函数 EcuM_CheckWakeup 被改为 EcuM 的一个实际函数（同名），对应现在的 EcuM_CheckWakeupHook。
注意：EcuM_CheckWakeupHook 函数由集成器代码实现，用于调用给定唤醒源的对应 <driver module>_CheckWakeup。在 EcuM_CheckWakeupHook 调用中，可按给定顺序调用以下函数：
- 用给定的唤醒源调用 EcuM_StartCheckWakeup，以启动 CheckWakeupTimer。对于一个待处理的唤醒，运行中的 CheckWakeupTimer 应阻止 ECU Shutdown，在相应驱动程序模块（例如 CanTrcv）对唤醒源的检查完毕之前。
- 调用驱动程序模块（例如 CanTrcv）的 <driver module>_CheckWakeup，该模块被分配给给定的唤醒源。
[SWS_EcuM_04098]
[ ]
- 如果驱动程序模块为相应的唤醒源调用 EcuM_SetWakeupEvent，则应取消CheckWakeupTimer。
EcuM_CheckRamHash
[SWS_EcuM_02921]
[ ]
EcuM 模块在 WakeupRestart 序列的早期调用 EcuM_CheckRamHash（参见第 7.5.5 节 WakeupRestart 序列中的活动）。
[SWS_EcuM_02987]
[ ]
- 当唤醒时的 RAM 检查失败时，EcuM 模块应使用参数 ECUM_E_RAM_CHECK_FAILED 调用 EcuM_ErrorHook。
另请参阅第 7.5.2 节“Halt 序列中的活动”。
EcuM_DisableWakeupSources
[SWS_EcuM_02922]
[ ]
EcuM 模块在 WakeupRestart 序列中调用 EcuM_DisableWakeupSources（参见第 7.5.5 节 WakeupRestart 序列中的活动）。
[SWS_EcuM_04084]
[ ]
- EcuM 模块应从内部挂起事件变量（NOT 操作）中派生要禁用的唤醒源（并用作 wakeupSource 参数）。用于此调用的集成代码必须确定哪些唤醒源应被禁用。
EcuM_AL_DriverRestart
[SWS_EcuM_02923]
[ ]
EcuM 模块在 WakeupRestart 序列中调用 EcuM_AL_DriverRestart（参见第 7.5.5 节 WakeupRestart 序列中的活动）
EcuM 模块配置工具应通过在 EcuMDriverRestartList 配置容器中定义的模块序列生成 EcuM_AL_DriverRestart 调用的默认实现（参见 [ECUC_EcuM_00115]）。另请参阅
[SWS_EcuM_02561]、[SWS_EcuM_02559] 和 [SWS_EcuM_02730]。
UP 阶段的 Callout
EcuM_StartWakeupSources
[SWS_EcuM_02924]
[ ]
EcuM 模块在 WakeupValidation 序列中调用 EcuM_StartWakeupSources（参见第 7.6.4 节 WakeupValidation 序列中的活动）。
EcuM_CheckValidation
[SWS_EcuM_02925]
[ ]
EcuM 模块在 WakeupValidation 序列中调用 EcuM_CheckValidation（参见第 7.6.4 节 WakeupValidation 序列中的活动）。
EcuM_StopWakeupSources
[SWS_EcuM_02926]
[ ]
EcuM 模块在 WakeupValidation 序列中调用 EcuM_StopWakeupSources（参见第 7.6.4 节 WakeupValidation 序列中的活动）。
调度函数
这些函数由基础软件调度程序直接调用。以下函数应无返回值和参数。所有函数均应为不可重入的。
EcuM_MainFunction
[SWS_EcuM_02837]
[SRS_BSW_00425]
[SRS_BSW_00373]
为了确定周期，系统设计人员应该考虑：
- 该函数将执行唤醒验证（参见 7.8 唤醒验证协议）。最短的验证超时时间通常会限制该周期的长短。
- 根据经验法则，该函数的周期应约为最短验证超时时间的一半。
不应在可能调用可运行实体的任务中调用 EcuM_MainFunction。
预期接口
[SWS_EcuM_02858]
[ ]
可选接口
[SWS_EcuM_02859]
[ ]
可配置接口
STARTUP 阶段的 Callback
[SWS_EcuM_91001]
[ ]
EcuM_AL_DriverInitBswM_<x> 回调由 BswM 在初始化期间调用。EcuM 模块配置工具必须通过在 EcuMDriverInitListBswM 配置容器中定义的模块序列生成 EcuM_AL_DriverInitBswM_<x> 回调的默认实现（参见 [ECUC_EcuM_00226]）。另请参阅 [SWS_EcuM_04142]。
[SWS_EcuM_04114]
[ ]
- 为每个配置的 EcuMDriverInitListBswM 生成 EcuM_AL_DriverInitBswM_<x>。生成的函数的名称应为 EcuM_AL_DriverInitBswM_<x>，其中 <x> 表示 EcuMDriverInitListBswM 容器的简称。
端口接口规范
本章指定了通过 VFB 访问 EcuM 模块所需的端口接口和端口。
EcuM_ShutdownTarget 接口的端口和端口接口
一般方法
EcuM_ShutdownTarget 客户端-服务器接口允许软件组件选择将在下一个 Shutdown 阶段执行的 Shutdown 目标。但请注意，EcuM 模块不向软件组件提供发起 Shutdown 的端口接口。
服务接口
[SWS_EcuM_03011]
[ ]
[SWS_EcuM_02979]
[ ]
- shutdownMode 参数应确定与
- SelectShutdownTarget
- GetShutdownTarget
- GetLastShutdownTarget
- EcuM 模块应仅在 shutdownTarget 参数等于
- ECUM_SHUTDOWN_TARGET_SLEEP
- ECUM_SHUTDOWN_TARGET_RESET
EcuM_BootTarget 接口的端口接口
一般方法
选择 Boot 目标的软件组件必须需要客户端-服务器接口 EcuM_BootTarget。
服务接口
[SWS_EcuM_03012]
[ ]
EcuM_AlarmClock 接口的端口接口
一般方法
使用闹钟的软件组件必须需要客户端-服务器接口 EcuM_AlarmClock。EcuM_AlarmClock 接口使用端口定义的参数值来识别管理其闹钟的用户。有关端口定义参数值的描述，请参阅 RTE 规范 （AUTOSAR_SWS_RTE.pdf） 中的 [SWS_Rte_1350]。
服务接口
[SWS_EcuM_04105]
[ ]
EcuM_Time 接口的端口接口
一般方法
使用 EcuM 时间功能的软件组件必须需要客户端服务器接口 EcuM_Time。
数据类型
EcuM_Time 服务没有任何特定的数据类型。
服务接口
[SWS_EcuM_04109]
[ ]
EcuM_StateRequest 接口的端口接口
[SWS_EcuM_04130]
[SRS_ModeMgm_09116]
- 当容器 EcuMModeHandling（参见 10.2.1）可用时，EcuM 模块应为以下功能提供系统服务：
- 请求 RUN
- 释放 RUN
- 请求 POST_RUN
- 释放 POST_RUN
一般方法
需要让 ECU 处于活动状态或需要在 ECU Shutdown 之前执行任何操作的软件组件需要客户端-服务器接口 EcuM_StateRequest。此接口使用端口定义的参数值来识别请求模式的用户。有关端口定义参数值的描述，请参阅 [SWS_Rte_1350]。
数据类型
此接口不需要任何数据类型。
服务接口
[SWS_EcuM_04131]
[ ]
EcuM_CurrentMode 接口的端口接口
一般方法
[SWS_EcuM_04132]
[SRS_ModeMgm_09116]
- EcuM 模块的模式端口应声明以下模式：
- STARTUP
- RUN
- POST_RUN
- SLEEP
- SHUTDOWN
此定义是应用程序确实需要了解的 ECU 模式的简化视图。它不会以任何方式限制如何定义应用程序模式。应用程序模式完全由应用程序自身处理。
[SWS_EcuM_04133]
[ ]
- 当模式发生变化时，应通过 RTE 模式端口将模式变化通知给软件组件。本规范假设端口名称为 currentMode，并为将被使用的 RTE 的直接 API。在这些条件下，模式改变通过调用
Rte_ModeType_EcuM_Mode mode
)
)
- 发出信号，其中模式是需要被通知的新模式。值范围由前面的要求指定。返回值应被忽略。想要收到模式更改通知的软件组件应要求模式切换接口 EcuM_CurrentMode。
数据类型
模式声明组 EcuM_Mode 代表将向软件组件通知的 EcuM 模块的模式。
ModeDeclarationGroup EcuM_Mode
{
{ STARTUP, RUN, POST_RUN, SLEEP, SHUTDOWN }
initialMode = STARTUP
};
[SWS_EcuM_04107]
[ ]
服务接口
[SWS_EcuM_04108]
[ ]
EcuM 服务定义
本节提供有关 EcuM 模块服务定义的指导。请注意，这些定义只能在 ECU 配置期间被完成（因为某些 EcuM 模块配置参数决定了 EcuM 模块服务提供的端口数量）。另请注意，软件组件的实现不依赖于这些定义。
在 AUTOSAR 系统中，RTE 上方和下方都有端口。EcuM 模块服务描述定义了提供给 RTE 的端口，并且每个使用此服务的软件组件的描述都必须包含被 RTE 这些 EcuM 模块端口所需要的“服务端口”。
EcuM 提供以下端口：
[SWS_EcuM_04111]
[ ]
[SWS_EcuM_04110]
[ ]
[SWS_EcuM_03017]
[ ]
[SWS_EcuM_04113]
[ ]
[SWS_EcuM_04135]
[ ]
[SWS_EcuM_04112]
[ ]
EcuM 提供以下类型：
[SWS_EcuM_91004]
[ ]
[SWS_EcuM_04102]
[ ]
[SWS_EcuM_91008]
[ ]
[SWS_EcuM_04045]
[ ]
[SWS_EcuM_04101]
[ ]
[SWS_EcuM_04136]
[ ]
[SWS_EcuM_04094]
[ ]
- 对于多核 ECU，EcuM AUTOSAR 服务（标准化 AUTOSAR 接口）可在一个或多个核心上被提供。
尽管 EcuM 服务接口在每个核心上都可用（有关详细信息，请参阅第 7.9 节“多核心”），但 EcuC 允许将提供的端口绑定到特定分区上的接口，从而被绑定到特定核心（请参阅 ECU 配置规范 [5]），并且只有该端口将对 VFB 可见。在多核心的情况下，这应该被绑定到主核心。ECU 上需要访问 EcuM 服务的软件组件和 CDD 可以通过 RTE 生成的 IOC 访问主核心。
[SWS_EcuM_04095]
[ ]
- 对于多核心 ECU，有 EcuM 运行的每个分区都应提供其他 BSW 模块会使用的 EcuM C-API 接口（标准化接口）。
每个 EcuM 实例都提供其他 BSW 模块用来与 EcuM 通信的 C-API 接口，因为每个 EcuM 实例都可以执行一些独立的操作。如果 BSW 模块想要使用 EcuM，但位于不包含自己的 EcuM 实例的分区内，这些模块可以使用 SchM 函数跨越分区边界。
序列图
状态序列
规范文本流程中包含了显示 EcuM 模块在各种状态下的行为的序列图。以下列表显示了本规范中呈现的所有序列图。
- Figure 7.3 - STARTUP 阶段
- Figure 7.4 - StartPreOS 序列
- Figure 7.5 - StartPostOS 序列
- Figure 7.7 - SHUTDOWN 阶段
- Figure 7.8 - OffPreOS 序列
- Figure 7.9 - OffPostOS 序列
- Figure 7.10 - SLEEP 阶段
- Figure 7.11 - GoSleep 序列
- Figure 7.12 - Halt 序列
- Figure 7.13 - Poll 序列
- Figure 7.14 - WakeupRestart 序列
- Figure 7.16 - WakeupValidation 序列
Wakeup 序列
唤醒序列显示了多个模块如何通过协作使 ECU 进入休眠状态，以便能够在唤醒事件发生时唤醒并启动 ECU。
GPT Wakeup 序列
通用定时器 (GPT) 是可能的唤醒源之一。通常，GPT 在 ECU 进入休眠状态之前启动，并且硬件定时器在到期时会引发中断。中断唤醒微控制器，并执行 GPT 模块中的中断处理程序。它通知 EcuM 模块 GPT 唤醒已发生。为了区分导致唤醒的不同 GPT 通道，集成商可以为每个 GPT 通道分配不同的唤醒源标识符。图 9.1 显示了相应的调用序列。
如果 GPT 硬件能够锁存定时器溢出，那么也可以轮询 GPT 是否唤醒，如图 9.2 所示。
ICU Wakeup 序列
输入捕获单元 (ICU) 是另一个唤醒源。与 GPT 不同，ICU 驱动程序本身不是唤醒源。它只是处理唤醒中断的模块。因此，只有唤醒源的驱动程序才能判断它是否负责该唤醒。这使得 EcuM_CheckWakeupHook 必须询问实际唤醒源的模块。为了知道要询问哪个模块，ICU 必须将唤醒源的标识符传递给 EcuM_CheckWakeup。对于共享中断，集成代码可能必须检查 EcuM_CheckWakeupHook 中的多个唤醒源。为此，ICU 必须将所有可能导致此中断的唤醒源的标识符传递给 EcuM_CheckWakeup。请注意，每个唤醒源在 EcuM_WakeupSourceType（参见 8.2.3 EcuM_WakeupSourceType）上由一个 bit 表示，因此可以在一次调用中传递多个唤醒源。
图 9.3 显示了调用所导致的序列。由于 ICU 仅负责处理唤醒中断，因此轮询 ICU 并不明智。轮询时必须直接检查唤醒源，如图 38 所示。
CAN Wakeup 序列
在 CAN 上，收发器或通信控制器可以使用中断或轮询来检测唤醒。唤醒源标识符应在收发器和控制器之间共享，因为 EcuM 模块只需要知道已被唤醒的网络并将其传递给通信管理器模块。
在中断或共享中断情况下，不清楚哪个特定唤醒源（CAN 控制器、CAN 收发器、LIN 控制器等）检测到了唤醒。
因此，集成器必须将 EcuM_CheckWakeup(wakeupSource) 派生的 wakeupSource（可以代表共享中断或仅代表中断通道）分配给被传递到 CanIf_CheckWakeup(WakeupSource) 的特定唤醒源。
因此，此处 EcuM_CheckWakeup() 的 wakeupSource 参数可能与 CanIf_CheckWakeup 的 WakeupSource 不同，也可能相等。
这取决于硬件拓扑和 EcuM_CheckWakeupHook 的集成器代码的实现。
在 CanIf_CheckWakeup(WakeupSource) 期间，CAN 接口模块 (CanIf) 将检查是否有任何设备（CAN 通信控制器或收发器）被配置了“WakeupSource”的值。
如果是这种情况，则通过相应的设备驱动程序模块检查设备是否唤醒。
如果设备检测到唤醒，设备驱动程序将通过 EcuM_SetWakeupEvent(sources) 通知 EcuM。参数“sources”被设置为被唤醒设备上的配置值。
因此，它也被设置为调用 CanIf_CheckWakeup() 的值。
多个设备可能配置了相同的唤醒源。但如果设备连接到不同的总线介质并且它们可被唤醒，则为它们配置不同的唤醒源是有意义的。
以下 CAN 唤醒序列部分是可选的，因为没有对此“集成代码”的规范。因此，如果在 EcuM_CheckWakeup() 期间调用 CanIf 来检查唤醒源，则它是特定于实现的。
图 9.4 显示了通过中断唤醒 CAN 收发器。中断通常由 ICU 驱动程序处理，如第 9.2.2 章所述。
CAN 控制器中断唤醒与 GPT 唤醒类似，其中中断处理程序和 CheckWakeup 功能均封装在 CAN 驱动程序模块中，如图 9.5 所示。
CAN 收发器和控制器都可以通过轮询唤醒。EcuM 模块将定期检查 CAN 接口模块，然后根据传递给 CAN 接口模块的唤醒源参数，依次询问 CAN 驱动程序模块或 CAN 收发器驱动程序模块，如图 9.6 所示。
通过中断或轮询检测到来自 CAN 收发器或控制器的唤醒事件后，可以对该唤醒事件进行验证（参见[SWS_EcuM_02566]）。
这是通过在 EcuM_StartWakeupSources 中打开相应的 CAN 收发器和控制器来完成的（参见 [SWS_EcuM_02924]）。
集成器代码 EcuM_StartWakeupSource 中的哪些函数调用是必要的，取决于所使用的 CAN 收发器和控制器。
例如，在图 9.7 中提到了，启动和停止来自 CAN 状态管理器模块的唤醒源所需的函数调用。
需要注意的是，虽然收发器和控制器都已被打开，但是 CAN 接口模块（CanIf）不会将 CAN 报文转发到任何上层模块。
只有当 CanIf 对应的 PDU 通道模式被设置为“Online”时，才会转发 CAN 报文。
如果 CanIf 识别至少一条消息的成功接收，会将其记录为一个成功验证。
在验证期间，EcuM 模块会定期检查集成器代码 EcuM_CheckValidation 中的 CanIf（参见 [SWS_EcuM_02925]）。
在验证成功后，EcuM 模块将通过通信管理模块继续 CAN 网络的正常启动。
否则，它将关闭 EcuM_StopWakeupSources 中的 CAN 收发器和控制器（参见 [SWS_EcuM_02926]）并重新进入休眠状态。
序列如图 9.7 所示。
LIN Wakeup 序列
图 9.8 显示了 LIN 收发器通过中断唤醒。中断通常由 ICU 驱动程序处理，如第 9.2.2 章所述。
如图 9.9 所示，LIN 控制器的中断唤醒与 CAN 控制器的中断唤醒类似，两种情况下驱动模块都封装了中断处理程序。
LIN 收发器和控制器可以通过轮询唤醒。EcuM 模块将定期检查 LIN 接口模块，后者又会询问 LIN 驱动程序模块或 LIN 收发器驱动程序模块，如图 9.10 所示。
FlexRay Wakeup 序列
对于 FlexRay，只能通过 FlexRay 收发器进行唤醒。FlexRay 集群中的两个不同通道有两个收发器。它们被视为属于同一个网络，因此应为这两个通道配置同一个唤醒源标识符。
图 9.11 显示了 FlexRay 收发器通过中断唤醒。中断通常由 ICU 驱动程序处理，如第 9.2.2 章所述。
请注意，在 EcuM_CheckWakeupHook 中需要对 FrIf_WakeupByTransceiver 进行两次单独的调用，每个 FlexRay 通道一次。
Ethernet Wakeup 序列
在具有符合 OA TC10 的以太网硬件的以太网交换机网络上，可以使用以太网硬件 (PHY) 检测到唤醒。
对于维护以太网交换机（主机 ECU）的以太网 ECU，建议使用按需轮询来检查以太网硬件通知的唤醒。
因为检查所有受影响的以太网交换机端口会非常耗时，并且不适合在中断内进行检查。
因此，中断发出信号表明至少有一个以太网交换机端口检测到唤醒。
在中断上下文中，受影响的以太网收发器接收到信号以便在 EthTrcv_MainFunction 中接受异步检查。
每个 EthTrcv 应有自己的唤醒源，以区分哪个以太网交换机端口被唤醒。如果以太网交换机端口被分配给相同的 PNC（Partial Network Cluster），则可以共享唤醒源。
以下以太网唤醒序列部分是可选的，因为没有“集成代码”的规范。因此，如果在 EcuM_CheckWakeupHook 期间调用 EthIf 来检查唤醒源，则它是特定于实现的。
单个以太网 ECU（不维护以太网交换机的 ECU）可以选择如何通过中断或轮询来检测唤醒。与主机 ECU 的区别在于，不需要检查大量的以太网交换机端口。
配置规范
常用容器及配置参数
以下容器包含对 BSW 模块初始化结构的各种引用。NULL 应为有效引用，表示“无可用配置数据”，但前提是待初始化的 BSW 模块的实现支持这一点。
EcuM
EcuMGeneral
EcuMConfiguration
EcuMCommonConfiguration
EcuMDefaultShutdownTarget
EcuMDriverInitListOne
EcuMDriverInitListZero
EcuMDriverRestartList
EcuMDriverInitItem
EcuMSleepMode
EcuMWakeupSource
EcuMFlex 容器和配置参数
EcuMFlexGeneral
EcuMFlexConfiguration
EcuMAlarmClock
EcuMDriverInitListBswM
EcuMGoDownAllowedUsers
EcuMResetMode
EcuMSetClockAllowedUsers
评论
发表评论