1、概述
ECU管理器模块（ECU Manager）是管理ECU状态的基础软件模块。具体来说，ECU管理器模块负责：
·初始化和去初始化OS、SchM和BswM以及一些基础软件驱动模块。
·将ECU配置为SLEEP和SHUTDOWN状态。
·管理ECU上的所有唤醒事件（wakeup events）。
ECU管理器模块提供唤醒验证协议（Wakeup validation protocol），以区分真实（real）和不稳定（erratic）唤醒事件。
此外，ECUM还负责：
·提供部分或快速启动（Partial or fast startup）机制。也就是说ECU以有限的功能启动，接着由应用程序确定，并一步步继续完成启动过程。
·提供交错启动（Interleaved startup）机制。ECU以最低限度地启动，然后启动RTE以实现SW-C能尽快地执行功能。接着ECU继续启动其他的BSW和SW-C，从而将BSW和应用程序功能能够交错运行。
·分拆RUN状态到多个运行子状态（operational states）。ECU管理模块将一系列SLEEP状态的概念细化为多个RUN状态。从经典的RUN（完全运行）状态到最深的SLEEP（处理器停止）状态，转换为多个连续运行子状态。
·支持多核ECU：启动、关机、睡眠和唤醒能在ECU的所有内核上进行协调。
灵活的ECUM（Flexible）采用以下模块提供的通用模式管理工具：
RTE和BSWM现在合并为一个模块：该模块支持可自由配置的BSW和应用程序模式及其模式切换工具。
BSWM：该模块实施可配置的规则和操作列表，以评估切换ECU模式的条件并实施必要的操作。
因此，通过灵活的ECU管理，大多数ECU状态已经不在ECU管理器模块中实现。通常来说，当通用模式管理工具在以下情况下不可用时，ECU管理器模块会接管控制：
早期启动阶段（Early STARTUP phases）
后期关闭阶段（Late SHUTDOWN phases）
设施被调度程序锁定的睡眠阶段。
在ECU管理器模块的UP阶段，BSW模式管理器负责进一步的操作。然而，ECU管理器模块会对来自SW-C的RUN和POST_RUN请求进行仲裁，并通知BswM有关的模式状态。
如果进行了相应的配置，灵活的ECU管理模块可以向后兼容以前的ECU管理模块的版本。
RUN请求协议是ECU状态管理器固定中的一种既定方法，用于确定ECU是应保持活动状态还是准备关闭。
固定ECU管理继续ECU管理在以前的AUTOSAR版本的形式。它具有一组固定的ECU状态和它们之间的转换，足以满足没有特殊要求的传统ECU，例如部分或快速启动，交错启动和多个运行状态(多个RUN状态)。除其他事项外，固定（Fixed）ECU管理不支持多核ECU。
2、使用约束
ECU不能总是关闭，即：零功耗（zero power consumption）。 理由：关机目标OFF只能通过ECU特殊硬件来达到。例如：电源保持电路（a power hold circuit）。如果此硬件不存在，则AUTOSAR规范建议改为发出复位（reset）指令。 但是其他默认行为被允许的。
3、驱动依赖
3.1、MCAL部分
MCU驱动是ECU管理器模块初始化的第一个基础软件模块。 但是当MCU_Init返回时，MCU模块和MCU驱动程序模块不一定已经完全初始化，可能需要额外的MCU模块特定步骤来完成初始化。ECU管理器模块提供了两个Callout，可以放置相关附加代码。有关详细信息，可参阅StartPreOS序列中的活动。
BSW驱动程序可能相互依赖。一个典型的例子是看门狗驱动，它需要SPI驱动来访问外部看门狗。这意味着一方面，驱动程序可能是堆叠的，与ECU管理器模块无关。另一方面，一些被调用模块必须在调用模块的初始化之前已被初始化。
系统设计者需负责在配置时，在EcuMDriverInitListZero、EcuMDriverInitListOne、EcuMDriverRestartList和EcuMDriverInitListBswM中定义初始化顺序。
3.2、具备唤醒功能的外设
唤醒源必须由驱动程序处理和封装。
这些驱动程序必须遵循AUTOSAR ECU管理器模块中提出的协议和要求，以确保无缝集成到AUTOSAR的基础软件中。
基本上协议如下：
驱动程序必须调用EcuM_SetWakeupEvent来通知ECUM模块，已检测到待定的唤醒事件。驱动程序不仅需要在ECU在睡眠阶段，等待唤醒事件时调用EcuM_SetWakeupEvent，同时在驱动程序初始化阶段以及EcuM_MainFunction运行的正常操作期间，也是同样需要调用EcuM_SetWakeupEvent。
驱动程序必须提供一个显式函数来使唤醒源进入睡眠状态。此功能应将唤醒源置于节能（energy saving），进入惰性操作模式，并重新启用唤醒通知机制。
如果唤醒源能够产生虚假事件，则以下模块必须为唤醒事件提供验证调用，或者调用ECU管理器模块的验证函数。
·驱动程序
·使用驱动程序的软件堆栈
·另一个合适的 BSW 模块
如果不需要验证，则此需求不适用于相应的唤醒源。
3.3、OS
ECU管理器模块负责初始化BSW调度程序。同时ECU管理器模块会提供EcuM_MainFunction，此接口函数会被定期调度，用于评估唤醒请求并且更新闹钟。
3.4、BSWM
ECUM负责初始化BSW调度程序。同时ECU管理器模块会提供EcuM_MainFunction，此接口函数会被定期调度，用于评估唤醒请求并且更新闹钟。
ECU状态通过AUTOSAR模式来实现，BSWM负责监控ECU中的变化，并酌情影响ECU状态机的相应变化。
有关AUTOSAR模式管理的讨论，请参阅虚拟功能总线规范（Specification of the Virtual Function Bus）
有关ECU状态机实现细节的指南，以及如何通过配置BSW模式管理器以实现ECU的状态机，请参阅模式管理指南（Guide to Mode Management）
BSWM只能在模式管理运行后才能管理ECU的状态机。也就是说，在SchM被初始化之后，直到SchM被去初始化或者停止。ECU管理器模块会在BSWM不工作后接管ECU的控制。
ECUM在ECU启动后立刻进行控制，并在初始化SchM和BswM后将控制权委托给BSW模式管理器。
BswM会将ECU的控制权交还给ECU管理器模块，以达到锁定操作系统并处理唤醒事件。
BswM也会在操作系统关闭停止前，将控制权立刻交还给ECU管理器。
在验证唤醒源时，ECUM通过模式切换请求向BswM指示唤醒源状态更改。
3.5、SWC
ECU 管理器模块需处理以下ECU范围的属性：
关机目标（Shutdown targets）。
在AUTOSAR规范中，假定SW-C通过AUTOSAR的端口来设置这些关机目标的属性，通常通过SW-C的某些ECU的特定部件。ECUM不会阻止SW-C覆盖SW-C所做的设置。这些策略必须在更高级别来定义。
以下措施可能有助于解决此问题：
SW-C模板可能会包含某个字段来表示SW-C是否设置关机目标。
生成工具可能只允许有一个SW-C访问关机目标的配置。
4、ECUM的各个阶段
以前版本的ECU管理模块规范已经区分了ECU状态和ECU模式。
ECU模式是一种持续时间较长的操作ECU活动，这些活动对应用程序可见并为它们提供方向，例如：启动（starting up）、关闭（shutting down）、休眠（going to sleep）和唤醒（waking up）。
ECUM状态通常是ECU管理器模块操作的连续序列，通过等待直到外部条件满足而终止。例如：Startup1包含操作系统启动之前的所有BSW初始化，并在操作系统将控制权返回给ECU管理器模块时终止。
在这里ECU状态机在BSW模式管理器模块的控制下作为通用模式实现。这就产生了一个术语问题。因为旧的ECU状态（State）现在变成了通过RTE_Mode端口接口可见的模式（Mode），而旧的ECU模式（Mode）变成了阶段（Phase）。由于通过VFB定义并在RTE中使用的模式（Mode）仅在UP阶段可用，即ECU管理器处于被动状态，所以有必要将术语从模式（Mode）更改为阶段（Phase）。
STARTUP阶段一直需持续到模式管理设施（Mode Management Facilities）正常运行。基本上STARTUP阶段包括启动模式管理所需的最少活动：初始化低级驱动程序、启动操作系统和初始化BSW调度程序和BSW模式管理器模块。类似地SHUTDOWN阶段与STARTUP阶段相反，是模式管理被去初始化（de-initialized）的阶段。
UP阶段由所有未突出显示的状态组成。在该阶段ECU按照integrator定义的状态机要求，从一个状态转换到另一个状态，从一个模式转换到另一个模式。
在使用ECU模式处理（ECU Mode Handling）的情况下，UP阶段包含默认模式。这些模式之间的转换是通过ECU状态管理器模块和BSW模式管理器模块之间的合作完成的。
注意: UP阶段包含一些以前的睡眠状态。从OS调度程序被锁定以防止其他任务在睡眠中运行的点，到使ECU进入睡眠状态的MCU模式已经退出的点。此时，模式管理设施不运行，ECU 管理器模块提供了唤醒处理的支持。
4.1、STARTUP阶段
STARTUP阶段的目的是将基础软件模块初始化到通用模式管理设施（Generic Mode Management facilities）可操作的点。
ECU管理器模块在调用EcuM_Init之前，假定MCU的最小化的初始化过程已经完成。也就是说堆栈已被设置，并且代码已经可以被执行，同时C语言中所有变量的初始化也已经被执行。
4.1.1、StartPreOS阶段
StartPreOS序列中的活动如下图：
可选列（Opt.），所有可选的活动都可以通过配置来被激活或关闭。
ECU管理器模块需记住复位原因转换产生的唤醒源，可参见StartPreOS Sequence表格。同时唤醒源必须由EcuM_MainFunction进行验证， WakeupValidation序列中的活动。
当功能通过EcuM_Init被激活时，ECU管理器模块会执行StartPreOS序列中的操作
StartPreOS序列旨在让ECU为初始化OS做好准备，所以执行时间应尽可能短。驱动程序应尽可能在UP阶段初始化，并且Callout函数也应保持简短。在此序列期间，中断不应被使用。如果必须使用中断，则StartPreOS序列中只允许使用I类（category I）的中断。
驱动程序和硬件抽象模块的初始化不是由ECU管理器来严格定义的。但ECU管理器提供了两个Callout函数EcuM_AL_DriverInitZero和EcuM_AL_DriverInitOne来定义初始化块 0和1。这些初始化块包含了与StartPreOS序列相关的初始化活动。
MCU_Init并不提供完整的MCU的初始化。此外与硬件相关的步骤必须被执行，并且必须在系统设计时被定义。这些步骤应该在EcuM_AL_DriverInitZero或者EcuM_AL_DriverInitOne两个Callout函数中进行。
ECU管理器模块需使用配置的默认关机目标（通过EcuMDefaultShutdownTarget配置）来调用EcuM_GetValidatedWakeupEvents接口。
StartPreOS序列为启动操作系统，需要完成初始化所需的所有基础软件模块。
4.2.2、StartPostOS序列
StartPostOS序列中的活动如下图：
可选列（Opt.），所有可选的活动都可以通过配置来被激活或关闭。
4.2、UP阶段
本质上，UP阶段开始于BSW调度程序启动并调用了BswM_Init函数。此时内存管理（memory management）尚未初始化，没有通信堆栈（communication stacks），没有 SW-C 支持（RTE）并且SW-C尚未启动。处理以特定的模式启动（在STARTUP之后配置的下一个模式），并具有相应的可运行项，如：BSW主程序（BSW MainFunctions），并继续作为模式更改的任意组合，导致BswM执行操作，同时触发和禁用相应的可运行项。
然而从ECU管理器模块的角度来看，ECU是已启动的。接着BSW模式管理器模块启动模式仲裁和所有进一步的BSW的初始化，启动RTE和隐式的启动SW-C成为在BswM的操作列表中被执行的代码，或由依赖模式的调度驱动，有效地在integrator的控制下。
接着初始化NvM模块并调用NvM_Readall，使其也成为集成代码的一部分。这也意味着integrator需负责在NvM_ReadAll结束时，触发Com、DEM和FIM的初始化。当NvM_ReadAll完成时，NvM将通知BswM。
注意： RTE可以在NvM和COM被初始化之后启动。同时通信堆栈无需在COM模块被初始化之前被完全初始化（fully initialized）。
这些更改将初始化BSW模块，并以任意顺序启动SW-C，直到ECU达到满负荷，并且这些更改也将继续决定ECU的功能。最终模式开关停止SW-C，并对BSW进行去初始化，以便在ECU达到可以关闭电源的状态时，UP阶段结束。
因此就ECU管理器模块而言，BSW和SW-C会一直运行，直到它们准备好，让ECU关闭或进入睡眠状态。
在UP阶段，EcuM_MainFunction会被定期执行。它主要具有三个功能：
检查唤醒源是否被唤醒，并在必要时启动唤醒验证。
·更新闹钟定时器（Alarm Clock timer）
·仲裁RUN和POST_RUN的请求和释放。
4.2.1、闹钟处理
当闹钟服务存在时（可参见参数EcuMAlarmClockPresent），EcuM_MainFunction需更新闹钟定时器。
4.2.2、唤醒状态处理
唤醒源不仅需在唤醒期间处理，而且与所有其他EcuM活动并行处理。相关功能在EcuM_MainFunction中运行，通过模式请求（mode requests）与ECU管理的其余部分完全分离。
唤醒源可以处理以下状态：
状态 | 描述 |
NONE | 唤醒事件未被检测到或已被清除 |
PENDING | 检测到唤醒事件但尚未验证 |
VALIDATED | 检测到唤醒事件并成功验证 |
EXPIRED | 检测到唤醒事件但验证失败 |
下图说明了唤醒源状态和引起状态变化的条件函数之间的关系。此处仅显示两个超级状态Disabled和Validation以进行说明和更好地理解。
当ECU管理器动作导致唤醒源的状态改变时，ECU管理器模块应向BswM发出模式请求（mode request），以将唤醒源的模式更改为新的唤醒源状态。对于这些唤醒源状态的通信，主要使用 EcuM_WakeupStatusType类型。
当ECU管理器模块处于UP阶段时，唤醒事件通常不会触发状态更改，但是它们会触发停止（Halt）和轮询（Poll）子阶段的结束。接着ECU管理器模块自动执行WakeupRestart 序列后，并随后返回到UP阶段。此行为需由集成商（integrator）在BswM中配置规则，以便ECU对唤醒事件做出正确反应。因为此反应完全取决于当前ECU的状态。
如果唤醒源有效，则BswM将ECU返回到运行（RUN）状态。如果所有唤醒事件都返回到NONE或EXPIRED，则BswM再次为基础软件模块准备SLEEP或OFF并调用EcuM_GoDownHaltPoll。
总结：
每个未决事件（pending event）都被独立验证（如果已配置），EcuM将结果作为模式请求发布到BswM，这反过来可以触发EcuM中的状态更改。
4.2.3、唤醒状态的内部表示
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位掩码表示，其中各个唤醒源对应于固定位位置。有5个预定义位的位置，其余的可以通过配置分配。更多详细信息，可参阅EcuM_WakeupSourceType的定义。
一方面，ECU管理器模块管理每个唤醒源的模式。另一方面，ECU管理器模块通过预先假定存在的内部变量（internal variables），即EcuM_WakeupSourceType的实例，来跟踪哪些唤醒源处于特定状态，特别是NONE（即已清除）、PENDING、VALIDATED和EXPIRED。ECU管理器模块在各自的接口定义中使用这些内部变量来定义接口的语义。因此，这些内部变量是否真的被执行是次要的，它们主要用于解释接口的语义。
4.2.4、WakeupValidation序列
由于唤醒事件可能会无意中产生，例如：CAN线路上的EVM尖峰，所以有必要在ECU恢复完全运行之前验证这些唤醒事件。
所有唤醒源的验证机制都是相同的。当唤醒事件发生时，ECU从SLEEP状态唤醒，并在MCU驱动程序的MCU_SetMode服务中恢复执行。当WakeupRestart序列完成时，ECU管理器模块将有一个待验证的唤醒事件列表。接着ECU管理器模块释放BSW调度器和所有BSW MainFunctions。最值得注意的是，在这种情况下EcuM Main Function可以恢复处理。
BswM需配置为通过EcuM的模式切换请求（mode switch requests）来监视唤醒验证，EcuM负责验证唤醒源或等待计时器的超时。如果最后一次验证，没有通过验证的情况下超时，则BswM需认为唤醒验证失败。如果有任意一个待定唤醒源被验证通过，那么整个验证需视为已通过。
ECU管理器模块可以选择提供单个的唤醒验证超时定时器，或者为每个唤醒源提供一个定时器。
ECU管理器模块需在EcuM_SetWakeupEvent函数被调用时，启动唤醒验证超时计时器。而EcuM_ValidateWakeupEvent函数需停止唤醒验证超时计时器的计时。
唤醒超时的时间设定可以通过参数EcuMValidationTimeout进行配置定义。
驱动程序在检测到唤醒事件时，必须调用EcuM_SetWakeupEvent一次。在调用时使用配置参数EcuMWakeupSourceId来作为EcuM_WakeupSourceType的参数，来标识指定的唤醒源。
4.3、SHUTDOWN阶段
SHUTDOWN阶段处理基础软件模块的受控关闭，最终导致选定的关机目标：关闭（OFF）或者复位（RESET)。
通过使用关机目标RESET或OFF调用EcuM_GoDownHaltPoll来启动SHUTDOWN阶段。
如果在关机阶段发生唤醒事件时，ECU管理器模块应完成关机并在此后立即重新启动。
4.3.1、OffPreOs序列
OffPreOs序列如下
在OffPreOS序列期间，如果配置参数EcuMIgnoreWakeupEvValOffPreOS设置为true，只需考虑那些不需要验证的唤醒事件，所有其他的唤醒事件可以忽略。如果配置参数EcuMIgnoreWakeupEvValOffPreOS设置为false时，不需要验证的唤醒事件和需要验证的待定唤醒事件都需被考虑到。
注意：
因为在OffPreOS序列期间，SchM已经去初始化，周期性执行的函数以及不被执行，所以不再可能验证唤醒源。在OffPreOS期间中，唤醒事件是否需要被考虑，取决于EcuMIgnoreWakeupEvValOffPreOS的配置。
作为OffPreOS期间的最后一项活动，ECU管理器模块需调用ShutdownOS函数。操作系统会在关机结束时，调用关机钩子（hook）函数。关闭钩子函数会调用EcuM_Shutdown来结束关机过程。 EcuM_Shutdown不应返回，而是直接关闭ECU或发起复位动作。
4.3.2、OffPostOs序列
OffPostOs序列如下
OffPostOS序列执行了在操作系统关闭后，达到关机目标的最后步骤。由EcuM_Shutdown函数发起此序列。关机目标可以是ECUM_SHUTDOWN_TARGET_RESET或ECUM_SHUTDOWN_TARGET_OFF，
当关机目标为RESET时，ECU管理器模块需调用EcuM_AL_Reset的Callout函数。当关机目标为OFF时，ECU管理器模块需调用EcuM_AL_SwitchOff的Callout函数。
4.4、SLEEP阶段
ECU在SLEEP阶段保持节能（saves energy）状态。通常不执行任何代码，但依旧会提供供电。如果进行了相应配置，则ECU在此状态下是可被唤醒的。ECU管理器模块提供了一组可配置的（硬件）睡眠模式，这些模式通常是在功耗和重启ECU所需时间之间进行权衡。
ECU管理器模块唤醒ECU，以响应预期或非预期的唤醒事件。由于非预期的唤醒事件需要被忽略，ECU管理器模块提供了一个协议来验证唤醒事件。该协议指定了处理唤醒源的驱动程序和ECU管理器之间的协作过程
可以通过SLEEP作为关机目标，调用EcuM_GoDownHaltPoll函数来启动SLEEP阶段。
使用SLEEP作为关机目标的EcuM_GoDownHaltPoll函数会启动两种控制流。具体哪种控制流取决于EcuMSleepModeSuspend参数所配置的睡眠模式。它们在实现睡眠的机制上的结构是不同。但是它们在准备睡眠和从睡眠恢复过程的顺序却是相同的。
同时存在另一个模块，可能是BswM，虽然它也可能是另一个SW-C。这个模块必须确保在调用EcuM_GoDownHaltPoll之前，以及选择了适当的ECUM_STATE_SLEEP的关机目标。
4.4.1、GoSleep序列
在GoSleep的序列中，ECU管理器模块需为即将到来的睡眠阶段进行相关的硬件配置，同时为下一个唤醒事件设置ECU。
ECU管理器模块为了接着的睡眠模式，需进行唤醒源的配置。ECU管理器模块会通过在EcuM_EnableWakeupSources的Callout函数中，依次为每个在EcuMWakeupSourceMask中配置的唤醒源执行相关的设置工作。
与SHUTDOWN阶段相比，ECU管理器模块在进入SLEEP阶段时，不应关闭操作系统。睡眠模式，即EcuM的SLEEP阶段和MCU模式的组合，对操作系统来说应该是透明的。
4.4.2、Halt序列
ECU管理器模块需在停止微控制器的睡眠模式下执行停止序列（Halt Sequence）。在这睡眠模式下，ECU管理器模块不执行任何代码。
ECU管理器模块应在停止微控制器之前，调用EcuM_GenerateRamHash的Callout函数。然后当处理器从停止状态返回后，调用EcuM_CheckRamHash的Callout函数（为了检查休眠前后RAM是否是一样的，不一样复位）。
如果存在多核的情况，且存在从属（Slave）的EcuM，则此检查动作仅只需在主（Master）的EcuM上执行。 主EcuM从其范围内的所有数据中生成散列。从属EcuM的私有数据不在此范围内。
逻辑依据：
当ECU长时间处于睡眠模式时，RAM内存可能会损坏。 因此需检查RAM存储器的完整性，以防意外行为的发生。系统设计者可以选择适当的校验和算法来执行检查。
4.4.3、Poll序列
睡眠模式下的轮询序列（Poll Sequence）可用于检查唤醒源。在轮询序列中，EcuMWakeupSourcePolling设置为True，EcuM需在一个阻塞循环中（blocking loop），调用EcuM_SleepActivity和EcuM_CheckWakeupHook函数，直到有待定（pending）或者已验证（validated）的唤醒事件被报告。
4.4.4、离开Halt或Poll
如果当ECU处于停止（Halt）或轮询（Poll）状态时，发生唤醒了事件。
唤醒硬线发生翻转变化（toggling a wakeup line）
CAN总线上有通讯信号（communication on a CAN bus）等
则ECU管理器模块需重新获得控制权，并通过执行唤醒重启序列（WakeupRestart sequence）退出睡眠阶段。
可以调用ISR来处理唤醒事件，但这取决于硬件和驱动程序的实现。如果ECU处于Halt或者Poll时，发生了不规则事件（Irregular Events）
硬件复位（hardware reset）
电源循环（power cycle）
则ECU管理器模块需在STARTUP阶段，重新启动ECU。
4.4.5、WakeupRestart序列
ECU管理器模块需调用用于重新初始化驱动程序的EcuM_AL_DriverRestart的Callout函数。其中具有唤醒源的驱动程序通常需要重新初始化。
在重新初始化（re-initialization）期间，驱动程序必须检查其一个分配的唤醒源是否是先前被唤醒的原因。如果该测试为真，驱动程序必须调用唤醒被检测到（wakeup detected）的回调函数。例如：参见CAN 收发器驱动程序规范[12]。而后者必须再调用EcuM_SetWakeupEvent函数。
驱动程序的实现应该只调用一次唤醒回调。此后它不应再次调用唤醒回调，直到它被显式函数调用重置（re-armed）。所以驱动程序必须重置后了，才能再次触发回调。
如果在WakeupRestart序列完成时，ECU管理器模块具有候选唤醒源的列表，则ECU管理器模块应在EcuM_MainFunction中验证这些候选唤醒源。
如果报告了WakeupEvent，EcuM需退出睡眠模式。如果所有WakeupSource的CheckWakeupTimer都已超时，则EcuM需转换到GoSleep状态，并再次开始让EcuM进入睡眠状态（暂停或轮询）。
注意：
当EcuM由异步WakeupSource恢复运行（resume）时，EcuM必须执行WakeRestart序列，以重新启动主功能，以便建立与使用的硬件（例如：SPI）的异步通信。
如果在信号唤醒后，并且相应的CheckWakeupTimer也已经超时，没有任何唤醒事件被设置，则EcuM需报告运行时错误ECUM_E_WAKEUP_TIMEOUT。
4.5、OFF阶段
下电时，ECU的状态为OFF状态。在此状态下ECU可能是可以被唤醒的，但仅适用于具有集成电源控制的唤醒源。在任何情况下，ECU都必须是可启动的。例如：通过复位事件（reset event）。
5、ECUM结构描述
上图说明了ECU 管理器模块与其他基础软件模块接口的关系。在大多数情况下，ECU管理器模块只负责初始化。 然而有些模块与ECU管理器模块具有功能关联。
6、闹钟
ECU管理器模块可以提供可选的持久化地时钟服务。此服务即使在睡眠期间，也能保持活动（active）状态。 因此，它能保证ECU在未来的某个时间被唤醒（假设硬件没有任何故障），并为长期活动提供时钟服务，支持可以小时、天、甚至年为单位地时间区间。
通常该服务将通过ECU中的定时器来实现，该定时器可以触发唤醒。但是，在某些情况下，外部设备也可以使用常规中断线来定期唤醒ECU。无论使用何种机制，服务都会私下使用一个唤醒源。
ECU管理器模块维护一个主闹钟，其值决定了ECU将被唤醒的时间。此外ECU管理器管理一个内部时钟，即EcuM时钟，用于与主闹钟进行比较。
注意：
闹钟唤醒机制仅与SLEEP阶段相关。SW-C和BSW模块可以在UP阶段（并且仅在UP阶段）设置和检索闹钟设定值，但是最终在SLEEP阶段被使用。
与其他计时/唤醒机制相比，可以使用通用ECU管理器模块设施来实现，闹钟服务在计时器到期之前并不会启动WakeupRestart序列。当时钟时间已超过警报时间，ECU模块检测到计时器已触发唤醒事件时，它会增加其计时器，接着返回睡眠状态。
当闹钟服务存在时（参见：EcuMAlarmClockPresent），EcuM管理器模块需维护一个EcuM时钟，其时间应为电池连接后的秒数。
EcuM时钟应在UP和SLEEP阶段跟踪时间。在硬件允许的情况下，ECU时钟时间不应由于ECU的复位而被重置。
系统应该有且只有一个唤醒源分配给了EcuM时钟（详见参见：EcuMAlarmWakeupSource）
在停止序列中，GPT驱动程序必须放在GPT_MODE_SLEEP中，以便只配置那些时间基数所需的计时器通道。它还需要GPT使用Gpt_EnableWakeup API来启用基于定时器的唤醒通道。最好将Gpt_StartTimer API设置为1秒。但如果无法设置此数值，则EcuM将需要更频繁地唤醒，以积累多个定时器唤醒，只有在时间累计1秒后，时钟才能增加1。
在轮询序列中，EcuM的时钟可以在EcuM_SleepActivity函数被调用期间，使用EcuM_SetClock函数定期更新。假设时间概念仍然可用。只有在时间累计1秒后，时钟才能增加1。
7、多核
BSW模块在不同分区上（partition）的分布。分区（partition）可以被看作是映射在一个内核（core）上的独立部分。所以每个核（无论是单核架构还是多核架构）都至少包含一个，但也可以包含任意多个分区。但是任何分区都不能跨越一个以上的内核。
BSW模块可以分布在不同的分区上，所以可以分布在不同的内核上。如BswM这类的一些BSW模块需包含在每个分区中。如OS或EcuM这类的一些其他模块需包含在每个内核的一个分区中。具体示例请参考下图。
在多核架构中，EcuM必须以某种方式分布，即：每个核存在一个实例。
一个用来引导加载程序（boot loader）指定的主内核通过EcuM_Init启动主EcuM（master EcuM）。 主EcuM负责启动一些驱动程序，确定Post Build配置，接着启动其他的内核及其所附属EcuM（Satellite EcuMs）。
每个EcuM现在启动内核的本地操作系统和内核的本地BswM（在每个分区中驻留一个BswM）。
如果在ECU的每个内核上执行相同的EcuM映像，则ECU管理器的行为必须在不同内核上有所不同。这可以由ECU管理器通过测试，确认它是在主内核还是从内核上，并采取适当的行动来完成。
ECU管理器模块在多核ECU上支持与传统ECU上相同的阶段（即：STARTUP、UP、SHUTDOWN和SLEEP）。
如果使用安全机制，ECU管理器模块必须以完全信任级别运行。
前面的ECU管理器术语来表示各种ECU状态，特别是Run / PostRun。通过灵活的ECU管理，系统集成商可以决定ECU的状态名称和语义。但是必须坚持确保去初始化阶段的方法。 所以这里使用的名称是不规范的。
主内核（Master Core）具体是哪个内核？它是由引导加载程序（boot loader）决定。主内核的EcuM作为第一个BSW模块启动，并执行初始化操作。接着才是通过其他EcuM模块，启动剩下的其他内核。
当所有内核都启动完成时，主内核会与每个附属EcuM（Satellite EcuM）一起初始化自身内核的本地OS和BswM模块。
操作系统提供了一种基本机制，用于同步主从内核上的操作系统启动。调度程序管理器（Scheduler Manager）为BSW模块跨分区边界（Partition Boundaries）的通信提供了基本机制。每个内核有一个BSW模式管理器负责启动和停止RTE。
关机同步示例：
在调用ShutdownAllCores之前，主ECU管理器模块需完成以下步骤：
·启动所有从ECU管理器模块的关机请求，
·必须等到所有模块都去初始化它们负责的BSW模块并成功关机动作。
主ECU管理器模块设置了一个可以被所有从模块读取的关机标志。EcuM为每个已配置的从内核激活随后的任务。从模块在其主程序中读取标志信息，并在请求时进行关机操作。任务（Task）的名称为EcuM_SlaveCore
实例：
首先先配置了三个EcuMPartitionRef实例，然后在调用EcuM_GoDownHaltPoll期间，将启动EcuM_SlaveCore1_Task和EcuM_SlaveCore2_Task。从模块在主程序（main routine）内读取的标志并在请求时关闭。
操作系统扩展了OSEK SetEvent的跨内核功能。一个内核上的任务（Task）可以等待另一个内核上的事件集（Event Set）。下图说明了如何应用在调用ShutdownAllCores之前的内核同步的问题（其中去初始化的详细信息被省略）。Set/WaitEvent函数接受一个位掩码（bitmask），该位掩码可用于指示各个从内核上的关闭就绪状态。来自从ECU管理器模块的每个SetEvent调用都将停止主ECU管理器模块的等待。所以主ECU管理器模块必须跟踪各个从内核的状态并设置等待，直到所有内核都注册已就绪。
如果调用者已经获取了资源（resource）或自旋锁（spinlock），则可以用GetEvent循环替换WaitEvent函数。
注意：
上图是主内核上的逻辑控制流示例。EcuM_GoDownHaltPoll API需要EcuM在每个内核上都提供。从内核上此函数的行为是需要特定实现的。
集成说明：
如果主从核之间的同步是通过SetEvent/WaitEvent的方式实现的，那么EcuM_GoDownHaltPoll将被BswM模块在其主函数任务的上下文中调用（模式仲裁需延迟处理）。这还需要主函数任务（the main function task）必须是扩展任务（extended task）。
如果您需要在多个内核上初始化一个模块，您必须将此模块添加到每个内核的特定的初始化列表中。同时也必须意识到，在这种情况下，可能存在从不同的内核并行调用init函数的情况，所以init函数需被定义为不可重入的。
8、ECUM模式处理
ECU状态管理器为SW-C提供接口以请求和释放RUN模式和可选的POST_RUN模式。
EcuMFlex对SW-C发出的请求和释放进行仲裁，并将结果传送给BswM。因为只有BswM可以决定何时可以转换到不同的模式，所以EcuM和BswM之间的合作是必需的。由于EcuM没有自己的状态机，EcuM依赖于BswM进行的状态转换，所以EcuM不请求状态。 此外EcuM将当前请求的仲裁通知BswM。当RTE执行完所有属于某个模式的Runnable时会通知BswM模块。
当EcuMModeHandling配置为true时，ECU模式处理需被使能。
当BswM通过EcuM_SetState设置了EcuM的状态时，EcuM需向RTE通知相应的模式变化。
当最后一个RUN请求已被释放时，ECU状态管理器模块应使用BswM_EcuM_RequestedState(ECUM_STATE_RUN, ECUM_RUNSTATUS_RELEASED)接口通知BswM模块。
如果SW-C在POST_RUN期间需要运行活动（例如：关机准备等），它必须在释放RUN请求之前，请求POST_RUN。否则，不能保证此SW-C有机会运行其 POST_RUN的代码。POST_RUN的状态为SW-C 提供了post run阶段，允许SW-C保存重要数据或者关闭相关外围设备。
当ECU状态管理器模块不处于SW-C请求的状态时，ECU状态管理器需使用BswM_EcuM_RequestedState接口通知BswM有关请求的状态。
当接收到第一个RUN或者POST_RUN请求时，ECU状态管理器模块需调用BswM_EcuM_RequestedState(ECUM_STATE_RUN, ECUM_RUNSTATUS_REQUESTED)接口通知BswM。
当最后一个POST_RUN请求也已经被释放时，ECU状态管理器模块需调用BswM_EcuM_RequestedState(ECUM_STATE_POST_RUN, ECUM_RUNSTATUS_RELEASED)接口通知BswM。
为防止ECU Mode的模式状态机实例滞后，以及EcuM和RTE状态不一致，EcuM可以使用确认反馈（acknowledgement feedback）来进行模式切换通知。
EcuM仅在RUN和POST_RUN切换时请求模式，SLEEP模式必须由BswM设置，因为EcuM没有关于何时可以进入此模式的信息。
状态 | 描述 |
STARTUP | 初始值。在调用Rte_Start时由Rte设置。 |
RUN | 当所有需要的BSW模块被初始化，BswM就会切换到此模式。 |
POST_RUN | 当没有RUN请求存在时，EcuM请求POST_RUN。 |
SLEEP | 当没有RUN和POST_RUN请求存在，且关机目标设置为SLEEP时，EcuM请求SLEEP模式。 |
SHUTDOWN | 当没有RUN和POST_RUN请求存在，且关机目标设置为SHUTDOWN时，EcuM请求SHUTDOWN模式。 |
EcuM需通过调用接口BswM_EcuM_CurrentState(EcuM_StateType State)通知BswM当前状态。当RTE通过确认端口给出反馈时，EcuM将设置一个新的状态。