在CP AUTOSAR架构中定义了许多和模式管理相关的组件，其中主要包括EcuM、BswM、ComM等。
在CP AUTOSAR 标准更新许多版本中，和ECU控制相关的模式管理模块EcuM主要包括两种类型，分别是Fixed和Flex，其中在CP AUTOSAR标准4.x之前的版本EcuM只有Fixed模式，而4.x之后出现了Flex模式，这两个模式都是在一些Common模式基础上增加了一些自己独有的功能。
Fixed模式下，有一组固定的ECU状态和它们之间的转换，对于没有特殊要求的常规ECU来说就足够了,Fixed模式下EcuM处理整个ECU状态切换，而Flex下主要通过BswM的Rules和Action中完成ECU状态的切换。本篇主要对EcuM的Flex模式管理做介绍。
EcuM的主要作用是初始化BSW的各个模块；协调芯片MCAL相关模块的初始化；开启OS；进行初运行、睡眠、唤醒等模式的状态切换；执行ECU的关机和复位；检验唤醒事件等。在EcuM中要定义系统的下电方式、唤醒源、多核上下电模式处理等。Flex EcuM下大多数ECU状态不再在EcuM模块本身中实现。通常EcuM模块接管控制早期STARTUP阶段和后期SHUTDOWN阶段。在EcuM的启动阶段后BswM负责进一步的操作,EcuM模块仲裁来自SWCs的Run和PostRun请求，并通知BswM模式的状态。Run协议是EcuM中建立的一种方法，用于确定ECU应保持活动状态还是准备关闭。Flex EcuM支持部分或快速启动、多核操作状态（多核运行状态）,Fixed ECU管理不支持多核ECU。
配置不同的唤醒源
配置OS启动前的BSW模块的初始化
User初始化代码集成
通知BswM相关的唤醒源
分配Com通道的唤醒源
Com通道唤醒时，通知ComM相关的唤醒源
配置休眠模式
选择Shutdown的原因和目标
支持多核EcuM协调多核的模式转换
Run、PostRun模式请求
通知SWC当前的模式
在EcuM的Flex模式下，EcuM的状态比较灵活，一般没有标准的状态和模式转换，用户可以根据自己的需要定义相关的状态，在EcuM Mode Handling使能后，RUN以及PostRUN的模式转换可以在BswM的仲裁机制中实现。Flex模式下的EcuM的状态也主要在BswM中实现，但是在EcuM中对模式管理的阶段作了定义，主要包括四个阶段，分别是STARTUP、UP、SLEEP、SHUTDOWN。整个阶段如下所示：STARTUP阶段主要完成Mcal主要模块的初始化工作，使得Mcal的模块能够满足后续功能的使用，在该阶段主要分为OS启动前的初始化和OS启动后的初始化。其中OS启动前的初始化主要分为两个阶段InitZero和InitOne，其中InitZero主要负责Det或者Dem的初始化，保证在后续的过程中，如果发生初始化的错误，开发集成人员可以确认；InitOne主要用于完成OS启动前必要的模块的初始化，主要是MCU初始化、时钟初始化、内存的初始化、Port、GPT、WDG、ADC等初始化等，经过Ecu这两个阶段的初始化后，OS就可以启动了。OS启动后，进入STARTUP最后阶段的初始化，完成相关模块的初始化，主要包括BswM、SchM等，程序就可以正常的调度了。初始化的时序图如下所示：UP阶段EcuM主要作用是进行唤醒相关的功能的验证，对于唤醒的验证和Power、Reset、WDG相关的唤醒功能不进行validation，对于其他的唤醒源，比如CAN唤醒、LIN唤醒等需要进行唤醒源的验证，验证也会对Timeout进行监控，如果检测到唤醒事件，但是验证无效或者超时发生，仍然视为唤醒失败。UP阶段主要负责对唤醒的验证工作，SLEEP阶段主要进行唤醒查询，最终唤醒相关的使能和状态转换在BswM中统一根据定义的Rule和Action进行转换和管理。在该阶段会周期的调用EcuM的MainFunction，由于Flex模式的状态切换主要依靠BswM进行仲裁，因此在UP阶段，EcuM的功能比较少，考虑到与APP层的模式转换和交互，在EcuM中会对RUN和PostRUN的请求与APP层的模式管理进行交互，根据APP层的模式管理，可以在BswM中设置RUN以及PostRUN请求和释放交互接口的数目，实现APP层模式管理与BSW层模式管理的协调。在EcuM的Shutdown的Target为Sleep的时候，程序执行转换的时候便会调用EcuM_GoDownHaltPol根据选择的Sleep模式选择进入到Halt还是Poll的Sleep子模式。在Poll模式下，此时EcuM能够继续执行相关的代码，此时的MCU处于低功耗的模式，此时主要轮询相关的唤醒状态，是否有唤醒的命令发生；在Halt模式下，EcuM不在执行任何代码，此时MCU已经被Halt。同样在EcuM在Sleep的Halt模式下等待唤醒信号的到来，一旦唤醒信号到来，无论是Sleep还是Halt模式，都会导致EcuM进入到正常的操作模式，下图展示了EcuM在Halt模式下，等待Gpt唤醒时间到来，ECU重新正常工作的过程。SHUTDOWN阶段主要对ECU的下电进行管理，Shutdown阶段处理的主要是Shutdown Target类型为RESET和OFF的两种模式。在进入到Shutdown的时候同样存在两个阶段，分别是PreOS阶段下电和PostOS下电阶段，对于Reset模式下电，一般调用Mcu_PerformReset相关的函数进行软件复位，在PreOS下电前阶段主要进行BswM的DeInit、SchM的禁用、做最后相关的唤醒Check，检测是否还有存在有效的唤醒。在PostOs下电阶段RESET模式一般执行的软件复位，这种情况主要是软件运行出现了相关的错误（WdgM程序监控出错）或者DCM请求等使用；OFF模式将ECU彻底的下电，进入到断电模式。
EcuM支持多核的使用，在多核使用的过程中，一般会在主核，也就是默认的启动核（比如Aurix系列的主核就是Core0）内完成一些基本的初始化工作，然后主核启动从核的运行，一般从核启动后启动自己相关OS，进行程序的调度管理。通常而言，在CStart代码中会做主核和从核相关的启动引导程序，对于主核启动从核后，可以在Rte启动调度前根据需要做多核启动OS执行的同步机制。然后所有核的OS正常运行后，每个核都有自己的EcuM的MainFunction用于管理自己核的运行。在下电阶段，主核通过EcuM的MainFunction设置相应的Flag，然后从核执行下电，并将结果告诉主核，主核协调同步多核的下电。最终，主核完成整个ECU下电的工作，主要是进入到OFF模式。多数情况下MCU在使用的时候一般都会使用相关的SBC芯片，因此在EcuM的Shutdown Target中直接选择对应的OFF模式就可以。在使用了外部的SBC控制相关的MCU的下电的时候，在OFF阶段最后调用SBC进入到Sleep的指令。在MCU走最后的下电，让外部的SBC休眠流程的时候一定要确保SBC唤醒相关的引脚没有高电平，否则操作SBC进入休眠会导致SBC相关的错误。在APP层可以添加相关的模块单独做ECU的唤醒检测，并不需要使用EcuM内部的唤醒功能做，也可以基于两者设计唤醒相关的检测机制。APP中也可以定义模式管理模块来协调BSW的模式管理，同时管理APP层的各个模块状态切换和运行。在多核下电的时候，一定要让对核进行GetCoreID的判断，保证主核进入到最终的下电操作。EcuM_OnGoOffTwo和EcuM_AL_SwitchOff可以直接使用一个实现，并不一定完全使用CP AUTOSAR定义的这两个下电流程。对于RESET的Shutdown Target可以不要做，直接做成OFF，然后根据相关的功能（DCM请求、程序流监控出错、内存相关的权限监控出错等）使用直接调用Mcu_PerformReset相关的函数执行RESET操作。本期分享就到这里，欢迎大家一起交流学习，如果有不合理的地方也请大家指正，愿和大家一起学习进步，一步步做好汽车电子软件开发。
