前言
当你看到ECU从启动状态至正常运行状态,再从正常运行状态至休眠或关闭的过程时,你是否曾想过以下一些问题呢?
- ECU是怎么启动或关闭的呢?
- ECU启动方式有没有一般规律呢?
- 按照AUTOSAR标准,ECU启动过程又可分为哪几个阶段呢?
- 今天,我们来一起探讨并回答这些问题。为了便于大家理解,以下是本文的主题大纲:
主要功能
EcuM模块作为AUTOSAR中的标准模块,全称为(ECU State Management)。故名思义,指的就是ECU 的状态管理,不过需特别强调的是ECU上下电流程的状态管理,具体可以简单概括为以下五个方面的内容:
- Startup 初始化流程状态管理;
- ECU运行状态管理;
- ShutDown流程状态管理;
- Sleep流程状态管理
- Wakeup Source管理;
总状态机(Flexible 与 Fixed)
在具体介绍上述5个状态管理过程之前,我们有必要对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模式。
- 在上图中,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的操作。
清晰的描述了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之后的初始化
STARTUP I
通过调用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所作的前提准备
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不同而做出的不同状态机处理。
不管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阶段的总体流程
如果所有的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
无论是在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模块常用函数列
免责声明:本文系网络转载或改编,未找到原创作者,版权归原作者所有。如涉及版权,请联系删