CN117827301A - 一种状态管理方法、配置文件生成方法及设备 - Google Patents

Abstract

一种状态管理方法、配置文件生成方法及设备，应用于包括多个控制单元的可移动智能设备，每个控制单元包括多个功能组，每个功能组包括多个进程。每个功能组有至少两个状态，控制单元通过控制功能组的状态切换，从而完成对控制单元中进程的控制。多个控制单元中至少两个控制单元对应同一功能组。在确定需要将第一功能组由第一状态切换为第二状态的情况下，可以根据包括有每个控制单元和功能组对应关系的第一配置文件，确定对应第一功能组的目标控制单元，并控制目标控制单元中对应第一功能组的进程进行状态切换。通过上述方法，在多个控制单元存在相同的功能组时，通过上述第一配置文件，能够对多个控制单元中的相同功能组进行集中的状态管理。

Description

一种状态管理方法、配置文件生成方法及设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种状态管理方法、配置文件生成方法及设备。

背景技术

车辆控制单元是一种安装在车辆上，负责控制车辆正常运行的器件，是车辆的重要组成部分。汽车开放系统架构(automotive open system architecture,AUTOSAR)是汽车行业制定的一种标准化软件架构。AUTOSAR的自适应平台(adaptive platform，AP)是为了适应车辆功能不断增加的情况而提出的一种灵活、可配置和安全的软件架构。AP软件架构是车辆控制单元可以使用的软件架构之一。

基于AP软件架构的车辆控制单元中，一般将用于实现某个功能的多个进程集合称为功能组(function group)。状态管理(state management，SM)是上述车辆控制单元中用于控制功能组状态切换的进程。SM通过控制功能组的状态切换，可以控制功能组对应的进程的运行状态，从而使得车辆可以实现相应的功能。比如某个功能组的状态从关闭切换为开启，那么该功能组对应的进程也会相应启动，从而实现相应功能。

随着智能驾驶技术的发展，需要车辆控制单元执行的功能也越来越多，对车辆控制单元的算力和安全性要求也越来越高。为了提高车辆控制单元的算力，并满足车辆的安全性要求，车辆朝着集成多个车辆控制单元的方向发展。比如，在一个车辆上集成多个基于AP软件架构的车辆控制单元，不同的车辆控制单元可以实现不同功能，或者不同车辆控制单元功能相同，多个车辆控制单元可以协同完成计算。

在一个车辆上集成有多个车辆控制单元的情况下，多个车辆控制单元中可能存在相同的功能组，那么就需要对多个车辆控制单元的相同功能组进行协同管理，也即属于不同车辆控制单元的多个功能组的状态需要一起进行切换。比如，在车辆需要进行操作系统升级的情况下，往往需要多个车辆控制单元的操作系统一起进行升级，也即多个车辆控制单元中实现升级功能的功能组需要一起由关闭状态切换至开启状态。

而现有技术中，在一个车辆上集成了多个基于AP软件架构的车辆控制单元的场景下，缺少一种对多个车辆控制单元的功能组状态进行协同管理的方法。

发明内容

本申请提供一种状态管理方法、配置文件生成方法及设备，解决了现有技术中无法对多个车辆控制单元的功能组状态进行协同管理的问题。

根据本申请的第一方面，提供一种状态管理方法，应用于包括多个控制单元的可移动智能设备，其中，每个控制单元都包括多个功能组，每个功能组包括用于实现相同功能的多个进程。每个功能组有能进行切换的两个状态，控制单元通过控制功能组的状态切换，从而完成对控制单元中进程的控制。其中，上述多个控制单元中至少两个控制单元对应同一功能组。在确定需要将第一功能组由第一状态切换为第二状态的情况下，可以根据包括有每个控制单元和功能组对应关系的第一配置文件，确定对应第一功能组的目标控制单元，并控制目标控制单元中对应第一功能组的进程进行状态切换。该可移动智能设备包括车辆。通过上述方法，在多个控制单元存在相同的功能组时，通过上述第一配置文件，可以确定对应第一功能组的目标控制单元，并控制目标控制单元第一功能组对应进程完成状态切换，从而能够对多个控制单元中的相同功能组进行统一的状态管理。当该可移动智能设备为车辆时，多个车辆控制单元的第一功能组可以一起完成状态切换，解决了现有技术无法对多个车辆控制单元的功能组进行协同管理的问题。

在一可选实施方式中，可移动智能设备还可以包括状态管理中心，上述确定目标控制单元和控制状态切换的步骤均为状态管理中心执行的。具体而言，状态管理中心先根据第一配置文件，从多个控制单元中确定对应第一功能组的目标控制单元。再向目标控制单元发送指示第一功能组由第一状态切换为第二状态的状态切换指令。目标控制单元接收状态切换指令后，便可以根据该指令控制第一功能组对应的进程的状态切换。这样，通过状态管理中心，可以实现集中式状态管理，简化状态管理流程。

在一可选实施方式中，每个控制单元除了包括功能组对应的进程，还可以包括状态管理节点和执行管理节点。上述目标控制单元控制第一功能组对应的进程完成状态切换，具体可以是目标控制单元的状态管理节点接收状态切换指令，并将该状态切换指令转发给当前目标控制单元的执行管理节点。该执行管理节点根据接收的状态切换指令和指示有该控制单元中功能组和功能组对应的状态信息的第二配置文件，控制目标控制单元中对应第一功能组的进程进行状态切换。状态管理中心只需要和控制单元中的状态管理节点通信，不需要和控制单元中的多个进程进行通信，简化了状态管理流程，提高了状态管理效率。

在一可选实施方式中，状态管理中心可以部署在多个控制单元中可靠性最高的控制单元。这样，状态管理中心所在的控制单元更不容易故障，保障了状态管理中心的正常工作，从而保证了可移动智能设备为车辆时，车辆的功能可以正常启动或关闭，保证车辆的正常运行。

在一可选实施方式中，在目标控制单元中所有控制单元对应的第一功能组都状态切换成功的情况下，显示指示第一功能组的状态切换成功的提示信息。此外，目标控制单元包括两种控制单元，一种是安全等级大于预设阈值的控制单元，另一种是安全等级小于等于预设阈值的控制单元，在安全等级小于等于预设阈值的控制单元故障的情况下，可以仅根据安全等级大于预设阈值的控制单元的状态切换结果来确定是否状态切换成功，并在状态切换成功的情况下显示提示信息。这样可以保证即使安全等级小于等于预设阈值的控制单元故障，安全等级大于预设阈值的控制单元也可以正常运行一段时间，保证可移动智能设备基本的安全功能可以正常运行，保证使用可移动智能设备的用户的安全。

在一可选实施方式中，第一配置文件中包括每个控制单元的标识，以及每个控制单元的标识对应的功能组的标识，以指示控制单元和功能组的对应关系。或者，第一配置文件可以包括每个控制单元的标识，与每个控制单元的标识对应的功能组的标识，以及与控制单元的SoC的标识，以在存在多个SoC的情况下，指示多个控制单元与功能组的对应关系。这样，通过第一配置文件的上述标识，使得可移动智能设备可以对多个控制单元的功能组状态切换进行统一管理。

根据本申请的第二方面，提供一种配置文件生成方法，包括：获取至少两个第三配置文件，每个第三配置文件是可移动智能设备上的一个控制单元的配置文件，可移动智能设备和本申请第一方面的可移动智能设备相同。并根据至少两个第三配置文件，生成可移动智能设备的第一配置文件，第一配置文件指示可移动智能设备上多个控制单元与功能组的对应关系。通过生成第一配置文件，使得可移动智能设备可以根据第一配置文件来确定包括第一功能组的目标控制单元，从而在对应第一功能组的目标控制单元有多个的情况下，可以控制多个目标控制单元的第一功能组一起进程状态切换，实现了对功能组的状态切换进行统一管理。

在一可选实施方式中，第一配置文件中包括每个控制单元的标识，以及每个控制单元的标识对应的功能组的标识，以指示控制单元和功能组的对应关系。或者，第一配置文件可以包括每个控制单元的标识，与每个控制单元的标识对应的功能组的标识，以及与控制单元的SoC的标识，以在存在多个SoC的情况下，指示多个控制单元与功能组的对应关系。这样，通过第一配置文件的上述标识，使得可移动智能设备可以对多个控制单元的功能组状态切换进行统一管理。

在一可选实施方式中，第一配置文件包括的控制单元的标识，是根据第三配置文件中的用于标识控制单元的第一标识生成的。通过第三配置文件中的标识来生成第一配置文件中控制单元的标识，使得第一配置文件中可以增加用于区分不同控制单元对应的数据的标识，从而可移动智能设备可以根据第一配置文件来确定对应第一功能组的目标控制单元。且无需改变现有技术中的配置方法，配置可移动智能设备更加灵活。

根据本申请的第三方面，提供一种可移动智能设备，包括存储器和处理器，存储器用于存储计算机程序，处理器用于执行计算机程序，实现上述第一方面的状态管理方法。

根据本申请的第四方面，提供一种电子设备，包括存储器和处理器，存储器用于存储计算机程序，处理器用于执行计算机程序，实现上述第二方面的配置文件生成方法。

根据本申请的第五方面，提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序用于实现上述第一方面或第二方面的方法。

根据本申请的第六方面，提供一种计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当计算机可读代码在电子设备中运行时，电子设备中的处理器执行上述第一方面或第二方面的方法。

根据本申请的第七方面，提供一种装置，该装置具有实现上述第一方面或第二方面的方法中设备行为的功能。功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块。

应当理解的是，上述第三方面，第四方面，第五方面，第六方面以及第七方面提供的技术方案，其技术特征均可对应到第一方面及其可选的实施方式中提供的方法，因此能够达到的有益效果类似，此处不再赘述。

附图说明

图1为本申请提供的一种功能组与进程的关系的示意图；

图2为本申请提供的一种状态管理控制进程运行过程的示意图；

图3为本申请提供的一种多个控制单元协同管理方法的示意图；

图4为可以应用本申请实施例的系统架构的简化示意图；

图5为本申请实施例提供的一种状态管理方法的流程图；

图6为本申请实施例提供的另一种状态管理方法的示意图；

图7为本申请实施例提供的一种配置文件生成方法的流程图；

图8为本申请实施例提供的又一种状态管理方法的示意图；

图9为本申请实施例提供的另一种配置文件生成方法的示意图；

图10为本申请实施例提供的一种可移动智能设备的示意图；

图11为本申请实施例提供的另一种可移动智能设备的示意图。

具体实施方式

车辆控制单元是车辆的重要组成部分，负责控制车辆正常运行的器件。随着车辆功能的增多，传统的发动机控制单元、变速器控制单元等独立的车辆控制单元已经无法满足复杂的功能需求，越来越多的功能需要多个车辆控制单元协同完成。而不同厂商供应的控制单元等电子器件的软件系统不互通，这给车辆的开发带来了极大的不便，阻碍了汽车行业的发展。

为了解决不同厂商供应的电子器件不互通的问题，汽车行业制定了一个标准化的软件架构，即AUTOSAR。该软件架构制定了一系列标准，使得不同厂商供应的车辆控制单元等电子器件的软件系统互通，从而提高软件功能的开发效率，加快汽车行业的发展。

随着汽车行业功能需求进一步增多，AUTOSAR定义的传统软件架构已经不能满足需求，所以提出了AP软件架构。AP软件架构是一种灵活、可配置和安全的软件架构。

接下来将对AP软件架构中和本申请实施例有关的部分进行简要介绍。

基于AP软件架构的车辆控制单元也称为计算域。为了完成对进程的控制，基于AP软件架构的车辆控制单元中一般包括执行管理(execution management，EM)。执行管理为负责管理进程的开启或关闭的进程，通过执行管理，可以启动进程，从而完成车辆对应的功能。

此外，为了简化系统的设计和开发，基于AP软件架构的车辆控制单元中还包括状态管理(SM)，状态管理是用于管理功能组状态的进程。其中，功能组也即车辆控制单元中多个用于执行相同功能的进程集合。功能组一般是开发人员根据车辆的需求设计的。一个基于AP软件架构的车辆控制单元中一般包括至少一个功能组，一个功能组通常用于完成一个特定的功能。比如，一个基于AP软件架构的车辆控制单元包括两个功能组，其中一个功能组可以用于管理该车辆控制单元的启动状态，另一个功能组用于计算车辆的自动驾驶路径。图1是一种基于AP软件架构的车辆控制单元包括两个功能组的示意图，其中功能组1是用户定义的功能组，用于实现某个特定的功能，功能组2是系统定义的功能组，该功能组2也称为MachineState，用于控制车辆控制单元的启动、重启等。上述图1只是一种车辆控制单元可能的示例，并不表示对本申请的限定。

状态管理可以通过管理功能组的状态，来通过执行管理控制该功能组对应的进程的启动或停止。结合图1来对功能组和进程之间的关系进行说明。其中，图1中的点划线框代表功能组，虚线框代表功能组的状态，实线框代表进程。功能组和功能组的状态之间的线代表功能组可以包括与之连接的状态，功能组的状态和功能组的进程之间的线代表在某个状态下运行的进程。如图1所示，功能组1有运行(running)和关闭(off)两个状态，功能组1的运行状态下，该功能组1对应的两个进程(进程1和进程2)将会运行，功能组1的关闭状态下，该功能组1对应的两个进程(进程1和进程2)将会停止运行。功能组2有开启(startup)、重置(reset)和升级(update)三个状态，功能组2的开启状态下，该功能组2对应的进程3和进程4将会运行；功能组2的重置状态下，进程5将会运行；功能组2的升级状态的情况下，进程5和进程6将会运行。

状态管理可以通过和执行管理配合，来控制基于AP软件架构的车辆控制单元中进程的运行，具体的控制过程可以如图2所示。其中，图2中的实线框代表进程，虚线框代表进程执行的动作。状态管理根据一系列的触发条件，确定需要切换某个功能组的状态。一系列的触发条件可以包括：第一，外部触发，比如当状态管理接收到外部传入的信息时，可以确定需要改变某个功能组的状态，外部传入的信息可以是用户输入内容、外部系统或其他功能组的状态切换请求等。第二，内部触发，比如状态管理可以监测某个传感器的数值，在该传感器的数值超过阈值的情况下，确定需要切换某个功能组的状态，再比如在状态管理可以在时间满足预设的周期时，确定需要切换某个功能组的状态。

状态管理在确定需要切换某个功能组的状态的情况下，将会向执行管理发送状态切换指令，以使得执行管理完成状态切换。比如状态切换指令可以是指示将功能组1设置为运行状态的指令。执行管理在收到指令后，会根据配置文件中的内容，通过启动或关闭相应进程来完成功能组1的状态切换。比如如图1所示，功能组1的运行状态需要启动进程1和进程2，那么如图2所示，执行管理将会控制进程1和进程2启动。进程1和进程2启动后，执行管理可以向状态管理返回状态切换成功的信息。

随着汽车领域自动驾驶技术的发展，车辆对于算力和安全性的要求越来越高，车辆的控制系统也朝着多车辆控制单元的方向发展，也即一个车辆中集成有多个车辆控制单元，每个车辆控制单元也即一个可以单独运行的计算机系统。这样，通过多个车辆控制单元协同进行计算，可以满足车辆对于算力的要求。对于安全性要求较高的功能，比如紧急停车、保护驾驶员等功能，可以设置在一个车辆控制单元中，并且对该车辆控制单元中的代码进行严格审核，对其他车辆控制单元的代码则无需过于严格审核，这样可以将安全性较高的功能和其他功能隔离开来，从而保证安全性较高的功能的代码中没有任何问题，从而更好进行分层管理，保证车辆的安全性。

而对于车辆集成了多个基于AP软件架构的车辆控制单元的场景下的状态管理方法，可以实行了如图3所示的分层管理方案。如图3所示，每个基于AP软件架构的车辆控制单元，如车辆控制单元1，车辆控制单元2和车辆控制单元3，都部署有状态管理，该状态管理只能管理自身所在车辆控制单元的功能组。各个车辆控制单元中，状态管理控制当前车辆控制单元的功能组状态切换的过程可以参见前文针对图2的描述。对于车辆控制单元1控制其他车辆控制单元的功能组的方法，可以在车辆控制单元1中，针对车辆控制单元2和车辆控制单元3分别设置一个总的状态机，该状态机用于维护对应车辆控制单元中功能组的状态，该状态机可以看做一个功能组。车辆控制单元1中的状态管理在确定需要切换其他车辆控制单元对应的功能组的状态时，会控制对应的状态机进行状态切换，从而可以通过该状态机的状态切换，控制该车辆控制单元中的虚拟机管理进程与虚拟机进行通信，从而使得该虚拟机可以向对应的车辆控制单元发送状态切换指令，使得对应车辆控制单元中的状态管理根据该状态切换指令，控制对应的车辆控制单元进行状态切换。

比如，车辆控制单元1中的状态管理确定需要切换车辆控制单元2对应的功能组的状态，会通过执行管理，控制车辆控制单元2对应的状态机进行状态切换，从而，虚拟机管理进程向虚拟机发送状态机的状态切换指令，虚拟机再将状态切换指令发送给车辆控制单元2的状态管理，从而使得车辆控制单元2完成对应功能组的状态管理。

上述分层管理方案，每个状态管理只能控制自身所在的车辆控制单元，对其他车辆控制单元无感知，这使得实现协同管理也较为复杂。

具体而言，有时候不同车辆控制单元中会包括相同的功能组，也即不同的车辆控制单元部署了相同的功能组对应的进程。比如，MachineState功能组用于控制车辆控制单元的状态(比如开启、关闭和重置等)，那么可能几乎所有车辆控制单元都部署有MachineState。再比如有些情况下，为了提升算力，会部署多个相同的车辆控制单元，那么这些车辆控制单元部署的功能组也是相同的。

上述情况下，为了保证车辆保持正常运行，往往不同车辆控制单元的相同功能组需要一起进行状态切换。比如车辆要进行升级，那么不同的车辆控制单元对应的MachineState需要一起切换到升级状态。再比如多个不同车辆控制单元功能相同的情况下，也需要多个车辆控制单元的功能组一起切换到特定状态，从而协同完成计算。

而上述的分层管理方案，并未给出协同管理的具体实现方式，且该方法的实现逻辑较为复杂，会降低车辆控制单元的处理效率。

基于此，本申请提出了一种状态管理方法，应用于包括多个控制单元的可移动智能设备，其中，每个控制单元都包括多个功能组，每个功能组包括用于实现相同功能的多个进程。每个功能组有能进行切换的两个状态，控制单元通过控制功能组的状态切换，从而完成对控制单元中进程的控制。其中，上述多个控制单元中至少两个控制单元对应同一功能组。在确定需要将第一功能组由第一状态切换为第二状态的情况下，可以根据包括有每个控制单元和功能组对应关系的第一配置文件，确定对应第一功能组的目标控制单元，并控制目标控制单元中对应第一功能组的进程进行状态切换。

通过上述方法，在多个控制单元存在相同的功能组时，通过上述第一配置文件，能够对多个控制单元中的相同功能组进行统一的状态管理，解决了现有技术的相应问题。并且，上述方案实现逻辑更加简单，也能提高处理效率。

需要说明的是，虽然上文中以基于AP软件架构的车辆控制单元为例对功能组相关的概念进行说明，但是本申请实施例的方案不限于应用于车辆，也不限于应用于AP软件架构中。首先，对于本申请中控制单元的软件架构而言，本申请的控制单元不限于基于AP软件架构的车辆控制单元中，本申请的控制单元也可以是其他的具有状态管理需求的软件架构的控制单元。此外，对于本申请中的可移动智能设备而言，本申请的可移动智能设备可以是车辆，也可以是机器人或除车辆之外的其他运载工具等其他智能设备，任何设备存在状态管理需求，都可以作为本申请的执行主体。

其中，运载工具如陆上交通工具、水上交通工具、空中交通工具、工业设备、农业设备或娱乐设备等。例如，本申请实施例所述车可以是交通工具(如轿车、公共汽车、地铁、高铁、摩托车、飞行车、火车等)，工业车辆(如叉车、挂车、牵引车等)，工程车辆(如挖掘机、推土机、吊车等)，农用设备(如割草机、收割机等)，游乐设备，玩具车辆，船、气垫船、潜水艇、飞机、直升机等。本申请实施例对车的具体类型、型态和功能等不做限定。

接下来将以车辆为示例，来对本申请实施例所示的方法应用的系统进行说明。图4是可以应用本申请实施例的系统架构的简化示意图。如图4所示，该系统架构可以包括：车辆41和电子设备42。

其中，车辆41也即存在状态管理需求的设备，用于实现本申请实施例提供的状态管理方法。车辆41的硬件可以包括传感器411、处理单元412、车载信息娱乐系统413。

其中传感器411可以包括摄像头、定位装置、激光雷达、毫米波雷达和超声波雷达等。传感器411用于采集数据，并将数据传递给处理单元412，由处理单元412对数据进行处理。

处理单元412可以包括多个车辆控制单元。处理单元412可以收集传感器411采集的数据、接收用户通过车载信息娱乐系统413发送的指令，并对接收的数据进行处理。在本申请实施例中，车辆控制单元的状态管理可以根据传感器411采集的数据、或根据车载娱乐系统413发送的指令，确定某个特定的功能组需要进行状态切换。本申请实施例中车辆控制单元可以是基于AP软件架构的车辆控制单元。车辆控制单元所基于的软件架构也可以是具有状态管理需求的其他软件架构，本申请实施例对此不做限定。处理单元412可以执行本申请实施例中的方法，如，处理单元412可以根据第一配置文件，控制多个车辆控制单元的功能组的状态切换，从而保证车辆的正常运行。

其中，车辆控制单元可以是安装在车辆上的用于控制或管理某种功能的器件，例如，座舱域控制器(或者称为智能信息域控制器)，车身域控制器，动力域控制器、底盘域控制器、车载计算平台(或者称为智驾域控制器)等。

其中，座舱域控制器主要用于控制车辆的智能座舱中的各种电子信息系统功能，如中控系统、车载信息娱乐系统、抬头显示、座椅系统、仪表系统、后视镜系统、驾驶行为监测系统、导航系统等。车身域控制器主要用于控制各种车身功能，包括但不限于对于车前灯、车后灯、内饰灯、车门锁、车窗、天窗、雨刮器、电动后备箱、智能钥匙、空调、天线、网关通信等的控制。动力域控制器主要用于控制车辆的动力总成，优化车辆的动力表现，保证车辆的动力安全，如发动机管理、变速箱管理、电池管理、动力分配管理、排放管理、限速管理、节油节电管理等。底盘域控制器主要用于控制车辆的行驶行为和行驶姿态，其功能包括但不限于制动系统管理、车传动系统管理、行驶系统管理、转向系统管理、车速传感器管理、车身姿态传感器管理、空气悬挂系统管理、安全气囊系统管理等。智驾域控制器主要用于提供自动驾驶感知、决策等业务，如图像信息的接收、图像信息的处理和判断、数据的处理和计算、导航与路线规划、对于实时情况的快速判断和决策，智驾域控制器需要处理感知、决策、控制三个层面的算法，对于域控制器的软硬件要求都最高。

车载娱乐系统413是一种车载综合信息处理系统，能够实现导航、车身控制、娱乐等功能。车载娱乐系统413可以与用户进行互动，接收用户的操作。车载娱乐系统可以与处理单元412进行通信，将用户的操作传递给处理单元412，以使得处理单元412可以对用户的操作进行处理。

电子设备42为对车辆41进行配置的设备，用于实现本申请实施例提供的配置文件生成方法。电子设备42可以包括处理模块421、存储模块422、和通信模块423等。

处理模块421是该电子设备的控制中心，例如处理模块421可以是中央处理器(central processing unit，CPU)、现场可编程门阵列(field-programmable gate array，FPGA)和特定应用集成电路(application-specific integrated circuit，ASIC)中的任意一种或者多种的组合。

处理模块421可以用于接收用户的操作，如处理模块421可以通过输入模块接收用户的操作。处理模块421还可以用于根据接收到的用户的操作，生成车辆41的多个第三配置文件，每个第三配置文件描述一个车辆控制单元的配置信息。处理模块421还可以将多个第三配置文件进行格式转换，转换为车辆41可以读取的第二配置文件。处理模块421还可以根据多个第三配置文件生成包括车辆控制单元和功能组对应关系的第一配置文件。第一配置文件、第二配置文件和第三配置文件的具体形式将在下文进行详述。

存储模块422用于存储数据，在本申请实施例中，存储模块422可以用于存储上述第一配置文件、第二配置文件和第三配置文件。

通信模块423用于和车辆41的处理单元412进行通信，从而向车辆41的处理单元412发送生成的第一配置文件和第二配置文件，以完成车辆41的处理单元412的配置。

接下来将结合图5、图6和图7，来对本申请示例性实施例的方法进行说明。

本申请示出了一种状态管理方法，该方法应用于可移动智能设备，这里的可移动智能设备可以是车辆或其他运载工具。该可移动智能设备包括多个控制单元，不同的控制单元可以独立运行。多个控制单元中每个控制单元包括多个进程，每个控制单元包括的多个进程可以按照实现功能的不同划分为多个功能组。

比如可移动智能设备是车辆，某个控制单元包括进程1、进程2和进程3，进程1和进程2用于实现自动驾驶路径规划的功能，进程3负责根据车辆摄像头传感器采集的数据进行车道线识别。那么按照实现功能的不同，进程1和进程2属于功能组1，进程3属于功能组2。

上述的功能组中每个功能组包括至少两个状态，功能组的状态的含义详见上文。功能组的状态用于控制功能组对应进程的运行状态。进程的运行状态也即进程的启动或停止，功能组的不同状态的情况下，控制单元可以根据功能组所处的状态，控制该功能组对应的至少一个进程启动或停止。比如，如图1所示，在功能组的不同的状态的情况下，控制单元中对应启动的进程不同，在功能组1的运行状态下，可以将该功能组包括的进程1和进程2启动，在功能组2的开启状态下，会将进程3、进程4启动，而进程5和进程6不启动。

此外，本申请所针对的是存在协同管理需求的场景，也即多个控制单元中，至少存在两个控制单元中部署有同一功能组对应的进程。比如，可移动智能设备可以包括三个控制单元，三个控制单元中至少存在两个控制单元对应功能组1这一功能组，也即至少存在两个控制单元都部署了功能组1对应的进程1和进程2。

基于以上说明，图5示出了本申请实施例中的状态管理方法的流程图，包括以下步骤：

步骤501，响应于功能组1由状态1切换为状态2的需求，根据总配置文件，从多个控制单元中确定对应功能组1的目标控制单元。

具体而言，在存在实现某个功能的需求的情况下，会触发功能组进行状态切换。比如为了实现自驾业务场景下的确定自动驾驶路径的功能，会存在将功能组1由状态1切换为状态2的需求。响应于该需求，根据总配置文件，从多个控制单元中确定对应第一功能组的目标控制单元。其中，总配置文件至少指示了多个控制单元中每个控制单元与功能组的对应关系。

在本申请中，功能组1也可以称为第一功能组，状态1也可以称为第一状态，状态2也可以称为第二状态，总配置文件也可以称为第一配置文件。

目标控制单元，也即多个控制单元中，部署有第一功能组对应的进程的控制单元，总配置文件的具体说明将在下文进行详述。

步骤502，控制目标控制单元中对应功能组1的进程进行状态切换。

在确定了目标控制单元后，便可以控制目标控制单元中对应功能组1的进程进行状态切换。这里对应功能组1的进程可以指的是功能组1对应的所有进程，也可以指的是功能组1对应的部分进程。对应功能组1的进程，具体可以根据状态1和状态2下启动的进程来确定，也即关闭状态2下不需要启动而状态1下需要启动的进程，并启动状态2下需要启动而状态1下不需要启动的进程。比如状态1需要进程1启动，状态2需要进程1和进程2启动，那么对应功能组1的进程进行状态切换，可以指的是进程2启动。再比如，状态1需要进程1启动，状态2需要进程2启动，那么对应功能组1的进程进行状态切换，可以指的是进程1关闭，进程2启动。

对于实现上述方法的具体控制过程而言，比如在基于AP软件架构的控制单元中，可以是通过状态管理和执行管理协作，完成对于功能组1状态切换的控制。具体实现方法详见后文。

接下来将结合图6对上述过程来进行具体说明。图6示出了本申请实施例的一种状态管理方法的示意图。该实施例中可移动智能设备为车辆，车辆包括两个控制单元，分别是控制单元1和控制单元2。如上文所述，控制单元可以是域控制器，这里的两个控制单元均可以是智能域控制器，两个智能域控制器共同组成了车辆的智能驾驶平台。在智能驾驶平台中，车辆需要完成多种业务场景下的功能，比如需要完成自驾业务场景、升级业务场景和休眠业务场景，不同业务场景下的功能通过不同进程来完成。图6中的虚线框即代表上述业务场景。业务场景指向状态管理中心的连线也即代表状态管理中心需要控制功能组的状态切换以实现上述业务场景。

控制单元1和控制单元2中都包括执行管理节点，这里的执行管理节点也即上文提及的执行管理。控制单元1中除了包括执行管理节点，还可以包括状态管理中心(statemanagement center，SMC)。该状态管理中心和上述状态管理不同的是，上述状态管理往往只对自身所在的控制单元内的功能组有管理权限，而本实施例中的状态管理中心，可以管理多个控制单元中的功能组，改变了上述分层管理方案。

此外，图6中虽然示出了状态管理中心部署在控制单元1，但是需要说明的是，状态管理中心单元不限于部署在控制单元1，也可以部署在控制单元2。此外，还可以在车辆中新增一个控制单元，并在该新增的控制单元中部署状态管理中心，且该新增的控制节点不部署执行管理节点和其他进程，也即新增控制单元是专门用于状态管理中心运行的控制单元。

还可以根据可移动智能设备包括的各个控制单元的可靠性来确定合适的控制单元来部署状态管理中心。具体而言，为了保证状态管理中心的正常运行，可以将状态管理中心部署在更可靠，更不容易故障的控制单元中。比如可以将状态管理中心部署在多个控制单元中的可靠性最高的控制单元中。这样，状态管理中心部署在更不可能故障的控制单元中，保证了状态管理中心的正常运行，从而保证了可移动智能设备的安全运行。

对于具体的状态切换方法而言，状态管理中心可以根据总配置文件，从多个控制单元中确定目标控制单元。确定方法和前文相同。

控制目标控制单元中对应功能组1的进程进行状态切换的过程可以是：状态管理中心向目标控制单元发送状态切换指令，如图6所示，控制单元1和控制单元2都部署有对应功能组1的进程，这里的目标控制单元可以是控制单元1和控制单元2，状态管理中心可以根据总配置文件中控制单元和功能组的对应关系，确定目标控制单元为控制单元1和控制单元2。状态切换指令也即用于指示功能组1由状态1切换为状态2的指令。目标控制单元接收状态切换指令，并根据该指令，控制目标控制单元中对应功能组1的进程进行状态切换。

其中，状态管理中心和目标控制节点通信的方法，可以利用已有的控制单元内或跨控制单元的通信手段进行通信，本申请实施例对于具体的通信方法不做限定。

如图6所示，上述状态管理中心向目标控制单元发送状态切换指令，目标控制单元根据该状态切换指令控制对应功能组1的进程完成状态切换可以是：状态管理中心向目标控制单元的执行管理节点下发状态切换指令，执行管理节点控制对应功能组1的进程进行状态切换。

此外，有些情况下，状态管理中心为了控制完成功能组1的状态切换，不仅需要向执行管理节点发送状态切换指令，还需要向目标控制单元的其他进程发送状态切换指令或其他的信息。比如，状态管理中心还需要向目标控制单元的监控进程和日志记录进程等进程发送状态变化通知，以使得监控进程可以对控制单元的运行进行监控，日志记录进程可以记录控制单元运行过程中的状态变化。在上述情况下，每个控制单元中还可以包括状态管理节点(state management node，SMN)，状态管理中心可以向目标控制单元的状态管理节点发送状态切换指令，状态管理节点将状态切换指令转发给执行管理节点，或者转发给执行管理节点和其他的进程，这样执行管理节点可以根据状态切换指令和子配置文件，控制目标控制单元中对应第一功能组的进程进行状态切换。

其中，在本申请实施例中，子配置文件也称为第二配置文件，一个子配置文件可以包括一个控制单元中功能组以及功能组对应的状态信息。状态信息可以包括功能组对应的状态，功能组可以进行的状态切换，以及功能组每个状态下需要启动的进程。这样执行管理节点可以根据所在的控制单元的子配置文件，确定切换功能组1的状态后需要启动或关闭的进程，从而完成功能组1的状态切换。

这样，在状态管理中心需要向执行管理节点和其他进程发送信息才能控制功能组完成状态切换的情况下，状态管理中心只需要区分不同控制单元内的状态管理节点，不需要区分不同控制单元中的多个不同的进程。这样可以提高处理效率。

本申请实施例对包括多个控制单元的可移动智能设备的状态管理进行改进，提出上述集中式的多域(即控制单元)状态管理方法，支持在不同控制单元中定义不同控制单元所需的功能组和功能组的状态，部署一个状态管理中心，维护多个控制单元的状态，并在每个控制单元部署一个状态管理节点。基于单状态管理中心，多状态管理节点的部署方式，通过多个控制单元中定义的不同的功能组保存在一份总配置文件中，该总配置文件可以被状态管理中心读取，这样可以实现集中式管理多个控制单元的不同的功能组和状态，从而实现多控制单元的协同管理。

接下来，还将对本申请实施例提出的一种配置文件生成方法进行说明。

当每个状态管理只对自身所在的控制单元有控制权限，针对每个控制单元，只会生成一份配置文件，状态管理和执行管理根据该配置文件对功能组的状态进行管理。而本申请中，由于需要统一对所有的控制单元进行状态管理，需要根据配置文件来确定控制单元和功能组的对应关系。那么除了针对每个控制单元，生成该控制单元对应的配置文件之外，还需要生成总配置文件，接下来将对如何生成该总配置文件进行说明。

图7是本申请示出的一种配置文件生成方法的流程图，包括以下步骤：

步骤701，获取至少两个用户配置文件。

首先，可以获取至少两个用户配置文件。在本申请中，用户可以通过电子设备(比如个人电脑或服务器等)，配置可移动智能设备上的每个控制单元。这里的用户是指允许对可移动智能设备进行配置的用户。用户在针对可移动智能设备上的每个控制单元，配置完成后，将会生成每个控制单元对应的用户配置文件。

对于用户配置文件的内容而言，用户配置文件中包括了对应的控制单元中功能组的配置。具体而言，用户配置文件指示对应的控制单元包括的每个进程对应的功能组，以及每个功能组的状态信息；状态信息指示对应功能组包括的至少两个状态，功能组的状态用于控制功能组对应进程的运行状态。状态信息还可以包括各个功能组可以进行的状态切换。也即，用户配置文件中记录了控制单元包括的功能组，每个功能组对应的进程，功能组的多个状态以及功能组可以进行的状态切换。通过控制功能组的状态切换，可以控制功能组对应的进程的启动或停止，从而使得可移动智能设备可以实现特定的功能。

此外，用户配置文件在本申请中也称为第三配置文件。第三配置文件可以和第二配置文件相同，也即用户配置文件可以直接供控制单元的执行管理节点使用。有些实施例中，第三配置文件和第二配置文件可以不同，具体而言，第三配置文件可能是可移动智能设备无法正常读取的文件，那么为了方便可移动智能设备进行文件的读取，第二配置文件可以是将第三配置文件进行格式转换后，可供可移动智能设备进行读取的配置文件。

从上述描述可以确定，至少两个用户配置文件与可移动智能设备上的至少两个控制单元一一对应。配置文件生成方法和上文的状态管理方法所面对的场景是相同的，那么这里的控制单元与上文中的控制单元也相同。即，至少两个控制单元中的每个控制单元包括多个进程，每个控制单元的多个进程按照实现功能的不同划分为多个功能组。

步骤702，根据至少两个用户配置文件，生成可移动智能设备的总配置文件。

在获取了至少两个用户配置文件后，便可以根据获取的至少两个用户配置文件，生成可移动智能设备的总配置文件。总配置文件和上文总配置文件含义相同，即至少指示了可移动智能设备上多个控制单元中每个控制单元与功能组对应关系的配置文件。

通过生成总配置文件，可以使得设备中能读取总配置文件的进程，比如状态管理中心，可以根据总配置文件，确定该可移动智能设备中所有控制单元中包括的功能组，从而可以针对该可移动智能设备，进行统一管理，提高管理效率。

接下来以可移动智能设备为车辆，控制单元为智能域控制器，控制单元是基于AP软件架构的控制单元为例，来对本申请示出的配置文件生成方法及状态管理方法进行说明。

如图8所示，本申请实施例中的车辆包括两个控制单元，分别是控制单元A和控制单元B。控制单元A对应车辆的安全域，用于完成车辆智能驾驶平台中和安全相关的功能，比如保护驾驶员安全等。控制单元B对应通用域，用于完成除了和安全相关的功能之外的其他功能。安全域相比于控制域，可靠性更高，因此可以在安全域(也即控制单元A)中部署状态管理中心，该状态管理中心负责集中管理所有控制单元的状态。

此外，如图8所示，控制单元A和控制单元B中都部署了状态管理节点和执行管理节点。执行管理节点和用于控制进程的启动或停止。状态管理节点主要用于接收状态管理中心的状态切换指令，将该指令透传给控制单元中的进程，比如可以透传给执行管理节点，以使得执行管理节点完成进程的控制。状态管理中心可以在启动时加载总配置文件，执行管理节点可以在启动时加载控制单元的配置文件，以便进行状态管理时可以使用上述文件。

图8中，控制单元A和控制单元B的用户配置文件可以分别生成两个子配置文件，此外，还可以根据两个用户配置文件，生成总配置文件。在进行状态管理时，状态管理中心可以根据总配置文件，向需要进行状态切换的功能组所在的控制单元的状态管理节点发送状态切换指令。状态管理节点接收到状态切换指令后，可以将状态切换指令转发给执行管理节点，进而执行管理节点可以根据控制单元的配置文件，切换相应功能组的状态。

在对图8进行简要说明后，接下来将从配置文件的生成文件的方法开始，对本申请实施例的方法进行说明。

第一步，配置功能组、功能组的状态和状态切换的信息。

具体而言，多个控制单元可以包括相同的功能组，为了更方便进行控制单元的配置，可以先建一个智能驾驶平台项目，在该项目的公共的配置文件中对功能组的基本信息进行配置。

这里的配置文件可以是ARXML(AUTOSAR XML)格式的文件，是用可扩展标记语言(extensible markup language，XML)描述AUTOSAR模型的一种人机可读的文本格式。

如下所示，在公共的ARXML中配置的功能组可以包括以下配置信息：

-智能驾驶平台

-功能组配置

-功能组A(功能组)

-运行(功能组的状态)

-关闭(功能组的状态)

-关闭切换到运行(功能组的状态切换)

-运行切换到关闭(功能组的状态切换)

-MachineState(功能组)

……

-功能组B(功能组)

……

-功能组C(功能组)

……

上述配置信息中，智能驾驶平台代表智能驾驶平台的项目，后面包括该智能驾驶平台包括的所有ARXML文件，功能组配置代表功能组对应的公共的ARXML文件，在该文件中可以配置若干功能组，上文的举例中配置了功能组A、功能组B、功能组C和MachineState四个功能组。功能组A、功能组B、功能组C和MachineState后面的括号中的描述“功能组”为标签，代表了配置的具体内容，也即表征配置的功能组A和MachineState为功能组。运行和关闭后面的括号中的描述“状态”也是标签，代表了配置的内容为功能组的状态，也即表征运行和关闭为功能组A的状态。相似的，括号中的描述“功能组的状态切换”代表配置的内容为允许功能组进行的状态切换，也即表征允许功能组A从关闭状态切换到运行状态，也允许从运行状态切换到关闭状态。功能组B、功能组C和MachineState的配置内容和功能组A的配置内容相似。

上文只是以为一个功能组配置两个状态进行举例，容易理解的是，一个功能组可以包括不止两个状态，也可以为一个功能组配置三个或三个以上状态。

第二步，对多个控制单元进行配置。

在完成功能组配置后，还可以对多个控制单元进行配置，也即可以对多个控制单元的功能组进行配置。

此外，还可以配置控制单元的操作系统、系统启停时间、处理器等。

上述第一步和第二步的配置可以是用户完成的，用户配置完成后，用户配置可移动智能设备所使用的电子设备可以针对控制单元A和控制单元B分别生成用户配置文件，比如可以生成控制单元A.ARXML和控制单元B.ARXML两个用户配置文件。两个用户配置文件中分别记录了控制单元A和控制单元B包括的功能组、功能组的状态以及功能组的状态切换等。

控制单元A的用户配置文件包括的内容可以为：

-控制单元A(控制单元)

……

-功能组B(功能组)

-功能组C(功能组)

-MachineState(功能组)

控制单元B的用户配置文件包括的内容可以为：

-控制单元B(控制单元)

……

-功能组A(功能组)

-功能组C(功能组)

-MachineState(功能组)

上述内容中，控制单元A和控制单元B后面的括号中的控制单元为标签，代表了配置的控制单元A和控制单元B为控制单元。功能组A、功能组B、功能组C和MachineState后面的括号中的功能组也是标签，代表了配置的内容为引用在公共的ARXML文件中已经配置的功能组。省略号表示了还针对控制单元配置了操作系统、系统启停时间、处理器等。

从上述用户配置文件中可知，控制单元A中配置了功能组B、功能组C和MachineState三个功能组，控制单元B中配置了功能组A、功能组C和MachineState三个功能组。

第三步，通过工具链，根据控制单元A和控制单元B的用户配置文件，生成总配置文件。将控制单元A和控制单元B的用户配置文件进行格式转换，得到控制单元A和控制单元B的子配置文件。

第三步也即对应于图8中的工具链配置的步骤。

如上文所述，智能驾驶平台无法直接读取用户配置文件，因此，可以先将用户配置文件转换成子配置文件，也即可以将至少两个控制单元的用户配置文件进行格式转换，得到至少两个子配置文件。子配置文件指示了当前控制单元配置的功能组和功能组的状态信息。此外，为了方便状态管理中心进行集中式状态管理，还可以生成包括各控制单元和功能组对应关系的总配置文件。总配置文件至少包括了控制单元和功能组的对应关系，还可以包括每个控制单元包括的功能组的状态信息。

其中，用户配置文件可以供执行管理节点使用，也即如图8所示，控制单元A的执行管理节点读取控制单元A的子配置文件，控制单元B的执行管理节点读取控制单元B的子配置文件。

对于具体实现方式而言，可以将控制单元A的用户配置文件进行格式转换，转换成智能驾驶平台可以读取的子配置文件。比如，智能驾驶平台可以读取的文件形式是json，那么可以将控制单元A.ARXML进行格式转换，转换成控制单元A.json文件。控制单元B的子配置文件生成方式与配置文件A的生成方式相同。

对于生成总配置文件的过程而言，与每个配置文件中只会包括一个控制单元的配置信息不同，本申请的总配置文件可以包括多个控制单元的配置信息，因此在总配置文件中需要新增用于标识配置信息所对属的控制单元的信息。进而状态管理中心可以根据上述配置信息，区分不同控制单元包括的功能组。

此外，在一个智能驾驶平台集成了多个片上系统(system–on-chip，SoC)的情况下，总配置文件中还可以包括用于标识不同SoC的信息。

也即，总配置文件包括：多个控制单元中每个控制单元的标识，以及与每个控制单元的标识对应的功能组的标识。或，总配置文件包括：多个控制单元中每个控制单元的标识，与每个控制单元的标识对应的功能组的标识，以及与每个控制单元的标识对应的片上系统SoC的标识。

以json文件存储的是键-值(key-value)对为例，总配置文件中控制单元A对应的配置信息可以包括：

键：控制单元

值：[

(键：功能组

值：……)

……

(键：控制单元标识

值：控制单元A)

]

控制单元B在总配置文件中的配置信息同理。上文中，上述控制单元键后的中括号中的内容即为一个控制单元对应的配置信息。为了节省重复描述，功能组的配置和控制单元的其他配置在此省略。当然，总配置文件中也可以不包括其他配置，只在此对每个控制单元包括的功能组进行配置，或只对每个控制单元包括的功能组以及功能组的状态进行配置。

控制单元标识-控制单元A这一键值对就是总配置文件中针对控制单元A新增的信息。该键值对用于标识上述配置信息对应于控制单元A。

上述控制单元标识-控制单元A这一键值对，可以是工具链在解析时，根据用户配置文件的名称等信息自动生成的。也可以是用户配置文件中增加的扩展字段(admindata)，扩展字段用于标识该用户配置文件所对应的控制单元，在工具链解析时，可以将该扩展字段解析成控制单元标识-控制单元A这一键值对。

也即总配置文件包括的控制单元的标识是根据至少两个用户配置文件中的第一标识生成的，第一标识为所属的第三配置文件对应的控制单元的标识。

第一标识也即上文的扩展字段。

举例而言，第二步中的用户配置文件可以如下所示：

-控制单元A(控制单元)

……

-功能组B(功能组)

-功能组C(功能组)

-MachineState(功能组)

-控制单元A(控制单元标签)

-控制单元B

……

-功能组A(功能组)

-功能组C(功能组)

-MachineState(功能组)

-控制单元B(控制单元标签)

与第二步不同的是，这里的用户配置文件增加了控制单元标签，控制单元A和控制单元B后面的括号中的配置文件标签为标签，代表了标签前面的控制单元A和控制单元B为控制单元的标签。

在得到总配置文件、控制单元A的子配置文件和控制单元B的子配置文件后，可以将这些文件存储至智能驾驶平台中。

如图9所示，图9中的(a)中是电子设备中的用户配置文件的内容，图9中的(b)是车辆上的总配置文件和子配置文件。功能组配置可以配置功能组A、功能组B、功能组C和MachineState(对应于图中的功能组D)四个功能组，也即对应于上文的在公共的ARXML文件中对功能组进行配置的过程。两个控制单元的用户配置文件分别引用了如图9所示的功能组，对应于上文第二步的用户配置文件。相应的，生成的子配置文件和总配置文件存储至智能驾驶平台后，如图9右侧所示，控制单元A的状态管理中心可以读取的总配置文件可以包括功能组A、功能组B、功能组C和MachineState四个功能组的状态信息，以及四个功能组和控制单元的对应关系。控制单元A的执行管理节点可以读取的子的配置文件可以包括功能组B、功能组C和MachineState的状态信息，控制单元B的执行管理节点可以读取的子配置文件可以包括功能组A、功能组C和MachineState的状态信息。

第四步，状态管理中心根据总配置文件，对多个控制单元的功能组状态进行管理。

这里管理的方法具体可以参见上文。

此外，为了保证车辆可以安全行驶，可以执行以下步骤：

在第一功能组的状态切换成功的情况下，显示提示信息，提示信息指示第一功能组的状态切换成功；其中，目标控制单元包括第一控制单元和第二控制单元，第一控制单元包括目标控制单元中安全等级大于预设阈值的控制单元；在第一控制单元和第二控制单元状态切换均成功的情况下，确定第一功能组的状态切换成功；或，在第一控制单元状态切换成功，且第二控制单元异常的情况下，确定第一功能组的状态切换成功。

也即，目标控制单元包括安全等级大于阈值的至少一个控制单元，以及安全等级小于等于阈值的至少一个控制单元，在可以确定安全等级小于等于阈值的至少一个控制单元故障的情况下，可以仅根据未故障的控制单元的状态切换结果来确定状态切换结果，故障的安全等级小于阈值的控制单元是否状态切换成功不影响最终的状态切换结果。

这样，安全等级小于等于阈值的控制单元所执行的功能一般为和安全无关的功能，为了保证这些控制单元故障的情况下，可移动智能设备仍能正常运行，可以仅根据未故障的控制单元的状态切换结果来确定状态切换结果。这样，在存在安全等级小于等于阈值的控制单元故障的情况下，无需重复去触发故障的控制单元进行状态切换，保证了安全等级大于阈值的控制单元可以正常单独运行，保证控制单元的基本运行。

同时将状态切换结果进行显示，可以告知用户当前可移动智能设备的状况，提升用户的使用体验。

接下来将结合图9来对状态管理过程进行举例说明。

场景1：状态管理中心确定存在功能组C的状态切换需求，状态管理中心可以根据总配置文件，确定控制单元A和控制单元B均包括功能组C，那么可以分别向控制单元A和控制单元B的状态管理节点发送状态切换指令，该指令用于指示对功能组C进行状态切换。具体的状态管理节点控制功能组C进行状态管理的过程详见上文。

这种情况下，状态管理中心可以根据两个控制单元的功能组C的状态切换来确定最终的返回结果，比如状态管理中心可以在两个控制单元的功能组C都状态切换成功的情况下，确定状态切换成功，两个控制单元中任一控制单元的功能组C状态切换失败，即确定状态切换失败。

场景2：状态管理中心确定存在功能组A的状态切换需求，状态管理中心可以根据总配置文件，确定控制单元B包括功能组A，那么可以向控制单元B的状态管理节点发送状态切换指令，该指令用于指示对功能组A进行状态切换。

这种情况下，状态管理中心可以根据控制单元B的执行管理节点通过控制单元B的状态管理节点转发的状态切换结果，来确定控制单元B的状态切换结果。比如，控制单元B的执行管理节点确定功能组A状态切换成功，则会向控制单元B的状态管理节点返回状态切换成功，控制单元B的状态管理节点将状态切换成功的信息转发给状态管理中心。状态管理中心根据收到的信息确定控制单元B的功能组A状态切换成功。

场景3，在控制单元B异常的情况下，控制单元A是安全等级大于阈值的控制单元，控制单元B是安全等级小于等于阈值的控制单元，可以通过控制单元A的独立运行，保证车辆仍然可以正常运行一段时间。那么如果需要切换两个控制单元都包括的功能组的状态，则可以仅根据控制单元A的状态切换结果来确定最终的切换结果。

具体而言，状态管理中心可以通过心跳等机制确定控制单元B存在异常，在需要进行功能组C的状态切换的情况下，可以仅根据控制单元A的状态切换结果来确定状态切换是否成功。

其他功能组的状态切换方法和上文类似。在上述场景中，在状态切换成功的情况下，可以显示提示信息，用于提示使用可移动智能设备的用户状态切换成功。

对于本申请的应用场景而言，本申请可以应用于集成了单SoC的可移动智能设备，也可以应用于集成了多个SoC的可移动智能设备。集成了单SoC的可移动智能设备中SMC的部署方法和上文相同。在可移动智能集成多个SoC的情况下，也可以部署一个SMC，该SMC可以控制多个SoC中的控制单元。如上文所述，多SoC的场景下，还可以在总配置文件中增加用于标识不同SoC对应的控制单元的标签。

对于单SoC和双SoC下的SMC部署，可以参见图10中的(a)和图10中的(b)。

如图10中的(a)所示，单SoC场景中，一个可移动智能设备部署了一个SMC，用于管理控制单元1和控制单元2，比如可以如图10中的(a)所示，SMC和执行管理节点进行通信，从而完成功能组的状态管理，当然也可以在每个控制单元中设置SMN，SMC也可以和SMN通信来完成功能组的状态管理。

如图10中的(b)所示，双SoC场景中，一个可移动智能设备可以部署一个SMC，一个SMC用于管理两个SoC中的控制单元1、控制单元2和控制单元3。

此外，有些情况下会在一个可移动智能设备中部署多个盒子，每个盒子可以看做是可移动智能设备的一个控制系统。那么在一个可移动智能设备中部署了多个盒子的场景下，可以只部署一个SMC，也可以在每个盒子中部署一个SMC，由该SMC对盒子内的功能组进行状态管理。在一个可移动智能设备部署了两个盒子的情况下，部署一个SMC的示意图可以参见图11中的(a)，每个盒子都部署一个SMC的示意图可以参见图11中的(b)。此外，每个盒子中还可以部署多个SoC，部署多个SoC的场景中的控制方法详见上文。

本申请实施例还提供用于实现以上任一种方法的装置，例如，提供一种装置包括用以实现以上任一种方法中可移动智能设备所执行的各步骤的单元(或手段)。再如，还提供另一种装置，包括用以实现以上任一种方法中电子设备所执行的各步骤的单元(或手段)。实现上述个步骤可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块，例如，处理模块，获取模块，生成模块。作为一种示例，可移动智能设备可以包括处理模块，处理模块可以执行上述501和502；电子设备可以包括获取模块和处理模块，获取模块可以执行上述701；处理模块可以执行上述702。

本申请还提供一种可移动智能设备，包括存储器和处理器，存储器用于存储计算机程序，处理器用于执行计算机程序，实现上述的状态管理方法。

本申请还提供一种电子设备，包括存储器和处理器，存储器用于存储计算机程序，处理器用于执行计算机程序，实现上述配置文件生成方法。

本申请还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序用于实现上述任意一项的方法。

本申请还提供一种计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当计算机可读代码在电子设备中运行时，电子设备中的处理器执行上述任意一项的方法。

应理解以上装置中各模块的划分仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

本申请实施例中采用的第一、第二的前缀词，仅仅为了区分不同的描述对象，对被描述对象的位置、顺序、优先级、数量或内容等没有限定作用。

在本申请的各个实施例中，如果没有特殊说明以及逻辑冲突，各个实施例之间的术语和/或描述具有一致性、且可以相互引用，不同的实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。

Claims (12)

1.一种状态管理方法，其特征在于，应用于可移动智能设备，所述可移动智能设备包括多个控制单元，所述多个控制单元中每个控制单元包括多个进程，所述每个控制单元的多个进程按照实现功能的不同划分为多个功能组，所述多个功能组中每个功能组包括至少两个状态，功能组的状态用于控制功能组对应进程的运行状态，所述多个控制单元中存在至少两个控制单元对应同一功能组；所述方法包括：

响应于第一功能组由第一状态切换为第二状态的需求，根据第一配置文件，从所述多个控制单元中确定对应所述第一功能组的目标控制单元，所述第一配置文件指示所述多个控制单元中每个控制单元与功能组的对应关系；

控制所述目标控制单元中对应所述第一功能组的进程进行状态切换。

2.根据权利要求1所述的方法，其特征在于，所述可移动智能设备还包括状态管理中心；

所述根据第一配置文件，从所述多个控制单元中确定对应所述第一功能组的目标控制单元，包括：

所述状态管理中心根据所述第一配置文件，从所述多个控制单元中确定所述目标控制单元；

所述控制所述目标控制单元中对应于所述第一功能组的进程进行状态切换，包括：

所述状态管理中心向所述目标控制单元发送状态切换指令，所述状态切换指令用于指示将所述第一功能组由所述第一状态切换为所述第二状态；

所述目标控制单元接收所述状态切换指令；

所述目标控制单元根据所述状态切换指令，控制所述目标控制单元中对应所述第一功能组的进程进行状态切换。

3.根据权利要求2所述的方法，其特征在于，所述多个控制单元中每个控制单元还包括状态管理节点和执行管理节点；

所述目标控制单元根据所述状态切换指令，控制所述目标控制单元中对应所述第一功能组的进程进行状态切换，包括：

所述目标控制单元的状态管理节点接收所述状态切换指令；

所述目标控制单元的状态管理节点将所述状态切换指令转发给所述目标控制单元的执行管理节点；

所述目标控制单元的执行管理节点根据所述状态切换指令和第二配置文件，控制所述目标控制单元中对应所述第一功能组的进程进行状态切换，所述第二配置文件指示所述目标控制单元中的功能组以及功能组对应的状态信息。

4.根据权利要求2或3所述的方法，其特征在于，所述状态管理中心部署在所述多个控制单元中的可靠性最高的控制单元。

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

在所述第一功能组的状态切换成功的情况下，显示提示信息，所述提示信息指示所述第一功能组的状态切换成功；

其中，所述目标控制单元包括第一控制单元和第二控制单元，所述第一控制单元包括所述目标控制单元中安全等级大于预设阈值的控制单元；在所述第一控制单元和所述第二控制单元状态切换均成功的情况下，确定所述第一功能组的状态切换成功；或，在所述第一控制单元状态切换成功，且所述第二控制单元异常的情况下，确定所述第一功能组的状态切换成功。

6.根据权利要求1-5任一项所述的方法，其特征在于，

所述第一配置文件包括：所述多个控制单元中每个控制单元的标识，以及与每个控制单元的标识对应的功能组的标识；或

所述第一配置文件包括：所述多个控制单元中每个控制单元的标识，与每个控制单元的标识对应的功能组的标识，以及与每个控制单元的标识对应的片上系统SoC的标识。

7.一种配置文件生成方法，其特征在于，所述方法包括：

获取至少两个第三配置文件，所述至少两个第三配置文件与可移动智能设备上的至少两个控制单元一一对应，所述至少两个控制单元中的每个控制单元包括多个进程，所述每个控制单元的多个进程按照实现功能的不同划分为多个功能组，所述第三配置文件指示所述第三配置文件对应的控制单元包括的每个进程对应的功能组，以及每个功能组的状态信息；所述状态信息指示对应功能组包括的至少两个状态，功能组的状态用于控制功能组对应进程的运行状态；

根据至少两个所述第三配置文件，生成所述可移动智能设备的第一配置文件，所述第一配置文件指示所述可移动智能设备上多个控制单元中每个控制单元与功能组的对应关系。

8.根据权利要求7所述的方法，其特征在于，

所述第一配置文件包括：所述多个控制单元中每个控制单元的标识，以及与每个控制单元的标识对应的功能组的标识；或

所述第一配置文件包括：所述多个控制单元中每个控制单元的标识，与每个控制单元的标识对应的功能组的标识，以及与每个控制单元的标识对应的片上系统SoC的标识。

9.根据权利要求8所述的方法，其特征在于，所述第一配置文件包括的控制单元的标识是根据所述至少两个第三配置文件中的第一标识生成的，所述第一标识为所属的第三配置文件对应的控制单元的标识。

10.一种可移动智能设备，其特征在于，包括多个控制单元，存储器和处理器，所述多个控制单元中每个控制单元包括多个进程，所述每个控制单元的多个进程按照实现功能的不同划分为多个功能组，所述多个功能组中每个功能组包括至少两个状态，功能组的状态用于控制功能组对应进程的运行状态，所述多个控制单元中存在至少两个控制单元对应同一功能组；

所述存储器用于存储计算机程序，所述处理器用于执行所述计算机程序，实现权利要求1-6任一项所述的状态管理方法。

11.一种电子设备，其特征在于，包括存储器和处理器，所述存储器用于存储计算机程序，所述处理器用于执行所述计算机程序，实现权利要求7-9任一项所述的配置文件生成方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序用于实现权利要求1-9任一项所述的方法。