Data collaborative processing method and device, equipment and readable storage medium
Patent Information
- Application Number
- CN202611036847.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-13
- Publication Date
- 2026-10-30
Smart Images
Figure CN123020648A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, and in particular to a data collaborative processing method, apparatus, device, and readable storage medium. Background Technology
[0002] With the rapid development of IoT and AI technologies, intelligent connected vehicles have become a crucial direction for the transformation and upgrading of the automotive industry. In business scenarios such as autonomous driving, remote diagnostics, and user behavior analysis, the amount of data generated by vehicles is growing exponentially, and the data types are becoming increasingly complex, encompassing multi-source heterogeneous data such as raw sensor data, vehicle status signals, and environmental perception information. How to efficiently and in real-time process this massive amount of data and transform it into valuable business services has become a critical issue that urgently needs to be addressed in the field of connected vehicles.
[0003] In existing technologies, the processing of vehicle-to-everything (V2X) data typically employs a traditional data platform architecture or a single cloud computing model. In terms of processing flow, statically configured data flow pipelines are often used, meaning the data collection, transmission, processing, and storage paths are predefined, and business logic is strongly bound to the data processing link. When business requirements change, it is often necessary to redevelop and redeploy the data link, resulting in slow system response, poor flexibility, and an inability to meet the dynamic data flow reconstruction requirements of scenarios such as autonomous driving. Regarding computing power distribution, processing is either primarily concentrated in the cloud or limited to local computing on the vehicle, lacking a collaborative mechanism between the vehicle, edge, and cloud, thus failing to guarantee the real-time performance and reliability of critical business operations.
[0004] In summary, how to solve the problems of static data flow configuration being unable to adapt to dynamic business scenarios, weak collaborative scheduling capabilities of vehicle-cloud-edge computing resources, and poor real-time data processing in existing technologies has become a technical challenge that needs to be addressed by those skilled in the art. Summary of the Invention
[0005] This application provides a data collaborative processing method, apparatus, device, and readable storage medium, aiming to solve the technical problems in the prior art where static configuration of data streams cannot adapt to dynamic business scenarios, the collaborative scheduling capability of vehicle-cloud-edge computing resources is weak, and the real-time performance of data processing is poor.
[0006] Firstly, this application provides a data collaborative processing method, the data collaborative processing method comprising: Receive data requirements from business scenarios and extract the various data processing tasks and their data dependencies from the data requirements; Using data processing tasks as nodes and data dependencies as edges, a directed acyclic topology graph is generated. Based on the status information of computing nodes and the attribute information of data processing tasks, the processing priority and execution strategy of each node in the directed acyclic topology are determined, and the data processing tasks are distributed to computing nodes located at the vehicle end, edge end, or cloud for processing.
[0007] Optionally, the data processing task is based on semantic entities. Before receiving the data requirements of the business scenario and extracting the various data processing tasks and their data dependencies from the data requirements, the following steps are included: Extract the physical signals of the vehicle hardware; The physical signal is standardized and its features are extracted to generate standardized feature data; Based on feature data, construct semantic entities oriented towards business scenarios.
[0008] Optionally, after distributing the data processing tasks to computing nodes located at the vehicle end, edge end, or cloud for processing, the process includes: It receives the processed data from the computing node and returns the processed data to the application service's business interface.
[0009] Optionally, the data processing task is based on semantic entities, and the data collaborative processing method further includes: Define new semantic entities and configure data flow paths for the data processing tasks corresponding to the new semantic entities in the directed acyclic topology graph to enable the addition of new services.
[0010] Optionally, the data collaborative processing method further includes: It enables end-to-end data traceability, hierarchical access control, and monitoring and alerting for the flow of data.
[0011] Optionally, the data collaborative processing method further includes: When a compute node failure is detected, the data processing tasks of the failed compute node are migrated to other available compute nodes.
[0012] Secondly, this application provides a data platform system, the data platform system comprising: The physical signal layer extracts the physical signals of the vehicle hardware. The data feature layer standardizes and extracts features from the physical signal to generate standardized feature data. The semantic entity layer, based on feature data, constructs semantic entities oriented towards business scenarios for data processing tasks to call; The business application layer, based on semantic entities, encapsulates the business interfaces of application services.
[0013] Thirdly, this application provides a data collaborative processing apparatus, the data collaborative processing apparatus comprising: The receiving module is used to receive data requirements from business scenarios and extract the various data processing tasks and their data dependencies from the data requirements. The generation module is used to generate a directed acyclic topology graph with data processing tasks as nodes and data dependencies as edges. The distribution module is used to determine the processing priority and execution strategy of each node in the directed acyclic topology graph based on the status information of the computing nodes and the attribute information of the data processing tasks, and to distribute the data processing tasks to computing nodes located at the vehicle end, edge end or cloud for processing.
[0014] Fourthly, this application provides a data collaborative processing device, including a processor, a memory, and a data collaborative processing program stored in the memory and executable by the processor, wherein when the data collaborative processing program is executed by the processor, it implements the steps of the data collaborative processing method as described above.
[0015] Fifthly, this application provides a readable storage medium storing a data collaborative processing program, wherein when the data collaborative processing program is executed by a processor, it implements the steps of the data collaborative processing method as described above.
[0016] The beneficial effects of the technical solution provided in this application include: This application receives data requirements from a business scenario, extracts various data processing tasks and their data dependencies from the data requirements, generates a directed acyclic graph (DAG) with data processing tasks as nodes and data dependencies as edges, and determines the processing priority and execution strategy of each node in the DAG based on the state information of the computing nodes and the attribute information of the data processing tasks. The data processing tasks are then distributed to computing nodes located at the vehicle end, edge end, or cloud for processing. This application transforms vague business requirements into structured task nodes and dependency edges, decoupling business logic from underlying execution resources. This allows data flow to be dynamically generated according to the business scenario, rather than statically fixed, solving the problem of statically configured data flow in existing technologies, which cannot adapt to dynamic business scenarios such as autonomous driving. It improves the system's response speed and adaptability to changing business requirements. Using a DAG graph theory model to describe the task scheduling problem clearly represents the sequential constraints and parallel possibilities between tasks. The visualized topology facilitates global optimization of subsequent scheduling algorithms, supports dynamic reconstruction of complex application scenarios, and greatly improves the flexibility of data processing. Based on a multi-dimensional state-aware dynamic scheduling mechanism, the optimal matching of computing resources and task requirements is achieved. This enables optimized allocation of computing resources across vehicle, edge, and cloud platforms, meeting the low-latency requirements of scenarios such as autonomous driving while leveraging the powerful computing capabilities of the cloud for model training or big data analysis. This addresses the issues of poor data real-time performance and weak dynamic adjustment links in existing technologies. Attached Figure Description
[0017] Figure 1 This is a flowchart illustrating an embodiment of the data collaborative processing method of this application; Figure 2 This is a schematic diagram of the system architecture corresponding to the data collaborative processing method of this application; Figure 3 This is a schematic diagram of the system architecture of an embodiment of the data platform system of this application; Figure 4 This is a schematic diagram of the functional modules of an embodiment of the data collaborative processing device of this application; Figure 5 This is a schematic diagram of the hardware structure of the data collaborative processing device involved in the embodiments of this application. Detailed Implementation
[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.
[0019] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.
[0020] In a first aspect, embodiments of this application provide a data collaborative processing method.
[0021] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the data collaborative processing method of this application, as shown below. Figure 1 As shown, the data collaborative processing methods include: Step S10: Receive the data requirements of the business scenario and extract the data processing tasks and their data dependencies from the data requirements.
[0022] In this embodiment, refer to Figure 2 , Figure 2 This is a schematic diagram of the system architecture corresponding to the data collaborative processing method of this application, as shown below. Figure 2 As shown, the data requirements of the business scenario originate from application services in the upstream application layer, such as autonomous driving decision-making, remote vehicle diagnostics, user behavior analysis, or battery health management. The system receives these requirements through the flow definition module in the dynamic flow orchestration engine. In addition to the flow definition module, the dynamic flow orchestration engine also includes flow scheduling and flow execution modules. The specific extraction process includes: semantic parsing of the data requirements of the business scenario to identify the data processing tasks needed to complete the business; simultaneously, analyzing the input-output relationships between tasks to determine data dependencies. The data processed by the data processing tasks originates from the semantic entity layer of the layered semantic decoupling architecture. A data platform system based on this layered semantic decoupling architecture can be referenced... Figure 3 As shown, Figure 3 This is a schematic diagram of the system architecture of an embodiment of the data platform system of this application. By transforming vague business requirements into structured task nodes and dependency edges, the decoupling of business logic and underlying execution resources is achieved. This enables data flow to be dynamically generated according to business scenarios, rather than being statically fixed. This solves the problem in the prior art where data flow uses static configuration and cannot adapt to dynamic business scenarios such as autonomous driving, and improves the system's response speed and adaptability to changing business requirements.
[0023] Step S20: Using data processing tasks as nodes and data dependencies as edges, generate a directed acyclic topology graph.
[0024] In this embodiment, after extracting the data processing tasks and dependencies, the system constructs a Directed Acyclic Graph (DAG). Each node in the graph represents an independent data processing task, with node attributes including task type, computational complexity, and real-time requirements. The edges in the graph represent the data flow direction, meaning the output of the upstream data processing task serves as the input of the downstream data processing task. Cycle detection is performed during the generation process to ensure the topology graph is acyclic, guaranteeing the correct logical order of data processing and preventing deadlocks. Using a DAG graph theory model to describe the task scheduling problem clearly characterizes the sequential constraints and parallel possibilities between tasks. The visualized topology facilitates global optimization of subsequent scheduling algorithms, supports dynamic reconfiguration in complex application scenarios, lays the foundation for dynamic scheduling of data flow links, and greatly improves the flexibility of data processing.
[0025] Step S30: Based on the status information of the computing nodes and the attribute information of the data processing tasks, determine the processing priority and execution strategy of each node in the directed acyclic topology graph, and distribute the data processing tasks to computing nodes located at the vehicle end, edge end, or cloud for processing.
[0026] In this embodiment, the status information of the computing nodes includes the load rate of the vehicle-side computing unit, the network congestion status of the edge base station, the remaining computing power of the cloud server, and the current network bandwidth latency. The attribute information of the data processing tasks includes the task's sensitivity to latency (e.g., braking control requires milliseconds, log analysis can be done in seconds), data privacy level, and computational load. Based on the above information, the flow scheduling module dynamically adjusts the processing priority and execution strategy of each node in the DAG topology using a scheduling algorithm, and distributes the data processing tasks to computing nodes located at the vehicle, edge, or cloud for processing. For example, high real-time tasks are distributed to the vehicle, while high-computing-power-consuming and non-real-time tasks are distributed to the cloud. Through a dynamic scheduling mechanism based on multi-dimensional state awareness, optimal matching of computing resources and task requirements is achieved. This realizes optimized allocation of computing resources across the vehicle, edge, and cloud, meeting the low-latency requirements of scenarios such as autonomous driving while utilizing the powerful computing power of the cloud for model training or big data analysis, thus solving the problems of poor data real-time performance and weak dynamic adjustment links in existing technologies.
[0027] In this embodiment, by transforming ambiguous business requirements into structured task nodes and dependency edges, the decoupling of business logic and underlying execution resources is achieved. This allows data flow to be dynamically generated according to business scenarios, rather than being statically fixed. This solves the problem in existing technologies where data flow uses static configuration and cannot adapt to dynamic business scenarios such as autonomous driving, improving the system's response speed and adaptability to changing business requirements. Using a Directed Acyclic Graph (DAG) model to describe the task scheduling problem clearly represents the sequential constraints and parallel possibilities between tasks. The visualized topology facilitates global optimization of subsequent scheduling algorithms, supports dynamic reconstruction of complex application scenarios, and greatly improves the flexibility of data processing. A dynamic scheduling mechanism based on multi-dimensional state awareness achieves optimal matching of computing resources and task requirements. It realizes optimized configuration of computing resources across vehicle, edge, and cloud terminals, meeting the low-latency requirements of scenarios such as autonomous driving while leveraging the powerful computing power of the cloud for model training or big data analysis, solving the problems of poor data real-time performance and weak dynamic adjustment links in existing technologies.
[0028] Furthermore, in one embodiment, the data processing task is based on semantic entities, and before step S10, it includes: Extract the physical signals of the vehicle hardware; The physical signal is standardized and its features are extracted to generate standardized feature data; Based on feature data, construct semantic entities oriented towards business scenarios.
[0029] In this embodiment, this process corresponds to the first three layers of the four-layer semantic decoupling architecture. First, the Controller Area Network (CAN) bus signal, vehicle Ethernet signal, and raw physical data stream from sensors are extracted through a unified access gateway (physical signal layer). Second, the physical signals undergo dimension unification, format conversion, noise filtering, and anomaly removal to extract temporal or statistical features (data feature layer). Finally, standardized semantic entities oriented towards business scenarios are constructed based on the feature data, such as "vehicle entity" (including health status and power type), "user entity" (including driving habits), and "environment entity" (including weather and road type) (semantic entity layer). Through layered processing, the underlying hardware-related physical signals are abstracted into semantic objects that can be understood by the upper-layer business, achieving the separation of physical attributes and business attributes. This decoupling of data semantics from physical hardware data breaks the strong binding relationship between data and a single business, allowing data to be reused across application scenarios without iterating the underlying data architecture, reducing system coupling and operation and maintenance costs, while unifying the semantic standards of multi-source heterogeneous data and eliminating data barriers.
[0030] Further, in one embodiment, after distributing the data processing tasks to computing nodes located at the vehicle end, edge end, or cloud for processing, the process includes: It receives the processed data from the computing node and returns the processed data to the application service's business interface.
[0031] In this embodiment, the processed data is encapsulated by the semantic entity layer and returned to the requester through a standardized service interface provided by the business application layer. Based on the standardized semantic entities provided by the semantic entity layer, the business application layer generates data service interfaces through service orchestration to implement corresponding business processing logic, such as intelligent driving closed-loop, precision marketing, or battery life prediction. The unified service interface encapsulation shields the complexity of the underlying data processing, decoupling business applications from data processing. Application services only need to call the standard interface to obtain the required data, improving the efficiency of business development and the universality of system interfaces.
[0032] Furthermore, in one embodiment, the data processing task is based on semantic entities, and the data collaborative processing method further includes: Define new semantic entities and configure data flow paths for the data processing tasks corresponding to the new semantic entities in the directed acyclic topology graph to enable the addition of new services.
[0033] In this embodiment, when new services are added (such as adding a new type of driving behavior analysis), there is no need to reconstruct the entire data platform. Only new semantic entity rules need to be defined at the semantic entity layer, and a new data flow path in the directed acyclic graph (DAG) needs to be configured for the processing task corresponding to that entity in the dynamic flow orchestration engine. Through a configuration-based business expansion mechanism, leveraging the flexibility of the semantic decoupling architecture, the scalability of the platform is greatly improved. Data links and service interfaces can be quickly adapted, eliminating constraints on the implementation of different application scenarios. New services do not require architectural modifications; only redefining semantic rules and orchestration links is needed for rapid adaptation, significantly reducing iteration costs.
[0034] Furthermore, in one embodiment, the data collaborative processing method further includes: It enables end-to-end data traceability, hierarchical access control, and monitoring and alerting for the flow of data.
[0035] In this embodiment, the system records a full lifecycle log of data from physical signal acquisition to business application output, enabling data traceability; it implements hierarchical access control based on user roles and data sensitivity (such as location information and user privacy); and it runs a monitoring and alarm mechanism to provide real-time alerts for abnormal data flow and access violations. Through the embedded security governance mechanism, the compliance and auditability of data flow are ensured, achieving full auditability and controllability of in-vehicle data flow, meeting the data security compliance requirements of the Internet of Vehicles, and enhancing end-to-end security.
[0036] Furthermore, in one embodiment, the data collaborative processing method further includes: When a compute node failure is detected, the data processing tasks of the failed compute node are migrated to other available compute nodes.
[0037] In this embodiment, the dynamic stream orchestration engine monitors the health status of the vehicle-side, edge-side, and cloud computing nodes in real time. Once a node failure is detected (such as overheating of the vehicle-side computing unit or cloud network interruption), a fault-tolerant recovery mechanism is triggered, automatically migrating the DAG data processing tasks on the failed node to other available computing nodes (such as migrating from the vehicle-side to the edge-side, or from the primary cloud to a backup cloud). This status-monitoring-based task migration mechanism ensures system continuity, improves system reliability and availability, and ensures that critical services can continue to operate even with partial node failures, achieving elastic scaling and fault-tolerant recovery.
[0038] Secondly, embodiments of this application also provide a data platform system.
[0039] In one embodiment, reference is made to Figure 3 , Figure 3 This is a schematic diagram of the system architecture of an embodiment of the data platform system of this application, as shown below. Figure 3 As shown, the data platform system includes: The physical signal layer extracts the physical signals of the vehicle hardware. The data feature layer standardizes and extracts features from the physical signal to generate standardized feature data. The semantic entity layer, based on feature data, constructs semantic entities oriented towards business scenarios for data processing tasks to call; The business application layer, based on semantic entities, encapsulates the business interfaces of application services.
[0040] In this embodiment, the data platform system adopts a four-layer hierarchical semantic decoupling architecture. The physical signal layer is responsible for multi-protocol adaptation and raw data extraction; the data feature layer ensures data consistency and is independent of the hardware platform; the semantic entity layer decouples data semantics from physical hardware data; and the business application layer implements business processing logic. Each layer interacts through standardized interfaces. The layered architecture design follows the principle of high cohesion and low coupling, with each layer managing only one type of information, facilitating understanding, modeling, and computation. Through hierarchical division, the entire process of data processing—from raw data collection, semantic standardization, data fusion processing to business output—is achieved. Standardized interaction between layers significantly reduces system coupling, enabling semantic decomposition and decoupling of multi-source heterogeneous data, unifying data standards, and generating reusable semantic units that can be universally recognized by the business.
[0041] Thirdly, embodiments of this application also provide a data collaborative processing device.
[0042] In one embodiment, reference is made to Figure 4 , Figure 4 This is a functional module diagram of an embodiment of the data collaborative processing device of this application, as shown below. Figure 4 As shown, the data collaborative processing device includes: The receiving module 10 is used to receive data requirements from business scenarios and extract the various data processing tasks and their data dependencies from the data requirements. The generation module 20 is used to generate a directed acyclic topology graph with data processing tasks as nodes and data dependencies as edges. The distribution module 30 is used to determine the processing priority and execution strategy of each node in the directed acyclic topology graph based on the status information of the computing nodes and the attribute information of the data processing tasks, and to distribute the data processing tasks to computing nodes located at the vehicle end, edge end or cloud for processing.
[0043] Furthermore, in one embodiment, the data collaborative processing device further includes a semantic entity acquisition module, used for: Extract the physical signals of the vehicle hardware; The physical signal is standardized and its features are extracted to generate standardized feature data; Based on feature data, construct semantic entities oriented towards business scenarios.
[0044] Furthermore, in one embodiment, the data collaborative processing apparatus further includes a return module for: It receives the processed data from the computing node and returns the processed data to the application service's business interface.
[0045] Furthermore, in one embodiment, the data collaborative processing device further includes a new service addition module, used for: Define new semantic entities and configure data flow paths for the data processing tasks corresponding to the new semantic entities in the directed acyclic topology graph to enable the addition of new services.
[0046] Furthermore, in one embodiment, the data collaborative processing device further includes a monitoring module, used for: It enables end-to-end data traceability, hierarchical access control, and monitoring and alerting for the flow of data.
[0047] Furthermore, in one embodiment, the data collaborative processing apparatus further includes a migration module for: When a compute node failure is detected, the data processing tasks of the failed compute node are migrated to other available compute nodes.
[0048] The functions of each module in the aforementioned data collaborative processing device correspond to the steps in the aforementioned data collaborative processing method embodiment, and their functions and implementation processes will not be described in detail here.
[0049] Fourthly, embodiments of this application provide a data collaborative processing device.
[0050] Reference Figure 5 , Figure 5 This is a schematic diagram of the hardware structure of the data collaborative processing device involved in the embodiments of this application. In the embodiments of this application, the data collaborative processing device may include a processor, a memory, a communication interface, and a communication bus.
[0051] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.
[0052] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting devices within the data collaborative processing device, as well as interfaces used for interconnecting the data collaborative processing device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.
[0053] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.
[0054] The processor can be a general-purpose processor, which can call a data co-processing program stored in memory and execute the data co-processing method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the data co-processing program is called can be referred to in the various embodiments of the data co-processing method of this application, and will not be repeated here.
[0055] Those skilled in the art will understand that Figure 5 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.
[0056] Fifthly, embodiments of this application also provide a readable storage medium.
[0057] The present application has a data co-processing program stored on a readable storage medium, wherein when the data co-processing program is executed by a processor, it implements the steps of the data co-processing method as described above.
[0058] The method implemented when the data collaborative processing program is executed can be referred to in various embodiments of the data collaborative processing method of this application, and will not be repeated here.
[0059] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0060] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.
[0061] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.
[0062] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.
[0063] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.
[0064] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.
[0065] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.
Claims
1. A data collaborative processing method, characterized in that, include: Receive data requirements from business scenarios and extract the various data processing tasks and their data dependencies from the data requirements; Using data processing tasks as nodes and data dependencies as edges, a directed acyclic topology graph is generated. Based on the status information of computing nodes and the attribute information of data processing tasks, the processing priority and execution strategy of each node in the directed acyclic topology are determined, and the data processing tasks are distributed to computing nodes located at the vehicle end, edge end, or cloud for processing.
2. The data collaborative processing method as described in claim 1, characterized in that, The data processing task is based on semantic entities and, before receiving the data requirements of the business scenario and extracting the various data processing tasks and their data dependencies from the data requirements, includes: Extract the physical signals of the vehicle hardware; The physical signal is standardized and its features are extracted to generate standardized feature data; Based on feature data, construct semantic entities oriented towards business scenarios.
3. The data collaborative processing method as described in claim 1, characterized in that, After the data processing tasks are distributed to computing nodes located at the vehicle, edge, or cloud for processing, the process includes: It receives the processed data from the computing node and returns the processed data to the application service's business interface.
4. The data collaborative processing method as described in claim 2, characterized in that, The data processing task is based on semantic entities, and the data collaborative processing method further includes: Define new semantic entities and configure data flow paths for the data processing tasks corresponding to the new semantic entities in the directed acyclic topology graph to enable the addition of new services.
5. The data collaborative processing method as described in claim 1, characterized in that, The data collaborative processing method further includes: It enables end-to-end data traceability, hierarchical access control, and monitoring and alerting for the flow of data.
6. The data collaborative processing method as described in claim 1, characterized in that, The data collaborative processing method further includes: When a compute node failure is detected, the data processing tasks of the failed compute node are migrated to other available compute nodes.
7. A data middleware system, characterized in that, include: The physical signal layer extracts the physical signals of the vehicle hardware. The data feature layer standardizes and extracts features from the physical signal to generate standardized feature data. The semantic entity layer, based on feature data, constructs semantic entities oriented towards business scenarios for data processing tasks to call; The business application layer, based on semantic entities, encapsulates the business interfaces of application services.
8. A data collaborative processing device, characterized in that, include: The receiving module is used to receive data requirements from business scenarios and extract the various data processing tasks and their data dependencies from the data requirements. The generation module is used to generate a directed acyclic topology graph with data processing tasks as nodes and data dependencies as edges. The distribution module is used to determine the processing priority and execution strategy of each node in the directed acyclic topology graph based on the status information of the computing nodes and the attribute information of the data processing tasks, and to distribute the data processing tasks to computing nodes located at the vehicle end, edge end or cloud for processing.
9. A data collaborative processing device, characterized in that, The system includes a processor, a memory, and a data co-processing program stored in the memory and executable by the processor, wherein when the data co-processing program is executed by the processor, it implements the steps of the data co-processing method as described in any one of claims 1 to 6.
10. A readable storage medium, characterized in that, The readable storage medium stores a data co-processing program, wherein when the data co-processing program is executed by a processor, it implements the steps of the data co-processing method as described in any one of claims 1 to 6.