CN115431896A - 控制方法、装置、电子设备、存储介质、车机系统及车辆 - Google Patents

Abstract

本公开涉及一种控制方法、装置、电子设备、存储介质、车机系统及车辆，其中，所述方法用于车机的MCU，所述方法包括：在所述车机的SOC启动的过程中，依次监测所述SOC在每个启动阶段反馈的状态信息；若在任一所述启动阶段未监测到所述SOC反馈的状态信息，则向所述SOC发送重启指令。采用上述技术方案，通过接收SOC启动过程中各个阶段的状态信息，并在未接到状态信息时控制SOC重启，实现了实时监测SOC启动过程中的状态，能够在SOC启动过程中出现故障时及时重启SOC，无需用户介入处理，避免了车机无法正常启动的问题。

Description

控制方法、装置、电子设备、存储介质、车机系统及车辆

技术领域

本公开涉及车辆的车机控制技术领域，尤其涉及一种控制方法、装置、电子设备、存储介质、车机系统及车辆。

背景技术

通常车辆的车机包含微控制单元(Microcontroller Unit，MCU)和系统级芯片(System on Chip，SOC)。其中，MCU负责车机的电源逻辑管理和控制器局域网络(Controller Area Network，CAN)通信；SOC负责车机音视频图像处理。MCU在接收到开机信号启动后，会给SOC上电以启动SOC，从而使得车机启动，如果SOC在启动过程中出现故障，则需要用户介入进行重启操作，否则将无法恢复。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开的至少一个实施例提供了一种控制方法、装置、电子设备、存储介质、车机系统及车辆。

第一方面，本公开提供了一种控制方法，用于车机的MCU，包括：

在车机的SOC启动的过程中，依次监测所述SOC在每个启动阶段反馈的状态信息；

若在任一所述启动阶段未监测到所述SOC反馈的状态信息，则向所述SOC发送重启指令。

第二方面，本公开提供了另一种控制方法，用于车机的SOC，包括：

接收所述车机的MCU发送的重启指令，所述重启指令为所述MCU在所述SOC的任一启动阶段对应的等待时长内未监测到所述任一启动阶段的状态信息而发送的；

根据所述重启指令进行重启。

第三方面，本公开提供了一种控制装置，用于车机的MCU，包括：

监测模块，用于在车机的SOC启动的过程中，依次监测所述SOC在每个启动阶段反馈的状态信息；

重启控制模块，用于在任一所述启动阶段未监测到所述SOC反馈的状态信息时，向所述SOC发送重启指令。

第四方面，本公开提供了一种控制装置，用于车机的SOC，所述装置包括：

接收模块，用于接收所述车机的MCU发送的重启指令，所述重启指令为所述MCU在所述SOC的任一启动阶段对应的等待时长内未监测到所述任一启动阶段的状态信息而发送的；

重启模块，用于根据所述重启指令进行重启。

第五方面，本公开提供了一种电子设备，包括：

至少一个处理器；

以及与所述至少一个处理器通信连接的存储器；其中，

所述至少一个处理器通过调用所述存储器存储的程序或指令，用于执行本公开实施例提供的任一所述的车机控制方法。

第六方面，本公开提供了一种计算机可读存储介质，所述计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行本公开实施例提供的任一所述的控制方法。

第七方面，本公开提供了一种车机系统，包括本公开实施例提供的控制装置或本公开实施例提供的电子设备

第八方面，本公开提供了一种车辆，包括本公开实施例提供的控制装置或本公开实施例提供的电子设备或本公开实施例提供的车机系统。

第九方面，本公开提供了一种计算机程序产品，所述计算机程序产品用于执行本公开实施例提供的任一所述的车机控制方法。

本公开实施例提供的技术方案与现有技术相比至少具有如下优点：

在本公开实施例中，在车机的SOC启动的过程中，MCU依次监测SOC在每个启动阶段反馈的状态信息，若在任一启动阶段未监测到SOC反馈的状态信息，则向SOC发送重启指令。采用上述技术方案，通过监测SOC启动过程中各个阶段的状态信息，并在未监测到任一阶段的状态信息时向SOC发送重启指令以控制SOC重启，实现了实时监测SOC启动过程中的状态，能够在SOC启动过程中出现故障时及时重启SOC，无需用户介入处理即可完成自动重启操作，避免了车机启动过程中因出现故障但无人工介入导致车机无法正常启动的问题。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本公开一实施例提供的控制方法的流程示意图；

图2为本公开另一实施例提供的控制方法的流程示意图；

图3为本公开一实施例提供的控制装置的结构示意图；

图4为本公开另一实施例提供的控制装置的结构示意图。

具体实施方式

为了能够更清楚地理解本公开的上述目的、特征和优点，下面结合附图和实施例对本公开作进一步的详细说明。可以理解的是，所描述的实施例是本公开的一部分实施例，而不是全部的实施例，此处所描述的具体实施例仅仅用于解释本公开，而非对本公开的限定，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。基于所描述的本公开的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本公开保护的范围。

在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。

在解释说明本公开实施例的控制方法、装置、电子设备、存储介质、车机系统及车辆之前，先对本公开中可能涉及的专业名词进行解释说明如下。

车机：车机指的是安装在汽车里面的车载信息娱乐产品的简称，车机在功能上能够实现人与车、车与外界(车与车)的信息通讯。

MCU：微控制单元，又称单片微型计算机(Single Chip Microcomputer)或者单片机，是把中央处理器(Central Process Unit，CPU)的频率与规格做适当缩减，并将内存(memory)、计数器(Timer)、通用串行总线(Universal Serial Bus，USB)、模数(A/D)转换、通用异步收发传输器(Universal Asynchronous Receiver/Transmitter，UART)、可编程逻辑控制器(Programmable Logic Controller，PLC)、直接存储器访问(Direct MemoryAccess，DMA)等周边接口，甚至液晶显示器(Liquid Crystal Display，LCD)驱动电路都整合在单一芯片上，形成芯片级的计算机，为不同的应用场合做不同组合控制。

SOC：系统级芯片，也有称片上系统，意指它是一个产品，是一个有专用目标的集成电路，其中包含完整系统并有嵌入软件的全部内容。

RPC：远程过程调用(Remote Procedure Call)的缩写形式，本公开实施例中指的是SOC跟MCU的通信技术方式。

Android：安卓，是一种基于Linux内核的自由及开放源代码的操作系统。

XBL：Extensible Boot Loader/Secondary bootloader，扩展引导加载程序，是Android在启动时候的一个阶段，负责芯片驱动及充电等核心应用功能等初始化，在该阶段会进行项目、板级、器件等区分，并将区分的信息通过数据结构传递至ABL。

ABL：Application Boot Loader，应用引导程序，是Android在启动时候的一个阶段，引导Android启动，加载Linux内核，包括芯片无关的应用，并接收XBL一些初始化的信息并将其传递至内核(kernel)，内核会解析传递进来的信息。

车辆的车机包括MCU和SOC，MCU给SOC上电以启动SOC。SOC启动进入Android系统需要经过多个阶段，通常包括XBL阶段、ABL阶段、Android的内核启动阶段、Android的服务(carservice)程序启动阶段，之后进入到Android系统。在SOC启动各阶段的过程中，任一阶段都存在故障的可能。

然而，现有的SOC从上电后即自己独立运行，没有动态与MCU进行状态交互，如果SOC在任一启动阶段出现程序故障或系统启动后出现挂死或不正常运行的情况，在无用户介入的情况下则无法自行恢复，使得系统一直无法进入或处于挂死状态，影响车机系统的运行。

针对上述问题，本公开提供了一种控制方法，用于车机的MCU，在车机的SOC启动的过程中，MCU依次监测SOC在每个启动阶段反馈的状态信息，若在任一启动阶段未监测到SOC反馈的状态信息，则向SOC发送重启指令。采用上述技术方案，通过监测SOC启动过程中各个阶段的状态信息，并在未监测到任一阶段的状态信息时向SOC发送重启指令以控制SOC重启，实现了实时监测SOC启动过程中的状态，能够在SOC启动过程中出现故障时及时重启SOC，无需用户介入处理，避免了车机无法正常启动的问题。

图1为本公开一实施例提供的控制方法的流程示意图，该控制方法可以由本公开实施例提供的控制装置执行，该控制装置可以采用软件和/或硬件实现，并可集成在车辆上，具体可以集成在车辆中车机的MCU上，车机还包括SOC，MCU与SOC之间进行通信连接。

如图1所示，本公开实施例提供的控制方法，可以包括以下步骤：

步骤101，在车机的SOC启动的过程中，依次监测所述SOC在每个启动阶段反馈的状态信息。

通常，车辆的车机包括SOC和MCU，MCU在接收到开机信号启动后，会给SOC上电以启动SOC。本公开实施例中，MCU接收到开机信号启动后，给SOC上电，之后，SOC开始启动，逐步进入SOC的各个启动阶段，比如XBL阶段、ABL阶段、Android系统内核启动阶段，等等。

在SOC启动的过程中，任一阶段均可能出现故障导致SOC无法正常启动。本公开实施例中，在SOC启动过程中，MCU依次监测SOC在每个启动阶段反馈的状态信息，SOC每成功启动一个启动阶段，则向MCU反馈该启动阶段的状态信息，状态信息用于表征SOC成功进入该启动阶段，以使MCU能够根据接收的该启动阶段的状态信息判断SOC在启动过程中是否出现异常情况。SOC的启动过程中包括多个启动阶段，并且在当前启动阶段成功启动后，才会进入下一个启动阶段。本公开实施例中，MCU监测SOC启动过程中的每个启动阶段的状态信息。

首先，SOC上电后进入第一个启动阶段，第一个启动阶段成功启动后，SOC向MCU发送状态信息。MCU监测第一个启动阶段的状态信息，如果在第一个启动阶段对应的等待时长内监测到对应的状态信息，则继续监测下一个启动阶段的状态信息。SOC成功启动第一个启动阶段后，进入第二个启动阶段，第二个启动阶段成功启动后，SOC向MCU发送第二个启动阶段的状态信息，以告知MCU该阶段成功启动。MCU监测SOC的第二个启动阶段的状态信息，如果在第二个启动阶段对应的等待时长内监测到对应的状态信息，则继续监测下一个启动阶段的状态信息。SOC成功启动第二个启动阶段后，进入第三个启动阶段，第三个启动阶段成功启动后，SOC向MCU发送第三个启动阶段的状态信息，以告知MCU该阶段成功启动。MCU监测SOC的第三个启动阶段的状态信息，如果在第三个启动阶段对应的等待时长内监测到第三个启动阶段对应的状态信息，则继续监测下一个启动阶段的状态信息。以此类推，MCU依次监测SOC启动过程中的每个启动阶段的状态信息，直至SOC成功启动，或者直至未监测到某个启动阶段的状态信息时向SOC发送重启指令以控制SOC重启，并在SOC重启后启动各启动阶段的过程中，重新监测各启动阶段的状态信息。

其中，SOC的每个启动阶段对应的等待时长可以根据实际需求预先设置，即在MCU内预先设置好SOC的每个启动阶段分别对应的等待时长，称为标准等待时长；SOC的每个启动阶段对应的等待时长也可以由SOC根据各阶段启动时需要耗费的时长提供给MCU，比如SOC可以在反馈当前阶段的状态信息时提供下一阶段对应的等待时长给MCU，本公开对此不作限制。

示例性地，MCU与SOC之间可以直接建立通信连接来交互SOC各阶段的状态信息。在MCU给SOC上电后，则建立与SOC之间的通信连接，以通过通信连接接收SOC反馈的每个启动阶段的状态信息。

示例性地，MCU与SOC之间可以通过第三方转发的方式来交互SOC启动过程中每个启动阶段的状态信息，SOC在成功启动某个启动阶段后，可以将该启动阶段的状态信息发送给第三方，由第三方将接收的状态信息反馈给MCU。

需要说明的是，本公开实施例中，SOC向MCU反馈的每个启动阶段的状态信息，可以是SOC成功启动某个启动阶段后，向MCU发送的用于表征该启动阶段已成功启动的反馈消息，该反馈消息可以是MCU与SOC之间预先约定的，MCU接收到该反馈消息则认为SOC已成功进入对应阶段；状态信息也可以是SOC启动每个启动阶段的过程中产生的启动信息，MCU与SOC之间可以预先约定SOC向MCU反馈各阶段的全部启动信息，也可以约定SOC向MCU反馈每个阶段的部分启动信息，可以根据实际需求进行设置，本公开对此不作限制。

步骤102，若在任一所述启动阶段未监测到所述SOC反馈的状态信息，则向所述SOC发送重启指令。

本公开实施例中，MCU在SOC的启动过程中，依次监测SOC的每个启动阶段的状态信息，如果MCU未监测到SOC反馈的任一启动阶段的状态信息，则认为SOC启动过程中出现异常，MCU向SOC发送重启指令，以控制SOC重启。

示例性地，假设SOC成功启动XBL阶段，则MCU能够在XBL启动阶段监测到SOC反馈的XBL阶段的状态信息，则继续监测下一阶段(即ABL阶段)的状态信息，如果MCU在ABL阶段未监测到SOC反馈的ABL阶段的状态信息，则认为SOC进入ABL阶段的过程中出现异常，使得SOC无法正常进入ABL阶段，从而无法完成本次启动流程并进入到安卓系统，则MCU向SOC发送重启指令，以控制SOC重启。

本公开实施例的控制方法，车机的MCU在车机的SOC启动的过程中，MCU依次监测SOC在每个启动阶段反馈的状态信息，若在任一启动阶段未监测到SOC反馈的状态信息，则向SOC发送重启指令。采用上述技术方案，通过监测SOC启动过程中各个阶段的状态信息，并在未监测到任一阶段的状态信息时向SOC发送重启指令以控制SOC重启，实现了实时监测SOC启动过程中的状态，能够在SOC启动过程中出现故障时及时重启SOC，无需用户介入处理即可完成自动重启操作，避免了车机启动过程中因出现故障但无人工介入导致车机无法正常启动的问题。

在本公开的一种可选实施方式中，MCU依次监测SOC在每个启动阶段反馈的状态信息时，可以在所述每个启动阶段的等待时长内，监测所述SOC反馈的状态信息。

其中，等待时长为MCU等待SOC反馈对应阶段的状态信息的时长，若在某个启动阶段对应的等待时长内MCU成功接收到该启动阶段的状态信息，则确定SOC成功进入该阶段，之后在下一阶段对应的等待时长内等待接收下一阶段的状态信息；如果超过某个启动阶段对应的等待时长MCU仍未接收到该启动阶段的状态信息，则认为SOC进入该阶段失败，则MCU向SOC发送重启指令以控制SOC重启。

需要说明的是，各个阶段对应的等待时长可以根据实际需求预先设置，即在MCU内预先设置好SOC的每个启动阶段分别对应的等待时长，称为标准等待时长，也可以由SOC根据各阶段启动时需要耗费的时长提供给MCU，比如SOC可以在反馈当前阶段的状态信息时提供下一阶段对应的等待时长给MCU，本公开对此不作限制。

在本公开实施例中，通过在每个启动阶段的等待时长内，监测SOC反馈的状态信息，能够在超过等待时长未监测到某个启动阶段的状态信息时，及时做出向SOC发送重启指令的操作，以及时重启SOC。

SOC的启动过程包括多个阶段，如XBL阶段、ABL阶段、安卓的内核启动阶段等，在一个阶段启动成功后再进入下一阶段的启动过程，因此，MCU监测的SOC各阶段的状态信息也是逐阶段的，在监测到一个阶段的状态信息后再接收下一阶段的状态信息。由于SOC中不同阶段启动时消耗的时间可能不同，不同的车机中SOC的同一阶段启动时消耗的时间也可能不同，为了保证各阶段对应的等待时长的合理性，以及提高本方案的适用性，本公开实施例中，除了SOC启动过程中的第一个启动阶段外，其他各启动阶段的等待时长可以由SOC发送给MUC，SOC可以在反馈当前启动阶段的状态信息时，同时反馈下一启动阶段对应的等待时长。从而，在本公开的一种可选实施方式中，所述MCU预设有所述SOC的启动过程中的第一个启动阶段对应的标准等待时长，所述在所述每个启动阶段的等待时长内，监测所述SOC反馈的状态信息之前，所述方法还包括：

确定所述每个启动阶段的等待时长；其中，

若所述启动阶段为所述第一个启动阶段，则将所述启动阶段的所述标准等待时长确定为所述启动阶段的等待时长；

若所述启动阶段非所述第一个启动阶段，则将所述SOC反馈前一启动阶段的状态信息时反馈的第一等待时长，确定为所述启动阶段的等待时长。

本公开实施例中，MCU中预设有SOC的第一个启动阶段对应的标准等待时长，标准等待时长可以根据经验预先设定。SOC在向MCU反馈各个启动阶段的状态信息时，会将下一个启动阶段对应的第一等待时长也反馈给MCU。对于SOC中的第一个启动阶段，由于其之前无其他启动阶段，因此SOC无法向MCU反馈第一个启动阶段对应的第一等待时长，从而，如果当前监测的启动阶段为第一个启动阶段，则MCU可以将预设的标准等待时长确定为该启动阶段的等待时长。如果当前监测的启动阶段不是第一个启动阶段，比如当前监测的启动阶段是SOC启动的过程中的第二个启动阶段，则SOC在向MCU反馈第一个启动阶段的状态信息时，会将第二个启动阶段的第一等待时长也反馈也MCU，则MCU可以将监测到的第一等待时长确定为当前监测的启动阶段的等待时长。

其中，第一等待时长可以根据启动阶段启动时耗费的时长确定，将第一等待时长设置为不小于启动阶段启动消耗时长。由此，SOC可以根据自身各阶段启动耗费的时长设置对应阶段的等待时长，有利于避免各阶段的等待时长过短或过长的现象，从而有利于保证各阶段的等待时长的合理性。

在本公开实施例中，通过在启动阶段为SOC启动过程中的第一个启动阶段时，将启动阶段的标准等待时长确定为启动阶段的等待时长，在启动阶段非第一个启动阶段时，将SOC反馈前一启动阶段的状态信息时反馈的第一等待时长，确定为启动阶段的等待时长，由此，实现了动态设置各阶段对应的等待时长，避免了MCU端预先设置SOC各个阶段对应的等待时长，并且，SOC可以根据自身各阶段启动耗费的时长设置对应阶段的等待时长，有利于避免各阶段的等待时长过短或过长的现象，从而有利于保证各阶段的等待时长的合理性。

为了避免MCU监测SOC反馈的各节点的状态信息时，未监测到下一阶段对应的等待时长，导致MCU一直处于接收下一阶段的状态信息的状态中，而无法做出是否在等待时长内接收到下一阶段的状态信息的判断的情况，在本公开的一种可选实施方式中，还可以在MCU中预设SOC的启动过程中除第一个启动阶段外的其他启动阶段分别对应的标准等待时长，从而，所述将所述SOC反馈前一启动阶段的状态信息时反馈的第一等待时长，确定为所述启动阶段的等待时长，包括：

将所述启动阶段对应的等待时长由所述启动阶段对应的标准等待时长更新为所述第一等待时长。

其中，其他启动阶段对应的标准等待时长可以根据实际需求预先设定。

本公开实施例中，预先设置每个启动阶段对应的标准等待时长并存储在MCU中，当正在监测的启动阶段为SOC上电后启动的第一个启动阶段时，MCU可以在预设的第一个启动阶段对应的标准等待时长内，监测SOC反馈的第一个启动阶段的状态信息及下一个启动阶段的第一等待时长。如果MCU在第一个启动阶段对应的标准等待时长内未监测到第一个启动阶段的状态信息，则向SOC发送重启指令以控制SOC重启；如果MCU监测到SOC反馈的第一个启动阶段的状态信息但未监测到第二个启动阶段的第一等待时长，可以在预设的与第二个启动阶段对应的标准等待时长内，监测SOC反馈的第二个启动阶段的状态信息和第三个启动阶段的第一等待时长；如果MCU监测到SOC反馈的第一个启动阶段的状态信息和第二个启动阶段的第一等待时长，则可以将第二个启动阶段对应的等待时长由第二个启动阶段对应的标准等待时长更新为监测到的第一等待时长，从而MCU能够在第一等待时长内监测第二个启动阶段的状态信息和第三个启动阶段的第一等待时长，以此类推，直至SOC进入系统运行阶段或达到预设的重启次数后提醒相关人员进行介入。

本公开实施例中，MCU与SOC之间可以预先约定好SOC需要向MCU反馈的各个阶段的状态信息，状态信息可以是一个能够说明对应阶段已成功启动的反馈消息，也可以是对应阶段启动过程中产生的全部或部分启动信息，MCU监测到各阶段的状态信息后，根据状态信息判断对应阶段是否成功启动。

在本公开的一种可选实施方式中，SOC与MCU之间预先约定好反馈消息，反馈消息用于表示对应阶段已成功启动，其中，不同阶段对应的反馈消息可以相同也可以不同，MCU中可以按照SOC中各阶段的启动顺序记录对应阶段的反馈消息，SOC成功启动一个阶段后，向MCU反馈该阶段对应的反馈消息，如果MCU在对应阶段的等待时长内监测到对应的反馈消息，则不会重启SOC，继续等待下一阶段的反馈消息，如果MCU在对应阶段的等待时长内未监测到对应的反馈消息，则说明SOC进入该阶段失败，则MCU向SOC发送重启指令，以控制重启SOC。

在本公开的一种可选实施方式中，SOC与MCU之间预先约定好需要SOC反馈的各阶段的启动信息，为了便于MCU区分各个阶段的启动信息，SOC向MCU反馈的各个阶段的反馈信息中包括对应阶段的阶段标识和启动信息，从而，MCU可以根据启动信息判断是否接收到阶段标识对应的目标阶段的状态信息。本公开实施例中，所述依次监测所述SOC在每个启动阶段反馈的状态信息，包括：

接收所述SOC在所述每个启动阶段反馈的反馈信息，所述反馈信息包括阶段标识和启动信息；

根据所述阶段标识，从所述MCU中预设的与所述每个启动阶段对应的参考信息中，获取与所述阶段标识对应的目标参考信息；

在所述启动信息与所述目标参考信息不一致的情况下，确定在所述阶段标识对应的目标启动阶段未监测到所述SOC反馈的状态信息；

在所述启动信息与所述目标参考信息一致的情况下，确定在所述阶段标识对应的目标启动阶段监测到所述SOC反馈的状态信息。

其中，参考信息是MCU与SOC之间预先约定好的用于说明SOC已成功进入对应阶段的信息，参考信息可以是对应阶段启动过程中产生的部分或全部的启动信息，当MCU接收的某个启动阶段的启动信息与该启动阶段的参考信息一致时，则认为MCU成功接收到该启动阶段的状态信息，SOC已成功启动该阶段。

示例性地，假设MCU中预设有与SOC的每个启动阶段对应的参考信息，并存储在MCU的本地存储空间中。本公开实施例中，当MCU在任一启动阶段的等待时长内接收到SOC反馈的反馈信息时，可以对接收的反馈信息进行校验，首先根据反馈信息中包含的阶段标识，从MCU的本地存储空间中存储的参考信息中，获取与该阶段标识对应的目标参考信息，进而将反馈信息中包含的启动信息与获取的目标参考信息进行匹配，如果启动信息与目标参考信息一致，则确定在该阶段标识对应的目标启动阶段对应的等待时长内成功接收到SOC反馈的该目标启动阶段的状态信息，则继续等待接收下一阶段的状态信息；如果启动信息与目标参考信息不一致，则确定在该阶段标识对应的目标启动阶段对应的等待时长内未接收到SOC反馈的该目标启动阶段的状态信息，则向SOC发送重启指令，以控制SOC重启。

需要说明的是，本公开实施例中所说的启动信息与目标参考信息一致，是指启动信息中包含对应阶段的全部参考信息，启动信息可以与目标参考信息完全相同，即包括的信息的数量以及信息的内容均相同，启动信息也可以包含比目标参考信息更多的信息，但不能仅包含部分目标参考信息或不包含目标参考信息。也就是说，当启动信息中至少包括对应阶段的全部参考信息时，认为启动信息与目标参考信息一致，当存在参考信息未包含在启动信息中时，认为启动信息与目标参考信息不一致。

在本公开实施例中，反馈信息包括对应阶段的阶段标识和启动信息，通过根据反馈信息中包含的阶段标识，从MCU中预设的与每个启动阶段对应的参考信息中，获取与阶段标识对应的目标参考信息，并在反馈信息中的启动信息与目标参考信息不一致的情况下，确定在阶段标识对应的目标启动阶段未接收到SOC反馈的状态信息，在启动信息与目标参考信息一致的情况下，确定在阶段标识对应的目标启动阶段监测到SOC反馈的状态信息，由此，实现了根据预先约定的参考信息，对接收的启动信息进行校验来判断是否成功接收到第一阶段的状态信息，能够提高接收结果的判断准确性，从而有效避免误重启或未能及时重启SOC导致系统处于挂死状态的现象。

在SOC的XBL、ABL、安卓系统内核等启动阶段均成功启动后，SOC进入安卓系统运行阶段。由于车机系统(Android)有时会出现卡死情况，或者出现重要的车辆信息无法获取的情况，导致车机系统无法正常运行，这种情况下，也可以控制SOC重启以重新启动车机系统，以使车机系统在无人工介入的情况下恢复正常运行状态，避免车机一直处于挂死黑屏或者不正常状态。从而，在本公开的一种可选实施方式中，所述方法还包括：

在所述SOC进入到系统运行阶段后，监测所述SOC反馈的系统状态信息；

如果在预设周期内未监测到所述SOC反馈的所述系统状态信息，则控制所述SOC重启。

其中，系统运行阶段比如可以是安卓系统、苹果系统等操作系统启动后进入运行的阶段。以安卓系统为例，当SOC的XBL、ABL、安卓系统内核等启动阶段均成功启动后，安卓系统成功启动，SOC即进入安卓系统运行阶段。

本公开实施例中，预设周期可以根据实际需求进行设置，比如设置预设周期为1分钟、5分钟等。预设周期可以由SOC与MCU预先约定，SOC在进入Android系统后，按照预设周期向MCU反馈Android系统的系统状态信息，MCU则按照预设周期接收系统状态信息。

示例性地，MCU监测到SOC反馈的进入到Android系统阶段的状态信息后，则可以确定SOC进入到系统运行阶段，之后，MCU按照预设周期接收SOC反馈的系统状态信息。

其中，系统状态信息可以是MCU与SOC之间预先约定的用于说明Android系统处于正常运行状态的预设报文，MCU接收到该预设报文则确定Android系统当前处于正常运行状态。

本公开实施例中，MCU监测SOC反馈的系统状态信息，当在一个预设周期内成功监测到SOC反馈的系统状态信息时，则进入下一预设周期，重新开始计时，在该预设周期内继续监测系统状态信息；当在一个预设周期内未监测到系统状态信息时，则认为Android系统运行过程中出现异常，则MCU向SOC发送重启指令，以控制SOC重启。

在本公开实施例中，通过在SOC进入到系统运行阶段后，监测SOC反馈的系统状态信息，并当在预设周期内未监测到SOC反馈的系统状态信息时控制SOC重启，由此，能够在车机系统运行过程中出现异常时及时重启SOC来使车机系统恢复正常运行，有效避免车机系统一直处于挂死或不正常运行状态。

在本公开的一种可选实施方式中，MCU在给SOC上电后，则建立与SOC之间的通信连接，以通过通信连接接收SOC反馈的各阶段的状态信息，其中，通信连接包括但不限于CAN总线连接、局域互联网络(Local Interconnect Network，LIN)连接等车载网络连接方式。由此，使得SOC上电后即可与MCU建立通信过程以进行交互，MCU可以通过通信连接及时获取SOC各启动阶段的状态信息，实时监测SOC的整个运行周期的状态，并在必要时及时重启SOC，能够在无人工介入的情况下，保证SOC成功进入系统运行阶段并保证车机系统的正常运行。

在本公开的一种可选实施方式中，所述通信连接为远程过程调用。本公开实施例中，MCU与SOC之间采用RPC进行通信，能够使得MCU像调用本地内容一样调用SOC上的内容，部署灵活，扩展性强。

图2为本公开另一实施例提供的控制方法的流程示意图，该控制方法可以由本公开实施例提供的控制装置执行，该控制装置可以采用软件和/或硬件实现，并可集成在车辆上，具体可以集成在车辆中车机的SOC上，车机还包括MCU，MCU与SOC之间进行通信连接。

如图2所示，本公开实施例提供的控制方法，可以包括以下步骤：

步骤201，接收所述车机的MCU发送的重启指令，所述重启指令为所述MCU在所述SOC的任一启动阶段对应的等待时长内未监测到所述任一启动阶段的状态信息而发送的。

本公开实施例中，MCU给SOC上电后，SOC开始启动，逐步进入SOC的各个启动阶段，比如XBL阶段、ABL阶段、Android系统内核启动阶段，等等。在启动过程中，SOC向MCU发送各阶段的状态信息。

在一种可选的实施方式中，SOC在发送某个启动阶段的状态信息的同时，还可以发送下一启动阶段的等待时长。

其中，下一启动阶段为SOC启动与发送的状态信息对应的目标阶段后进入的阶段。

示例性地，假设SOC在启动时，需要依次启动XBL阶段、ABL阶段和Android系统内核启动阶段，SOC启动XBL阶段后进入ABL阶段，SOC启动ABL阶段后进入Android系统内核启动阶段。则，SOC向MCU发送XBL阶段的状态信息时，还发送下一启动阶段即ABL阶段的等待时长，SOC向MCU发送ABL阶段的状态信息时，还发送下一启动阶段即Android系统内核启动阶段的等待时长。

MCU在SOC任一启动阶段对应的等待时长内，监测该启动阶段的状态信息，如果在等待时长内未监测到该启动阶段的状态信息，则向SOC发送重启指令，SOC接收MCU发送的重启指令。比如，MCU在ABL阶段对应的等待时长内未接收到ABL阶段的状态信息，则MCU向SOC发送重启指令。

步骤202，根据所述重启指令进行重启。

本公开实施例中，SOC接收到车机的MCU发送的重启指令后，可以自动进行重启，无需人工介入处理。

本公开实施例的控制方法，车机的SOC接收车机的MCU发送的重启指令，重启指令为MCU在SOC的任一启动阶段对应的等待时长内未监测到任一启动阶段的状态信息而发送的，并根据重启指令进行重启，由此，能够在SOC启动过程中出现故障时及时接收重启指令进行重启，无需用户介入处理即可完成自动重启操作，避免了车机启动过程中因出现故障但无人工介入导致车机无法正常启动的问题。

为了实现上述实施例，本公开还提供了一种控制装置。

图3为本公开一实施例提供的控制装置的结构示意图，该装置可以采用软件和/或硬件实现，并可集成在车辆上，具体可以集成在车辆中车机的MCU上，车机还包括SOC，MCU与SOC之间进行通信连接。

如图3所示，本公开实施例提供的控制装置30可以包括：监测模块301和重启控制模块302，其中：

监测模块301，用于在所述车机的SOC启动的过程中，依次监测所述SOC在每个启动阶段反馈的状态信息；

重启控制模块302，用于在任一所述启动阶段未监测到所述SOC反馈的状态信息时，向所述SOC发送重启指令。

可选地，所述监测模块301，还用于：

在所述每个启动阶段的等待时长内，监测所述SOC反馈的状态信息。

可选地，所述MCU预设有所述SOC的启动过程中的第一个启动阶段对应的标准等待时长，

所述控制装置30，还包括：

确定模块，用于确定所述每个启动阶段的等待时长；其中，

若所述启动阶段为所述第一个启动阶段，则将所述启动阶段的所述标准等待时长确定为所述启动阶段的等待时长；

若所述启动阶段非所述第一个启动阶段，则将所述SOC反馈前一启动阶段的状态信息时反馈的第一等待时长，确定为所述启动阶段的等待时长。

可选地，所述MCU还预设有所述SOC的启动过程中除所述第一个启动阶段外的其他启动阶段分别对应的标准等待时长，所述确定模块，还用于：

将所述启动阶段对应的等待时长由所述启动阶段对应的标准等待时长更新为所述第一等待时长。

可选地，所述监测模块301，还用于：

接收所述SOC在所述每个启动阶段反馈的反馈信息，所述反馈信息包括阶段标识和启动信息；

根据所述阶段标识，从所述MCU中预设的与所述每个启动阶段对应的参考信息中，获取与所述阶段标识对应的目标参考信息；

在所述启动信息与所述目标参考信息不一致的情况下，确定在所述阶段标识对应的目标启动阶段未监测到所述SOC反馈的状态信息；

在所述启动信息与所述目标参考信息一致的情况下，确定在所述阶段标识对应的目标启动阶段监测到所述SOC反馈的状态信息。

可选地，所述状态信息为所述SOC启动任一启动阶段后向所述MCU发送的用于表征所述任一启动阶段成功启动的反馈消息；或者，所述状态信息为所述SOC启动所述每个启动阶段的过程中产生的启动信息。

可选地，所述监测模块301还用于：

在所述SOC进入到系统运行阶段后，监测所述SOC反馈的系统状态信息；

所述重启控制模块302还用于：

如果在预设周期内未监测到所述SOC反馈的所述系统状态信息，则控制所述SOC重启。

可选地，所述控制装置30还包括：

通信建立模块，用于在给所述SOC上电后，建立与所述SOC之间的通信连接，以通过所述通信连接接收所述SOC反馈的各阶段的状态信息。

可选地，所述通信连接为远程过程调用。

本公开实施例所提供的可配置于车机的MCU上的控制装置，可执行本公开实施例所提供的任意应用于车机的MCU上的控制方法，具备执行方法相应的功能模块和有益效果。本公开装置实施例中未详尽描述的内容可以参考本公开任意方法实施例中的描述。

为了实现上述实施例，本公开还提供了一种控制装置。

图4为本公开一实施例提供的控制装置的结构示意图，该装置可以采用软件和/或硬件实现，并可集成在车辆上，具体可以集成在车辆中车机的SOC上，车机还包括MCU，所述SOC与所述MCU进行通信连接。

如图4所示，本公开实施例提供的控制装置40可以包括：接收模块401和重启模块402，其中：

接收模块401，用于接收所述车机的MCU发送的重启指令，所述重启指令为所述MCU在所述SOC的任一启动阶段对应的等待时长内未监测到所述任一启动阶段的状态信息而发送的；

重启模块402，用于根据所述重启指令进行重启。

本公开实施例所提供的可配置于车机的SOC上的控制装置，可执行本公开实施例所提供的任意应用于车机的SOC上的控制方法，具备执行方法相应的功能模块和有益效果。本公开装置实施例中未详尽描述的内容可以参考本公开任意方法实施例中的描述。

本公开实施例还提供了一种电子设备，包括：

至少一个处理器；

以及与所述至少一个处理器通信连接的存储器；其中，

所述至少一个处理器通过调用所述存储器存储的程序或指令，用于执行如前述任意实施例所述控制方法各实施例的步骤，为避免重复描述，在此不再赘述。

本公开实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质是非暂态的，所述计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行如前述任意实施例所述控制方法各实施例的步骤，为避免重复描述，在此不再赘述。

本公开实施例还提供了车机系统，包括本公开实施例提供的控制装置或本公开实施例提供的电子设备。

本公开实施例还提供了一种车辆，包括本公开实施例提供的控制装置或本公开实施例提供的电子设备或本公开实施例提供的车机系统。

本公开实施例还提供了一种计算机程序产品，所述计算机程序产品用于执行如前述任意实施例所述控制方法各实施例的步骤。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (14)

1.一种控制方法，其特征在于，用于车机的MCU，所述方法包括：

在车机的SOC启动的过程中，依次监测所述SOC在每个启动阶段反馈的状态信息；

若在任一所述启动阶段未监测到所述SOC反馈的状态信息，则向所述SOC发送重启指令。

2.根据权利要求1所述的方法，其特征在于，所述依次监测所述SOC在每个启动阶段反馈的状态信息，包括：

在所述每个启动阶段的等待时长内，监测所述SOC反馈的状态信息。

3.根据权利要求2所述的方法，其特征在于，所述MCU预设有所述SOC的启动过程中的第一个启动阶段对应的标准等待时长，所述在所述每个启动阶段的等待时长内，监测所述SOC反馈的状态信息之前，所述方法还包括：

确定所述每个启动阶段的等待时长；其中，

若所述启动阶段为所述第一个启动阶段，则将所述启动阶段的所述标准等待时长确定为所述启动阶段的等待时长；

若所述启动阶段非所述第一个启动阶段，则将所述SOC反馈前一启动阶段的状态信息时反馈的第一等待时长，确定为所述启动阶段的等待时长。

4.根据权利要求3所述的方法，其特征在于，所述MCU还预设有所述SOC的启动过程中除所述第一个启动阶段外的其他启动阶段分别对应的标准等待时长，所述将所述SOC反馈前一启动阶段的状态信息时反馈的第一等待时长，确定为所述启动阶段的等待时长，包括：

将所述启动阶段对应的等待时长由所述启动阶段对应的标准等待时长更新为所述第一等待时长。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述依次监测所述SOC在每个启动阶段反馈的状态信息，包括：

接收所述SOC在所述每个启动阶段反馈的反馈信息，所述反馈信息包括阶段标识和启动信息；

根据所述阶段标识，从所述MCU中预设的与所述每个启动阶段对应的参考信息中，获取与所述阶段标识对应的目标参考信息；

在所述启动信息与所述目标参考信息不一致的情况下，确定在所述阶段标识对应的目标启动阶段未监测到所述SOC反馈的状态信息；

在所述启动信息与所述目标参考信息一致的情况下，确定在所述阶段标识对应的目标启动阶段监测到所述SOC反馈的状态信息。

6.根据权利要求1-4任一项所述的方法，其特征在于，所述状态信息为所述SOC启动任一启动阶段后向所述MCU发送的用于表征所述任一启动阶段成功启动的反馈消息；或者，

所述状态信息为所述SOC启动所述每个启动阶段的过程中产生的启动信息。

7.根据权利要求1-4任一项所述的方法，其特征在于，所述方法还包括：

在所述SOC进入到系统运行阶段后，监测所述SOC反馈的系统状态信息；

如果在预设周期内未监测到所述SOC反馈的所述系统状态信息，则控制所述SOC重启。

8.一种控制方法，其特征在于，用于车机的SOC，所述方法包括：

接收所述车机的MCU发送的重启指令，所述重启指令为所述MCU在所述SOC的任一启动阶段对应的等待时长内未监测到所述任一启动阶段的状态信息而发送的；

根据所述重启指令进行重启。

9.一种控制装置，其特征在于，用于车机的MCU，所述装置包括：

监测模块，用于在车机的SOC启动的过程中，依次监测所述SOC在每个启动阶段反馈的状态信息；

重启控制模块，用于在任一所述启动阶段未监测到所述SOC反馈的状态信息时，向所述SOC发送重启指令。

10.一种控制装置，其特征在于，用于车机的SOC，所述装置包括：

接收模块，用于接收所述车机的MCU发送的重启指令，所述重启指令为所述MCU在所述SOC的任一启动阶段对应的等待时长内未监测到所述任一启动阶段的状态信息而发送的；

重启模块，用于根据所述重启指令进行重启。

11.一种电子设备，其特征在于，包括：

至少一个处理器；

以及与所述至少一个处理器通信连接的存储器；其中，

所述至少一个处理器通过调用所述存储器存储的程序或指令，用于执行如权利要求1至8任一项所述的控制方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行如权利要求1至8任一项所述的控制方法。

13.一种车机系统，其特征在于，包括如权利要求9或10所述的控制装置或如权利要求11所述的电子设备。

14.一种车辆，其特征在于，包括如权利要求9或10所述的控制装置或如权利要求11所述的电子设备或如权利要求13所述的车机系统。

Images