CN115442768A - 一种车载tbox通讯模组异常唤醒监控方法 - Google Patents
一种车载tbox通讯模组异常唤醒监控方法 Download PDFInfo
- Publication number
- CN115442768A CN115442768A CN202110620867.7A CN202110620867A CN115442768A CN 115442768 A CN115442768 A CN 115442768A CN 202110620867 A CN202110620867 A CN 202110620867A CN 115442768 A CN115442768 A CN 115442768A
- Authority
- CN
- China
- Prior art keywords
- awakening
- abnormal
- communication module
- vehicle
- wake
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000002159 abnormal effect Effects 0.000 title claims abstract description 158
- 238000004891 communication Methods 0.000 title claims abstract description 138
- 238000000034 method Methods 0.000 title claims abstract description 38
- 238000012544 monitoring process Methods 0.000 title claims abstract description 24
- 230000005059 dormancy Effects 0.000 claims abstract description 18
- 238000001514 detection method Methods 0.000 claims abstract description 9
- 230000007958 sleep Effects 0.000 claims description 40
- 230000006870 function Effects 0.000 claims description 21
- 230000002618 waking effect Effects 0.000 claims description 12
- 230000008439 repair process Effects 0.000 claims description 9
- 230000001960 triggered effect Effects 0.000 claims description 8
- 208000019116 sleep disease Diseases 0.000 claims description 6
- 230000004622 sleep time Effects 0.000 claims description 3
- 238000012545 processing Methods 0.000 description 9
- 230000008569 process Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 7
- 230000008859 change Effects 0.000 description 4
- 230000005856 abnormality Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 241000282326 Felis catus Species 0.000 description 1
- 230000037007 arousal Effects 0.000 description 1
- 230000001351 cycling effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000035772 mutation Effects 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000006641 stabilisation Effects 0.000 description 1
- 238000011105 stabilization Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
- H04W4/48—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/04—Arrangements for maintaining operational condition
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
- H04W52/02—Power saving arrangements
- H04W52/0209—Power saving arrangements in terminal devices
- H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Measurement Of The Respiration, Hearing Ability, Form, And Blood Characteristics Of Living Organisms (AREA)
Abstract
本发明提供一种车载TBOX通讯模组异常唤醒监控方法，包括，步骤S1，检测车载TBOX通讯模组的工作状态；其中，所述工作状态包括上电、下电、休眠及唤醒；步骤S2，根据车载TBOX通讯模组的工作状态通过预设的异常唤醒判断规则确定AP核是否产生异常唤醒故障；步骤S3，当AP核产生异常唤醒故障时，根据预设的异常场景检测规则确定异常唤醒场景；其中，所述异常唤醒场景包括长时间异常唤醒或频繁异常唤醒；步骤S4，根据异常唤醒场景通过预设的异常唤醒修复规则对异常唤醒故障进行修复处理，直到故障解除为止。本发明能够高效降低TBOX在异常情况下的整机功耗，可以高效解决TBOX由于通讯模组长时间或频繁异常唤醒导致整车馈电的痛点。
Description
技术领域
本发明涉及车载TBOX技术领域，特别是涉及一种车载TBOX通讯模组异常唤醒监控方法。
背景技术
TBOX(Telematics BOX，车载网联终端)产品主要包含MCU(微控制单元，Microcontroller Unit)和通讯模组两大部分，其中通讯模组主要由Modem核和AP(application process)核组成，AP核运行Linux操作系统。当TBOX休眠稳定之后，整机平均功耗在5mA/12V以内，此时MCU和通讯模组的AP核都处于休眠状态，这两者功耗微乎其微；而为了维持远程控制功能，Modem核还会保留搜网/驻网、短信/振铃/数据业务等网络相关功能，Modem核消耗了绝大部分整机功耗。但在一些异常情况，比如无网络、限制服务、基站切换、制式频繁切换之类的网络异常或硬件异常等情况，Modem核会主动唤醒AP核并把这些异常通知AP核，此时整机功耗会增加到40mA/12V左右，对于5G TBOX产品甚至达到100mA/12V以上。由于整车蓄电池在休眠工况的使用时长设计值基本都在30天以上，如果AP核长时间或者频繁维持异常唤醒状态，蓄电池实际休眠使用时长将远远达不到设定值。
因此，如何设计出一种自动化检测通讯模组AP核异常唤醒并做出相应低功耗处理的方法，降低TBOX功耗进而降低整车馈电风险，几乎是全部TBOX产品开发者面临的技术难题。现有技术中关于监测通讯模组长时间或者频繁维持异常唤醒状态并采取相应处理方法来降低TBOX功耗的方案仍处于空白状态。
发明内容
本发明的目的在于，提出一种车载TBOX通讯模组异常唤醒监控方法，解决现有方法无法有效降低TBOX在异常情况的休眠功耗，进而影响整车馈电风险的技术问题。
一方面，提供一种车载TBOX通讯模组异常唤醒监控方法，包括以下步骤：
步骤S1，检测车载TBOX通讯模组的工作状态；其中，所述工作状态包括上电、下电、休眠及唤醒；
步骤S2，根据车载TBOX通讯模组的工作状态通过预设的异常唤醒判断规则确定AP核是否产生异常唤醒故障；
步骤S3，当AP核产生异常唤醒故障时，根据预设的异常场景检测规则确定异常唤醒场景；其中，所述异常唤醒场景包括长时间异常唤醒或频繁异常唤醒；
步骤S4，根据异常唤醒场景通过预设的异常唤醒修复规则对异常唤醒故障进行修复处理，直到故障解除为止。
优选地，在步骤S2中，所述预设的异常唤醒判断规则，具体包括：
当AP核完成上电后，初始化监控函数并通过异步IO方式监听休眠或唤醒事件；
通过执行shell指令方式实时截取内核日志并保存到存储器的对应目录；
通过执行shell指令方式更改内核日志打印级别，开启唤醒源打印和ipc消息内容打印开关；
当AP核处于休眠状态下，出现自动唤醒且触发监控函数时，设置不进入自动休眠，并获取上一次状态信息、当前状态信息；其中，若当前状态信息是休眠状态，则判定车载TBOX通讯模组休眠成功，执行应用层休眠操作；
根据获取的上一次状态信息和当前状态信息确定AP核产生异常唤醒或属于正常的唤醒。
优选地，在步骤S2中，所述根据获取的上一次状态信息和当前状态信息确定AP核产生异常唤醒，具体包括：
若当前状态是唤醒状态，则获取唤醒控制管脚状态；若唤醒控制管脚状态是低电平，则获取各唤醒源的唤醒状态且通过检索关键字解析所述内核日志确定各唤醒源对应的唤醒类型；其中，所述唤醒类型包括正常或异常。
优选地，在步骤S2中，所述根据获取的上一次状态信息和当前状态信息确定AP核属于正常的唤醒，具体包括：
若唤醒控制管脚状态是高电平，则判定MCU将车载TBOX通讯模组唤醒，AP核属于正常的唤醒。
优选地，在步骤S3中，所述预设的异常场景检测规则，具体包括：
当AP核休眠之后出现自动唤醒，唤醒源的唤醒类型为异常且唤醒持续时间超过异常时间阈值时，判定异常唤醒场景为长时间异常唤醒。
优选地，在步骤S3中，所述预设的异常场景检测规则，具体还包括：
当AP核休眠之后出现自动唤醒，唤醒源的唤醒类型为异常且在预设的异常时间阈值内再次休眠后，又多次出现自动唤醒-休眠循环时，判定异常唤醒场景为频繁异常唤醒。
优选地，在步骤S4中，所述预设的异常唤醒修复规则，具体包括：
当异常唤醒场景为长时间异常唤醒时，启动计时器并等待AP核休眠；
若车载TBOX通讯模组一直保持唤醒，导致计时器超时，则停止并清空计时器，重新获取唤醒控制管脚状态，根据唤醒控制管脚状态进行修复。
优选地，在步骤S4中，所述预设的异常唤醒修复规则，具体还包括：
若唤醒控制管脚状态是高电平，则判定车载TBOX通讯模组是由MCU唤醒的，属于正常唤醒，继续等待AP核休眠；
若唤醒控制管脚状态是低电平，则读取当前重启次数值；
将当前重启次数值与最大重启次数值比较，若当前重启次数值大于等于最大重启次数值，则唤醒MCU并与车载TBOX通讯模组建立spi通讯，将重启次数值清零，通过spi通讯管脚通知MCU对车载TBOX通讯模组进行下电操作；
若当前重启次数值小于最大重启次数值，则唤醒MCU并建立spi通讯，将重启次数值加一，通过spi通讯管脚通知MCU对车载TBOX通讯模组进行重启；
当重启之后对车载TBOX通讯模组休眠成功时，将重启次数值清零。
优选地，在步骤S4中，所述预设的异常唤醒修复规则，具体还包括：
当异常唤醒场景为频繁异常唤醒时，通过创建/遍历链表进行寻找/添加唤醒源，将相应的唤醒计数器加一；并启动计时器等待AP核休眠；
当AP核在预设休眠时间阈值内进入休眠状态后，又自动唤醒时，重复执行通过创建/遍历链表进行寻找/添加唤醒源，将相应的唤醒计数器加一；
当某一唤醒源的唤醒次数大于等于最大频繁唤醒次数时，停止并清空计时器；
当某一异常唤醒源的唤醒类型等于禁止的Modem服务事件唤醒时，执行飞行模式操作，将飞行模式总次数加一并等待休眠；
当某一异常唤醒源的唤醒类型不等于禁止的Modem服务事件唤醒，或者多次执行飞行模式之后，还出现频繁唤醒时，获取当前重启次数值；将当前重启次数值与最大重启次数值比较，若当前重启次数值大于等于最大重启次数值，则唤醒MCU并与车载TBOX通讯模组建立spi通讯，将重启次数值清零，通过spi通讯管脚通知MCU对车载TBOX通讯模组进行下电操作；若当前重启次数值小于最大重启次数值，则唤醒MCU并建立spi通讯，将重启次数值加一，通过spi通讯管脚通知MCU对车载TBOX通讯模组进行重启；当重启之后对车载TBOX通讯模组休眠成功时，将重启次数值清零。
优选地，在步骤S4中，所述预设的异常唤醒修复规则，具体还包括：
当检测到当前唤醒源属于正常唤醒时，遍历链表把所有元素的异常唤醒源类型唤醒的总次数和执行飞行模式的总次数清零。
综上，实施本发明的实施例，具有如下的有益效果：
本发明提供的车载TBOX通讯模组异常唤醒监控方法，针对TBOX通讯模组AP核长时间异常唤醒和频繁异常唤醒两大常见场景的自动化监测和处理流程，能够高效降低TBOX在异常情况下的整机功耗，填补现有技术在这两大场景的空白。且适用于不同品牌的3G/4G/5G通讯模组，可以高效解决TBOX由于通讯模组长时间或频繁异常唤醒导致整车馈电的痛点。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，根据这些附图获得其他的附图仍属于本发明的范畴。
图1为本发明实施例中TBOX硬件连接示意图。
图2为本发明实施例中一种车载TBOX通讯模组异常唤醒监控方法的主流程示意图。
图3为本发明实施例中异常唤醒的判断示意图。
图4为本发明实施例中长时间异常唤醒的修复示意图。
图5为本发明实施例中频繁异常唤醒的修复示意图
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。
如图1所示，为本发明提供的TBOX硬件连接示意图，主要包括通讯模组、MCU和emmc存储器。其中，通讯模组由Modem核和AP核组成，两个核基于共享内存进行核间ipc通讯；通讯模组和MCU之间的直连管脚有电源控制管脚pwr_ctl(由MCU控制)、开关机管脚on_off(由MCU控制)、AP核启动状态指示管脚boot_status(由通讯模组控制)、spi通讯管脚组合、唤醒控制管脚wakeup_in(由MCU控制)、唤醒状态管脚wakeup_out(由通讯模组控制)、唤醒MCU管脚wakeup_mcu(由通讯模组控制)；另外，通讯模组还通过sdhc(Secure Digital HighCapacity)接口与emmc(Embedded Multi Media Card)存储器连接。
如图2所示，为本发明提供的一种车载TBOX通讯模组异常唤醒监控方法的一个实施例的示意图。在该实施例中，所述方法包括以下步骤：
步骤S1，检测车载TBOX通讯模组的工作状态；其中，所述工作状态包括上电、下电、休眠及唤醒；可以理解的是，TBOX通讯模组的电源控制场景分为上电、下电、休眠、唤醒四个流程，具体地在进行各场景处理过程中需要采用不同的供电方式，然后通过AP核启动状态指示管脚的电压状态变化，可以判断各场景内操作是否成功，综合分析就可以判断车载TBOX通讯模组的工作状态。
具体实施例中，在上电场景中，MCU控制pwr_ctl管脚输出高电平给车载TBOX通讯模组供电并等待电压稳定；电压稳定之后控制on_off管脚先输出高电平，再输出低电平持续时间一端时间T1(可以根据实际情况设置)，最后保持高电平进行开机操作。此时，确定AP核启动状态指示管脚(boot_status管脚)状态，其中，若AP核启动状态指示管脚状态由高电平变为低电平，则判定车载TBOX通讯模组启动成功，控制唤醒控制管脚向车载TBOX通讯模组输出高电平，直到MCU和车载TBOX通讯模组之间的spi通讯建立成功；也就是，确定启动成功后，控制wakeup_in管脚输出高电平保持模组唤醒状态，并等待MCU和模组之间的spi握手通讯成功即可。若AP核启动状态指示管脚状态在预设的启动超时时间阈值之内没变化，则判定车载TBOX通讯模组启动失败，对车载TBOX通讯模组进行重启(先进行下电再进行上电对模组进行重启操作)。
具体地，在下电场景中，MCU控制on_off管脚先输出高电平，再输出低电平持续时间一段时间T2(根据实际情况设置)，最后保持高电平进行关机操作。若AP核启动状态指示管脚状态由低电平变为高电平，则判定车载TBOX通讯模组关闭成功，表示模组系统关机成功；若AP核启动状态指示管脚状态在预设的关闭超时时间阈值之内没变化，则判定车载TBOX通讯模组关闭失败，表示模组系统关机失败，此时对于某些品牌的通讯模组需要重试几次下电场景的操作过程，控制唤醒控制管脚(wakeup_in管脚)输出低电平，并控制电源控制管脚(pwr_ctl管脚)停止供电，下电操作完成。
具体地，在休眠场景中，具体操作过程为，MCU控制唤醒控制(wakeup_in)管脚向车载TBOX通讯模组进行供电(输出低电平)并允许车载TBOX通讯模组休眠；若唤醒状态(wakeup_out)管脚状态由低电平变为高电平，且维持时间超过2s，则判定车载TBOX通讯模组休眠成功；若唤醒状态(wakeup_out)管脚在预设的休眠超时时间阈值之内没变化，则判定车载TBOX通讯模组休眠失败，对车载TBOX通讯模组进行重启(先进行下电再进行上电对模组进行重启操作)。
具体地，在唤醒场景中，MCU控制唤醒控制(wakeup_in)管脚向车载TBOX通讯模组输出高电平，保持车载TBOX通讯模组处于唤醒状态；若唤醒状态(wakeup_out)管脚由高电平变为低电平，且维持时间超过2s，则判定车载TBOX通讯模组唤醒成功，MCU和车载TBOX通讯模组之间建立spi通讯，即，接着等待MCU和模组之间的spi握手通讯成功即可；若唤醒状态(wakeup_out)管脚状态在预设的唤醒超时时间阈值之内没变化，则判定车载TBOX通讯模组唤醒失败，对车载TBOX通讯模组进行重启，先进行下电再进行上电对模组进行重启操作。
步骤S2，根据车载TBOX通讯模组的工作状态通过预设的异常唤醒判断规则确定AP核是否产生异常唤醒故障；可以理解的是，TBOX在休眠成功之后，MCU处于低功耗状态，通讯模组内的AP核所有进程都处于挂起状态，只有Modem核还保持全功能状态。在基站切换、信号突变、无服务搜网、网络维持等正常情况下，Modem核都不会把AP核唤醒；在收到振铃、短信、远程数据包或出现网络异常、硬件gpio(General-purpose input/output，通用型之输入输出)异常等情况下，Modem核才会把AP核唤醒，并把具体唤醒源通过核间ipc通讯发送给AP核。因此，需要鉴别哪些是异常唤醒源，并做相应处理。
一个实施例中，为了尽可能快获取到AP核唤醒或休眠状态的变化情况，通过一个预设的低功耗模块驱动lpm_driver，该驱动为休眠和唤醒分别设计了对应的回调函数(监控函数)lpm_driver_suspend_cb和lpm_driver_resume_cb；另外，还设计了一个设备节点/dev/suspend_resume和一个proc文件节点/proc/suspend_resume。/dev/suspend_resume设备节点用来进行异步IO通知操作，/proc/suspend_resume文件用来获取最近两次的休眠唤醒状态。其中，/proc/suspend_resume文件的内容格式为：“last_st＝xxx,curr_st＝xxx”,其中xxx是字符串格式，表示AP核休眠唤醒状态，有3个可选值：“unknown”、“suspend”、“resume”，初始值是“unknown”。比如在某一次唤醒中，/proc/suspend_resume文件的可能值为“last_st＝suspend,curr_st＝resume”。
具体实施例中，当AP核从休眠状态切换到唤醒状态时，函数lpm_driver_resume_cb被触发，该函数修改/proc/suspend_resume文件值，并通过调用kill_fasync函数触发异步IO通知给应用层，应用层就能以最快的速度读取到最近两次的休眠唤醒状态值，并执行休眠或唤醒相关操作。
当AP核从唤醒状态切换到休眠状态时，函数lpm_driver_suspend_cb被触发，该函数修改/proc/suspend_resume文件值，并通过调用kill_fasync函数触发异步IO通知应用层。但由于Linux系统休眠很快，大多数情况下AP核都来不及执行应用层的异步IO通知回调函数就再次进入休眠状态了。因此需要在下次唤醒时，先判断last_st是否是休眠状态，如果是就先执行应用层休眠相关操作，再执行应用层唤醒相关操作。
具体地，如图3所示，异常唤醒判断规则，具体包括：当AP核完成上电后，初始化监控函数并通过异步IO方式监听休眠或唤醒事件；
通过执行shell指令方式实时截取内核日志并保存到存储器的对应目录；
通过执行shell指令方式更改内核日志打印级别，开启唤醒源打印和ipc消息内容打印开关；
当AP核处于休眠状态下，出现自动唤醒且触发监控函数时，设置不进入自动休眠，并获取上一次状态信息、当前状态信息；其中，若当前状态信息是休眠状态，则判定车载TBOX通讯模组休眠成功，执行应用层休眠操作；
根据获取的上一次状态信息和当前状态信息确定AP核产生异常唤醒或属于正常的唤醒。
若当前状态是唤醒状态，则获取唤醒控制管脚状态；若唤醒控制管脚状态是低电平，则获取各唤醒源的唤醒状态且通过检索关键字解析所述内核日志确定各唤醒源对应的唤醒类型；其中，所述唤醒类型包括正常或异常。
若唤醒控制管脚状态是高电平，则判定MCU将车载TBOX通讯模组唤醒，AP核属于正常的唤醒。
可以理解的是，通过insmod方式手动加载lpm_driver；并且通过signal方式注册异步IO通知回调函数app_suspend_resume_cb。通过执行shell指令方式实时截取内核日志并保存到存储器(emmc存储器)的对应目录；比如在某一实施例中指令为：“cat/proc/kmsg>>/mnt/sdcard/log/dmesg/dmesg_yyyy_mm_dd_hh_mm_ss.log&”。通过执行shell指令方式更改内核日志打印级别，开启唤醒源打印和ipc消息内容打印开关；当AP核处于休眠状态下，出现自动唤醒且触发监控函数时，设置不进入自动休眠，并获取上一次状态、当前状态；具体为，等休眠控制流程完成之后，如果AP核出现自动唤醒，app_suspend_resume_cb函数会被触发。该函数执行的步骤为：把suspend_resume_wake_lock加到/sys/power/wake_lock文件防止系统自动休眠；读取/proc/suspend_resume文件并解析出last_st和curr_st值。若当前状态(curr_st)是唤醒(resume)状态，则获取唤醒控制(wakeup_in)管脚状态；若唤醒控制(wakeup_in)管脚状态是低电平，则判定MCU处于休眠状态，说明MCU还在休眠，是通讯模组自身产生了主动唤醒，且通过检索关键字解析存储器里面的内核日志判断是否产生了异常唤醒，获取异常判断结果；常见的唤醒源、类型及检索关键字方式如下表所示：
若唤醒控制管脚状态是高电平，则判定MCU将车载TBOX通讯模组唤醒，属于正常的唤醒；如果wakeup_in管脚是高电平，说明是由于MCU把模组唤醒的，属于正常的被动唤醒，需要把suspend_resume_wake_lock加到/sys/power/wake_unlock文件释放掉。
若当前状态(curr_st)是休眠(suspend)状态，则判定车载TBOX通讯模组休眠成功，执行应用层休眠操作。
步骤S3，当AP核产生异常唤醒故障时，根据预设的异常场景检测规则确定异常唤醒场景；其中，所述异常唤醒场景包括长时间异常唤醒或频繁异常唤醒。
一个实施例，异常场景检测规则具体为：当AP核休眠之后出现自动唤醒，且唤醒持续时间超过异常时间阈值时，判定异常唤醒场景为长时间异常唤醒；可以理解的是，长时间异常唤醒判断依据为：AP核休眠之后出现自动唤醒，唤醒源是异常的，且持续时间超过RESUME_TIMEOUT(在某一实施例中该值为180s)都没再次休眠下去。
当AP核休眠之后出现自动唤醒，且在异常时间阈值内再次休眠后，又多次出现自动唤醒-休眠循环时，判定异常唤醒场景为频繁异常唤醒；可以理解的是，频繁异常唤醒判断依据：AP核休眠之后出现自动唤醒，唤醒源是异常的，且在RESUME_TIMEOUT内再次休眠下去，但很快又自动唤醒，如此频繁地循环。
步骤S4，根据异常唤醒场景通过预设的异常唤醒修复规则对异常唤醒故障进行修复处理，直到故障解除为止。可以理解的是，当确实异常唤醒存在，且确定了异常唤醒的场景情况，则需要针对不同场景采用不同的处理策略对异常唤醒故障进行处理和修复，以排除异常唤醒的出现。
具体实施例中，如图4所示，异常唤醒修复规则具体包括：针对长时间异常唤醒场景，由于异常唤醒处理流程包含重启通讯模组的操作，因此需要在emmc存储器里面设置一个文件来记录重启次数，在某一实施例中该文件路径为/mnt/sdcard/data/suspend_resume_reboot_cnt.dat。
具体地，首先当异常唤醒场景为长时间异常唤醒时，启动计时器并等待AP核休眠；
若车载TBOX通讯模组一直保持唤醒，导致计时器超时，则停止并清空计时器，重新获取唤醒控制管脚状态，若唤醒控制管脚状态是高电平，则判定车载TBOX通讯模组是由MCU唤醒的，属于正常唤醒，继续等待AP核休眠；
若唤醒控制管脚状态是低电平，则读取当前重启次数值；将当前重启次数值与最大重启次数值比较，若当前重启次数值大于等于最大重启次数值，则唤醒MCU并与车载TBOX通讯模组建立spi通讯，将重启次数值清零，通过spi通讯管脚通知MCU对车载TBOX通讯模组进行下电操作；若当前重启次数值小于最大重启次数值，则唤醒MCU并建立spi通讯，将重启次数值加一，通过spi通讯管脚通知MCU对车载TBOX通讯模组进行重启；当重启之后对车载TBOX通讯模组休眠成功时，将重启次数值清零。
可以理解的是，当检测到异常唤醒时，设置计时器超时值RESUME_TIMEOUT并启动计时器；释放suspend_resume_wake_lock并等待AP核休眠；如果模组一直保持唤醒，导致计时器超时，停止并清空计时器；使能suspend_resume_wake_lock，并再次读取wakeup_in管脚状态确认是否中途被MCU唤醒了；如果wakeup_in管脚是高电平，说明是由MCU唤醒的，属于正常唤醒，释放suspend_resume_wake_lock并等待AP核休眠，整个流程结束；
但是，如果wakeup_in管脚是低电平，从suspend_resume_reboot_cnt.dat读取当前重启次数值；如果当前重启次数值大于等于最大重启次数值(在某一实施例中该值为3次)，控制wakeup_out管脚输出低电平延时100ms再输出高电平唤醒MCU，等待通讯模组和MCU之间SPI握手通过，把suspend_resume_reboot_cnt.dat里面的重启次数值清零，最后通过SPI消息通知MCU对通讯模组操作下电控制流程；如果当前重启次数值小于最大重启次数值，把MCU唤醒并建立SPI通讯，把suspend_resume_reboot_cnt.dat里面的重启次数值加一，最后通过SPI消息通知MCU对通讯模组先操作下电控制流程再操作上电控制流程进行重启；但是，如果重启之后模组能够休眠成功，直接执行应用层休眠相关操作，把suspend_resume_reboot_cnt.dat里面的重启次数值清零即可；或者等下次唤醒之后把suspend_resume_wake_lock加到/sys/power/wake_lock文件防止系统自动休眠；读取/proc/suspend_resume文件并解析出last_st和curr_st值，如果last_st是休眠状态，同样把重启次数值清零。
如图5所示，异常唤醒修复规则具体包括：针对频繁异常唤醒场景，考虑到频繁唤醒原因可能不是同一种，需要AP核RAM缓存中采用链表方式记录休眠唤醒及相关操作计数值，链表元素结构体类型如下：
其中，wakeup_source表示异常唤醒源类型，1表示usbvbus高电平唤醒，2表示gpio唤醒，3表示禁止的Modem服务事件唤醒；wakeup_cnt表示某一wakeup_source唤醒的总次数；airplane_cnt表示执行飞行模式的总次数；list指向上一个和下一个链表元素。
具体处理过程为，通过创建/遍历链表进行寻找/添加唤醒源，将相应的唤醒计数器加一；并启动计时器等待AP核休眠，具体地，设置计时器超时值RESUME_TIMEOUT并启动计时器(与长时间异常唤醒场景处理中采用同一个计时器)，释放suspend_resume_wake_lock并等待AP核休眠；
当AP核在预设休眠时间阈值(RESUME_TIMEOUT)内进入休眠状态后，又自动唤醒时，重复执行通过创建/遍历链表进行寻找/添加唤醒源，将相应的唤醒计数器加一；当某一唤醒源的唤醒次数大于等于最大频繁唤醒次数(在实施例中该值为6次)时，停止并清空计时器；当某一异常唤醒源的唤醒类型(wakeup_source)等于3，则执行飞行模式操作，将飞行模式总次数(airplane_cnt)加一；其中，通过发送AT指令(比如先发送AT+CFUN＝0再发送AT+CFUN＝1)或调用API的方式执行飞行模式操作。
当某一异常唤醒源的唤醒类型(wakeup_source)不等于3，或者多次(在某一实施例中该值为1次)执行飞行模式之后，还出现频繁唤醒时，获取当前重启次数值；将当前重启次数值与最大重启次数值比较，若当前重启次数值大于等于最大重启次数值，则唤醒MCU并与车载TBOX通讯模组建立spi通讯，将重启次数值清零，通过spi通讯管脚通知MCU对车载TBOX通讯模组进行下电操作；若当前重启次数值小于最大重启次数值，则唤醒MCU并建立spi通讯，将重启次数值加一，通过spi通讯管脚通知MCU对车载TBOX通讯模组进行重启；当重启之后对车载TBOX通讯模组休眠成功时，将重启次数值清零。
异常唤醒修复规则中，如果出现检测到当前唤醒源属于正常唤醒时，遍历链表把所有元素的异常唤醒源类型唤醒的总次数(wakeup_cnt)和执行飞行模式的总次数(airplane_cnt)值清零。
综上，实施本发明的实施例，具有如下的有益效果：
本发明提供的车载TBOX通讯模组异常唤醒监控方法，针对TBOX通讯模组AP核长时间异常唤醒和频繁异常唤醒两大常见场景的自动化监测和处理流程，能够高效降低TBOX在异常情况下的整机功耗，填补现有技术在这两大场景的空白。且适用于不同品牌的3G/4G/5G通讯模组，可以高效解决TBOX由于通讯模组长时间或频繁异常唤醒导致整车馈电的痛点。
以上所揭露的仅为本发明较佳实施例而已，当然不能以此来限定本发明之权利范围，因此依本发明权利要求所作的等同变化，仍属本发明所涵盖的范围。
Claims (10)
1.一种车载TBOX通讯模组异常唤醒监控方法，其特征在于，包括以下步骤：
步骤S1，检测车载TBOX通讯模组的工作状态；其中，所述工作状态包括上电、下电、休眠及唤醒；
步骤S2，根据车载TBOX通讯模组的工作状态通过预设的异常唤醒判断规则确定AP核是否产生异常唤醒故障；
步骤S3，当AP核产生异常唤醒故障时，根据预设的异常场景检测规则确定异常唤醒场景；其中，所述异常唤醒场景包括长时间异常唤醒或频繁异常唤醒；
步骤S4，根据异常唤醒场景通过预设的异常唤醒修复规则对异常唤醒故障进行修复处理，直到故障解除为止。
2.如权利要求1所述的方法，其特征在于，在步骤S2中，所述预设的异常唤醒判断规则，具体包括：
当AP核完成上电后，初始化监控函数并通过异步IO方式监听休眠或唤醒事件；
通过执行shell指令方式实时截取内核日志并保存到存储器的对应目录；
通过执行shell指令方式更改内核日志打印级别，开启唤醒源打印和ipc消息内容打印开关；
当AP核处于休眠状态下，出现自动唤醒且触发监控函数时，设置不进入自动休眠，并获取上一次状态信息、当前状态信息；其中，若当前状态信息是休眠状态，则判定车载TBOX通讯模组休眠成功，执行应用层休眠操作；
根据获取的上一次状态信息和当前状态信息确定AP核产生异常唤醒或属于正常的唤醒。
3.如权利要求2所述的方法，其特征在于，在步骤S2中，所述根据获取的上一次状态信息和当前状态信息确定AP核产生异常唤醒，具体包括：
若当前状态是唤醒状态，则获取唤醒控制管脚状态；若唤醒控制管脚状态是低电平，则获取各唤醒源的唤醒状态且通过检索关键字解析所述内核日志确定各唤醒源对应的唤醒类型；其中，所述唤醒类型包括正常或异常。
4.如权利要求3所述的方法，其特征在于，在步骤S2中，所述根据获取的上一次状态信息和当前状态信息确定AP核属于正常的唤醒，具体包括：
若唤醒控制管脚状态是高电平，则判定MCU将车载TBOX通讯模组唤醒，AP核属于正常的唤醒。
5.如权利要求3所述的方法，其特征在于，在步骤S3中，所述预设的异常场景检测规则，具体包括：
当AP核休眠之后出现自动唤醒，唤醒源的唤醒类型为异常且唤醒持续时间超过异常时间阈值时，判定异常唤醒场景为长时间异常唤醒。
6.如权利要求5所述的方法，其特征在于，在步骤S3中，所述预设的异常场景检测规则，具体还包括：
当AP核休眠之后出现自动唤醒，唤醒源的唤醒类型为异常且在预设的异常时间阈值内再次休眠后，又多次出现自动唤醒-休眠循环时，判定异常唤醒场景为频繁异常唤醒。
7.如权利要求6所述的方法，其特征在于，在步骤S4中，所述预设的异常唤醒修复规则，具体包括：
当异常唤醒场景为长时间异常唤醒时，启动计时器并等待AP核休眠；
若车载TBOX通讯模组一直保持唤醒，导致计时器超时，则停止并清空计时器，重新获取唤醒控制管脚状态，根据唤醒控制管脚状态进行修复。
8.如权利要求7所述的方法，其特征在于，在步骤S4中，所述预设的异常唤醒修复规则，具体还包括：
若唤醒控制管脚状态是高电平，则判定车载TBOX通讯模组是由MCU唤醒的，属于正常唤醒，继续等待AP核休眠；
若唤醒控制管脚状态是低电平，则读取当前重启次数值；
将当前重启次数值与最大重启次数值比较，若当前重启次数值大于等于最大重启次数值，则唤醒MCU并与车载TBOX通讯模组建立spi通讯，将重启次数值清零，通过spi通讯管脚通知MCU对车载TBOX通讯模组进行下电操作；
若当前重启次数值小于最大重启次数值，则唤醒MCU并建立spi通讯，将重启次数值加一，通过spi通讯管脚通知MCU对车载TBOX通讯模组进行重启；
当重启之后对车载TBOX通讯模组休眠成功时，将重启次数值清零。
9.如权利要求8所述的方法，其特征在于，在步骤S4中，所述预设的异常唤醒修复规则，具体还包括：
当异常唤醒场景为频繁异常唤醒时，通过创建/遍历链表进行寻找/添加唤醒源，将相应的唤醒计数器加一；并启动计时器等待AP核休眠；
当AP核在预设休眠时间阈值内进入休眠状态后，又自动唤醒时，重复执行通过创建/遍历链表进行寻找/添加唤醒源，将相应的唤醒计数器加一；
当某一唤醒源的唤醒次数大于等于最大频繁唤醒次数时，停止并清空计时器；
当某一异常唤醒源的唤醒类型等于禁止的Modem服务事件唤醒时，执行飞行模式操作，将飞行模式总次数加一并等待休眠；
当某一异常唤醒源的唤醒类型不等于禁止的Modem服务事件唤醒，或者多次执行飞行模式之后，还出现频繁唤醒时，获取当前重启次数值；将当前重启次数值与最大重启次数值比较，若当前重启次数值大于等于最大重启次数值，则唤醒MCU并与车载TBOX通讯模组建立spi通讯，将重启次数值清零，通过spi通讯管脚通知MCU对车载TBOX通讯模组进行下电操作；若当前重启次数值小于最大重启次数值，则唤醒MCU并建立spi通讯，将重启次数值加一，通过spi通讯管脚通知MCU对车载TBOX通讯模组进行重启；当重启之后对车载TBOX通讯模组休眠成功时，将重启次数值清零。
10.如权利要求9所述的方法，其特征在于，在步骤S4中，所述预设的异常唤醒修复规则，具体还包括：
当检测到当前唤醒源属于正常唤醒时，遍历链表把所有元素的异常唤醒源类型唤醒的总次数和执行飞行模式的总次数清零。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110620867.7A CN115442768A (zh) | 2021-06-03 | 2021-06-03 | 一种车载tbox通讯模组异常唤醒监控方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110620867.7A CN115442768A (zh) | 2021-06-03 | 2021-06-03 | 一种车载tbox通讯模组异常唤醒监控方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115442768A true CN115442768A (zh) | 2022-12-06 |
Family
ID=84272052
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110620867.7A Pending CN115442768A (zh) | 2021-06-03 | 2021-06-03 | 一种车载tbox通讯模组异常唤醒监控方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115442768A (zh) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106126209A (zh) * | 2016-06-15 | 2016-11-16 | 广东欧珀移动通信有限公司 | 一种终端系统的唤醒统计方法及终端 |
| CN108549593A (zh) * | 2018-03-29 | 2018-09-18 | 广东欧珀移动通信有限公司 | 信息处理方法、装置、移动终端和计算机可读存储介质 |
| CN108646909A (zh) * | 2018-05-15 | 2018-10-12 | Oppo（重庆）智能科技有限公司 | 信息处理方法、装置、移动终端和计算机可读存储介质 |
| JP2019084942A (ja) * | 2017-11-06 | 2019-06-06 | トヨタ自動車株式会社 | 電子制御装置 |
| CN112141122A (zh) * | 2020-09-23 | 2020-12-29 | 北京车和家信息技术有限公司 | 车辆休眠异常检测方法、装置、设备及存储介质 |
| CN112558590A (zh) * | 2020-12-08 | 2021-03-26 | 广州橙行智动汽车科技有限公司 | 网络管理异常监测方法、系统、车辆及可读存储介质 |
-
2021
- 2021-06-03 CN CN202110620867.7A patent/CN115442768A/zh active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106126209A (zh) * | 2016-06-15 | 2016-11-16 | 广东欧珀移动通信有限公司 | 一种终端系统的唤醒统计方法及终端 |
| JP2019084942A (ja) * | 2017-11-06 | 2019-06-06 | トヨタ自動車株式会社 | 電子制御装置 |
| CN108549593A (zh) * | 2018-03-29 | 2018-09-18 | 广东欧珀移动通信有限公司 | 信息处理方法、装置、移动终端和计算机可读存储介质 |
| CN108646909A (zh) * | 2018-05-15 | 2018-10-12 | Oppo（重庆）智能科技有限公司 | 信息处理方法、装置、移动终端和计算机可读存储介质 |
| CN112141122A (zh) * | 2020-09-23 | 2020-12-29 | 北京车和家信息技术有限公司 | 车辆休眠异常检测方法、装置、设备及存储介质 |
| CN112558590A (zh) * | 2020-12-08 | 2021-03-26 | 广州橙行智动汽车科技有限公司 | 网络管理异常监测方法、系统、车辆及可读存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0813707B1 (en) | A computer system with unattended on-demand availability | |
| US20040243868A1 (en) | Method and apparatus for power mode transition in a multi-thread processor | |
| CN111683287B (zh) | 智能设备启动方法、装置、智能设备和可读存储介质 | |
| CN109803359A (zh) | 一种唤醒终端系统的方法及终端 | |
| KR20110021927A (ko) | 전력 소모를 감소시키기 위해 슬립 상태를 제공하는 제 2 메모리 컨트롤러를 구비한 집적 회로 및 그 방법 | |
| CN101154131A (zh) | 信息处理设备和系统状态控制方法 | |
| US20030070065A1 (en) | Suspending to nonvolatile storage | |
| US10394307B2 (en) | Information processing apparatus, information processing method, and program | |
| CN102736928B (zh) | 快速唤醒计算机系统方法与计算机系统 | |
| CN115756622B (zh) | 芯片控制方法及芯片 | |
| CN113721751A (zh) | 一种基于事件与休眠定时器的低功耗管理方法及系统 | |
| CN101436097B (zh) | 电子装置及其唤醒方法 | |
| CN111176408B (zh) | 一种SoC的低功耗处理方法和装置 | |
| CN117687694A (zh) | 误唤醒处理方法、装置及存储介质 | |
| CN115442768A (zh) | 一种车载tbox通讯模组异常唤醒监控方法 | |
| US10042650B2 (en) | Computer startup method, startup apparatus, state transition method and state transition apparatus | |
| CN109960638A (zh) | Bmc启动原因记录方法、系统、装置及可读存储介质 | |
| EP1229430B1 (en) | Power management system and method | |
| CN115437859A (zh) | 休眠唤醒处理方法、装置、电子设备及存储介质 | |
| CN110659169B (zh) | 一种安卓系统自动休眠唤醒压力测试的方法 | |
| US20180157311A1 (en) | System-Wide Idle Resiliency Mechanism for Always-On Always-Connected Computers | |
| CN110457072A (zh) | 防止系统挂死的方法、装置、设备及计算机可读介质 | |
| CN115185359B (zh) | 一种机密计算协处理器系统及其掉电保护方法 | |
| CN117950737A (zh) | 唤醒处理方法、装置、电子设备及计算机可读存储介质 | |
| US7822999B2 (en) | Computer system and method for controlling a processor thereof |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |