AUTOSAR基础篇之EcuM
前言
当你看到ECU从启动状态至正常运行状态，再从正常运行状态至休眠或关闭的过程时，你是否曾想过以下一些问题呢？
ECU是怎么启动或关闭的呢？
ECU启动方式有没有一般规律呢？
按照AUTOSAR标准，ECU启动过程又可分为哪几个阶段呢？
。。。。。。
今天，我们来一起探讨并回答这些问题。为了便于大家理解，以下是本文的主题大纲：
正文
EcuM模块总体介绍
主要功能
EcuM模块作为AUTOSAR中的标准模块，全称为（ECU State Management）。故名思义，指的就是ECU 的状态管理，不过需特别强调的是ECU上下电流程的状态管理，具体可以简单概括为以下五个方面的内容：
Startup 初始化流程状态管理；
ECU运行状态管理；
ShutDown流程状态管理；
Sleep流程状态管理
Wakeup Source管理；
总状态机（Flexible 与 Fixed）
在具体介绍上述5个状态管理过程之前，我们有必要对ECU启动过程有个总体的感性认识，以便于对后续各个阶段的之间的关系有个较为清晰的了解。如下图1所示，描述了一般情况下ECU的启动流程。
图1 ECU一般启动流程
在上述的ECU启动过程中，可以看出ECU的一般启动过程涉及到Boot，C_Init, EcuM，OS等模块，在这些模块的共同接力下保证BSW及RTE成功初始化，进而使得整个SW-C处于正常running的过程。
ECU启动时，首先通过中断向量表运行引导程序（俗称BootLoader），Bootloader在满足一定条件下跳转至APP程序中的C_Init处并指向Main函数。
在Main函数中首先完成堆栈空间的初始化，然后调用EcuM_Init函数进入到后续的StartPreOS，StartOS阶段。
在开启OS的初始化函数中调用EcuM_StartupTwo进行第二启动阶段的初始化，最后就是进入StartPostOS阶段，如完成BswM模块的初始化，进而将控制权转交给BswM模块。
由于接力赛中首棒很关键，因此本文将重点关注EcuM模块的启动与关闭过程，按照AUTOSAR定义，EcuM可分为两种模式：Flexible与Fixed模式。
Flexible 总状态机，如下图2-1所示：
图2-1 EcuM Flexible 总状态机
在上图中，Startup阶段按照开始OS节点作为分水岭，可分为StartPreOS与StartPostOS两个阶段。经历过Startup阶段之后，则会进入到UP阶段。
在UP阶段则是正常运行状态，当条件满足时，可以根据CPU是否进入到低功耗状态还是OFF状态，相应进入到Sleep阶段与ShutDown阶段，当然如果是Reset，那么也是先进入到Shutdown阶段，最后跳转至Startup阶段。
若进入到Sleep阶段之后，也存在着两种CPU低功耗模式：Poll与Halt模式，后者比前者更节约电能且无需运行代码，具体采用哪个则可根据当初的系统设计而定。
在该阶段不会关闭OS，OS始终低功耗的running状态，同时也会不断的对唤醒源进行监控，若唤醒源满足，则会直接跳转至RUN阶段。
若进入到Shutdown阶段，会经历两个阶段：OffPreOS与OffPostOS阶段，前者则是为Shutdown OS之前所做的准备，后者则是关闭OS之后，选择对应的函数执行关闭ECU还是重启ECU的操作。
Fixed 总状态机,如下图2-2所示：
图2-2 EcuM Fixed 总状态机
在上图2-2中，较为清晰的描述了EcuM Fixed模式下五种状态Startup，Shutdown，RUN，Sleep，Wakeup的状态组成以及状态切换的过程，其中OFF，Sleep，RUN是稳态，而Startup跟Wakeup则是暂态。
在Startup阶段，同样按照Flexible 模式中开启OS为界限，分为Startup I与Startup II两个阶段；
当唤醒事件能够控制CPU供电时，则需要进入Wakeup阶段验证Wakeup Event是否有效，相反如果不带电源控制，则直接进入RUN阶段。
若进入到RUN阶段，可分为两个阶段：RUN II与RUN III两个阶段。其中RUN II指的是正常运行阶段，RUN III则是SW-C为即将进入到ShutDown所需要做的前提准备。
若进入到ShutDown阶段，首先会进入到PreShutDown阶段，然后按照Shutdown的目标不同，可以分为reset，OFF，Sleep三条路径。
如果Target为Sleep，则进入到Go Sleep阶段，若在该阶段检测到唤醒事件，那么直接跳转至Wakeup Validation阶段。
如果Target为OFF或Reset，则需经历Go OFF I与Go OFF II两个阶段，reset则会重新跳转至Startup阶段，而OFF则是直接关闭ECU。
若进入到Wakeup阶段，则需要进行四个阶段的唤醒源验证，主要分为Wakeup I，Wakeup Validation，Wakeup Reaction，Wakeup II阶段；
若进入到Sleep阶段，则可以分为两种Sleep模式：Sleep I 与Sleep II，一般两者选其一。其中Sleep I阶段（Halt），此阶段不运行代码， 等待唤醒事件，然后跳转至Wakeup阶段；
其中Sleep II阶段则为Polling阶段，这个阶段则会低功耗运行代码，并且等待唤醒事件，如果存在，则进入到Wakeup阶段。
Fixed与Flexible模式区别与联系，从上述EcuM Fixed Mode与Flexible Mode的描述，便可知两者存在着很多的相似点，同时也存在着彼此之间的差异，因此小T我将两者的区别与联系展现如下表1所示：
表1 EcuM Fixed与Flexible模式区别与联系
由上分析可知，EcuM Flexible可以兼容Fixed模式，是传统ECU的启动过程的扩展，也可理解Flexible是Fixed模式的更高一层抽象，Fixed则可以称作Flexible模式的一种表现形式。
同时Fixed模式明确了各个阶段的状态及状态切换过程，而Flexible则更为灵活，可以实现多核启动，局部快速启动等特性，为了更好的了解Flexible模式的启动思想，本文将以重点介绍Fixed模式下各状态机的状态机及切换过程，举一反三。
按照EcuM的主体功能，对应的将从以下五个过程来展开讲解EcuM Fixed Mode下的各状态机状态及状态切换过程。
Startup Sequence : 完成启动过程的初始化；
Run Sequence ：正常运行及退出运行状态阶段
ShutDown Sequence：shutdown 或Reset ECU的阶段；
Sleep Sequence：ECU休眠阶段;
Wakeup Sequence: ECU 验证唤醒源阶段；
Startup Sequence
STARTUP阶段的目的就是初始化基础软件模块，主要可分为两个阶段：启动OS之前的初始化以及启动OS之后的初始化，如下图3所示，为Startup Sequence的顶层设计。
图3 Startup Sequence顶层设计
STARTUP I
如上图3所示，通过调用EcuM_Init函数则进入到STARTUP I阶段，在该阶段主要会调用下列两个Callout函数完成OS启动前的初始化工作；
EcuM_AL_DriverInitZero：完成无需OS支持的底层硬件驱动的初始化或者其他低水平的初始化（无需postconfig），将这部分驱动的初始化称为Init Block 0；
EcuM_AL_DriverInitOne：完成无需OS支持的底层硬件驱动的初始化或者其他低水平的初始化，将这部分驱动的初始化称为Init Block 1;
STARTUP II
在STARTUP II阶段则是在start os函数中调用EcuM_AL_DriverInitTwo ，随后开启RTE，最后调用函数EcuM_AL_DriverInitThree最后初始化那些需要NVM数据的BSW模块。
EcuM_AL_DriverInitTwo ：需要OS支持但是无需使用NVM的BSW模块初始化，并将此部分驱动的初始化称为Init Block II；
EcuM_AL_DriverInitThree：需要OS支持同时也需要使用NVM的BSW模块初始化，并将此部分驱动的初始化称为Init Block III；
特别需要注意的是，STARTUP 1主要用于为start OS而作的驱动函数初始化，启动时间应当尽可能短，而START UP II尽可能完成所有所需模块的初始化。
且中断一般不允许在startup I阶段使用，如果需要使用，也只能使用Category I，不能使用Category II。
为了加深大家对Startup两个阶段的驱动模块初始化的认识与理解，特此将其总结如下表2所示：
表2 StartUp阶段驱动初始化列表
RUN Sequence
RUN阶段可以划分为以下两个阶段，一个是RUN II，表示正常工作状态，另一个是RUN III，表示为进入到ShutDown所作的前提准备，顶层设计如下图4所示：
图4 RUN Sequence顶层设计
RUN II
在RUN I阶段则表明已完成了所有BSW模块（包括OS及RTE）的初始化，开始运行SW-C程序。在该阶段，将主要完成以下几种操作：
通过调用函数ComM_CommunicationAllowed来使得相应的通信通道允许通信；
在该阶段，EcuM将允许保持一个最小的运行事件EcuMRunMinimumDuration，以便让SW-C有机会向EcuM模块请求RUN Request；
在该阶段也需要进行休眠总线的唤醒源验证工作；
除非没有通信请求，否则ComM不会释放RUN Request，也就不会退出RUN II阶段；
RUN III
当最后一个Run Request被释放之后，EcuM就会进入到RUN III阶段（即Post RUN 阶段）。在PostRUN主要完成以下几种操作：
在RUN III阶段，如果Sw-C请求PostRun，那么就会停留在该状态，SW-C可以运行其相应的代码如存储重要的数据等，直至释放PostRun Request；
若在该阶段存在RUN Request，那么就会立刻跳回到RUN II阶段；
若既不存在RUN Request，也不存在PostRun Reqest，那么就会直接进入到ShutDown阶段中的PreShutdown阶段；
ShutDown Sequence
在ShutDown阶段，主要根据ShutDown Target不同而进入不同的状态机处理流程。如下图5所示，总体上体现了根据Target不同而做出的不同状态机处理。
图5 ShutDown Sequence顶层设计
从上图可知，不管ShutDown Target是什么，都会经历PreShutdown阶段，进入到该阶段，主要完成以下操作：
De_Init所有的SW-C，同时保证通信协议栈处于关闭状态。
清除所有的Wakeup Event；
关闭Dem模块；
根据不同的ShutDown目标进入不同的状态（Sleep或者OFF或者Reset）；
ShutDown Target
在ShutDown阶段，ShutDown Target非常重要，因为其决定了ShutDown阶段应当走何种路线。ShutDown Target可分为以下三种：
OFF：CPU掉电；
RESET：这属于一个暂态，CPU Reset；
Sleep：CPU处于低功耗状态，未掉电；
默认的ShutDown Target可以通过配置得到，当然SW-C可以直接调用函数接口 EcuM_SelectShutdownTarget来覆盖掉默认的ShutDown Target。
Go Sleep
当ShutDown Target为Sleep时，那么就会进入到Go Sleep阶段，在该阶段主要完成以下操作：
调用NvM_WriteAll函数完成写操作，同时开启NVM写超时计数器；
调用函数EcuM_EnableWakeupSources使能Wake up事件接收；
在该阶段，OS并没有关闭，处于正常Running状态；
若此阶段存在Pending Wakeup Event，则直接调用函数NvM_CancelWriteAll取消写操作，然后直接跳转Wakeup阶段的Wakup Validation子状态；
当Nvm_WriteAll成功执行完或者写超时，则直接进入到Sleep阶段；
Go OFF I
当ShutDown目标为OFF或者RESET时，则首先进入到该状态。在该阶段，主要完成以下几种操作：
仅设置LIN的通信状态为FALSE；
完成ComM，BswM的Deinit操作；
调用NvM_WriteAll函数完成写操作，并开启写超时计数器；
等待NvM写成功或者NvM写超时，调用函数ShutdownOS关闭OS；
在ShutDown OS的过程中通过shutdown hook函数调用EcuM_ShutDown来进入OFF II阶段；
Go OFF II
当ShutDown Target为OFF或者RESET时，经过OFF I阶段就会最终调用EcuM_ShutDown进入到该阶段，在该阶段，主要完成以下几种操作：
如果ShutDown Target是OFF，则调用Callout函数EcuM_AL_SwitchOff来直接断掉CPU供电；
如果ShutDown Target是RESET，则调用Callout函数EcuM_AL_Reset进而调用MCAL标准函数Mcu_PerformReset来重启CPU；
Sleep Sequence
当ShutDownTarget为Sleep，经历了Go Sleep阶段后，便会直接进入到Sleep阶段，Sleep阶段的总体流程如下图6所示：
图6 Sleep Sequence顶层设计
如果所有的RUN Request没有被释放，则不会进入到Sleep阶段，也就意味着进入到Sleep阶段了，表示当前已没有RUN Request。
在进入Sleep状态之前，EcuM模块应当将所有的通信接口处在Standby状态，且需要使能必要的Wakeup Source。
进入到Sleep模式后，可以选择MCU Halt模式，等待Wakeup Event触发，也可以选择Polling模式，主动查找当前有无唤醒事件，两者根据系统设计选择其中一种即可。
Sleep I
在Sleep I阶段，即Halt模式，在该低功耗模式下，无需运行代码，但需要存在某种CheckSum算法来保证唤醒前后RAM空间的数值不会遭到破坏。
即通过调用EcuM_GenerateRamHash生成对应的Hash值，接收到唤醒事件后，则调用EcuM_CheckRamHash来完成前后RAM一致性检查。
若一致，则进入到Wakeup阶段，若不一致，则调用Dem模块的Event ID来上报故障并触发重启来保证安全。
Sleep II
在Sleep II阶段，即Polling模式，在该低功耗模式下，会降低系统时钟频率来运行代码，并实时检查有没有相应的唤醒源。
通过调用Callout函数EcuM_SleepActivity以及EcuM_CheckWakeup来检查是否存在唤醒源。
Wakeup Sequence
如上图2-2所示，无论是在Go Sleep阶段还是Sleep阶段或者是带有电源控制的唤醒阶段，如果监测到Wakeup Event就会进入到该阶段，目前Wakeup Sequence可以分为以下四个基本阶段：
Wakeup One：
Wakeup Validation
Wakeup Reaction：
Wakeup Two：
如下图7为Wakeup Sequence的总体流程图：
图7 Wakeup Sequence顶层设计
Wakeup I
当从Sleep状态进入到Wakeup阶段时，首先进入到Wakeup I阶段，在Wakeup I阶段主要完成以下几种操作：
设置MCU模式为Normal Mode；
抑制当前pending的Wakeup Event；
调用函数EcuM_AL_DriverRestart重新启动驱动，主要初始化Block I与Block II；
使能Run Reqest以及PostRun Request；
解锁Scheduler并可能重新运行OS；
Wakeup Validation
当从Go Sleep或者通过待电源控制的唤醒条件下启动时，则会进入到该阶段，在该阶段主要会进行以下操作：
获取当前Pending Wakeup Event并调用函数EcuM_ValidateWakeupEvent开启验证；
如果validate超时，则可以通过调用函数EcuM_StopWakeupSources停止验证工作；
在该阶段，存在以下5种唤醒源在任何时刻都无需验证：
WKSOURCE_POWER；
WKSOURCE_RESET
WKSOURCE_INTERNAL_RESET；
WKSOURCE_INTERNAL_WDG ；
WKSOURCE_EXTERNAL_WDG；
Wakeup Reaction
经过Wakeup Validation阶段后，肯定会进入到该阶段，在该阶段主要会进行以下几个操作：
根据event Validation之后的结果选择进入不同的阶段，一种是验证有效，进入RUN II阶段，另外一种是验证无效，进入Go Sleep阶段；
Wakeup II
当经过Wakeup Reaction之后，如果验证成功就会进入到该阶段，在该阶段主要完成以下几类操作：
如果是从Sleep阶段跳转至该阶段，则首先要调用Dem_Init函数来完成Dem模块初始化，因为是新一轮operation cycle；
如果是从Startup阶段跳转至该阶段，则可能需要等待NvM readall操作完成；
最后可直接跳转至RUN II阶段直接运行；
常用函数接口
为了更好的使用该模块函数以及遇到问题时方便调试该模块，特将BswM模块中较为重要的常用函数列举如下表3所示。
表3 EcuM模块常用函数列表