Internet of Vehicles application construction method, system, device and medium

Abstract

The invention discloses an Internet of Vehicles application construction method based on double monitoring data driving, and the method comprises the steps: firstly, forming a task portrait containing a compiling environment and resource configuration through analyzing a construction task, and providing a basis for the subsequent precise resource matching; then the tasks are classified and stored in a task pool, dynamic scheduling is carried out based on task monitoring data and resource monitoring data, a traditional sequential scheduling mode is broken through, and the task execution sequence can adapt to the real-time system state; tasks with higher priorities or matched with the environment are scheduled preferentially, so that the time consumption of environment switching and task blockage are remarkably reduced; and finally, dynamically allocating matched resources from a resource pool according to the task portrait to execute compiling. Through the technical means of task portrait definition demand and dual-monitoring data driven decision, the efficiency and resource utilization rate of multi-application parallel compilation of the Internet of Vehicles are effectively improved.

Description

Technical Field

[0001] This application relates to the field of vehicle network application development technology, and in particular to a method, system, device and medium for building vehicle network applications based on dual monitoring data. Background Technology

[0002] In the field of connected vehicles, in-vehicle systems typically consist of multiple interconnected applications (such as Bluetooth phone, driving assistance, and air conditioning control) working collaboratively. Current technologies generally employ a sequential compilation model for the compilation and building of these applications, which suffers from key drawbacks such as low compilation efficiency, fixed compilation parameters that cannot be dynamically adjusted, inconsistent compilation environments leading to dependency conflicts, and a disconnect between resource scheduling and recycling, resulting in resource waste or idleness. These problems severely restrict the development iteration efficiency and system stability of large-scale connected vehicle projects. Summary of the Invention

[0003] The purpose of this application is to solve at least one of the technical problems existing in the prior art mentioned above, and to propose a method, system, device and medium for building vehicle network applications based on dual monitoring data, so as to improve compilation efficiency, optimize resource allocation and ensure environmental stability, and solve the core pain point of parallel compilation of multiple vehicle network applications.

[0004] In a first aspect, embodiments of this application provide a method for constructing a vehicle-to-everything (V2X) application, including:

[0005] Trigger the build task;

[0006] The build task is analyzed to obtain the compilation environment configuration and compilation resource configuration, forming a task profile;

[0007] The construction tasks are stored in a task pool, and the tasks are classified and stored according to their characteristics.

[0008] Based on task monitoring data and resource monitoring data, tasks in the task pool are dynamically scheduled.

[0009] Based on the task profile, resources are allocated from the resource pool to the scheduled task;

[0010] Use the allocated resources to perform compilation and build;

[0011] Monitor task status and resource usage, and reclaim resources based on the monitoring data.

[0012] Furthermore, the dynamic scheduling includes:

[0013] Tasks are reordered based on at least one of the following: task priority, environment dependency, queuing time, system load, and resource idle status, prioritizing the scheduling of higher priority tasks, tasks in the same environment, or tasks in the same project.

[0014] Furthermore, the allocation of resources includes:

[0015] Based on the recommended and minimum configurations in the task profile, and combined with the current resource availability in the resource pool, a resource allocation scheme is dynamically selected.

[0016] When the resource quantity is greater than the first preset resource quantity threshold, the recommended configuration will be used for allocation; when the resource quantity is less than the second preset resource quantity threshold, the minimum configuration will be used for allocation.

[0017] Furthermore, the resource pool includes a virtual container pool and a physical machine pool. Virtual containers are used preferentially during resource allocation, while special tasks within a preset range are allocated to physical machines.

[0018] Furthermore, the categorized storage includes:

[0019] The tasks are categorized and stored according to their project relevance, compilation environment requirements, and priority.

[0020] Furthermore, the resource recycling includes:

[0021] Based on the task characteristics and resource monitoring data of the tasks to be executed in the task pool, a decision is made on whether to reclaim resources;

[0022] If there is a pending task that matches the current resource, the resource reclamation will be temporarily suspended; otherwise, the resource will be reclaimed immediately.

[0023] Furthermore, it also includes:

[0024] Record the build time and resource consumption of historical build tasks, and optimize the compilation environment and compilation resource configuration based on historical data.

[0025] Secondly, embodiments of this application provide a vehicle network application construction system capable of implementing any of the foregoing vehicle network application construction methods, comprising:

[0026] The task management subsystem includes a task parsing module, a task pool module, a task scheduling module, and a task monitoring module;

[0027] The resource management subsystem includes a resource scheduling module, a resource pool module, a resource recycling module, and a resource monitoring module;

[0028] The task parsing module is used to parse the construction task and form a task profile.

[0029] The task pool module is used to store tasks and classify them according to task characteristics;

[0030] The task scheduling module dynamically schedules tasks based on data from the task monitoring module and the resource monitoring module.

[0031] The resource scheduling module allocates resources from the resource pool module based on the task profile;

[0032] The resource recycling module recycles resources based on data from the task monitoring module and the resource monitoring module.

[0033] Thirdly, embodiments of this application provide an electronic device, including: one or more processors;

[0034] A memory for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors are able to implement the steps in the vehicle network application construction method described in any of the preceding claims.

[0035] Fourthly, embodiments of this application provide a computer-readable medium storing a computer program, which, when executed by a processor, can implement the steps in the vehicle network application construction method described in any of the preceding claims.

[0036] This application discloses a method for building vehicle-to-everything (V2X) applications based on dual-monitoring data. First, the method parses the building tasks to form a "task profile" containing the compilation environment and resource configuration, providing a basis for subsequent accurate resource matching. Then, tasks are categorized and stored in a task pool, and dynamically scheduled based on task monitoring data (such as priority and environment dependencies) and resource monitoring data (such as system load and resource idle status). This breaks the traditional sequential scheduling mode, allowing the task execution order to adapt to the real-time system state, prioritizing higher-priority tasks or those matching the environment, thus significantly reducing environment switching time and task blocking. Finally, matching resources are dynamically allocated from the resource pool based on the "task profile" for compilation. Through the above-mentioned technical means of "defining requirements through task profiles and driving decision-making with dual-monitoring data," the efficiency and resource utilization of parallel compilation of multiple V2X applications are effectively improved. Attached Figure Description

[0037] Figure 1 The core flowchart of a vehicle networking application construction method based on dual monitoring data provided in this application embodiment;

[0038] Figure 2 A schematic diagram of the architecture of a vehicle networking application construction system based on dual monitoring data provided in this application embodiment;

[0039] Figure 3 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0040] To enable those skilled in the art to better understand the technical solutions of this application, exemplary embodiments of this application are described below with reference to the accompanying drawings, including various details of the embodiments of this application to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description. Unless otherwise specified, the various embodiments of this application and the features within those embodiments can be combined with each other.

[0041] As used herein, the term “and / or” includes any and all combinations of one or more of the associated enumerated entries. The terminology used herein is for describing particular embodiments only and is not intended to limit the application. As used herein, the singular forms “a” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated features, integrals, steps, operations, elements, and / or components is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0042] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It should also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and this application, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0043] In the field of connected vehicles, the vehicle system needs to be split into multiple interrelated applications (such as Bluetooth phone, driving assistance, air conditioning, weather, etc.) to work together. However, the existing compilation technology is difficult to adapt to the requirements of this scenario and has the following key defects, which seriously restrict development efficiency and stability.

[0044] (1) Low compilation efficiency: Many applications adopt a "sequential compilation" mode without taking into account the characteristics of multi-core CPU hardware for parallel scheduling, resulting in idle hardware resources. For large-scale vehicle networking projects containing more than 20 applications, the compilation time often reaches several hours, which greatly extends the development iteration cycle and cannot meet the needs of rapid version updates.

[0045] (2) Fixed compilation parameters: The core parameters in the compilation process (such as JVM memory allocation, number of worker processes, number of parallel tasks) are mostly fixed configurations. They cannot be dynamically adjusted according to the resource requirements of different applications (such as weather applications with large file resources needing high memory, while Bluetooth phone applications have lower memory requirements) and the real-time load of the system. This can easily lead to two extreme problems: "resource overload causing compilation crash" or "resource redundancy causing waste".

[0046] (3) Inconsistent compilation environment: Different in-vehicle applications rely on different underlying environments (e.g., some applications require JDK 11+Gradle 7.5, while others require JDK 17+Gradle 8.0). Existing solutions lack a standardized environment management mechanism. During parallel compilation, dependency conflicts are easily caused by incompatible environment versions, which directly leads to compilation failure. Furthermore, troubleshooting requires checking the environment configuration one by one, which is time-consuming.

[0047] (4) Disconnection between resource scheduling and recycling: resource allocation is not linked to task status. For example, a compilation task that is triggered on a timed basis needs to wait for resources to be available before it can start. However, resources are not recycled in time after the task is completed, resulting in physical machines / virtual containers being idle for a long time. At the same time, there is a lack of resource reuse strategy. Tasks in the same environment need to repeatedly create containers / start physical machines, which increases the time spent on environment preparation.

[0048] In summary, existing technologies cannot solve the coordination problems of "efficiency, resources, and environment" in the compilation of multiple applications in the Internet of Vehicles. There is an urgent need for a technical solution that can dynamically adapt to resource requirements, perceive system status in real time, and manage the compilation environment in a unified manner.

[0049] In view of this, one embodiment of this application proposes a method for constructing vehicle-to-everything (V2X) applications based on dual-monitoring data. This method uses "task-driven - resource adaptation - dynamic collaboration" as its core logic. Through bidirectional data linkage between the task management subsystem and the resource management subsystem, it achieves efficient control over the entire process from task triggering to construction completion. Specifically, it may include the following steps, as described in the reference... Figure 1 and Figure 2 .

[0050] Step 1: Trigger the build task.

[0051] Specifically, developers trigger a build task called "In-vehicle Weather App" through CI / CD tools such as Jenkins.

[0052] Build tasks can be triggered manually, on a schedule, or through CI tools. For example, developers can trigger them manually via a web interface, set up a scheduled task to build automatically at night, or integrate them through Jenkins. This setup is compatible with multiple triggering methods, adapts to different development habits, and reduces implementation costs.

[0053] Step 2, Task Analysis and Task Profile Formation: Analyze the build task, obtain the compilation environment configuration and compilation resource configuration, and form a task profile.

[0054] Specifically, the system reads the project's configuration file (such as pom.xml or build.gradle), parses out the required compilation environment configuration (such as JDK 17 and Gradle 8.0 required) and compilation resource configuration (such as a recommended memory configuration of 4 GB and a minimum memory configuration of 2 GB). This information is then structured to form a "task profile" for the task.

[0055] Step 3, Task Classification and Storage: Store the constructed tasks in the task pool and classify and store the tasks according to their characteristics.

[0056] Specifically, the "In-vehicle Weather Application" build task is stored in a task pool. The task pool is not simply queued, but is categorized and stored according to task characteristics (such as "Environment Requirements: JDK17 + Gradle8.0" and "Project Group: UI Application Group" in this project).

[0057] Categorized storage can specifically include classifying tasks by project relevance, compilation environment requirements, and priority. For example, multiple application tasks (such as Bluetooth phone and driving assistance) within the same connected vehicle project can be stored in the same group, while tasks requiring the same JDK version can be grouped together. This configuration reduces the filtering time during scheduling and facilitates batch scheduling of tasks with the same environment, thereby improving scheduling efficiency.

[0058] Step 4: Dynamic task scheduling: Based on task monitoring data and resource monitoring data, dynamically schedule tasks in the task pool.

[0059] Specifically, the task scheduling module acquires task monitoring data (e.g., this task has a "high" priority and has been queued for 5 minutes) and resource monitoring data in real time (e.g., the current system CPU load is 30%, and there is an idle JDK 17 environment container). Based on this data, the scheduling module decides to schedule this task immediately, rather than other tasks that were queued earlier but whose environments do not match.

[0060] Dynamic scheduling can specifically include: reordering tasks based on at least one of the following: task priority, environment dependencies, and queuing time from task monitoring data, and system load and resource idle status from resource monitoring data, prioritizing tasks with higher priority, those in the same environment, or those from the same project. For example, if the system detects task A (high priority, requires JDK 11 environment) and task B (low priority, requires JDK 17 environment) in the task pool, and resource monitoring shows that there are currently idle JDK 11 containers, the scheduler will prioritize scheduling task A instead of scheduling task B according to the triggering order. This improves multi-core CPU utilization, reduces environment switching time, solves task blocking problems, and significantly improves compilation efficiency.

[0061] Step 5: Resource allocation: Based on the task profile, allocate resources from the resource pool to the scheduled task.

[0062] Specifically, after receiving the scheduling instruction and the "task profile," the resource scheduling module queries the resource pool. Since resources are sufficient, it allocates a Docker container with a pre-configured JDK 17 and Gradle 8.0 environment and 4 GB of memory from the virtual container pool to the task, according to the "recommended configuration."

[0063] The resource pool includes a virtual container pool and a physical machine pool. Virtual containers are prioritized for resource allocation, with physical machines allocated only for specific tasks. For example, the virtual container pool comes pre-configured with Docker templates such as JDK 11+ and Gradle 7.5 for rapid container creation; physical machines are used for tasks requiring specialized hardware (such as GPU compilation). This setup achieves environment standardization and rapid resource allocation, reducing environment conflicts.

[0064] The virtual container pool stores Docker templates for different compilation environments, thus providing a unified and stable compilation environment, avoiding version conflicts from the source, and improving the compilation success rate.

[0065] Resource allocation can specifically include: dynamically selecting a resource allocation scheme based on the recommended and minimum configurations in the task profile, combined with the current resource availability in the resource pool; allocating according to the recommended configuration when resources are sufficient (resources exceeding a first preset resource threshold), and allocating according to the minimum configuration when resources are scarce (resources falling below a second preset resource threshold). For example, the task profile recommends 4 GB of memory and requires a minimum of 2 GB of memory. If the resource pool has sufficient memory, 4 GB is allocated; if memory is scarce, 2 GB is allocated, thus ensuring that the task does not fail due to insufficient resources. This setting avoids resource overload or redundancy, achieving a balance between resource utilization and compilation efficiency, and reducing hardware costs.

[0066] Step 6: Execute the build: Use the allocated resources to perform the build.

[0067] Specifically, the assigned container executes the compilation script to build the "in-vehicle weather application." During this process, the task monitoring module updates the task status to "running" in real time, and the resource monitoring module records the CPU and memory usage of the container.

[0068] Step 7, Monitoring and Resource Reclamation: Monitor task status and resource usage, and reclaim resources based on monitoring data.

[0069] Specifically, after the build is complete, the task status is updated to "Completed". The resource recycling module checks the task pool and finds another pending task belonging to the "UI Application Group" that requires a JDK 17 environment. Therefore, it decides to temporarily postpone recycling the current container and set its status to "Idle" for quick reuse. If there is no matching task, the container is destroyed to release resources.

[0070] Resource reclamation can specifically include: determining whether to reclaim resources based on the task characteristics and resource monitoring data of tasks awaiting execution in the task pool; if there are tasks awaiting execution that match the current resources, resource reclamation is temporarily suspended. For example, after a Docker container completes compilation, if the resource reclamation module detects that there are still tasks in the task pool that require the same environment, the container will not be reclaimed and will be used directly for new tasks. This setting improves resource reuse rate, reduces the time loss of environment creation and destruction, and enhances process smoothness.

[0071] Preferably, a method for constructing a vehicle-to-everything (V2X) application based on dual monitoring data may further include the following step 8.

[0072] Step 8: Record the build time and resource consumption of historical build tasks, and optimize the compilation environment and resource configuration based on historical data. For example, the system records the build time and memory usage of a task over multiple builds, and automatically adjusts its recommended configuration to more efficient values ​​for subsequent scheduling. Through iterative data optimization, resource allocation accuracy and compilation efficiency are further improved.

[0073] This application achieves dynamic collaboration between tasks and resources through task profiling and dual monitoring data linkage, improving compilation efficiency and avoiding resource waste and compilation blockage, making it particularly suitable for multi-application vehicle networking scenarios.

[0074] refer to Figure 2Another embodiment of this application provides a vehicle-to-everything (V2X) application construction system capable of implementing any of the aforementioned V2X application construction methods. Through a "dual-core subsystem + bidirectional data linkage" architecture, it constructs a dynamic collaborative management mechanism for tasks and resources. The system core consists of a task management subsystem and a resource management subsystem. The two subsystems achieve closed-loop control through "monitoring data exchange and decision command transmission." Specifically, this V2X application construction system may include a task management subsystem and a resource management subsystem; the task management subsystem may further include a task parsing module, a task pool module, a task scheduling module, and a task monitoring module; the resource management subsystem may further include a resource scheduling module, a resource pool module, a resource recycling module, and a resource monitoring module. The specific technical features and effects of each functional module are described below.

[0075] (1) Task parsing module

[0076] The system triggers build tasks in any way users can, including manually, on a schedule, or through CI tools such as Jenkins. The task parsing module of the task management subsystem reads the project configuration file, extracting the compilation environment configuration (such as operating system, JDK, Gradle version, and preset parameters) and compilation resource configuration (such as recommended and minimum configurations for CPU and memory), forming a structured "task profile" that provides a basis for subsequent scheduling and resource matching.

[0077] (2) Task Pool Module

[0078] The parsed tasks are stored in the task pool module. The task pool module does not queue tasks sequentially, but rather categorizes and stores them according to project relevance, compilation environment, and task priority. Simultaneously, the task monitoring module collects task status in real time and synchronizes it to the resource management subsystem, providing a clear data source for scheduling.

[0079] (3) Task scheduling module

[0080] The task scheduling module abandons the traditional method of scheduling according to the trigger order. Instead, it dynamically rearranges tasks by combining the task status (such as priority and queuing time) obtained by the task monitoring module and the system load obtained by the resource monitoring module. It prioritizes scheduling high-priority tasks, tasks in the same environment or project, lightweight tasks when the load is high, and tasks with high resource requirements are centrally scheduled when the load is low. Then, it pushes matching instructions to the resource management subsystem.

[0081] (4) Task monitoring module

[0082] The task monitoring module tracks the entire lifecycle status of tasks in real time (pending execution / in execution / failed / completed), labels task project ownership, environmental dependencies, and other characteristics, and updates data regularly to provide task-side data support for resource decisions.

[0083] (5) Resource scheduling module

[0084] After receiving the matching instruction, the resource scheduling module allocates resources from the resource pool according to the task environment requirements: virtual containers are used for regular tasks, and physical machines are used for special tasks. If resources are sufficient, the recommended configuration is used; otherwise, the minimum configuration is used.

[0085] For scheduled tasks, resource scheduling can request resources from the resource pool in advance as needed, thereby reducing resource scheduling waiting time.

[0086] The resource scheduling module also records the duration and resources consumed for each task build. Based on historical build data, it optimizes the compilation environment and resource configuration to improve subsequent scheduling.

[0087] (6) Resource Pool Module

[0088] The resource pool module includes a virtual container pool and a physical machine pool. The virtual container pool stores Docker templates for different environments, enabling rapid container creation; the physical machine pool stores specialized hardware servers. The status (idle / occupied / configured, etc.) of both resource pools is periodically synchronized to the resource monitoring module.

[0089] (7) Resource recycling module

[0090] The resource recycling module makes decisions based on task and resource monitoring data: if there are pending tasks in the task pool that match the current resource, recycling will be temporarily suspended to avoid repeated creation and time consumption; if the resource is idle and there are no matching tasks, the resource can be recycled immediately (destroy the container or release the physical machine).

[0091] (8) Resource monitoring module

[0092] Real-time monitoring of key resource usage metrics for various tasks (CPU / memory utilization, etc.), combined with predictions of future peak resource demands based on pending tasks, and early warning of resource shortfalls. This provides data-driven decision support for resource scheduling and recycling, enabling intelligent scheduling and intelligent recycling.

[0093] The compilation is executed on containers or physical machines allocated with resources, supporting script builds or as Jenkins Slave nodes. During the build process, task monitoring synchronizes progress, resource monitoring collects consumption data, and resources can be dynamically scaled up when insufficient. Upon completion, artifacts are output to a specified path, and the results are synchronized to the task monitoring module.

[0094] In some embodiments, when a new build request arrives, the task parsing module analyzes it and generates a task profile, which is then stored in the task pool module. The task scheduling module queries the task monitoring module (to obtain task priority and queuing time) and the resource monitoring module (to obtain the current CPU, memory load, and idle container status of the system), and after comprehensive judgment, schedules multiple tasks in the same environment together and issues instructions to the resource scheduling module. The resource scheduling module allocates a suitable container from the resource pool module to execute these tasks. After the task is completed, the resource recycling module queries the task pool module to see if there are any pending tasks matching this container environment. If not, the container is immediately recycled; if so, it is retained for reuse. The entire process is supported by real-time data from the monitoring modules of the two subsystems. Through a modular dual-subsystem design, this system achieves intelligent and dynamic coupling of task flow and resource flow, effectively improving the efficiency, resource utilization, and environmental stability of large-scale vehicle network multi-application compilation, and solving the core pain points in existing technologies.

[0095] The task management subsystem and the resource management subsystem interact bidirectionally via a data bus (e.g., task status, resource status, scheduling instructions), forming a closed-loop intelligent control system. Through this bidirectional data linkage between the two subsystems, intelligent collaboration between tasks and resources is achieved, resolving efficiency, resource, and environmental issues in compiling multiple applications for the Internet of Vehicles, and improving development efficiency and system stability.

[0096] Overall, this application addresses the core pain points of compiling and building multiple applications for the Internet of Vehicles (IoV), and has formed four core innovations in task management and resource scheduling, specifically including:

[0097] (1) Dynamic scheduling mechanism driven by task-resource dual monitoring: abandoning the traditional sequential scheduling mode, it innovatively combines task monitoring (task priority, environment dependency, queuing time) and resource monitoring (system load, resource idle status) data to realize the linkage decision of task reordering and resource matching, solve the problems of low utilization of multi-core CPU resources and task blocking, and significantly improve compilation efficiency.

[0098] (2) "Recommended + Minimum" dual-standard resource adaptation strategy: In response to the defects of fixed compilation parameters, the recommended configuration and minimum configuration of resource requirements are clearly defined in the task parsing stage. During resource scheduling, the resource is dynamically adapted according to the resource balance in the pool. When resources are sufficient, the recommended configuration is used to ensure efficiency, and when resources are scarce, the minimum configuration is used to ensure that tasks are not blocked. At the same time, the configuration is iteratively optimized by combining historical compilation data, thus achieving a balance between resource utilization and compilation efficiency.

[0099] (3) Resource reuse architecture based on classified storage and deferred reclamation: The task pool stores tasks according to application relevance, environment requirements and priority, which reduces the time spent on scheduling and screening; the resource reclamation process deferred the reclamation of resources that match the environment / configuration based on the task pool's pending tasks, avoiding the time loss of frequent creation and destruction of virtual containers / physical machines, and improving the resource reuse rate and overall process smoothness.

[0100] (4) Standardized management solution for compilation environment compatible with multiple scenarios: Through the dual-pool architecture of "virtual container pool + physical machine build pool" of resource pool, a standardized environment template with different JDK and Gradle versions is provided. The task parsing process accurately matches the environment requirements, avoiding version conflict issues during parallel compilation from the source. At the same time, it is compatible with manual, scheduled, CI tool triggering and traditional build methods, reducing the access cost of existing development processes.

[0101] Based on the same inventive concept, embodiments of this application also provide an electronic device. Figure 3 This is a structural block diagram of an electronic device provided in an embodiment of this application. Figure 3 As shown in the figure, an electronic device provided in this application embodiment includes: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement any of the vehicle networking application construction methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0102] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0103] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0104] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0105] This application also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps in any of the vehicle-to-everything (V2X) application construction methods described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0106] This application also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described method for building vehicle networking applications.

[0107] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0108] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0109] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0110] The computer program instructions used to perform the operations of this application may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), are personalized by utilizing the status information of the computer-readable program instructions. These electronic circuits can execute the computer-readable program instructions to implement various aspects of this application.

[0111] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0112] Various aspects of this application are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0113] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0114] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0115] 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. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0116] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for general illustrative purposes only and should not be construed as limiting. In some embodiments, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this application as set forth by the appended claims.

Claims

1. A method for constructing a vehicle-to-everything (V2X) application, characterized in that, include: Trigger the build task; The build task is analyzed to obtain the compilation environment configuration and compilation resource configuration, forming a task profile; The construction tasks are stored in a task pool, and the tasks are classified and stored according to their characteristics. Based on task monitoring data and resource monitoring data, tasks in the task pool are dynamically scheduled. Based on the task profile, resources are allocated from the resource pool to the scheduled task; Use the allocated resources to perform compilation and build; Monitor task status and resource usage, and reclaim resources based on the monitoring data.

2. The method for constructing vehicle-to-everything (V2X) applications according to claim 1, characterized in that, The dynamic scheduling includes: Tasks are reordered based on at least one of the following: task priority, environment dependency, queuing time, system load, and resource idle status, prioritizing the scheduling of higher priority tasks, tasks in the same environment, or tasks in the same project.

3. The method for constructing vehicle-to-everything (V2X) applications according to claim 1, characterized in that, The allocated resources include: Based on the recommended and minimum configurations in the task profile, and combined with the current resource availability in the resource pool, a resource allocation scheme is dynamically selected. When the resource quantity is greater than the first preset resource quantity threshold, the recommended configuration will be used for allocation; when the resource quantity is less than the second preset resource quantity threshold, the minimum configuration will be used for allocation.

4. The method for constructing vehicle-to-everything (V2X) applications according to claim 1, characterized in that, The resource pool includes a virtual container pool and a physical machine pool. Virtual containers are used first when allocating resources, and special tasks within a preset range are assigned to physical machines.

5. The method for constructing vehicle-to-everything (V2X) applications according to claim 1, characterized in that, The categorized storage includes: The tasks are categorized and stored according to their project relevance, compilation environment requirements, and priority.

6. The method for constructing vehicle-to-everything (V2X) applications according to claim 1, characterized in that, The resource recycling includes: Based on the task characteristics and resource monitoring data of the tasks to be executed in the task pool, a decision is made on whether to reclaim resources; If there is a pending task that matches the current resource, the resource reclamation will be temporarily suspended; otherwise, the resource will be reclaimed immediately.

7. The method for constructing vehicle-to-everything (V2X) applications according to claim 1, characterized in that, Also includes: Record the build time and resource consumption of historical build tasks, and optimize the compilation environment and compilation resource configuration based on historical data.

8. A vehicle-to-everything (V2X) application construction system capable of implementing the V2X application construction method according to any one of claims 1-7, characterized in that, include: The task management subsystem includes a task parsing module, a task pool module, a task scheduling module, and a task monitoring module; The resource management subsystem includes a resource scheduling module, a resource pool module, a resource recycling module, and a resource monitoring module; The task parsing module is used to parse the construction task and form a task profile. The task pool module is used to store tasks and classify them according to task characteristics; The task scheduling module dynamically schedules tasks based on data from the task monitoring module and the resource monitoring module. The resource scheduling module allocates resources from the resource pool module based on the task profile; The resource recycling module recycles resources based on data from the task monitoring module and the resource monitoring module.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors are enabled to implement the steps in the vehicle networking application construction method as described in any one of claims 1 to 7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it can implement the steps in the vehicle networking application construction method as described in any one of claims 1 to 7.

Images