A message processing method and device, and a storage medium

Abstract

The application discloses a message processing method and device and a storage medium. Taking that the method is applied to an electronic device with processing capability as an example, the method specifically comprises the following steps: the electronic device acquires data to be processed, and then, according to the data to be processed, a first state machine is run. The first state machine comprises a first sub-state machine and a plurality of second sub-state machines, the states in the first sub-state machine comprise states shared by a plurality of application tasks, one second sub-state machine comprises the states of one application task, and the states comprised by different second sub-state machines are different. The method is used to solve the problem that the integration of functions realized based on the state machine may cause the crossing and conflict of running control timing.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a message processing method, apparatus and storage medium. Background Technology

[0002] The autonomous driving system of a vehicle involves many autonomous driving assistance functions, such as adaptive cruise control (ACC), lane keeping assistance (LKA), automatic emergency braking (AEB), and automated parking assist (APA), which involve many complex state machine-based algorithms.

[0003] Currently, autonomous driving assistance functions are designed in an integrated manner; for example, ACC and AEB functions are both related to driving and can be integrated into a single design. However, as the functions of autonomous driving systems become more diversified and the integration of autonomous driving assistance functions increases, state machine-based function integration may lead to overlapping and conflicting operational control timings, resulting in functional errors and lower safety. Summary of the Invention

[0004] This application provides a message processing method, apparatus, and storage medium to address the problem that the increasingly high integration of autonomous driving assistance functions, based on state machines, may lead to the overlap and conflict of operation control timing.

[0005] Firstly, this application provides a message processing method. Taking an electronic device with processing capabilities as an example, the method specifically includes: the electronic device acquiring data to be processed, and then running a first state machine based on the data to be processed. The first state machine includes a first sub-state machine and multiple second sub-state machines. The states in the first sub-state machine include states common to multiple application tasks, and each second sub-state machine includes the state of one application task. Different second sub-state machines include different states.

[0006] In this embodiment, the common states of various automated driving assistance functions are handled by a first sub-state machine, while each second sub-state machine handles the independent states of its respective automated driving assistance function. Because the common states are abstracted, different second sub-state machines contain different states; that is, there is no overlap between the states of different second sub-state machines. In other words, the first sub-state machine and each second sub-state machine can ensure that the states of the various automated driving assistance functions do not overlap, thereby minimizing the overlap and conflict of the timing of the automated driving system's operation control and improving the stability of the automated driving system's operation.

[0007] Optionally, before acquiring the data to be processed, the method further includes: the electronic device acquiring all states of each application task in the multiple application tasks. Then, based on all states of each application task, it determines the common states of the multiple application tasks and the states unique to each application task. Afterwards, based on the common states of the multiple application tasks and the states unique to each application task, it determines a first sub-state machine and multiple second sub-state machines.

[0008] Optionally, a first sub-state machine and multiple second sub-state machines are determined based on the common states of multiple application tasks and the states unique to each application task. This includes determining the first sub-state machine and multiple second sub-state machines based on the system configuration file, the common states of multiple application tasks, and the states unique to each application task. The system configuration file is used to indicate the execution order of the states corresponding to each application task.

[0009] Optionally, before running the first state machine, the method further includes: reading the topological ordering of each second sub-state machine from a system configuration file, the topological ordering being used to indicate the execution order of states. Then, updating the topological ordering of at least one second sub-state machine and generating a new system configuration file based on the updated topological ordering.

[0010] The topology order of each second sub-state machine is stored in the system configuration file. When it is necessary to update the topology order of each second sub-state machine, the topology order can be read from the system configuration file and modified. This allows for adaptive adjustment of the execution order of the states of each second sub-state machine according to actual needs, providing a more flexible choice.

[0011] Optionally, a sub-state machine is bound to a thread, and states and coroutines within a sub-state machine are bound together. Running a first state machine includes running a first thread bound to the first sub-state machine and running second threads bound to each of the respective second sub-state machines.

[0012] In this embodiment, a sub-state machine is bound to a thread, and states within a sub-state machine are bound to coroutines. Based on the independence of thread execution, binding a second sub-state machine to a thread enables the independent operation of each second sub-state machine; that is, the state machines for each autonomous driving application scenario operate independently. Since coroutines can run on top of threads, multiple coroutines can run on a single thread through time-division multiplexing. Furthermore, the execution parameters of multiple coroutines running on a single thread can be flexibly configured, such as the number of coroutines and their execution order. Based on these characteristics of coroutines, when binding these states to coroutines, the execution order of the coroutines can be set according to the logical order of state execution. The scheduling of coroutine execution is then determined by the user space to control the entire execution process.

[0013] Secondly, this application provides a message processing apparatus. The apparatus includes an acquisition module and an execution module. The acquisition module acquires data to be processed. The execution module executes a first state machine based on the data to be processed. The first state machine includes a first sub-state machine and multiple second sub-state machines. The states in the first sub-state machine include states common to multiple application tasks, and each second sub-state machine includes the state of one application task. Different second sub-state machines include different states.

[0014] Optionally, the acquisition module is further configured to: acquire all states of each application task in the multiple application tasks. Then, based on all states of each application task, determine the common states of the multiple application tasks and the states unique to each application task. Afterward, based on the common states of the multiple application tasks and the states unique to each application task, determine a first sub-state machine and multiple second sub-state machines.

[0015] Optionally, the acquisition module is specifically used to: determine the first sub-state machine and multiple second sub-state machines based on the system configuration file, the states shared by multiple application tasks, and the states unique to each application task. The system configuration file is used to indicate the execution order of the states corresponding to each application task.

[0016] Optionally, the acquisition module is also used to: read the topological sorting of each second sub-state machine from the system configuration file, the topological sorting being used to indicate the execution order of the states. Then, it updates the topological sorting of at least one second sub-state machine and generates a new system configuration file based on the updated topological sorting.

[0017] Optionally, the running module is specifically used to: run the first thread bound to the first sub-state machine, and run the second thread bound to each of the second sub-state machines.

[0018] Thirdly, embodiments of this application provide an electronic device including a processor and a memory communicatively connected to the processor. The memory stores computer-executable instructions, which are executed by the processor to enable the processor to perform the method described in any one of the first aspects above.

[0019] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, cause the processor to perform the method described in any one of the first aspects.

[0020] Fifthly, embodiments of this application provide a computer program product, which includes a computer program stored in a computer-readable storage medium. A processor can read the computer program from the computer-readable storage medium, and when the processor executes the computer program, it can implement the method described in any one of the first aspects above. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of an autonomous driving scenario provided in an embodiment of this application;

[0022] Figure 2 This application provides a schematic diagram of the structure of the first and second sub-state machines in an embodiment.

[0023] Figure 3 A schematic diagram of the topological ordering of the states included in the second sub-state machine provided in the embodiments of this application;

[0024] Figure 4 This is a schematic diagram of the design flow of the first state machine provided in an embodiment of this application;

[0025] Figure 5 A flowchart illustrating the message processing method provided in an embodiment of this application;

[0026] Figure 6 A schematic diagram illustrating the execution method of a state machine in a conventional autonomous driving system provided in this application embodiment;

[0027] Figure 7 A flowchart illustrating the message processing of the first and second sub-state machines provided in this application embodiment;

[0028] Figure 8 This is a schematic diagram of the structure of the message processing apparatus provided in the embodiments of this application;

[0029] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] The embodiments of this application can be applied to parallel processing of multiple tasks. For example, the embodiments of this application can be applied to... Figure 1 The image shows an autonomous driving scenario. Autonomous driving systems integrate a range of assistance functions, including adaptive cruise control, lane keeping assist, automatic lane changing, and automatic parking, to meet increasingly diverse driving needs. Typically, the various assistance functions of an autonomous driving system are implemented based on a state machine mechanism.

[0031] A state machine is an abstraction of the operating rules of a real-world system; it's a mathematical model used for algorithm design. A state machine receives a series of inputs, processes them internally, causes its system state to transition, and generates a specific output. A state machine system can be described by a directed graph, where the vertices of the directed graph represent the states of the system, and the edges represent the inputs and outputs required for the system to transition from one state to another.

[0032] A state machine consists of multiple states, or it can be understood as a set of states. A "state" is a position in the state machine system where the system is stable and awaiting input for a state transition. State transitions occur when the state the system is waiting for is satisfied or the awaited event has occurred, triggering a series of actions.

[0033] Of these, only one is the starting state of the state machine system, also referred to as the initial state. The state machine system also includes transition functions for state switching. When the system starts, it is in the initial state. When the system receives new input, it switches from the current state to the next state based on the transition functions.

[0034] For example, a state machine for lane keeping assist (LKA) might include: on, off, standby, ids-on, operation, ready, run, and off states. The on state indicates the vehicle is in LKA mode. The off state indicates the vehicle is in LKA mode. The safe state indicates the vehicle is in a fault-free state. The standby state indicates the vehicle is in a fault-free state, but the LKA-related sensors are malfunctioning. The ids-on state indicates the vehicle is in a fault-free state, and the LKA-related sensors are functioning correctly. The suspend state indicates the vehicle is in a fault-free state, and the LKA-related sensors are functioning correctly, but the LKA switch is not turned on or the LKA-related sensor data does not meet the control conditions. The operation state indicates the vehicle is in a fault-free state, and the LKA-related sensors are functioning correctly, and the sensor data meets the control conditions. The ready state indicates the vehicle is in a fault-free state, and the LKA-related sensors are functioning correctly, the sensor data meets the control conditions, the LKA switch is on, but the driver's hands are not on the steering wheel. In the "run" state, the vehicle is in a fault-free condition, the sensors associated with LKA are functioning normally, the sensor data meets the control conditions, the LKA switch is turned on, the driver holds the steering wheel, and LKA is controlling the vehicle.

[0035] The state machine for implementing lane keeping assist (LKA) is initially in the off state. When the autonomous driving system receives a command to activate LKA, it switches the state machine to the on state. Subsequently, if the vehicle sensors detect that the vehicle is in a fault-free state, the LKA-related sensors are functioning correctly, and the sensor data meets the control conditions (but the driver's hands are not on the steering wheel), the system switches to the ready state. If the vehicle sensors subsequently detect that the driver's hands are on the steering wheel, the system switches to the run state, indicating that LKA is operating normally. The run state is governed by a built-in algorithm that ensures the stable operation of the lane keeping assist function.

[0036] For example, a state machine for adaptive cruise control (ACC) might include the following states: off, on, cc_normal, acc_normal, and hold. The off state indicates that the vehicle's ACC is off. The on state indicates that the vehicle's ACC is on. The cc_normal state indicates that the vehicle's ACC is on, and a valid cruise speed signal and following distance are acquired, but the PVDS does not output the longitudinal distance to the target vehicle. The acc_normal state indicates that the vehicle's ACC is on, and the PVDS outputs the longitudinal distance to the target vehicle. The hold state indicates that both the vehicle and the target vehicle are braking. Adaptive cruise control is implemented using a state machine, similar to how LKA (Lane Keeping Assist) is implemented using a state machine; details will not be elaborated here.

[0037] Typically, the integrated design of autonomous driving assistance functions involves combining multiple state machines. When the state machine is a finite state machine, it contains many states or has complex logic, and there may be overlaps between different state machines. Taking the integrated design of LKA and ACC state machines as an example, the LKA function's state machine includes on and off states, and the ACC function's state machine also includes on and off states. On and off states exist in both the LKA and ACC state machines, meaning that different state machines have one or more overlapping states. As the number of autonomous driving assistance functions increases, the complexity of the state machines in the autonomous driving system gradually increases, and the number of overlapping states in the autonomous driving system also increases. This may lead to overlaps and conflicts in the timing of the autonomous driving system's operation and control, causing functional errors and lower safety.

[0038] This application's embodiments take into account that different autonomous driving assistance functions are applicable to different scenarios, corresponding to the handling of one or more different tasks, and the states involved may be the same or different. For example, the LKA function is applicable to application scenarios where there are multiple lanes and the vehicle automatically changes lanes, corresponding to the task of handling automatic lane changing. Another example is the ACC function, applicable to application scenarios where the vehicle is driving in the current lane and performs adaptive cruise control, corresponding to the task of handling adaptive cruise control. Yet another example is the APA function, applicable to application scenarios where the vehicle is parking, corresponding to the task of handling automatic parking. Different autonomous driving assistance functions may have the same tasks to handle; for example, ACC and LKA functions are typically used in scenarios where the vehicle is moving, requiring the handling of vehicle movement tasks. Different autonomous driving assistance functions may also have different tasks to handle. For example, ACC is typically used in scenarios where the vehicle is moving, while APA is typically used in scenarios where the vehicle is relatively stationary; the tasks they handle may differ, and the states involved may also differ. Some autonomous driving assistance functions have similar tasks, but the states involved may differ slightly. For example, both ACC and LKA functions are applicable to scenarios involving vehicle movement. However, ACC primarily controls vehicle speed and needs to consider whether there are obstacles or target vehicles in front of or behind the vehicle, switching states based on the judgment result. LKA, on the other hand, primarily controls the vehicle's trajectory. Therefore, it can be considered that ACC and LKA involve different tasks. Of course, other autonomous driving assistance functions can be distinguished in the same way, which will not be elaborated upon here.

[0039] Due to the integrated design of various autonomous driving assistance functions, the state machines of each autonomous driving assistance function may have overlapping states. This may lead to overlap and conflict in the timing of the autonomous driving system's operation control when different autonomous driving assistance functions may have similar tasks to handle.

[0040] To address this, this application provides a message processing method. In the embodiments of this application, the state machines of each driving assistance function are decoupled, and there is no overlap between different state machines. That is, the state machines of each driving assistance function operate independently, thereby minimizing the overlap and conflict of the operation control timing of the autonomous driving system and improving the stability of the autonomous driving system.

[0041] For example, considering that there are common states in the state machines corresponding to various autonomous driving assistance functions, this embodiment can extract these common states from the state machines corresponding to each autonomous driving assistance function and form a separate state machine. After extracting the common states, the states corresponding to each autonomous driving assistance function form an independently operating state machine. For example, the common states under multiple autonomous driving assistance functions include on state, off state, idle state, and running state. The on state, off state, idle state, and running state can be extracted from the state machines corresponding to each autonomous driving assistance function and formed a separate state machine. After extracting the on state, off state, idle state, and running state, each autonomous driving assistance function forms an independently operating state machine. For ease of description, the state machine composed of common states is called the first sub-state machine. The state machine composed of the states corresponding to one autonomous driving assistance function after extracting the common states is called the second sub-state machine. It can be understood that, as Figure 2 As shown, multiple autonomous driving assistance functions correspond to one first sub-state machine and multiple second sub-state machines (second sub-state machine 1, second sub-state machine 2, ..., second sub-state machine N). Figure 2 The top-level state machine is the first sub-state machine, denoted by TSM. The second-level state machine is the second sub-state machine, denoted by SSM.

[0042] In this way, the common states of all automated driving assistance functions are handled by the first sub-state machine, while each second sub-state machine handles the independent states of its respective automated driving assistance function. It is understandable that, because the common states are removed, the states included in different second sub-state machines are different; that is, there is no overlap in states between different second sub-state machines. In other words, the first sub-state machine and each second sub-state machine can ensure that the states of the various automated driving assistance functions do not overlap, thereby minimizing the overlap and conflict of the timing of the automated driving system's operation control and improving the stability of the automated driving system's operation.

[0043] Multiple autonomous driving assistance functions can be integrated together, and a state machine can be designed, which consists of a first sub-state machine and multiple second sub-state machines. For ease of description, this state machine will be referred to as the first state machine.

[0044] For any autonomous driving assistance function, multiple sub-functions are involved. Taking adaptive cruise control as an example, it involves acquiring cruise speed signals and following distance, among other things. The implementation of these multiple sub-functions is related to their execution order. Therefore, the design of any second sub-state machine is related to the execution order of the multiple sub-functions involved in the autonomous driving function associated with that second sub-state machine.

[0045] In this embodiment, after determining the states included in a second sub-state machine, each second sub-state machine is determined according to the execution order of the states included in the second sub-state machine. For example, a topological sort (topology structure) of the second sub-state machines is generated according to the execution order of the states included in the second sub-state machines, and a system configuration file is generated and saved according to the topological sort. For example, please refer to... Figure 3 This illustrates a topological ordering of the states included in the second sub-state machine 1. For example... Figure 3 As shown, states 1 through 9 belong to a second sub-state machine 1. The execution order of the states in the second sub-state machine 1 can be either state 1 → state 5 → state 8 → state 9, or state 1 → state 3 → state 6 → state 8 → state 9.

[0046] Depending on the requirements of autonomous driving functions, the states included in any second sub-state machine and their corresponding execution order can be adjusted. For example, depending on the requirements, second sub-state machine 1 includes states 1, 3, 6, 8, and 9, with the execution order being state 1 -> state 3 -> state 6 -> state 8 -> state 9. Alternatively, second sub-state machine 1 may include states 1, 4, 7, 8, and 9, with the execution order being state 1 -> state 4 -> state 7 -> state 8 -> state 9. Specifically, the topological order of the states included in the second sub-state machine can be achieved by updating (modifying) the system configuration file. For example, when it is necessary to adjust the execution order of the states included in the second sub-state machine, the configuration information of each second sub-state machine, i.e., the execution order of the states included in the second sub-state machine, can be read from the system configuration file. Then, the topological order of each second sub-state machine can be adjusted according to actual needs, and the adjusted topological order can be saved to the system configuration file.

[0047] Please see Figure 4This document illustrates the design flow of the first state machine provided in this embodiment. First, all states of multiple automated driving assistance functions (AWDFCs) are acquired. Common states shared by the multiple AWDFCs are extracted from all states, and the rationality of each common state is verified to determine if the extraction is reasonable. Specifically, determining the rationality of the extracted common states can be achieved by verifying the completeness of the state machine logic of the multiple AWDFCs after extraction. If the extraction is reasonable, extracting the common states will not affect the normal operation of the original AWDFCs and will make the operation of each AWDFC more independent. Then, the states included in each second sub-state machine are determined based on all states of the multiple AWDFCs and the common states of the multiple AWDFCs. Similarly, the rationality of the states included in each second sub-state machine also needs to be verified. When designing each second sub-state machine, the execution order of the states included in the second sub-state machine is determined according to topological sorting, and each second sub-state machine is designed as a directed acyclic execution order. Based on the directed acyclic design concept, the flow of states in each designed second sub-state machine is directional and will not form a circular deadlock; that is, for the internal operating states of each second sub-state machine and the scheduling of each state, a closed loop state with connected beginning and end states will not be formed. Therefore, no deadlock will occur during the internal operation of each second sub-state machine or during the user's logic scheduling. The timing is reliable and can support high-concurrency execution.

[0048] The first state machine designed based on the embodiments of this application can realize the integrated design of multiple autonomous driving assistance functions. Running the first state machine can realize the corresponding autonomous driving assistance function. When there is a message / information / data that needs to be processed, the first state machine can be started.

[0049] For example, see Figure 5 This diagram illustrates a flowchart of a message processing method provided in an embodiment of this application. This method can be executed by an electronic device with processing capabilities, such as a system-on-chip (SoC) in an autonomous driving system. Of course, the type of electronic device in this embodiment is not limited to an SoC in an autonomous driving system; it can also be other electronic devices within the autonomous driving system. In the following description, the execution of this method by an electronic device is used as an example.

[0050] S501, The electronic device acquires the data to be processed.

[0051] The data to be processed can be data representing vehicle state information. From the perspective of automated driving assistance functions, the data to be processed can represent the state information corresponding to one or more automated driving assistance functions, which can indicate the vehicle's state in that scenario. For example, if the data to be processed can represent that the vehicle is in a fault-free state, then it corresponds to the safe state in the LKA function.

[0052] The data to be processed can be acquired through vehicle body sensors and sent to electronic devices via a data bus. In addition, the data to be processed can also be sent to electronic devices through other means besides the data bus, which will not be elaborated here. Since the data to be processed includes state information from multiple application scenarios, i.e., state information from multiple autonomous driving assistance functions, the electronic device, upon receiving the data, needs to run multiple state machines and perform state switching tasks based on the data.

[0053] S502. The electronic device runs a first state machine based on the data to be processed. The first state machine includes a first sub-state machine and multiple second sub-state machines. Each second sub-state machine is used to handle the state transition of an application scenario. Different second sub-state machines include different states. The states in the first sub-state machine include states common to multiple application scenarios.

[0054] When an electronic device acquires data to be processed, it can process the data by running the first state machine designed as described above. Since the first state machine includes multiple second sub-state machines, when the electronic device processes the data, it can run different second sub-state machines according to the different driving assistance functions corresponding to the data. This avoids state overlap between state machines of different driving assistance functions and ensures the stability of autonomous driving operation.

[0055] In one possible implementation, the autonomous driving system uses a high-cycle polling method with a single time slice to run each state machine. For example, see [link to relevant documentation]. Figure 6 This illustrates how the state machine in a traditional autonomous driving system is executed. Figure 6 Taking an autonomous driving system as an example, it includes an APA state machine adapted to the APA function, an AEB state machine adapted to the AEB function, and other state machines. Figure 6 Taking time slices T0-T6 as an example, the autonomous driving system follows a polling sequence from T0 to T6. In each polling time slice, the system detects an input event, starting with the APA state machine and polling sequentially through the AEB state machine and other state machines to determine which state machine was triggered by the input event. Since the autonomous driving system needs to poll each state machine, each state machine needs to operate normally. This means that even idle state machines consume system resources, affecting data processing efficiency. Furthermore, idle state machines also consume system resources for computation, resulting in significant data processing latency and impacting the execution efficiency of the autonomous driving system.

[0056] Therefore, in this embodiment, the execution efficiency of the state machine can be improved by introducing threads and coroutines. Since threads are contained within processes and are the smallest unit of computation scheduling by the operating system, a process can include multiple threads. A thread can be understood as a single sequential control flow within a process, and the creation and destruction of threads are implemented by the operating system allocating system resources. Coroutines, on the other hand, run on top of threads, and multiple coroutines can run on a single thread through time-division multiplexing. Increasing the number of coroutines does not affect the execution time of threads, and switching between multiple coroutines does not require the system to allocate system resources for coroutine creation and destruction, thus avoiding additional system resource overhead. Furthermore, by flexibly setting the execution parameters of multiple coroutines running on a single thread, such as the number of coroutines, their execution order, and execution time, the actual requirements of the task can be met. Therefore, based on the characteristics of threads and coroutines, the state machine can be bound to threads or coroutines to improve its execution efficiency.

[0057] To improve the efficiency of the first state machine, the first sub-state machine and multiple second sub-state machines within it can be bound to threads. Based on the independence of thread execution, binding multiple second sub-state machines to threads allows for the independent operation of each second sub-state machine, meaning that the state machines for different autonomous driving application scenarios can operate independently. Furthermore, the states within each second sub-state machine can be bound to coroutines. Since coroutines can run on top of threads, multiple coroutines can run on a single thread through time-division multiplexing. The execution parameters of multiple coroutines running on a single thread can also be flexibly configured, such as the number of coroutines and their execution order. Based on these characteristics of coroutines, the execution order of coroutines can be set according to the logical order of state execution when binding these states to them. Therefore, when the electronic device is running the first state machine, it can switch states by running the coroutines corresponding to the first state machine. The state transition is then performed by combining functional logic with the specific execution results and associated events of each thread bound to the second sub-state machine (SSM). The scheduling of coroutine execution within a thread is controlled by the user-space mechanism based on the processing results.

[0058] When a thread is waiting for I / O, the operating system blocks the current thread and switches to another thread. However, this thread switching involves system calls, and frequent thread switching consumes a significant amount of CPU time. In contrast, switching between coroutine subroutines within a thread is controlled by the program itself and involves only user-mode function calls, not system calls. Increasing the number of coroutines does not affect the thread's execution time. Switching between multiple coroutines does not require the system to allocate system resources for coroutine creation and destruction, thus avoiding additional system resource overhead. Therefore, by running the first thread bound to the first sub-state machine and multiple second threads bound to multiple second sub-state machines, there is no thread switching overhead. This method reduces resource consumption during system execution. Furthermore, when the ECU's CPU is multi-core, different states of multiple second sub-state machines (SSMs) can run simultaneously on different CPU cores, improving execution efficiency and reducing processing time, thereby enhancing the overall efficiency of the autonomous driving system.

[0059] Please see Figure 7 This diagram illustrates the message processing flow of the first and second sub-state machines. After being bound to threads, the first and second sub-state machines can process the data to be processed. This data includes state information from multiple autonomous driving assistance functions (ADAS), acquired through vehicle sensors and sent to the electronic device via a data bus. The electronic device buffers the data and processes the common states among the various AAS using the first sub-state machine. The states specific to each AAS after processing by the first sub-state machine are then handled by the second sub-state machine. Finally, the processing result from the second sub-state machine drives the corresponding algorithm for each AAS, generating vehicle control commands to control the vehicle.

[0060] In this embodiment, the common states of various automated driving assistance functions are handled by a first sub-state machine, while each second sub-state machine handles the independent states of its respective automated driving assistance function. Because the common states are abstracted, different second sub-state machines contain different states; that is, there is no overlap between the states of different second sub-state machines. In other words, the first sub-state machine and each second sub-state machine can ensure that the states of the various automated driving assistance functions do not overlap, thereby minimizing the overlap and conflict of the timing of the automated driving system's operation control and improving the stability of the automated driving system's operation.

[0061] Please see Figure 8Based on the same inventive concept, this application also provides a message processing device 800. The device includes an acquisition module 801 and an operation module 802. The acquisition module 801 is used to acquire data to be processed. The operation module 802 is used to run a first state machine based on the data to be processed. The first state machine includes a first sub-state machine and multiple second sub-state machines. The states in the first sub-state machine include states common to multiple application tasks, and each second sub-state machine includes the state of one application task. Different second sub-state machines include different states.

[0062] Optionally, the acquisition module 801 is further configured to: acquire all states of each application task in the multiple application tasks respectively; then, determine the common states of the multiple application tasks and the states unique to each application task based on all states of each application task; subsequently, determine a first sub-state machine and multiple second sub-state machines based on the common states of the multiple application tasks and the states unique to each application task.

[0063] Optionally, the acquisition module 801 is specifically used to: determine a first sub-state machine and multiple second sub-state machines based on the system configuration file, the states shared by multiple application tasks, and the states unique to each application task. The system configuration file is used to indicate the execution order of the states corresponding to each application task.

[0064] Optionally, the acquisition module 801 is further configured to: read the topological order of each second sub-state machine from the system configuration file, the topological order being used to indicate the execution order of the states. Then, update the topological order of at least one second sub-state machine and generate a new system configuration file based on the updated topological order.

[0065] Optionally, the running module 802 is specifically used to: run a first thread bound to the first sub-state machine, and run a second thread bound to each of the second sub-state machines.

[0066] Based on the same inventive concept, embodiments of this application provide an electronic device including at least one processor 901 and a memory 902 communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor to enable the at least one processor to perform the methods described in any of the above embodiments.

[0067] In this embodiment, the specific connection medium between the processor 901 and the memory 902 is not limited. Figure 9 Taking the connection between processor 901 and memory 902 via bus 900 as an example, bus 900 in... Figure 9The connections between other components are indicated by thick lines and are for illustrative purposes only, not as limiting information. The Bus 900 can be divided into address bus, data bus, control bus, etc., for ease of representation. Figure 9 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0068] The computing device in this application embodiment may also include a communication interface 903, such as a network port, through which the computing device can receive or send data.

[0069] The processor 901 serves as the control center of the computing device. It connects to various parts of the device via various interfaces and lines, executing instructions stored in the memory 902 and accessing data stored in the memory 902 to perform various functions and process data, thereby providing overall monitoring of the computing device. Optionally, the processor 901 may include one or more processing units. The processor 901 may integrate an application processor and a modem processor. The application processor primarily handles the operating system and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may not be integrated into the processor 901. In some embodiments, the processor 901 and the memory 902 may be implemented on the same chip; in other embodiments, they may be implemented on separate chips.

[0070] Optionally, the processor 901 may be a general-purpose processor, such as a central processing unit, an application-specific integrated circuit (ASIC), one or more integrated circuits for controlling program execution, a hardware circuit developed using a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the message processing method disclosed in the embodiments of this application can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0071] By designing and programming the processor 901, the code corresponding to the message processing method described in the foregoing embodiments can be embedded into the chip, so that the chip can execute the steps of the aforementioned message processing method when running. How to design and program the processor 901 is a well-known technique to those skilled in the art, and will not be described in detail here.

[0072] Optionally, in this embodiment, the memory 902 stores instructions executable by at least one processor 901. The at least one processor 901 can execute the steps included in the aforementioned message processing method by executing the instructions stored in the memory 902. The memory 902, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. The memory 902 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic memory, magnetic disk, optical disk, etc. The memory 902 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. The memory 902 in this embodiment can also be a circuit or any other device capable of performing storage functions, used to store program instructions and / or data. The number of memories 902 can be one or more. The memory 902 is used in... Figure 9 It is shown together, but it should be noted that the memory 902 is not a mandatory functional module, therefore in Figure 9 It is shown in dashed lines.

[0073] Based on the same inventive concept, embodiments of this application provide a computer storage medium storing computer program instructions for executing the methods in any of the above embodiments. In specific implementations, the computer-readable storage medium includes various storage media capable of storing program code, such as a Universal Serial Bus flash drive (USB), a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0074] In some possible implementations, various aspects of the message processing method provided in this application may also be implemented as a program product comprising program code that, when the program product is run on a computing device, causes the computing device to perform the steps of the message processing method according to the various exemplary embodiments of this application described above.

[0075] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0076] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0077] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0078] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0079] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes: Universal Serial Bus flash disks, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0080] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A message processing method, characterized in that, include: Obtain the data to be processed; The data to be processed includes status information of multiple autonomous driving assistance functions; Based on the data to be processed, a first state machine is run. The first state machine includes a first sub-state machine and multiple second sub-state machines running in parallel. The states in the first sub-state machine include states common to multiple application tasks. The states in a second sub-state machine include all states of an application task after removing the common states. Different second sub-state machines include different states. The states included in the second sub-state machines flow in a directed acyclic execution order. A sub-state machine is bound to a thread, and a state within the sub-state machine is bound to a coroutine. Running the first state machine includes: The first thread, which is bound to the first sub-state machine, processes the common states among the state information of the multiple autonomous driving assistance functions, and hands over the states held by the multiple autonomous driving assistance functions in the data to be processed after the first sub-state machine is processed by the second thread, which is bound to the corresponding second sub-state machine. Based on the processing result of the second thread, the corresponding autonomous driving assistance function is driven to generate corresponding vehicle control commands to control the vehicle.

2. The method as described in claim 1, characterized in that, Before acquiring the data to be processed, the method further includes: Obtain all states of each application task in the plurality of application tasks; Based on all the states of each application task, determine the common state of the multiple application tasks and the state that each application task has independently. The first sub-state machine and the multiple second sub-state machines are determined based on the common states of the multiple application tasks and the tasks that each application task has independently.

3. The method as described in claim 2, characterized in that, The first sub-state machine and the multiple second sub-state machines are determined based on the common states of the multiple application tasks and the states unique to each application task, including: The first sub-state machine and the multiple second sub-state machines are determined based on the system configuration file, the common states of the multiple application tasks, and the states that each application task has independently; wherein, the system configuration file is used to indicate the execution order of the states corresponding to each application task.

4. The method as described in claim 3, characterized in that, Before running the first state machine, the method further includes: Read the topological sorting of each of the second sub-state machines from the system configuration file, the topological sorting being used to indicate the execution order of the states; Update the topology order of at least one of the second sub-state machines, and generate a new system configuration file based on the updated topology order.

5. A message processing device, characterized in that, include: The acquisition module is used to acquire the data to be processed. The data to be processed includes status information of multiple autonomous driving assistance functions; The execution module is used to run a first state machine based on the data to be processed. The first state machine includes a first sub-state machine and multiple second sub-state machines running in parallel. The states in the first sub-state machine include states common to multiple application tasks. The states in a second sub-state machine include all states of an application task after removing the common states. Different second sub-state machines include different states. The states contained in the second sub-state machines flow in a directed acyclic execution order. A sub-state machine is bound to a thread, and the states in a sub-state machine are bound to a coroutine. Running the first state machine includes: running a first thread bound to the first sub-state machine to process the common states in the state information of the multiple autonomous driving assistance functions, and handing over the states held by each of the multiple autonomous driving assistance functions in the data to be processed after the first sub-state machine has been processed to a second thread bound to the corresponding second sub-state machine for processing. Based on the processing result of the second thread, the corresponding autonomous driving assistance function is driven to generate corresponding vehicle control commands to control the vehicle.

6. The apparatus as claimed in claim 5, characterized in that, The acquisition module is also used for: Obtain all states of each application task in the plurality of application tasks; Based on all the states of each application task, determine the common state of the multiple application tasks and the state that each application task has independently. The first sub-state machine and the multiple second sub-state machines are determined based on the common states of the multiple application tasks and the tasks that each application task has independently.

7. The apparatus as claimed in claim 6, characterized in that, The acquisition module is specifically used for: The first sub-state machine and the multiple second sub-state machines are determined based on the system configuration file, the common states of the multiple application tasks, and the states that each application task has independently; wherein, the system configuration file is used to indicate the execution order of the states corresponding to each application task.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-4.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-4.

Images