Data scheduling method and device, equipment and medium

Abstract

The invention discloses a data scheduling method, comprising: receiving a data transmission request initiated by a source node, the data transmission request at least comprising a topic identifier of a communication topic and to-be-transmitted data; querying a pre-configured data flow topological graph according to the topic identifier, and determining a data transmission channel associated with the topic identifier; wherein the data flow topological graph is generated based on a graph model, nodes in the graph model correspond to function modules of the cockpit system, edges represent data dependency relationships among the nodes, and each edge is bound with a topic identifier; and transmitting the to-be-transmitted data from a source node to a target node based on a data transmission channel. According to the method, the graph theory thought is adopted, the modules in the system are abstracted into the nodes, the data flow direction between the modules is abstracted into the edges between the nodes, the data transmission channel can be dynamically determined through the data flow topological graph of the graph model, data transmission is carried out, the flexibility and configurability of data scheduling are improved, the system maintenance cost is reduced, and the data transmission efficiency is improved. And the method adapts to rapid iteration requirements.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a data scheduling method, apparatus, device, and medium. Background Technology

[0002] In the field of intelligent cockpits, middleware technologies are exhibiting a diversified development pattern. Among them, ROS (Robot Operating System) and ROS2, with their flexible communication mechanisms and rich functional ecosystems, have expanded from the robotics field to autonomous driving scenarios, commonly used for sensor data acquisition, processing, and inter-module communication. The CyberRT real-time computing framework used in the Baidu Apollo platform addresses the low latency and high real-time performance requirements of autonomous driving by improving system performance through shared memory communication and efficient task scheduling. Furthermore, AutoSar CP (Automotive Open System Architecture Classic Platform), as a widely followed standard in the automotive electronics field, provides a unified specification framework for communication between electronic control units and software components.

[0003] Currently, the aforementioned middleware generally adopts a point-to-point hard-coded model for data transmission between modules. This means that the transmission relationship between the data source and the data target is fixed in code during the system development phase. When system requirements change, such as adjusting the data flow to direct data from a specific module to a new target module, or inserting a new processing module into the existing data transmission link, the hard-coded communication logic in the source code of the relevant modules must be modified, followed by recompiling and redeploying the entire system. This approach not only significantly extends the development cycle and increases maintenance costs, but also, due to the rigid constraints of the hard-coded logic, makes the system difficult to adapt to the rapidly iterating development environment of smart cockpits. Summary of the Invention

[0004] In view of the shortcomings of the prior art described above, this application provides a data scheduling method, apparatus, device and medium to solve the above technical problems.

[0005] This application provides a data scheduling method, including: Receive a data transmission request initiated by the source node, the data transmission request including at least a topic identifier of the communication topic and data to be transmitted; Based on the topic identifier, a pre-configured data flow topology graph is queried to determine the data transmission channel associated with the topic identifier; wherein, the data flow topology graph is generated based on a graph model, the nodes in the graph model correspond to the functional modules of the cockpit system, the edges represent the data dependencies between nodes, and each edge is bound to a topic identifier; Based on the data transmission channel, the data to be transmitted is transmitted from the source node to the target node to complete data scheduling.

[0006] This application addresses, to some extent, the lack of system flexibility caused by hard-coded data transmission relationships in traditional intelligent cockpit systems through a dynamic query mechanism based on a graph model-based data flow topology graph and topic identifiers.

[0007] In one embodiment of this application, transmitting the data to be transmitted from the source node to the target node includes: Based on the topic identifier carried in the data transmission request, query the predefined mapping relationship or determine the corresponding target middleware and target middleware adapter class according to the platform operating environment; The target middleware adapter class adapts the data to be transmitted to the target middleware, and the data transmission is completed based on the target middleware.

[0008] This application addresses the lack of flexibility in data transmission to some extent by dynamically determining the target middleware and its adapter classes.

[0009] In one embodiment of this application, adapting the data to be transmitted to the target middleware through the target middleware adapter class and completing the data transmission based on the target middleware includes: The data transmission request is routed to the target middleware adapter class that inherits from the middleware abstract interface by calling the predefined middleware abstract interface in the middleware layer. The target middleware adapter class calls the target middleware's native communication interface to complete the data transmission from the source node to the target node.

[0010] This application effectively decouples upper-layer application logic from lower-layer specific middleware through a predefined middleware abstract interface and target middleware adapter class. This eliminates the need for applications to concern themselves with the communication details of different middleware, thereby simplifying system design and maintenance. Furthermore, by directly utilizing the target middleware's native communication interface, data transmission can fully leverage the middleware's performance advantages, ensuring efficient and reliable data transmission.

[0011] In one embodiment of this application, transmitting the data to be transmitted from the source node to the target node based on the data transmission channel includes: The target node corresponding to the data transmission channel subscribes to the communication topic, and uses the data processing logic of the target node as the callback function of the subscription, so as to activate the data transmission channel as a data transmission path from the source node to the corresponding target node; Based on the data transmission path, the data to be transmitted is transmitted from the source node to the target node.

[0012] This application enables the dynamic activation of pre-configured data transmission channels into data transmission paths from the source node to the corresponding target node. This approach, to some extent, solves the problems of inflexible and difficult-to-dynamically adjust data transmission paths in the traditional hard-coded mode.

[0013] In one embodiment of this application, the method for establishing the graph model includes: Create a graph data structure; The functional modules of the cockpit system are abstracted as nodes and registered to the graph data structure. Create edges connecting the source node and the target node in the graph data structure, and bind a topic identifier to each edge; A graph model is constructed based on the nodes and edges labeled with the topics.

[0014] This application abstracts each functional module as a node and registers them, creates edges connecting the source node and the target node in the graph data structure, and binds a unique topic identifier to each edge, thereby making the data flow topology graph highly flexible and configurable.

[0015] In one embodiment of this application, the method further includes: a data recording step and a data playback step; The data recording steps include: Intercepting intermediate data with a uniform format transmitted via middleware; The intermediate data and corresponding metadata are written into a data packet file in chronological order, wherein the metadata includes at least a topic identifier and a timestamp; The data playback step includes: Read and parse the data packet file to obtain the intermediate data and corresponding metadata; Determine the corresponding target middleware adapter based on the type of middleware currently in operation; The intermediate data is converted into the native data format of the target middleware through the target middleware adapter and published according to the topic identifier and the timestamp.

[0016] In this application, during the data recording step, by intercepting data transmitted via middleware that has been converted to a unified intermediate format, and writing it and its corresponding metadata into a data packet file in chronological order, comprehensive, standardized, and persistent recording of the system's internal data flow is achieved. During the data playback step, the target middleware adapter is dynamically determined based on the currently running middleware type, and the unified intermediate format data is converted to the target middleware's native format and published precisely according to the original topic identifier and timestamp.

[0017] In one embodiment of this application, the data scheduling method further includes: The data to be transmitted is classified according to its data structure to obtain a classification result; the data classification result includes: image data, point cloud data, and other structured data. The data to be transmitted is transmitted based on the classification results; If the data classification result includes image data, the image data will be converted into a standardized format data that conforms to the preset communication specifications through a preset format conversion interface for transmission. If the data classification result includes point cloud data, the point cloud data is converted into standardized format data that conforms to the preset communication specifications through a preset format conversion interface for transmission. If the data classification result includes other structured data, then the other structured data will be converted into ordinary structured data, and the ordinary structured data will be serialized into a string format for transmission.

[0018] This application categorizes various types of data into three standard types through unified data classification and format conversion, reducing a large amount of repetitive work in data conversion between different middleware and departments, and lowering development complexity.

[0019] This application provides a data scheduling device, comprising: The request receiving module is used to receive a data transmission request initiated by the source node, wherein the data transmission request includes at least a topic identifier of the communication topic and data to be transmitted; The channel query module is used to query a pre-configured data flow topology graph based on the topic identifier and determine the data transmission channel associated with the topic identifier; wherein, the data flow topology graph is generated based on a graph model, the nodes in the graph model correspond to the functional modules of the cockpit system, the edges represent the data dependencies between nodes, and each edge is bound to a topic identifier; A data transmission module is used to transmit the data to be transmitted from the source node to the target node based on the data transmission channel, thereby completing data scheduling. This application provides an intelligent cockpit, in which the aforementioned data scheduling device is provided.

[0020] This application provides a data scheduling device, the data scheduling device comprising: One or more processors; A memory for storing one or more programs, which, when executed by one or more processors, cause the data processing to implement the steps of the data scheduling method described above.

[0021] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a computer's processor, causes the computer to perform the steps of the above-described data scheduling method.

[0022] The beneficial effects of this application are as follows: A data scheduling method of this application includes: receiving a data transmission request initiated by a source node, the data transmission request including at least a topic identifier of a communication topic and data to be transmitted; querying a pre-configured data flow topology graph according to the topic identifier to determine a data transmission channel associated with the topic identifier; wherein, the data flow topology graph is generated based on a graph model, the nodes in the graph model correspond to the functional modules of the cockpit system, the edges represent the data dependencies between nodes, and each edge is bound to a topic identifier; and transmitting the data to be transmitted from the source node to the target node based on the data transmission channel to complete the data scheduling. This application adopts graph theory, abstracting modules in the system as nodes, and the data flow between modules as edges between nodes. Data transmission channels can be dynamically determined and data transmission performed through the data flow topology graph of the graph model, which has the advantages of improving the flexibility and configurability of data scheduling, reducing system maintenance costs, and adapting to rapid iteration requirements. Moreover, by providing a configuration interface, the data flow direction can be flexibly configured, realizing dynamic adjustment and flexible expansion of data transmission between modules, thus overcoming the limitations of traditional fixed point-to-point data transmission.

[0023] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0024] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1 This is a flowchart illustrating a data scheduling method as an exemplary embodiment of this application; Figure 2 This is a schematic diagram illustrating the implementation environment of a data scheduling method according to an example embodiment of this application; Figure 3 This is a schematic diagram illustrating a process for transmitting the data to be transmitted from the source node to the target node, as shown in an exemplary embodiment of this application. Figure 4 This is a schematic diagram illustrating a process for completing data transmission based on the target middleware, as shown in an exemplary embodiment of this application. Figure 5This is a schematic diagram illustrating the process of transmitting the data to be transmitted from the source node to the target node, as shown in an exemplary embodiment of this application. Figure 6 This is a schematic flowchart illustrating a method for creating a graph model, as shown in an exemplary embodiment of this application. Figure 7 This is a flowchart illustrating a data scheduling method as an exemplary embodiment of this application; Figure 8 This is a schematic diagram of the structure of a data scheduling device shown in an exemplary embodiment of this application; Figure 9 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0025] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0026] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the shape, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0027] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the present application. However, it will be apparent to those skilled in the art that embodiments of the present application may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the present application.

[0028] Please see Figure 1 , Figure 1 This is a flowchart illustrating a data scheduling method as an exemplary embodiment of this application. Figure 1 The data scheduling method includes at least steps S110 to S130, which are described in detail below: Step S110: Receive a data transmission request initiated by the source node. The data transmission request includes at least a topic identifier of the communication topic and the data to be transmitted. Among them, a data transmission request can be an instruction issued by the source node to the data scheduling system, requesting the transmission of specific data to the target node.

[0029] In this system, the source node can be the initiator of data transmission, possessing a unique ID (Identity Document) and an output port. It is responsible for sending data, initiating data transmission requests, and providing the data to be transmitted. The source node can be any functional module within the cockpit system, such as a sensor data acquisition module or a user interface input module. The target node can be the receiver of data transmission, possessing a unique ID and an input port. It is responsible for receiving and processing data from the source node. It can also be any functional module within the cockpit system, such as a data display module or a control execution module.

[0030] The topic identifier is a unique identifier for a communication topic, which can be used to distinguish different types of data streams.

[0031] For example, a data transmission request initiated by a source node is received. This data transmission request includes at least a topic identifier for the communication topic and the data to be transmitted. For instance, the source node could be an image acquisition module, whose data transmission request includes a topic identifier representing "forward-facing camera image" and the actual image data.

[0032] Step S120: Based on the topic identifier, query the pre-configured data flow topology graph to determine the data transmission channel associated with the topic identifier; wherein, the data flow topology graph is generated based on a graph model, the nodes in the graph model correspond to the functional modules of the cockpit system, the edges represent the data dependencies between nodes, and each edge is bound to a topic identifier; The data flow topology graph is constructed based on a graph model, where nodes represent the various functional modules of the cockpit system, and edges represent the data dependencies between these modules. Each edge is bound to a topic identifier to specify the data type it carries.

[0033] The functional modules of the cockpit system can be software or hardware units that perform specific functions in the intelligent cockpit system, including algorithm modules, sensor modules and actuator modules, which can be used to implement specific business functions, such as voice recognition, environmental perception, human-computer interaction, etc.

[0034] Data dependency can be the data supply and consumption relationship between two functional modules, defined by the edge between the source node's output port and the target node's input port.

[0035] For example, based on the received topic identifier, a pre-configured data flow topology graph is queried to determine the data transmission channel associated with that topic identifier. The data flow topology graph is generated based on a graph model, where nodes in the graph model correspond to functional modules of the cockpit system, edges represent data dependencies between nodes, and each edge is bound to a topic identifier. For instance, when the topic identifier "forward-facing camera image" is received, the system searches the data flow topology graph for all edges bound to that topic identifier and constructs paths from the source node to all relevant target nodes along these edges, forming a data transmission channel.

[0036] Step S130: Based on the data transmission channel, the data to be transmitted is transmitted from the source node to the target node to complete the data scheduling.

[0037] For example, once a data transmission channel is determined, the system will guide the data to be transmitted from the source node to one or more target nodes according to the path indicated by the channel.

[0038] This application addresses, to some extent, the lack of system flexibility caused by hard-coded data transmission relationships in traditional intelligent cockpit systems through a dynamic query mechanism based on a graph model-based data flow topology graph and topic identifiers. This method allows data transmission channels to be dynamically determined according to actual needs without modifying the underlying code or redeploying the system, thus significantly improving the intelligent cockpit system's ability to adapt to rapidly changing requirements and reducing the complexity of system maintenance and upgrades.

[0039] In one embodiment, this application can use a visual configuration tool or a structured configuration file to define a data flow topology without coding: Visual configuration tool: Provides a graphical user interface that allows users to intuitively design data flow topology by dragging and dropping node icons representing functional modules and drawing connecting lines between nodes. All graphical operations automatically generate standardized, machine-readable configuration files.

[0040] Structured configuration file: Provides text configuration files based on formats such as JSON or XML. Users can edit this file to declare node sets, node attributes, and connections between nodes (including source nodes, target nodes, and associated communication topic identifiers) in a structured syntax.

[0041] Through the above interfaces, users can build and modify complex data flow topologies without writing or modifying the core business code of the system.

[0042] In one embodiment, this application also provides a graph structure parser, which can parse configuration files and generate executable data flow topologies, automatically establishing data transmission channels between nodes. The parser supports dynamic updates; when the configuration file is modified, the changes take effect without restarting the system, enabling real-time adjustment of the data flow.

[0043] Figure 2 This is a schematic diagram illustrating an implementation environment for a data scheduling method according to an exemplary embodiment of this application. Please refer to... Figure 2 The implementation environment includes, from bottom to top, a hardware platform layer, a cross-platform cockpit middleware layer, and an application layer, along with cross-platform recording and playback tools, forming a complete system closed loop.

[0044] Hardware Platform Layer: As the physical foundation of the system, this layer supports a variety of mainstream hardware devices, including but not limited to industrial personal computers (IPCs) and automotive chip platforms such as the Qualcomm 8155. This layer provides a unified hardware resource interface for the upper layers, including central processing units (CPUs), memory, graphics processing units (GPUs), sensor interfaces, etc., ensuring that the middleware system can run stably in different hardware environments.

[0045] Middleware Layer: Located at the core of the architecture, this layer is crucial for achieving cross-platform compatibility, data unification, and flexible configuration. It integrates the core capabilities of mainstream middleware such as ROS, ROS2, CyberRT, and AutoSar CP. Through encapsulation and adaptation, it shields the technical differences of underlying middleware, providing a unified API (Application Programming Interface) to the upper layers. Its core functions include data format conversion and standardization, graph-based data flow configuration and management, and cross-platform communication scheduling, ensuring seamless data flow between different middleware layers.

[0046] Application Layer: This layer contains various algorithms and application modules for the smart cockpit, such as Around View Monitor (AVM), Driver Monitoring System (DMS), voice interaction, and environmental perception. These application modules achieve data transmission and reception and functional collaboration by calling the unified interface provided by the middleware system layer, without needing to concern themselves with the specific implementation of the underlying middleware.

[0047] Cross-platform recording and playback tool: As a supporting component of the system, it is deeply integrated with the middleware layer and supports unified recording (recording) and playback (playback) of all data flowing through the middleware (including POD (Plain Old Data) data, image data, and point cloud data). It is not limited by the type of underlying middleware and provides support for system testing, debugging, and data reproduction.

[0048] In the above implementation environment, the source node in the application layer calls the middleware abstraction interface provided by the middleware layer to submit a data transmission request (including topic identifiers and data) to the middleware layer. The middleware layer then parses the data flow topology graph based on the graph model. It queries using the topic identifier as the key to find all edges bound to that topic identifier, thereby determining the data transmission channel—that is, the path from the source node to which target nodes. Finally, based on the current system configuration, it selects the corresponding middleware adapter to convert the uniformly formatted data into the native format of the target middleware and completes the transmission through the underlying communication mechanism (such as ROS Topic or CyberRT Channel).

[0049] Please see Figure 3 , Figure 3 This is a schematic diagram illustrating a process for transmitting the data to be transmitted from the source node to the target node, as shown in an exemplary embodiment of this application. Figure 3 In this process, transmitting the data to be transmitted from the source node to the target node includes at least steps S310 to S320, which are detailed below: Step S310: Based on the topic identifier carried in the data transmission request, query the predefined mapping relationship or determine the corresponding target middleware and target middleware adapter class according to the platform operating environment; For example, the system can maintain a configuration table that records the mapping relationship between topic identifiers and middleware and middleware adapter classes. When a data transmission request is received, the system queries the configuration table based on the topic identifier carried in the request to obtain the target middleware and its corresponding adapter class, i.e., the target middleware adapter class. This approach provides high configurability, allowing adjustments to the middleware selection strategy without modifying the code. Furthermore, the system can dynamically evaluate and select the most suitable middleware and middleware adapter class based on the current platform operating environment, such as system load, network conditions, deployed hardware platform type, or real-time requirements. For example, the CyberRT adapter class can be selected on the Apollo platform, while the AutoSar CP adapter class can be selected on a traditional automotive platform.

[0050] Step S320: Adapt the data to be transmitted to the target middleware through the target middleware adapter class, and complete the data transmission based on the target middleware.

[0051] For example, the target middleware adapter class encapsulates the native communication interface and data format conversion logic of the specific middleware. When it receives data to be transmitted, the target middleware adapter class first converts it from a unified internal data format to the specific data format required by the target middleware. After the conversion is complete, the adapter calls the native interface provided by the target middleware, such as the publish / subscribe interface or send / receive function, to complete the publication or transmission of data, thereby realizing the transmission of data from the source node to the target node.

[0052] Please see Figure 4 , Figure 4 This is a schematic diagram illustrating a process for completing data transmission based on the target middleware, as shown in an exemplary embodiment of this application. Figure 4 In this process, the data transmission based on the target middleware includes at least steps S410 to S420, which are described in detail below: Step S410: Invoke the predefined middleware abstract interface in the middleware layer to route the data transmission request to the target middleware adapter class that inherits from the middleware abstract interface; The middleware abstract interface can be a set of data communication methods, independent of specific middleware implementations, used to unify the way upper-layer modules call data transmission services. Specifically, it can be an abstract base class containing pure virtual function declarations. The middleware abstract interface provides a unified service to upper-layer applications, independent of specific middleware platforms.

[0053] The middleware adapter class can be a concrete implementation class that inherits from the middleware abstract interface. It encapsulates the calling logic for a specific middleware's native interface and can be used to convert general communication requests into calling instructions that the specific middleware can recognize. Each middleware adapter class corresponds to a middleware (such as ROS, ROS2, CyberRT, AutoSar, etc.) and internally encapsulates the middleware's native communication interface and initialization logic.

[0054] Step S420: The target middleware's native communication interface is called through the target middleware adapter class to complete the data transmission from the source node to the target node.

[0055] The target middleware is one of several middleware options, selectable by the user. The native communication interface is the low-level communication interface provided by the middleware itself, which encapsulates low-level communication functions.

[0056] For example, application modules in the application layer call the middleware abstract interface, which acts as a unified access point in the system architecture, and initiate data processing requests by calling methods declared in the middleware abstract interface. The data processing request is routed to the corresponding middleware adapter class based on preset configuration information (such as the target middleware type and hardware platform identifier). The middleware adapter class calls the native interface of the encapsulated target middleware to send the data, which has been converted to a middleware-specific format, and transmits the data to be transmitted to the hardware core through the middleware.

[0057] This application encapsulates the differences between middleware within a middleware adapter class through a middleware abstraction interface. Upper-layer applications only need to program to a unified interface without needing to be aware of changes in the underlying middleware type or hardware platform. This greatly reduces system coupling and development complexity, ensuring that the middleware functions and performs consistently across platforms, thereby improving the overall stability and consistency of the system.

[0058] Please see Figure 5 , Figure 5 This is a schematic diagram illustrating a process for transmitting data to be transmitted from a source node to a target node, as shown in an exemplary embodiment of this application. Figure 5 In this process, transmitting the data to be transmitted from the source node to the target node includes at least steps S510 to S520, which are detailed below: Step S510: Subscribe to the communication topic for the target node corresponding to the data transmission channel, and use the data processing logic of the target node as the subscription callback function to activate the data transmission channel as a data transmission path from the source node to the corresponding target node.

[0059] For example, by subscribing to a communication topic, the target node proactively informs the system that it needs to receive data related to that topic, thus breaking free from the limitations of traditional point-to-point hard-coding and enabling dynamic configuration of data flow. Simultaneously, the target node's data processing logic is used as a callback function for the subscription. A callback function is a predefined program segment that the system automatically calls when a specific event (such as receiving subscribed data) occurs. Encapsulating the target node's data processing logic as a callback function ensures that data can be processed immediately and automatically once it arrives, without requiring the target node to actively poll or wait for external triggers.

[0060] Step S520: Based on the data transmission path, transmit the data to be transmitted from the source node to the target node.

[0061] For example, once the data transmission path is successfully activated, the source node can use this path to publish the data to be transmitted. The middleware is responsible for efficiently and reliably routing the data from the source node to all target nodes that have subscribed to the topic, based on the established subscription relationships, and triggering their pre-defined callback functions for processing.

[0062] This application enables the dynamic activation of pre-configured data transmission channels into data transmission paths from the source node to the corresponding target node. This approach, to some extent, solves the problems of inflexible and difficult-to-dynamically adjust data transmission paths in the traditional hard-coded mode.

[0063] Please see Figure 6 , Figure 6 This is a schematic flowchart illustrating a method for creating a graph model, as shown in an exemplary embodiment of this application. Figure 6 The method for establishing this graphical model includes at least steps S610 to S640, which are detailed below: Step S610: Create a graph data structure; For example, graph data structures serve as the underlying framework for carrying the entire data flow topology graph, used to efficiently store and manage nodes and edges in the graph.

[0064] Step S620: Abstract each functional module of the cockpit system into nodes and register them to the graph data structure; For example, a cockpit system typically comprises multiple independent functional modules, such as sensor data acquisition modules, image processing modules, navigation modules, and human-machine interaction modules. Abstracting these functional modules as nodes in a graph means creating a unique identifier for each module in the graph data structure, and associating it with metadata such as its name, type, and functional description. For instance, this can be achieved by assigning a unique node ID to each functional module and storing its associated attributes in the graph data structure.

[0065] Step S630: Create an edge connecting the source node and the target node in the graph data structure, and bind a topic identifier to each edge; For example, edges represent data dependencies between functional modules of the cockpit system. The source node is the data sender, and the target node is the data receiver. Binding a topic identifier to each edge clarifies the data type and semantics carried along that data transmission path. In specific implementations, when creating an edge, in addition to specifying the IDs of the source and target nodes, a string-type topic identifier can be associated with the edge and stored as an attribute of the edge; alternatively, an edge object can be constructed containing attributes such as source node ID, target node ID, topic identifier (transmitted data type (POD / image / point cloud)), and QoS (quality of service, such as transmission rate and reliability), and added to the edge set of the graph data structure.

[0066] Step S640: Construct a graph model based on nodes and edges with topic labels.

[0067] For example, in this step, all the abstracted and defined nodes and edges are integrated to form a complete and logically clear data flow topology graph. By traversing the registered functional module nodes and the created edges with topic identifiers, the system can construct a comprehensive graph structure that intuitively shows the data flow paths and dependencies within the cockpit system.

[0068] This application provides a clear representation framework for the data flow between complex functional modules of a cockpit system by creating a unified graph data structure. Abstracting each functional module into nodes and registering them simplifies system complexity and makes the data flow representation more intuitive. By creating edges connecting source and target nodes in the graph data structure and binding a unique topic identifier to each edge, data dependencies and data types are clearly defined, thus making the data flow topology graph highly flexible and configurable.

[0069] In one embodiment, the data flow topology graph is managed using Node and Graph classes.

[0070] The Node class serves as an abstract carrier for the algorithm module. Each node contains a unique identifier, node_id, and manages subscription relationships for POD data, image data, and point cloud data through three types of subscriber containers (pod_subscribers, image_subscribers, and pointcloud_subscribers), respectively. Nodes provide publishXxx methods for sending data and subscribeXxx methods for registering callbacks for processing data received, thus implementing a decoupled design of the "publish-subscribe" pattern.

[0071] The Graph class acts as a global manager for nodes and edges. It stores all node instances in the `nodes` container and records the connections between nodes (source node ID, target node ID, and communication topic) in the `edges` container. Its core function is to automatically establish data forwarding links between nodes using the `addEdge` method. When a source node publishes data, it automatically triggers the corresponding publishing operation on the target node, enabling data to be transmitted according to a preset flow.

[0072] When constructing the data flow topology graph, the graph management object is first initialized as the coordination center for the system's global data flow, for example, through std::shared_ptr. <graph>cockpit_graph = std::make_shared <graph>() Create a graph instance, which will serve as the container for all subsequent node and edge configurations. Subsequently, the various functional modules of the system are abstracted into graph nodes and registered in the graph, such as "camera_sensor" for camera sensors and "lidar_sensor" for lidar sensors, "avm_algorithm" for surround view image processing, "dms_algorithm" for driver monitoring algorithm processing and "fusion_algorithm" for data fusion algorithm processing, and "display_controller" for display control. Each node achieves functional mapping and system identification through a unique identifier.

[0073] After node registration is complete, the data flow edges between nodes are defined using the `addEdge` method. Each edge requires specifying three parameters: source node identifier, target node identifier, and communication topic, thus logically establishing a transmission channel from data producer to consumer. For example, image flow edges from the camera sensor to the AVM algorithm (topic: ` / camera / raw_image`), face image flow edges to the DMS algorithm (topic: ` / camera / face_image`), and point cloud flow edges from LiDAR to the fusion algorithm (topic: ` / lidar / point_cloud`) can be configured. Furthermore, feature flow edges (such as ` / avm / feature` from AVM to the fusion algorithm) and result output edges (such as ` / avm / rendered_image` from AVM to the display control module) can be established between algorithms. Simultaneously, the transmission of status information is supported, such as the DMS algorithm sending driver status information to the display module (topic: ` / dms / status`), and the fusion algorithm sending perception results (topic: ` / fusion / result`).

[0074] Once the connections between nodes are established, specific data processing logic needs to be bound to each node. Taking the AVM algorithm node as an example, by obtaining a node instance and calling the subscribeImage method, the node subscribes to the topic of raw images from the camera. In the callback function, processing steps such as distortion correction and image stitching are implemented. After processing is complete, publishImage can be called to publish the results to downstream topics, thus forming a coherent data processing and forwarding chain.

[0075] The system also supports dynamically adjusting the data flow topology at runtime. It can flexibly adapt to changing needs without requiring a restart. For example, a debug node named "debugger_node" can be dynamically added, and an edge (topic / avm / intermediate_result) can be established from the AVM algorithm to this node, enabling the debug node to subscribe to intermediate results and perform operations such as log output, thereby realizing real-time monitoring and diagnosis of the system.

[0076] Please see Figure 7 , Figure 7 This is a flowchart illustrating a data scheduling method as an exemplary embodiment of this application. Figure 7 The data scheduling method includes: a data recording step and a data playback step; Data recording steps include: Step S710: Intercept intermediate data with a uniform format transmitted via middleware; Interception refers to obtaining a copy of data during transmission through middleware without affecting the normal communication process. A unified format is a standardized data representation (a cross-platform compatible binary format) independent of specific middleware types. Its purpose is to eliminate differences in data formats between different middleware, facilitating unified data processing and storage.

[0077] Step S720: Write the intermediate data and corresponding metadata into a data packet file in chronological order, wherein the metadata includes at least a topic identifier and a timestamp; Metadata describes the data, while timestamps record the precise time when the data was generated or intercepted.

[0078] The data playback step includes: Step S730: Read and parse the data packet file to obtain intermediate data and corresponding metadata; Reading refers to loading the contents of a data packet file from the storage medium into memory. Parsing, on the other hand, refers to extracting the binary or text data from the data packet file in a structured manner according to its specific format, separating the data in a unified intermediate format and the corresponding metadata.

[0079] Step S740: Determine the corresponding target middleware adapter based on the type of the currently running middleware.

[0080] For example, during data playback, the system may run in a different middleware environment than when the data was recorded, or the data may need to be played back to a module that supports different middleware. Therefore, it is necessary to dynamically select an adapter that can interact with the middleware based on the current system configuration or the target middleware type specified by the user.

[0081] Step S750: Convert the intermediate data into the target middleware's native data format through the target middleware adapter, and publish it according to the topic identifier and timestamp.

[0082] Publishing by topic identifier means that data will be sent to the data transmission channel associated with that topic identifier so that target nodes subscribed to that topic can receive it. Publishing by timestamp means that during playback, the time interval and order of the original data generation will be simulated as much as possible to ensure that the temporal characteristics of the data stream are preserved during playback.

[0083] For example, since the data packet file stores data in a uniform intermediate format, in order for it to be correctly processed by the target middleware, the intermediate data needs to be converted back to the native data format that the middleware can recognize through the selected target middleware adapter.

[0084] In this application, during the data recording step, data transmitted via middleware and converted to a unified intermediate format is intercepted, and the data, along with its corresponding metadata, is written to a data packet file in chronological order, thereby achieving standardized processing of the internal data stream. During the data playback step, the target middleware adapter is dynamically determined based on the currently running middleware type, and the unified intermediate format data is converted to the target middleware's native format and published precisely according to the original topic identifier and timestamp.

[0085] In one embodiment, the data scheduling method includes: The data to be transmitted is classified according to its data structure to obtain the classification results; the data classification results include: image data, point cloud data, and other structured data. The data to be transmitted is transmitted based on the classification results; If the data classification results include image data, the image data will be converted into a standardized format that conforms to the preset communication specifications through the preset format conversion interface for transmission. If the data classification results include point cloud data, the point cloud data will be converted into standardized format data that conforms to the preset communication specifications through the preset format conversion interface for transmission. If the data classification results include other structured data, then the other structured data will be converted into ordinary structured data, and the ordinary structured data will be serialized into string format for transmission.

[0086] For example, after receiving the data to be transmitted, the system calls a classification function to analyze the data structure and classify the data into one of the following categories: other structured data, image data, or point cloud data. Other structured data can be data other than image data or point cloud data, specifically including control commands, status information, etc.; image data can be RGB (Red, Green, Blue) images or grayscale images captured by a camera; point cloud data can be 3D point clouds captured by a LiDAR or depth camera. Based on the classification result, the system calls the corresponding conversion strategy: if it is other structured data, it converts it to plain old data (POD) and serializes it into a string format (such as JSON); if it is image data, it calls an image conversion interface to convert the image data into an image format supported by the target middleware; if it is point cloud data, it converts the point cloud data into a point cloud format supported by the target middleware, thus completing data standardization processing and preparing for cross-platform transmission.

[0087] For image data, its unified structure uses the cv::Mat matrix from the OpenCV library as the core intermediate representation, and associates it with key metadata such as the image's width, height, pixel encoding format, and timestamp. This definition covers various cockpit images from physical camera capture to virtual interface rendering.

[0088] For POD data, a simple legacy data schema is adopted, constrained to be a scalar data type structure that does not contain pointers or dynamic memory. This type of data needs to be serialized into a string format before transmission to ensure consistent binary layout across different computing environments.

[0089] For point cloud data, its unified structure uses the pcl::PointCloud point set of the point cloud library as the core intermediate representation, containing the three-dimensional coordinates of the points, and can be extended to support attributes such as color and reflection intensity. This definition is compatible with point cloud outputs from various sensors such as LiDAR and millimeter-wave radar.

[0090] This application categorizes various types of data into three standard types through unified data classification and format conversion, reducing a large amount of repetitive work in data conversion between different middleware and departments, and lowering development complexity.

[0091] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0092] Figure 8 This is a block diagram illustrating a data scheduling apparatus as shown in an exemplary embodiment of this application. Figure 8 As shown, this application provides a data scheduling apparatus, which includes: The request receiving module 810 is used to receive a data transmission request initiated by the source node. The data transmission request includes at least a topic identifier of the communication topic and the data to be transmitted. The channel query module 820 is used to query a pre-configured data flow topology graph based on the topic identifier and determine the data transmission channel associated with the topic identifier. The data flow topology graph is generated based on a graph model. The nodes in the graph model correspond to the functional modules of the cockpit system, the edges represent the data dependencies between the nodes, and each edge is bound to a topic identifier. The data transmission module 830 is used to transmit data to be transmitted from the source node to the target node based on the data transmission channel in order to complete data scheduling.

[0093] This application provides an intelligent cockpit, in which the aforementioned data scheduling device is installed.

[0094] Embodiments of this application also provide a data scheduling device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by one or more processors, enable the data scheduling device to implement the data scheduling methods provided in the above embodiments.

[0095] Embodiments of this application also provide an intelligent cockpit, wherein the intelligent cockpit is provided with the data scheduling device provided in the above embodiments.

[0096] Figure 9 A schematic diagram of a computer system suitable for implementing the memory of embodiments of this application is shown. It should be noted that... Figure 9 The computer system with the memory shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0097] like Figure 9 As shown, the computer system 900 includes a Central Processing Unit (CPU) 901, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on a program stored in Read-Only Memory (ROM) 902 or a program loaded from storage into Random Access Memory (RAM) 903. The RAM also stores various programs and data required for system operation. The CPU 901, ROM 902, and RAM 903 are interconnected via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0098] The following components are connected to I / O interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to I / O interface 905 as needed. Removable media 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 910 as needed so that computer programs read from them can be installed into storage section 908 as needed.

[0099] Specifically, according to embodiments of this application, the processes described in the above-described flowchart can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the data scheduling method of the aforementioned embodiments. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium 911. When the computer program is executed by a central processing unit (CPU) 901, it performs various functions defined in the system of this application.

[0100] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM) 903, read-only memory (ROM) 902, erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0101] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in the flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block or combination of blocks in the block diagram or flowchart may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0102] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0103] Another aspect of this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a computer's processor, causes the computer to perform the data scheduling method described above. This computer-readable storage medium may be included in the memory described in the above embodiments, or it may exist independently and not assembled into that memory.

[0104] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the data scheduling methods provided in the various embodiments described above.

[0105] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.< / graph> < / graph>

Claims

1. A data scheduling method, characterized in that, include: Receive a data transmission request initiated by the source node, the data transmission request including at least a topic identifier of the communication topic and data to be transmitted; Based on the topic identifier, a pre-configured data flow topology graph is queried to determine the data transmission channel associated with the topic identifier; wherein, the data flow topology graph is generated based on a graph model, the nodes in the graph model correspond to the functional modules of the cockpit system, the edges represent the data dependencies between nodes, and each edge is bound to a topic identifier; Based on the data transmission channel, the data to be transmitted is transmitted from the source node to the target node to complete data scheduling.

2. The data scheduling method according to claim 1, characterized in that, The step of transmitting the data to be transmitted from the source node to the target node includes: Based on the topic identifier carried in the data transmission request, query the predefined mapping relationship or determine the corresponding target middleware and target middleware adapter class according to the platform operating environment; The target middleware adapter class adapts the data to be transmitted to the target middleware, and the data transmission is completed based on the target middleware.

3. The data scheduling method according to claim 2, characterized in that, The step of adapting the data to be transmitted to the target middleware through the target middleware adapter class and completing the data transmission based on the target middleware includes: The data transmission request is routed to the target middleware adapter class that inherits from the middleware abstract interface by calling the predefined middleware abstract interface in the middleware layer. The target middleware adapter class calls the target middleware's native communication interface to complete the data transmission from the source node to the target node.

4. The data scheduling method according to claim 1, characterized in that, The process of transmitting the data to be transmitted from the source node to the target node based on the data transmission channel includes: The target node corresponding to the data transmission channel subscribes to the communication topic, and uses the data processing logic of the target node as the callback function of the subscription, so as to activate the data transmission channel as a data transmission path from the source node to the corresponding target node; Based on the data transmission path, the data to be transmitted is transmitted from the source node to the target node.

5. The data scheduling method according to claim 1, characterized in that, The method for establishing the graph model includes: Create a graph data structure; The functional modules of the cockpit system are abstracted as nodes and registered to the graph data structure. Create edges connecting the source node and the target node in the graph data structure, and bind a topic identifier to each edge; A graph model is constructed based on the nodes and edges labeled with the topics.

6. The data scheduling method according to claim 3, characterized in that, The method further includes: a data recording step and a data playback step; The data recording steps include: Intercepting intermediate data with a uniform format transmitted via middleware; The intermediate data and corresponding metadata are written into a data packet file in chronological order, wherein the metadata includes at least a topic identifier and a timestamp; The data playback step includes: Read and parse the data packet file to obtain the intermediate data and corresponding metadata; Determine the corresponding target middleware adapter based on the type of middleware currently in operation; The intermediate data is converted into the native data format of the target middleware through the target middleware adapter and published according to the topic identifier and the timestamp.

7. The data scheduling method according to claim 1, characterized in that, The data scheduling method further includes: The data to be transmitted is classified according to its data structure to obtain a classification result; the data classification result includes: image data, point cloud data, and other structured data. The data to be transmitted is transmitted based on the classification results; If the data classification result includes image data, the image data will be converted into a standardized format data that conforms to the preset communication specifications through a preset format conversion interface for transmission. If the data classification result includes point cloud data, the point cloud data is converted into standardized format data that conforms to the preset communication specifications through a preset format conversion interface for transmission. If the data classification result includes other structured data, then the other structured data will be converted into ordinary structured data, and the ordinary structured data will be serialized into a string format for transmission.

8. A data scheduling device, characterized in that, include: The request receiving module is used to receive a data transmission request initiated by the source node, wherein the data transmission request includes at least a topic identifier of the communication topic and data to be transmitted; The channel query module is used to query a pre-configured data flow topology graph based on the topic identifier and determine the data transmission channel associated with the topic identifier; wherein, the data flow topology graph is generated based on a graph model, the nodes in the graph model correspond to the functional modules of the cockpit system, the edges represent the data dependencies between nodes, and each edge is bound to a topic identifier; The data transmission module is used to transmit the data to be transmitted from the source node to the target node based on the data transmission channel, so as to complete data scheduling.

9. A data scheduling device, characterized in that, include: One or more processors; A memory for storing one or more programs, which, when executed by one or more processors, cause the data scheduling device to implement the steps of the data scheduling method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by the computer's processor, causes the computer to perform the steps of the data scheduling method according to any one of claims 1 to 7.

Images