State management method, configuration file generation method, and device

Abstract

A state management method, a configuration file generation method, and a device. The state management method is applied to a mobile intelligent device comprising a plurality of control units, wherein each control unit comprises a plurality of function groups, and each function group comprises a plurality of processes; each function group has at least two states, and a control unit completes control of processes in the control unit by means of controlling state switching of the function group; and at least two of the plurality of control units correspond to the same function group. When it is determined that a first function group needs to be switched from a first state to a second state, a target control unit corresponding to the first function group can be determined on the basis of a first configuration file, which comprises a correspondence between control units and function groups, and processes in the target control unit which correspond to the first function group are controlled to perform state switching. By means of the method, when identical function groups exist in a plurality of control units, centralized state management can be performed on the identical function groups in the plurality of control units by means of the first configuration file.

Description

A state management method, configuration file generation method and device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on November 13, 2023, with application number 202311512210.4 and application name “A state management method, configuration file generation method and device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to a state management method, a configuration file generation method and a device. Background Art

[0003] A vehicle control unit (VCU) is a device installed in a vehicle that controls its normal operation and is a crucial component of the vehicle. The Automotive Open System Architecture (AUTOSAR) is a standardized software architecture developed by the automotive industry. AUTOSAR's Adaptive Platform (AP) is a flexible, configurable, and secure software architecture designed to accommodate the increasing number of vehicle functions. The AP software architecture is one of the software architectures that VCUs can use.

[0004] In vehicle control units based on the AP software architecture, the collection of multiple processes used to implement a specific function is generally referred to as a function group. State management (SM) is the process within the vehicle control unit used to control the state switching of the function group. By controlling the state switching of the function group, SM can control the running state of the corresponding process of the function group, thereby enabling the vehicle to implement the corresponding function. For example, if the state of a function group switches from off to on, the corresponding process of the function group will also be started, thus implementing the corresponding function.

[0005] With the development of intelligent driving technology, the number of functions that vehicle control units need to perform is increasing, and the computing power and safety requirements of vehicle control units are also increasing. To improve the computing power of vehicle control units and meet vehicle safety requirements, vehicles are moving towards integrating multiple vehicle control units. For example, multiple vehicle control units based on the AP software architecture can be integrated into a single vehicle. Different vehicle control units can perform different functions, or different vehicle control units with the same functions can collaborate to complete calculations.

[0006] When a vehicle is integrated with multiple vehicle control units (VCUs), the same functional groups may exist in these VCUs. Therefore, these functional groups need to be managed collaboratively, meaning that the states of multiple functional groups belonging to different VCUs need to be switched together. For example, when a vehicle's operating system needs to be upgraded, the operating systems of multiple VCUs often need to be upgraded together, meaning that the functional groups implementing the upgrade functions in multiple VCUs need to be switched from the off state to the on state together.

[0007] However, in the prior art, in a scenario where multiple vehicle control units based on the AP software architecture are integrated on a vehicle, there is a lack of a method for collaboratively managing the functional group states of the multiple vehicle control units.

[0008] Summary of the Invention

[0009] The present application provides a state management method, a configuration file generation method and a device, which solve the problem in the prior art of being unable to collaboratively manage the functional group states of multiple vehicle control units.

[0010] According to a first aspect of the present application, a state management method is provided for a mobile intelligent device comprising multiple control units, wherein each control unit comprises multiple functional groups, each functional group comprising multiple processes for implementing the same function. Each functional group has two switchable states, and the control unit controls the processes within the control unit by controlling the state switching of the functional group. At least two of the multiple control units correspond to the same functional group. When it is determined that a first functional group needs to be switched from a first state to a second state, a target control unit corresponding to the first functional group can be determined based on a first configuration file containing a correspondence between each control unit and the functional group, and the process corresponding to the first functional group in the target control unit can be controlled to switch states. The mobile intelligent device may comprise a vehicle. Using the above method, when multiple control units have the same functional group, the first configuration file can be used to determine a target control unit corresponding to the first functional group, and the corresponding process of the first functional group in the target control unit can be controlled to switch states, thereby enabling unified state management of the same functional group within the multiple control units. When the mobile intelligent device is a vehicle, the first functional groups of multiple vehicle control units can switch states together, resolving the problem of prior art inability to collaboratively manage functional groups within multiple vehicle control units.

[0011] In an optional embodiment, the mobile smart device may further include a state management center, and the steps of determining a target control unit and controlling state switching are both performed by the state management center. Specifically, the state management center first determines the target control unit corresponding to the first functional group from a plurality of control units based on the first configuration file. It then sends a state switching instruction to the target control unit, instructing the first functional group to switch from the first state to the second state. After receiving the state switching instruction, the target control unit can control the state switching of the process corresponding to the first functional group according to the instruction. In this way, centralized state management can be implemented through the state management center, simplifying the state management process.

[0012] In an optional embodiment, each control unit may include, in addition to the process corresponding to the functional group, a state management node and an execution management node. The above-mentioned target control unit controls the process corresponding to the first functional group to complete the state switch, specifically, the state management node of the target control unit receives the state switch instruction, and forwards the state switch instruction to the execution management node of the current target control unit. The execution management node controls the process corresponding to the first functional group in the target control unit to perform state switching based on the received state switch instruction and the second configuration file indicating the functional group in the control unit and the state information corresponding to the functional group. The state management center only needs to communicate with the state management node in the control unit, and does not need to communicate with multiple processes in the control unit, which simplifies the state management process and improves the state management efficiency.

[0013] In an alternative embodiment, the state management center can be deployed in the most reliable control unit among multiple control units. This makes the control unit where the state management center resides less prone to failure, ensuring the normal operation of the state management center. This ensures that when the mobile smart device is a vehicle, the vehicle's functions can be activated or deactivated normally, ensuring the normal operation of the vehicle.

[0014] In an optional embodiment, when the state switching of the first functional groups corresponding to all control units in the target control unit is successful, a prompt message indicating that the state switching of the first functional group is successful is displayed. In addition, the target control unit includes two types of control units, one is a control unit with a security level greater than a preset threshold, and the other is a control unit with a security level less than or equal to the preset threshold. In the event that the control unit with a security level less than or equal to the preset threshold fails, whether the state switching is successful can be determined only based on the state switching results of the control unit with a security level greater than the preset threshold, and a prompt message is displayed if the state switching is successful. This ensures that even if the control unit with a security level less than or equal to the preset threshold fails, the control unit with a security level greater than the preset threshold can still operate normally for a period of time, thereby ensuring that the basic security functions of the mobile smart device can operate normally and ensuring the safety of users using the mobile smart device.

[0015] In an optional embodiment, the first configuration file includes an identifier for each control unit and an identifier for the functional group corresponding to each control unit identifier, thereby indicating the correspondence between the control unit and the functional group. Alternatively, the first configuration file may include an identifier for each control unit, an identifier for the functional group corresponding to each control unit identifier, and an identifier for the SoC of the control unit, thereby indicating the correspondence between multiple control units and functional groups when multiple SoCs exist. In this way, through the above identifiers in the first configuration file, the mobile smart device can uniformly manage the functional group state switching of multiple control units.

[0016] According to a second aspect of the present application, a configuration file generation method is provided, comprising: obtaining at least two third configuration files, each of which is a configuration file for a control unit on a mobile smart device, the mobile smart device being the same as the mobile smart device according to the first aspect of the present application. Based on the at least two third configuration files, a first configuration file is generated for the mobile smart device, the first configuration file indicating a correspondence between multiple control units and functional groups on the mobile smart device. By generating the first configuration file, the mobile smart device can determine, based on the first configuration file, a target control unit that includes a first functional group. Thus, if there are multiple target control units corresponding to the first functional group, the first functional groups of the multiple target control units can be controlled to switch process states together, thereby achieving unified management of the state switching of the functional groups.

[0017] In an optional embodiment, the first configuration file includes an identifier for each control unit and an identifier for the functional group corresponding to each control unit identifier, thereby indicating the correspondence between the control unit and the functional group. Alternatively, the first configuration file may include an identifier for each control unit, an identifier for the functional group corresponding to each control unit identifier, and an identifier for the SoC of the control unit, thereby indicating the correspondence between multiple control units and functional groups when multiple SoCs exist. In this way, through the above identifiers in the first configuration file, the mobile smart device can uniformly manage the functional group state switching of multiple control units.

[0018] In an optional embodiment, the control unit identifier included in the first configuration file is generated based on the first identifier used to identify the control unit in the third configuration file. By using the identifier in the third configuration file to generate the control unit identifier in the first configuration file, the first configuration file can be supplemented with identifiers for distinguishing data corresponding to different control units. This allows the mobile smart device to determine the target control unit corresponding to the first functional group based on the first configuration file. This eliminates the need to change existing configuration methods, making configuration of the mobile smart device more flexible.

[0019] According to a third aspect of the present application, a mobile smart device is provided, comprising a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to execute the computer program to implement the state management method of the first aspect.

[0020] According to a fourth aspect of the present application, an electronic device is provided, including a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to execute the computer program to implement the configuration file generation method of the second aspect.

[0021] According to a fifth aspect of the present application, a computer-readable storage medium is provided, on which a computer program is stored, and the computer program is used to implement the method of the first aspect or the second aspect mentioned above.

[0022] According to the sixth aspect of the present application, a computer program product is provided, comprising a computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code. When the computer-readable code runs in an electronic device, the processor in the electronic device executes the method of the first or second aspect above.

[0023] According to a seventh aspect of the present application, a device is provided that implements the device behavior described in the method of the first or second aspect. The functionality can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the functionality described above.

[0024] It should be understood that the technical solutions provided in the third, fourth, fifth, sixth and seventh aspects above, and their technical features can all correspond to the methods provided in the first aspect and its optional implementation methods, so the beneficial effects that can be achieved are similar and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] FIG1 is a schematic diagram of the relationship between a functional group and a process provided by the present application;

[0026] FIG2 is a schematic diagram of a state management control process operation process provided by the present application;

[0027] FIG3 is a schematic diagram of a method for collaborative management of multiple control units provided by the present application;

[0028] FIG4 is a simplified schematic diagram of a system architecture to which embodiments of the present application may be applied;

[0029] FIG5 is a flow chart of a state management method provided in an embodiment of the present application;

[0030] FIG6 is a schematic diagram of another state management method provided in an embodiment of the present application;

[0031] FIG7 is a flowchart of a configuration file generation method provided in an embodiment of the present application;

[0032] FIG8 is a schematic diagram of another state management method provided in an embodiment of the present application;

[0033] FIG9 is a schematic diagram of another configuration file generation method provided in an embodiment of the present application;

[0034] FIG10 is a schematic diagram of a mobile smart device provided in an embodiment of the present application;

[0035] FIG11 is a schematic diagram of another mobile smart device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0036] The vehicle control unit (VCU) is a crucial component of a vehicle, responsible for ensuring its proper operation. With the increasing number of vehicle functions, traditional standalone VCUs, such as the engine control unit (ECU) and transmission control unit (TCU), are no longer able to meet these complex functional requirements. An increasing number of functions require the coordinated implementation of multiple VCUs. Furthermore, the software systems of control units and other electronic components supplied by different manufacturers are not interoperable, significantly hindering vehicle development and hindering the development of the automotive industry.

[0037] To address the interoperability issues between electronic components supplied by different manufacturers, the automotive industry has developed a standardized software architecture, AUTOSAR. This framework establishes a series of standards that enable interoperability between the software systems of electronic components such as vehicle control units supplied by different manufacturers, thereby improving software development efficiency and accelerating the development of the automotive industry.

[0038] As the automotive industry's functional requirements continue to increase, the traditional software architecture defined by AUTOSAR can no longer meet these requirements, so the AP software architecture was proposed. The AP software architecture is flexible, configurable, and secure.

[0039] Next, we will briefly introduce the parts of the AP software architecture that are relevant to the embodiments of this application.

[0040] Vehicle control units based on the AP software architecture are also called compute domains. To control processes, these systems typically include execution management (EM). EM manages the opening and closing of processes. Through EM, processes can be started, completing corresponding vehicle functions.

[0041] In addition, in order to simplify the design and development of the system, the vehicle control unit based on the AP software architecture also includes state management (SM), which is a process used to manage the state of the function group. Among them, the function group is a collection of multiple processes in the vehicle control unit for performing the same function. The function group is generally designed by the developer according to the needs of the vehicle. A vehicle control unit based on the AP software architecture generally includes at least one function group, and a function group is usually used to complete a specific function. For example, a vehicle control unit based on the AP software architecture includes two function groups, one of which can be used to manage the startup state of the vehicle control unit, and the other function group is used to calculate the vehicle's automatic driving path. Figure 1 is a schematic diagram of a vehicle control unit based on the AP software architecture including two function groups, where function group 1 is a user-defined function group used to implement a specific function, and function group 2 is a system-defined function group, which is also called MachineState and is used to control the startup, restart, etc. of the vehicle control unit. The above Figure 1 is only a possible example of a vehicle control unit and does not represent a limitation of this application.

[0042] State management can be used to manage the states of functional groups and, through execution management, control the start or stop of processes corresponding to those functional groups. The relationship between functional groups and processes is illustrated with reference to Figure 1. In Figure 1, the dotted-line boxes represent functional groups, the dashed-line boxes represent functional group states, and the solid-line boxes represent processes. The line between a functional group and its state represents the states that the functional group can include, and the line between a functional group state and its processes represents the processes running in that state. As shown in Figure 1, functional group 1 has two states: running and off. In the running state, the two processes corresponding to functional group 1 (process 1 and process 2) will run. In the off state, the two processes corresponding to functional group 1 (process 1 and process 2) will stop running. Functional group 2 has three states: startup, reset, and update. In the on state, processes 3 and 4 corresponding to functional group 2 will run; in the reset state, process 5 will run; and in the update state, processes 5 and 6 will run.

[0043] State management can coordinate with execution management to control the execution of processes within a vehicle control unit based on the AP software architecture. The specific control process is shown in Figure 2. The solid-line boxes in Figure 2 represent processes, and the dashed-line boxes represent the actions executed by the processes. State management determines whether a functional group's state needs to be switched based on a series of trigger conditions. These trigger conditions can include: First, external triggers. For example, when state management receives external information, it can determine that the state of a functional group needs to be changed. External information can include user input, state switching requests from external systems, or other functional groups. Second, internal triggers. For example, state management can monitor the value of a sensor and determine that the state of a functional group needs to be switched if the sensor value exceeds a threshold. Alternatively, state management can determine that the state of a functional group needs to be switched when a preset period of time has passed.

[0044] When the state management determines that the state of a certain functional group needs to be switched, it will send a state switching instruction to the execution management so that the execution management can complete the state switch. For example, the state switching instruction can be an instruction to set functional group 1 to the running state. After receiving the instruction, the execution management will complete the state switch of functional group 1 by starting or shutting down the corresponding process according to the content of the configuration file. For example, as shown in Figure 1, the running state of functional group 1 requires the start of process 1 and process 2. Then, as shown in Figure 2, the execution management will control the start of process 1 and process 2. After process 1 and process 2 are started, the execution management can return information to the state management that the state switch is successful.

[0045] With the development of autonomous driving technology in the automotive field, vehicles have increasingly higher requirements for computing power and safety. Vehicle control systems are also developing in the direction of multiple vehicle control units (VCUs), that is, multiple VCUs are integrated into a single vehicle, and each VCU is a computer system that can operate independently. In this way, the vehicle's computing power requirements can be met by having multiple VCUs perform calculations in collaboration. For functions with higher safety requirements, such as emergency stop and driver protection, they can be set up in a single VCU, and the code in this VCU can be strictly reviewed. The code of other VCUs does not need to be reviewed as strictly. This can isolate the higher safety functions from other functions, ensuring that there are no problems in the code of the higher safety functions, thereby better implementing layered management and ensuring vehicle safety.

[0046] For a state management method in a scenario where a vehicle integrates multiple vehicle control units based on the AP software architecture, a hierarchical management scheme can be implemented, as shown in Figure 3. As shown in Figure 3, each vehicle control unit based on the AP software architecture, such as vehicle control unit 1, vehicle control unit 2, and vehicle control unit 3, is deployed with a state management system. This state management system can only manage the functional group of its own vehicle control unit. The process by which the state management system controls the state switching of the functional group of the current vehicle control unit in each vehicle control unit can be found in the description of Figure 2 above. Regarding the method by which vehicle control unit 1 controls the functional groups of other vehicle control units, a general state machine can be set up in vehicle control unit 1 for each of vehicle control units 2 and 3. This state machine is used to maintain the state of the functional group in the corresponding vehicle control unit. This state machine can be considered as a functional group. When the state management system in vehicle control unit 1 determines that the state of the functional group corresponding to another vehicle control unit needs to be switched, it controls the corresponding state machine to perform a state switch. This state machine state switch can then control the virtual machine management process in the vehicle control unit to communicate with the virtual machine, allowing the virtual machine to send a state switch instruction to the corresponding vehicle control unit, and the state management system in the corresponding vehicle control unit controls the state switch of the corresponding vehicle control unit according to the state switch instruction.

[0047] For example, the state management in the vehicle control unit 1 determines that the state of the functional group corresponding to the vehicle control unit 2 needs to be switched. Through execution management, the state machine corresponding to the vehicle control unit 2 will be controlled to perform state switching. Thus, the virtual machine management process sends a state switching instruction of the state machine to the virtual machine, and the virtual machine then sends the state switching instruction to the state management of the vehicle control unit 2, so that the vehicle control unit 2 completes the state management of the corresponding functional group.

[0048] In the above hierarchical management scheme, each state manager can only control the vehicle control unit in which it is located and has no perception of other vehicle control units, which makes collaborative management more complicated.

[0049] Specifically, sometimes different vehicle control units include the same functional group, that is, different vehicle control units deploy the processes corresponding to the same functional group. For example, the MachineState functional group is used to control the state of the vehicle control unit (such as turning on, off, and resetting, etc.), so it is possible that almost all vehicle control units deploy MachineState. For example, in some cases, in order to improve computing power, multiple identical vehicle control units are deployed, and the functional groups deployed in these vehicle control units are also the same.

[0050] In these situations, to ensure the vehicle maintains normal operation, the same functional groups across different vehicle control units often need to switch states together. For example, if a vehicle upgrade is required, the corresponding MachineStates of different vehicle control units must be switched to the upgrade state together. Another example is when multiple vehicle control units have the same functionality, and the functional groups of these control units also need to switch to specific states together to collaboratively complete the calculation.

[0051] However, the above-mentioned hierarchical management solution does not provide a specific implementation method for collaborative management, and the implementation logic of this method is relatively complex, which will reduce the processing efficiency of the vehicle control unit.

[0052] Based on this, the present application proposes a state management method, which is applied to a mobile intelligent device including multiple control units, wherein each control unit includes multiple functional groups, and each functional group includes multiple processes for implementing the same function. Each functional group has two states that can be switched, and the control unit completes the control of the process in the control unit by controlling the state switching of the functional group. Among the multiple control units mentioned above, at least two control units correspond to the same functional group. When it is determined that the first functional group needs to be switched from the first state to the second state, the target control unit corresponding to the first functional group can be determined according to a first configuration file including the correspondence between each control unit and the functional group, and the process corresponding to the first functional group in the target control unit can be controlled to perform state switching.

[0053] Through the above method, when multiple control units have the same functional group, the first configuration file can be used to uniformly manage the status of the same functional group in the multiple control units, thus resolving the corresponding problems of the prior art. Furthermore, the above solution simplifies the implementation logic and improves processing efficiency.

[0054] It should be noted that, although the concepts related to the functional group are described above using the vehicle control unit based on the AP software architecture as an example, the solutions of the embodiments of the present application are not limited to application in vehicles, nor are they limited to application in the AP software architecture. First of all, as for the software architecture of the control unit in the present application, the control unit of the present application is not limited to the vehicle control unit based on the AP software architecture. The control unit of the present application may also be a control unit of other software architectures with state management requirements. In addition, as for the mobile smart device in the present application, the mobile smart device of the present application may be a vehicle, or it may be a robot or other smart device such as other means of transport other than vehicles. Any device with state management requirements may serve as the execution subject of the present application.

[0055] Among them, vehicles include land vehicles, water vehicles, air vehicles, industrial equipment, agricultural equipment, or entertainment equipment. For example, the vehicle described in the embodiments of the present application can be a vehicle (such as a car, bus, subway, high-speed rail, motorcycle, flying car, train, etc.), an industrial vehicle (such as a forklift, trailer, tractor, etc.), an engineering vehicle (such as an excavator, bulldozer, crane, etc.), agricultural equipment (such as a lawn mower, harvester, etc.), amusement equipment, a toy vehicle, a boat, an air cushion vehicle, a submarine, an airplane, a helicopter, etc. The embodiments of the present application do not limit the specific type, form, and function of the vehicle.

[0056] Next, a vehicle will be used as an example to illustrate the system to which the method described in the embodiments of the present application is applied. FIG4 is a simplified schematic diagram of a system architecture to which the embodiments of the present application can be applied. As shown in FIG4 , the system architecture may include: a vehicle 41 and an electronic device 42.

[0057] The vehicle 41 is a device that has a state management requirement and is used to implement the state management method provided in the embodiment of the present application. The hardware of the vehicle 41 may include a sensor 411, a processing unit 412, and an in-vehicle infotainment system 413.

[0058] The sensor 411 may include a camera, a positioning device, a laser radar, a millimeter-wave radar, an ultrasonic radar, etc. The sensor 411 is used to collect data and transmit the data to the processing unit 412, which processes the data.

[0059] The processing unit 412 may include multiple vehicle control units. The processing unit 412 may collect data collected by the sensor 411, receive instructions sent by the user through the in-vehicle infotainment system 413, and process the received data. In an embodiment of the present application, the state management of the vehicle control unit may determine that a specific functional group needs to be switched in state based on the data collected by the sensor 411 or the instructions sent by the in-vehicle entertainment system 413. In an embodiment of the present application, the vehicle control unit may be a vehicle control unit based on the AP software architecture. The software architecture on which the vehicle control unit is based may also be other software architectures with state management requirements, which is not limited in the embodiment of the present application. The processing unit 412 may execute the method in the embodiment of the present application, such as, the processing unit 412 may control the state switching of the functional groups of multiple vehicle control units based on the first configuration file, thereby ensuring the normal operation of the vehicle.

[0060] Among them, the vehicle control unit can be a device installed on the vehicle for controlling or managing a certain function, such as a cockpit domain controller (or intelligent information domain controller), a body domain controller, a power domain controller, a chassis domain controller, an on-board computing platform (or intelligent driving domain controller), etc.

[0061] The cockpit domain controller primarily controls the various electronic information system functions within the vehicle's intelligent cockpit, including the central control system, in-vehicle infotainment system, head-up display, seating system, instrumentation system, rearview mirror system, driver behavior monitoring system, and navigation system. The body domain controller primarily controls various vehicle body functions, including but not limited to headlights, taillights, interior lights, door locks, windows, sunroof, wipers, power trunk, smart key, air conditioning, antenna, and gateway communications. The power domain controller primarily controls the vehicle's powertrain, optimizing performance and ensuring power safety, including engine management, transmission management, battery management, power distribution management, emissions management, speed limit management, and fuel and power conservation management. The chassis domain controller primarily controls the vehicle's driving behavior and posture, including but not limited to brake system management, transmission system management, driving system management, steering system management, vehicle speed sensor management, body posture sensor management, air suspension system management, and airbag system management. The intelligent driving domain controller is mainly used to provide autonomous driving perception, decision-making and other services, such as the reception of image information, image information processing and judgment, data processing and calculation, navigation and route planning, and rapid judgment and decision-making of real-time situations. The intelligent driving domain controller needs to process algorithms at the three levels of perception, decision-making, and control, and has the highest requirements for the domain controller's hardware and software.

[0062] In-vehicle entertainment system 413 is an integrated in-vehicle information processing system capable of performing navigation, vehicle control, entertainment, and other functions. In-vehicle entertainment system 413 can interact with the user and receive user operations. The in-vehicle entertainment system can communicate with processing unit 412, transmitting user operations to processing unit 412 so that processing unit 412 can process the user operations.

[0063] The electronic device 42 is a device for configuring the vehicle 41 and is used to implement the configuration file generation method provided in the embodiment of the present application. The electronic device 42 may include a processing module 421, a storage module 422, and a communication module 423.

[0064] The processing module 421 is the control center of the electronic device. For example, the processing module 421 can be any one or a combination of multiple types of a central processing unit (CPU), a field-programmable gate array (FPGA), and an application-specific integrated circuit (ASIC).

[0065] Processing module 421 can be used to receive user operations, such as through the input module. Processing module 421 can also be used to generate multiple third configuration files for vehicle 41 based on the received user operations, each of which describes the configuration information of a vehicle control unit. Processing module 421 can also convert the multiple third configuration files into a second configuration file readable by vehicle 41. Processing module 421 can also generate a first configuration file that includes correspondences between vehicle control units and functional groups based on the multiple third configuration files. The specific forms of the first, second, and third configuration files will be described in detail below.

[0066] The storage module 422 is used to store data. In the embodiment of the present application, the storage module 422 can be used to store the above-mentioned first configuration file, second configuration file and third configuration file.

[0067] The communication module 423 is used to communicate with the processing unit 412 of the vehicle 41 , thereby sending the generated first configuration file and second configuration file to the processing unit 412 of the vehicle 41 to complete the configuration of the processing unit 412 of the vehicle 41 .

[0068] Next, the method of the exemplary embodiment of the present application will be described with reference to FIG5 , FIG6 and FIG7 .

[0069] This application describes a state management method applicable to a mobile smart device, which may be a vehicle or other means of transport. The mobile smart device includes multiple control units, each of which can operate independently. Each of the multiple control units includes multiple processes, and the multiple processes included in each control unit can be divided into multiple functional groups according to the different functions they implement.

[0070] For example, if the mobile smart device is a vehicle, a control unit may include processes 1, 2, and 3. Processes 1 and 2 implement autonomous driving path planning, while process 3 is responsible for lane recognition based on data collected by the vehicle's camera sensors. Based on their respective functions, processes 1 and 2 belong to functional group 1, while process 3 belongs to functional group 2.

[0071] Each of the above-mentioned functional groups includes at least two states, and the meaning of the states of the functional groups is detailed above. The state of the functional group is used to control the running state of the process corresponding to the functional group. The running state of the process is also the start or stop of the process. In the case of different states of the functional group, the control unit can control the start or stop of at least one process corresponding to the functional group according to the state of the functional group. For example, as shown in Figure 1, in the case of different states of the functional group, the corresponding processes started in the control unit are different. In the running state of functional group 1, process 1 and process 2 included in the functional group can be started. In the open state of functional group 2, process 3 and process 4 will be started, while process 5 and process 6 will not be started.

[0072] In addition, this application targets scenarios where collaborative management is required, that is, among multiple control units, at least two control units have processes corresponding to the same functional group deployed in them. For example, a mobile smart device may include three control units, and at least two of the three control units correspond to functional group 1. In other words, at least two control units have processes 1 and 2 corresponding to functional group 1 deployed in them.

[0073] Based on the above description, FIG5 shows a flowchart of the state management method in an embodiment of the present application, including the following steps:

[0074] Step 501 : In response to a requirement that function group 1 switches from state 1 to state 2 , a target control unit corresponding to function group 1 is determined from a plurality of control units according to a general configuration file.

[0075] Specifically, when there's a need to implement a certain function, a function group state switch is triggered. For example, to implement the function of determining an autonomous driving path in a self-driving business scenario, there may be a need to switch function group 1 from state 1 to state 2. In response to this need, a target control unit corresponding to the first function group is determined from multiple control units based on the master configuration file. The master configuration file at least indicates the correspondence between each of the multiple control units and the function group.

[0076] In this application, functional group 1 may also be referred to as a first functional group, state 1 may also be referred to as a first state, state 2 may also be referred to as a second state, and the overall configuration file may also be referred to as a first configuration file.

[0077] The target control unit is the control unit in which the process corresponding to the first functional group is deployed among the multiple control units. The specific description of the general configuration file will be described in detail below.

[0078] Step 502: Control the process corresponding to function group 1 in the target control unit to switch its state.

[0079] After the target control unit is determined, the process of the corresponding functional group 1 in the target control unit can be controlled to switch states. Here, the process corresponding to functional group 1 can refer to all processes corresponding to functional group 1, or it can refer to some processes corresponding to functional group 1. The process corresponding to functional group 1 can be specifically determined based on the processes started in state 1 and state 2, that is, the processes that do not need to be started in state 2 but need to be started in state 1 are shut down, and the processes that need to be started in state 2 but do not need to be started in state 1 are started. For example, if state 1 requires process 1 to be started, and state 2 requires process 1 and process 2 to be started, then the state switching of the process corresponding to functional group 1 can refer to the start of process 2. For another example, if state 1 requires process 1 to be started, and state 2 requires process 2 to be started, then the state switching of the process corresponding to functional group 1 can refer to the shutdown of process 1 and the start of process 2.

[0080] Regarding the specific control process for implementing the above method, for example, in a control unit based on the AP software architecture, the state switching of function group 1 can be controlled through the collaboration of state management and execution management. The specific implementation method is described in detail below.

[0081] Next, the above process will be described in detail with reference to FIG6. FIG6 shows a schematic diagram of a state management method of an embodiment of the present application. In this embodiment, the mobile intelligent device is a vehicle, and the vehicle includes two control units, namely control unit 1 and control unit 2. As mentioned above, the control unit can be a domain controller, and the two control units here can both be intelligent domain controllers, and the two intelligent domain controllers together constitute the intelligent driving platform of the vehicle. In the intelligent driving platform, the vehicle needs to complete functions in a variety of business scenarios, such as the need to complete self-driving business scenarios, upgrade business scenarios and dormant business scenarios, and the functions in different business scenarios are completed through different processes. The dotted box in FIG6 represents the above business scenarios. The line connecting the business scenario to the state management center also means that the state management center needs to control the state switching of the function group to realize the above business scenarios.

[0082] Both control units 1 and 2 include an execution management node, which is also referred to as the execution management node mentioned above. In addition to the execution management node, control unit 1 may also include a state management center (SMC). This state management center differs from the aforementioned state management in that the aforementioned state management center typically only has management authority over the functional groups within its own control unit. In contrast, the state management center in this embodiment can manage functional groups in multiple control units, changing the aforementioned hierarchical management approach.

[0083] In addition, although Figure 6 shows that the state management center is deployed in control unit 1, it should be noted that the state management center unit is not limited to being deployed in control unit 1, but can also be deployed in control unit 2. In addition, a new control unit can be added to the vehicle and the state management center can be deployed in the new control unit. The execution management node and other processes are not deployed in the new control node, that is, the new control unit is a control unit dedicated to the operation of the state management center.

[0084] The state management center can also be deployed in an appropriate control unit based on the reliability of each control unit included in the mobile smart device. Specifically, to ensure the normal operation of the state management center, the state management center can be deployed in a more reliable and less prone to failure control unit. For example, the state management center can be deployed in the most reliable control unit among multiple control units. In this way, the state management center is deployed in a control unit that is less likely to fail, ensuring the normal operation of the state management center and thus the safe operation of the mobile smart device.

[0085] Regarding the specific state switching method, the state management center can determine the target control unit from multiple control units based on the overall configuration file. The determination method is the same as above.

[0086] The process of controlling the state switching of the process corresponding to functional group 1 in the target control unit may be: the state management center sends a state switching instruction to the target control unit. As shown in FIG6 , both control unit 1 and control unit 2 are deployed with the process corresponding to functional group 1. The target control units here may be control unit 1 and control unit 2. The state management center may determine the target control units as control unit 1 and control unit 2 based on the correspondence between the control unit and the functional group in the overall configuration file. The state switching instruction is an instruction for instructing functional group 1 to switch from state 1 to state 2. The target control unit receives the state switching instruction and, according to the instruction, controls the state switching of the process corresponding to functional group 1 in the target control unit.

[0087] Among them, the method for communication between the status management center and the target control node can use the existing communication means within the control unit or across the control units for communication, and the embodiments of the present application do not limit the specific communication method.

[0088] As shown in Figure 6, the above-mentioned state management center sends a state switching instruction to the target control unit, and the target control unit controls the process of the corresponding functional group 1 to complete the state switching according to the state switching instruction. It can be: the state management center sends a state switching instruction to the execution management node of the target control unit, and the execution management node controls the process of the corresponding functional group 1 to perform state switching.

[0089] In addition, in some cases, in order to control the state switching of functional group 1, the state management center not only needs to send a state switching instruction to the execution management node, but also needs to send a state switching instruction or other information to other processes of the target control unit. For example, the state management center also needs to send a state change notification to processes such as the monitoring process and the logging process of the target control unit, so that the monitoring process can monitor the operation of the control unit, and the logging process can record the state changes during the operation of the control unit. In the above case, each control unit can also include a state management node (SMN), and the state management center can send a state switching instruction to the state management node of the target control unit. The state management node forwards the state switching instruction to the execution management node, or forwards it to the execution management node and other processes, so that the execution management node can control the state switching of the process corresponding to the first functional group in the target control unit according to the state switching instruction and the sub-configuration file.

[0090] In this embodiment of the present application, a sub-profile, also referred to as a second profile, can include a functional group within a control unit and the corresponding state information for the functional group. This state information can include the corresponding state of the functional group, the state transitions that the functional group can make, and the processes that need to be started in each state of the functional group. This allows the execution management node to determine the processes that need to be started or shut down after switching the state of functional group 1 based on the sub-profile of the control unit in which it resides, thereby completing the state transition of functional group 1.

[0091] In this way, when the state management center needs to send information to the execution management node and other processes to control the functional group to complete the state switch, the state management center only needs to distinguish the state management nodes in different control units, without having to distinguish multiple different processes in different control units. This can improve processing efficiency.

[0092] The embodiment of the present application improves the state management of a mobile smart device including multiple control units, and proposes the above-mentioned centralized multi-domain (i.e., control unit) state management method, which supports defining the functional groups and states of functional groups required by different control units in different control units, deploying a state management center, maintaining the states of multiple control units, and deploying a state management node in each control unit. Based on the deployment method of a single state management center and multiple state management nodes, different functional groups defined in multiple control units are saved in a general configuration file, which can be read by the state management center, so that centralized management of different functional groups and states of multiple control units can be achieved, thereby achieving collaborative management of multiple control units.

[0093] Next, a configuration file generation method proposed in an embodiment of the present application will be described.

[0094] When each state management only has control authority over the control unit where it is located, only one configuration file will be generated for each control unit, and the state management and execution management will manage the state of the functional group according to the configuration file. In this application, since it is necessary to uniformly manage the state of all control units, it is necessary to determine the correspondence between the control unit and the functional group based on the configuration file. In addition to generating the configuration file corresponding to each control unit, it is also necessary to generate a total configuration file. The following will explain how to generate the total configuration file.

[0095] FIG7 is a flowchart of a configuration file generation method shown in the present application, comprising the following steps:

[0096] Step 701: Obtain at least two user configuration files.

[0097] First, at least two user profiles can be obtained. In this application, a user can configure each control unit on a mobile smart device through an electronic device (such as a personal computer or server, etc.). The user here refers to a user who is allowed to configure the mobile smart device. After the user completes the configuration of each control unit on the mobile smart device, a user profile corresponding to each control unit will be generated.

[0098] As for the content of the user configuration file, the user configuration file includes the configuration of the functional groups in the corresponding control unit. Specifically, the user configuration file indicates the functional groups corresponding to each process included in the corresponding control unit, as well as the status information of each functional group; the status information indicates at least two states included in the corresponding functional group, and the state of the functional group is used to control the running state of the process corresponding to the functional group. The status information can also include the state switching that each functional group can perform. That is, the user configuration file records the functional groups included in the control unit, the processes corresponding to each functional group, the multiple states of the functional groups, and the state switching that the functional groups can perform. By controlling the state switching of the functional groups, the start or stop of the processes corresponding to the functional groups can be controlled, so that the mobile smart device can realize specific functions.

[0099] In addition, the user configuration file is also referred to as a third configuration file in this application. The third configuration file can be the same as the second configuration file, that is, the user configuration file can be directly used by the execution management node of the control unit. In some embodiments, the third configuration file and the second configuration file can be different. Specifically, the third configuration file may be a file that cannot be normally read by the mobile smart device. In this case, in order to facilitate the mobile smart device to read the file, the second configuration file can be a configuration file that can be read by the mobile smart device after the third configuration file is formatted.

[0100] From the above description, it can be determined that the at least two user profiles correspond one-to-one to the at least two control units on the mobile smart device. The configuration file generation method and the state management method described above address the same scenario, so the control unit here is also the same as the control unit described above. That is, each of the at least two control units includes multiple processes, and the multiple processes of each control unit are divided into multiple functional groups according to the different functions they implement.

[0101] Step 702: Generate a general configuration file of the mobile smart device based on at least two user configuration files.

[0102] After obtaining at least two user profiles, a master profile for the mobile smart device can be generated based on the obtained at least two user profiles. The master profile has the same meaning as the master profile described above, i.e., a profile that at least indicates the correspondence between each of the multiple control units and the functional groups on the mobile smart device.

[0103] By generating a master configuration file, the process in the device that can read the master configuration file, such as the status management center, can determine the functional groups included in all control units in the mobile smart device based on the master configuration file, thereby enabling unified management of the mobile smart device and improving management efficiency.

[0104] Next, taking the mobile smart device as a vehicle, the control unit as an intelligent domain controller, and the control unit as a control unit based on the AP software architecture as an example, the configuration file generation method and status management method shown in this application are explained.

[0105] As shown in Figure 8, the vehicle in the embodiment of the present application includes two control units, namely control unit A and control unit B. Control unit A corresponds to the security domain of the vehicle and is used to complete safety-related functions in the vehicle intelligent driving platform, such as protecting driver safety. Control unit B corresponds to the general domain and is used to complete other functions in addition to safety-related functions. The security domain is more reliable than the control domain, so a state management center can be deployed in the security domain (that is, control unit A), which is responsible for centrally managing the status of all control units.

[0106] In addition, as shown in Figure 8, both control units A and B are deployed with state management nodes and execution management nodes. The execution management node is used to control the start or stop of processes. The state management node is primarily used to receive state switching instructions from the state management center and transparently transmit these instructions to the processes in the control units, for example, to the execution management node, so that the execution management node can complete process control. The state management center can load the master configuration file at startup, and the execution management node can load the control unit configuration file at startup so that these files can be used for state management.

[0107] In Figure 8, the user configuration files for control units A and B can each generate two sub-configurations. Furthermore, a master configuration file can be generated based on the two user configuration files. During state management, the state management center can send a state switching instruction based on the master configuration file to the state management node of the control unit containing the functional group that needs to switch state. Upon receiving the state switching instruction, the state management node can forward it to the execution management node, which can then switch the state of the corresponding functional group based on the control unit's configuration file.

[0108] After briefly describing FIG8 , the method of the embodiment of the present application will be described starting with the method of generating a configuration file.

[0109] The first step is to configure the function group, its status, and status switching information.

[0110] Specifically, multiple control units may include the same functional group. To facilitate the configuration of the control units, an intelligent driving platform project may be created first, and the basic information of the functional group may be configured in the public configuration file of the project.

[0111] The configuration file here may be a file in ARXML (AUTOSAR XML) format, which is a human- and machine-readable text format for describing the AUTOSAR model using extensible markup language (XML).

[0112] As shown below, the feature group configured in the public ARXML can include the following configuration information:

[0113] -Intelligent Driving Platform

[0114] -Functional group configuration

[0115] -Functional Group A (Functional Group)

[0116] - Operation (state of the functional group)

[0117] - Off (state of the function group)

[0118] -Switch from shutdown to run (state switch of function group)

[0119] -Switch the operation to off (state switch of the function group)

[0120] -MachineState (Function Group)

[0121] …

[0122] -Functional Group B (Functional Group)

[0123] …

[0124] -Functional Group C (Functional Group)

[0125] …

[0126] In the above configuration information, "intelligent driving platform" represents the intelligent driving platform project, followed by all ARXML files included in the intelligent driving platform. Function group configuration refers to the common ARXML file corresponding to the function group. Several function groups can be configured in this file. In the example above, four function groups are configured: Function Group A, Function Group B, Function Group C, and MachineState. The "Function Group" in parentheses after "Function Group A," "Function Group B," "Function Group C," and "MachineState" are tags representing the specific configuration content, specifically indicating that the configured Function Group A and MachineState are function groups. The "State" in parentheses after "Run" and "Shutdown" are also tags, indicating that the configuration content is the function group state, specifically indicating that "Run" and "Shutdown" are the states of Function Group A. Similarly, the "Function Group State Switching" in parentheses indicates that the configuration content allows the function group to switch states, specifically allowing Function Group A to switch from the Off state to the Running state, and from the Running state to the Off state. The configuration content of Function Group B, Function Group C, and MachineState is similar to that of Function Group A.

[0127] The above is just an example of configuring two states for a functional group. It is easy to understand that a functional group can include more than two states, and three or more states can also be configured for a functional group.

[0128] The second step is to configure multiple control units.

[0129] After completing the configuration of the functional group, multiple control units may be configured, that is, the functional groups of multiple control units may be configured.

[0130] In addition, the control unit's operating system, system start and stop times, processor, etc. can also be configured.

[0131] The configuration of steps 1 and 2 can be completed by the user. After the user configuration is completed, the electronic device used by the user to configure the mobile smart device can generate user configuration files for control unit A and control unit B, respectively. For example, two user configuration files, control unit A.ARXML and control unit B.ARXML, can be generated. These two user configuration files respectively record the function groups included in control unit A and control unit B, the states of the function groups, and the state transitions of the function groups.

[0132] The user configuration file of control unit A may include:

[0133] -Control Unit A (Control Unit)

[0134] …

[0135] -Functional Group B (Functional Group)

[0136] -Functional Group C (Functional Group)

[0137] -MachineState (Function Group)

[0138] The user configuration file of control unit B may include:

[0139] -Control Unit B (Control Unit)

[0140] …

[0141] -Functional Group A (Functional Group)

[0142] -Functional Group C (Functional Group)

[0143] -MachineState (Function Group)

[0144] In the above content, the control unit in parentheses after control unit A and control unit B is a label, indicating that the configured control unit A and control unit B are control units. The function group in parentheses after function group A, function group B, function group C, and MachineState are also labels, indicating that the configuration content refers to the function group configured in the public ARXML file. Ellipses indicate that the operating system, system start and stop time, processor, etc. are also configured for the control unit.

[0145] From the above user configuration file, it can be seen that the control unit A is configured with three function groups: function group B, function group C, and MachineState; the control unit B is configured with three function groups: function group A, function group C, and MachineState.

[0146] In the third step, a tool chain is used to generate a master configuration file based on the user configuration files of control unit A and control unit B. The user configuration files of control unit A and control unit B are converted into sub-configurations of control unit A and control unit B.

[0147] The third step corresponds to the tool chain configuration step in FIG8 .

[0148] As mentioned above, the intelligent driving platform cannot directly read the user configuration file. Therefore, the user configuration file can be converted into a sub-configuration file first. That is, the user configuration files of at least two control units can be formatted to obtain at least two sub-configuration files. The sub-configuration file indicates the functional groups and status information of the functional groups configured in the current control unit. In addition, to facilitate centralized status management by the status management center, a master configuration file can also be generated that includes the correspondence between each control unit and the functional group. The master configuration file includes at least the correspondence between the control unit and the functional group, and can also include the status information of the functional groups included in each control unit.

[0149] Among them, the user configuration file can be used by the execution management node, that is, as shown in Figure 8, the execution management node of control unit A reads the sub-configuration file of control unit A, and the execution management node of control unit B reads the sub-configuration file of control unit B.

[0150] Specifically, the user configuration file for control unit A can be converted into a sub-configuration file readable by the intelligent driving platform. For example, if the intelligent driving platform can read JSON files, the control unit A.ARXML file can be converted into the control unit A.json file. The sub-configuration file for control unit B is generated in the same way as the configuration file A.

[0151] Regarding the process of generating a master configuration file, unlike each configuration file which only includes configuration information for a single control unit, the master configuration file of this application can include configuration information for multiple control units. Therefore, it is necessary to add information in the master configuration file to identify the control unit to which the configuration information belongs. Furthermore, the state management center can distinguish the functional groups included in different control units based on this configuration information.

[0152] In addition, when an intelligent driving platform integrates multiple system-on-chip (SoC), the overall configuration file may also include information for identifying different SoCs.

[0153] That is, the overall configuration file includes: the identifier of each control unit in the plurality of control units, and the identifier of the functional group corresponding to each control unit identifier. Alternatively, the overall configuration file includes: the identifier of each control unit in the plurality of control units, the identifier of the functional group corresponding to each control unit identifier, and the identifier of the system-on-chip (SoC) corresponding to each control unit identifier.

[0154] Taking the json file storing key-value pairs as an example, the configuration information corresponding to control unit A in the overall configuration file may include:

[0155] The same applies to the configuration information for control unit B in the master configuration file. In the above text, the content in square brackets after the control unit key is the configuration information corresponding to a control unit. To save repetition, the configuration of the function group and other control unit configurations are omitted here. Of course, the master configuration file can also exclude other configurations and only configure the function groups included in each control unit, or only configure the function groups included in each control unit and the status of the function groups.

[0156] The key-value pair "Control Unit Identifier - Control Unit A" is the newly added information in the overall configuration file for Control Unit A. This key-value pair is used to identify that the above configuration information corresponds to Control Unit A.

[0157] The control unit identifier - control unit A key-value pair can be automatically generated by the toolchain during parsing based on the name of the user profile and other information. It can also be an extension field (admin data) added to the user profile. The extension field is used to identify the control unit corresponding to the user profile. During toolchain parsing, this extension field can be parsed into the control unit identifier - control unit A key-value pair.

[0158] That is, the identifier of the control unit included in the overall configuration file is generated according to the first identifiers in at least two user configuration files, where the first identifier is the identifier of the control unit corresponding to the third configuration file.

[0159] The first identifier is also the extension field mentioned above.

[0160] For example, the user configuration file in step 2 could look like this:

[0161] -Control Unit A (Control Unit)

[0162] …

[0163] -Functional Group B (Functional Group)

[0164] -Functional Group C (Functional Group)

[0165] -MachineState (Function Group)

[0166] -Control Unit A (Control Unit Label)

[0167] -Control Unit B

[0168] …

[0169] -Functional Group A (Functional Group)

[0170] -Functional Group C (Functional Group)

[0171] -MachineState (Function Group)

[0172] -Control Unit B (Control Unit Label)

[0173] The difference from the second step is that the user configuration file here adds a control unit label. The configuration file labels in brackets after control unit A and control unit B are labels, which means that control unit A and control unit B in front of the label are labels of the control units.

[0174] After obtaining the overall configuration file, the sub-configuration file of control unit A, and the sub-configuration file of control unit B, these files can be stored in the intelligent driving platform.

[0175] As shown in Figure 9, (a) in Figure 9 shows the contents of the user configuration file in the electronic device, and (b) in Figure 9 shows the master configuration file and sub-configurations in the vehicle. Function group configuration can configure four function groups: Function Group A, Function Group B, Function Group C, and MachineState (corresponding to Function Group D in the figure), which corresponds to the process of configuring function groups in a common ARXML file described above. The user configuration files of the two control units respectively reference the function groups shown in Figure 9, corresponding to the user configuration files in the second step above. Accordingly, after the generated sub-configurations and master configuration file are stored in the intelligent driving platform, as shown on the right side of Figure 9, the master configuration file that can be read by the state management center of control unit A includes the status information of the four function groups: Function Group A, Function Group B, Function Group C, and MachineState, as well as the corresponding relationship between the four function groups and the control units. The sub-configurations that can be read by the execution management node of control unit A include the status information of Function Group B, Function Group C, and MachineState, while the sub-configurations that can be read by the execution management node of control unit B include the status information of Function Group A, Function Group C, and MachineState.

[0176] In the fourth step, the status management center manages the functional group status of multiple control units according to the overall configuration file.

[0177] The specific management methods here can be found above.

[0178] In addition, to ensure that the vehicle can be driven safely, the following steps can be performed:

[0179] When the state switching of the first functional group is successful, a prompt message is displayed, indicating that the state switching of the first functional group is successful; wherein, the target control unit includes a first control unit and a second control unit, and the first control unit includes a control unit in the target control unit whose security level is greater than a preset threshold; when the state switching of the first control unit and the second control unit is successful, it is determined that the state switching of the first functional group is successful; or, when the state switching of the first control unit is successful and the second control unit is abnormal, it is determined that the state switching of the first functional group is successful.

[0180] That is, the target control unit includes at least one control unit with a safety level greater than a threshold, and at least one control unit with a safety level less than or equal to the threshold. When it can be determined that at least one control unit with a safety level less than or equal to the threshold is faulty, the state switching result can be determined only based on the state switching result of the non-faulty control unit. Whether the state switching of the faulty control unit with a safety level less than the threshold is successful does not affect the final state switching result.

[0181] In this way, the functions performed by control units with a safety level less than or equal to the threshold are generally unrelated to safety. To ensure that the mobile smart device can continue to operate normally even if these control units fail, the state switching result can be determined solely based on the state switching results of the control units that are not failing. In this way, if a control unit with a safety level less than or equal to the threshold fails, there is no need to repeatedly trigger the state switching of the failed control unit, ensuring that the control units with a safety level greater than the threshold can operate normally and independently, ensuring the basic operation of the control units.

[0182] At the same time, the status switching result is displayed to inform the user of the current status of the mobile smart device and improve the user experience.

[0183] Next, the state management process will be described with an example in conjunction with FIG9 .

[0184] Scenario 1: The state management center determines that a state switching requirement exists for functional group C. Based on the master configuration file, the state management center can determine that both control unit A and control unit B include functional group C. The state management center can then send a state switching instruction to the state management nodes of control units A and B, respectively, instructing functional group C to perform a state switching. The specific process by which the state management node controls the state management of functional group C is described above.

[0185] In this case, the status management center can determine the final return result based on the status switching of the functional groups C of the two control units. For example, the status management center can determine that the status switching is successful if the status switching of the functional groups C of both control units is successful. If the status switching of the functional groups C of any of the two control units fails, it can be determined that the status switching fails.

[0186] Scenario 2: The state management center determines that there is a state switching requirement for functional group A. The state management center can determine that control unit B includes functional group A based on the overall configuration file, and then send a state switching instruction to the state management node of control unit B. The instruction is used to instruct the state switching of functional group A.

[0187] In this case, the state management center can determine the state switching result of control unit B based on the state switching result forwarded by control unit B's execution management node through control unit B's state management node. For example, if control unit B's execution management node determines that the state switching of functional group A is successful, it will return the successful state switching message to control unit B's state management node. The state management node of control unit B will forward the successful state switching message to the state management center. Based on the received message, the state management center determines that the state switching of functional group A of control unit B is successful.

[0188] In scenario 3, if control unit B fails, control unit A has a safety level greater than the threshold, while control unit B has a safety level less than or equal to the threshold. Control unit A can operate independently, ensuring the vehicle can continue to operate normally for a period of time. If the state of a function group shared by both control units needs to be switched, the final switching result can be determined solely based on the state switch result of control unit A.

[0189] Specifically, the state management center can determine that there is an abnormality in control unit B through a mechanism such as a heartbeat. When the state switching of function group C is required, it can determine whether the state switching is successful based only on the state switching result of control unit A.

[0190] The state switching method of other function groups is similar to the above. In the above scenario, if the state switching is successful, a prompt message can be displayed to prompt the user of the mobile smart device that the state switching is successful.

[0191] As for the application scenarios of this application, this application can be applied to a mobile smart device that integrates a single SoC, and can also be applied to a mobile smart device that integrates multiple SoCs. The deployment method of the SMC in a mobile smart device that integrates a single SoC is the same as above. In the case where the mobile smart device integrates multiple SoCs, an SMC can also be deployed, which can control the control units in multiple SoCs. As mentioned above, in the scenario of multiple SoCs, labels for identifying the control units corresponding to different SoCs can also be added to the total configuration file.

[0192] For the SMC deployment under single SoC and dual SoC, please refer to (a) in Figure 10 and (b) in Figure 10.

[0193] As shown in (a) of Figure 10, in a single SoC scenario, a mobile smart device deploys an SMC to manage control unit 1 and control unit 2. For example, as shown in (a) of Figure 10, the SMC communicates with the execution management node to complete the state management of the functional group. Of course, an SMN can also be set in each control unit, and the SMC can also communicate with the SMN to complete the state management of the functional group.

[0194] As shown in (b) of FIG10 , in a dual-SoC scenario, one SMC can be deployed on one mobile smart device, and one SMC is used to manage control units 1 , 2 , and 3 in two SoCs.

[0195] In addition, in some cases, multiple boxes are deployed in a mobile smart device, and each box can be regarded as a control system of the mobile smart device. In the scenario where multiple boxes are deployed in a mobile smart device, only one SMC can be deployed, or an SMC can be deployed in each box, and the SMC will manage the status of the functional groups in the box. In the case where two boxes are deployed in a mobile smart device, the schematic diagram of deploying one SMC can be seen in (a) of Figure 11, and the schematic diagram of deploying one SMC in each box can be seen in (b) of Figure 11. In addition, multiple SoCs can be deployed in each box. The control method in the scenario of deploying multiple SoCs is detailed above.

[0196] The embodiments of the present application also provide a device for implementing any of the above methods, for example, providing a device including a unit (or means) for implementing each step performed by a mobile smart device in any of the above methods. For example, another device is also provided, including a unit (or means) for implementing each step performed by an electronic device in any of the above methods. The above steps can be implemented by hardware, or by hardware executing corresponding software implementations. The hardware or software includes one or more modules corresponding to the above functions, for example, a processing module, an acquisition module, and a generation module. As an example, a mobile smart device may include a processing module, and the processing module may execute the above 501 and 502; the electronic device may include an acquisition module and a processing module, and the acquisition module may execute the above 701; the processing module may execute the above 702.

[0197] The present application also provides a mobile smart device, including a memory and a processor, the memory is used to store computer programs, and the processor is used to execute the computer programs to implement the above-mentioned state management method.

[0198] The present application also provides an electronic device, including a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to execute the computer program to implement the above-mentioned configuration file generation method.

[0199] The present application also provides a computer-readable storage medium, on which a computer program is stored, and the computer program is used to implement any of the above methods.

[0200] The present application also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code. When the computer-readable code runs in an electronic device, the processor in the electronic device executes any of the above methods.

[0201] It should be understood that the division of the modules in the above device is only a division of logical functions, and in actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated.

[0202] The above is only a specific embodiment of the present application, but the scope of protection of this application is not limited to this. Any changes or substitutions within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0203] The first and second prefixes used in the embodiments of the present application are only used to distinguish different description objects and have no limiting effect on the position, order, priority, quantity or content of the described objects.

[0204] In the various embodiments of the present application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between the various embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

Claims

1. A state management method, characterized in that: Applied to a mobile smart device, the mobile smart device includes a plurality of control units, each of the plurality of control units includes a plurality of processes, the plurality of processes of each control unit are divided into a plurality of functional groups according to different functions to be implemented, each of the plurality of functional groups includes at least two states, the state of the functional group is used to control the running state of the process corresponding to the functional group, and at least two of the plurality of control units correspond to the same functional group; the method includes: In response to a requirement that the first functional group switches from a first state to a second state, determining a target control unit corresponding to the first functional group from the plurality of control units according to a first configuration file, wherein the first configuration file indicates a correspondence between each control unit in the plurality of control units and the functional group; Control the process corresponding to the first functional group in the target control unit to switch the state.

2. The method according to claim 1, characterized in that The mobile intelligent device also includes a state management center; The step of determining, according to the first configuration file, a target control unit corresponding to the first functional group from the plurality of control units comprises: The state management center determines the target control unit from the plurality of control units according to the first configuration file; The controlling the process corresponding to the first functional group in the target control unit to switch the state includes: The state management center sends a state switching instruction to the target control unit, wherein the state switching instruction is used to instruct the first functional group to switch from the first state to the second state; The target control unit receives the state switching instruction; The target control unit controls the process corresponding to the first functional group in the target control unit to switch the state according to the state switching instruction.

3. The method according to claim 2, characterized in that Each of the plurality of control units further comprises a state management node and an execution management node; The target control unit controls the process corresponding to the first functional group in the target control unit to switch the state according to the state switching instruction, including: The state management node of the target control unit receives the state switching instruction; The state management node of the target control unit forwards the state switching instruction to the execution management node of the target control unit; The execution management node of the target control unit controls the state switching of the process corresponding to the first functional group in the target control unit according to the state switching instruction and the second configuration file, and the second configuration file indicates the functional groups in the target control unit and the state information corresponding to the functional groups.

4. The method according to claim 2 or 3, characterized in that: The state management center is deployed in the control unit with the highest reliability among the multiple control units.

5. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: In the case where the state switching of the first functional group is successful, displaying prompt information, wherein the prompt information indicates that the state switching of the first functional group is successful; Wherein, the target control unit includes a first control unit and a second control unit, the first control unit includes a control unit in the target control unit whose security level is greater than a preset threshold; when the state switching of the first control unit and the second control unit is successful, it is determined that the state switching of the first functional group is successful; or, when the state switching of the first control unit is successful and the second control unit is abnormal, it is determined that the state switching of the first functional group is successful.

6. The method according to any one of claims 1 to 5, characterized in that: The first configuration file includes: an identifier of each control unit in the plurality of control units, and an identifier of a function group corresponding to the identifier of each control unit; or The first configuration file includes: an identifier of each control unit in the plurality of control units, an identifier of a functional group corresponding to the identifier of each control unit, and an identifier of a system on chip SoC corresponding to the identifier of each control unit.

7. A configuration file generation method, characterized in that: The method comprises: Acquire at least two third configuration files, the at least two third configuration files correspond one-to-one to at least two control units on the mobile smart device, each of the at least two control units includes a plurality of processes, the plurality of processes of each control unit are divided into a plurality of function groups according to different functions to be implemented, the third configuration file indicates a function group corresponding to each process included in the control unit corresponding to the third configuration file, and state information of each function group; the state information indicates at least two states included in the corresponding function group, and the state of the function group is used to control the running state of the process corresponding to the function group; A first configuration file of the mobile intelligent device is generated according to at least two of the third configuration files, wherein the first configuration file indicates a corresponding relationship between each control unit of a plurality of control units on the mobile intelligent device and a functional group.

8. The method according to claim 7, characterized in that The first configuration file includes: an identifier of each control unit in the plurality of control units, and an identifier of a function group corresponding to the identifier of each control unit; or The first configuration file includes: an identifier of each control unit in the plurality of control units, an identifier of a functional group corresponding to the identifier of each control unit, and an identifier of a system on chip SoC corresponding to the identifier of each control unit.

9. The method according to claim 8, characterized in that The identifier of the control unit included in the first configuration file is generated according to the first identifiers in the at least two third configuration files, and the first identifier is the identifier of the control unit corresponding to the third configuration file.

10. A mobile intelligent device, characterized in that: The system comprises a plurality of control units, a memory and a processor, wherein each of the plurality of control units comprises a plurality of processes, wherein the plurality of processes of each control unit are divided into a plurality of functional groups according to different functions to be implemented, wherein each of the plurality of functional groups comprises at least two states, wherein the state of the functional group is used to control the running state of the process corresponding to the functional group, and at least two of the plurality of control units correspond to the same functional group; The memory is used to store a computer program, and the processor is used to execute the computer program to implement the state management method according to any one of claims 1 to 6.

11. An electronic device, characterized in that: The invention comprises a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to execute the computer program to implement the configuration file generation method according to any one of claims 7 to 9.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the computer program is used to implement the method according to any one of claims 1 to 9.

Images