CN117312092A - 多核mcu的监控方法、装置、车辆及可读存储介质 - Google Patents

Abstract

本申请公开了一种多核MCU的监控方法、装置、车辆及可读存储介质，其方法包括：获取各个从核中从核监控任务对应的当前状态信息，以确定各个从核中是否存在处于挂死状态的目标从核；若存在处于挂死状态的目标从核，则确定所述目标从核处于挂死状态的第一持续时长；若所述第一持续时长达到对应第一预设时长，则执行所述目标从核对应的恢复操作。本申请通过从核监控任务对各个从核进行实时监控，并在从核中存在异常的目标从核时及时恢复该目标从核，以对多核MCU中异常的从核进行近视恢复，进而在多核系统中的从核出现异常的情况下及时有效地恢复从核，以及时恢复整个系统的正常运行。

Description

多核MCU的监控方法、装置、车辆及可读存储介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种多核MCU的监控方法、装置、车辆及可读存储介质。

背景技术

在计算机技术和电子技术迅猛发展的趋势下，将多个芯片集成于一个封装之内的多核技术逐渐成熟。多核系统中的每个核均可被看作为一个中央处理器(CPU)，以便提高多核系统的处理效率并减少处理延迟。然而，相关技术中心，难以在多核系统中的核出现异常的情况下及时有效地恢复系统运行。

发明内容

本申请的主要目的在于提供一种多核MCU的监控方法、装置、车辆及可读存储介质，旨在解决相关技术无法在多核系统中的核出现异常的情况下及时有效地恢复系统运行的技术问题。

为实现上述目的，本申请提供一种多核MCU的监控方法，应用于多核MCU的主核，所述多核MCU该包括多个从核；各个所述从核设有多个不同周期的从核监控任务，所述多核MCU的监控方法包括以下步骤：

获取各个从核中从核监控任务对应的当前状态信息，以确定各个从核中是否存在处于挂死状态的目标从核；

若存在处于挂死状态的目标从核，则确定所述目标从核处于挂死状态的第一持续时长；

若所述第一持续时长达到对应第一预设时长，则执行所述目标从核对应的恢复操作。

进一步地，所述获取各个从核中从核监控任务对应的当前状态信息，以确定各个从核中是否存在处于挂死状态的目标从核的步骤包括：

获取各个从核的从核监控任务对应的当前状态信息；

若存在当前状态信息与对应从核监控任务的记录状态信息不一致的第一从核监控任务，则更新第一从核监控任务对应的记录状态信息；

基于各个从核监控任务的记录状态信息，确定各个从核中是否存在处于挂死状态的目标从核。

进一步地，所述基于各个从核监控任务的记录状态信息，确定各个从核中是否存在处于挂死状态的目标从核的步骤包括：

基于各个从核监控任务的记录状态信息，确定各个从核监控任务对应记录状态信息的更新持续时长；

基于各个更新持续时长，确定各个从核中是否存在处于挂死状态的目标从核。

进一步地，所述基于各个更新持续时长，确定各个从核中是否存在处于挂死状态的目标从核的步骤包括：

确定各个更新持续时长中是否存在大于对应第二预设时长的第二持续时长；

若各个更新持续时长中存在大于对应第二预设时长的第二持续时长，则将所述第二持续时长对应的从核作为所述目标从核。

进一步地，所述获取各个从核的从核监控任务对应的当前状态信息的步骤包括：

通过Pport接口接收各个从核的从核监控任务对应的当前状态信息，其中，对于每一个从核，所述从核运行从核监控任务，并基于所述从核的任务调度信息通过所述从核的Pport接口反馈对应从核监控任务的当前状态信息。

进一步地，所述若所述持续时长达到预设时长，则执行所述目标从核对应的恢复操作的步骤包括：

若所述持续时长达到预设时长，则获取所述目标从核对应的调度表；

重启所述调度表，并输出所述目标从核对应的错误信息。

进一步地，所述重启所述调度表，并输出所述目标从核对应的错误信息的步骤之后，还包括：

在所述调度表重启完成时，重置所述第一持续时长以及所述第二持续时长。

进一步地，所述主核设有多个不同周期的主核监控任务，所述多核MCU的监控方法还包括：

基于各个主核监控任务对应的状态信息，确定所述主核是否处于挂死状态；

若所述主核处于挂死状态，则确定所述主核处于挂死状态的第三持续时长；

若所述第三持续时长达到对应第三预设时长，则重启所述多核MCU对应的系统。

此外，为实现上述目的，本申请还提供一种多核MCU的监控装置应用于包括多核MCU的主核，所述多核MCU该包括多个从核；各个所述从核设有多个不同周期的从核监控任务，所述多核MCU的监控装置包括：

获取模块，用于获取各个从核中从核监控任务对应的状态信息，以确定各个从核中是否存在处于挂死状态的目标从核；

确定模块，用于若存在处于挂死状态的目标从核，则确定所述目标从核处于挂死状态的第一持续时长；

恢复模块，用于若所述第一持续时长达到对应第一预设时长，则执行所述目标从核对应的恢复操作。

此外，为实现上述目的，本申请还提供一种车辆，所述车辆包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的多核MCU的监控程序，所述多核MCU的监控程序被所述处理器执行时实现前述的多核MCU的监控方法的步骤。

此外，为实现上述目的，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有多核MCU的监控程序，所述多核MCU的监控程序被处理器执行时实现前述的多核MCU的监控方法的步骤。

本申请通过获取各个从核中从核监控任务对应的状态信息，以确定各个从核中是否存在处于挂死状态的目标从核；接着若存在处于挂死状态的目标从核，则确定所述目标从核处于挂死状态的第一持续时长；而后若所述第一持续时长达到对应第一预设时长，则执行所述目标从核对应的恢复操作，通过从核监控任务对各个从核进行实时监控，并在从核中存在异常的目标从核时及时恢复该目标从核，以对多核MCU中异常的从核进行近视恢复，进而在多核系统中的从核出现异常的情况下及时有效地恢复从核，以及时恢复整个系统的正常运行。

附图说明

图1为本申请多核MCU的监控方法第一实施例的流程示意图；

图2为本申请实施例的一种可能性场景示意图；

图3为本申请实施例的另一种可能性场景示意图；

图4为本申请实施例的又一种可能性场景示意图；

图5是本申请实施例方案涉及的硬件运行环境中车辆的结构示意图；

图6为本申请实施例车辆一实施例的功能模块示意图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

目前，在计算机技术和电子技术迅猛发展的趋势下，将多个芯片集成于一个封装之内的多核技术逐渐成熟。多核系统中的每个核均可被看作为一个中央处理器(CPU)，以便提高多核系统的处理效率并减少处理延迟。

在多核系统中，通常采用流水线或者并行处理等工作方式来完成待处理任务。在流水线工作方式下，待处理任务被分成多个部分，每个核完成其中的一个部分。只有前面的核完成处理后，后面的核才继续执行该任务的后续部分，并在最后一个核结束处理后输出处理结果。在并行处理工作方式下，每个核都能够独立地执行待处理任务，并输出处理结果。

对于多核系统，由于所运行程序中存在的潜在错误以及恶劣环境干扰等因素会导致核出现异常而无法运行，因此为了保证该系统能够在无人干预下自动恢复正常，目前，对多核系统进行监控并执行异常情况下的系统复位时，在多核系统中设置一个作为监控装置的看门狗芯片，并且该看门狗的输出端与多核系统的复位端相连。多核系统中的每个核都可以在运行正常的情况下定期对看门狗清零，以保证该看门狗不会溢出，从而不会对该多核系统进行复位。当所有核均发生故障而无法执行清零操作时，看门狗因未被清零而溢出，则整个多核系统被复位。

在上述的监控方法下，只有等到全部核均处于异常状态时，才能够对多核系统进行复位。那么，当多核系统采用流水线工作方式时，任何一个核出现故障都会导致待处理任务无法正常执行，即需要对整个多核系统进行复位，然而当多核系统中存在正常运行的核时无法执行复位，则必须等待全部的核均出现故障。当多核系统采用并行处理工作方式时，当仅有几个核出现异常时，也必须等待全部核均出现故障时才能够对多核系统进行复位；并且由于并行处理工作方式下，各个核能够相互独立地工作，每个核的故障均不会中断多核系统的运行，则当存在处于正常状态的核时，无需对多核系统进行整体复位，导致无法在多核系统中的核出现异常的情况下及时有效地恢复系统运行。

基于上述相关技术中存在的问题，本申请提供了一种多核MCU的监控方法，通过在从核设置多个不同周期的从核监控任务，主核监控从核监控任务的状态信息，通过获取各个从核中从核监控任务对应的状态信息，以确定各个从核中是否存在处于挂死状态的目标从核；若存在处于挂死状态的目标从核，则确定所述目标从核处于挂死状态的第一持续时长；若所述第一持续时长达到对应第一预设时长，则执行所述目标从核对应的恢复操作，进而在各个从核中存在异常的从核时，通过对异常的从核进行恢复，以在多核系统中的从核出现异常的情况下及时有效地恢复从核，以及时恢复整个系统的正常运行。

为了便于理解，结合附图和应用场景，对本申请实施例提供的多核MCU的监控方法进行具体阐述。

本申请还提供一种多核MCU的监控方法，参照图1，图1为本申请多核MCU的监控方法第一实施例的流程示意图。

该多核MCU的监控方法应用于多核MCU的主核，多核MCU该包括主核以及多个从核；各个所述从核设有多个不同周期的从核监控任务。

如图2所示，多核MCU该包括主核(Master)Core0以及多个从核Core1、Core2…CoreN；基于AUTOSAR架构设计，利用AUTOSAR OS的设计思想，把每个独立的Core分配单独的监控任务Application，如图3所示，Core0运行Application 0，Application 0包括主核监控任务Task Supervision、主核监控任务Task 1ms、主核监控任务Task 10ms以及主核监控任务Task 50ms。Core1运行Application 1，Application 1包括从核监控任务Task 1ms、从核监控任务Task 10ms以及从核监控任务Task 50ms。Core2运行Application 2，Application2包括从核监控任务Task 1ms、从核监控任务Task 10ms以及从核监控任务Task 50ms。其中Core0的Task Supervision配置为最高优先级的任务，能够在其他task卡死的时候也可以运行。主核通过Task Supervision监控从核的Application。其中，Task1ms、Task 10ms以及Task 50ms等各个监控任务的时间阈值可以根据主核或者从核所执行任务的耗时进行合理设置，主核或者每一个从核可同时运行一个或多个Task。

步骤S101，获取各个从核中从核监控任务对应的当前状态信息，以确定各个从核中是否存在处于挂死状态的目标从核；

在进行从核监控时，主核可获取从核中从核监控任务对应的当前状态信息，具体地，在一可能实现非方式中，该步骤S101包括：

步骤S1011，通过Pport接口接收各个从核的从核监控任务对应的当前状态信息，其中，对于每一个从核，所述从核运行从核监控任务，并基于所述从核的任务调度信息通过所述从核的Pport接口反馈对应从核监控任务的当前状态信息。

对于每一个从核，从核运行从核监控任务，并基于所述从核的任务调度信息通过所述从核的Pport接口反馈对应从核监控任务的当前状态信息，该从核的Application运行当前执行任务对应的Task，例如当Core1任务调度时，调用Application1的1ms Task，通过Pport接口(checkpoint)将1ms Task对应的状态信息alive counter发送至Core0，Core0的1ms Task利用Rport接收该alive counter。

接着，主核基于从核监控任务对应的状态信息，确定各个从核中是否存在处于挂死状态的目标从核，具体地，主核确定各个从核监控任务对应的状态信息是否存在变化，并根据不存在变化的状态信息的持续时长，确定各个从核中是否存在处于挂死状态Deadtask的目标从核。

步骤S102，若存在处于挂死状态的目标从核，则确定所述目标从核处于挂死状态的第一持续时长；

若确定各个从核中存在处于挂死状态的目标从核，则确定所述目标从核处于挂死状态的第一持续时长，具体地，主核在该目标从核的状态信息未变化持续时长达到对应预设时长时，将该目标从核设置为挂死状态Dead task，并累计该目标从核处于挂死状态Deadtask的第一持续时长。

步骤S103，若所述第一持续时长达到对应第一预设时长，则执行所述目标从核对应的恢复操作。

在获取到目标从核处于挂死状态的第一持续时长时，确定该第一持续时长是否达到对应的第一预设时长，该第一预设时长可根据导致该目标从核处于挂死状态的从核监控任务进行合理设置。

若该第一持续时长达到对应第一预设时长，则执行所述目标从核对应的恢复操作，例如，获取该目标从核对应的调度表，重启该调度表以恢复该目异常的目标从核。

若该第一持续时长达到对应第一预设时长之前，接收到导致该目标从核处于挂死状态的从核监控任务的状态信息，且接收到的状态信息与记录状态信息不一致，则将该目标从核的挂死状态更新为正常状态，并重置第一持续时长。

通过获取各个从核中从核监控任务对应的状态信息，以确定各个从核中是否存在处于挂死状态的目标从核；接着若存在处于挂死状态的目标从核，则确定所述目标从核处于挂死状态的第一持续时长；而后若所述第一持续时长达到对应第一预设时长，则执行所述目标从核对应的恢复操作，通过从核监控任务对各个从核进行实时监控，并在从核中存在异常的目标从核时及时恢复该目标从核，以对多核MCU中异常的从核进行近视恢复，进而在多核系统中的从核出现异常的情况下及时有效地恢复从核，以及时恢复整个系统的正常运行。

基于第一实施例，提出本申请多核MCU的监控方法的第二实施例，其中，步骤S101包括：

步骤S201，获取各个从核的从核监控任务对应的当前状态信息；

步骤S202，若存在当前状态信息与对应从核监控任务的记录状态信息不一致的第一从核监控任务，则更新第一从核监控任务对应的记录状态信息；

步骤S203，基于各个从核监控任务的记录状态信息，确定各个从核中是否存在处于挂死状态的目标从核。

在进行从核监控时，主核获取各个从核的从核监控任务对应的当前状态信息，具体地，主核通过Pport接口接收各个从核的从核监控任务对应的当前状态信息，对于每一个从核，从核运行从核监控任务，并基于所述从核的任务调度信息通过所述从核的Pport接口反馈对应从核监控任务的当前状态信息，该从核的Application运行当前执行任务对应的Task，例如当Core1任务调度时，调用Application1的1ms Task，通过Pport接口(checkpoint)将1ms Task对应的状态信息alive counter发送至Core0，Core0的1ms Task利用Rport接收该alive counter。

接着，主核基于从核监控任务对应的状态信息，确定各个从核中是否存在处于挂死状态的目标从核，具体地，主核确定从核监控任务中是否存在当前状态信息与对应从核监控任务的记录状态信息不一致的第一从核监控任务，其中，记录状态信息为主核所记录的当前时刻之前从核监控任务的状态信息，若存在当前状态信息与对应从核监控任务的记录状态信息不一致的第一从核监控任务，则主核更新第一从核监控任务对应的记录状态信息，即将不一致的第一从核监控任务的当前状态信息作为对应新的记录状态信息。

完成记录状态信息的更新之后，主核基于各个从核监控任务的记录状态信息，确定各个从核中是否存在处于挂死状态的目标从核。具体地，在一可能实现非方式中，该步骤S203包括：

步骤S2031，基于各个从核监控任务的记录状态信息，确定各个从核监控任务对应记录状态信息的更新持续时长；

步骤S2032，基于各个更新持续时长，确定各个从核中是否存在处于挂死状态的目标从核。

完成记录状态信息的更新之后，主核基于各个从核监控任务的记录状态信息，确定各个从核监控任务对应记录状态信息的更新持续时长，其中，在每一次更新从核监控任务对应记录状态信息时，主核重新累计对应记录状态信息的更新持续时长，以获得每一个从核监控任务对应记录状态信息的更新持续时长。

获取到每一个从核监控任务对应记录状态信息的更新持续时长之后，主核基于各个更新持续时长，确定各个从核中是否存在处于挂死状态的目标从核，以通过各个更新持续时长准确检测当前处于挂死状态的目标从核，具体地，在一可能实现非方式中，该步骤S2032包括：

步骤a，确定各个更新持续时长中是否存在大于对应第二预设时长的第二持续时长；

步骤b，若各个更新持续时长中存在大于对应第二预设时长的第二持续时长，则将所述第二持续时长对应的从核作为所述目标从核。

获取到每一个从核监控任务对应记录状态信息的更新持续时长之后，主核获取每一个从核监控任务对应的第二预设时长，即可获得每一个更新持续时长对应的第二预设时长，并确定各个更新持续时长中是否存在大于对应第二预设时长的第二持续时长，其中，第二预设时长可根据对应从核的从核监控任务进行合理设置。

若各个更新持续时长中存在大于对应第二预设时长的第二持续时长，则主核将所述第二持续时长对应的从核作为所述目标从核，以准确确定异常的目标从核，提升从核监控的准确性。

通过获取各个从核的从核监控任务对应的当前状态信息；接着若存在当前状态信息与对应从核监控任务的记录状态信息不一致的第一从核监控任务，则更新第一从核监控任务对应的记录状态信息；而后基于各个从核监控任务的记录状态信息，确定各个从核中是否存在处于挂死状态的目标从核，可以根据从核监控任务对应的当前状态信息准确确定处于挂死状态的目标从核，以便于在目标从核异常时及时恢复该目标从核，以对多核MCU中异常的从核进行近视恢复，进而在多核系统中的从核出现异常的情况下及时有效地恢复从核，以及时恢复整个系统的正常运行。

基于第一实施例，提出本申请多核MCU的监控方法的第三实施例，其中，步骤S103包括：

步骤S301，若所述持续时长达到预设时长，则获取所述目标从核对应的调度表；

步骤S302，重启所述调度表，并输出所述目标从核对应的错误信息。

在获取到目标从核处于挂死状态的第一持续时长时，确定该第一持续时长是否达到对应的第一预设时长，该第一预设时长可根据导致该目标从核处于挂死状态的从核监控任务进行合理设置。

若该第一持续时长达到对应第一预设时长，则确定该目标从核异常，进而获取所述目标从核对应的调度表。

获取到目标从核对应的调度表之后，执行所述目标从核对应的恢复操作，具体地，重启所述调度表，并输出所述目标从核对应的错误信息，即将该错误信息打印到CAN和DLT上。

其中，重启所述调度表的过程为：关闭调度表，关闭调度表之后的持续时间地点预设等待时长Core Recovery Time时，启动该调度表。如图4所示，图4为Core状态打印变化的示意图，其中，Core Timeout Time为第一预设时长，Task Timeout Time为第二预设时长，Core Recovery Time为重启该调度表的耗时。当TaskError发生后，需要等待(TaskTimeout Time)+(Core Timeout Time)后则认为此Core异常，并尝试恢复。在关闭调度表ScheduleTable后等待(Core Recovery Time)，再重新打开调度表，如果打开无法恢复则一直周期尝试，直到恢复正常。

进一步地，在一可能实现非方式中，该步骤S302之后，该多核MCU的监控方法还包括：

步骤c，在所述调度表重启完成时，重置所述第一持续时长以及所述第二持续时长。

在调度表重启完成时，通过重置所述第一持续时长以及所述第二持续时长，实现对目标从核以及导致该目标从核异常的从核监控任务进行重新监控。

通过若所述持续时长达到预设时长，则获取所述目标从核对应的调度表；接着重启所述调度表，并输出所述目标从核对应的错误信息，通过重启目标从核对应的调度表实现对该异常的目标从核的恢复，进而及时恢复该目标从核，以对多核MCU中异常的从核进行近视恢复，进而在多核系统中的从核出现异常的情况下及时有效地恢复从核，以及时恢复整个系统的正常运行。

基于上述各个实施例，提出本申请多核MCU的监控方法的第四实施例，其中，主核设有多个不同周期的主核监控任务，该多核MCU的监控方法还包括：

步骤S401，基于各个主核监控任务对应的状态信息，确定所述主核是否处于挂死状态；

步骤S402，若所述主核处于挂死状态，则确定所述主核处于挂死状态的第三持续时长；

步骤S403，若所述第三持续时长达到对应第三预设时长，则重启所述多核MCU对应的系统。

主核也可以设置多个不同周期的主核监控任务，以实现对主核的监控，具体的，基于各个主核监控任务对应的状态信息，确定所述主核是否处于挂死状态，其中主核是否处于挂死状态与从核是否处于挂死状态的判断方式类似，在此不再赘述。

若主核处于挂死状态，则确定所述主核处于挂死状态的第三持续时长；若第三持续时长达到对应第三预设时长，则重启多核MCU对应的系统，也就是说，在主核异常时，可直接重启多核MCU对应的系统，以实现多核MCU对应的系统的恢复。

通过基于各个主核监控任务对应的状态信息，确定所述主核是否处于挂死状态；接着若所述主核处于挂死状态，则确定所述主核处于挂死状态的第三持续时长；而后若所述第三持续时长达到对应第三预设时长，则重启所述多核MCU对应的系统，通过监控到主核异常时，重启多核MCU对应的系统实现整个系统的恢复，进而在多核系统中的从核出现异常的情况下及时有效地恢复从核，以及时恢复整个系统的正常运行。

此外，本申请实施例还提出一种车辆，如图5所示，图5是本申请实施例方案涉及的硬件运行环境中车辆的结构示意图。

如图5所示，该车辆可以包括：处理器1001，例如CPU，网络接口1004，用户接口1003，存储器1005，通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

可选地，车辆还可以包括摄像头、RF(Radio Frequency，射频)电路，传感器、音频电路、WiFi模块等等。其中，传感器比如光传感器、运动传感器以及其他传感器。当然，车辆还可配置陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

本领域技术人员可以理解，图5中示出的终端结构并不构成对车辆的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图5所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及多核MCU的监控程序。

在图5所示的车辆中，网络接口1004主要用于连接后台服务器，与后台服务器进行数据通信；用户接口1003主要用于连接客户端(用户端)，与客户端进行数据通信；而处理器1001可以用于调用存储器1005中存储的多核MCU的监控程序。

在本实施例中，车辆包括：存储器1005、处理器1001及存储在所述存储器1005上并可在所述处理器1001上运行的多核MCU的监控程序，其中，处理器1001调用存储器1005中存储的多核MCU的监控程序时，并执行如上所述的多核MCU的监控方法的步骤。

此外，本申请还提出一种多核MCU的监控装置，应用于包括多核MCU的主核，所述多核MCU该包括多个从核；各个所述从核设有多个不同周期的从核监控任务，参照图6，所述多核MCU的监控装置包括：

获取模块10，用于获取各个从核中从核监控任务对应的状态信息，以确定各个从核中是否存在处于挂死状态的目标从核；

确定模块20，用于若存在处于挂死状态的目标从核，则确定所述目标从核处于挂死状态的第一持续时长；

恢复模块30，用于若所述第一持续时长达到对应第一预设时长，则执行所述目标从核对应的恢复操作。

上述各程序单元所执行的方法可参照本申请多核MCU的监控方法各个实施例，此处不再赘述。

此外，本申请实施例还提出一种计算机可读存储介质，所述计算机可读存储介质上存储有多核MCU的监控程序，所述多核MCU的监控程序被处理器执行时实现上所述的多核MCU的监控方法的步骤。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。

以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (11)

1.一种多核MCU的监控方法，其特征在于，应用于多核MCU的主核，所述多核MCU该包括多个从核；各个所述从核设有多个不同周期的从核监控任务，所述多核MCU的监控方法包括以下步骤：

获取各个从核中从核监控任务对应的当前状态信息，以确定各个从核中是否存在处于挂死状态的目标从核；

若存在处于挂死状态的目标从核，则确定所述目标从核处于挂死状态的第一持续时长；

若所述第一持续时长达到对应第一预设时长，则执行所述目标从核对应的恢复操作。

2.如权利要求1所述的多核MCU的监控方法，其特征在于，所述获取各个从核中从核监控任务对应的当前状态信息，以确定各个从核中是否存在处于挂死状态的目标从核的步骤包括：

获取各个从核的从核监控任务对应的当前状态信息；

若存在当前状态信息与对应从核监控任务的记录状态信息不一致的第一从核监控任务，则更新第一从核监控任务对应的记录状态信息；

基于各个从核监控任务的记录状态信息，确定各个从核中是否存在处于挂死状态的目标从核。

3.如权利要求2所述的多核MCU的监控方法，其特征在于，所述基于各个从核监控任务的记录状态信息，确定各个从核中是否存在处于挂死状态的目标从核的步骤包括：

基于各个从核监控任务的记录状态信息，确定各个从核监控任务对应记录状态信息的更新持续时长；

基于各个更新持续时长，确定各个从核中是否存在处于挂死状态的目标从核。

4.如权利要求3所述的多核MCU的监控方法，其特征在于，所述基于各个更新持续时长，确定各个从核中是否存在处于挂死状态的目标从核的步骤包括：

确定各个更新持续时长中是否存在大于对应第二预设时长的第二持续时长；

若各个更新持续时长中存在大于对应第二预设时长的第二持续时长，则将所述第二持续时长对应的从核作为所述目标从核。

5.如权利要求2所述的多核MCU的监控方法，其特征在于，所述获取各个从核的从核监控任务对应的当前状态信息的步骤包括：

通过Pport接口接收各个从核的从核监控任务对应的当前状态信息，其中，对于每一个从核，所述从核运行从核监控任务，并基于所述从核的任务调度信息通过所述从核的Pport接口反馈对应从核监控任务的当前状态信息。

6.如权利要求1所述的多核MCU的监控方法，其特征在于，所述若所述持续时长达到预设时长，则执行所述目标从核对应的恢复操作的步骤包括：

若所述持续时长达到预设时长，则获取所述目标从核对应的调度表；

重启所述调度表，并输出所述目标从核对应的错误信息。

7.如权利要求6所述的多核MCU的监控方法，其特征在于，所述重启所述调度表，并输出所述目标从核对应的错误信息的步骤之后，还包括：

在所述调度表重启完成时，重置所述第一持续时长以及第二持续时长。

8.如权利要求1至7任一项所述的多核MCU的监控方法，其特征在于，所述主核设有多个不同周期的主核监控任务，所述多核MCU的监控方法还包括：

基于各个主核监控任务对应的状态信息，确定所述主核是否处于挂死状态；

若所述主核处于挂死状态，则确定所述主核处于挂死状态的第三持续时长；

若所述第三持续时长达到对应第三预设时长，则重启所述多核MCU对应的系统。

9.一种多核MCU的监控装置，其特征在于，应用于包括多核MCU的主核，所述多核MCU该包括多个从核；各个所述从核设有多个不同周期的从核监控任务，所述多核MCU的监控装置包括：

获取模块，用于获取各个从核中从核监控任务对应的状态信息，以确定各个从核中是否存在处于挂死状态的目标从核；

确定模块，用于若存在处于挂死状态的目标从核，则确定所述目标从核处于挂死状态的第一持续时长；

恢复模块，用于若所述第一持续时长达到对应第一预设时长，则执行所述目标从核对应的恢复操作。

10.一种车辆，其特征在于，所述车辆包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的多核MCU的监控程序，所述多核MCU的监控程序被所述处理器执行时实现如权利要求1至8中任一项所述的多核MCU的监控方法的步骤。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有多核MCU的监控程序，所述多核MCU的监控程序被处理器执行时实现如权利要求1至8中任一项所述的多核MCU的监控方法的步骤。