Supports fine-grained state management methods, systems, vehicles, and storage media.

By configuring dependencies and state machines in multiple service layers of the in-vehicle software platform, fine-grained state management is achieved, solving the problem of vehicle malfunctions affecting the whole system caused by process-level management in existing technologies, and improving vehicle operation performance and user experience.

CN116781473BActive Publication Date: 2026-06-30GUOKE FOUNDATION STONE (CHONGQING) SOFTWARE CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
GUOKE FOUNDATION STONE (CHONGQING) SOFTWARE CO LTD
Filing Date
2023-06-12
Publication Date
2026-06-30

AI Technical Summary

Technical Problem

Existing middleware architectures can only achieve process-level state management in in-vehicle software, which means that minor faults in the vehicle can affect the overall program operation, resulting in poor vehicle operation performance and user experience.

Method used

By setting up application service layers, composite service layers, and executable program atomic service layers in multiple service layers of the software platform, and configuring the dependencies and state machines between each layer, fine-grained state management can be achieved, including the state transitions of applications, service programs, and node nodes.

Benefits of technology

It enables fine-grained state management within the vehicle, preventing minor malfunctions from rendering service programs or applications unusable, thereby improving vehicle functionality and user experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116781473B_ABST
    Figure CN116781473B_ABST
Patent Text Reader

Abstract

This disclosure relates to a method, system, vehicle, and storage medium supporting fine-grained state management. The method is applied to multiple service layers, wherein the application service layer includes an application group of at least one application, and the composite service layer includes a functional group of at least one service program. The service programs are accessible to at least one application through an interface. An executable program atomic service layer sets up multiple node nodes, each attached to at least one service program. Configuration information is configured between the multiple service layers, including dependencies between applications and service programs, the state machines of each application, service program, node node, and software platform, mapping relationships between state machines, and state switching rules. Switching between the application and software platform states is implemented according to switching instructions. This invention solves the problem of service programs and applications becoming unusable due to minor faults during vehicle use, resulting in poor vehicle operation performance and user experience.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to the field of service architecture technology, and in particular to methods, systems, vehicles, and storage media that support fine-grained state management. Background Technology

[0002] Service-oriented software architecture (SOA) has become the mainstream evolutionary direction for passenger vehicle in-vehicle software and autonomous vehicle underlying software. In SOA, middleware software is particularly critical, playing a role in connecting upper-layer business services with lower-layer communication protocols and operating systems.

[0003] State management, as an important part of the framework, is mainly used to manage the state at the ECU level and the vehicle level. However, existing state management components in mainstream middleware architectures such as Adaptive AUTOSAR or ROS2 all have their own shortcomings. They only have the layout of process-level state management components, and the granularity of state management can only reach the process-level application program or process-level service program. This leads to the problem that a small fault during vehicle use will affect the operation of the global program, resulting in poor vehicle operation performance and user experience. Summary of the Invention

[0004] To overcome the problems existing in related technologies, this disclosure provides a method, system, medium, and vehicle that supports fine-grained state management.

[0005] According to a first aspect of the present disclosure, a fine-grained state management method is provided, including multiple service layers applied to a software platform, wherein the multiple service layers include an application service layer, a composite service layer, and an executable program atomic service layer;

[0006] The application service layer sets up an application group, and the application group sets up at least one application.

[0007] The combined service layer is configured with functional groups, and each functional group contains at least one service program; the service program is called by at least one application program through a general interface.

[0008] The executable program atomic service layer is configured with multiple node nodes, each node node being attached to at least one of the service programs; characterized in that it includes:

[0009] Configure the configuration information between the multiple service layers and generate a configuration file. The configuration information includes the dependency relationship between the application and the service program, the state machine of each application, each service program and each node, the mapping relationship between the state machines and the state switching rules.

[0010] Based on the switching instructions and the configuration file, the state switching of at least one of the application, service program, and node is realized, thereby realizing the state management of the multiple service layers.

[0011] Furthermore, the state management of the multiple service layers includes:

[0012] Based on the service programs that each application in each application group depends on, the state machines of each application, each service program, each node, and the mapping relationship between each state machine, the state machine of the service program attached to each node and the running state of the corresponding service program are determined according to the state machine of each node.

[0013] Based on the state machine of each service program, determine the running state of the application corresponding to the state machine of each application that has a dependency on it, and then determine the running state of the application group.

[0014] Furthermore, the implementation of state switching for at least one of the application, service program, and node includes:

[0015] Based on the configuration file generated by the configuration module, the running status of each application set in the application group, the service program that has a dependency relationship with each application, and the node node attached to the service program are switched according to the switching instruction.

[0016] Furthermore, the switching between applications includes the following steps:

[0017] When a switching command is detected as an application switching command, determine whether the current state meets the switching conditions.

[0018] When the switching conditions are met, the target application group is determined according to the application switching instruction, and the functional group that has a dependency relationship with the target application group is determined according to the configuration file;

[0019] A start command is sent to the service program and its associated node in the functional group, and the state machine of each service program and node is changed to the corresponding first state machine;

[0020] The second state machine of each application is determined based on the first state machine, and it is determined whether the application group is started.

[0021] Furthermore, it also includes the management of switching platform operating states, with specific steps including:

[0022] Listen for the platform state switching command;

[0023] When a platform state switching instruction is detected, and the current state meets the switching conditions, the state to be switched to is determined according to the platform state switching instruction.

[0024] The platform software state machine is changed to the corresponding third state machine to realize the change of platform software state; wherein,

[0025] The platform software state machine includes:

[0026] ①. The default state when the execution management component starts. In this state, the execution management component starts all platform software.

[0027] ②. After completing the startup phase, the state management component switches to the running phase;

[0028] ③. All applications are closed, but the platform software is running normally;

[0029] ④. Start the software platform;

[0030] ⑤. Close all applications and platform software;

[0031] ⑥. User-defined modes, including safe mode or limp mode.

[0032] According to a second aspect of the present disclosure, a fine-grained state management system is provided, comprising multiple service layers, a configuration module, and a state management component; wherein...

[0033] The multiple service layers include an application service layer, a composite service layer, and an executable program atomic service layer;

[0034] The application service layer sets up an application group, and the application group sets up at least one application.

[0035] The combined service layer is configured with functional groups, and each functional group contains at least one service program; the service program is called by at least one application program through a general interface.

[0036] The executable program atomic service layer is configured with multiple node nodes, each of which is attached to at least one of the service programs, enabling the service programs to combine the executable program atomic services according to various control simulation scenarios;

[0037] Configuration module: used to set configuration information between the multiple service layers and generate configuration files. The configuration information includes the dependency relationship between the application and the service program, the state machine of each application, each service program, and each node, the mapping relationship between the state machines, and the state switching rules.

[0038] State management component: Used to switch the state of at least one of the application, service program, and node node according to the switching instructions and the configuration file.

[0039] Furthermore, the state management component performs the following steps:

[0040] Based on the service programs that each application in each application group depends on, the state machines of each application, each service program, each node, and the mapping relationship between each state machine, the state machine of the service program attached to each node and the running state of the corresponding service program are determined according to the state machine of each node.

[0041] Based on the state machine of each service program, determine the running state of the application corresponding to the state machine of each application that has a dependency on it, and then determine the running state of the application group.

[0042] Furthermore, the state management component is used to switch the running state of each application set in the application group, the service program that has a dependency relationship with each application, and the node node attached to the service program, based on the configuration file and according to the switching instruction.

[0043] According to a third aspect of the present disclosure, a vehicle is provided that stores a set of instructions, which are executed by the vehicle to implement the fine-grained state management method provided in the first aspect of the present disclosure.

[0044] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided having computer program instructions stored thereon, which, when executed by a processor, implement the steps of the fine-grained state management method provided in the first aspect of the present disclosure.

[0045] The technical solutions provided by the embodiments of this disclosure may include the following beneficial effects: by setting different state machines for each layer in multiple service layers and setting the mapping relationship between state machines, each application, each service program and each node is discretized and managed. Through the linkage changes of state transitions and actions of each layer, the granularity of state management is refined to the node level, so that service programs or even applications will not become unusable due to minor faults during vehicle use, thereby improving the vehicle's functional operation performance and user experience.

[0046] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0047] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0048] Figure 1 This is a flowchart illustrating a fine-grained state management method according to an exemplary embodiment.

[0049] Figure 2 This is a schematic diagram of a multi-service layer architecture according to an exemplary embodiment.

[0050] Figure 3 This is a flowchart illustrating another method for supporting fine-grained state management according to an exemplary embodiment.

[0051] Figure 4 This is a flowchart illustrating a third method for supporting fine-grained state management according to an exemplary embodiment.

[0052] Figure 5 This is a sequence diagram illustrating the state transitions of a process-level application or a process-level service program according to an exemplary embodiment.

[0053] Figure 6 This is a schematic diagram illustrating the definition of state machines and switching rules for each service layer according to an exemplary embodiment.

[0054] Figure 7 This is a schematic diagram illustrating the mapping relationship settings of the state machines of multiple service layers according to an exemplary embodiment.

[0055] Figure 8 This is a schematic diagram of the state machine transition at the node level, according to an exemplary embodiment.

[0056] Figure 9 This is a block diagram illustrating a fine-grained state management system according to an exemplary embodiment.

[0057] Figure 10 This is a block diagram illustrating a vehicle according to an exemplary embodiment. Detailed Implementation

[0058] The exemplary embodiments will now be described in detail with reference to the accompanying drawings.

[0059] It should be noted that the relevant embodiments and accompanying drawings are only for describing and illustrating exemplary embodiments provided by this disclosure, and not all embodiments of this disclosure, nor should this disclosure be understood to be limited to the relevant exemplary embodiments.

[0060] It should be noted that the terms "first," "second," etc., used in this disclosure are only used to distinguish different steps, devices, or modules. These terms do not represent any specific technical meaning, nor do they indicate any order or interdependence between them.

[0061] It should be noted that the terms “a,” “a plurality of,” and “at least one” used in this disclosure are illustrative rather than restrictive. Unless otherwise expressly indicated in the context, they should be understood as “one or more.”

[0062] It should be noted that the term "and / or" used in this disclosure is used to describe the relationship between related objects, and generally indicates that there are at least three relationships. For example, A and / or B can at least indicate: the existence of A alone, the existence of both A and B, and the existence of B alone.

[0063] It should be noted that the various steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Unless otherwise specified, the scope of this disclosure is not limited to the order in which the steps are described in the relevant embodiments.

[0064] It should be noted that all actions involving the acquisition of signals, information, or data in this disclosure are carried out in compliance with the relevant data protection laws and policies of the country where the location is situated, and with authorization from the owner of the relevant device.

[0065] Technical Terminology Explanation

[0066] State Management (SM) is responsible for the unified management of the runtime state of the software platform and its various service layers. This includes processing incoming events / requests, determining their priorities and corresponding internal states. State management typically involves one or more state machines, depending on the requirements.

[0067] State machine: Composed of state registers and combinational logic circuits, it can transition between states according to a pre-set state based on control signals. It is the control center that coordinates related signal actions and completes specific operations.

[0068] ROS2: ROS2 was formerly known as ROS (Robot Operating System). ROS2 is a middleware used for anonymous publish / subscribe and message passing between different processes.

[0069] A node is an entity that uses the ROS system to communicate with other nodes. Nodes communicate with other nodes through the ROS client library. Nodes can publish or subscribe to topics, provide ROS services, and have relevant configurable parameters. Connections between nodes are established through a distributed discovery process. Different nodes can be in the same process, in different processes, or even on different machines.

[0070] Exemplary methods

[0071] Figure 1 This is a flowchart illustrating a fine-grained state management method according to an exemplary embodiment. This embodiment is applied to multiple service layers. The state management function in this embodiment can be implemented in a componentized manner, for example, as a package file stored in a middleware architecture such as ROS2, and the package file is called by the scheduler to compile and run under the architecture, thereby realizing the state management function. The implementation process can be achieved by existing technologies, which will not be elaborated here.

[0072] In this embodiment, the multiple service layers include an application service layer, a composite service layer, and an executable program atomic service layer.

[0073] The application service layer sets up an application group, in which at least one application is configured.

[0074] The composite service layer sets up functional groups, and each functional group sets up at least one service program; the service program is called by at least one application through a general interface.

[0075] The executable program atomic service layer is configured with multiple node nodes, each node node being attached to at least one of the service programs, enabling the service programs to combine the executable program atomic services according to various control simulation scenarios.

[0076] In one specific embodiment, the reference opening Figure 2 The diagram illustrates the multiple service layer architecture provided in this embodiment. The application service layer sets up applications such as welcome mode, music-responsive mode, and fragrance atmosphere; the combined service layer sets up functional groups of service programs such as door control, window control, lighting control, and air conditioning control; and the executable program atomic service layer sets up multiple node nodes. For example, the door control service program has two attached node nodes. The welcome mode application depends on the two functional groups of the door control service program and the window control service program. In other words, the door control and window control service programs are called by the welcome mode application through an interface.

[0077] like Figure 1 As shown, the method in this embodiment includes the following steps.

[0078] In step S110, configuration information between the multiple service layers is configured and a configuration file is generated. The configuration information includes the dependency relationship between the application and the service program, the state machine of each application, each service program, each node node and the state machine of the software platform, the mapping relationship between the state machines and the state switching rules.

[0079] In some embodiments, the definition of state is divided into two levels, including machine state and function group state.

[0080] Machine State: A special type of FunctionGroup State responsible for the startup / shutdown state of platform software, such as application service layer, composite service layer and executable program atomic service layer state management (StateManage, SM) and execution management (ExecutionManage, EM).

[0081] FunctionGroup State: Responsible for the application's startup / shutdown state, such as... Figure 2 The configured function groups (e.g., DoorGroup) and applications (e.g., Welcome Mode App1-Group) manage the state of dependent service programs and applications, thereby enabling the startup and shutdown of the entire application.

[0082] In step S120, the configuration file is obtained according to the switching instruction, thereby enabling the switching of the application, service program, node node, and software platform states.

[0083] This embodiment of the method sets different state machines for each of the multiple service layers and the mapping relationship between the state machines, and performs discretized management of each application, each service program and each node. By linking the state transitions and actions of each layer, the granularity of state management is refined to the node level, so that minor faults do not cause service programs or even applications to become unusable during vehicle use, thereby improving vehicle operation performance and user experience.

[0084] In some embodiments, to implement a fine-grained state management mechanism, the running state of the node nodes in the lowest-level atomic service layer affects the running state of the service program, and the running state of the service program affects the running state of the uppermost applications that depend on it, thereby achieving linkage of state changes across the entire service layer. The state management of the multiple service layers includes:

[0085] Based on the service programs that each application in each application group depends on, the state machines of each application, each service program, each node, and the mapping relationship between each state machine, the state machine of the service program attached to each node and the running state of the corresponding service program are determined according to the state machine of each node.

[0086] Based on the state machine of each service program, determine the running state of the application corresponding to the state machine of each application that has a dependency on it, and then determine the running state of the application group.

[0087] In some embodiments, reference Figure 3 The diagram shown is a flowchart of another fine-grained state management method provided in this embodiment. This embodiment provides a fine-grained state management method. In step S120, according to the switching instruction, the configuration file is obtained, and the switching of the application, service program, node, and software platform states is implemented, including:

[0088] Step S1201: Based on the configuration file, switch the running status of each application set in the application group, the service program that has a dependency relationship with each application, and the node node attached to the service program according to the application switching instruction.

[0089] Step S1202: Based on the configuration file, switch the platform software running state according to the platform state switching instruction.

[0090] In some embodiments, reference Figure 4 The diagram shows another fine-grained state management method provided in this embodiment. To ensure vehicle safety, state switching occurs when the current vehicle operating state meets the switching conditions. This embodiment provides a fine-grained state management method, which includes the following steps for implementing the switching of various applications:

[0091] Step S101: When the application-level state management component detects that the switching instruction is an application switching instruction, it determines whether the current state meets the switching conditions.

[0092] Step S102: When the switching conditions are met, determine the target application group according to the application switching instruction, and determine the functional group that has a dependency relationship with the target application group according to the configuration file.

[0093] Step S103: Send a start command to the service program and its associated node in the functional group, and change the state machine of each service program and node to the corresponding first state machine;

[0094] Step S104: Determine the second state machine of each application based on each first state machine, and determine whether the application group is started.

[0095] In this embodiment, reference Figure 5 The diagram shown is a sequence diagram of state transitions for a process-level application or process-level service program provided in this embodiment, including:

[0096] Step 201: When the SM (StateManage) component is started and receives a state group switching request, it requests to switch to execution state group B (the application group);

[0097] Step 202: Determine whether the current execution state meets the preset state switching conditions. If it does, switch the execution state group B and send a trigger to the EM (Execution Management) component.

[0098] Step 203: The EM component determines the service programs that the application in the current state group B has a dependency relationship by reading the configuration information in the Manifest configuration file, including APP1 and APP2, and APP1 and APP2 belong to state group A.

[0099] Step 204: Determine whether each dependent service program is currently in an executing or occupied state, and whether the current executing state meets the switching conditions. When each dependent service program is in a waiting state and the current executing state meets the switching conditions, start the dependent state group A and the current state group B.

[0100] In this embodiment, the steps include determining whether the current execution state is switching conditions. This is because the time from the initial judgment logic of the SM component to the EM component reading the configuration file in step 2 and determining the switching execution state group and its logical relationship is relatively long (e.g., 5 seconds). If the current system execution state changes (e.g., the vehicle speed increases from 20 mph to 30 mph), then the current system execution state will not meet the switching conditions of some state groups.

[0101] Specifically, based on the dependency relationship, when the startup of an application group C depends on another functional group D, the startup state of functional group D needs to be determined according to the mapping of the set state machine. Specifically, since functional group D can contain multiple service programs, and each process has multiple attached / encapsulated nodes, based on the state machines of each application, each service program, each node, and the state machine of the software platform, and the mapping relationship between the state machines, the state machine of the service program is determined according to the state machine of each node in the service program. Then, based on the state machines of each service program set in functional group D and the mapping relationship with the state machine of application group C, the state machine of application group C is determined, thereby determining the startup state of application group C.

[0102] This embodiment divides the service programs in the functional group into node-level components. Then, during state machine setup, state machine mapping ensures that each service program can keep its associated nodes running while maintaining their functionality, thus achieving functional degradation. Since the nodes are encapsulated within the service programs, they do not consume system resources. Node management uses executors and callback functions to manage the callback order and execute the logic of each node according to the callback order. For example, in a window control service program, there are five nodes (left front window, right front window, left rear window, right rear window, and sunroof). Existing technologies do not achieve node-level state management, meaning that if one window malfunctions, the entire window control service becomes unusable. This embodiment implements node-level state management, allowing for more granular management of each window node. Even if one window malfunctions, the window control service can continue to control other healthy windows.

[0103] Similar to the process of switching between various applications, the step of switching the platform software running state according to the platform state switching instruction includes the following steps:

[0104] Step S201: Listen for the switching command;

[0105] Step S202: When the switching instruction is detected as a platform state switching instruction, and it is determined that the current state meets the switching conditions, the state to be switched is determined according to the platform state switching instruction.

[0106] Step S203: The platform software state machine is changed to the corresponding third state machine to realize the change of the platform software state.

[0107] In one specific embodiment, such as Figure 6 The diagram shown illustrates the definition of the state machines and switching rules for each service layer provided in this embodiment. The platform software state machine settings include:

[0108] ①. The default state when the execution management component starts. In this state, the execution management component starts all platform software.

[0109] ②. After completing the startup phase, the state management component switches to the running phase;

[0110] ③. All applications are closed, but the platform software is running normally;

[0111] ④. Start the software platform;

[0112] ⑤. Close all applications and platform software;

[0113] ⑥. User-defined modes, including safe mode or limp mode.

[0114] The feedback values ​​(returns) for each state machine are set according to user requirements and can be referenced. Figure 6 As shown.

[0115] In this embodiment, reference Figure 7 The diagram shows the mapping relationship settings of the state machines of the multiple service layers provided in this embodiment. According to the diagram, the startup of the application in the welcome mode of the application, such as App1-Group, depends on two functional groups: the door control service program and the window control service program. The door control service program has attached left front door NODE and right front door NODE, and the window control service program has attached left front window NODE and right front window NODE. Therefore, according to the state machine and mapping relationship settings, the state machines of left front door NODE, right front door NODE, left front window NODE and right front window NODE must first be determined. Then, according to the mapping relationship settings between the state machines of left front door NODE and right front door NODE and the state machine of door control service program, the state machine of door control service program is determined. If the mapping relationship is set such that either the state machine of left front door NODE or right front door NODE is Active (0x2), then the state machine of door control service program is fOn (0x0).

[0116] In one embodiment, reference Figure 8 The diagram shown is a schematic of the node-level state machine transition provided in this embodiment. The execution and state transition of each node are triggered by the tigger sent by the corresponding service program. When a node receives a tigger such as Startup, Shutdown or Resert from the service program, it realizes the change of the state of the dependent service program according to the set state machine and mapping relationship, and returns the changed state machine to the corresponding service program.

[0117] This embodiment employs a multi-layered service state management approach through the mapping design and implementation of process-level and node-level state machines. This tightly couples the software platform's state transitions and actions, allowing the software platform to alter its behavior when its internal state changes, thus appearing as if the platform's behavior has been modified. By refining the granularity of state management down to the node level, this fine-grained state management enables the precise management of the platform's software function interactions and operations, providing fundamental support for the platform's scalability and stability.

[0118] Exemplary System

[0119] Figure 9 This is a block diagram illustrating a fine-grained state management system according to an exemplary embodiment. The system includes multiple service layers, a configuration module 210, and a state management component 220; wherein,

[0120] The multiple service layers include an application service layer, a composite service layer, and an executable program atomic service layer;

[0121] The application service layer sets up an application group, and the application group sets up at least one application.

[0122] The combined service layer is configured with functional groups, and each functional group contains at least one service program; the service program is called by at least one application program through a general interface.

[0123] The executable program atomic service layer is configured with multiple node nodes, each node node being attached to at least one of the service programs, enabling the service programs to combine the executable program atomic services according to various control simulation scenarios.

[0124] Configuration module 210: used to set configuration information between the multiple service layers and generate configuration files. The configuration information includes the dependency relationship between the application and the service program, the state machine of each application, each service program, and each node, the mapping relationship between the state machines, and the state switching rules.

[0125] State management component 220: used to switch the state of at least one of the application, service program, and node node according to the switching instruction and the configuration file, and to realize the state management of the multiple service layers.

[0126] In this embodiment, the system uses the configuration module 210 to set different state machines for each of the multiple service layers and the mapping relationships between the state machines. The state management component 220 performs discretized management of each application, each service program, and each node. Through the linkage changes of state transitions and actions at each layer, the state management granularity is refined to the node level, so that minor faults do not cause service programs or even applications to become unusable during vehicle use, thereby improving the vehicle's functional operation performance and user experience.

[0127] In some embodiments, the state management component 220 manages the state of multiple service layers, including:

[0128] Based on the service programs that each application in each application group depends on, the state machines of each application, each service program, and each node, and the mapping relationship between each state machine, the state machine of the service program attached to each node and the running state of the corresponding service program are determined according to the state machine of each node.

[0129] Based on the state machine of each service program, determine the running state of the application corresponding to the state machine of each application that has a dependency on it, and then determine the running state of the application group.

[0130] In some embodiments, the state management component 220 includes a platform software management component and an application management component. The platform-level state management component is used to switch the running state of the platform software according to the platform state switching instructions based on the configuration information of the configured platform software state machine and running state switching rules.

[0131] The application-level state management component is used to switch the running state of each application set in the application group, the service program that has a dependency relationship with each application, and the node node attached to the service program, based on the configuration file and according to the application switching instruction.

[0132] The system embodiments disclosed herein correspond to the technical solutions of the method embodiments described above. The specific operations of each module can be understood by referring to the descriptions in the method embodiments. For details, please refer to... Figure 1-8 I understand, so I won't go into details here.

[0133] Exemplary vehicle

[0134] Figure 10 This is a block diagram illustrating a vehicle 800 according to an exemplary embodiment. The vehicle 800 may be a gasoline vehicle, a hybrid vehicle, an electric vehicle, a fuel cell vehicle, or other types of vehicles.

[0135] Reference Figure 10 The vehicle 800 may include multiple subsystems, such as a drive system 810, a control system 820, a sensing system 830, a communication system 840, an information display system 850, and a computing processing system 860. The vehicle 800 may also include more or fewer subsystems, and each subsystem may include multiple components, which will not be described in detail here.

[0136] The drive system 810 includes components that provide power to the vehicle 800. These include, for example, an engine, an energy source, and a transmission.

[0137] The control system 820 includes components that provide control for the vehicle 800. These include, for example, vehicle control, cockpit equipment control, and driver assistance control.

[0138] The perception system 830 includes components that provide the vehicle 800 with perception of its surroundings. These include, for example, a vehicle positioning system, a laser sensor, a voice sensor, an ultrasonic sensor, and camera equipment.

[0139] The communication system 840 includes components that provide communication connectivity for the vehicle 800. These may include, for example, mobile communication networks (e.g., 3G, 4G, 5G networks), WiFi, Bluetooth, and vehicle-to-everything (V2X) connectivity.

[0140] The information display system 850 includes components that provide various information displays for the vehicle 800. These include, for example, vehicle information displays, navigation information displays, and entertainment information displays.

[0141] The computing processing system 860 includes components that provide data computing and processing capabilities for the vehicle 800. The computing processing system 860 may include at least one processor 861 and a memory 862. The processor 861 can execute instructions stored in the memory 862.

[0142] The processor 861 can be any conventional processor, such as a commercially available CPU. The processor may also include, for example, a Graphics Processing Unit (GPU), a Field Programmable Gate Array (FPGA), a System on Chip (SOC), an Application Specific Integrated Circuit (ASIC), or a combination thereof.

[0143] The memory 862 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0144] In this embodiment of the disclosure, a set of instructions is stored in the memory 862, and the processor 861 can execute the set of instructions to implement all or part of the steps of the fine-grained state management method described in any of the exemplary embodiments above.

[0145] Exemplary computer-readable storage media

[0146] In addition to the methods and apparatus described above, exemplary embodiments of this disclosure may also be a computer program product or a computer-readable storage medium storing the computer program product. The computer product includes computer program instructions that can be executed by a processor to perform all or part of the steps described in any of the methods in the exemplary embodiments described above.

[0147] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages, and scripting languages ​​(e.g., Python). The program code can be executed entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0148] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: static random access memory (SRAM) having one or more electrically connected wires, electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk, or any suitable combination thereof.

[0149] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of this disclosure. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0150] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A state management method applied to multiple service layers of a software platform, wherein the multiple service layers include an application service layer, a composite service layer, and an executable program atomic service layer; The application service layer sets up an application group, and the application group sets up at least one application. The combined service layer is configured with functional groups, and each functional group contains at least one service program; the service program is called by at least one application program through a general interface. The executable program atomic service layer is configured with multiple node nodes, each node node being attached to at least one of the service programs; characterized in that it includes: Configure the configuration information between the multiple service layers and generate a configuration file. The configuration information includes: the dependency relationship between the application and the service program, the state machine of each application, each service program and each node, the mapping relationship between the state machines and the state switching rules. Based on the switching instructions and the configuration file, the state switching of at least one of the application, service program, and node is realized, thereby realizing the state management of the multiple service layers.

2. The state management method according to claim 1, characterized in that, The state management of the multiple service layers includes: Based on the service programs that each application in each application group depends on, the state machines of each application, each service program, each node, and the mapping relationship between each state machine, the state machine of the service program attached to each node and the running state of the corresponding service program are determined according to the state machine of each node. Based on the state machine of each service program, determine the running state of the application corresponding to the state machine of each application that has a dependency on it, and then determine the running state of the application group.

3. The state management method according to claim 1 or 2, characterized in that, The implementation of state switching for at least one of the application, service program, and node includes: Based on the configuration file generated by the configuration module, the running status of each application set in the application group, the service program that has a dependency relationship with each application, and the node node attached to the service program are switched according to the switching instruction.

4. The state management method according to claim 1, characterized in that, The process of switching between applications includes the following steps: When a switching command is detected as an application switching command, determine whether the current state meets the switching conditions. When the switching conditions are met, the target application group is determined according to the application switching instruction, and the functional group that has a dependency relationship with the target application group is determined according to the configuration file; A start command is sent to the service program and its associated node in the functional group, and the state machine of each service program and node is changed to the corresponding first state machine; The second state machine of each application is determined based on the first state machine, and it is determined whether the application group is started.

5. The state management method according to claim 1, characterized in that, It also includes the management of switching platform operating states, with specific steps including: Listen for the switching command; When a platform state switching instruction is detected, and the current state meets the switching conditions, the state to be switched to is determined according to the platform state switching instruction. The platform software state machine is changed to the corresponding third state machine to realize the change of platform software state; wherein, The platform software state machine includes: ①. The default state when the execution management component starts. In this state, the execution management component starts all platform software. ②. After completing the startup phase, the state management component switches to the running phase; ③. All applications are closed, but the platform software is running normally; ④. Start the software platform; ⑤. Close all applications and platform software; ⑥. User-defined modes, including safe mode or limp mode.

6. A status management system, characterized in that, It includes multiple service layers, configuration modules, and state management components; among them, The multiple service layers include an application service layer, a composite service layer, and an executable program atomic service layer; The application service layer sets up an application group, and the application group sets up at least one application. The combined service layer is configured with functional groups, and each functional group contains at least one service program; the service program is called by at least one application program through a general interface. The executable program atomic service layer is configured with multiple node nodes, each of which is attached to at least one of the service programs, enabling the service programs to combine the executable program atomic services according to various control simulation scenarios; Configuration module: used to set configuration information between the multiple service layers and generate configuration files. The configuration information includes the dependency relationship between the application and the service program, the state machine of each application, each service program and each node, the mapping relationship between the state machines and the state switching rules. State management component: used to switch the state of at least one of the application, service program, and node node according to the switching instruction and the configuration file, and to realize the state management of the multiple service layers.

7. The status management system according to claim 6, characterized in that, The state management component performs the following steps: Based on the service programs that each application in each application group depends on, the state machines of each application, each service program, each node, and the mapping relationship between each state machine, the state machine of the service program attached to each node and the running state of the corresponding service program are determined according to the state machine of each node. Based on the state machine of each service program, determine the running state of the application corresponding to the state machine of each application that has a dependency on it, and then determine the running state of the application group.

8. The status management system according to claim 6, characterized in that, The state management component is specifically used to switch the running state of each application set in the application group, the service program that has a dependency relationship with each application, and the node node attached to the service program, based on the configuration file and according to the switching instruction.

9. A vehicle, characterized in that, A set of instructions is stored, which is executed by the vehicle, including the state management method as described in any one of claims 1-5.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the program instructions are executed by the processor, they implement the steps of the state management method according to any one of claims 1-5.