WO2023093257A1

WO2023093257A1 - Modeling method for self-driving service and related device

Info

Publication number: WO2023093257A1
Application number: PCT/CN2022/120747
Authority: WO
Inventors: 管高扬; 陈瑞宁; 连学国; 王强东; 谭中平
Original assignee: 华为技术有限公司
Priority date: 2021-11-26
Filing date: 2022-09-23
Publication date: 2023-06-01
Also published as: CN116186955A

Abstract

Embodiments of the present application provide a modeling method for a self-driving service and a related device. The method comprises: obtaining a fusion log of a service node of a self-driving service; obtaining information of N behaviors of the service node according to the fusion log, N being a positive integer greater than or equal to one; and analyzing the information of the N behaviors of the service node, and obtaining a motion behavior model used for describing a motion behavior of the service node. The method can model for a motion behavior of a service node of a self-driving service without a self-driving service source code, so as to obtain a motion behavior model used for describing the motion behavior of the service node.

Description

A modeling method and related equipment for autonomous driving business

This application claims the priority of the Chinese patent application with the application number 202111424208.2 and the application title "A modeling method and related equipment for autonomous driving business" filed with the China Patent Office on November 26, 2021, the entire contents of which are incorporated by reference incorporated in this application.

technical field

The present application relates to the field of automatic driving, and more specifically, relates to a modeling method, computer device, computer equipment, chip system and computer-readable storage medium of an automatic driving business.

Background technique

Autonomous driving technology is the top priority of traditional human-controlled cars turning to smart cars controlled by electronic information systems. At present, self-driving cars are generally developed first, and then through the closed-loop feedback process of modeling, simulation, optimization, and then adjusting the code on the prototype vehicle, the cycle repeats and gradually achieves the requirements of high performance and low latency. This method generally adopts some self-defined domain-specific language to build a business model, which is used to describe the behavior of the business on computing resources such as a central processing unit (CPU) and a graphics processing unit (GPU). model. The fineness of the model determines the upper limit of simulation, simulation, and optimization capabilities. However, the autonomous driving business is numerous and complex, and it is time-consuming and labor-intensive to manually model each business node, and it is usually necessary to combine multiple business departments to sort out the overall context. In addition, at present, the source code of most autonomous driving services is not open to the public, so it is difficult to abstract the model of the service node from the service source code.

How to build a model for the operation behavior of the business nodes of the autonomous driving business without the source code of the autonomous driving business has become an urgent problem to be solved.

Contents of the invention

An embodiment of the present application provides a modeling method for an automatic driving service, a computer device, a computer device, a chip system, and a computer-readable storage medium, which can be used as a service node for the automatic driving service without the source code of the automatic driving service. Run behavioral modeling.

In the first aspect, a modeling method for an automatic driving service is provided, the method comprising: obtaining a fusion log of a service node of the automatic driving service; obtaining information on N behaviors of the service node according to the fusion log, where N is greater than or equal to 1 is a positive integer; analyze the information of N behaviors of the service node, and obtain an operation behavior model used to describe the operation behavior of the service node.

It should be understood that the fusion log is used to record the call event of the service node and the scheduling information of the thread, and the thread is run by the service node.

It should also be understood that the information of each behavior of the business node includes: the number of threads contained in each behavior, the running time of each behavior, the average value of the running time of each behavior and the probability of running time, the Execution time, average and probability of execution time for each behavior, execution time for each thread in each behavior, execution time, average and average execution time, names of events in each behavior, The average of the time points of events in a behavior or the probability distribution model of the time points of events. Events in each behavior include receive events in each behavior, send events in each behavior, callback start events in each behavior, and callback end events in each behavior. The time point of the event in each behavior includes an absolute time point of the event or a relative time point of the event.

It should also be understood that the running behavior model of the nth behavior among the N behaviors of the service node may include any of the following: the message channel for receiving events corresponding to each behavior that triggers the nth behavior, the nth behavior At least one time-triggered period, or a time-probability model for the nth behavior. If the running behavior model of the nth behavior includes a message channel for receiving events corresponding to each behavior that triggers the nth behavior, then the running behavior model of the nth behavior may also include a trigger relationship of the nth behavior. Wherein, n=1,...,N.

It should also be understood that the running behavior model of the nth behavior may further include any one or more of the following: the running time of at least one thread included in the nth behavior, the running time of at least one thread included in the nth behavior Period, the trigger relationship of at least one thread included in the nth behavior, or the dependency relationship of the business node.

In the embodiment of the present application, without the source code of the automatic driving service, the operating behavior of the service node of the automatic driving service can be modeled, and the operating behavior model used to describe the operating behavior of the service node can be obtained. The operating behavior model can be Provide reverse development guidance for designers and developers, and also calculate the running behavior status of the business nodes of the autonomous driving business on the hardware resources through simulation and other methods, and check whether the running behavior status of the business nodes on the hardware resources conforms to the design expected. Therefore, the operating behavior model of the embodiment of the present application has important value for feedback guidance and auxiliary design. At the same time, the operating behavior model of the embodiment of the present application can be used as the input for the simulation, simulation and optimization of the subsequent automatic driving business code, and can be used as the input for the subsequent automatic driving business code. Simulation, emulation and optimization provide high precision guarantee.

In combination with the first aspect, in some implementations of the first aspect, the node-level communication log and the thread-level scheduling log of the service node are obtained; the node-level communication log and the thread-level scheduling log are fused to obtain the fused log.

It should be understood that the node-level communication log is used to record the calling event of the service node, and the thread-level scheduling log is used to record the scheduling information of the thread. Each fusion log entry in the fusion log corresponds to a communication log entry in the node-level communication log or a scheduling log entry in the thread-level scheduling log, and each fusion log entry in at least two fusion log entries is used to record the corresponding The content of the log entry.

It should also be understood that the time information in the node-level communication log and the time information in the thread-level scheduling log can be synchronized according to the time synchronization data in the node-level communication log and the time synchronization data in the thread-level scheduling log; the time information The synchronized node-level communication log and thread-level scheduling log are fused to obtain the fused log. It should be understood that the time synchronization data in the node-level communication log is added during the process of obtaining the node-level communication log, and the time synchronization data in the thread-level scheduling log is added during the process of obtaining the thread-level scheduling log. It should also be understood that time synchronization data may be added once during the process of obtaining node-level communication logs and thread-level scheduling logs, or periodic time synchronization data may be added during the process of obtaining node-level communication logs and thread-level scheduling logs. Thus, the time information with inconsistent form in the node-level communication log and thread-level scheduling log is converted into time information with consistent form, so as to facilitate the acquisition of fusion logs with consistent time information.

In the embodiment of this application, the log entries in the node-level communication log and the thread-level scheduling log can be fused, so as to obtain a fused log that simultaneously records the call event of the service node and the scheduling information of the thread, which is convenient for subsequent recording in the fused log. The operation behavior model describing the operation behavior of the service node is obtained by merging the log entries.

In combination with the first aspect, in some implementations of the first aspect, the associated service nodes and dependencies of the service nodes are determined according to the communication data of the service nodes; the scheduling strategy of the service nodes and the associated service nodes is adjusted to obtain the adjusted scheduling Strategy: Run the autonomous driving business according to the adjusted scheduling strategy, collect communication data and scheduling data of business nodes, and obtain node-level communication logs and thread-level scheduling logs.

It should be understood that the associated service nodes of the service node include at least one of the ancestor nodes of the service node or the descendant nodes of the service node. The ancestor node of the service node is one or Multiple, the descendants of the service node are the fourth service node receiving the message sent by the service node, the fifth service node receiving the message sent by the fourth service node, the sixth service node receiving the message sent by the fifth service node, etc. one or more of the . It should also be understood that the dependency relationship of a service node is the relationship between the service node and service nodes that have receiving and sending relationships with the service node.

It should also be understood that adjusting the scheduling strategy of the service node and the associated service node includes: adjusting any one or more of the priority of the service node and the associated service node, the binding strategy, the cycle frequency, the length of the reserved time slice, or the length of the deadline indivual.

In the embodiment of this application, the associated service nodes and dependencies of the service nodes can be determined according to the communication data of the service nodes, and the service nodes and the associated service nodes of the service nodes can be determined by adjusting the scheduling strategy of the service nodes and the associated service nodes of the service nodes Priority execution sequence, so as to avoid resource competition, reduce mutual interference caused by the operation of multiple business nodes, obtain low-noise or no-noise node-level communication logs and thread-level scheduling logs, and facilitate subsequent and accurate establishment of business node operation behavior Model.

With reference to the first aspect, in some implementation manners of the first aspect, at least one time segment is determined according to the fusion log entries in the fusion log; according to the at least one time segment, N sets of fusion log entry sets are determined; respectively, according to the N The group fusion log entry set determines the N behavior information of the service node.

It should be understood that each time segment in the at least one time segment corresponds to at least two first fusion log entries and at least one second fusion log entry. The first fusion log entry is the fusion log entry corresponding to the scheduling information in the fusion log, and the second fusion log entry is the fusion log entry corresponding to the call event in the fusion log. The time information of the fusion log entry corresponding to each time segment is within each time segment. Each fusion log entry set in the N sets of fusion log entry sets includes at least one fusion log entry set, and each fusion log entry set in the at least one fusion log entry set includes at least one first fusion log entry and at least one second fusion log entry log entry. The time information of the second fusion log entry included in each fusion log entry set is within the range of the time information of the first fusion log entry included in each fusion log entry set.

It should also be understood that at least one time segment can be determined according to the time information of the fusion log entry in the fusion log; at least one time segment is aggregated to obtain at least one cluster; according to the time segment included in each cluster in the at least one cluster, determine At least one set of fused log entries; according to the at least one set of fused log entries, determine N sets of fused log entries; and determine N behavior information of service nodes according to the N sets of fused log entries.

It should also be understood that each time segment in the at least one time segment includes time information of one or more first fusion log entries in the at least two first fusion log entries, and the first fusion log entry corresponds to the schedule in the fusion log. Fusion log entries for information. Each of the at least one cluster includes one or more of the at least one time slice. At least one fusion log entry set corresponds to at least one cluster, and each fusion log entry set in the at least one fusion log entry set includes at least two first fusion log entries and at least one second fusion log entry. The time information of the first fused log entry included in each fused log entry set is located within the time segment included in the corresponding cluster. The time information of the second fusion log entry included in each fusion log entry set is within the range of the time information of the first fusion log entry included in each fusion log entry set. Each group of fusion log entry sets in the N sets of fusion log entry sets includes one or more fusion log entry sets. The nth behavior among the N behaviors of the business node corresponds to the nth group of fusion log entry sets in the N groups, that is, the nth behavior can correspond to one fusion log entry set, or it can correspond to multiple fusion log entry sets.

In the embodiment of the present application, by analyzing and processing the fusion log entries corresponding to the thread information and the fusion log entries corresponding to the invocation events in the fusion log, the information of the behavior of the service node and the running of the thread contained in the behavior of the business node can be obtained. Information such as time is convenient for subsequent further processing of the information of the service node and the information of the thread contained in the service node, so as to support the establishment of an accurate operation behavior model for the operation behavior of the service node.

With reference to the first aspect, in some implementation manners of the first aspect, according to the time information and identity information of the first fusion log entry included in the fusion log and the time information and identity information of the second fusion log entry included in the fusion log entry, At least one time slice is determined.

It should be understood that the identity information of at least two first fusion log entries corresponding to each time segment is the same, and the time of the two first fusion log entries adjacent in time among the at least two first fusion log entries corresponding to each time segment The interval is smaller than the segmentation threshold, and the process number of at least one second fusion log entry corresponding to each time segment is the same as the process number of at least two first fusion log entries corresponding to each time segment.

It should also be understood that at least one reference time segment may be determined according to the identity information of the at least two first fusion log entries, the time information of the at least two first fusion log entries, and the initial segmentation threshold; according to the constraints and at least one reference Time segment, determine the segmentation parameters of each reference time segment; optimize the initial segmentation threshold according to the optimization method, and obtain the segmentation threshold.

It should also be understood that the constraint condition is that the time information of one or more second fusion log entries in at least one second fusion log entry is within the time range of the reference time segment, and the identity of the one or more second fusion log entries The process number in the information is the same as the process number of the identity information of each first fusion log entry included in the reference time segment. Each second fusion log entry may record one or more of a receive event, a send event, a callback start event, or a callback end event. When a callback start event is recorded in the multiple second fusion log entries, a callback end event is also recorded in the multiple second fusion log entries. The segmentation parameter can be the execution time of at least one time segment of each thread divided by the average value of the running time, or it can be the average value of values obtained from other functional relationships between the execution time and the running time, which is not done in the embodiment of the present application Specific limits. The optimization method may include a heuristic optimization algorithm or a solver optimization method, which is not specifically limited in this embodiment of the present application. The obtained segmentation threshold is the initial segmentation threshold corresponding to the maximum segmentation parameter of each thread.

It should also be understood that the segmentation thresholds of each thread may be the same or different, which is not specifically limited in this embodiment of the present application.

It should also be understood that the running time of each time segment of a thread is the difference between the time information of the first fusion log entry that starts first and the time information of the first fusion log entry that ends last included in the time segment. The execution time of each time segment of a thread is the sum of at least one actual execution time in the time segment, and the actual execution time is the time information of the first merged log entry that records the thread start execution and the thread end execution difference.

In the embodiment of the present application, at least one time can be determined according to at least two first fusion log entries with the same identity information and adjacent in time and the segmentation threshold, that is, according to at least two temporally adjacent time records and segmentation thresholds of the same thread. fragment. In other words, at least two temporally adjacent time records of the same thread can be divided into at least one time segment, so as to facilitate subsequent acquisition of behavior information of the service node according to at least one time segment.

In combination with the first aspect, in some implementations of the first aspect, the trigger relationship of the first behavior is obtained according to the information of the first behavior and the behavior information of the service node that has a sending and receiving relationship with the service node; according to the information of the first behavior The trigger relationship between the information and the first behavior is to obtain the message channel for receiving the event corresponding to each behavior that triggers the first behavior.

It should be understood that the first behavior is any one of the N behaviors of the service node. The service nodes that have a sending and receiving relationship with the service node include: one or more of the service nodes that send messages to the service node, or one or more of the service nodes that receive the messages sent by the service node. The behavior that triggers the first behavior may be one or more behaviors, and each behavior that triggers the first behavior corresponds to a message channel for receiving events of the first behavior. The running behavior model of the first behavior includes a message channel for receiving events corresponding to each behavior that triggers the first behavior.

In the embodiment of the present application, the operation behavior model used to describe the operation behavior of the service node can be obtained by analyzing the information of N behaviors of the service node.

With reference to the first aspect, in some implementations of the first aspect, the time information of each first fusion log entry contained in the one or more first fusion log entry sets corresponding to the first row is converted into frequency domain data ; Determine whether there are one or more frequency values exceeding the average value of the frequency domain data in the frequency domain data; if so, then determine at least A time-triggered cycle.

It should be understood that the first behavior is any one of the N behaviors of the service node. The first fusion log entry is a fusion log entry corresponding to scheduling information in the fusion log. The operational behavior model of the first behavior includes at least one time-triggered period of the first behavior.

It should also be understood that the step of obtaining the message channel for receiving the event corresponding to each behavior that triggers the first behavior may be performed before the step of determining at least one time trigger period of the first behavior, or may be performed after determining at least one time trigger period of the first behavior The step of triggering the cycle is performed afterward, which is not specifically limited in this embodiment of the present application.

It should also be understood that at least one of the first fusion log entries corresponding to the m-th thread among the M threads included in the n-th behavior in the set of one or more first fusion log entries corresponding to the n-th behavior in the N behaviors can be The time information of log entries is converted into frequency domain data, and the running cycle of the mth thread is obtained.

It should also be understood that the first fusion log entry is a fusion log entry corresponding to scheduling information in the fusion log, and the first fusion log entry set is a set of at least one first fusion log entry, n=1, ..., N, m =1, ..., M, M is a positive integer greater than or equal to 1.

With reference to the first aspect, in some implementation manners of the first aspect, according to the interval of time information of at least two first fusion log entries included in the one or more first fusion log entry sets corresponding to the first behavior, obtain The first line runs the time probability model.

It should be understood that the first behavior is any one of the N behaviors of the service node. The first fusion log entry is a fusion log entry corresponding to scheduling information in the fusion log. The running behavior model of the first behavior includes a time probability model of the running of the first behavior.

In combination with the first aspect, in some implementations of the first aspect, when it is monitored that the directed graph of the dependency relationship of the service node has changed, the operating behavior model of the service node is updated; or, when the monitoring of the service node’s When the change of the behavior data exceeds the threshold, the behavior data in the running behavior model of the service node is updated.

It should be understood that a directed graph of dependency relationships of service nodes may be constructed according to dependency relationships of service nodes. It should also be understood that when the directed graph of dependencies of the service nodes is monitored to change, the fusion log of the service node may be reacquired, and the operating behavior model of the service node may be updated according to the reacquired fusion log of the service node.

It should also be understood that monitoring a change in the directed dependency graph of a service node includes: monitoring that at least one node in the directed dependency graph has changed, or that the longest path in the directed graph of dependency has changed.

It should also be understood that the change of at least one node includes any one or more items of at least one node being reduced, at least one node being added, and at least one node having a changed position in the dependency relationship directed graph. The change of the longest path includes any one or more items of the longest path increasing, the longest path shortening, and at least one node in the longest path changing. The change of at least one node in the longest path includes a change of a node constituting the longest path or a change of a position of a node constituting the longest path.

It should also be understood that the longest path can be found in the dependency directed graph through a search algorithm, and the search algorithm can be a maximum spanning tree algorithm, a dynamic programming algorithm, or a topological sorting algorithm, which is not specifically limited in this embodiment of the present application.

It should also be understood that it is possible to monitor in real time whether the directed graph of dependencies changes, or to check whether the directed graph of dependencies changes at regular intervals.

It should also be understood that, in the case that the behavior data of the business node is monitored to exceed the threshold, the behavior data in the operation behavior model of the business node can be updated by any of the following algorithms: moving average algorithm, simple moving average, weighted moving average , autoregressive moving average model algorithm, etc.

It should also be understood that the behavior data includes the frequency of receiving messages of the service node, the frequency of sending messages of the service node, the delay of the callback processing of the service node, the number of processes contained in the service node, and each behavior in at least one behavior of the service node Either or more of the number of threads contained.

It should also be understood that the embodiment of the present application may monitor whether the change of the behavior data of the service node exceeds a threshold while monitoring whether the directed graph of dependency relationship changes.

In the embodiment of the present application, the operation behavior model of the service node can be re-updated when it is monitored that the directed graph of dependency relationship has changed, and it can also be monitored that the change of the behavior data of the service node exceeds the threshold. Update the behavior data in the running behavior model of the business node. Therefore, after the automatic driving scene changes or the automatic driving service code is updated, the operation behavior model of the service node is re-established, so that the model can be used to describe the behavior state of the service node of the changed automatic driving service.

In a second aspect, an embodiment of the present application provides a computer device, where the computer device includes a unit for implementing the first aspect or any possible implementation manner of the first aspect.

In a third aspect, an embodiment of the present application provides a computer device, the computer device includes a processor, the processor is used to be coupled with a memory, read and execute instructions and/or program codes in the memory, so as to implement the first aspect or Any possible implementation of the first aspect.

In a fourth aspect, an embodiment of the present application provides a chip system, the chip system includes a logic circuit, the logic circuit is used to couple with an input/output interface, and transmit data through the input/output interface to perform the first aspect or the first Any possible implementation of the aspect.

In the fifth aspect, the embodiment of the present application provides a computer-readable storage medium, the computer-readable storage medium stores program codes, and when the computer storage medium is run on a computer, the computer executes the first aspect or the first aspect. any possible implementation of .

In a sixth aspect, an embodiment of the present application provides a computer program product, the computer program product comprising: computer program code, when the computer program code is run on a computer, the computer is made to execute any of the first aspect or the first aspect. One possible implementation.

Description of drawings

Figure 1 is a schematic system architecture diagram of an autonomous driving software and hardware platform.

Fig. 2 is a schematic system architecture diagram of a modeling method for a service node of an automatic driving service according to an embodiment of the present application.

Fig. 3 is a schematic flowchart of a modeling method for a service node of an automatic driving service according to an embodiment of the present application.

Fig. 4 is a schematic flowchart of a method for obtaining fusion logs according to an embodiment of the present application.

Fig. 5 is a schematic waveform diagram of converting the time information of behavior in the fusion log into frequency domain data according to an embodiment of the present application.

Fig. 6 is a schematic flowchart of a method for acquiring node-level communication logs and thread-level scheduling logs according to an embodiment of the present application.

Fig. 7 is a schematic diagram of a directed graph of dependency relationships of service nodes according to an embodiment of the present application.

Fig. 8 is a schematic diagram of adjusting a scheduling policy of a service node and a service node associated with the service node according to an embodiment of the present application.

Fig. 9 is a schematic flowchart of a method for acquiring node-level communication logs and thread-level scheduling logs according to another embodiment of the present application.

Fig. 10 is a schematic diagram of an internal structure of a service node according to an embodiment of the present application.

Fig. 11 is a schematic flowchart of a modeling method for a service node of an automatic driving service according to another embodiment of the present application.

Fig. 12 is a schematic diagram of visualized time information of multiple first fusion log entries in the fusion log according to an embodiment of the present application.

Fig. 13 is a schematic flowchart of a modeling method for a service node of an automatic driving service according to another embodiment of the present application.

Fig. 14 is a schematic flowchart of a modeling method for a service node of an automatic driving service according to another embodiment of the present application.

Fig. 15 is a schematic structural diagram of a modeling device for a service node of an automatic driving service according to an embodiment of the present application.

Fig. 16 is a schematic structural diagram of a modeling device for a service node of an automatic driving service according to an embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings.

The technical solutions of the embodiments of the present application can be applied to various automatic driving vehicle control operating systems and automatic driving intelligent operating systems, etc., which are not limited in the embodiments of the present application.

The automatic driving vehicle control operating system is an embedded real-time operating system developed by traditional gasoline-powered car factories. It is used for traditional vehicle control and is suitable for power system and chassis control. operating system interface (POSIX) standard operating system, suitable for high-performance computing and high-bandwidth communication required for autonomous driving, providing functions such as vehicle environment perception, intelligent decision-making, and path planning.

In order to facilitate the understanding of the embodiments of the present application, several terms involved in the present application are briefly described first.

1. Business

In the autonomous driving intelligent operating system, the business is usually a collection of processes and threads that are encapsulated by communication middleware and have specific autonomous driving functions. The communication middleware may be a robot operating system (robot operating system, ROS), an automotive open system architecture communication management module (automotive open system architecture communication management, AutoSAR CM), etc. This automatic driving function can be functions such as vehicle environment perception, sensor fusion and path planning.

2. Business node

A business node is an abstract concept of a single business. Two or more parties of a business node realize the transmission of messages or service calls between processes or components by calling the application programming interface (application programming interface, API) such as message sending and receiving of the communication middleware. A service node can include one or more behaviors to realize specific automatic driving functions.

3. Node

In network theory or graph theory, the term node denotes a point in a network topology where lines intersect or branch. A node can be understood as a point where lines intersect or branch in a directed graph of dependencies, and a node represents a service node with a specific autopilot function. An associated node of a node refers to at least one of at least one upstream node and at least one downstream node of the node in the dependency directed graph.

4. Behavior

A behavior is an abstraction of a collection of time slices (ie, one or more tasks) of one or more threads. In order to realize a specific autonomous driving function, each business node can perform one or more behaviors, which is a collection of one or more tasks with a clear purpose or clear function.

5. Tasks

A task is an abstraction of a slice of time for a thread. There is a one-to-one correspondence between a task and a time segment of a thread, that is, a time segment of a thread is a task. One or more tasks can constitute an action.

6. Process

A process is a running activity of a program in a computer on a certain data set. It is the basic unit for system resource allocation and scheduling, and the basis of the operating system structure. In the early process-oriented design computer structure, the process is the basic execution entity of the program; in the contemporary thread-oriented design computer structure, the process is the container of the thread. A program is a description of instructions, data and its organizational form, and a process is the entity of a program. Processes are identified by their process ID.

7. Thread

A thread is the smallest unit that an operating system can perform operation scheduling. A thread is included in a process and is the actual operating unit in the process. A thread refers to a single sequential flow of control in a process. Multiple threads can run concurrently in a process, and each thread performs different tasks in parallel. Threads can be identified by thread number.

To sum up, one or more threads can constitute a process; a collection of time segments of one or more processes (that is, one or more tasks) can constitute a behavior; and one or more behaviors can constitute a business.

8. Message channel (topic):

In this embodiment of the application, a message channel is a designated communication channel between service nodes, and the composition of a message channel includes a sending port of a sender, a receiving port of a receiver, a channel name, a message format, and the like.

9. Operating behavior of business nodes:

The running behavior of a business node includes the running behavior of threads contained in the business node on hardware resources and the dependencies and triggering relationships between different business nodes. The hardware resource can be CPU or GPU, etc., and the running behavior of the thread on the hardware resource Behavior includes the thread's running time, running cycle, trigger relationship, and so on.

The autonomous driving software and hardware platform system 100 can be divided into three parts: the autonomous driving business 110 , the autonomous driving software system 120 and the autonomous vehicle hardware platform 130 .

The automatic driving service 110 is the service source code that can enable the automatic driving car to realize basic automatic driving functions. The automatic driving software system 120 includes a communication middleware 121, a scheduling module 122 and an automatic driving intelligent operating system 123. The communication middleware 121 abstracts and unifies different communication protocol stacks and protocols of the intelligent driving operating system and the safe vehicle control operating system, including communication management (communication management, CM), ROS/ROS2, data distribution service (data distribution service, DDS), Internet protocol-based scalable service-oriented middleware (scalable service-oriented middleware over internet protocol, SOME/IP), etc. The communication middleware 121 provides a unified communication interface and function for the automatic driving service 110, and can record the necessary calling information when the automatic driving service 110 calls the communication interface. The scheduling module 122 can adjust the scheduling strategy of the automatic driving service node according to the actual needs in the process of automatic driving, or according to the actual needs when the service node of the automatic driving service is running, including adjusting the priority and core binding strategy. The scheduling module 122 can also track and record each service node and the running time sequence log of the threads included in the service node in the computing resources. The running timing log may be a node-level communication log of the service node, or a thread-level scheduling log of threads included in the service node. The computing resource may be a CPU or a GPU or the like.

Fig. 2 is a schematic system architecture diagram of a modeling method for a service node of an automatic driving service according to the present application.

The system architecture 200 of the modeling method for the autonomous driving service provided in this application may include an automatic driving service 210 , an automatic driving software system 220 and an automatic driving vehicle hardware platform 230 .

The automatic driving software system 220 includes a communication middleware 221 , a monitoring module 222 , a modeling framework 223 and an automatic driving intelligent operating system 224 .

The communication middleware 221 can provide a unified communication platform and capability, and integrates the vehicle communication protocol stack, transmission control protocol/internet protocol (transmission control protocol/internet protocol, TCP/IP) protocol and user datagram protocol/internet protocol (user datagram protocol) The protocol/internet protocol (UDP/IP) protocol can provide a unified communication interface and function for the automatic driving service 210, and can also record necessary call information when the automatic driving service 210 calls the communication interface.

The monitoring module 222 can obtain the communication data and scheduling data of the business nodes of the autonomous driving business, can interface with the communication middleware 221, the modeling framework 223 and the smart operating system for autonomous driving 224, and can monitor whether the dependencies and operating behavior of the business nodes change , which is convenient for updating the operating behavior model of the service node when the automatic driving service is updated or the automatic driving scene is switched. The monitoring module 222 includes a communication monitoring module 2221 and a trace monitoring module 2222, wherein the communication monitoring module 2221 is used to obtain communication data of service nodes, and the trace monitoring module is used to obtain scheduling data of service nodes.

The modeling framework 223 can provide a modeling framework and capabilities, including a dependency analysis module 2231 , a log fusion module 2232 , a segmentation and aggregation module 2233 , and an association analysis module 2234 . The dependency analysis module 2231 can obtain the associated service node and the dependency relationship of the service node according to the communication data of the service node obtained by the communication monitoring module 2221, and adjust the scheduling strategy of the service node and the service node's associated service node to collect the information of the service node. Node-level communication logs and thread-level scheduling logs. The log fusion module 2232 can obtain fusion logs according to the collected node-level communication logs and thread-level scheduling logs of service nodes. The segmentation and aggregation module 2233 can obtain information about one or more behaviors of the service node according to the fusion log. The association analysis module 2234 may obtain an operating behavior model used to describe the behavior of the service node according to information about one or more behaviors of the service node. The running behavior model of this behavior can include the dependencies of the business node, or the running behavior of all threads included in the behavior on hardware resources, and the running behavior can include any one or more of the following: thread running time, running cycle , or trigger relationships. The hardware resource may be a CPU or a GPU or the like. The running behavior model of the behavior may also include any of the following: a message channel for receiving events corresponding to each behavior that triggers the behavior, at least one time trigger period of the behavior, or a time probability model of the behavior. If the running behavior model of the behavior includes a message channel for receiving events corresponding to each behavior that triggers the behavior, then the running behavior model of the behavior may also include the trigger relationship of the behavior.

The autonomous driving intelligent operating system 224 runs on the autonomous driving vehicle hardware platform 230 , including a tracker 2241 and a scheduler 2242 . The tracker 2241 and the scheduler 2242 together constitute the scheduling module in FIG. 1 , which can adjust the scheduling strategy of the automatic driving service according to the actual needs during the automatic driving process or the actual needs during the operation of the automatic driving service.

The self-driving vehicle hardware platform 230 can provide a basic hardware platform for the self-driving software system 220 , including a processor 251 , a memory 252 and a storage 253 .

Fig. 3 is a schematic flow chart of a modeling method for a service node of an automatic driving service according to the present application. The modeling method for the automatic driving business in Figure 3 can be executed by a modeling device or modeling equipment, for example, it can be executed by the automatic driving system in Figure 2, or it can be performed by other modeling devices or modeling devices connected to the automatic driving system. It is realized by using a mold device, and the embodiments of the present application are not limited thereto. The modeling method of the autonomous driving business in Figure 3 includes the following contents.

S310. Obtain the fusion log of the service node of the automatic driving service.

Since most of the source codes of autonomous driving services are not open to the public, it is difficult to abstract business models from the source codes of autonomous driving services, such as the method of generating function call graphs. However, most current autonomous driving operating systems use communication middleware such as ROS, DDS, or execution manager (execution manager, EM) in order to decouple business logic from underlying communication and interfaces. The business is encapsulated into business modules with different functions, such as vehicle environment perception, sensor fusion, path planning and other modules. Each business module contains one or more business nodes, and different business nodes use communication middleware to transfer messages and call services. The autonomous driving business can be connected in series through middleware such as ROS or DDS to form a task node chain and form a complete autonomous driving capability. Therefore, although the source code of the automatic driving service cannot be obtained, the fusion log of the service node of the automatic driving service can still be obtained from the communication middleware 221 . The fusion log can record the call event of the service node and the scheduling information of the thread, where the thread is run by the service node.

Optionally, before step S310, step S301 and step S302 in FIG. 4 may be included. Fig. 4 is a schematic flowchart of a method for obtaining fusion logs.

Step S301, obtaining node-level communication logs and thread-level scheduling logs of service nodes.

The node-level communication logs of business nodes are communication logs recorded at the granularity of nodes. The node-level communication log of a business node records the invocation events of the business node. The node-level communication log of a business node contains one or more communication log entries. Each communication log entry can include identity information, time information, and log content. The identity information of each communication log entry includes the log that generated each communication log entry The name and process number of the business node of the content, the time information of each communication log entry includes the generation time of the log content included in each communication log entry, the log content of each communication log entry includes the name of the call event, and the call event includes Any one of the receiving event of the service node, the sending event of the service node, the callback start event of the service node, and the callback end event of the service node. When the calling event is a receiving event or sending event of the service node, the log content of the communication log entry also includes the message channel of the calling event.

It should be understood that the node-level communication log may include receiving and sending relationships between the service node and other service nodes, so the dependency relationship of the service nodes may be determined through the node-level communication log. Other service nodes refer to other service nodes except the service node. It should also be understood that the dependency relationship of a service node is the relationship between the service node and service nodes that have receiving and sending relationships with the service node.

The thread-level scheduling log of a business node is a scheduling log recorded at the granularity of a thread. The thread-level scheduling log of the service node records the scheduling information of the thread. Threads are run by business nodes. The thread-level scheduling log of a business node contains one or more scheduling log entries. Each scheduling log entry can include identity information, time information, and log content. The identity information of each scheduling log entry includes the information included in each scheduling log entry. The thread number and process number of the log content, the time information of each scheduling log entry includes the generation time of the log content included in each scheduling log entry, and the log content of each scheduling log entry includes thread priority, thread binding core Information, the name of the event of the thread, and the event of the thread includes any one of the wake-up event of the thread, the task switching event of the thread, and the relocation event of the thread.

S302. Fuse the node-level communication log and the thread-level scheduling log to obtain the fusion log.

Since the obtained node-level communication logs lack information about threads inside service nodes, such as thread priority, thread core binding information, and thread events, it is difficult to accurately establish the behavior of service nodes using only node-level communication logs. module, and because the obtained thread-level scheduling log only has the running information of the thread on the hardware resources, it lacks the behavior information of the service node, such as the call event of the service node, and the records of the thread-level scheduling log are messy, so it is impossible to The running information of the node is directly mapped to the behavior of the service node, so it is necessary to integrate the node-level communication log and the thread-level scheduling log, so as to facilitate the subsequent further analysis of the behavior of the service node.

In some embodiments, the time information in the node-level communication log is global time stamp information, and the time information in the thread-level scheduling log is local time stamp information. Since the form of the global time stamp information is inconsistent with the local time stamp information, therefore, in When merging node-level communication logs and thread-level scheduling logs, it is necessary to synchronize the time information in the node-level communication logs with the time information in the thread-level scheduling logs.

Optionally, the method of synchronizing the time of the node-level communication log and the thread-level scheduling log may be: during the process of obtaining the node-level communication log and the thread-level scheduling log, adding Time synchronization data, according to the time synchronization data, the time information in the node-level communication log and the time information in the thread-level scheduling log are synchronized. The synchronization method can be to synchronize data according to time, and convert the time information form of thread-level scheduling logs into the time information form of node-level communication logs, or the synchronization method can be to synchronize data according to time, and convert the time information form of node-level communication logs to It is converted into the time information form of the thread-level scheduling log.

Optionally, time synchronization data can be added once in the process of obtaining node-level communication logs and thread-level scheduling logs, or periodic time synchronization data can be added in the process of obtaining node-level communication logs and thread-level scheduling logs, for example, Add about 5 minutes as a period of time synchronization data.

Optionally, the time synchronization data can be in the form of <global timestamp, local timestamp> 2-tuple data at a certain moment, or it can be other data including global timestamp and local timestamp that can achieve the purpose of time synchronization structure type.

Optionally, in the process of merging node-level communication logs and thread-level scheduling logs, after synchronizing the time information of node-level communication logs and thread-level scheduling logs, the identities of node-level communication logs and thread-level scheduling logs can be Information, synchronized time information, and log content are merged into one log to obtain a fusion log.

Optionally, in the process of merging the node-level communication log and the thread-level scheduling log, after synchronizing the time information of the node-level communication log and the thread-level scheduling log, the node-level communication log can be merged according to the synchronized time information The identity information and log content of the thread-level scheduling log and the thread-level scheduling log are arranged in a chronological order and put into a log to obtain a fusion log.

Optionally, during the fusion process of node-level communication logs and thread-level scheduling logs, the identity information of node-level communication logs and the identity information of thread-level scheduling logs can be aligned, and the way of alignment can be by searching node-level communication The corresponding relationship between the process ID in the log and the process ID in the thread-level scheduling log is to align the name of the business node in the node-level communication log with the name of the thread number in the thread-level scheduling log.

In some other embodiments, if the time information of the node-level communication log and the thread-level scheduling log is a unified timestamp (for example, both are global timestamp information or local timestamp information), then the node-level communication log and the thread-level scheduling log can be directly merged. The fusion log can be obtained from the scheduling log at the node level without first synchronizing the time information of the communication log at the node level and the scheduling log at the thread level.

After the node-level communication log and the thread-level scheduling log are fused, the obtained fused log includes one or more fused log entries, wherein each fused log entry includes time information, type information, identity information and log content. The time information of each fusion log entry includes the time information of the node-level communication log entry or thread-level scheduling log entry corresponding to each fusion log entry, and the type information of each fusion log entry is used to indicate the log corresponding to each fusion log entry The entries are node-level communication log entries or thread-level scheduling log entries, the identity information of each fusion log entry includes the identity information of the log entry corresponding to each fusion log entry, and the log content of each fusion log entry includes each fusion log entry The log content of the corresponding log entry.

For example, assume that the content of the obtained node-level communication log is shown in Table 1 below, and the content of the obtained thread-level scheduling log is shown in Table 2 below.

Table 1 Node-level communication logs

编号serial number	身份信息Identity Information	时间信息time information	日志内容log content
通信日志条目1Communication log entry 1	业务节点名称1，进程号1Business node name 1, process number 1	全局时间戳1global timestamp 1	通信数据1communication data 1
通信日志条目2Communication log entry 2	业务节点名称1，进程号1Business node name 1, process number 1	全局时间戳2global timestamp 2	通信数据2communication data 2
通信日志条目3Communication log entry 3	业务节点名称1，进程号1Business node name 1, process number 1	全局时间戳3Global Timestamp 3	通信数据3communication data 3
通信日志条目4Communication log entry 4	业务节点名称1，进程号1Business node name 1, process number 1	全局时间戳4Global Timestamp 4	通信数据4communication data 4
通信日志条目5Communication log entry 5	业务节点名称1，进程号2Business node name 1, process number 2	全局时间戳5Global Timestamp 5	通信数据5communication data 5

Table 2 Thread-level scheduling logs

编号serial number	身份信息Identity Information	时间信息time information	日志内容log content
调度日志条目1dispatch log entry 1	进程号1，线程号3Process number 1, thread number 3	本地时间戳1local timestamp 1	调度数据1Scheduling Data 1
调度日志条目2dispatch log entry 2	进程号1，线程号3Process number 1, thread number 3	本地时间戳2local timestamp 2	调度数据2Scheduling Data 2
调度日志条目3dispatch log entry 3	进程号1，线程号4Process number 1, thread number 4	本地时间戳3local timestamp 3	调度数据3Scheduling data 3
调度日志条目4Dispatch log entry 4	进程号1，线程号3Process number 1, thread number 3	本地时间戳4local timestamp 4	调度数据4Scheduling Data 4
调度日志条目5Dispatch log entry 5	进程号1，线程号4Process number 1, thread number 4	本地时间戳5local timestamp 5	调度数据5Scheduling Data 5
调度日志条目6 Dispatch log entry 6	进程号1，线程号3Process number 1, thread number 3	本地时间戳6 local timestamp 6	调度数据6 Scheduling Data 6
调度日志条目7Dispatch log entry 7	进程号1，线程号3Process number 1, thread number 3	本地时间戳7local timestamp 7	调度数据7Scheduling Data 7
调度日志条目8 Dispatch log entry 8	进程号1，线程号4Process number 1, thread number 4	本地时间戳8 local time stamp 8	调度数据8 Scheduling data 8
调度日志条目9Dispatch log entry 9	进程号1，线程号3Process number 1, thread number 3	本地时间戳9local timestamp 9	调度数据9Scheduling Data 9
调度日志条目10 dispatch log entry 10	进程号1，线程号4Process number 1, thread number 4	本地时间戳10 local timestamp 10	调度数据10 Scheduling Data 10
调度日志条目11Dispatch log entry 11	进程号2，线程号5Process number 2, thread number 5	本地时间戳11local timestamp 11	调度数据11Scheduling Data 11

Synchronize the time information in the node-level communication log with the thread-level scheduling log, for example, you can convert the local timestamp in the thread-level scheduling log into the global timestamp in the node-level communication log, or you can convert the time information in the node-level communication log Global timestamps are converted to local timestamps in thread-level scheduling logs. After converting the local timestamp in the thread-level scheduling log into the global timestamp in the node-level communication log, the time information in the thread-level scheduling log shown in Table 2 is shown in Table 3 below.

Table 3 Thread-level scheduling log after time information synchronization

serial number

Identity Information

time information

log content

调度日志条目1dispatch log entry 1	进程号1，线程号3Process number 1, thread number 3	全局时间戳AGlobal Timestamp A	调度数据1Scheduling Data 1
调度日志条目2dispatch log entry 2	进程号1，线程号3Process number 1, thread number 3	全局时间戳BGlobal Timestamp B	调度数据2Scheduling Data 2
调度日志条目3dispatch log entry 3	进程号1，线程号4Process number 1, thread number 4	全局时间戳CGlobal Timestamp C	调度数据3Scheduling data 3
调度日志条目4Dispatch log entry 4	进程号1，线程号3Process number 1, thread number 3	全局时间戳DGlobal timestamp D	调度数据4Scheduling Data 4
调度日志条目5Dispatch log entry 5	进程号1，线程号4Process number 1, thread number 4	全局时间戳EGlobal Timestamp E	调度数据5Scheduling Data 5
调度日志条目6 Dispatch log entry 6	进程号1，线程号3Process number 1, thread number 3	全局时间戳FGlobal timestamp F		调度数据6Scheduling Data 6
调度日志条目7Dispatch log entry 7	进程号1，线程号3Process number 1, thread number 3	全局时间戳GGlobal timestamp G	调度数据7Scheduling Data 7
调度日志条目8 Dispatch log entry 8	进程号1，线程号4Process number 1, thread number 4	全局时间戳HGlobal timestamp H		调度数据8Scheduling data 8
调度日志条目9Dispatch log entry 9	进程号1，线程号3Process number 1, thread number 3	全局时间戳IGlobal Timestamp I	调度数据9Scheduling Data 9
调度日志条目10 dispatch log entry 10	进程号1，线程号4Process number 1, thread number 4	全局时间戳JGlobal Timestamp J		调度数据10Scheduling Data 10
调度日志条目11Dispatch log entry 11	进程号2，线程号5Process number 2, thread number 5	全局时间戳KGlobal timestamp K	调度数据11Scheduling Data 11

For example, after the time information in the node-level communication log and the time information in the thread-level scheduling log are arranged in a first-to-back order, the content of the obtained fusion log is shown in Table 4.

Table 4 fusion log

For example, when merging node-level communication logs and thread-level scheduling logs, other orders can be used to sort node-level communication log entries and thread-level scheduling log entries, or no sorting is performed, but only node-level communication log entries The content of and the content of thread-level scheduling log entries are placed in the same fusion log, as shown in Table 5 for example.

Table 5 fusion log

It should be understood that the numbering and naming of entries, identity information, time information, log content, etc. in Table 1, Table 2, Table 3, Table 4, and Table 5 are only for identification purposes, and should not be interpreted as a reference to the embodiment of the present application. limits.

Through the fusion of node-level communication logs and thread-level scheduling logs, the fusion log can be obtained. The fusion log includes the running information of the thread and the communication information of the business node, and the running information of the thread can be directly mapped to the business node in the subsequent processing. Behavior information, so as to support the establishment of an accurate operating behavior model for the operating behavior of business nodes.

It should be understood that in the above embodiment, the node-level communication log and the thread-level scheduling log can be fused through steps S301 and S302, so as to obtain the fused log. In some other embodiments, the fusion log can be obtained directly by directly obtaining the calling event of the service node and the scheduling information of the thread.

S320. Obtain information on N behaviors of service nodes according to the fusion log, where N is a positive integer greater than or equal to 1.

The fusion log obtained according to step S310 includes the call event of the service node and the scheduling information of the thread contained in the service node, so the information of N behaviors of the service node can be obtained by processing the information contained in the fusion log. Among them, the information of each behavior of the business node includes: the number of threads contained in each behavior, the running time of each behavior, the average running time of each behavior and the probability of running time, and the execution time of each behavior , the average and probability of the execution time of each behavior, the running time of each thread in each behavior, the execution time, the average running time and the average execution time, the name of the event in each behavior, the The mean of the time points of the events in or the probability distribution model of the time points of the events. Events in each behavior include receive events in each behavior, send events in each behavior, callback start events in each behavior, and callback end events in each behavior. The time point of the event in each behavior includes an absolute time point of the event or a relative time point of the event.

The behavior of a business node is aggregated by the time records of multiple threads. For example, the time information in fusion log entry 6 to fusion log entry 11 in Table 5 can be aggregated into the first behavior of business node 1, and the fusion log in Table 5 The time information in entry 12 to fusion log entry 15 may be aggregated into the second behavior of service node 1 . Therefore, each behavior of the service node includes one or more time records of each thread in one or more threads. The event in the behavior of the business node is the event recorded in the communication log entry corresponding to the time record of the thread included in the behavior. The communication log entry corresponding to the thread time record refers to the time information of the communication log entry recorded in the thread time time frame. The time point of the event in the behavior of the service node may be a relative time point or an absolute time point, which is not specifically limited in this embodiment of the present application. The relative time point of the event is the time point calculated according to the time information recorded in at least one communication log entry, and the absolute time point of the event is the time information recorded in the communication log entry that recorded the event.

It should also be understood that the running time of the mth thread in the nth behavior of the business node is: the running time of the time segment belonging to the mth thread included in the nth behavior, that is, the running time of the time segment included in this time segment The difference between the time information of the first fusion log entry that started first and the time information of the first fusion log entry that ended last. The first fusion log entry is a fusion log entry corresponding to scheduling information in the fusion log. The execution time of the mth thread in the nth behavior of the business node is: the execution time of the time segment belonging to the mth thread included in the nth behavior, that is, the sum of all actual execution times in this time segment, the actual The execution time is the difference between the time information of the first merged log entry that records the execution of the thread and the execution of the thread that are adjacent to each other in time. n=1, . . . , N, m=1, . . . , M, N and M are positive integers greater than or equal to 1.

It should also be understood that the running time of the nth behavior of the service node is: in one or more time segments included in the nth behavior, the time information of the first fusion log entry that starts first and the first fusion log entry that ends last The delta of the time information of the fused log entries. The execution time of the nth behavior of the business node is: the average execution time of the threads included in the nth behavior, that is, the sum of the execution times of the threads included in the nth behavior divided by the time of the threads included in the nth behavior quantity.

It should also be understood that one or more behaviors of the service node can be obtained according to the time information in the fusion log, and during the operation of the autonomous driving service, the behavior of the service node will run repeatedly, that is, the behavior of the service node includes The thread will run repeatedly multiple times. Therefore, the fusion log contains the time information of each behavior of one or more behaviors of the service node running one or more times. Whether multiple behaviors are the same behavior can be judged according to the set of thread numbers included in each behavior. The execution time and running time of threads obtained when the same behavior is run repeatedly, the execution time and running time of the behavior may be inconsistent. Therefore, the average execution time and average running time of the thread can be calculated according to the obtained multiple execution times and multiple running times of the threads included in the behavior, that is, the average value of the execution time and the average running time of the thread can be calculated . According to the obtained multiple running times and multiple execution times of the behavior, the average running time, the probability of running time, the average execution time and the probability of execution time of the behavior are calculated. The probability of the behavior's runtime is the probability that each runtime value of the behavior occurs among all the runtime values. The execution time probability of the behavior is the probability that each execution time value of the behavior occurs in all execution time values.

Optionally, the manner of obtaining information on the N behaviors of the service node according to the fusion log may be: according to the fusion log entries in the fusion log, determining at least one time segment; according to at least one time segment, determining N groups of fusion log entry sets; Determine N pieces of behavior information of the service node according to the N groups of fusion log entry sets respectively. Refer to the description in FIG. 11 for the manner of obtaining information on N behaviors of service nodes according to the fused logs.

By analyzing and processing the fusion log entries corresponding to the scheduling information and the fusion log entries corresponding to the call events in the fusion log, information such as the behavior of the service node and the running time of the thread included in the behavior of the business node can be obtained, which is convenient for subsequent The information of the service node and the information of the thread included in the service node are further processed, so as to support the establishment of an accurate running behavior model for the running behavior of the business node.

S330, analyzing information on N behaviors of the service node to obtain an operation behavior model used to describe the operation behavior of the service node.

According to the information on the N behaviors of the service node obtained in step S320, an operation behavior model of the N operation behaviors of the service node can be obtained. In other words, the running behavior model of each behavior can be determined based on the information of each behavior. Assume that the first behavior is any one of the N behaviors. Then, the running behavior model of the first behavior may include any of the following: the message channel for receiving events corresponding to each behavior that triggers the first behavior, at least one time trigger period of the first behavior, or the time probability of the first behavior Model. If the running behavior model of the first behavior includes a message channel for receiving events corresponding to each behavior that triggers the first behavior, then the running behavior model of the first behavior may also include a trigger relationship of the first behavior.

In some embodiments, the running behavior model of the first behavior may further include any one or more of the following: dependencies of service nodes, running time of at least one thread included in the first behavior, The trigger relationship of at least one thread, or the running period of at least one thread included in the first behavior.

Since some service nodes of the autonomous driving service use timers to run at a fixed frequency, it is not comprehensive to analyze the triggering method of the behavior of the service nodes only by merging the receiving events and sending events in the log. information, determine the trigger mode of the behavior of the business node, and obtain the behavior trigger record of the behavior of the business node. At the same time, it is difficult to obtain the trigger relationship of the service node through simple analysis due to the situation of multiple receiving and multiple sending among the service nodes. Therefore, it is necessary to obtain the trigger relationship of the service node according to the behavior information of the service node. Multi-receiving and multi-sending means that a service node can receive messages sent by multiple other service nodes, and can also send messages to multiple other service nodes. Other service nodes refer to other service nodes except the service node.

Optionally, according to the information of the first behavior and the behavior information of the service node that has a transceiving relationship with the service node, the trigger relationship of the first behavior can be obtained through an association rule mining algorithm, and it is determined that there is an event trigger in the first behavior, and the trigger relationship can be obtained. Each behavior of the first behavior corresponds to the message channel that receives the event.

It should be understood that the behavior that triggers the first behavior may be one or more behaviors that trigger the execution of the first behavior. A behavior that triggers the first behavior corresponds to a message channel that the first behavior receives events. The event-receiving message channels of the first behavior corresponding to each behavior that triggers the first behavior may be the same or different. The service nodes that have a sending and receiving relationship with the service nodes include: one or more of the service nodes that send messages to the service nodes, or the service nodes that receive the messages sent by the service nodes.

It should be understood that the behavior that triggers the first behavior may be the behavior of the service node, or the behavior of other service nodes except the service node, which is not specifically limited in this embodiment of the present application.

Optionally, the trigger relationship of the N behaviors of the service node can be obtained through an association rule mining algorithm, and one or more behaviors that trigger the first behavior can be determined. The behavior trigger record of the first behavior can be obtained according to one or more behaviors that trigger the first behavior. That is, there is an event trigger for the first behavior, and the behavior trigger record of the first behavior includes the name of the business node and the message channel that receives the event corresponding to each behavior that triggers the first behavior. For example, if the behavior that triggers the first behavior of service node 1 includes behavior A, behavior B, and behavior C, then there is an event trigger for the first behavior, and the behavior trigger record of the first behavior includes: the name of business node 1, the first behavior The message channel that receives the message sent by behavior A in the middle, the message channel that receives the message sent by behavior B in the first behavior, and the message channel that receives the message sent by behavior C in the first behavior.

Optionally, the triggering relationship of the first behavior or the triggering relationship of the M threads contained in the first behavior can be obtained by the following method: the business node in the same time window and the business node that has a sending and receiving relationship with the business node can be Behaviors are merged to establish a data set of nodes to be analyzed. The node behavior data set to be analyzed can be expressed as {{behavior including receiving events}, {behavior including sending events}, {other behaviors in the window}}. {Behaviors Including Receiving Events} means a data set containing events receiving events in the same time window, and the events containing receiving events include: one or more of the behaviors including receiving events of the service node. {behaviors with sending events} means the data set that contains the behaviors of sending events in the same time window. The behaviors that include sending events include: the behavior of business nodes that contain sending events, or the business nodes that send messages to this business node One or more of the behaviors that contain sending events. {Other behaviors in the window} means the data set of other behaviors in the same time window, the other behaviors include: the behavior of the business node containing the callback start event, or one of the behaviors of the business node containing the callback end event or Multiple. Since each of the N behaviors of the business node is composed of one or more threads, the behavior data set of the node to be analyzed contains the behaviors including receiving events, sending events and One or more threads of each behavior in the other behaviors of the business node, the other behaviors of the business node can be the behavior that contains the callback start event or the behavior that contains the callback end event; the one-hot (one -hot) coding; calling the association rule (apriori) algorithm to find out the frequent itemsets in the behavior data set of the node to be analyzed, as the trigger relationship of the M threads contained in the first behavior or the trigger relationship of the first behavior.

Optionally, the behavior corresponding to the receiving event among the first behaviors of the service node including the receiving event whose confidence degree is greater than the threshold in the above-mentioned node behavior data set to be analyzed is regarded as a necessary triggering behavior of the first behavior. In the necessary triggering behavior of the first behavior of the business node, if the first behavior only runs once, then according to the time information of the first behavior contained in the fusion log, the time before the callback start event in the first behavior is closest to Behaviors are considered key triggering behaviors. In the necessary triggering behavior of the first behavior of the service node, if the first behavior will run repeatedly, the time information of the first behavior running multiple times exists in the fusion log. According to the time information of multiple runs of the first behavior contained in the fusion log, the behavior that is always closest to the time of the callback start event in the first behavior is regarded as the key trigger behavior, that is, the first behavior in the fusion log runs multiple times In the time information of , the behavior that can be found at least once before the time of the callback start event is regarded as the key trigger behavior.

It should be understood that a behavior of a business node within the same time window can be combined with a behavior of a business node that has a sending and receiving relationship with the behavior of the business node, and a data set of nodes to be analyzed can be established to obtain the behavior of a business node. trigger relationship. It is also possible to combine multiple behaviors of business nodes within the same time window with behaviors of business nodes that have a sending and receiving relationship with multiple behaviors of the business node, establish a data set of nodes to be analyzed, and obtain triggers of multiple behaviors of business nodes relation. The behavior of the service node that has a transceiving relationship with the behavior of the service node may be one or more behaviors of each of the one or more service nodes that have a transceiving relationship with the behavior of the service node.

It should also be understood that, according to the information of the first behavior of the business node and the behavior information of the business node that has a transceiving relationship with the business node, the frequent itemsets in the business node behavior data set can be obtained through the association rule mining algorithm, that is, If the trigger relationship of the first behavior of the service node is obtained, then the first behavior has an event trigger. If the frequent item set in the behavior data set of the business node cannot be obtained through the association rule mining algorithm, that is, the trigger relationship of the first behavior of the business node cannot be obtained, then there is no event trigger for the first behavior.

It should also be understood that when there is an event trigger in the first behavior, the trigger relationship of the m-th thread among the M threads included in the first behavior can be obtained through the above method. When there is no event trigger in the first behavior, the trigger relationship of the m-th thread among the M threads included in the first behavior can still be obtained through the above method. Wherein, m=1, . . . , M, M is a positive integer greater than or equal to 1.

It should also be understood that the necessary triggering behavior is a necessary condition for triggering the service node to execute the next behavior. As shown in FIG. 7 , the fusion node N5 in FIG. 7 receives messages sent by the sensor node N2 and the pre-processing node N3 . If the behavior of node N2 sending a message and the behavior of node N3 sending a message are both necessary triggering behaviors of node N5, then after N5 executes a behavior, in the next time period, N5 receives at least one message sent by N2 and N3, It will trigger N5 to execute the next behavior. In other words, even if N5 has received multiple messages sent by N2, if N5 has not received the message sent by N3, it will not trigger N5 to execute the next action until N5 receives the message sent by N3, then trigger N5 to execute the next action. one act. Vice versa, that is, N5 has received multiple messages sent by N3. If N5 has not received the message sent by N2, it will not trigger N5 to execute the next action until N5 receives the message sent by N2, then trigger N5 to execute next behavior.

It should also be understood that the key triggering behavior is the key condition for triggering the next behavior of the service node, but if the business node has multiple necessary triggering behaviors at the same time, the triggering of the The service node executes the next behavior. As shown in Figure 7, if the behavior of N2 sending a message is a key triggering behavior, and the behavior of N3 sending a message is not a necessary triggering behavior, then after N5 executes one behavior, in the next time period, even if N5 receives multiple N3 sending If N5 has not received the message sent by N2, it will not trigger N5 to execute the next action until N5 receives a message sent by N2, it will trigger N5 to execute the next action.

If the behavior of N2 sending a message is a key triggering behavior, and the behavior of N3 sending a message is a necessary triggering behavior, then after N5 executes one behavior, in the next time period, N5 receives at least one message sent by N2 and N3, and it will Trigger N5 to execute the next action. In other words, even if N5 has received multiple messages sent by N2, if N5 has not received the message sent by N3, it will not trigger N5 to execute the next action until N5 receives the message sent by N3, then trigger N5 to execute the next action. one act. Vice versa, that is, N5 has received multiple messages sent by N3. If N5 has not received the message sent by N2, it will not trigger N5 to execute the next action until N5 receives the message sent by N2, then trigger N5 to execute next behavior.

Optionally, frequent itemsets in the node data set to be analyzed can be obtained through other association rule mining algorithms, such as frequent item set discovery algorithm (frequent pattern-growth, FP-Growth) algorithm, multi-stage algorithm, multi-hashing algorithm, etc.

Optionally, the time information of each first fusion log entry contained in one or more first fusion log entry sets corresponding to the first behavior among the N behaviors is converted into frequency domain data, that is, the first behavior is included in the fusion log The time information in is converted to frequency domain data, and it is determined whether there are one or more frequency values exceeding the average value of the frequency domain data in the frequency domain data. If so, determine that there is a time trigger in the first behavior, and determine at least one time trigger period of the first behavior according to one or more frequency values exceeding the average value of the frequency domain data of the first behavior. Each first fusion log entry set includes one or more first fusion log entries.

Optionally, according to at least one time-triggered period of the first behavior, a behavior-triggered record of the first behavior may be obtained. When the first behavior has a time trigger, the behavior trigger record of the first behavior includes: the name of the service node and at least one time trigger period of the first behavior.

It should be understood that, if the first behavior among the N behaviors will be repeated multiple times, all the time information of the first behavior in the fusion log will be converted into frequency domain data, so as to determine whether there is a time trigger in the first behavior. If the first behavior is only run once, the time information of the first behavior in the fusion log is converted into frequency domain data, so as to determine whether the first behavior has a time trigger.

It should also be understood that the step of obtaining the message channel for receiving the event corresponding to each behavior that triggers the first behavior may be performed before the step of determining at least one time trigger period of the first behavior, or after determining at least one time trigger period of the first behavior. The steps of a time-triggered period are performed afterward, which is not specifically limited in this embodiment of the present application.

The embodiment of the present application does not limit the implementation manner of how to convert time domain data into frequency domain data. For example, the time information in the first row in the fused log can be converted into frequency domain data using Fourier transform or fast Fourier transform methods.

If there is a frequency value exceeding the average value of the frequency domain data of the first behavior in the frequency domain data of the first behavior, then there is a single-cycle time trigger in the first behavior, and the time trigger period of the first behavior is corresponding to the frequency value time period; if there are multiple frequency values exceeding the average value of the frequency domain data of the first behavior in the frequency domain data of the first behavior, then the first behavior has multi-period time triggers, and multiple frequency values exceeding the first behavior The time period corresponding to the frequency value of the average value of the frequency domain data is the time trigger period of the first behavior.

For example, a partial waveform diagram obtained by converting the time information of a behavior of a service node in the fusion log into frequency domain data is shown in FIG. 5 .

Fig. 5 is a schematic waveform diagram of converting the time information of behavior in the fusion log into frequency domain data according to an embodiment of the present application. Fig. 5 is part of the frequency domain data converted from the time information of a behavior of a service node in the fusion log. In Figure 5, there are two frequency values that exceed the average value of the frequency domain data of this behavior, so there is a multi-period time trigger for this behavior, and the time trigger period is multiple frequency values that exceed the average value of the frequency domain data of this behavior The corresponding time periods, that is, the

abscissas

20 and 60 corresponding to the peaks shown in FIG. 5 are time trigger periods for this behavior.

Optionally, if the frequent itemsets of the first behavior of the service node can be found through the above method, and after the time information of the first behavior in the fusion log is converted into frequency domain data through the above method, there is a or a plurality of frequency values exceeding the average value of the frequency domain data of the first behavior (that is, there are one or more peaks in the waveform diagram of the frequency domain data), the trigger mode of the first behavior of the service node is determined according to the following conditions:

(1) If the first behavior has only one necessary trigger behavior, the time information of the necessary trigger behavior of the first behavior in the fusion log is converted into frequency domain data. If there are one or more frequency values exceeding the average value of the frequency domain data of the necessary trigger behavior of the first behavior in the frequency domain data of the necessary trigger behavior of the first behavior (that is, there are one or more frequency values in the waveform diagram of the frequency domain data peaks), and the number of peaks in the frequency domain data of the first behavior and the necessary trigger behavior of the first behavior is exactly the same as the value of the time period corresponding to the peak, then there is an event trigger in the first behavior. When the first behavior has an event trigger, the behavior trigger record of the first behavior includes: the name of the service node, and the event message channel of the first behavior that receives the message sent by the necessary trigger behavior of the first behavior.

If there is at least one discrepancy between the number of peaks in the frequency domain data of the first behavior and the necessary trigger behavior of the first behavior and the value of the time period corresponding to the peak, then there is another trigger in the first behavior.

(2) If the first behavior has multiple necessary triggering behaviors, and there is only one key triggering behavior among the multiple necessary triggering behaviors, convert the time information of the key triggering behavior of the first behavior in the fusion log into frequency domain data. If there are one or more frequency values exceeding the average value of the frequency domain data of the key trigger behavior of the first behavior in the frequency domain data of the key trigger behavior of the first behavior (that is, there are one or more frequency values in the waveform diagram of the frequency domain data peaks), and the number of peaks in the frequency domain data of the first behavior and the key trigger behavior of the first behavior is exactly the same as the value of the time period corresponding to the peak, then there is an event trigger in the first behavior. When there is an event trigger for the first behavior, the behavior trigger record of the first behavior includes: the name of the business node, and the message channel of the first behavior that receives the message sent by the key trigger behavior of the first behavior.

If there is at least one discrepancy between the number of peaks in the frequency domain data of the first behavior and the key trigger behavior of the first behavior and the value of the time period corresponding to the peak, then there is another trigger in the first behavior.

(3) If the frequent itemset of the first behavior of the service node can be found, one or more frequency domain data beyond the first behavior of the first behavior in the frequency domain data converted from the time information in the fusion log can also be found The frequency value of the average value (that is, one or more peaks in the waveform diagram of the frequency domain data), and the above conditions (1) and (2) are not satisfied, then there are other triggers in the first behavior.

Optionally, if the frequent itemsets of the first behavior of the service node can be found through the above method, but after the time information of the first behavior in the fusion log is converted into frequency domain data through the above method, the frequency domain data does not exist If one or more frequency values exceed the average value of the frequency domain data of the first row, then there is an event trigger for the first row. When there is an event trigger for the first behavior, the behavior trigger record of the first behavior includes: the name of the service node and the message channel that receives the event corresponding to each behavior that triggers the first behavior.

Optionally, if the frequent itemset of the first behavior of the service node cannot be found through the above method, but after the time information of the first behavior in the fusion log is converted into frequency domain data through the above method, there is a or multiple frequency values exceeding the average value of the frequency domain data of the first behavior, then the first behavior has a time trigger. When the first behavior has a time trigger, the behavior trigger record of the first behavior includes: the name of the service node and one or more time trigger periods of the first behavior.

Optionally, if the frequent itemset of the first behavior of the service node cannot be found through the above method, and after the time information of the first behavior in the fusion log is converted into frequency domain data through the above method, the frequency domain data does not exist One or more frequency values that exceed the average value of the frequency domain data of the first row, then there are other triggers for the first row.

Optionally, when the first behavior has other triggers and only runs once, according to the time information of at least one first fusion log entry contained in a first fusion log entry set corresponding to the first behavior, that is, according to the first behavior in The time information in the log is fused to obtain the behavior trigger record of the first behavior. When the first behavior has other triggers and only runs once, the behavior trigger record of the first behavior is: the name of the service node and the time information of one or more first behaviors running. The time information may be absolute time information or relative time information, which is not specifically limited in this embodiment of the present application.

Optionally, when the first behavior has other triggers and will be repeated multiple times, according to the time information of at least two first fusion log entries included in the plurality of first fusion log entry sets corresponding to the first behavior, that is, according to The time information of the first behavior in the fusion log is obtained to obtain the running time interval of the first behavior. According to the running time interval of the first behavior, the time probability model of the running of the first behavior and the behavior trigger record of the first behavior are obtained. When the first behavior has other triggers and will run repeatedly, the behavior trigger record of the first behavior can be: the name of the business node and the time probability model of the first behavior running.

It should be understood that the time probability model of the running of the first behavior is used to describe the probability distribution of the time interval of the running of the first behavior. The probability distribution of the time interval of the operation of the first line refers to the probability distribution of the value of the time interval between the i-th operation and the i+1-th operation of the first line, wherein, i=1,...,I , I is a positive integer greater than or equal to 1.

It should also be understood that the time interval for running the first behavior may be the interval between the start time of the i-th first behavior running and the i+1th time the first behavior running starts in the fusion log, or it may be the i-th The interval between the time when the first behavior of the first behavior ends and the time when the first behavior of the i+1th time ends, or it can be the time during the running of the first behavior of the ith time and the time during the running of the first behavior of the i+1th time The interval of time is not specifically limited in this embodiment of the present application.

Optionally, when the first behavior has other triggers and will be repeated multiple times, according to the time information of at least two first fusion log entries included in the plurality of first fusion log entry sets corresponding to the first behavior, that is, according to The first behavior is the time information in the fusion log, and the running time interval and the average value of the time interval of the first behavior are obtained. According to the average value of the time interval during which the first behavior runs, the behavior trigger record of the first behavior is obtained. When the first behavior has other triggers and will run repeatedly, the behavior trigger record of the first behavior can be: the name of the business node and the average value of the time interval for the first behavior to run.

It should be understood that the triggering manner of the first behavior can be determined through the above method, and the behavior trigger record of the first behavior can be obtained. The triggering mode of the first behavior may be any one of event triggering, time triggering, and other triggering modes.

Optionally, at least one first fusion log entry corresponding to the m-th thread among the M threads contained in the first behavior in the set of one or more first fusion log entries corresponding to the first behavior among the N behaviors The time information of is converted into frequency domain data, that is, the time record of the mth thread in the fusion log of the M threads included in the first row is converted into frequency domain data, and the running period of the mth thread is obtained.

To sum up, through step S301, the dependency relationship of service nodes can be obtained. Through step S320, the running time of at least one thread included in the nth behavior among the N behaviors of the service node can be obtained. Through step S330, the trigger relationship of at least one thread contained in the nth action among the N actions of the service node, and the running cycle of at least one thread included in the nth action can be obtained. Through step S330, the message channel of the receiving event corresponding to each behavior that triggers the first behavior, or at least one time trigger period of the first behavior, or the time probability model of the first behavior can be obtained. If the message channel for receiving the event corresponding to each behavior that triggers the first behavior can be obtained, the trigger relationship of the first behavior can also be obtained.

The running behavior model used to describe the running behavior of business nodes can provide reverse development guidance for designers and developers, and can also calculate the running behavior status of business nodes on hardware resources through simulation and other methods, and check the performance of business nodes on hardware. Whether the state of the running behavior on the resource is as designed. Therefore, the operating behavior model of the service node in the embodiment of the present application has important value for feedback guidance and auxiliary design. The running behavior model can also be used as the input for the simulation, simulation and optimization of the subsequent automatic driving business code, providing high-precision guarantee for the simulation, simulation and optimization of the subsequent automatic driving business code.

In some embodiments, when obtaining the node-level communication log and thread-level scheduling log of the service node, because the priority execution order of the service node is not adjusted, the interference caused by the operation of other service nodes other than the service node itself occurs, so that The obtained node-level communication log and thread-level scheduling log of the service node may contain a high noise floor. The degree of refinement of the operating behavior model of the service node of the autonomous driving service can be determined by the degree of noise of the obtained node-level communication logs and thread-level scheduling logs. When the obtained node-level communication logs and thread-level scheduling logs are low-noise or no-noise logs, the operation behavior model established for the service node can restore the operation behavior state of the service node more accurately.

Fig. 6 is a schematic flowchart of a method for acquiring node-level communication logs and thread-level scheduling logs according to an embodiment of the present application. The method for obtaining node-level communication logs and thread-level scheduling logs in FIG. 6 includes the following contents:

S410. Determine associated service nodes and dependencies of the service nodes according to the communication data of the service nodes.

When the self-driving vehicle enters the self-driving mode and runs the self-driving service, the communication middleware 221 can obtain the communication data of one or more service nodes. The communication data of each service node includes the receiving event or sending event of each service node. If the communication data includes the receiving event, the communication data also includes the message channel of the receiving event; if the communication data includes the sending event, the communication data also includes The message channel for sending events. For example, for a service node using the ROS communication protocol stack, ROS node (rosnode) information and ROS topic (rostopic) information can be collected to obtain the communication data of the service node. For example, rosnode can include node name (Node name), process identification number (Pid) , information published by nodes (Publications), subscribed information (Subscriptions), connection information (Connections) and other information, rostopic can include type information (Type), publisher information (Publisher), subscriber information (Subscriber) and other information. Among them, the name and process identification number of the service node can be obtained through Node name and Pid, the messages sent and received by the service node can be obtained through Publications, Subscriptions and Connections, and the existence and reception of the service node can be obtained through Publisher and Subscriber , Send the information of the business node of the relationship. For service nodes using the DDS communication protocol stack, domain information and internal domain participant (Domain Participant) information can be collected to obtain communication data of service nodes. For example, Domain can include domain identifier (Domain ID) and its Domain Participant, etc. Information, Domain Participant can include publisher information (Publisher), subscriber information (Subscriber), topic information (Topic), data subscriber information (Data Reader) and data publisher information (Data Writer) and other information. Among them, the message sent and received by the service node can be obtained through Topic, Data Reader, and Data Writer, and the information of the service node that has a receiving and sending relationship with the service node can be obtained through Publisher and Subscriber.

Optionally, in the embodiment of the present application, the communication data of the service node can be obtained by piling key APIs such as the vehicle communication protocol stack, TCP/IP, UDP/IP receiving, sending, and callback processing contained in the communication middleware 221, and There is no need to use the autopilot service code or piling the autopilot service code to obtain the communication data of one or more service nodes.

According to the acquired communication data of multiple service nodes, the receiving and sending relationship between each service node and other service nodes except itself can be determined, so as to determine the associated service nodes and dependencies of each service node. The associated service node of each service node is at least one of the ancestor node of the service node or the descendant node of the service node.

Optionally, after determining the receiving and sending relationship between a service node and other service nodes except itself, the service node and other service nodes can be regarded as nodes in a directed graph, and the sending and receiving relationship between service nodes can be regarded as a slave sending The node points to the directed connection of the receiving node, so as to generate the directed graph of the dependency relationship of the service node according to the receiving and sending relationship, as shown in Fig. 7 .

Fig. 7 is a schematic diagram of a directed graph of dependency relationships of service nodes according to an embodiment of the present application. The directed graph of dependency relationships of service nodes in FIG. 7 is an example of the method in step S410 in FIG. 6 .

Figure 7 includes sensing node N0, sensing node N1, sensing node N2, pre-processing node N3, sensing node N4, fusion node N5, sensing node N6, fusion node N7, fusion node N8, fusion node N9, where N1 The original scheduling algorithm of the node is round robin (RR) with a priority of 10, and the original scheduling algorithms of other nodes are completely fair scheduler (CFS). Taking N5 as the current node to be analyzed, both N2 and N3 send messages to N5, N1 sends messages to N3, N0 sends messages to N1; N5 sends messages to N7 and N8, and N8 sends messages to N9, then N0, N1, N2 , N3 are the ancestor nodes of N5, and N7, N8, and N9 are all descendant nodes of N5, so the associated business nodes of N5 are N0, N1, N2, N3, N7, N8, and N9, and the dependencies of N5 are N2, N3 , N7, N8 and N5 are directed connections.

Optionally, the modeling framework 223 can call the communication middleware 221 through the monitoring module 222 to collect receiving and sending relationships between service nodes and other service nodes, that is, to obtain a complete static sending and receiving relationship between service nodes. For example, for business nodes using the ROS communication protocol stack, the modeling framework 223 can call the ROS node list (rosnode list) to first obtain all node names, and then call the command to view the ROS node information (rosnode info nodename) for each node in turn to obtain the node Detailed information; optionally, all communication topic information can be obtained by calling the rostopic command. It should be understood that a similar method can also be used for DDS, AutoSAR CM, and SOME/IP protocol stacks to actively call APIs to obtain specific information about nodes and message channels.

According to the communication data of the service nodes, the associated service nodes and dependencies of the service nodes can be determined, so as to facilitate the subsequent adjustment of the scheduling strategy of the service nodes, and facilitate the collection of low-noise or no-noise node-level communication logs and thread-level scheduling logs.

S420. Adjust the scheduling policy of the service node and the associated service node, and obtain the adjusted scheduling policy.

According to the associated service nodes and dependencies of the service nodes obtained in step S410, the scheduling policy of each service node and the associated service nodes of each service node can be adjusted to obtain an adjusted scheduling policy.

It should be understood that adjusting the scheduling policy of the service node may include adjusting one or more of the scheduling algorithm, priority, core binding policy, cycle frequency, reserved time slice length, and deadline (deadline) length. Among them, the scheduling algorithm is a resource allocation algorithm stipulated according to the resource allocation strategy of the system, which can include Linux completely fair scheduling or real-time scheduling algorithm; Priority; cycle frequency means that if the service node is running periodically, the scheduling effect can be achieved by adjusting the cycle length of the service node, that is, changing the cycle frequency of the service node; the reserved time slice length means that the system will reserve the operation for the service node Time, which will not be interrupted by other business nodes during the running time, so the scheduling effect can be achieved by adjusting the reserved time slice length; the deadline length is the fixed deadline length assigned to each business node.

It should be understood that the length of the deadline and the priority cannot be adjusted at the same time. In addition, the scheduling algorithm, priority, core binding strategy, cycle frequency, reserved time slice length, and deadline (deadline) length can be adjusted independently or arbitrarily. Adjust any combination.

Optionally, the scheduling policy of each business node and all ancestor nodes of each business node can be adjusted, so that each business node is executed preferentially, and the priority execution order of the ancestor nodes of each business node is based on the distance from the business node Decrease step by step.

It should be understood that the priority execution order of business nodes refers to adjusting the scheduling strategy of business nodes so that the business nodes are executed in order, that is, to determine the business nodes that are executed preferentially, and other business nodes except the business nodes that are preferentially executed the order in which they are executed. For example, by adjusting the priorities of each service node and all ancestor nodes of each service node, each service node has the highest priority, and the priority of each service node's ancestor nodes is gradually increased according to the distance from the service node. The levels are decremented, as shown in Figure 8.

Fig. 8 is a schematic diagram of adjusting a scheduling policy of a service node and a service node associated with the service node according to an embodiment of the present application. FIG. 8 is a schematic diagram of adjusting the scheduling policy of the fusion node N5 and the ancestor nodes of N5 in the directed graph of the dependency relationship of the service nodes shown in FIG. 7 .

Figure 8 includes sensing node N1, sensing node N2, pre-processing node N3, sensing node N4, fusion node N5, sensing node N6, fusion node N7, fusion node N8, fusion node N9, taking N5 as the current to-be-analyzed Nodes, the associated service nodes of N5 are N0, N1, N2, N3, N7, N8, and N9, and the ancestor nodes of N5 are N0, N1, N2, and N3.

After step S420, the scheduling algorithm of N5 is adjusted to a first-come-first-out (FIFO) scheduling algorithm, the priority is adjusted to 99, the scheduling algorithms of the ancestor nodes of N5 are adjusted to RR, and the ancestor nodes of N5 are adjusted to RR. Nodes N2 and N3 adjust the priority to 98, the ancestor node N1 of N5 adjusts the priority to 97, and the ancestor node N0 of N5 adjusts the priority to 96, that is, N5 is set to be executed first, and the ancestor node of N5 is set to be executed first after N5 is executed Execute, and the priority of the ancestor node of N5 is decremented according to the distance from N5. At the same time, the core binding policies of N5 and the ancestor nodes of N5 are all set so that all available cores on the processor 231 can run. After the above adjustments, N5 can be executed first, and the ancestor nodes of N5 can also be executed first, so as to avoid resource competition and interference from other service nodes except N5, and obtain node-level communication of N5 with low or no background noise Logging and thread-level scheduling logging.

Optionally, the scheduling policy of each service node and the parent node of each service node can be adjusted so that each service node is executed first, and the parent node of each service node is executed first after each service node is executed. The parent node of each service node is the first service node that sends a message to the service node.

Optionally, the scheduling policy of each service node and its descendant nodes can be adjusted so that each service node is executed preferentially, and the priority execution sequence of each service node’s descendant nodes is gradually increased according to the distance from the service node. level decrease.

Optionally, the scheduling strategy of each service node and each service node's sub-nodes can be adjusted, so that each service node is executed first, and each service node's sub-nodes are executed first after the execution of the service node.

Optionally, the scheduling strategy of each service node and its ancestor nodes and descendant nodes can be adjusted, so that each service node is executed preferentially, and the priority execution order of each service node's ancestor nodes is based on the The distance of each business node decreases step by step, so that the priority execution order of the descendant nodes of each business node is after the priority execution order of the ancestor node, and decreases step by step according to the distance from the node; or the priority execution order of the descendant nodes of each business node Decrease step by step according to the distance from the node, so that the priority execution order of the ancestor nodes of each business node is after the priority execution order of descendant nodes, and decrease step by step according to the distance from the node; or make the ancestor nodes of each business node The priority execution order of descendant nodes and descendant nodes is gradually reduced according to the distance from the business node, and the priority execution order of ancestor nodes and descendant nodes with the same distance as the business node is the same.

Optionally, the scheduling policy of each service node and its parent node and child nodes can be adjusted so that the service node is executed preferentially, and the parent node of each service node is executed preferentially after the service node is executed, so that each The sub-nodes of each business node are executed first after the execution of the parent node of the business node; Execute first after the node is executed; or make the parent node and child node of each business node execute first after the execution of the business node.

Optionally, the modeling framework 223 can use the scheduler 2242 to adjust the scheduling policies of the service nodes and the service nodes associated with the service nodes.

It should be understood that step S420 can be repeated multiple times, and only adjust the scheduling strategy of one service node and its associated service nodes each time, and at the same time adjust the scheduling policy of the service node and its associated service nodes Before making adjustments, it is necessary to record the scheduling policy of the business node and the business node associated with the business node. After adjusting the business node and the business nodes associated with the business node, it is necessary to restore the The scheduling strategy of the associated service node can continue to adjust the scheduling strategy of the next service node and the associated service node of the next service node, so as not to affect the original state of the autonomous driving service and the next service node and the next The processing of the associated business node of the business node.

By adjusting the scheduling strategy of each service node and the associated service nodes of each service node, the priority execution order of the service nodes and the associated service nodes of the service nodes can be determined, thereby avoiding resource competition and reducing mutual interference caused by the operation of multiple service nodes , to obtain low-noise or no-noise node-level communication logs and thread-level scheduling logs.

S430. Run the automatic driving service according to the adjusted scheduling strategy, collect communication data and scheduling data of service nodes, and obtain node-level communication logs and thread-level scheduling logs.

According to step S420, each service node is processed, that is, the adjusted dispatch strategy of each service node and the associated service node of each service node is obtained, and the automatic driving service is run according to the adjusted dispatch strategy, and the adjusted dispatch strategy is collected. The communication data and scheduling data of the service node in the scheduling policy state, and the node-level communication log and thread-level scheduling log of the service node are obtained. Since the adjusted scheduling strategy avoids resource competition and interference from other service nodes except the service node, the obtained node-level communication logs and thread-level scheduling logs of the service node are logs with low or no background noise , which can support subsequent and accurate establishment of a model for the operation behavior of the service node.

It should be understood that step S420 and step S430 can be combined and repeated multiple times, that is, each time step S420 is performed, only one service node and the scheduling policy of the service node associated with the service node are adjusted, and then step S430 is performed, according to the The adjusted scheduling strategy of the business node and its associated business nodes, run the auto-driving business, collect the communication data and scheduling data of the business node, obtain the node-level communication log and thread-level scheduling log of the business node, and Before step S420, record the scheduling policies of the service node and its associated service nodes, and restore the scheduling policies of the service node and its associated service nodes after step S430. After the combination of steps S420 and S430 is performed once, the combination steps of S420 and S430 are performed again, that is, for the next service node, the scheduling strategy of the next service node and the associated service node of the next service node is adjusted, and then according to the next service node and the adjusted scheduling strategy of the associated service node of the next service node, run the automatic driving service, collect the communication data and scheduling data of the next service node, obtain the node-level communication log and thread-level scheduling log of the next service node, and Before step S420, record the scheduling strategy of the next service node and the associated service nodes of the next service node, and restore the scheduling strategy of the next service node and the associated service nodes of the next service node after step S430. The combination steps of S420 and S430 are repeated for each service node to obtain the node-level communication log and thread-level scheduling log of each service node.

Optionally, the modeling framework 223 can use the communication monitoring module 2221 and the Trace monitoring module 2222 in the monitoring module 222 to collect the node-level communication logs and thread-level scheduling logs of the service nodes from the communication middleware 221 and the tracker 2241 respectively, Recorded in the memory 233 of the self-driving vehicle hardware platform 230.

Fig. 9 is a schematic flowchart of a method for acquiring node-level communication logs and thread-level scheduling logs according to another embodiment of the present application. The method for obtaining node-level communication logs and thread-level scheduling logs in FIG. 9 is an example of the method for obtaining node-level communication logs and thread-level scheduling logs in FIG. 6 . The method for obtaining node-level communication logs and thread-level scheduling logs in Figure 9 includes the following content:

S510, whether each node in the node dependency directed graph has been traversed.

According to the communication data of the service nodes obtained in step S410, the receiving and sending relationship between each service node and other service nodes except itself can be determined, each service node is regarded as a node of a directed graph, and the sending and receiving relationship between service nodes is regarded as a slave The sending node points to the directed connection of the receiving node, so as to generate a directed graph of the dependency relationship of the service node according to the receiving and sending relationship between the service nodes, as shown in Figure 7.

By traversing each node in the dependency directed graph, the node-level communication log and thread-level scheduling log of the currently traversed node are obtained each time, so as to complete the acquisition of the log of each node. When there is still a node that has not obtained the log in the dependency graph, repeat steps S520 to S550 to obtain the node-level communication log and thread-level scheduling log of the node; when all the nodes in the dependency graph have obtained the log, end Log acquisition steps for nodes in a directed graph of dependencies.

Optionally, the method for traversing the directed graph of dependencies may be a graph search method, such as a depth-first search method, or a breadth-first search method, or other traversals that can be traversed to each node in the directed graph of dependencies method.

Optionally, the dependency analysis module 2231 of the modeling framework 223 may traverse the directed graph of dependencies.

S520. Traverse the upstream nodes of the node to be analyzed, and record the current scheduling policies of the node and all its upstream nodes.

When traversing each node in the dependency directed graph, record the current scheduling strategy of the node and all upstream nodes of the node, which can facilitate subsequent restoration of the original scheduling strategy of the node and all upstream nodes of the node, and avoid It can also avoid the impact on the original state of the autonomous driving business. All upstream nodes of this node correspond to all ancestor nodes of this business node, all downstream nodes of this node correspond to all descendant nodes of this business node, and all upstream nodes of this node correspond to all parents of this business node Node, the downstream nodes of this node correspond to all child nodes of this business node.

Optionally, it is possible to traverse the upstream nodes of the node to be analyzed, and record the current scheduling policy of the node and its layer-one upstream nodes; or it is possible to traverse the downstream nodes of the node to be analyzed, and record the current or can traverse the downstream nodes of the node to be analyzed, and record the current scheduling strategy of the node and its downstream nodes; or can traverse the upstream and downstream nodes of the node to be analyzed, and record the node and its nodes The current scheduling strategy of all upstream nodes and all downstream nodes of the node; or it can traverse the upstream nodes and downstream nodes of the node to be analyzed, and record the current scheduling strategy of the node and its layer of upstream nodes and layer of downstream nodes.

Optionally, when traversing the node to be analyzed and one or more of the upstream nodes or downstream nodes of the node to be analyzed, it can be executed by the dependency analysis module 2231 of the modeling framework 223, traversing the node to be analyzed and the upstream nodes of the node to be analyzed or one or more of the downstream nodes can then obtain the scheduling policy and can be recorded in the memory 232 of the hardware platform 230 of the self-driving vehicle.

Optionally, the adjustable scheduling policy may include one or more of scheduling algorithm, scheduling priority, core binding policy, cycle frequency, reserved time slice length, and deadline length.

S530. Adjust the scheduling policies of the node and all upstream nodes of the node in sequence.

For the node to be analyzed, after obtaining the scheduling strategy of this node and all upstream nodes of this node, adjust the scheduling strategy of this node and all upstream nodes of this node, so that this node is executed first, and all upstream nodes of this node are executed first The order decreases step by step according to the distance from the node, as shown in Figure 8.

Optionally, after obtaining the scheduling strategy of the node and its layer-upstream node, adjust the scheduling strategy of the node and the node’s layer-upstream node so that the service node is executed preferentially, and the node’s layer-1 The upstream node is executed first after this node is executed.

Optionally, after obtaining the scheduling policies of the node and all downstream nodes of the node, the scheduling policies of the node and all downstream nodes of the node can be adjusted so that the node is executed preferentially, and the scheduling policies of all downstream nodes of the node are prioritized The execution order decreases step by step according to the distance from the node.

Optionally, after obtaining the scheduling policy of the node and its layer-1 downstream nodes, adjust the scheduling strategy of the node and the node-1-layer downstream nodes so that the node is executed preferentially, and the node’s layer-1 downstream nodes Nodes are executed first after this node is executed.

Optionally, after obtaining the scheduling policies of the node and all upstream nodes and downstream nodes of the node, adjust the scheduling policies of the node and all upstream nodes and downstream nodes of the node, so that the node is executed preferentially, and the node The priority execution order of all upstream nodes of the node decreases step by step according to the distance from the node, so that the priority execution order of all downstream nodes of this node is after the priority execution order of all upstream nodes, and decreases step by step according to the distance from the node; or Make the priority execution order of all downstream nodes of this node decrease step by step according to the distance from this node, make the priority execution order of all upstream nodes of this node after the priority execution order of downstream nodes, and decrease step by step according to the distance from this node ; Or make the priority execution order of all upstream nodes and all downstream nodes of this node decrease step by step according to the distance from this node, so that the priority execution order of upstream nodes and downstream nodes with the same distance from this node are the same.

Optionally, after obtaining the scheduling strategy of the node and its layer of upstream nodes and layer of downstream nodes, adjust the scheduling strategy of the node and its layer of upstream nodes and layer of downstream nodes, so that the node Priority execution, so that the first-level upstream nodes of this node are executed first after the execution of the business node, so that the first-level downstream nodes of this node are executed first after the first-level upstream nodes of this node are executed, or make the first-level downstream nodes of this node Execute first after the node is executed, so that the node's one-level upstream node is executed first after the node's one-level downstream node is executed; or the node's one-level upstream node and one-level downstream node are prioritized after the node is executed implement.

Optionally, adjusting the scheduling policy of the node and one or more of the node's upstream node or the node's downstream node may be executed by the modeling framework 223 through the scheduler 2242 .

S540. Run the automatic driving service according to the adjusted scheduling policy, collect communication data and scheduling data of the node, and obtain a node-level communication log and a thread-level scheduling log of the node.

For the node to be analyzed, obtain the adjusted scheduling strategy of the node and all upstream nodes of the node according to step S530, run the automatic driving service according to the obtained adjusted scheduling strategy, and collect the communication data and scheduling data of the node, thereby Obtain the node-level communication log and thread-level scheduling log of this node. The specific implementation manner of step S540 is the same as that of step S430, and will not be repeated here.

S550. Restoring the scheduling policies of the node and all upstream nodes of the node according to the records.

For the node to be analyzed, according to the scheduling strategy of the node and all upstream nodes of the node recorded in step S520, the scheduling strategy of the node and all upstream nodes of the node is restored, so as to avoid the The scheduling strategy of the upstream node is adjusted, which affects the log acquisition of subsequent nodes and the original state of the automatic driving business.

Optionally, if what is recorded in step S520 is the scheduling strategy of the node and its layer-one upstream node, restore the scheduling strategy of the node and its layer-one upstream node.

Optionally, if the scheduling policies of the node and all downstream nodes of the node are recorded in step S520, the scheduling policies of the node and all downstream nodes of the node are restored.

Optionally, if what is recorded in step S520 is the scheduling strategy of the node and its layer-1 downstream nodes, restore the scheduling strategies of the node and its layer-1 downstream nodes.

Optionally, if the scheduling policies of the node and all upstream nodes and all downstream nodes of the node are recorded in step S520, the scheduling policies of the node and all upstream nodes and all downstream nodes of the node are restored.

Optionally, if what is recorded in step S520 is the scheduling strategy of the node and its layer of upstream nodes and its layer of downstream nodes, then the scheduling strategy of the node and its layer of upstream nodes and its layer of downstream nodes to restore.

Optionally, step S550 may be executed by the modeling framework 223, that is, read the scheduling policy recorded in step S520 from the memory 232, and restore the node and one or more of the upstream node of the node or the downstream node of the node Scheduling strategy, so as not to affect the log acquisition of subsequent nodes and the original state of the automatic driving business.

Fig. 10 is a schematic diagram of an internal structure of a service node provided according to an embodiment of the present application. What is shown in FIG. 10 is the internal callback processing of the service node, including task T1, task T2 and task T3. The internal callback processing of the service node is executed through the process P1. Process P1 includes thread t1, thread t2 and thread t3. Thread t1 is used to execute task T1, thread t2 is used to execute task T2, and thread t3 is used to execute task T3. Among them, the receiving information of thread t1 and thread t2 and the sending information of thread t3 can be obtained through the communication middleware 221, but the information sent by thread t1 and thread t2 to thread t3 belongs to the receiving and sending information of threads included in the service node, and cannot Obtained through the communication middleware 221, that is, the running behavior of the threads included in the service node cannot be obtained through the communication middleware. Therefore, it is necessary to process the node-level communication log and thread-level scheduling log of the service node obtained from the communication middleware 221 to obtain the fusion log, so as to obtain the running behavior of the thread contained in the service node according to the fusion log.

Fig. 11 is a schematic flowchart of a modeling method for a service node of an automatic driving service according to another embodiment of the present application. The modeling approach in Figure 11 includes the following:

S331. Determine at least one time segment according to fusion log entries in the fusion log.

In order to further analyze the running behavior of the threads included in the service node, it is necessary to analyze the information in the obtained fusion log. Each fusion log entry in the fusion log includes time information, type information, identity information and log content, so at least one time segment can be determined according to the time information of the fusion log entry.

As mentioned above, according to the type information in the fusion log entry, the fusion log entries included in the fusion log can be divided into two types. The first type of fusion log entry records scheduling information, and the second type of fusion log entry records Call event. For ease of description, a fusion log entry recording scheduling information may be called a first fusion log entry, and a fusion log entry recording call events may be called a second fusion log entry.

Each time segment in the at least one time segment corresponds to at least two first fusion log entries and at least one second fusion log entry, and the time information of the fusion log entry corresponding to each time segment is within each time segment. Exemplarily, each time segment in at least one time segment includes time information of one or more first fusion log entries in at least two first fusion log entries, and one or more time information in at least one second fusion log entry The time information of the second fusion log entry is within the time range of each time segment. Among the one or more first fusion log entries in the fusion log, the first fusion log entries with the same identity information belong to the scheduling information of the same thread of the service node. Segmenting the time information of at least two first fusion log entries with the same identity information is to segment the time records of the same thread of the service node. Segment the time records of the same thread of the service node to obtain at least one time segment, and each time segment corresponds to a task.

Optionally, at least one time segment may be determined according to the time information and identity information of the first fusion log entry included in the fusion log and the time information and identity information of the second fusion log entry included in the fusion log entry, wherein each time The identity information of the at least two first fusion log entries corresponding to the segment is the same, and the time interval between the two first fusion log entries adjacent in time among the at least two first fusion log entries corresponding to each time segment is less than the segmentation threshold, and each The process number of at least one second fusion log entry corresponding to each time segment is the same as the process number of at least two first fusion log entries corresponding to each time segment. That is, the time records of each thread of the service node are segmented according to the segmentation threshold to obtain at least one time segment, and the time records contained in each time segment belong to the same thread. The split threshold can be the same or different for each thread.

Optionally, the segmentation threshold of each thread is a fixed threshold, which may be an empirical value or a value obtained from a simulation experiment, which is not specifically limited in this embodiment of the present application.

Optionally, an optimization method may be used to optimize the segmentation threshold of each thread, including: determining at least one Refer to time slices. According to the constraints and at least one reference time segment, a segmentation parameter for each reference time segment is determined. The constraint condition is that the time information of one or more second fusion log entries in the at least one second fusion log entry is within the time range of the reference time segment, and the process in the identity information of the one or more second fusion log entries The number is the same as the process number of the identity information of each first fusion log entry included in the reference time segment. Each second fusion log entry can record any one of a receiving event, a sending event, a callback start event or a callback end event. When a callback start event is recorded in the multiple second fusion log entries, a callback end event is also recorded in the multiple second fusion log entries. The initial segmentation threshold is optimized according to an optimization method to obtain the segmentation threshold, and the optimization method includes a heuristic optimization algorithm or a solver optimization method. That is, according to the initial preset threshold value of the m-th thread among the M threads contained in the business node, the time record of the m-th thread is segmented to obtain at least one reference time segment of the m-th thread, m=1, .. ...., M, M is a positive integer greater than or equal to 1. After segmentation, judge whether the initial preset threshold for this segmentation is available according to the constraints, that is, determine whether the time information of one or more second fusion log entries in at least one second fusion log entry of the service node is within the reference time segment within the time range, and the process number in the identity information of the one or more second fusion log entries is the same as the process number in the identity information of each first fusion log entry included in the reference time segment. If so, the initial preset threshold for this split is available. Otherwise, discard the initial preset threshold for this segmentation, select a new initial preset threshold, and re-segment until the initial preset threshold is available. When the initial preset threshold is available, calculate the segmentation parameters of one or more time segments after the m-th thread is segmented. For example, calculate the value of dividing the execution time of each time segment by the running time, and obtain the average value of the segmentation parameters of all time segments of the mth thread. Use an optimization algorithm to optimize the initial segmentation threshold, that is, select a new initial segmentation threshold through an optimization method, and segment the time records of the mth thread according to the new initial segmentation threshold. Repeat the above steps to calculate the average value of the segmentation parameters of the time segments segmented according to the new initial segmentation threshold. When the optimization end condition is met, the optimization process is ended, and the initial segmentation threshold obtained during the optimization process to maximize the average value of the segmentation parameters of one or more time segments of each thread is used as the segmentation threshold. For the time of the mth thread Records are segmented according to the segmentation threshold, and at least one time segment of the mth thread is obtained.

It should be understood that each second fusion log entry may record a receiving event, or may record a sending event, or may record a callback processing event, or may record a receiving event and a sending event, or may record a receiving event event and a callback to handle the event, or you can log a send event and a callback to handle the event, or you can log a receive event, a send event, and a callback to handle the event. A callback processing event includes a callback start event and a callback end event.

Optionally, the method for optimizing the initial segmentation threshold can be a heuristic optimization algorithm or a solver optimization method, and the heuristic optimization algorithm can be a genetic algorithm, an ant colony algorithm, etc., and the optimization end condition can be determined according to a specific optimization method, for example, when optimizing When the method is a genetic algorithm, the optimization end condition may be the number of iterations satisfied, etc., which is not specifically limited in this embodiment.

Optionally, a clustering algorithm can be used to segment the time records of the mth thread, that is, to discretize the time records of the mth thread into time series points per unit time, and the distance between the time series points transformed by the time records is The time records of the mth thread are clustered. When the distance between the two sub-clusters exceeds the preset threshold, the clustering is stopped. When the previously aggregated sub-clusters meet the constraint conditions, the aggregated sub-clusters are used as a time segment to obtain At least one time segment, otherwise re-clustering until the aggregated sub-clusters all meet the constraint condition, the constraint condition is that the time information of one or more second fusion log entries in at least one second fusion log entry of the service node is in Within the time range included in the aggregated subcluster, and the process number in the identity information of the one or more second fusion log entries is the same as the process number of the identity information of each first fusion log entry contained in the aggregated subcluster same number.

For example, a visual schematic diagram of splitting the time records of each thread is shown in FIG. 12 .

In FIG. 12 , _t1 to _t18 are the visual timing points corresponding to the time information of the first fusion log entry with the same identity information in the fusion log, that is, the time records of the same thread. T ₁ to T ₉ in FIG. 12 are visual timing fragments of the actual execution time of the thread. Time slice 1, time slice 2 and time slice 3 in FIG. 12 are the time slices obtained after dividing the time record of the thread in FIG. 12 according to step S331. Wherein, time segment 1 includes time sequence segments T ₁ , T ₂ , T ₃ and T ₄ , that is, time segment 1 includes time sequence points t ₁ to t ₈ . Time segment 2 includes timing segments T ₅ and T ₆ , that is, time segment 2 includes timing points t ₉ to t ₁₂ . Time segment 3 includes timing segments T ₇ , T ₈ and T ₉ , that is, time segment 3 includes timing points t ₁₃ to t ₁₈ .

It should be understood that when splitting is performed according to step S331, if the interval between actual execution times is smaller than the splitting threshold, splitting is not performed. As shown in Figure 12, the difference between t ₂ and t ₃ is smaller than the segmentation threshold, that is, the interval between T ₁ and T ₂ is smaller than the segmentation threshold, so T ₁ and T ₂ are not segmented, that is, T ₁ and T ₂ in the same time slice. If the interval between actual execution times is greater than the split threshold, splitting is performed. As shown in Figure 12, the difference between t ₈ and t ₉ is greater than the segmentation threshold, that is, the interval between T ₄ and T ₅ is greater than the segmentation threshold, so T ₄ and T ₅ are segmented, that is, T ₄ and T ₅ in different time segments.

It should also be understood that, in FIG. 12 , the sum of the times corresponding to timing segments T ₁ to T ₄ is the execution time of time segment 1 of the thread, and the difference between the times corresponding to t ₁ and t ₈ is time segment 1 of the thread running time. The sum of the times corresponding to timing segments T ₁ to T ₉ is the execution time of the thread, and the difference between the times corresponding to t ₁ and t ₁₈ is the running time of the thread.

It should be understood that the numbering and naming of timing points, timing segments, and time segments in FIG. 12 is only for the purpose of identification, and should not be construed as limiting the embodiment of the present application.

It should be understood that step S331 is executed for each of the M threads included in the service node, and at least one segmented time segment of each thread is obtained.

It should be understood that the embodiment of the present application does not specifically limit the time information segmentation method of the fusion log entry, and the time information of the fusion log entry corresponding to the same identity information as the scheduling information in the fusion log can be segmented, and The method of including the time point of one or more second fusion log entries in the at least one second fusion log entry of the service node in the segmented time segment is the method protected by the embodiment of the present application.

S332. Determine N groups of fusion log entry sets according to at least one time segment.

Since each behavior of a business node includes multiple threads, it is necessary to determine N sets of fusion log entry sets according to at least one time segment, wherein each set of fusion log entry sets in the N sets of fusion log entry sets includes at least one fusion log entry set , each fusion log entry set in at least one fusion log entry set includes at least one first fusion log entry and at least one second fusion log entry, and the time information of the second fusion log entry included in each fusion log entry set within the range of the time information of the first fused log entry included in the set of fused log entries.

Optionally, the time segments of each thread in a process among the M threads of the service node obtained in step S331 may be aggregated to obtain at least one cluster, and each cluster in the at least one cluster includes at least one of the time segments or multiple time segments, that is, each cluster in at least one cluster includes at least one time segment of at least one thread.

Optionally, the method of aggregating time slices of M threads may be:

(1) The time segment of each thread is discretized into timing points of unit time, so that the time segment of each thread is converted into one-dimensional lattice data. For example, one of the time segments of the m-th thread among the M threads is a time segment from 2ms to 4ms, convert this time segment into a timing point with a unit time of 0.5ms, and obtain 5 timing points, which are 2ms and 2.5ms respectively , 3ms, 3.4ms, 4ms.

(2) Map the discrete timing points of the time segments of each thread into a two-dimensional space to form a two-dimensional lattice. For example, calculate the number of discrete timing points of each thread, find the thread T _i with the largest number of discrete timing points, and map all the discrete timing points of T _i to the y=0 axis of the two-dimensional plane; then calculate the thread T _j to The distance d _ij of T _i maps the discrete timing points of thread T _j to y=d _ij . The calculation method of d _ij is d _ij ＝D-|<T _i , T _j >|, where i≠j, |<T _i, T _j >| is coincident in the discrete timing points of threads T _i and T _j The number of discrete timing points, D is the empirical value.

(3) According to the clustering algorithm, the data in the two-dimensional lattice is gathered into a large cluster, that is, the points in all the two-dimensional lattice are gradually gathered into a large cluster from bottom to top, so that the cluster presents a tree structure, Clustering is stopped each time when the distance between two sub-clusters is greater than the first threshold or the distance ratio is greater than the second threshold.

It should be understood that both the first threshold and the second threshold are preset thresholds. The distance between two subclusters may be Euclidean distance, Minkowski distance, or Chebyshev distance, etc., which is not specifically limited in this embodiment of the present application. The distance ring ratio when two subclusters are gathered can be the ratio of the threshold when the last subcluster was gathered to the threshold when the subcluster was gathered this time, or it can be based on the threshold when the last subcluster was gathered and the threshold when the subcluster was gathered this time. The values of other functional relationships obtained by the threshold are not specifically limited in this embodiment of the present application.

Optionally, the clustering algorithm may be a hierarchical clustering (Hierarchical Clustering) algorithm, or a clustering algorithm such as a partition method, which is not specifically limited in this embodiment of the present application.

It should be understood that the time records of M threads of the service node may be aggregated into at least one cluster, and the time records contained in each cluster may belong to the same thread or different threads.

Optionally, at least one fusion log entry set may be determined according to the obtained time segment included in each cluster of the at least one cluster. Each fusion log entry set in the at least one fusion log entry set includes at least two first fusion log entries and at least one second fusion log entry. At least one fusion log entry set is in one-to-one correspondence with at least one cluster. The time information of the first fused log entry included in each fused log entry set is located within the time segment included in the corresponding cluster. The time information of the second fusion log entry included in each fusion log entry set is within the range of the time information of the first fusion log entry included in each fusion log entry set.

In some embodiments, at least one fusion log entry set may be determined directly according to the time information of the fusion log entry and the determined at least one time segment, wherein each fusion log entry set includes at least two first fusion log entries and at least one Second fusion log entry.

In some other embodiments, at least one first fusion log entry set may be determined according to the determined at least one time segment, where the at least one first fusion log entry set corresponds to the at least one time segment one by one. The time information of one or more first fusion log entries included in each first fusion log entry set is within a corresponding time segment. According to the determined at least one first fusion log entry set, at least one second fusion log entry set is determined. Wherein at least one second fusion log entry set is in one-to-one correspondence with at least one first fusion log entry set. The time information of one or more second fusion log entries included in each second fusion log entry set is within the time range of the corresponding first fusion log entry set. According to the determined at least one first fusion log entry set and the corresponding at least one second fusion log entry set, at least one fusion log entry set is determined. Wherein, each fusion log entry set includes a first fusion log entry set and a second fusion log entry set, and the time information of one or more second fusion log entries contained in the second fusion log entry set is in the The time range of the first fusion log entry collection.

It should be understood that since at least one time segment of each of the M threads is aggregated, and M is a positive integer greater than or equal to 1, that is, at least one time record of each of the at least one thread is aggregated. Therefore, according to the obtained time segment included in at least one cluster, at least one time record of at least one thread included in each cluster in at least one cluster can be determined, that is, at least one first fusion log entry correspondingly included in each cluster can be determined. It should also be understood that, in step S331, since at least one time segment is determined using one or more second fusion log entries, each time segment in the at least one time segment may correspond to at least two first fusion log entries log entry and at least one second fused log entry. In summary, according to the obtained time segment included in at least one cluster, at least two first fusion log entries and at least one second fusion log entry corresponding to each cluster can be determined. That is, the fusion log entry set corresponding to each cluster can be determined, and each fusion log entry set includes a first fusion log entry set and a second fusion log entry set.

Since the behavior of the business node will run repeatedly during the operation of the autonomous driving business, the time record of a behavior running multiple times will be included in the fusion log.

According to the obtained identity information of each fusion log entry in each fusion log entry set in at least one fusion log entry set, a set of thread numbers corresponding to each fusion log entry set can be obtained. According to the set of thread numbers corresponding to each fusion log entry set, N sets of fusion log entry sets may be determined. The number sets of threads corresponding to each fusion log entry set in the nth group of fusion log entry sets in the N groups are the same. In other words, the nth group of fused log entry sets may contain only one fused log entry set, or may include multiple fused log entry sets with the same set of corresponding thread numbers.

S333. Determine N pieces of behavior information of the service node according to the N sets of merged log entry sets respectively.

According to the N groups of fusion log entry sets obtained in step S332, N behaviors of the service node can be determined. That is, the nth behavior among the N behaviors of the service node corresponds to the nth group of fusion log entry sets in the N groups. In other words, the nth behavior among the N behaviors of the business node may only correspond to one fusion log entry set, or may correspond to multiple fusion log entry sets, and each fusion log entry set in the multiple fusion log entry sets corresponds to The same set of thread numbers. According to the set of Q fusion log entries corresponding to the nth behavior among the N behaviors of the service node, the information of the nth behavior among the N behaviors of the business node can be determined, and Q is a positive integer greater than or equal to 1.

The information of each behavior in the N behaviors of the business node includes: the number of threads contained in each behavior, the running time of each behavior, the average running time of each behavior and the probability of running time, the Execution time, average and probability of execution time for each behavior, execution time for each thread in each behavior, execution time, average and average execution time, names of events in each behavior, The average of the time points of events in a behavior or the probability distribution model of the time points of events. Events in each behavior include receive events in each behavior, send events in each behavior, callback start events in each behavior, and callback end events in each behavior. The time point of the event in each behavior includes an absolute time point of the event or a relative time point of the event.

It should be understood that the following information can be obtained from at least two first fusion log entries contained in the Q fusion log entry set corresponding to the nth behavior: Quantity, running time of the nth behavior, average and probability of running time of the nth behavior, execution time of the nth behavior, average and probability of execution time of the nth behavior, The running time, execution time, average running time, and average execution time of each thread in the nth behavior. Wherein, q=1, . . . , Q. The following information can be obtained through at least one second fusion log entry included in the Q fusion log entry set corresponding to the nth behavior: the set of event names in the nth behavior, the nth A collection of time points for events in a behavior. The time point of the event may be a relative time point or an absolute time point, which is not specifically limited in this embodiment of the present application.

It should also be understood that the name of the event included in the nth behavior may be determined according to the obtained set of names of events in the nth behavior. If the nth behavior runs only once, the time point of the event in the nth behavior can be determined through the set of time points of the events in the nth behavior. If the nth behavior will run repeatedly for many times, the average value or probability distribution model of the time points of the events in the nth behavior can be determined through the set of time points of the events in the nth behavior.

It should also be understood that if the set of event time points records relative time points, the average value of the event relative time points or the probability distribution model of the relative time points can be directly calculated based on the set of event time points. If the set of event time points records absolute time points, after converting the absolute time points in the set into relative time points, calculate the average value of the relative time points of events or the probability distribution model of relative time points.

It should also be understood that since the behavior of a service node is aggregated by threads, each behavior of a service node includes one or more time segments of each thread in one or more threads. The information of the nth behavior can be obtained by making statistics on the time segment information of the threads included in the nth behavior.

It should also be understood that if the nth behavior of the business node will be repeated multiple times, that is, the nth behavior corresponds to multiple fusion log entry sets, then the time in each fusion log entry set corresponding to the nth behavior The information is collected, that is, the information of the time segment of the thread contained in each fusion log entry set is collected, so as to obtain the information of the nth behavior.

Specifically, the number of threads included in the nth behavior is the number of threads to which the time segment included in the behavior belongs. The running time of the mth thread in the nth behavior is: the running time of the time segment belonging to the mth thread contained in the nth behavior, that is, the first fusion log entry that is included in the time segment The difference between the time information of and the time information of the first fusion log entry that ended last. For example, the difference between the times corresponding to _t1 and _t18 shown in FIG. 12 is the running time of the thread. The execution time of the mth thread in the nth behavior is: the execution time of the time segment belonging to the mth thread included in the nth behavior, that is, the sum of all actual execution times in the time segment. The actual execution time is the difference between the time information of the first merged log entry that records the execution of the thread and the execution of the thread that are adjacent to each other in time. For example, the sum of the times corresponding to the timing segments T ₁ to T ₉ shown in FIG. 12 is the execution time of the thread.

The running time of the nth behavior is: the difference between the time information of the first fusion log entry that starts first and the time information of the first fusion log entry that ends in one or more time segments included in the nth behavior . The execution time of the nth behavior is: the average execution time of the threads included in the nth behavior, that is, the sum of the execution times of the threads included in the nth behavior divided by the number of threads included in the nth behavior.

It should also be understood that during the operation of the autonomous driving business, the behavior of the business node will be repeatedly run, and the execution time, running time, and execution time and running time of the thread obtained when the same behavior is repeatedly run may be Inconsistent. Therefore, the average execution time and average running time of the thread can be calculated according to the execution time and multiple running times of multiple threads included in the obtained behavior, that is, the average value of the execution time and the average running time of the thread can be calculated . According to the obtained multiple running times and multiple execution times of the behavior, the average running time, the probability of running time, the average execution time and the probability of execution time of the behavior are calculated. The probability of the behavior's runtime is the probability that each runtime value of the behavior occurs among all the runtime values. The execution time probability of the behavior is the probability that each execution time value of the behavior occurs in all execution time values.

Through step S331 to step S333, the fusion log entry corresponding to the scheduling information and the fusion log entry corresponding to the invocation event in the fusion log are analyzed and processed, and the behavior information of the service node and the running behavior of the thread included in the service node behavior can be obtained and other information, which is convenient for subsequent further processing of the information of the service node and the information of the thread contained in the service node, thereby supporting the establishment of a more accurate operation behavior model for the operation behavior of the service node.

Fig. 13 is a schematic flowchart of a modeling method for a service node of an automatic driving service according to another embodiment of the present application. The modeling method in Figure 13 includes the following:

S610. Monitor whether the directed graph of dependency relationship changes.

According to the dependency relationship of the business nodes obtained in step S410, construct the dependency relationship directed graph of the business node, and monitor whether the dependency relationship directed graph changes, that is, monitor the positions or positions of any one or more nodes in the dependency relationship directed graph Whether the number of nodes has changed. If there is a change, go to step S620; if not, go to step S630.

Optionally, when monitoring whether the directed graph of dependencies changes, a search algorithm can be used to find the longest path in the directed graph of node dependencies as the critical path for monitoring, and monitor whether the nodes in the critical path change, or monitor Whether the directed graph or longest path of dependencies changes.

Optionally, a maximum spanning tree algorithm, a dynamic programming algorithm, or a topological sorting algorithm may be used to find the longest path in the directed dependency graph.

Optionally, it is possible to monitor in real time whether the directed graph of dependencies changes, or to check whether the directed graph of dependencies changes at regular intervals.

Optionally, step S610 may be executed by the monitoring module 222 .

S620. Update the running behavior model of the service node by reacquiring the fusion log.

If the following changes are monitored in step S610, then start to obtain the fusion log of the service node from step S310 again, and update the operating behavior model of the service node through steps S320 and S330 according to the obtained fusion log:

(1) One or more nodes are reduced in the directed graph of dependencies;

(2) One or more nodes are added to the directed graph of dependencies;

(3) The positions of one or more nodes in the dependency directed graph have changed;

(4) The longest path growth in the directed graph of dependencies;

(5) The longest path in the directed graph of dependencies is shortened;

(6) The nodes in the longest path in the dependency directed graph have changed;

(7) The position of one or more nodes that make up the longest path in the directed graph of dependencies has changed.

After the operating behavior model of the service node is updated, continue to execute step S610, construct a new directed graph of dependencies, and monitor whether the new directed graph of dependencies changes.

S630, monitor whether the behavior data change of the service node exceeds a threshold.

After obtaining the operation behavior model of the service node, monitor whether the change of the behavior data of the service node exceeds the threshold value. The behavior data of the service node includes the frequency of receiving messages of the service node, the frequency of sending messages of the service node, and the callback processing time of the service node. delay, the number of processes included in the business node, and the number of threads included in each behavior of at least one behavior of the business node. If the data change exceeds the threshold, go to step S640 to update the behavior data of the operation behavior model of the service node, otherwise go to step S650.

Optionally, while monitoring whether the directed graph of dependency relationship changes according to step S610, it is possible to monitor whether the change of the behavior data of the service node exceeds the threshold, that is, when it is monitored that the directed graph of dependency relationship does not change, continue to monitor the business Whether the change of the node's behavior data exceeds the threshold.

Optionally, when it is monitored that the scheduling policy of the node in the dependency directed graph changes, if the changed scheduling policy of the node causes the behavior data of the node to change, and the change exceeds the threshold, update the service node's behavioral data.

S640. Update the behavior data in the running behavior model of the service node through an algorithm.

In a case where it is monitored that the change of the behavior data of the service node exceeds the threshold, the behavior data in the operation behavior model of the service node is updated through an algorithm. After the behavior data is updated, step S610 is continued to monitor whether the directed graph of dependencies changes.

Optionally, the algorithm for updating the behavior data may be: a moving average algorithm, a simple moving average, a weighted moving average, an autoregressive moving average model algorithm, etc., which are not specifically limited in this embodiment of the present application.

S650, whether it is in self-driving state.

When it is detected that the vehicle is still in the automatic driving mode, repeat steps S610 to S640, and continue to monitor whether the directed graph of dependencies of the service nodes has changed, or whether the behavior data of the service nodes has changed beyond the threshold; In the driving mode, the monitoring of steps S610 to S640 ends.

Optionally, the monitoring action can be performed by the monitoring module 222 .

Fig. 14 is a schematic flowchart of a modeling method for a service node of an automatic driving service according to another embodiment of the present application. The modeling method in Figure 14 includes the following:

S710. According to the communication data of the service nodes, determine the associated service nodes and the dependencies of the service nodes. The specific implementation manner of step S710 is the same as that of step S410, and will not be repeated here.

S720. Adjust the scheduling policy of the service node and the associated service node, and obtain the adjusted scheduling policy. The specific implementation manner of step S720 is the same as that of step S420, and will not be repeated here.

S730. Run the automatic driving service according to the adjusted scheduling strategy, collect communication data and scheduling data of the automatic driving service, and obtain node-level communication logs and thread-level scheduling logs. The specific implementation manner of step S730 is the same as that of step S430 or step S301, and will not be repeated here.

S740, merging the node-level communication log and the thread-level scheduling log to obtain the fused log. The specific implementation manner of step S740 is the same as that of step S302, and will not be repeated here.

S750. Obtain information on N behaviors of service nodes according to the fusion log, where N is a positive integer greater than or equal to 1. The specific implementation manner of step S750 is the same as that of step S320, and will not be repeated here.

S760. Analyze the information on the N behaviors of the service node to obtain an operation behavior model used to describe the operation behavior of the service node. The specific implementation manner of step S760 is the same as that of step S330, and will not be repeated here.

S770. Construct a directed graph of dependency relationships of the service nodes according to the dependency relationships of the service nodes.

According to the communication data of multiple service nodes obtained in step S710, the receiving and sending relationship between each service node and other service nodes except itself can be determined, and the service node and other service nodes except itself can be regarded as nodes of the directed graph , the sending and receiving relationship between service nodes is regarded as a directed connection from the sending node to the receiving node, so that a directed graph of dependency relationships of service nodes can be generated according to the receiving and sending relationship.

S780. Update the behavior data in the operation behavior model of the service node when it is monitored that the change of the behavior data of the service node exceeds the threshold. The specific implementation manner of step S780 is the same as that of step S640, and will not be repeated here.

S790. Re-acquire the fusion log of the service node and update the operation behavior model of the service node when it is monitored that the directed graph of the dependency relationship of the service node has changed. The specific implementation manner of step S790 is the same as that of step S620, and will not be repeated here.

According to the modeling method of the service node of the autonomous driving service provided in the embodiment of the present application, the operation behavior model used to describe the operation behavior of the service node of the automatic driving service can be obtained, and the operation behavior model can provide feedback for designers and developers. To guide the development, it is also possible to calculate the running behavior status of the business nodes of the autonomous driving business on the hardware resources through simulation and other methods, and check whether the running behavior status of the business nodes on the hardware resources meets the design expectations. When the scene is switched or the automatic driving business is updated, the change of the operating behavior model is monitored, so as to re-update the operating behavior model. Therefore, the operating behavior model of the service node in the embodiment of the present application has important value for feedback guidance and auxiliary design. At the same time, the operating behavior model of the service node in the embodiment of the present application can be used as the input for the simulation, simulation and optimization of the subsequent automatic driving business code. Provide high-precision guarantee for the simulation, simulation and optimization of subsequent autonomous driving business codes.

The above describes the modeling method of the service node of the automatic driving service according to the embodiment of the present application. The following describes the modeling device and equipment of the service node of the automatic driving service according to the embodiment of the present application in conjunction with FIG. 15 and FIG. 16 respectively.

The embodiment of the present application also provides a computer storage medium, the computer storage medium stores program instructions, and when the program is executed, it may include the modeling method of the service node of the automatic driving service in the corresponding embodiment as shown in Fig. 3-14 some or all of the steps.

Fig. 15 is a schematic structural diagram of a modeling device for a service node of an automatic driving service according to an embodiment of the present application. The modeling device 800 includes an acquisition module 810 , a processing module 820 and a monitoring module 830 .

The obtaining module 810 is used to obtain the fusion log of the service node of the automatic driving service, and execute step S310 in the method of FIG. 3, the method of FIG. 4, the method of FIG. 6, the method of FIG. Some or all of the steps in S740.

The processing module 820 is used to obtain an operation behavior model for describing the operation behavior of the service node according to the fusion log, and execute steps S320, S330, the method in FIG. 11 , and the method in FIG. 14 in the method of FIG. 3 S750, part or all of the steps in step S760.

The monitoring module 830 is used to monitor whether the directed graph of the dependency relationship of the service node changes or whether the change of the behavior data of the service node exceeds the threshold value, and re-establish the operation behavior model of the service node according to the change of the directed graph of the dependency relationship, or according to the change of the behavior data of the service node Changes in the behavior data update the behavior data in the running behavior model, and execute steps S770 to S790 in the method of FIG. 13 and the method of FIG. 14 .

Fig. 16 is a structural block diagram of an IO device provided according to an embodiment of the present application. The IO device 900 shown in FIG. 16 includes: a processor 901 , a memory 902 and a communication interface 903 , and the processor 901 , the memory 902 and the communication interface 903 communicate through a bus 904 . The receiver 905 is used to receive pending requests from the host, and the sender 906 is used to send the pending requests stored in the memory 902 to another computing device in the computing cluster.

The methods disclosed in the foregoing embodiments of the present invention may be applied to the processor 901 or implemented by the processor 901 . Processor 901 can be a central processing unit (central processing unit, CPU), and can also be other general processors, digital signal processors (digital signal processor, DSP), application specific integrated circuits (application specific integrated circuit, ASIC), on-site Programmable gate array (field programmable gate array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general purpose processor may be a microprocessor or any conventional processor or the like. In the implementation process, each step of the above method may be completed by an integrated logic circuit of hardware in the processor 901 or instructions in the form of software. Various methods, steps and logic block diagrams disclosed in the embodiments of the present invention may be implemented or executed. A general-purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like. The steps of the methods disclosed in the embodiments of the present invention may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. Software modules may be located in memory 902, which may be either volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. Among them, the non-volatile memory can be read-only memory (read-only memory, ROM), programmable read-only memory (programmable ROM, PROM), erasable programmable read-only memory (erasable PROM, EPROM), electrically programmable Erases programmable read-only memory (electrically EPROM, EEPROM) or flash memory. Volatile memory can be random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, many forms of RAM are available such as static random access memory (static RAM, SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (synchronous DRAM, SDRAM), Double data rate synchronous dynamic random access memory (double data date SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous connection dynamic random access memory (synchlink DRAM, SLDRAM) and direct A memory bus random access memory (direct rambus RAM, DR RAM) processor 901 reads instructions in the memory 902, and completes the steps of the above method in combination with its hardware.

The memory 902 may store instructions for executing the method performed by the IO device in the foregoing embodiments. The processor 901 can execute the instructions stored in the memory 902 and combine with other hardware (such as the receiver 905 and the transmitter 906) to complete the steps of the IO device in the above embodiment, and the specific working process and beneficial effects can be described in the above embodiment.

Memory can be volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. Among them, the non-volatile memory can be read-only memory (read-only memory, ROM), programmable read-only memory (programmable ROM, PROM), erasable programmable read-only memory (erasable PROM, EPROM), electrically programmable Erases programmable read-only memory (electrically EPROM, EEPROM) or flash memory. Volatile memory can be random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, many forms of RAM are available such as static random access memory (static RAM, SRAM), dynamic random access memory (dynamic RAM, DRAM), synchronous dynamic random access memory (synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous connection dynamic random access memory (synchlink DRAM, SLDRAM ) and direct memory bus random access memory (direct rambus RAM, DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but not be limited to, these and any other suitable types of memory.

In addition to the data bus, the bus 904 may also include a power bus, a control bus, a status signal bus, and the like. However, for clarity of illustration, the various buses are labeled as bus 904 in the figure.

The embodiment of the present application also provides a chip system, the chip system includes a logic circuit, the logic circuit is used to couple with the input/output interface, and transmit data through the input/output interface, so as to execute the IO device in the above embodiment various steps.

According to the methods provided in the embodiments of the present application, the present application also provides a computer program product, the computer program product including: computer program code, when the computer program code is run on the computer, the computer is made to execute each of the above-mentioned embodiments. step.

According to the methods provided in the embodiments of the present application, the present application also provides a computer-readable medium, the computer-readable medium stores program codes, and when the program codes are run on a computer, the computer is made to execute each of the above-mentioned embodiments. step.

In the implementation process, each step of the above-mentioned method can be completed by an integrated logic circuit of hardware in a processor or an instruction or program code in the form of software. The steps of the methods disclosed in connection with the embodiments of the present application may be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor. The software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register. The storage medium is located in the memory, and the processor reads the information in the memory, and completes the steps of the above method in combination with its hardware. To avoid repetition, no detailed description is given here.

It should be noted that the processor in the embodiment of the present application may be an integrated circuit chip, which has a signal processing capability. In the implementation process, each step of the above-mentioned method embodiments may be implemented by an integrated logic circuit of hardware in a processor or instructions or program codes in the form of software. A general-purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like. The steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register. The storage medium is located in the memory, and the processor reads the information in the memory, and completes the steps of the above method in combination with its hardware.

Embodiments of the present application provide a modeling method, device and equipment for a service node of an automatic driving service. It will be obvious to those skilled in the art that the present application can use other types of self-driving vehicle platforms without limitation, and the embodiments of the present invention can be applied to various types of self-driving vehicle platforms.

Those skilled in the art can appreciate that the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed by hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may use different methods to implement the described functions for each specific application, but such implementation should not be regarded as exceeding the scope of the present application.

Those skilled in the art can clearly understand that for the convenience and brevity of the description, the specific working process of the above-described system, device and unit can refer to the corresponding process in the foregoing method embodiment, which will not be repeated here.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods may be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or May be integrated into another system, or some features may be ignored, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, each unit may exist separately physically, or two or more units may be integrated into one unit.

If the functions described above are realized in the form of software function units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including Several instructions are used to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disc and other media that can store program codes. .

The above is only a specific implementation of the application, but the scope of protection of the application is not limited thereto. Anyone familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the application. Should be covered within the protection scope of this application. Therefore, the protection scope of the present application should be determined by the protection scope of the claims.

Claims

A modeling method for an automatic driving service, comprising:

Obtaining the fusion log of the service node of the automatic driving service, the fusion log is used to record the calling event of the service node and the scheduling information of the thread, and the thread is run by the service node;

Obtain information on N behaviors of the service node according to the fusion log, where N is a positive integer greater than or equal to 1;

The information on the N behaviors of the service node is analyzed to obtain an operation behavior model for describing the operation behavior of the service node.
The method according to claim 1, wherein said obtaining the fusion log of the service node of the automatic driving service comprises:

Obtaining a node-level communication log and a thread-level scheduling log of the service node, the node-level communication log is used to record the invocation event of the service node, and the thread-level scheduling log is used to record the scheduling information of the thread;

Fusing the node-level communication log and the thread-level scheduling log to obtain a fusion log, where each fusion log entry in the fusion log corresponds to a communication log entry in the node-level communication log or the thread One scheduling log entry in the level scheduling log, each of the at least two fusion log entries is used to record the content of the corresponding log entry.
The method according to claim 2, wherein the obtaining the node-level communication log and the thread-level scheduling log of the service node comprises:

According to the communication data of the service node, determine the associated service node and the dependency relationship of the service node, the associated service node includes at least one of the ancestor node of the service node or the descendant node of the service node;

Adjusting the scheduling strategy of the service node and the associated service node to obtain the adjusted scheduling strategy;

Running the automatic driving service according to the adjusted scheduling policy, collecting communication data and scheduling data of the service node, and obtaining the node-level communication log and the thread-level scheduling log.
The method according to any one of claims 1 to 3, wherein the obtaining information on the N behaviors of the service node according to the fusion log includes:

According to the fusion log entry in the fusion log, at least one time segment is determined, wherein each time segment in the at least one time segment corresponds to at least two first fusion log entries and at least one second fusion log entry, so The first fusion log entry is a fusion log entry corresponding to the scheduling information in the fusion log, the second fusion log entry is a fusion log entry corresponding to the call event in the fusion log, and each The time information of the fusion log entry corresponding to each time segment is within each time segment;

According to the at least one time segment, determine N sets of fusion log entry sets, each set of fusion log entry sets in the N sets of fusion log entry sets includes at least one fusion log entry set, and the at least one fusion log entry set Each fusion log entry set includes at least one first fusion log entry and at least one second fusion log entry, and the time information of the second fusion log entry included in each fusion log entry set is included in each fusion log entry set Include within the time information of the first fusion log entry;

Determine N pieces of behavior information of the service node according to the N groups of fusion log entry sets respectively.
The method according to claim 4, wherein said determining at least one time segment according to the fusion log entry in the fusion log comprises:

Determine the at least one time segment according to the time information and identity information of the first fusion log entry included in the fusion log and the time information and identity information of the second fusion log entry included in the fusion log entry, wherein each The identity information of at least two first fusion log entries corresponding to each time segment is the same, and the time interval between the two first fusion log entries adjacent in time among the at least two first fusion log entries corresponding to each time segment is less than The segmentation threshold, the process number of the at least one second fusion log entry corresponding to each time segment is the same as the process number of the at least two first fusion log entries corresponding to each time segment.
The method according to any one of claims 1 to 5, wherein the information on the N behaviors of the service node is analyzed to obtain an operation behavior model for describing the operation behavior of the service node ,include:

Obtain the trigger relationship of the first behavior according to the information of the first behavior and the behavior information of the service node that has a transceiving relationship with the service node, and the first behavior is any of the N behaviors of the service node. In one behavior, the service node that has a sending and receiving relationship with the service node includes: one or more of the service node that sends a message to the service node, or one or more of the service nodes that receive the message sent by the service node;

According to the information of the first behavior and the trigger relationship of the first behavior, obtain the message channel for receiving events corresponding to each behavior that triggers the first behavior, and the running behavior model of the first behavior includes the trigger Each behavior of the first behavior corresponds to a message channel for receiving events.
The method according to any one of claims 1 to 5, wherein the information on the N behaviors of the service node is analyzed to obtain an operation behavior model for describing the operation behavior of the service node ,include:

converting the time information of each first fusion log entry contained in one or more first fusion log entry sets corresponding to the first behavior into frequency domain data, the first behavior being the N behaviors of the service node Any one of the behaviors, the first fusion log entry is a fusion log entry corresponding to the scheduling information in the fusion log;

determining whether there are one or more frequency values in the frequency domain data that exceed the average value of the frequency domain data;

If so, at least one time-triggered period of the first behavior is determined based on the one or more frequency values exceeding the average value of the frequency domain data, the operating behavior model of the first behavior includes the first Behavior with at least one time-triggered period.
The method according to any one of claims 1 to 5, wherein the information on the N behaviors of the service node is analyzed to obtain an operation behavior model for describing the operation behavior of the service node ,include:

According to the interval of the time information of at least two first fusion log entries contained in one or more first fusion log entry sets corresponding to the first behavior, the time probability model of the operation of the first behavior is obtained, and the first behavior The operation behavior model includes the time probability model of the operation of the first behavior, wherein the first behavior is any one of the N behaviors of the service node, and the first fusion log entry is the A fusion log entry corresponding to the scheduling information.
The method according to any one of claims 1 to 8, further comprising:

In the case of monitoring that the directed graph of dependencies of the service nodes has changed, updating the operation behavior model of the service nodes; or,

In a case where it is monitored that the change of the behavior data of the service node exceeds a threshold, the behavior data in the operation behavior model of the service node is updated.
A computer device, characterized in that it includes:

An acquisition module, configured to obtain a fusion log of a service node of an automatic driving service, where the fusion log is used to record the calling event of the service node and scheduling information of a thread, and the thread is run by the service node;

A processing module, configured to obtain information on N behaviors of the service node according to the fusion log, where N is a positive integer greater than or equal to 1;

The processing module is further configured to analyze information on the N behaviors of the service node, and obtain an operation behavior model for describing the operation behavior of the service node.
The computer device according to claim 10, wherein the obtaining module is specifically configured to obtain a node-level communication log and a thread-level scheduling log of the service node, and the node-level communication log is used to record the service An invocation event of a node, the thread-level scheduling log is used to record the scheduling information of the thread;

The acquiring module is further configured to fuse the node-level communication log and the thread-level scheduling log to obtain a fusion log, and each fusion log entry in the fusion log corresponds to an entry in the node-level communication log A communication log entry or a scheduling log entry in the thread-level scheduling log, each of the at least two fusion log entries is used to record the content of the corresponding log entry.
The computer device according to claim 11, wherein the acquisition module is specifically configured to determine the associated service nodes and dependencies of the service nodes according to the communication data of the service nodes, and the associated service nodes include At least one of the ancestor node of the service node or the descendant node of the service node;

The obtaining module is further configured to adjust the scheduling strategy of the service node and the associated service node, and obtain the adjusted scheduling strategy;

The acquiring module is further configured to run the automatic driving service according to the adjusted scheduling strategy, collect communication data and scheduling data of the service node, and obtain the node-level communication log and the thread-level scheduling log.
The computer device according to any one of claims 10 to 12, wherein the processing module is specifically configured to determine at least one time segment according to fusion log entries in the fusion log, wherein the at least one Each time segment in the time segment corresponds to at least two first fusion log entries and at least one second fusion log entry, and the first fusion log entry is a fusion log entry corresponding to the scheduling information in the fusion log , the second fusion log entry is a fusion log entry corresponding to the call event in the fusion log, and the time information of the fusion log entry corresponding to each time segment is within each time segment;

The processing module is specifically configured to determine N sets of fusion log entry sets according to the at least one time segment, each set of fusion log entry sets in the N sets of fusion log entry sets includes at least one fusion log entry set, the Each fusion log entry set in at least one fusion log entry set includes at least one first fusion log entry and at least one second fusion log entry, and the time information of the second fusion log entry included in each fusion log entry set is at Within the range of the time information of the first fusion log entry included in each collection of fusion log entries;

The processing module is specifically configured to determine information on N behaviors of the service node according to the N sets of fusion day entry sets respectively.
The computer device according to claim 13, wherein the processing module is specifically configured to combine the time information and identity information of the first fusion log entry included in the fusion log with the second fusion log entry included in the fusion log. Fusing the time information and identity information of log entries to determine the at least one time segment, wherein the identity information of at least two first fusion log entries corresponding to each time segment is the same, and at least two of the first fusion log entries corresponding to each time segment The time interval between two first fusion log entries adjacent in time among the first fusion log entries is less than the segmentation threshold, and the process number of at least one second fusion log entry corresponding to each time segment is the same as the process number of each time segment The process IDs of at least two corresponding first fusion log entries are the same.
The computer device according to any one of claims 10 to 14, wherein the processing module is specifically configured to use the first behavior information and the behavior information of the service node that has a transceiving relationship with the service node , to obtain the trigger relationship of the first behavior, the first behavior is any one of the N behaviors of the service node, and the service node that has a sending and receiving relationship with the service node includes: sending to the service node A service node sending a message from a node, or one or more of service nodes receiving a message sent by the service node;

The processing module is specifically configured to obtain, according to the information of the first behavior and the trigger relationship of the first behavior, a message channel for receiving an event corresponding to each behavior that triggers the first behavior, and the first behavior The running behavior model includes a message channel for receiving events corresponding to each behavior that triggers the first behavior.
The computer device according to any one of claims 10 to 14, wherein the processing module is specifically configured to convert each entry contained in the one or more first fusion log entry sets corresponding to the first line to The time information of a fusion log entry is converted into frequency domain data, the first behavior is any one of the N behaviors of the service node, and the first fusion log entry is corresponding to the Fusion log entries for scheduling information;

The processing module is specifically configured to determine whether there are one or more frequency values exceeding the average value of the frequency domain data in the frequency domain data, and if so, according to the one or more frequency values exceeding the average value of the frequency domain data The frequency value of the average value of the first behavior determines at least one time-triggered period of the first behavior, and the running behavior model of the first behavior includes at least one time-triggered period of the first behavior.
The computer device according to any one of claims 10 to 14, wherein the processing module is specifically configured to include at least two entries contained in one or more first fusion log entry sets corresponding to the first behavior. The interval of the time information of the first fusion log entry to obtain the time probability model of the operation of the first behavior, the operation behavior model of the first behavior includes the time probability model of the first behavior, wherein the first behavior is For any one of the N behaviors of the service node, the first fusion log entry is a fusion log entry corresponding to the scheduling information in the fusion log.
The computer device according to any one of claims 10 to 17, characterized in that the computer device further comprises: a monitoring module, specifically configured to monitor changes in the directed graph of dependencies of the service nodes In the case of , update the operating behavior model of the service node; or,

The monitoring module is specifically configured to update the behavior data in the operation behavior model of the service node when it is monitored that the change of the behavior data of the service node exceeds a threshold.
A computer device, characterized in that it comprises: a processor, configured to be coupled to a memory, to read and execute instructions and/or program codes in the memory, so as to perform any one of claims 1-9 method described in the item.
A system on a chip, characterized in that it includes: a logic circuit, the logic circuit is used to couple with an input/output interface, and transmit data through the input/output interface, so as to perform the operation described in any one of claims 1-9. described method.
A computer-readable medium, characterized in that the computer-readable medium stores program codes, and when the computer program codes run on a computer, the computer executes the method described in any one of claims 1-9. method.