New energy vehicle-mounted idle computing power unified opening and scheduling method, device, equipment and system

Abstract

This application provides a unified method, device, electronic device, computer-readable storage medium, vehicle, and system for the unified opening and scheduling of idle computing power in new energy vehicles. It includes: acquiring the physical operating parameters of vehicle nodes; vehicle nodes calling the abstract layer hardware translation component in the hardware interface to convert the physical operating parameters to generate computing power feature words; sending the computing power feature words to the scheduling node; the scheduling node extracting the task resource identifier and parsing the computing power feature words, constructing encrypted fragmented packets and sending them to the vehicle nodes; the vehicle nodes decrypting the target computing code in a local trusted sandbox to obtain and run it, using kernel modules to monitor physical operating parameters, and initiating a system interrupt to suspend the target computing code when a hard interrupt condition is triggered; generating cryptographic credentials in the trusted sandbox after completion, encapsulating the computation results and returning the cryptographic credentials; and controlling the underlying driver to clear the temporary data stored in the trusted sandbox.

Description

Technical Field

[0001] This application relates to the field of distributed computing and data processing technology, and more specifically, to a method, apparatus, electronic device, computer-readable storage medium, vehicle, and system for the unified opening and scheduling of idle computing power in new energy vehicles. Background Technology

[0002] As the intelligence level of new energy vehicles continues to improve, the computing performance of the intelligent computing units they are equipped with continues to grow. Since vehicles spend a significant amount of time parked throughout their 24 / 7 operation cycle, their underlying onboard computing components remain idle during this period. Therefore, how to uniformly allocate these vast amounts of idle distributed onboard processing resources, enabling them to participate in distributed task processing while still meeting the vehicle's operational needs, has become a pressing application scenario requirement.

[0003] Existing computing power scheduling solutions typically employ a centralized cloud scheduling architecture. This approach first requires vehicle nodes to directly upload their underlying raw operational data or computational task packages to a single vendor's central cloud server. Subsequently, the central cloud server performs centralized parsing and computational matching on the received data in the cloud. Finally, the central cloud server directly issues standard computational execution instructions to each vehicle node, which then completes the computation according to the cloud instructions and returns the processing results.

[0004] However, this centralized cloud scheduling architecture has significant technical drawbacks. Because the solution heavily relies on a single vendor's cloud architecture and lacks a unified translation mechanism for heterogeneous underlying hardware, it suffers from low cross-platform hardware compatibility and difficulty in uniformly identifying resources for vehicle nodes with different architectures. Furthermore, raw data is uploaded directly to the cloud outside the local environment, and the execution process lacks a locally controlled and isolated environment, resulting in a high risk of data exposure. In addition, cloud computing instructions operate outside the vehicle's underlying control system. When the vehicle's physical operating state changes abruptly, it cannot directly trigger hardware-level truncation instructions in the underlying kernel, making it difficult to quickly suspend external computing tasks. This poses a significant threat to the vehicle's core driving functions and physical safety. Summary of the Invention

[0005] This application provides a method, apparatus, electronic device, computer-readable storage medium, vehicle, and system for unified opening and scheduling of idle computing power in new energy vehicles, so as to at least alleviate the above-mentioned technical problems.

[0006] The technical advantages of the technical solution provided in this application are: The unified open and scheduling method for idle computing power on new energy vehicles in this application addresses the technical shortcomings of traditional cloud scheduling solutions, such as low cross-platform hardware compatibility, high data exposure risk, and difficulty in quickly responding to sudden changes in the underlying physical state.

[0007] First, by calling the abstract layer hardware translation component in the hardware interface through the vehicle node to convert the physical operating parameters, a computing power feature word is generated and sent to the scheduling node. This solves the problem of the lack of a unified translation mechanism for heterogeneous underlying hardware in traditional solutions. Compared with the limitations of traditional solutions that rely heavily on a single hardware platform, this application shields the differences in underlying hardware architecture through the abstract layer hardware translation component. The scheduling node can complete the task distribution simply by constructing encrypted fragment packets based on the parsed computing power feature word. This allows nodes of different brands or structures to be uniformly managed and identified, and significantly improves cross-platform hardware compatibility and the universality of computing power scheduling.

[0008] Secondly, by decrypting encrypted fragment packets within a local trusted sandbox on the vehicle node to run the target computation code, and generating cryptographic credentials within the sandbox for transmission after completion, the underlying driver clears the temporarily stored data in the trusted sandbox. This solves the exposure risk associated with directly uploading raw data outside the local environment in traditional solutions. In traditional schemes, data computation is outside a controlled environment, while this application utilizes a local trusted sandbox to complete closed computation, supplemented by cryptographic credentials to ensure the credibility of the results. Combined with the post-use clearing mechanism executed by the underlying driver, this creates a closed loop within the terminal for the entire computation lifecycle. Compared to traditional solutions, this significantly improves the physical isolation of core data and the strength of privacy protection.

[0009] Finally, by using the kernel module to monitor physical operating parameters during the process of the vehicle node running the target computation code, when the kernel module detects that the physical operating parameters trigger a hard interrupt condition, it initiates a system interrupt to suspend the target computation code. This solves the technical deficiency of traditional scheduling instructions that cannot deeply link with the underlying hardware. Traditional solutions, because cloud computing is detached from the vehicle's underlying system, cannot respond to sudden vehicle conditions in a timely manner. This application establishes a real-time monitoring channel at the local kernel module level. Once the vehicle's physical parameters do not meet the operating requirements, a hard interrupt condition can be issued immediately for hardware-level truncation. This allows distributed task processing to give way to the vehicle's driving state at any time. Compared with traditional external computing mechanisms, this can better prevent external tasks from interfering with the core operating functions of the vehicle, and provides a higher level of protection for the safe operation of the vehicle. Attached Figure Description

[0010] Figure 1 This application provides an embodiment of a scenario for the unified opening and scheduling of idle computing power in new energy vehicles. Figure 2 This application provides an embodiment of a method for unified opening and scheduling of idle computing power in new energy vehicles. Figure 3 This application provides an embodiment of a unified open and scheduling device for idle computing power in new energy vehicles. Figure 4An electronic device is described in an embodiment of this application; Figure 5 This application provides an embodiment of a computer-readable storage medium. Figure 6 This application describes a vehicle as an embodiment of the present application; Figure 7 This application provides an embodiment of a unified open and scheduling system for idle computing power in new energy vehicles. Detailed Implementation

[0011] like Figure 1 As shown, this is an embodiment of the present application illustrating a scenario for the unified opening and scheduling of idle computing power in new energy vehicles; Figure 2 The image shows an embodiment of this application of a method for unified opening and scheduling of idle computing power in new energy vehicles, comprising the following steps: The vehicle node obtains the physical operating parameters; the vehicle node calls the abstract layer hardware translation component in the hardware interface to perform conversion on the physical operating parameters to generate computing power feature words; the vehicle node sends the computing power feature words to the scheduling node; The scheduling node receives a distributed processing task request and extracts a task resource identifier from the request; the scheduling node parses the computing power feature word and constructs an encrypted fragment packet based on the task resource identifier and the computing power feature word; the scheduling node sends the encrypted fragment packet to the vehicle node. The vehicle node decrypts the encrypted fragment packet within its local trusted sandbox to obtain and run the target computation code. During the execution of the target computation code, the vehicle node uses a kernel module to monitor the physical operating parameters. When the kernel module detects that the physical operating parameters trigger a hard interrupt condition, the vehicle node initiates a system interrupt to suspend the target computation code. After completing the execution of the target computation code, the vehicle node generates a cryptographic credential within the trusted sandbox. The vehicle node encapsulates the computation result and the cryptographic credential. The vehicle node then sends the encapsulated computation result and the cryptographic credential back to the scheduling node. The vehicle node control underlying driver clears the temporary data stored in the trusted sandbox within the trusted sandbox.

[0012] Optionally, the physical operating parameters include the battery's available energy storage ratio; During the process of running the target computation code, the vehicle node uses a kernel module to monitor the physical operating parameters; when the kernel module detects that the physical operating parameters trigger a hard interrupt condition, the vehicle node initiates a system interrupt to suspend the target computation code, including: The vehicle node is pre-configured with a first energy storage protection parameter and a second energy storage protection parameter in the kernel module, wherein the value of the first energy storage protection parameter is greater than the value of the second energy storage protection parameter; The vehicle node reads the available energy storage ratio of the battery in real time through the internal battery management bus; When the available energy storage ratio of the battery drops to the first energy storage protection parameter, the kernel module sends a request packet to the scheduling node to refuse to receive new fragments. The scheduling node stops sending new encrypted fragment packets to the vehicle node based on the refusal to receive new fragment request packets; The kernel module maintains the current execution thread of the target computation code, and when the battery available energy storage ratio continues to drop to the second energy storage protection parameter, the kernel module determines that the hard interrupt condition is met. The kernel module sends a thread freeze command to the trusted sandbox; The trusted sandbox forcibly suspends the current execution thread of the target computation code based on the thread freeze instruction.

[0013] Preferably, the specific implementation process of step "during the process of running the target computing code, the vehicle node uses the kernel module to monitor the physical operating parameters" is as follows: After the trusted sandbox completes the decryption of the encrypted fragment packet, the vehicle node loads the decrypted target computing code into the trusted sandbox isolated running space corresponding to the trusted sandbox, and allocates a current execution thread for the target computing code; after the current execution thread starts to occupy the underlying computing resources of the vehicle node, the vehicle node synchronously establishes an energy storage monitoring association record corresponding to the current execution thread. The energy storage monitoring and association record does not read the execution content of the target computing code, but rather records the task handle of the target computing code, the trusted sandbox isolation space identifier corresponding to the trusted sandbox isolation running space, the thread identifier of the currently executing thread, the source of the battery available energy storage ratio, the first energy storage protection parameter, and the second energy storage protection parameter. The task handle of the target computing code enables the energy storage monitoring and association record to correspond to the target computing code formed after the encrypted fragment packet is decrypted. The trusted sandbox isolation space identifier enables the energy storage monitoring and association record to correspond to the trusted sandbox isolation running space where the target computing code resides. The thread identifier of the currently executing thread enables the energy storage monitoring and association record to correspond to the currently executing thread that is occupying the underlying computing resources. The source of the battery available energy storage ratio enables the kernel module to read the battery available energy storage ratio associated with the currently executing thread from the internal battery management bus. Through the energy storage monitoring and association record, the kernel module can establish a direct correspondence between the vehicle's own energy storage status and the running external computing task. The kernel module performs monitoring at the kernel level within the vehicle's operating environment. It bypasses the queuing process of upper-level scheduling instructions, directly reading the available battery energy storage ratio from the internal battery management bus. It then performs a threshold comparison of the available battery energy storage ratio with the first and second energy storage protection parameters in the energy storage monitoring association record, using the same units of measurement. The available battery energy storage ratio here represents the proportion of remaining energy storage from the vehicle's power battery that can currently be used to maintain both the vehicle's operation and external computing tasks. The technical essence of the kernel module monitoring these physical operating parameters is to continuously establish a kernel-level constraint relationship between the vehicle's energy storage status and the external computing task's resource occupancy status while the target computing code is still running. This kernel-level constraint relationship prevents the target computing code from continuing to operate under its original resource occupancy status after the available battery energy storage ratio decreases, thus ensuring that while the vehicle node opens up idle computing power, it still prioritizes the vehicle's operational needs for resource allocation.Therefore, the monitoring and processing of the kernel module is not simply about collecting power data, but rather about transforming the battery's available energy storage ratio into a kernel-level judgment criterion for controlling the reception of the encrypted fragmented packet, maintaining the current execution thread, and suspending the current execution thread. This kernel-level judgment criterion further participates in the continuous technical processing relationship between the scheduling node issuing the encrypted fragmented packet, the trusted sandbox running the target calculation code, and the vehicle node transmitting the calculation result back.

[0014] Preferably, in the specific technical implementation of the step "the vehicle node pre-configures the first energy storage protection parameter and the second energy storage protection parameter in the kernel module", the vehicle node first reads the locally stored vehicle safety constraint configuration data, and extracts the power guard configuration item, charging status configuration item, vehicle parking status configuration item, and owner authorization record status item from the vehicle safety constraint configuration data; the power guard configuration item is used to limit the energy storage boundary that allows external computing tasks to occupy underlying computing resources when the vehicle opens idle computing power; the charging status configuration item is used to express whether the vehicle node is in a rechargeable state; the vehicle parking status configuration item is used to express whether the vehicle node is in a resident state that allows open idle computing power; and the owner authorization record status item is used to express whether the vehicle node is currently allowed to execute the target computing code. Subsequently, the vehicle node generates an energy storage protection configuration record based on the power guard configuration item, and writes the first energy storage protection parameter and the second energy storage protection parameter into the energy storage protection configuration record. The energy storage protection configuration record is used to provide the first energy storage protection parameter and the second energy storage protection parameter to the kernel module, enabling the kernel module to perform subsequent threshold comparison processing of the same dimension based on the energy storage protection configuration record. The first energy storage protection parameter is configured as a new segment reception control limit in the energy storage configuration record, which is used to limit the boundary for triggering new segment rejection control when the battery's available energy storage ratio enters the energy storage buffer. The second energy storage protection parameter is configured as a thread freeze control limit in the energy storage protection configuration record, which is used to limit the boundary for triggering hard interrupt condition determination when the battery's available energy storage ratio enters the thread freeze interval. The value of the first energy storage protection parameter represents the new fragment reception control limit when the battery's available energy storage ratio enters the energy storage buffer. Its technical essence is to prevent new encrypted fragment packets from continuing to enter the vehicle node in advance, so as to reduce the continuous occupation of the vehicle's energy storage state by subsequent new tasks. The value of the second energy storage protection parameter represents the thread freeze control limit when the battery's available energy storage ratio enters the thread freeze interval. Its technical essence is to switch the currently running thread from the continuing running state to the forced suspension state, so that the vehicle node will transfer the underlying computing resources from external computing tasks to the vehicle's own operating needs.The value of the first energy storage protection parameter is greater than that of the second energy storage protection parameter because the vehicle node needs to truncate the new encrypted fragment packet reception path through the new fragment reception control boundary corresponding to the first energy storage protection parameter before the battery's available energy storage ratio enters the thread freeze interval, and retain the time window for the currently executing thread to complete the current segment or enter a controllable maintenance state. If the first energy storage protection parameter and the second energy storage protection parameter do not have a high-low hierarchy, the vehicle node will face two types of processing pressures simultaneously when it discovers that the battery's available energy storage ratio is insufficient: new fragment reception and current thread freezing. The trusted sandbox will also find it difficult to form an orderly freezing preparation for the currently executing thread in a short period of time. By forming a hierarchical energy storage boundary through the first energy storage protection parameter and the second energy storage protection parameter, the kernel module can first execute the new fragment rejection control according to the new fragment reception control boundary, and then execute the hard interrupt condition judgment according to the thread freeze control boundary, so that there is a clear sequential relationship between the power guard processing, the encrypted fragment packet scheduling processing, the target calculation code execution processing, and the current executing thread suspension processing.

[0015] Preferably, the specific implementation process of step "the vehicle node reads the available energy storage ratio of the battery in real time through the internal battery management bus, and when the available energy storage ratio of the battery drops to the first energy storage protection parameter, the kernel module sends a request packet to the scheduling node to refuse to receive new fragments" is as follows: After the current execution thread starts, the vehicle node reads the battery management data frame through the internal battery management bus according to the set sampling period, and extracts the remaining energy storage field, the available output status field, and the charging access status field from the battery management data frame; the vehicle node performs field consistency verification on the remaining energy storage field, the available output status field, and the charging access status field to form a battery available energy storage ratio sampling record. The battery available energy storage ratio sampling record is used to associate the battery available energy storage ratio read in a single reading with the corresponding sampling time, the thread identifier of the currently executing thread, and the trusted sandbox isolation space identifier. The sampling time is used to enable the battery available energy storage ratio sampling record to participate in the subsequent descent direction confirmation process according to its formation time. The thread identifier of the currently executing thread is used to ensure that the battery available energy storage ratio sampling record can be mapped to the currently executing thread. The trusted sandbox isolation space identifier is used to ensure that the battery available energy storage ratio sampling record can be mapped to the trusted sandbox isolation running space where the currently executing thread is located, thereby preventing the kernel module from directly triggering control actions based solely on discrete energy readings. Subsequently, the kernel module reads the continuously formed battery available energy storage ratio sampling records and performs descent direction confirmation processing on the battery available energy storage ratio at adjacent sampling times to form an energy storage descent confirmation record. The technical essence of the energy storage decline confirmation record is to transform the battery's available energy storage ratio from a static reading into a kernel-level judgment criterion that reflects the changing trend of energy storage margin. The energy storage decline confirmation record subsequently participates in threshold comparison processing of the same dimension as the first energy storage protection parameter, enabling the kernel module to distinguish between short-term sampling disturbances and continuous energy storage decline. When the aforementioned threshold comparison processing of the same dimension indicates that the battery's available energy storage ratio has dropped to the first energy storage protection parameter, the kernel module does not immediately freeze the currently executing thread. Instead, it first generates a packet to reject new sharding requests based on the energy storage monitoring association record. The packet to reject new sharding requests carries at least the vehicle node identifier, the trusted sandbox isolation space identifier, the thread identifier of the currently executing thread, the trigger flag of the first energy storage protection parameter, and the record identifier of the energy storage decline confirmation record.The vehicle node identifier is used to enable the scheduling node to locate the vehicle node that sent the "Reject New Shard Request Packet". The trusted sandbox isolation space identifier is used to enable the scheduling node to identify the trusted sandbox isolation space in the vehicle node where the target computation code is running. The thread identifier of the current execution thread is used to enable the scheduling node to identify the current execution thread associated with the "Reject New Shard Request Packet". The trigger flag of the first energy storage protection parameter is used to enable the scheduling node to identify the trigger source of the "Reject New Shard Request Packet". The record identifier of the energy storage decline confirmation record is used to enable the scheduling node to associate the energy storage decline confirmation record corresponding to the "Reject New Shard Request Packet". After the "Reject New Shard Request Packet" is sent to the scheduling node, the scheduling node switches the vehicle node from a state that can receive new shards to a state that rejects new shards based on the "Reject New Shard Request Packet", and stops sending new encrypted shard packets to the vehicle node according to the new shard rejection state. The "accept new fragment" state indicates that the vehicle node still allows receiving new encrypted fragment packets, while the "reject new fragment" state indicates that the vehicle node has rejected receiving new encrypted fragment packets. The technical essence of stopping the distribution of new encrypted fragment packets is to cut off the entry point for subsequent external computing tasks to the vehicle node, rather than deleting the target computing code already running within the trusted sandbox. Therefore, the kernel module maintains the current execution thread of the target computing code, allowing the trusted sandbox to continue maintaining its running context within the existing task fragment range, thereby providing a continuous context source for subsequent normal completion, checkpoint saving, or thread freezing.

[0016] Preferably, the specific implementation process of step "when the available battery energy storage ratio continues to decrease to the second energy storage protection parameter, the kernel module determines that the hard interrupt condition is met and sends a thread freeze instruction to the trusted sandbox" is as follows: After the scheduling node stops issuing new encrypted fragment packets based on the rejection of new fragment request packets, the vehicle node continues to read the available battery energy storage ratio through the internal battery management bus and appends the subsequently formed available battery energy storage ratio sampling record to the energy storage decrease confirmation record. If the energy storage decrease confirmation record indicates that the available battery energy storage ratio continues to decrease under the new fragment rejection state, the kernel module reads the second energy storage protection parameter in the energy storage protection configuration record and performs a threshold comparison of the available battery energy storage ratio and the second energy storage protection parameter with the same dimension to form a hard interrupt condition determination record. The hard interrupt condition determination record is used to carry the trigger flag of the second energy storage protection parameter, the thread identifier of the currently executing thread, the identifier of the trusted sandbox isolation space, and the record identifier of the energy storage decline confirmation record. This makes the hard interrupt condition no longer an abstract security prompt, but a kernel-level control basis that can directly point to the currently executing thread. The trigger flag of the second energy storage protection parameter is used to enable the hard interrupt condition determination record to reflect that the thread freeze control limit has been triggered. The thread identifier of the currently executing thread is used to enable the hard interrupt condition determination record to correspond to the currently executing thread. The trusted sandbox isolation space identifier is used to enable the hard interrupt condition determination record to correspond to the trusted sandbox isolation runtime space where the currently executing thread is located. The record identifier of the energy storage decline confirmation record is used to enable the hard interrupt condition determination record to trace back to the energy storage decline confirmation record. The hard interrupt condition determination record indicates that when the hard interrupt condition is met, the kernel module generates a thread freeze instruction based on the thread identifier of the currently executing thread and sends the thread freeze instruction to the trusted sandbox. The thread freeze instruction includes at least a freeze reason field, a freeze object field, a context retention field, and a resource release field. The freeze reason field corresponds to the trigger flag of the second energy storage protection parameter, the freeze object field corresponds to the currently executing thread, the context retention field is used to instruct the trusted sandbox to retain the running context of the target computing code, and the resource release field is used to instruct the trusted sandbox to relinquish the underlying computing resources occupied by the currently executing thread.After receiving the thread freeze command, the trusted sandbox first locates the currently executing thread based on the freeze object field, and then saves the instruction location, runtime stack information, and temporary state within the sandbox of the target computation code based on the context retention field. The instruction location, runtime stack information, and temporary state within the sandbox together constitute the runtime context of the target computation code. This runtime context is used by the vehicle node for subsequent state verification processing before resuming operation, abandoning tasks, or sending back results. Subsequently, the trusted sandbox releases the currently executing thread from the underlying computing resources based on the resource release field, thereby forcibly suspending the currently executing thread of the target computation code. Through this process, when the available battery energy storage ratio enters the thread freeze range, the vehicle node does not rely on the scheduling node to issue control commands again. Instead, the kernel module directly drives the trusted sandbox to freeze the execution thread, enabling the runtime state of the target computation code to be switched to a suspended state in a timely manner when the vehicle's energy storage is insufficient. This allows the vehicle node to subsequently perform state verification processing before resuming operation, abandoning tasks, or sending back results based on the runtime context of the target computation code.

[0017] Optionally, the physical operating parameters include the physical junction temperature data of the main control chip node; During the process of running the target computation code, the vehicle node uses a kernel module to monitor the physical operating parameters; when the kernel module detects that the physical operating parameters trigger a hard interrupt condition, the vehicle node initiates a system interrupt to suspend the target computation code, including: The vehicle node is pre-configured in the kernel module with thermal warning limits and thermal threshold upper limits; The kernel module continuously collects the physical junction temperature data within a preset period; When the physical junction temperature data is continuously monitored to reach the thermal warning limit, the kernel module sends a frequency reduction control signal to the underlying clock controller; The clock controller lowers the operating clock frequency of the main control chip node based on the frequency reduction control signaling, and when the physical junction temperature data exceeds the upper limit of the thermal threshold, the kernel module determines to trigger the hard interrupt condition. The kernel module cuts off the computing resource supply to the trusted sandbox in order to forcibly suspend the target computing code; The kernel module migrates the current execution context of the target computation code to a non-volatile medium for storage; The current running context in the non-volatile medium serves as the basis for hot interrupt recovery when the target computation code resumes operation.

[0018] Preferably, the specific implementation process of step "the vehicle node pre-configures thermal warning limits and thermal threshold upper limits in the kernel module" is as follows: Before allowing the target computing code to enter the trusted sandbox isolated running space, the vehicle node first reads the locally stored vehicle safety constraint configuration data, and extracts the thermal management guard configuration item, the main control chip node specification identifier, the trusted sandbox isolated running space identifier, and the thread identifier of the currently executing thread from the vehicle safety constraint configuration data; the thermal management guard configuration item is used to limit the temperature boundary that the main control chip node allows the target computing code to occupy the underlying computing resources when the main control chip node opens idle computing power; the main control chip node specification identifier is used to enable the thermal management guard configuration item to correspond to the physical junction temperature data source of the main control chip node; the trusted sandbox isolated running space identifier is used to enable subsequent temperature control actions to correspond to the trusted sandbox isolated running space where the target computing code is running; and the thread identifier of the currently executing thread is used to enable subsequent temperature control actions to correspond to the currently executing thread. Subsequently, the vehicle node generates a thermal protection configuration record based on the thermal management guard configuration item, and writes the thermal warning limit and the thermal threshold upper limit into the thermal protection configuration record. The thermal protection configuration record is used to provide the kernel module with temperature boundaries that can be directly involved in the comparison process, enabling the kernel module to perform temperature layering control based on the thermal protection configuration record during the execution of the target computation code. The thermal warning limit is configured as a frequency reduction control trigger boundary in the thermal protection configuration record, which is used to limit the temperature position at which the frequency reduction control signal is triggered when the physical junction temperature data enters the thermal buffer. The thermal threshold upper limit is configured as a hard interrupt trigger boundary in the thermal protection configuration record, which is used to limit the temperature position at which the hard interrupt condition is triggered when the physical junction temperature data enters the thermal interrupt interval. The technical essence of the thermal warning limit is to reduce the operating clock frequency of the main control chip node in advance before the main control chip node enters the temperature state that requires the target computing code to be forcibly suspended, so as to reduce the thermal load generated when the currently executing thread continues to occupy the underlying computing resources; the technical essence of the thermal threshold upper limit is to enable the kernel module to directly trigger the hard interrupt condition when the physical junction temperature data has exceeded the temperature boundary that the main control chip node is allowed to continue to carry external computing tasks.The high-low layered configuration between the thermal warning limit and the thermal threshold upper limit is because when the vehicle node opens up idle computing power, it needs to maintain the operation of the target computing code corresponding to the received encrypted fragment packet, and also needs to promptly relinquish the underlying computing resources when the main control chip node enters a high-heat state. By configuring the thermal warning limit first and then configuring the thermal threshold upper limit, the kernel module can first perform frequency reduction control based on the thermal warning limit, and then perform hard interrupt condition judgment based on the thermal threshold upper limit, thus forming a clear sequential control relationship between thermal management processing and the target computing code operation processing.

[0019] Preferably, in the specific technical implementation of the step "the kernel module continuously collects the physical junction temperature data within a preset period", the vehicle node establishes a thermal monitoring association record with the current execution thread after the current execution thread starts. The thermal monitoring association record includes the main control chip node specification identifier, the trusted sandbox isolated running space identifier, the thread identifier of the current execution thread, the thermal warning limit, and the thermal threshold upper limit. The thermal monitoring association record is used to enable the kernel module to establish a correspondence between the physical junction temperature data of the main control chip node and the target calculation code that is running. The preset period is configured by the vehicle node according to the thermal management guard configuration item. The configuration principle is to ensure that the preset period can cover the temperature change process of the main control chip node under external computing task load, and that the interval between two adjacent acquisitions is less than the controllable response interval required for temperature change between the thermal warning limit and the upper limit of the thermal threshold. In one example, the preset period can be configured as multiple consecutive sampling windows, and a single sampling window can read the physical junction temperature data at millisecond or second intervals. This example is only used to illustrate the configuration method of the preset period and is not used to limit the protection scope of the preset period. The kernel module reads the on-chip sensor register data of the main control chip node according to the thermal monitoring association record, and performs temperature format conversion processing on the on-chip sensor register data to form the physical junction temperature data. The physical junction temperature data is not ambient temperature data, but digital temperature data characterizing the thermal state of hot spots inside the main control chip node. The physical junction temperature data can directly reflect the thermal load on the main control chip node when the currently executing thread occupies the underlying computing resources. The kernel module writes the generated physical junction temperature data, the corresponding sampling time, the thread identifier of the currently executing thread, and the identifier of the trusted sandbox isolated running space into the physical junction temperature data sampling record. This physical junction temperature data sampling record is used to convert the discretely acquired physical junction temperature data into a temperature data sequence with time order and thread affiliation. The temperature data sequence is composed of continuously generated physical junction temperature data sampling records. The kernel module subsequently reads the temperature data sequence and, based on the sequence, determines whether the physical junction temperature data continuously reaches the thermal warning limit or exceeds the thermal threshold upper limit, thereby avoiding directly changing the running state of the target calculation code based on a single temperature reading.

[0020] Preferably, the specific implementation process of step "when the physical junction temperature data is continuously monitored to reach the thermal warning limit, the kernel module sends a frequency reduction control signal to the underlying clock controller" is as follows: The kernel module reads the temperature data sequence within the preset period and performs sequential comparison processing on the physical junction temperature data in the temperature data sequence according to the sampling time to form a continuous thermal warning confirmation record. The continuous thermal warning confirmation record is not a single temperature exceedance mark, but a temperature trend confirmation result formed by the physical junction temperature data at multiple adjacent sampling times; after the temperature trend confirmation result is written into the continuous thermal warning confirmation record, it participates in the continuous judgment of the thermal warning limit. Specifically, when the physical junction temperature data at multiple adjacent sampling times all reach the thermal warning limit, or when the physical junction temperature data at multiple adjacent sampling times does not fall back below the thermal warning limit after reaching it, the kernel module marks the continuous thermal warning confirmation record as a continuous thermal warning state. The persistent thermal warning status in the continuous thermal warning confirmation record indicates that the main control chip node has entered the thermal buffer, and that the continued occupation of underlying computing resources by the currently executing thread will cause the physical junction temperature data to approach the upper limit of the thermal threshold. Subsequently, the kernel module generates a frequency reduction control signaling based on the continuous thermal warning confirmation record, the thermal monitoring association record, and the thermal protection configuration record. The frequency reduction control signaling includes the main control chip node specification identifier, the thread identifier of the currently executing thread, the trusted sandbox isolated running space identifier, the trigger flag of the thermal warning limit, and the target running clock frequency adjustment parameter. The target running clock frequency adjustment parameter is configured based on the difference between the physical junction temperature data and the thermal warning limit, the temperature rise direction of the physical junction temperature data between adjacent sampling times, and the duration of the currently executing thread's occupation of underlying computing resources, so that the target running clock frequency adjustment parameter can correspond to the thermal load state caused by the currently executing thread. The underlying clock controller mentioned here refers to a hardware control component that communicates with the clock domain management unit of the main control chip node and can adjust the operating clock frequency of the main control chip node. The kernel module sends the frequency reduction control signaling to the underlying clock controller because the target computation code runs in the trusted sandbox isolated runtime space, and the upper-layer task scheduling cannot directly change the operating clock frequency of the main control chip node. However, the kernel module can convert the continuous thermal warning confirmation record into an executable operating clock frequency adjustment action for the main control chip node through the underlying control path. Through this processing, when the physical junction temperature data reaches the thermal warning limit, the vehicle node first reduces the thermal load instead of immediately suspending the target computation code, allowing the current task segment corresponding to the encrypted fragment packet to continue running under lower thermal load conditions.

[0021] Preferably, the specific implementation process of step "the clock controller lowers the operating clock frequency of the main control chip node based on the frequency reduction control signaling, and when the physical junction temperature data exceeds the upper limit of the thermal threshold, the kernel module determines to trigger the hard interrupt condition" is as follows: After receiving the frequency reduction control signaling, the clock controller first parses the main control chip node specification identifier and the target operating clock frequency adjustment parameter in the frequency reduction control signaling, and locates the clock domain corresponding to the main control chip node according to the main control chip node specification identifier; the clock domain is used to express the operating clock frequency control range of the main control chip node that is adjusted by the clock controller. Subsequently, the clock controller performs a step-wise reduction process on the operating clock frequency of the main control chip node according to the target operating clock frequency adjustment parameter to form a frequency reduction execution record. The frequency reduction execution record includes the signaling identifier of the frequency reduction control signaling, the reduced operating clock frequency, the frequency reduction start time, the frequency reduction completion time, and the thread identifier of the currently executing thread. The signaling identifier of the frequency reduction control signaling is used to enable the frequency reduction execution record to correspond to the frequency reduction control signaling that triggered this frequency reduction process. The reduced operating clock frequency is used to record the frequency state after the clock controller completes the step-down process. The frequency reduction start time and the frequency reduction completion time are used to enable the kernel module to determine the time interval corresponding to the frequency reduction execution record. The thread identifier of the currently executing thread is used to enable the kernel module to associate the operating clock frequency reduction action with the currently executing thread. The technical essence of the clock controller reducing the operating clock frequency of the main control chip node is to reduce the computation switching frequency provided by the main control chip node to the currently executing thread per unit time, thereby reducing the thermal load formed during the continued execution of the target computation code. This process is different from directly deleting the target computation code or directly discarding the computation result. Instead, it preserves the runnable state of the currently executing thread while the physical junction temperature data is still within the thermal buffer. After reading the frequency reduction execution record, the kernel module continues to collect the physical junction temperature data through the temperature data sequence and appends the frequency-reduced physical junction temperature data to the continuous thermal warning confirmation record. If the continuous thermal warning confirmation record indicates that the physical junction temperature data continues to rise after frequency reduction and exceeds the thermal threshold upper limit, the kernel module reads the thermal threshold upper limit from the thermal protection configuration record and writes the physical junction temperature data exceeding the thermal threshold upper limit, the frequency reduction execution record, and the thread identifier of the currently executing thread into the thermal interrupt determination record. The thermal interrupt determination record is used to carry the technical fact that the hard interrupt trigger boundary has been exceeded and directly points the hard interrupt condition to the currently executing thread and the trusted sandbox isolated running space.The kernel module determines the trigger condition for the hard interrupt based on the thermal interrupt determination record because the frequency reduction control can no longer bring the physical junction temperature data back below the thermal warning limit. Continuing to maintain the current executing thread will put the main control chip node in a hot state that is not suitable for carrying external computing tasks. Therefore, it is necessary to switch from the frequency reduction control to the suspension control.

[0022] Preferably, the specific implementation process of step "the kernel module cuts off the computing resource supply of the trusted sandbox to forcibly suspend the target computing code" is as follows: When the hot interrupt determination record indicates that the hard interrupt condition has been triggered, the kernel module locates the trusted sandbox isolated runtime space running the target computing code based on the trusted sandbox isolated runtime space identifier in the hot interrupt determination record, and locates the current execution thread based on the thread identifier of the current execution thread in the hot interrupt determination record. Subsequently, the kernel module generates a computing resource supply cutoff instruction and writes the computing resource supply cutoff instruction into a resource control queue associated with the trusted sandbox isolated runtime space; the resource control queue is used to carry the resource control instructions that the trusted sandbox isolated runtime space needs to execute. After the computing resource supply cutoff instruction is written into the resource control queue, it is read and executed by the trusted sandbox. The computing resource supply cutoff instruction includes the trusted sandbox isolated runtime space identifier, the thread identifier of the current execution thread, the trigger flag of the hot threshold upper limit, and a computing core relinquishment flag. The computing core relinquishment flag is used to instruct the trusted sandbox to release the current execution thread from its occupation of the underlying computing resources. After the trusted sandbox reads the computing resource supply cutoff command, it first confirms the trusted sandbox isolated running space corresponding to the command based on the trusted sandbox isolated running space identifier. Then, it suspends the instruction dispatching action of the currently executing thread based on the thread identifier and revoks the computing core usage rights allocated to the currently executing thread based on the computing core relinquishment flag, thus forming a computing resource supply cutoff record. This record records that the instruction dispatching action of the currently executing thread has stopped, the underlying computing resources occupied by the currently executing thread have been released, and the target computing code has entered a suspended state. The technical essence of the kernel module cutting off the computing resource supply of the trusted sandbox is to block the target computing code from continuing execution on the underlying computing resource allocation path after the physical junction temperature data of the main control chip node exceeds the upper limit of the thermal threshold, rather than relying on the target computing code to exit on its own. This process enables the vehicle node to directly relinquish the underlying computing resources in a thermal interruption state and allows the main control chip node to exit from the continuous thermal load caused by external computing tasks. By using the computing resource supply cutoff record, the kernel module can subsequently determine whether the currently executing thread has been suspended, and use the computing resource supply cutoff record as the state basis for the target computing code before the current running context migration.

[0023] Preferably, the specific implementation process of step "the kernel module migrates the current running context of the target computing code to a non-volatile medium for storage" is as follows: After the computing resource supply cutoff record is formed, the kernel module reads the computing resource supply cutoff record and confirms based on the computing resource supply cutoff record that the currently executing thread has stopped the instruction dispatching action; subsequently, the kernel module extracts the current running context of the target computing code from the trusted sandbox isolated running space. The current execution context of the target computation code includes instruction location, execution stack information, register context, sandbox temporary state, encrypted fragment packet identifier, and current task fragment progress marker. The instruction location records the position of the next instruction to be executed when the target computation code is suspended. The execution stack information records the call level when the target computation code is suspended. The register context records the register state when the current execution thread is suspended. The sandbox temporary state records the intermediate state within the trusted sandbox isolated execution space that has not yet been returned. The encrypted fragment packet identifier enables the current execution context of the target computation code to correspond to the encrypted fragment packet issued by the scheduling node. The current task fragment progress marker ensures that subsequent resumption of execution allows the continuation of the processing progress already completed by the target computation code. The kernel module encapsulates the current execution context of the target computation code into a current execution context migration record and performs integrity marking processing on the current execution context migration record to ensure that the current execution context migration record can be read and verified after being written to the non-volatile medium. Subsequently, the kernel module writes the current runtime context migration record to the non-volatile medium and writes back the write location identifier in the non-volatile medium to the hot interruption determination record. The write location identifier is used to express the storage location of the current runtime context migration record in the non-volatile medium, and the hot interruption determination record establishes an association with the current runtime context migration record through the write location identifier. The non-volatile medium is used to continue to store the current runtime context migration record after the vehicle node experiences a power outage, hibernation, or restart. The kernel module migrates the current runtime context of the target computation code to the non-volatile medium for storage because, under hot interruption conditions, the trusted sandbox isolated runtime space has released the current execution thread from the underlying computing resources. If stored only in the volatile storage area, the current runtime context of the target computation code is easily lost when resources are released. Through the current runtime context migration record, the vehicle node can retain the recoverable state of the target computation code without re-issuing the encrypted fragment packet, and establishes a traceable data connection between hot interruption processing and subsequent recovery.

[0024] Preferably, the specific implementation process of step "the current running context in the non-volatile medium serves as the basis for thermal interruption recovery of the target computing code" is as follows: After the physical junction temperature data falls back to the temperature range that allows for resumption of operation, the kernel module rereads the thermal protection configuration record and confirms through the temperature data sequence that the physical junction temperature data of the main control chip node has left the thermal interruption range; the temperature range that allows for resumption of operation is pre-written into the thermal protection configuration record according to the thermal management guard configuration item, and is used to limit the temperature boundary at which the target computing code can re-enter the trusted sandbox isolated running space for execution after a thermal interruption. Subsequently, the kernel module reads the current running context migration record from the non-volatile medium according to the write position identifier in the thermal interruption determination record, and performs integrity verification processing on the current running context migration record to confirm that the current running context migration record has not experienced data loss during storage. After the current runtime context migration record undergoes integrity verification, the kernel module reads the instruction location, runtime stack information, register context, sandbox temporary state, encrypted fragment packet identifier, and current task segment progress marker from the current runtime context migration record. It then reloads the instruction location, runtime stack information, register context, sandbox temporary state, encrypted fragment packet identifier, and current task segment progress marker into the trusted sandbox isolated runtime space. After the trusted sandbox isolated runtime space is reloaded, the kernel module confirms, based on the encrypted fragment packet identifier, that the target computation code resuming execution still corresponds to the originally received encrypted fragment packet, and confirms the resumed execution location of the target computation code based on the current task segment progress marker. The instruction location, runtime stack information, and register context are used to restore the execution state of the currently executing thread, and the sandbox temporary state is used to restore the intermediate state of the target computation code before it is returned. The technical essence of using the current running context in the non-volatile medium as the basis for thermal interruption recovery is to save the execution state at the moment of thermal interruption as verifiable, rewritable, and reloadable state data. This allows the target computation code to resume execution from its suspended position after temperature conditions recover, rather than re-executing already completed task segments. Therefore, when the physical junction temperature exceeds the upper limit of the thermal threshold, the vehicle node can relinquish underlying computing resources and, after the physical junction temperature returns to normal, restore the running state of the target computation code based on the thermal interruption recovery criteria. This establishes a continuous technical processing relationship between the main control chip node's thermal management, the suspension processing of the trusted sandbox isolated running space, and the resumption of the target computation code.

[0025] Optionally, the physical operating parameters include autonomous driving intent activation signaling fed back by vehicle body sensors; During the process of running the target computation code, the vehicle node uses a kernel module to monitor the physical operating parameters; when the kernel module detects that the physical operating parameters trigger a hard interrupt condition, the vehicle node initiates a system interrupt to suspend the target computation code, including: The vehicle node is pre-configured with an absolute latency limit in the kernel module; The vehicle node continuously parses the autonomous driving intent activation signaling broadcast by the vehicle chassis network; When the autonomous driving intention activation signaling is captured, the kernel module determines that the hard interrupt condition is triggered, and then the kernel module injects a preset level interrupt vector into the trusted sandbox within the absolute latency limit; The trusted sandbox responds to the preset level interrupt vector to terminate the execution flow of the target computing code and release the corresponding hardware computing core resources; The vehicle node will allocate the released hardware computing core resources to the local autonomous driving perception and decision-making unit. The autonomous driving perception and decision-making unit performs local autonomous driving perception and decision-making processing based on the hardware computing core resources.

[0026] Preferably, the specific implementation process of step "the vehicle node pre-configures the absolute latency limit in the kernel module" is as follows: Before allowing the target computation code to enter the trusted sandbox isolated running space, the vehicle node first reads the locally stored vehicle safety constraint configuration data, and extracts the autonomous driving priority configuration item, the vehicle chassis network interface identifier, the trusted sandbox isolated running space identifier, and the thread identifier of the currently executing thread from the vehicle safety constraint configuration data; the autonomous driving priority configuration item is used to limit the priority resource transfer boundary of the vehicle node to the local autonomous driving perception decision processing when opening idle computing power; the vehicle chassis network interface identifier is used to enable the kernel module to locate the access source of the autonomous driving intention activation signal fed back by the vehicle body sensor; the trusted sandbox isolated running space identifier is used to enable the subsequent interrupt injection action to correspond to the trusted sandbox isolated running space where the target computation code is running; and the thread identifier of the currently executing thread is used to enable the subsequent interrupt injection action to correspond to the currently executing thread. Subsequently, the vehicle node generates an absolute latency configuration record based on the autonomous driving priority configuration item, and writes the absolute latency limit into the absolute latency configuration record. The absolute latency configuration record is used to provide the kernel module with the maximum allowable response time from capturing the autonomous driving intent activation signaling to releasing the hardware computing core resources. The maximum response time further participates in the latency constraint control of the kernel module, enabling the kernel module to execute the latency constraint control based on the absolute latency configuration record during the execution of the target computing code. The configuration principle of the absolute latency limit is to cover all control time required for the kernel module to parse the autonomous driving intent activation signaling, determine the hard interrupt condition, inject a preset level interrupt vector into the trusted sandbox, and release the corresponding hardware computing core resources from the trusted sandbox, and to ensure that all control time is less than the upper limit of the local autonomous driving perception decision processing's occupation and waiting for underlying computing resources. The upper limit of occupation and waiting is provided by the autonomous driving priority configuration item and is established in correspondence with the absolute latency limit in the absolute latency configuration record. The technical essence of the absolute latency limit is not a regular timing parameter, but rather a transformation of the resource response requirements of local autonomous driving perception and decision-making processing into an interrupt triggering time boundary executable by the kernel module. Through the absolute latency configuration record, the vehicle node can elevate the resource requests of local autonomous driving perception and decision-making processing to a kernel-level control basis that can directly suppress the continued execution of the target computing code while external computing tasks occupy the hardware computing core resources. The kernel-level control basis subsequently participates in the formation of the autonomous driving intent capture record, the generation of the interrupt vector injection record, and the formation of the hardware computing core resource release record, thereby reducing the interference of the opening of idle computing power on the vehicle's own perception and decision-making resource calls during the new energy vehicle's onboard process.

[0027] Preferably, in the specific technical implementation of the step "the vehicle node continuously parses the autonomous driving intent activation signaling broadcast by the vehicle chassis network", after the current execution thread starts, the vehicle node establishes an autonomous driving intent monitoring association record with the absolute latency configuration record and the current execution thread; the autonomous driving intent monitoring association record includes the vehicle chassis network interface identifier, the trusted sandbox isolated running space identifier, the thread identifier of the current execution thread, the absolute latency limit, and the autonomous driving priority configuration item. The autonomous driving intent monitoring association record is used to enable the kernel module to establish a correspondence between the autonomous driving intent activation signaling broadcast by the vehicle chassis network and the target computing code that is running. The vehicle-to-chassis network consists of data communication links connecting the vehicle nodes to the body sensors, chassis status acquisition components, vehicle motion control components, and local autonomous driving perception and decision-making units. Its technical essence is a low-latency in-vehicle data channel used to transmit the vehicle's operating status and driving intention status. The low-latency in-vehicle data channel establishes a listening relationship with the kernel module through the vehicle-to-chassis network interface identifier, enabling the kernel module to continuously read the broadcast content of the vehicle-to-chassis network during the execution of the currently executing thread. After the vehicle-to-chassis network broadcasts the autonomous driving intent activation signaling, the kernel module listens to the corresponding vehicle-to-chassis network message frame through the vehicle-to-chassis network interface identifier, and extracts the intent source field, intent type field, intent trigger time field, and resource request field from the vehicle-to-chassis network message frame. The intent source field is used to express the feedback source of the autonomous driving intent activation signaling, the intent type field is used to express the perception decision initiation category corresponding to the autonomous driving intent activation signaling, the intent trigger time field is used to express the time position of the autonomous driving intent activation signaling entering the vehicle-to-chassis network, and the resource request field is used to express the hardware computing core resource requirements of the local autonomous driving perception decision processing. The kernel module performs field caliber verification on the intent source field, intent type field, intent trigger time field, and resource request field to form an autonomous driving intent activation signaling parsing record. The autonomous driving intent activation signaling parsing record is used to transform the autonomous driving intent activation signaling from the original field state in the vehicle-to-chassis network message frame into a structured state that can participate in the hard interrupt condition determination. The continuous parsing does not involve reading the vehicle chassis network message frames all at once. Instead, it involves continuously listening to the vehicle chassis network message frames according to the message refresh rhythm of the vehicle chassis network while the current execution thread of the target calculation code is running, and writing the continuously formed autonomous driving intent activation signaling parsing records into the autonomous driving intent parsing sequence.The autonomous driving intent parsing sequence consists of multiple autonomous driving intent activation signaling parsing records arranged according to the intent trigger time field. Subsequently, the kernel module captures the autonomous driving intent activation signaling based on the autonomous driving intent parsing sequence to reduce the missed resource requests for local autonomous driving perception and decision processing during the execution of the target computing code.

[0028] Preferably, the specific implementation process of step "when the autonomous driving intention activation signaling is captured, the kernel module determines that the hard interrupt condition is triggered, and injects a preset level interrupt vector into the trusted sandbox within the absolute latency limit" is as follows: The kernel module reads the autonomous driving intention parsing sequence and performs intention validity confirmation processing on the autonomous driving intention activation signaling parsing record in the autonomous driving intention parsing sequence to form an autonomous driving intention capture record. The intention validity confirmation processing includes confirming, based on the intention source field, that the autonomous driving intention activation signaling originates from a vehicle sensor or a vehicle-to-chassis network broadcast source associated with a local autonomous driving perception decision unit; confirming, based on the intention type field, that the autonomous driving intention activation signaling corresponds to the startup requirement of a local autonomous driving perception decision processing; and confirming, based on the resource request field, that the local autonomous driving perception decision processing needs to occupy the hardware computing core resources. After the confirmation result formed by the intention validity confirmation processing is written into the autonomous driving intention capture record, the kernel module associates the autonomous driving intention capture record with the autonomous driving intention monitoring association record to directly point the hard interrupt condition to the trusted sandbox isolated running space and the current execution thread. After the kernel module captures the autonomous driving intent activation signaling, it determines that the hard interrupt condition is triggered because the autonomous driving intent activation signaling indicates that the vehicle itself has generated an immediate resource requirement for local autonomous driving perception and decision-making processing. Continuing to maintain the target computing code occupying the hardware computing core resources would delay the execution of the local autonomous driving perception and decision-making processing. Subsequently, the kernel module reads the absolute latency limit value in the absolute latency configuration record and uses the intent trigger time field in the autonomous driving intent capture record as the timing start point to generate an interrupt vector injection record. The interrupt vector injection record includes the trusted sandbox isolated running space identifier, the thread identifier of the currently executing thread, the preset level interrupt vector, the absolute latency limit value, and the injection deadline time. The injection deadline time is jointly determined by the intent trigger time field and the absolute latency limit value, and the injection deadline time is used to limit the latest time position for the preset level interrupt vector to enter the trusted sandbox isolated running space. The preset level interrupt vector is pre-written into the absolute latency configuration record according to the autonomous driving priority configuration item. The technical essence of the preset level interrupt vector is non-delayable interrupt control data for the trusted sandbox isolated running space. The non-delayable interrupt control data is used to instruct the trusted sandbox to terminate the running process of the target computing code first. The non-delayable interrupt control data also establishes a correspondence with the currently executing thread through the interrupt vector injection record.The kernel module injects the preset level interrupt vector into the trusted sandbox within the absolute latency limit, so that the hard interrupt condition can be transformed into a termination control action that the trusted sandbox can execute within the specified low-level response window; the low-level response window is jointly defined by the timing start point, the absolute latency limit and the injection end time, and subsequently participates in the timing verification of the target computing code termination record and the hardware computing core resource release record.

[0029] Preferably, the specific implementation process of step "the trusted sandbox responds to the preset level interrupt vector to terminate the execution flow of the target computing code and release the corresponding hardware computing core resources" is as follows: After receiving the preset level interrupt vector, the trusted sandbox first reads the trusted sandbox isolated running space identifier in the interrupt vector injection record and confirms the trusted sandbox isolated running space corresponding to the preset level interrupt vector; subsequently, the trusted sandbox reads the thread identifier of the currently executing thread in the interrupt vector injection record and locates the currently executing thread that is running the target computing code accordingly. After locating the currently executing thread, the trusted sandbox suspends the instruction dispatching action of the currently executing thread and terminates the execution flow of the target computation code to form a target computation code termination record. The target computation code termination record includes a trigger flag of the preset level interrupt vector, the thread identifier of the currently executing thread, the task handle of the target computation code, and a termination time field. The trigger flag of the preset level interrupt vector enables the target computation code termination record to trace back to the interrupt vector injection record. The task handle of the target computation code enables the target computation code termination record to correspond to the target computation code formed after the encrypted fragment packet is decrypted. The termination time field enables the target computation code termination record to participate in the timing verification of the underlying response window. The target computation code termination record records that the target computation code has entered a terminated state due to resource requests from the local autonomous driving perception and decision-making processing. Subsequently, the trusted sandbox, based on the target computation code termination record, withdraws the hardware computing core resources allocated to the currently executing thread and writes the withdrawal result to the hardware computing core resource release record. The hardware computing core resource release record includes the resource identifier of the hardware computing core resource, the thread identifier of the currently executing thread, the identifier of the trusted sandbox isolated runtime space, and a release time field. The resource identifier of the hardware computing core resource is used to enable the hardware computing core resource release record to identify the hardware computing core resource that has been released from occupation, and the release time field is used to enable the hardware computing core resource release record to participate in the timing verification of the underlying response window. The hardware computing core resource release record indicates that the hardware computing core resource has been released from the execution flow of the target computation code. The technical essence of the trusted sandbox responding to the preset level interrupt vector is to prevent external computation tasks from continuing to occupy underlying computation resources when the vehicle itself generates local autonomous driving perception and decision-making processing requirements, and to allow the hardware computing core resources to transition from the trusted sandbox isolated runtime space to a reallocatable state in a recordable and traceable manner.This process differs from waiting for the target computation code to finish executing before releasing resources. Instead, it directly terminates the currently executing thread based on the interrupt vector injection record, thereby enabling the autonomous driving intent activation signaling to drive the trusted sandbox to complete resource transfer at the kernel level.

[0030] Preferably, in the specific technical implementation of the step "the vehicle node allocates the released hardware computing core resources to the local autonomous driving perception and decision-making unit", the vehicle node reads the hardware computing core resource release record and confirms that the hardware computing core resources are in a reallocatable state based on the resource identifier of the hardware computing core resources in the hardware computing core resource release record; subsequently, the vehicle node reads the resource request field in the autonomous driving intent capture record and determines the number of hardware computing core resources, the type of hardware computing core resources, and the resource occupation duration required for local autonomous driving perception and decision-making processing based on the resource request field, so as to form an autonomous driving resource request parsing record. The number of hardware computing core resources is used to express the range of the number of hardware computing core resources that the local autonomous driving perception and decision-making processing needs to call; the type of hardware computing core resources is used to express the computing type of the hardware computing core resources that the local autonomous driving perception and decision-making processing needs to call; and the resource occupation duration is used to express the continuous occupation time of the hardware computing core resources by the local autonomous driving perception and decision-making processing. The number of hardware computing core resources, the type of hardware computing core resources, and the resource occupation duration are jointly written into the autonomous driving resource request parsing record and serve as the resource allocation basis for the matching processing of the hardware computing core resource release record. The autonomous driving resource request parsing record is used to convert the resource request content in the autonomous driving intent activation signaling into an executable resource allocation basis. The vehicle node matches the autonomous driving resource request parsing record with the hardware computing core resource release record. When the hardware computing core resources in the hardware computing core resource release record meet the quantity and type of the hardware computing core resources in the autonomous driving resource request parsing record, the vehicle node generates a hardware computing core resource allocation record and sends the hardware computing core resource allocation record to the local autonomous driving perception and decision unit. The hardware computing core resource allocation record includes the resource identifier of the hardware computing core resource, the record identifier of the autonomous driving intent capture record, the record identifier of the autonomous driving resource request parsing record, and an allocation effective time field. The record identifier of the autonomous driving intent capture record is used to ensure that the hardware computing core resource allocation record can be mapped to the autonomous driving intent capture record that triggered resource transfer. The record identifier of the autonomous driving resource request parsing record is used to ensure that the hardware computing core resource allocation record can be mapped to the autonomous driving resource request parsing record participating in the matching process. The allocation effective time field is used to express the time position when the hardware computing core resource is transferred to the local autonomous driving perception and decision processing. The hardware computing core resource allocation record is used to allocate the hardware computing core resources that have been released from the execution flow of the target computing code to the local autonomous driving perception and decision-making unit.The technical essence of the local autonomous driving perception and decision-making unit is that it is a functional unit within the vehicle node used to receive vehicle sensor data and execute local autonomous driving perception and decision-making processing. It has a direct data processing relationship with the vehicle chassis network and the hardware computing core resources. Through the hardware computing core resource allocation record, the vehicle node can directly connect the resource release result caused by the preset level interrupt vector to the resource supply action of the local autonomous driving perception and decision-making processing, so that the underlying computing resources yielded by the target computing code are used for the perception and decision-making tasks of the vehicle itself.

[0031] Preferably, the specific implementation process of step "the autonomous driving perception decision unit performs local autonomous driving perception decision processing based on the hardware computing core resources" is as follows: After receiving the hardware computing core resource allocation record, the local autonomous driving perception decision unit calls the hardware computing core resources according to the resource identifier of the hardware computing core resources in the hardware computing core resource allocation record, and reads the vehicle sensor data of the corresponding time period according to the intention trigger time field in the autonomous driving intention capture record; the vehicle sensor data includes digital perception data used to characterize the vehicle's surrounding environment, vehicle motion state, and chassis feedback state. After the vehicle sensor data enters the local autonomous driving perception decision unit through the vehicle chassis network, the local autonomous driving perception decision unit performs time alignment processing on the vehicle sensor data to form vehicle sensor aligned data. The vehicle sensor aligned data is used to enable vehicle sensor data from different sources to participate in subsequent processing at the same perception decision time. The vehicle sensor aligned data subsequently enters target object recognition processing, motion state estimation processing, and driving intention judgment processing. Subsequently, the local autonomous driving perception and decision-making unit performs target object recognition processing, motion state estimation processing, and driving intent judgment processing on the vehicle sensor alignment data based on the hardware computing core resources, to form a local autonomous driving perception and decision-making result. The target object recognition processing is used to extract the state of targets around the vehicle from the vehicle sensor alignment data; the motion state estimation processing is used to extract the vehicle's own motion constraint state from the vehicle sensor alignment data; and the driving intent judgment processing is used to generate local driving control candidate actions based on the state of targets around the vehicle and the vehicle's own motion constraint state. The local autonomous driving perception and decision-making result includes the state of targets around the vehicle, the vehicle's own motion constraint state, and the local driving control candidate actions, and provides a data foundation for subsequent control processing of the vehicle itself. The technical essence of the local autonomous driving perception and decision-making processing is that, without relying on the scheduling node to issue control commands again, the hardware computing core resources are transferred from the execution flow of the target computing code to the perception and decision-making processing flow of the vehicle itself, so that external computing tasks give up underlying computing resources in autonomous driving intent activation scenarios. Thus, a continuous data processing relationship is formed between the absolute latency configuration record, the autonomous driving intent parsing sequence, the autonomous driving intent capture record, the interrupt vector injection record, the target computation code termination record, the hardware computing core resource release record, the autonomous driving resource request parsing record, the hardware computing core resource allocation record, and the local autonomous driving perception decision result. This enables the unified opening and scheduling method of idle computing power in new energy vehicles to maintain the resource priority of vehicle-side perception decision processing while opening up idle computing power.

[0032] Optionally, the vehicle node invokes the abstraction layer hardware translation component in the hardware interface to perform a conversion on the physical operating parameters to generate computing power feature words, including: The vehicle node reads the chip manufacturer identification parameter and physical memory capacity parameter stored in the local system register; The vehicle node inputs the physical operating parameters, the chip manufacturer identification parameters, and the physical memory capacity parameters into the pre-deployed abstraction layer hardware translation component; The abstract layer hardware translation component performs low-level field mapping processing on the input data according to the pre-agreed general description protocol rules of the communication network, and encapsulates the processing results based on the low-level field mapping processing to generate the computing power feature word in a unified format that transcends hardware differences. The computing power feature word includes a physical operating parameter field, a chip manufacturer identification field, and a physical memory capacity field, so that the scheduling node can identify the available computing status of the vehicle node based on the computing power feature word.

[0033] Preferably, the specific implementation process of step "the vehicle node reads the chip manufacturer identification parameters and physical memory capacity parameters stored in the local system register" is as follows: After obtaining the physical operating parameters, the vehicle node first establishes a hardware basic identification reading record, and establishes a correspondence between the hardware basic identification reading record and the physical operating parameters, hardware interface, abstract layer hardware translation component, and the subsequently generated computing power feature word. The hardware basic identification reading record is used to carry the vehicle node's reading process of underlying hardware identity data and local storage resource boundary data, so that the subsequent underlying field mapping processing can simultaneously have the source of operating status, the source of underlying hardware identity data, and the source of local storage resource boundary data. Subsequently, the vehicle node accesses the local system register through the hardware interface and reads the chip manufacturer identification parameter and physical memory capacity parameter from the local system register. The local system register is the storage location where the vehicle node writes underlying hardware description data during startup and hardware initialization. The chip manufacturer identification parameter in the local system register is used to express the manufacturer and chip platform affiliation of the main control chip node mounted on the vehicle node. The physical memory capacity parameter in the local system register is used to express the local storage resource boundary that the vehicle node can currently be addressed by the underlying hardware and allocated to the trusted sandbox isolated operating space. The technical essence of the chip manufacturer identification parameter is not ordinary name information, but a hardware identity index that determines which type of field mapping should be used by the abstraction layer hardware translation component. If the chip manufacturer identification parameter is missing, the abstraction layer hardware translation component can only receive the physical operating parameters, but cannot determine which underlying chip platform the physical operating parameters come from. Therefore, it is difficult to convert the underlying hardware description data of different manufacturers and architectures into the computing power feature word in a unified format that transcends hardware differences. The technical essence of the physical memory capacity parameter is to describe the local storage resource boundary that determines whether the target computing code can be loaded, decrypted, and run within the trusted sandbox isolated operating space. Without the physical memory capacity parameter, even if the scheduling node can identify the vehicle node's battery level, thermal status, or idle status through the physical operating parameters, it cannot determine whether the vehicle node has the storage conditions to carry the data block corresponding to the encrypted fragment packet and the running context of the target computing code. Therefore, the vehicle node reads the chip manufacturer identification parameter and the physical memory capacity parameter to ensure that the computing power feature word not only reflects the real-time physical status of the vehicle node but also its underlying hardware identity data and local storage resource boundary. This allows the scheduling node to subsequently identify the available computing status of different vehicle nodes using the same criteria based on the computing power feature word.The hardware basic identification reading record is continued to be read when the hardware translation input record is subsequently formed, so that the source of the chip manufacturer identification parameter and the physical memory capacity parameter can form a traceable data connection relationship with the hardware translation input record.

[0034] Preferably, in the specific technical implementation of the step "the vehicle node inputs the physical operating parameters, the chip manufacturer identification parameters, and the physical memory capacity parameters into the pre-deployed abstraction layer hardware translation component," after reading the chip manufacturer identification parameters and the physical memory capacity parameters, the vehicle node reads the hardware basic identification read record and writes the physical operating parameters, chip manufacturer identification parameters, and physical memory capacity parameters from the hardware basic identification read record into the hardware translation input record. The hardware translation input record is used to uniformly carry the real-time physical state of the vehicle node, the manufacturer source of the main control chip node, and the local storage resource boundary in the same input structure, enabling the abstraction layer hardware translation component to read complete underlying hardware description data at the same processing entry point. The physical operating parameters in the hardware translation input record are used to express the current operating state of the vehicle node, indicating whether it can open up idle computing power. The chip manufacturer identification parameters in the hardware translation input record are used to express which type of field mapping caliber the vehicle node adapts to. The physical memory capacity parameters in the hardware translation input record are used to express the local storage resource boundary that the vehicle node can provide for the trusted sandbox isolated operating space. The abstraction layer hardware translation component is pre-deployed in the data reporting path between the vehicle node's hardware interface and the scheduling node, and is configured before the vehicle node connects to the computing power scheduling network. This configuration process includes establishing a hardware translation component deployment record, writing the component version field, readable local system register range, acceptable physical operating parameter types, identifiable chip manufacturer identifier parameter types, identifiable physical memory capacity parameter types, and the general description protocol rules into the hardware translation component deployment record. This hardware translation component deployment record enables the abstraction layer hardware translation component to identify the source and meaning of each field when receiving the hardware translation input record, rather than encapsulating the physical operating parameters, chip manufacturer identifier parameters, and physical memory capacity parameters as indiscriminate data. The vehicle nodes input the hardware translation input records to the abstract layer hardware translation component because the underlying hardware interfaces, register field names, local storage resource boundary representation methods, and internal encoding methods of physical operating parameters are inconsistent among different brands of vehicle nodes. If these underlying hardware description data are directly sent to the scheduling node, the scheduling node would need to understand the underlying hardware differences of each type of vehicle node, making it difficult to form a unified scheduling mechanism. Through the pre-deployed abstract layer hardware translation component, the vehicle nodes can complete the hardware difference translation preprocessing locally, so that the scheduling node receives not scattered underlying hardware raw fields, but computing power feature words that can be parsed according to the general description protocol rules. This allows the idle computing power of cross-vendor vehicle nodes to enter the same scheduling caliber.The hardware translation component deployment record is also used to establish a fixed calling relationship between the general description protocol rule and the abstract layer hardware translation component. Subsequently, when the abstract layer hardware translation component performs the underlying field mapping process, it can read the general description protocol rule based on the hardware translation component deployment record.

[0035] Preferably, the specific implementation process of step "the abstract layer hardware translation component performs low-level field mapping processing on the input data according to the pre-agreed general description protocol rules of the communication network, and encapsulates the processing result based on the low-level field mapping processing to generate the computing power feature word in a unified format that transcends hardware differences" is as follows: The abstract layer hardware translation component reads the hardware translation input record, and calls the field mapping caliber record corresponding to the chip manufacturer identification parameter according to the chip manufacturer identification parameter in the hardware translation input record; the field mapping caliber record is pre-configured according to the general description protocol rules, and the field mapping caliber record is used to record the correspondence between the original fields of different low-level hardware and the unified description fields. The general description protocol rules are data description rules pre-agreed upon by the vehicle node and the scheduling node before they access the computing power scheduling network. These rules include field name definitions, field order definitions, field data type definitions, field dimension definitions, and field integrity verification definitions. The field name definitions enable mapping of the physical operating parameters, chip manufacturer identification parameters, and physical memory capacity parameters to the physical operating parameter field, chip manufacturer identification field, and physical memory capacity field, respectively. The field order definitions enable the scheduling node to parse the computing power feature word in a fixed reading order. The field data type definitions enable the scheduling node to distinguish between ratio data, enumerated data, and capacity data. The field dimension definitions prevent the scheduling node from incorrectly comparing capacity values, ratios, or status values ​​from different sources. The field integrity verification definitions enable the scheduling node to determine whether any fields are missing during the transmission of the computing power feature word. The abstract layer hardware translation component, according to the field mapping standard, performs the underlying field mapping processing on the physical operating parameters, chip manufacturer identification parameters, and physical memory capacity parameters in the hardware translation input record to form the underlying field mapping processing result. The underlying field mapping processing result includes the physical operating parameter field, chip manufacturer identification field, and physical memory capacity field, all of which have undergone field name conversion, field order arrangement, field data type labeling, and field dimension normalization. The technical essence of the underlying field mapping processing result is to convert the original underlying hardware fields, which are difficult for different vehicle nodes to directly recognize, into unified description fields that the scheduling node can uniformly parse. Subsequently, the abstract layer hardware translation component performs encapsulation processing on the underlying field mapping processing result according to the general description protocol rules to form the computing power feature word. The encapsulation processing includes writing field boundary markers, writing field version markers, writing field integrity verification markers, and writing vehicle node identifiers, enabling the computing power feature word to be received, parsed, and verified by the scheduling node in the communication network.The unified format that transcends hardware differences refers to the separation of the computing power feature word from the chip manufacturer, underlying register naming, and hardware interface implementation of specific vehicle nodes in terms of outer field structure, field reading order, field unit caliber, and field verification method. Through this unified format, the scheduling node does not need to read the original underlying hardware fields of different vehicle nodes separately, but instead directly constructs the scheduling basis for the encrypted fragment packet based on the computing power feature word. The underlying field mapping processing result is transformed into the computing power feature word after the encapsulation process. The physical operating parameter field, the chip manufacturer identification field, and the physical memory capacity field in the computing power feature word subsequently continue to participate in the formation of the available computing status identification record.

[0036] Preferably, in the specific technical implementation of the step "the computing power feature word includes a physical operating parameter field, a chip manufacturer identification field, and a physical memory capacity field, so that the scheduling node can identify the available computing status of the vehicle node based on the computing power feature word", after the vehicle node sends the computing power feature word to the scheduling node, the scheduling node first reads the field boundary marker, field version marker, and field integrity verification marker of the computing power feature word according to the general description protocol rules, and reads the physical operating parameter field, the chip manufacturer identification field, and the physical memory capacity field after the field integrity verification marker passes the verification. The physical operation parameter field is used to express whether the vehicle node currently meets the vehicle's operating conditions for receiving the encrypted fragment packet, running the target computation code, and transmitting the computation results. The chip manufacturer identifier field is used to express the platform standard of the main control chip node corresponding to the vehicle node, enabling the scheduling node to determine whether the subsequently constructed encrypted fragment packet needs to adopt a task encapsulation method compatible with the platform standard of the main control chip node. The physical memory capacity field is used to express the local storage resource boundary that the vehicle node can provide to the trusted sandbox isolated operating space, enabling the scheduling node to determine whether the underlying task data, the target computation code, and the operating context corresponding to the encrypted fragment packet can be loaded and run locally on the vehicle node. The scheduling node performs an operating status availability determination based on the physical operation parameter field to form an operating status availability determination result; the scheduling node performs a platform standard availability determination based on the chip manufacturer identifier field to form a platform standard availability determination result; and the scheduling node performs a storage resource availability determination based on the physical memory capacity field to form a storage resource availability determination result. Subsequently, the scheduling node writes the availability determination results of the running status, the platform caliber availability determination results, and the storage resource availability determination results into the available computing status identification record, and determines the available computing status of the vehicle node based on the available computing status identification record. The technical essence of the available computing status is that, before constructing the encrypted sharding packet, the scheduling node makes a unified judgment on whether the vehicle node can handle external computing tasks, what main control chip node platform caliber it can use to handle external computing tasks, and the scale of external computing tasks it can handle. The available computing status subsequently participates in the scheduling node's process of parsing the computing power feature word, constructing the encrypted sharding packet based on the task resource identifier and the computing power feature word, enabling the scheduling node to split and distribute distributed processing task requests to vehicle nodes that match the task resource identifier.The physical operating parameter field, the chip manufacturer identification field, and the physical memory capacity field jointly contribute to the formation of the available computing status identification record. The computing power characteristic word is no longer simply vehicle status reporting data, but becomes a direct data basis for the vehicle node's cross-vendor access, unified management, and sharding scheduling. The available computing status identification record also refers back to the computing power characteristic word, enabling the scheduling node to trace the source of the operating status availability determination result, the platform-specific availability determination result, and the storage resource availability determination result when subsequently constructing the encrypted sharding package.

[0037] Optionally, the scheduling node parses the computing power feature word and constructs an encrypted fragment packet based on the task resource identifier and the computing power feature word; the scheduling node sends the encrypted fragment packet to the vehicle node, including: The scheduling node maintains the global available computing power topology network node status based on the received multiple computing power feature words; The scheduling node reads the processing delay attribute field from the task resource identifier; The scheduling node matches the task resource identifier with the status of the global available computing power topology network nodes to determine the applicable data routing level; When it is determined that the task resource identifier has a set processing delay attribute, the scheduling node selects multiple vehicle nodes with idle resources within the local transmission network based on the data routing level. The scheduling node reads the complete underlying task data from the distributed processing task request and performs proportional segmentation processing on the underlying task data according to the computing power feature words of each vehicle node to generate multiple independent data blocks. The scheduling node uses the asymmetric public key pre-registered by the corresponding vehicle node to perform encryption operations on the independent data blocks respectively, so as to generate the encrypted fragment packet corresponding one-to-one with each vehicle node; The scheduling node establishes a point-to-point direct link with each of the vehicle nodes to push the encrypted fragmented packet to the corresponding vehicle node through the point-to-point direct link.

[0038] Preferably, the specific implementation process of step "the scheduling node maintains the global available computing power topology network node status based on the received multiple computing power feature words" is as follows: After receiving the computing power feature words uploaded by multiple vehicle nodes respectively, the scheduling node first reads the field boundary marker, field version marker, and field integrity verification marker in each computing power feature word according to the general description protocol rules. After the field integrity verification marker passes the verification, the scheduling node reads the physical operating parameter field, the chip manufacturer identifier field, and the physical memory capacity field to form a computing power feature word parsing record. The computing power feature word parsing record is used to carry the source of the scheduling node's identification of the available computing status of a single vehicle node, so that when maintaining the global available computing power topology network node status, it does not directly rely on the underlying hardware original fields inside different vehicle nodes, but relies on the physical operating parameter field, the chip manufacturer identifier field, and the physical memory capacity field, which have completed unified field mapping. Subsequently, the scheduling node generates vehicle node status entries based on the parsed computing power feature words. Each vehicle node status entry includes a vehicle node identifier, the availability determination result of the physical operating parameter field, the platform availability determination result of the chip manufacturer identifier field, the storage resource availability determination result of the physical memory capacity field, the network access location of the vehicle node, the most recent status update time of the vehicle node, and a schedulable limit. The schedulable limit is written into the vehicle node status entry by the scheduling node based on the physical memory capacity field, the availability determination result of the operating status, and the number of encrypted fragment packets currently allocated to the vehicle node. This schedulable limit is used to determine whether the vehicle node is still allowed to receive new encrypted fragment packets during subsequent idle resource determination processing. After the vehicle node status entries enter the global available computing power topology network node status, the scheduling node performs topology attaching processing on multiple vehicle node status entries according to the network access location, the availability determination result of the operating status, the availability determination result of the platform, and the storage resource availability determination result of the vehicle node, to form the global available computing power topology network node status that reflects the schedulable relationships between multiple vehicle nodes. The technical essence of the global available computing power topology network node status is that the scheduling node continuously maintains a schedulable node status map based on multiple computing power feature words; in the global available computing power topology network node status, each vehicle node status entry corresponds to a schedulable vehicle node, and the connection relationship between the vehicle node status entries corresponds to the transmission range and routing level that can be used between vehicle nodes.The scheduling node maintains the status of the globally available computing power topology network nodes. Instead of simply listing and registering vehicle nodes, it transforms the availability determination results of the vehicle node's operating status, the availability determination results of the platform caliber, the availability determination results of the storage resources, the network access location of the vehicle node, and the schedulable limit into the scheduling basis for subsequently constructing the encrypted sharding packet. This allows the scheduling node to directly select vehicle nodes that match the task resource identifier from the status of the globally available computing power topology network nodes after receiving the distributed processing task request.

[0039] Preferably, in the specific technical implementation of step "the scheduling node reads the processing delay attribute field in the task resource identifier", after receiving the distributed processing task request, the scheduling node first performs request structure parsing processing on the distributed processing task request to extract the task header description field, the task underlying data description field, and the task resource identifier. The task header description field is used to carry the source identifier and request time information of the distributed processing task request. The task underlying data description field is used to carry the range description of the task underlying data that needs to be proportionally segmented in the subsequent processing. The task resource identifier is used to carry the call requirements of the distributed processing task request for vehicle node computing power resources, storage resources, network transmission paths, and processing delay. After reading the task resource identifier, the scheduling node extracts the processing delay attribute field from the task resource identifier and writes the processing delay attribute field into the task resource parsing record. The task resource parsing record is used to separate the fields in the task resource identifier related to subsequent routing selection, vehicle node filtering, and proportional segmentation processing, so that the processing delay attribute field can participate in the matching processing between the task resource identifier and the global available computing power topology network node status. The processing latency attribute field originates from the latency constraint data written into the task resource identifier when the distributed processing task request is generated. The technical essence of this processing latency attribute field is to use a unified field to express the constraints of the distributed processing task request on completion time, transmission distance, and vehicle node response speed, rather than expressing non-technical selection preferences. The processing latency attribute field includes at least one of the following: a low-latency processing flag, a local direct connection requirement flag, a allowed forwarding level flag, a maximum waiting time flag, and a result return time flag. The low-latency processing flag indicates whether the task needs to be processed preferentially on the nearest vehicle node; the local direct connection requirement flag indicates whether the task needs to preferentially use the local direct connection routing level; the allowed forwarding level flag limits the data routing level that the scheduling node can subsequently select; the maximum waiting time flag limits the allowed transmission time between the generation of the encrypted fragment packet and its reception by the vehicle node; and the result return time flag limits the time constraint for returning the computation result to the scheduling node. The scheduling node reads the processing delay attribute field because the global available computing power topology network node status may simultaneously contain vehicle nodes corresponding to the local direct connection routing level, the regional relay routing level, and the cross-domain computing power routing level. If the processing delay attribute field is not read, the scheduling node can only select vehicle nodes based on the available computing power, which may easily assign latency-sensitive tasks to vehicle nodes with longer transmission paths.Through the processing delay attribute field, the scheduling node can transform the latency constraint of the distributed processing task request into a direct basis for subsequently determining the data routing level and filtering vehicle nodes before constructing the encrypted fragment packet.

[0040] Preferably, the specific implementation process of step "the scheduling node matches the task resource identifier with the global available computing power topology network node status to determine the applicable data routing level" is as follows: After forming the task resource parsing record, the scheduling node reads the processing delay attribute field, the task underlying data description field, and the computing power requirement field in the task resource identifier from the task resource parsing record, and simultaneously reads the vehicle node status entry from the global available computing power topology network node status; subsequently, the scheduling node performs matching processing on the task resource identifier and the vehicle node status entry to form a task node matching record. The task node matching record is used to carry the matching result between the task resource identifier and each vehicle node status entry, and the matching result includes at least the running status matching result, platform caliber matching result, storage resource matching result, network access location matching result, and processing delay matching result. The running status matching result is formed based on the running status availability judgment result corresponding to the physical running parameter field, and is used to determine whether the vehicle node is suitable for receiving the encrypted fragment packet; the platform caliber matching result is formed based on the platform caliber availability judgment result corresponding to the chip manufacturer identifier field, and is used to determine whether the vehicle node is suitable for executing the task encapsulation method corresponding to the task resource identifier; the storage resource matching result is formed based on the storage resource availability judgment result corresponding to the physical memory capacity field, and is used to determine whether the vehicle node is suitable for loading the independent data block corresponding to the task underlying data; the network access location matching result is formed based on the network access location of the vehicle node, and is used to determine whether the vehicle node and the scheduling node are suitable for using a local direct connection routing layer, a regional relay routing layer, or a cross-domain computing power routing layer; the processing delay matching result is formed based on the processing delay attribute field, and is used to determine whether the transmission path corresponding to the vehicle node meets the task delay constraint. The technical essence of the data routing layer is that the scheduling node determines the task distribution path category based on the task resource identifier and the status of the globally available computing power topology network nodes. The data routing layer includes at least one of the following: local direct connection routing layer, regional relay routing layer, and cross-domain computing power routing layer. The local direct connection routing layer is used to distribute the encrypted fragmented packets to vehicle nodes within the local transmission network. The regional relay routing layer is used to forward the encrypted fragmented packets to vehicle nodes within the region through near-end relay nodes. The cross-domain computing power routing layer is used to select vehicle nodes within a larger range.When the scheduling node determines the applicable data routing level based on the task node matching record, it first determines whether the processing delay attribute field is restricted to near-end processing, and then determines whether there are vehicle nodes in the global available computing power topology network node status that meet the running status matching result, the platform caliber matching result, and the storage resource matching result; when the running status matching result, the platform caliber matching result, the storage resource matching result, the network access location matching result, and the processing delay matching result all meet the requirements of the task resource identifier, the scheduling node determines the corresponding data routing level as the applicable data routing level, so that subsequent vehicle node screening and encrypted fragment packet push can be performed within the transmission range that matches the task latency requirements.

[0041] Preferably, in the specific technical implementation of the step "when it is determined that the task resource identifier has a set processing delay attribute, the scheduling node filters out multiple vehicle nodes with idle resources within the local transmission network based on the data routing level", the scheduling node first reads the processing delay attribute field in the task resource parsing record and determines whether the processing delay attribute field contains a low-latency processing flag, a local direct connection requirement flag, or a maximum waiting time flag; the low-latency processing flag, the local direct connection requirement flag, and the maximum waiting time flag are all set processing delay attributes. The set processing delay attribute is configured by the scheduling node according to the general description protocol rules before accessing the computing power scheduling network and written into the task resource identifier parsing caliber record. The task resource identifier parsing caliber record is used to limit how the scheduling node identifies the processing delay attribute field, so that the processing delay attribute field can be uniformly interpreted as a routing constraint, rather than being interpreted differently by different scheduling processes. The technical essence of the defined processing delay attribute is to transform the requirements of the distributed processing task request for near-end transmission and short-path scheduling into a triggering basis for the scheduling node to select the local direct-connection routing level. When the processing delay attribute field meets the identification conditions for the defined processing delay attribute in the task resource identifier resolution caliber record, the scheduling node determines, based on the data routing level, that vehicle node screening needs to be performed within the local transmission network. The local transmission network is the communication range of vehicle nodes that are in the same near-end transmission range as the scheduling node and can transmit the encrypted fragmented packets via a shorter path. Within the local transmission network, the scheduling node reads the vehicle node status entries from the global available computing power topology network node status and performs idle resource determination processing on the vehicle node status entries to form a local vehicle node screening record. The idle resource determination process includes determining whether the availability determination result of the running status in the vehicle node status entry allows receiving the encrypted fragment packet, determining whether the storage resource availability determination result meets the independent data block loading requirements corresponding to the task's underlying data description field, determining whether the most recent status update time in the vehicle node status entry is still within the available status validity period, and determining whether the vehicle node has been occupied by other encrypted fragment packets exceeding the schedulable limit. The available status validity period is pre-written by the scheduling node into the update time verification caliber of the global available computing power topology network node status according to the general description protocol rules. The available status validity period is used to determine whether the vehicle node status entry can still reflect the current status of the corresponding vehicle node. The schedulable limit is provided by the vehicle node status entry and is used to determine whether the vehicle node still has idle resources to continue receiving the encrypted fragment packet.Vehicle nodes meeting the above conditions are written into the local vehicle node filtering record and marked as having idle resources. The technical essence of a vehicle node having idle resources is that it simultaneously meets the requirements of task latency constraints, hardware platform specifications, storage resource boundaries, and current operating status within the local transmission network. The scheduling node filters out multiple vehicle nodes with idle resources so that the underlying task data can be divided into multiple independent data blocks and distributed to different vehicle nodes, thereby reducing the pressure on a single vehicle node to carry the complete task data and enabling the distributed processing task requests to be executed in parallel across multiple vehicle nodes.

[0042] Preferably, the specific implementation process of step "the scheduling node reads complete task underlying data from the distributed processing task request and performs proportional segmentation processing on the task underlying data according to the computing power feature words of each vehicle node to generate multiple independent data blocks" is as follows: After forming the local vehicle node filtering record, the scheduling node reads the task underlying data description field in the distributed processing task request, and locates the task underlying data storage location, task underlying data length, task underlying data verification mark, and task underlying data boundary mark according to the task underlying data description field. When reading the task underlying data, it is necessary to simultaneously meet three conditions: the task underlying data length is consistent with the task underlying data verification mark, the task underlying data boundary mark is complete, and the task underlying data storage location can be accessed by the scheduling node; when all the above conditions are met, the scheduling node writes the read data into the complete task underlying data read record. The complete task underlying data read record is used to carry the complete task underlying data read from the distributed processing task request, and enables subsequent proportional segmentation processing to use the complete task underlying data read record as the input source. Subsequently, the scheduling node reads multiple vehicle nodes with idle resources from the local vehicle node filtering record, and reads the computing power feature word corresponding to each vehicle node with idle resources. The physical operating parameter field in the computing power feature word is used to determine the current operating status that each vehicle node with idle resources can bear, the chip manufacturer identifier field is used to determine the task packaging method corresponding to each vehicle node with idle resources, and the physical memory capacity field is used to determine the data block capacity boundary that each vehicle node with idle resources can bear. Based on the physical memory capacity field of each vehicle node with idle resources, the operating status availability determination result, and the computing power requirement field in the task resource identifier, the scheduling node performs proportional segmentation processing on the complete task underlying data reading record to form multiple independent data blocks. The proportional segmentation process is not an average split, but rather, based on the physical memory capacity field of each vehicle node with idle resources, the available computing status of each vehicle node with idle resources, and the computing power requirement field in the task resource identifier, a corresponding data block capacity ratio is determined for each vehicle node with idle resources. Subsequently, the scheduling node extracts the corresponding range of data content from the complete task underlying data reading record according to the data block capacity ratio, and writes a data block sequence number, a data block boundary marker, a data block verification marker, and the corresponding vehicle node identifier for each extracted data content to form the independent data block.The technical essence of the independent data block is that it is a data block cut from the same complete task's underlying data reading record, which can be independently loaded and processed by a single vehicle node with idle resources within the trusted sandbox isolated operating space. The scheduling node generates multiple independent data blocks because there are multiple vehicle nodes with idle resources in the local vehicle node screening record. Multiple independent data blocks can form a fragmented execution relationship with multiple vehicle nodes with idle resources, so that a single vehicle node does not access the complete task's underlying data, and subsequent encryption operations can be executed separately for different vehicle nodes.

[0043] Preferably, the specific implementation process of step "the scheduling node uses the pre-registered asymmetric public key of the corresponding vehicle node to perform encryption operations on the independent data blocks respectively to generate the encrypted fragment packets corresponding one-to-one with each vehicle node" is as follows: After generating multiple independent data blocks, the scheduling node reads the vehicle node key registration record and, based on the vehicle node identifier in each independent data block, reads the corresponding asymmetric public key from the vehicle node key registration record. The vehicle node key registration record is formed before the vehicle node accesses the computing power scheduling network. The vehicle node first generates public key material and private key material corresponding to the vehicle node identifier in its local secure storage area, and then registers the asymmetric public key, the vehicle node identifier, the key version marker, the key usage marker, and the key validity status marker corresponding to the public key material to the scheduling node to form the vehicle node key registration record; the private key material is retained in the local secure storage area of ​​the vehicle node and is not sent to the scheduling node along with the vehicle node key registration record. The essence of the asymmetric public key technology is that it enables the scheduling node to encrypt the independent data blocks into encrypted data blocks that only the corresponding vehicle node can decrypt locally, thus preventing different vehicle nodes from reading each other's corresponding independent data blocks. When the scheduling node performs an encryption operation on each independent data block, it first reads the data block sequence number, data block boundary marker, data block verification marker, and corresponding vehicle node identifier from the independent data block. Then, it reads the asymmetric public key corresponding to the vehicle node identifier and uses the asymmetric public key to encrypt the independent data block to form an encrypted data block. The encrypted data block carries the independent data block encrypted with the asymmetric public key and serves as the core data content for subsequently generating the encrypted fragment packet. Subsequently, the scheduling node encapsulates the encrypted data block, the data block sequence number, the vehicle node identifier, the key version marker, the task resource identifier backreference marker, and the fragment packet integrity verification marker to generate the encrypted fragment packet. The task resource identifier backreference marker is used to enable the encrypted fragment packet to backreference the task resource identifier on which the independent data block was generated. This marker subsequently participates in the formation of the encrypted fragment packet distribution record, allowing the scheduling node to trace the task source corresponding to the encrypted fragment packet. The method for determining the one-to-one correspondence between the encrypted fragment packet and each vehicle node is based on the consistency of the vehicle node identifier in the independent data block, the vehicle node identifier in the vehicle node key registration record, and the vehicle node identifier in the encrypted fragment packet. When all three are consistent, the scheduling node writes the encrypted fragment packet into the encrypted fragment packet distribution record and allocates it to the corresponding vehicle node.The essence of the encrypted fragment packet technology is to encrypt, encapsulate, and distribute the task data carrier at the vehicle node level. By performing encryption operations on the independent data blocks using the asymmetric public key, the scheduling node can limit the data readability to the corresponding vehicle node during the task fragmentation stage. This ensures that a single vehicle node can only access the encrypted fragment packet assigned to it, and reduces the risk of exposing the complete task underlying data on the vehicle node side.

[0044] Preferably, in the specific technical implementation of the step "the scheduling node establishes a point-to-point direct link corresponding to each of the vehicle nodes to push the encrypted fragmented packet to the corresponding vehicle node through the point-to-point direct link", after forming the encrypted fragmented packet distribution record, the scheduling node reads the local vehicle node filtering record based on the vehicle node identifier in the encrypted fragmented packet distribution record, and reads the network access location, communication address, link availability status, and most recent status update time of the corresponding vehicle node from the local vehicle node filtering record to form a point-to-point direct link establishment record. The link availability status comes from the vehicle node status entry in the global available computing power topology network node status, and the link availability status is used to determine whether the vehicle node allows the establishment of the point-to-point direct link; the point-to-point direct link establishment record is used to carry the link parameters required for establishing a near-end direct transmission path between the scheduling node and the corresponding vehicle node, so that each encrypted fragmented packet can be pushed through the transmission path corresponding to its vehicle node identifier. Subsequently, the scheduling node initiates a link handshake request to the corresponding vehicle node based on the point-to-point direct link establishment record. After receiving the link handshake confirmation from the vehicle node, the scheduling node marks the link status of the point-to-point direct link as transmissible. The link handshake request enables the scheduling node to initiate transmission preparation for establishing the point-to-point direct link with the corresponding vehicle node. The link handshake confirmation enables the corresponding vehicle node to report to the scheduling node that it can receive the encrypted fragmented packets. The transmissible status indicates that the point-to-point direct link has met the conditions for pushing the encrypted fragmented packets. The point-to-point direct link is not a broadcast path to multiple vehicle nodes, but a direct transmission path established between the scheduling node and a single vehicle node based on the vehicle node identifier. The technical essence of the point-to-point direct link is to construct a task distribution channel corresponding one-to-one with the encrypted fragmented packets for each vehicle node within the local area transmission network, enabling the encrypted fragmented packets to directly reach the corresponding vehicle node by reducing unnecessary multi-level forwarding paths. When the scheduling node pushes the encrypted fragmented packet through the point-to-point direct link, it first reads the encrypted fragmented packet corresponding to the vehicle node from the encrypted fragmented packet distribution record, and then writes the encrypted fragmented packet into the sending queue of the point-to-point direct link. The sending queue is used to cache the encrypted fragmented packets to be sent according to the push order of the encrypted fragmented packet distribution record, and to enable the fragmented packet integrity verification flag to participate in the integrity confirmation process before sending. After the integrity confirmation process is successful, the scheduling node pushes the encrypted fragmented packet to the corresponding vehicle node and waits for the vehicle node to send back a fragmented packet reception confirmation record.The fragment packet reception confirmation record includes the vehicle node identifier, the data block sequence number, the reception time, and the reception integrity verification result. The reception integrity verification result is used to express the vehicle node's confirmation of the integrity of the received encrypted fragment packet. The scheduling node updates the encrypted fragment packet distribution record based on the fragment packet reception confirmation record, so that the push status of the encrypted fragment packet can be read by subsequent task execution and result feedback processes. Through the point-to-point direct connection link, the scheduling node can establish a continuous data transmission relationship between the data routing hierarchy, the local vehicle node filtering record, the independent data block, the encrypted fragment packet, and the corresponding vehicle node, thereby making the process of the scheduling node sending the encrypted fragment packet to the vehicle node traceable, with a traceable link basis and node correspondence.

[0045] Optionally, the method further includes an abnormal network outage recovery step, specifically including: The vehicle node maintains a set keep-alive timer in the local system. The keep-alive timer is used to monitor the heartbeat communication link status between the vehicle node and the scheduling node. The vehicle node is pre-configured with a preset tolerance limit for determining the state of the heartbeat communication link; When the duration of the heartbeat communication link being disconnected exceeds the preset tolerance limit, the vehicle node suspends outputting the calculation results and temporarily saves the execution progress of the target calculation code at this moment as a local checkpoint file. The vehicle node places the trusted sandbox into a hibernation waiting mode, which is used to maintain the recovery correspondence between the local checkpoint file and the trusted sandbox; When the heartbeat communication link is detected to be re-established, the vehicle node sends a reconnection registration request packet to the scheduling node; The scheduling node sends a confirmation response instruction to the vehicle node based on the reconnection registration request packet, thus enabling... The vehicle node wakes up the trusted sandbox according to the confirmation response command to load the local checkpoint file and resume the execution of the target computation code.

[0046] Preferably, the specific implementation process of step "the vehicle node maintains a set keep-alive timer in the local system, the keep-alive timer being used to monitor the heartbeat communication link status between the vehicle node and the scheduling node" is as follows: Before receiving the encrypted fragment packet and loading the target computation code into the trusted sandbox isolated runtime space of the trusted sandbox, the vehicle node first establishes a network outage recovery monitoring record in the local system, and establishes a correspondence between the network outage recovery monitoring record and the vehicle node identifier, the scheduling node identifier, the encrypted fragment packet, the target computation code, the trusted sandbox, the trusted sandbox isolated runtime space, and the subsequently formed local checkpoint file. The technical essence of the local system is the on-board local runtime environment inside the vehicle node used to manage the network protocol stack, the trusted sandbox runtime status, the task execution progress, the local storage area, and the underlying driver call relationships; the local system does not participate in reading the plaintext content of the target computation code, but rather manages the external communication status and internal runtime status of the target computation code by associating the task handle of the target computation code, the trusted sandbox isolated runtime space identifier, and the network connection status marker. The network protocol stack is used to carry the heartbeat message transmission between the vehicle node and the scheduling node. The underlying driver call relationship is used to provide local call paths when subsequently forming the local checkpoint file, controlling the trusted sandbox to enter the hibernation waiting mode, and waking up the trusted sandbox. The network connection status flag is subsequently updated by the heartbeat monitoring record so that the network outage recovery monitoring record can continuously reflect the heartbeat communication link status. Subsequently, the vehicle node creates the keep-alive timer based on the network outage recovery monitoring record and establishes a binding relationship between the keep-alive timer and the heartbeat communication link status. The keep-alive timer records the heartbeat sending time, heartbeat response time, number of consecutive no-response times, and the time of the most recent valid response between the vehicle node and the scheduling node according to the set timing beat to form the heartbeat monitoring record. The heartbeat communication link status is generated by the heartbeat monitoring record and is used to express whether the vehicle node and the scheduling node still maintain a communication status that can be used to transmit the calculation results, the cryptographic credentials, the reconnection registration request packet, and the confirmation response instruction. The vehicle node maintains the keep-alive timer within the local system because, in the scenario of open idle computing power in new energy vehicles, the vehicle node may temporarily lose connection due to wireless network switching in the parking environment, changes in local transmission network coverage, or short-term unavailability of the scheduling node, and cannot immediately discard the running state of the target computing code when the connection fluctuates for a short time.The heartbeat monitoring record is continuously generated by the keep-alive timer. The vehicle node can convert the availability of the communication link into the heartbeat communication link status that can be directly read by the local system, so that the subsequent preset tolerance limit determination, the local checkpoint file generation and the trusted sandbox hibernation waiting process all have the same communication status basis.

[0047] Preferably, in the specific technical implementation of the step "the vehicle node pre-configures a preset tolerance limit for determining the heartbeat communication link status", after the keep-alive timer is created, the vehicle node reads the locally stored vehicle safety constraint configuration data and extracts the network disconnection recovery configuration item, task execution retention configuration item, trusted sandbox hibernation configuration item, and local checkpoint file storage configuration item from the vehicle safety constraint configuration data; the network disconnection recovery configuration item is used to limit the allowed duration of the heartbeat communication link status switching from a connectable state to a disconnected state; the task execution retention configuration item is used to limit whether the target computation code is allowed to continue to maintain its running context in the trusted sandbox during the abnormal heartbeat communication link status; the trusted sandbox hibernation configuration item is used to limit the running status fields that need to be retained when the trusted sandbox enters the hibernation waiting mode; and the local checkpoint file storage configuration item is used to limit the write location, verification method, and recoverable read conditions of the local checkpoint file. The vehicle node generates a heartbeat tolerance configuration record based on the network outage recovery configuration item, and writes the preset tolerance limit into the heartbeat tolerance configuration record. The heartbeat tolerance configuration record is used to provide the local system with the time boundary for determining whether the heartbeat communication link status has entered the abnormal network outage recovery step. The configuration principle of the preset tolerance limit is to ensure that the preset tolerance limit can cover the normal recovery time required for short-term jitter of the local transmission network, temporary queuing response of the scheduling node, and wireless access switching of the vehicle node, while being less than the task safety time window that may result in non-returnable computation results after the target computation code continues to run. The task safety time window is provided by the task execution hold configuration item and is established in correspondence with the preset tolerance limit in the heartbeat tolerance configuration record, so that the preset tolerance limit can simultaneously constrain the communication recovery waiting time and the state hold time of the target computation code. The technical essence of the preset tolerance limit is not a simple timeout parameter, but rather a transformation of the communication availability requirements between the vehicle node and the scheduling node into a locally executable boundary for judging abnormal network outages. This preset tolerance limit, along with the number of consecutive unanswered responses, the time of the most recent valid response, and the duration of the disconnection state recorded in the heartbeat monitoring log, participates in the judgment, enabling the vehicle node to distinguish between short-term heartbeat loss and communication interruptions requiring an abnormal network outage recovery step. Through the heartbeat tolerance configuration record, the heartbeat communication link status formed by the keep-alive timer is no longer merely network notification information, but directly affects the local judgment criteria for the operation result output control, the formation of the local checkpoint file, and the trusted sandbox hibernation waiting process.

[0048] Preferably, the specific implementation process of step "when the duration of the heartbeat communication link being disconnected exceeds the preset tolerance limit, the vehicle node suspends outputting the calculation results and temporarily stores the execution progress of the target calculation code at this moment as a local checkpoint file" is as follows: The vehicle node continuously reads the heartbeat monitoring record through the keep-alive timer, and performs a continuous disconnection determination on the heartbeat communication link status according to the preset tolerance limit in the heartbeat tolerance configuration record to form a network disconnection confirmation record. The network disconnection confirmation record includes the vehicle node identifier, the scheduling node identifier, the most recent valid response time, the duration of the disconnection state, the preset tolerance limit, the trusted sandbox isolated running space identifier, and the task handle of the target calculation code; the network disconnection confirmation record is used to establish a direct correspondence between the duration of the heartbeat communication link being disconnected and the target calculation code currently running. When the duration of the disconnection state exceeds the preset tolerance limit for the first time, the vehicle node takes the sampling time of the first exceeding the preset tolerance limit as the network disconnection confirmation time, and suspends outputting the calculation results according to the network disconnection confirmation time. The vehicle node suspends outputting the computation results because the heartbeat communication link can no longer provide a stable return path. Continuing to output the results could lead to duplicate transmissions, packet loss, or the scheduling node being unable to confirm receipt during a transmission interruption. Therefore, the vehicle node first writes the computation results to be output into a local buffer record awaiting return and associates this buffer record with the network disconnection confirmation record. Subsequently, the vehicle node reads the execution progress of the target computation code within the trusted sandbox at the time of the network disconnection confirmation. This execution progress includes the instruction position of the target computation code, the sequence number of the currently processed data block, the boundaries of completed data blocks, intermediate states not yet returned, runtime stack information, and the temporary storage state within the trusted sandbox. The technical essence of this execution progress is to characterize the state data that indicates where the target computation code has progressed and from which it should continue execution. The association between the intermediate states not yet returned and the local buffer record ensures that recoverable data sources from the computation process are retained even before the computation results are fully returned. The vehicle node encapsulates the execution progress, the encrypted fragment packet identifier, the network disconnection confirmation time, the local pending return buffer record, and the trusted sandbox isolated running space identifier into a local checkpoint file, and writes the local checkpoint file into the local storage area specified by the local checkpoint file storage configuration item; the local checkpoint file is used to reload the trusted sandbox after communication is restored, so that the target calculation code can continue to run according to the execution progress or complete the calculation result return.

[0049] Preferably, in the specific technical implementation of the step "the vehicle node puts the trusted sandbox into a hibernation waiting mode, the hibernation waiting mode being used to maintain the recovery correspondence between the local checkpoint file and the trusted sandbox", after the vehicle node forms the local checkpoint file, it first performs integrity marking processing on the local checkpoint file to form a local checkpoint file save record. The local checkpoint file save record includes the file identifier of the local checkpoint file, the write location identifier, the network disconnection confirmation time, the task handle of the target computing code, the encrypted fragment packet identifier, and the trusted sandbox isolated running space identifier. The local checkpoint file save record is used to indicate that the local checkpoint file has been written to a recoverable readable location, and is used to locate the local checkpoint file when the trusted sandbox is subsequently woken up. Subsequently, the vehicle node issues a hibernation waiting control command to the trusted sandbox based on the local checkpoint file save record. The hibernation waiting control command includes the trusted sandbox isolated running space identifier, the task handle of the target computing code, the file identifier of the local checkpoint file, a context retention field, an external output freeze field, and a resource usage degradation field. After receiving the hibernation and waiting control command, the trusted sandbox locates the trusted sandbox isolated runtime space where the target computation code runs based on the trusted sandbox isolated runtime space identifier. It retains the runtime context index corresponding to the local checkpoint file based on the context preservation field, prevents the trusted sandbox from continuing to output the computation result based on the external output freeze field, and reduces the trusted sandbox's consumption of underlying computing resources based on the resource usage degradation field, thereby enabling the trusted sandbox to enter the hibernation and waiting mode. The runtime context index is used to establish a correspondence between the runtime context within the trusted sandbox isolated runtime space and the file identifier of the local checkpoint file in the local checkpoint file's saved record. Subsequent trusted sandbox wake-up processing uses the runtime context index to determine the runtime context that should be restored. The technical essence of the hibernation and waiting mode is to prevent the trusted sandbox from continuing the execution flow that would generate new computation results before the heartbeat communication link status is restored, while simultaneously preserving the restoration correspondence between the local checkpoint file and the trusted sandbox isolated runtime space. The recovery correspondence is formed by the file identifier of the local checkpoint file, the identifier of the trusted sandbox isolated running space, the task handle of the target computing code, and the identifier of the encrypted fragment packet. The recovery correspondence subsequently participates in the confirmation response command verification, the trusted sandbox wake-up process, and the local checkpoint file loading process, so that the vehicle node can identify which trusted sandbox should be recovered, which local checkpoint file should be loaded, and which target computing code should be continued after communication is restored.

[0050] Preferably, the specific implementation process of step "when the heartbeat communication link is detected to be re-established, the vehicle node sends a reconnection registration request packet to the scheduling node" is as follows: While the trusted sandbox is in the dormant waiting mode, the vehicle node still sends heartbeat probe messages to the scheduling node according to the set retry rhythm through the keep-alive timer, and writes the sending time, receiving response time, response source identifier, and link round-trip time of each heartbeat probe message into the reconnection probe record. The response source identifier is used to verify whether the heartbeat probe message is returned by the scheduling node, and the link round-trip time is used to determine whether the re-established communication path can carry the reconnection registration request packet, the confirmation response instruction, and the subsequent transmission of the calculation result. The reconnection probe record and the heartbeat monitoring record use the same time source generated by the keep-alive timer, so that there is a continuous timing basis when the heartbeat communication link state switches from the disconnected state to the re-established connection state. The vehicle node performs link restoration confirmation processing on the reconnection probe record. When it continuously receives valid heartbeat responses from the scheduling node, and the scheduling node identifier in the valid heartbeat response matches the scheduling node identifier in the network disconnection confirmation record, the vehicle node marks the heartbeat communication link status as re-established. The technical essence of the heartbeat communication link re-establishment is that the communication path between the vehicle node and the scheduling node has been restored for sending the reconnection registration request packet, receiving the confirmation response instruction, and continuing to transmit the calculation results, rather than simply detecting the presence of a wireless signal. Subsequently, the vehicle node generates the reconnection registration request packet based on the reconnection probe record, the network disconnection confirmation record, and the local checkpoint file save record. The reconnection registration request packet includes the vehicle node identifier, the scheduling node identifier, the encrypted fragment packet identifier, the task handle of the target computation code, the file identifier of the local checkpoint file, the network disconnection confirmation time, the record identifier of the local pending return buffer record, and the identifier of the trusted sandbox isolated running space. The technical essence of the reconnection registration request packet is that after communication is restored, the vehicle node reports its local status of the abnormal network outage recovery steps to the scheduling node. This allows the scheduling node to determine whether the vehicle node still corresponds to the original task, whether it needs to continue receiving the computation results, and whether it should allow the vehicle node to recover the target computation code based on the local checkpoint file. The vehicle node sends the reconnection registration request packet instead of directly waking up the trusted sandbox because the scheduling node needs to first verify the task distribution status, the encrypted fragment packet distribution status, and the computation result reception status. These statuses subsequently enter the confirmation response instruction generation process to prevent the target computation code from repeatedly running or repeatedly sending back data when the scheduling node's task status is unknown.

[0051] Preferably, in the specific technical implementation of the step "the scheduling node sends a confirmation response instruction to the vehicle node based on the reconnection registration request packet", after receiving the reconnection registration request packet, the scheduling node first reads the vehicle node identifier, the encrypted fragment packet identifier, the task handle of the target computation code, the file identifier of the local checkpoint file, the network disconnection confirmation time, and the record identifier of the local pending return buffer record from the reconnection registration request packet according to the general description protocol rules, and writes the read fields into the reconnection registration parsing record. The reconnection registration parsing record is used to convert the recovery information in the reconnection registration request packet into task status information that the scheduling node can verify. Subsequently, the scheduling node reads the encrypted fragment packet distribution record corresponding to the encrypted fragment packet identifier and reads the vehicle node status entry corresponding to the vehicle node identifier; the scheduling node performs a consistency check between the reconnection registration parsing record and the encrypted fragment packet distribution record to confirm that the vehicle node has received the encrypted fragment packet and to confirm that the task handle of the target computation code still corresponds to the distributed processing task request. The scheduling node also reads the computation result reception record and determines whether the computation result corresponding to the local pending return buffer record has been completely received by the scheduling node. If the computation result has not been completely received, the scheduling node writes the vehicle node identifier, the encrypted fragment packet identifier, the file identifier of the local checkpoint file, and the recovery permission flag into the confirmation response instruction. The confirmation response instruction includes the recovery permission flag, the result return permission flag, the checkpoint loading permission flag, the task status return flag, and the response generation time. The recovery permission flag is used to indicate that the vehicle node is allowed to switch from the hibernation waiting mode to the resume running state. The result return permission flag is used to indicate that the vehicle node can continue to output the computation result. The checkpoint loading permission flag is used to indicate that the vehicle node can read the local checkpoint file. The task status return flag is used to make the vehicle node confirm that the target computation code still corresponds to the original distributed processing task request. The technical essence of the acknowledgment response command from the scheduling node is to align the task status on the scheduling node side with the recovery status on the vehicle node side. The task status on the scheduling node side is jointly represented by the encrypted fragment packet distribution record, the vehicle node status entry, and the computation result reception record. The recovery status on the vehicle node side is jointly represented by the reconnection registration parsing record, the file identifier of the local checkpoint file, and the record identifier of the local pending return buffer record. Through the acknowledgment response command, the vehicle node does not rely on unilateral judgment when subsequently waking up the trusted sandbox, thereby maintaining a continuous data processing relationship between the abnormal network outage recovery step and the encrypted fragment packet distribution, the computation result return, and the cryptographic credential return.

[0052] Preferably, the specific implementation process of step "the vehicle node wakes up the trusted sandbox according to the confirmation response instruction to load the local checkpoint file and restore the running action of the target computing code" is as follows: After receiving the confirmation response instruction, the vehicle node first reads the recovery permission flag, the result return permission flag, the checkpoint loading permission flag, and the task status return flag in the confirmation response instruction, and performs consistency verification between the confirmation response instruction and the local checkpoint file save record, the hibernation wait control instruction, and the reconnection registration request packet to form a recovery startup verification record. The recovery startup verification record is used to confirm that the local checkpoint file pointed to by the confirmation response instruction, the trusted sandbox isolated running space, and the task handle of the target computing code all maintain the corresponding relationship before the network disconnection. After the recovery startup verification record passes, the vehicle node sends a trusted sandbox wake-up instruction to the trusted sandbox; the trusted sandbox wake-up instruction includes the trusted sandbox isolated running space identifier, the file identifier of the local checkpoint file, the task handle of the target computing code, the resource recovery field, and the output recovery field. The trusted sandbox exits the hibernation waiting mode based on the trusted sandbox isolated runtime space identifier, and re-applies for the underlying computing resources required to run the target computing code based on the resource recovery field, thus forming a trusted sandbox wake-up record. The trusted sandbox also removes the output restriction corresponding to the external output freeze field based on the output recovery field, allowing the computation results in the local pending return buffer record to continue to be returned if permitted by the result return permission flag. Subsequently, the vehicle node reads the local checkpoint file based on the file identifier of the local checkpoint file and performs integrity verification on the local checkpoint file. After the local checkpoint file passes the integrity verification, the vehicle node reads the execution progress, the encrypted fragment packet identifier, the network disconnection confirmation time, and the local pending return buffer record from the local checkpoint file, and reloads the execution progress into the trusted sandbox. The instruction position in the execution progress is used to restore the position of the next instruction to be executed in the target computation code. The current data block sequence number and the boundary of the completed data block in the execution progress are used to restore the processing range of the target computation code for the independent data block. The intermediate state that has not yet been returned in the execution progress is used to restore the computation state of the target computation code that has not yet been returned at the time of network disconnection confirmation. The runtime stack information and the trusted sandbox temporary storage state in the execution progress are used to restore the runtime context of the target computation code in the trusted sandbox.The technical essence of the target computation code is that it is an external computation task code obtained by decrypting the encrypted fragment packet and executed within the trusted sandbox. Resuming the execution of the target computation code means that the vehicle node, based on the execution progress saved in the local checkpoint file, allows the target computation code to resume execution from the position corresponding to the network disconnection confirmation time or to continue transmitting the already formed computation results, rather than reloading the complete task. Through the continuous processing between the confirmation response command, the local checkpoint file, and the trusted sandbox wake-up record, the vehicle node can resume the execution of the target computation code after the heartbeat communication link is re-established, and seamlessly integrates the abnormal network disconnection recovery step with the transmission of computation results, the transmission of cryptographic credentials, and the clearing of temporarily stored data in the trusted sandbox.

[0053] Optionally, after completing the execution of the target computation code, the vehicle node generates cryptographic credentials within the trusted sandbox, including: During each instruction cycle of the target computation code, the trusted sandbox records a summary of the instruction execution trajectory of the target computation code within the trusted sandbox. The summary of the instruction execution trajectory is used to characterize the actual execution process of the target computation code within the trusted sandbox. Upon confirming that the target computation code has been processed, the trusted sandbox activates the built-in zero-knowledge proof generation firmware module and inputs the instruction execution trajectory digest as covert verification data into the zero-knowledge proof generation firmware module to perform a pre-configured polynomial commitment transformation calculation operation to generate a feature verification data string as the cryptographic credential. The cryptographic credentials enable external verification nodes to independently verify the authenticity and reliability of the entire operation phase solely by relying on the feature verification data string in the cryptographic credentials, without reading the original plaintext input data of the target computation code.

[0054] Preferably, the specific implementation process of step "the trusted sandbox records the instruction execution trajectory summary of the target computation code in the trusted sandbox one by one during each instruction cycle of the target computation code" is as follows: After the vehicle node decrypts the encrypted fragment packet and obtains the target computation code in the trusted sandbox, the trusted sandbox first establishes an instruction cycle division record based on the task handle of the target computation code, and establishes a correspondence between the instruction cycle division record and the encrypted fragment packet identifier, the trusted sandbox isolated running space identifier, the task handle of the target computation code, and the subsequently generated instruction execution trajectory summary. Each instruction cycle is not an arbitrary time slice, but a running segment with the division boundary defined by the target computation code completing one instruction fetch, one instruction dispatch, one execution status update, and one instruction execution trajectory summary writing in the trusted sandbox; the instruction cycle division record is used to split the continuously running target computation code into multiple traceable running segments, so that the trusted sandbox can record the actual execution process of the target computation code in the trusted sandbox segment by segment without disclosing the original plaintext input data of the target computation code. Subsequently, at the end of each instruction cycle, the trusted sandbox reads the instruction position, instruction type flag, input data block sequence number, runtime stack status flag, trusted sandbox isolated runtime space identifier, current execution thread identifier, and instruction cycle completion flag corresponding to that instruction cycle. It then performs digest processing on the instruction position, instruction type flag, input data block sequence number, runtime stack status flag, trusted sandbox isolated runtime space identifier, current execution thread identifier, and instruction cycle completion flag to form a summary of the instruction execution trajectory corresponding to that instruction cycle. The technical essence of the instruction execution trajectory digest is to compress the execution path, execution order, and execution state changes of the target computation code within the trusted sandbox into digested verification data that cannot be directly deduced from the original plaintext input data of the target computation code. The instruction execution trajectory digest does not record the original plaintext input data of the target computation code. Instead, it records the execution trajectory state that indicates whether the target computation code actually runs according to the task segment corresponding to the encrypted fragment packet, using the instruction position, instruction category marker, input data block sequence number, runtime stack state marker, trusted sandbox isolated runtime space identifier, current execution thread identifier, and instruction cycle completion marker. The trusted sandbox records the instruction execution trajectory digest one by one because the cryptographic credential subsequently needs to prove that the computation result originates from the actual execution process of the target computation code within the trusted sandbox, and cannot determine whether the target computation code was completely executed solely based on the computation result itself.By recording the instruction cycle and continuously forming the instruction execution trajectory summary, the trusted sandbox can transform the actual execution process of the target computation code within the trusted sandbox into a data source for the hidden verification data that can be read by the subsequent zero-knowledge proof generation firmware module, thus enabling a continuous data processing relationship between the execution of the target computation code, the generation of the instruction execution trajectory summary, and the generation of the cryptographic credential.

[0055] Preferably, in the specific technical implementation of the step "the instruction execution trajectory summary is used to characterize the actual execution process of the target computation code within the trusted sandbox", after the trusted sandbox continuously generates the instruction execution trajectory summary within multiple instruction cycles, it performs sequential indexing processing on the multiple instruction execution trajectory summaries according to the instruction cycle division record to form an instruction execution trajectory summary sequence. The instruction execution trajectory summary sequence includes multiple instruction execution trajectory summaries arranged according to the actual execution order, an instruction cycle completion marker corresponding to each instruction execution trajectory summary, the task handle of the target computation code, and the encrypted fragment packet identifier. The instruction execution trajectory summary sequence is used to characterize the execution order of the target computation code within the trusted sandbox from start to finish, rather than just characterizing the result of a single instruction execution. The trusted sandbox further reads adjacent instruction execution trajectory summaries in the instruction execution trajectory summary sequence and verifies the continuity of instruction positions, the continuity of input data block numbers, the progressive relationship of runtime stack status markers, and the consistency of instruction cycle completion markers between adjacent instruction execution trajectory summaries to form an actual execution process confirmation record. The actual execution process confirmation record is used to indicate whether the instruction execution trajectory summary sequence can continuously cover the actual execution process of the target computation code within the trusted sandbox. The instruction position continuity is used to confirm whether the instruction positions of the target computation code have a sequential relationship between adjacent instruction cycles. The input data block sequence number continuity is used to confirm whether the processing range of the target computation code for the corresponding task fragment of the encrypted fragment packet has a sequential relationship. The runtime stack state flag progression relationship is used to confirm whether the call hierarchy of the target computation code has a sequential relationship between adjacent instruction cycles. The instruction cycle completion flag consistency is used to confirm whether each instruction cycle has been digested and recorded. When the actual execution process confirmation record shows a sequential execution relationship between adjacent instruction execution trajectory summaries, the trusted sandbox uses the instruction execution trajectory summary sequence as a digested representation of the actual execution process of the target computation code. The technical essence of the summary representation of the actual execution process of the target computation code is to convert the actual execution process of the target computation code in the trusted sandbox into a verifiable execution trajectory state, so that the subsequent external verification nodes can verify whether the target computation code runs sequentially in the trusted sandbox without having to read the original plaintext input data of the target computation code.The correspondence between the actual execution process confirmation record and the encrypted fragment packet identifier is established because the encrypted fragment packet identifier points to the source of the task fragment processed by the target computation code; the correspondence between the actual execution process confirmation record and the task handle of the target computation code is established because the task handle of the target computation code points to the running object recorded within the trusted sandbox. Therefore, the instruction execution trajectory digest sequence, the actual execution process confirmation record, and the task handle of the target computation code together constitute the execution basis for subsequently generating the cryptographic credential.

[0056] Preferably, the specific implementation process of step "when it is known that the target computation code has been processed, the trusted sandbox wakes up the built-in zero-knowledge proof generation firmware module, and inputs the instruction execution trajectory digest as covert verification data into the zero-knowledge proof generation firmware module to perform a pre-configured polynomial commitment transformation calculation operation to generate a feature verification data string as the cryptographic credential" is as follows: During the execution of the target computation code, the trusted sandbox continuously reads the task handle of the target computation code, the encrypted fragment packet identifier, the instruction execution trajectory digest sequence, and the operation result generation status; when the trusted sandbox detects that all input data block numbers corresponding to the target computation code have been processed, and the operation result generation status indicates that the operation result has been formed, and the actual execution process confirmation record indicates that the instruction execution trajectory digest sequence has covered the entire running stage of the target computation code, the trusted sandbox forms a target computation code processing completion confirmation record, and takes the moment of forming the target computation code processing completion confirmation record as the moment the target computation code processing is completed. The target computation code processing completion confirmation record is used to avoid generating the cryptographic credential prematurely before the target computation code has completed all task segments. Subsequently, the trusted sandbox wakes up the built-in zero-knowledge proof generation firmware module based on the confirmation record of the completion of the target computation code. The zero-knowledge proof generation firmware module is in a pending wake-up state within the trusted sandbox. The trusted sandbox performs a wake-up process on the zero-knowledge proof generation firmware module using a firmware entry identifier, a task handle backreference marker, and a proof generation permission marker, ensuring that the zero-knowledge proof generation firmware module reads the instruction execution trajectory summary sequence only after the target computation code has been processed. The firmware entry identifier allows the trusted sandbox to locate the call entry point of the zero-knowledge proof generation firmware module; the task handle backreference marker allows the zero-knowledge proof generation firmware module to backreference the task handle of the target computation code; and the proof generation permission marker restricts the zero-knowledge proof generation firmware module to enter the proof generation state only based on the confirmation record of the completion of the target computation code. The trusted sandbox encapsulates the instruction execution trajectory summary sequence, the actual execution process confirmation record, the confirmation record of the completion of the target computation code, and the summary marker of the computation result into covert verification data, and inputs the covert verification data into the zero-knowledge proof generation firmware module. The technical essence of the hidden verification data is to convert the correspondence between the execution trajectory of the target computation code and the computation result into proof input data that can be processed by the zero-knowledge proof generation firmware module, without including the original plaintext input data of the target computation code.The polynomial commitment transformation calculation operation has been configured according to the proof parameter configuration record before the zero-knowledge proof generation firmware module is activated. The proof parameter configuration record includes a commitment parameter version marker, a digest field arrangement, a digest field constraint, and a verification data generation method. The commitment parameter version marker enables the zero-knowledge proof generation firmware module to read the commitment parameters corresponding to this proof generation. The digest field arrangement ensures that the fields in the instruction execution trajectory digest sequence enter the polynomial commitment transformation calculation operation in a fixed order. The digest field constraint method ensures that the fields in the instruction execution trajectory digest sequence satisfy pre-configured execution trajectory constraints. The verification data generation method limits the generation format of the feature verification data string. Based on the proof parameter configuration record, the zero-knowledge proof generation firmware module performs field constraint transformation processing on the instruction execution trajectory digest sequence in the hidden verification data to form a field constraint transformation processing result. Subsequently, the zero-knowledge proof generation firmware module performs commitment calculation processing on the field constraint transformation processing result to form the feature verification data string. The technical essence of the feature verification data string is that it is the verification data formed by performing commitment calculation on the instruction execution trajectory summary sequence, the actual execution process confirmation record, and the summary tag of the operation result; the feature verification data string is the core content of the cryptographic certificate, enabling the cryptographic certificate to characterize the execution process of the target computation code within the trusted sandbox, which has completed the execution of the corresponding task segment.

[0057] Preferably, the specific implementation process of step "the cryptographic credential is used to enable external verification nodes to independently verify the authenticity and reliability of the entire operation phase solely based on the feature verification data string in the cryptographic credential without reading the original plaintext input data of the target computation code" is as follows: After the vehicle node generates the feature verification data string in the trusted sandbox, it further reads the task handle of the target computation code, the encrypted fragment packet identifier, the digest marker of the operation result, the confirmation record of the target computation code processing completion, and the feature verification data string, and encapsulates the task handle of the target computation code, the encrypted fragment packet identifier, the digest marker of the operation result, the confirmation record of the target computation code processing completion, and the feature verification data string into the cryptographic credential. The cryptographic credential is used to be sent back to the scheduling node along with the operation result, and independently verified by the scheduling node or the external verification node. Upon receiving the cryptographic credential, the external verification node first reads the encrypted fragment packet identifier and the task handle of the target computation code from the cryptographic credential to confirm the source of the task fragment corresponding to the cryptographic credential. Subsequently, the external verification node reads the feature verification data string and, based on the public verification parameters corresponding to the proof parameter configuration record, performs commitment consistency verification, execution trajectory continuity verification, and computation result correspondence verification on the feature verification data string. The public verification parameters are generated corresponding to the commitment parameter version flag, digest field arrangement, digest field constraint, and verification data generation parameters in the proof parameter configuration record. These public verification parameters enable the external verification node to independently verify the feature verification data string without reading the hidden verification data or the original plaintext input data of the target computation code. The commitment consistency check is used to determine whether the feature verification data string originates from the same hidden verification data. The execution trajectory continuity check is used to determine whether the execution trajectory carried by the feature verification data string covers the entire running phase of the target computation code. The operation result correspondence check is used to determine whether the digest tag of the operation result corresponds to the execution trajectory carried by the feature verification data string. The external verification node performs verification without reading the original plaintext input data of the target computation code because the original plaintext input data of the target computation code is decrypted and processed within the trusted sandbox. Exposing the original plaintext input data of the target computation code to the external verification node would weaken the technical role of the encrypted fragment packet and the trusted sandbox in data isolation.The reliability mentioned in this application is not a subjective evaluation, but rather refers to the ability of the external verification node to confirm, through the cryptographic credentials, that the target computation code underwent the entire operational phase within the trusted sandbox, consistent with the instruction execution trajectory digest sequence, and to confirm a verifiable correspondence between the computation result and the entire operational phase experienced by the target computation code within the trusted sandbox. Through the feature verification data string, the external verification node can independently verify the entire operational phase of the target computation code without re-executing it or reading its original plaintext input data. This process establishes a continuous data processing relationship between the vehicle node's local trusted execution, the cryptographic credential return, and the trusted verification of the computation result.

[0058] Optionally, the vehicle node sends the encapsulated computation result and the cryptographic credential back to the scheduling node; the vehicle node controls the underlying driver to clear the temporarily stored data in the trusted sandbox, including: The vehicle node establishes an independent secure transmission channel in the underlying network protocol stack; The vehicle node reports the encapsulated computation result and the cryptographic credentials to the scheduling node through the secure transmission channel; The vehicle node activates its internal isolation timing hardware and monitors the elapsed time parameter after the sending action is completed; The vehicle node invokes a pre-configured temporary data clearing period. When it is determined that the elapsed duration parameter has reached the temporary data clearing period, the vehicle node sends a forced overwrite control word to the underlying memory controller; The underlying memory controller controls the hardware random number generator to generate a noise bit stream based on the forced overwrite control word, and uses the noise bit stream to perform multiple rounds of hard overwrite operations on all physical storage address ranges mapped by the trusted sandbox to erase the temporary data stored in the trusted sandbox.

[0059] Preferably, the specific implementation process of step "the vehicle node establishes an independent secure transmission channel in the underlying network protocol stack" is as follows: After the vehicle node generates the cryptographic credentials in the trusted sandbox and encapsulates the computation result and the cryptographic credentials, it first establishes a return channel establishment record, and establishes a correspondence between the return channel establishment record and the vehicle node identifier, the scheduling node identifier, the encrypted fragment packet identifier, the task handle of the target computation code, the computation result, the cryptographic credentials, and the subsequently formed independent secure transmission channel. The return channel establishment record is used to uniformly record the return object, return source, and return task source of the computation result and the cryptographic credentials, so that the subsequently established independent secure transmission channel can correspond to the running result of the target computation code in this instance, and is not mistakenly used for other external computation tasks. Subsequently, the vehicle node reads the network interface status, link handshake status, session key negotiation status, and scheduling node access address from the underlying network protocol stack. It then matches and verifies the scheduling node access address against the scheduling node identifier to form a backhaul link verification record. This backhaul link verification record simultaneously carries the network interface status, the link handshake status, the session key negotiation status, and the scheduling node access address, enabling the establishment of the independent secure transmission channel to trace back to an available network interface, a valid link handshake, a valid session key negotiation, and the correct scheduling node access address. The underlying network protocol stack is essentially the communication protocol execution environment within the vehicle node used to complete data frame encapsulation, link handshake, session state maintenance, and transmission confirmation. The vehicle node establishes the independent secure transmission channel on the underlying network protocol stack to ensure that the computation results and cryptographic credentials, after leaving the trusted sandbox, are still transmitted back along the controlled backhaul communication path corresponding to the scheduling node. The independent secure transmission channel is not a regular shared reporting channel, but a task-level transmission path created based on the return channel establishment record and the return link verification record. The independent secure transmission channel includes a channel session identifier corresponding to the task handle of the target computation code, a fragment source marker corresponding to the encrypted fragment packet identifier, a credential integrity marker corresponding to the cryptographic credential, and a result integrity marker corresponding to the computation result. By using this independent secure transmission channel to isolate the computation result and the return process of the cryptographic credential, the vehicle node can avoid problems such as unclear task source, untraceable channel status, or inconsistent return confirmations that could arise from the computation result and the cryptographic credential being mixed with other vehicle communication data in the same transmission queue.The relationship between this process and the protection theme of the unified open and scheduling method for idle computing power in new energy vehicles is that the vehicle node not only needs to complete the trusted operation of the target computing code locally, but also needs to send the calculation result and the cryptographic credentials back to the scheduling node through the traceable independent secure transmission channel, so that the scheduling node can subsequently verify the calculation result based on the cryptographic credentials and further trigger the clearing process of the trusted sandbox temporary data.

[0060] Preferably, in the specific technical implementation of the step "the vehicle node reports the encapsulated computation result and the cryptographic certificate to the scheduling node through the secure transmission channel", after the independent secure transmission channel is established, the vehicle node first reads the computation result, the cryptographic certificate, the task handle of the target computation code, the encrypted fragment packet identifier, and the vehicle node identifier, and writes the computation result, the cryptographic certificate, the task handle of the target computation code, the encrypted fragment packet identifier, and the vehicle node identifier into the return payload encapsulation record. The return payload encapsulation record is used to establish a task correspondence between the computation result and the cryptographic certificate within the same return payload; wherein, the computation result is used to express the data processing result formed by the target computation code after processing the corresponding task fragment of the encrypted fragment packet in the trusted sandbox, and the cryptographic certificate is used to express the verifiable data that the target computation code has undergone a verifiable running process in the trusted sandbox. The vehicle node further generates the encapsulated computation result and the cryptographic credential based on the return payload encapsulation record, and writes the encapsulated computation result and the cryptographic credential into the transmission queue of the independent secure transmission channel. The transmission queue of the independent secure transmission channel performs pre-transmission verification on the encapsulated computation result and the cryptographic credential based on the channel session identifier, the result integrity flag, and the credential integrity flag to form a pre-transmission verification record. The pre-transmission verification record is used to confirm that no fields are missing in the encapsulated computation result and the cryptographic credential, and to confirm that the encapsulated computation result and the cryptographic credential still correspond to the task handle of the target computation code. Subsequently, the vehicle node sends the encapsulated computation result and the cryptographic credential to the scheduling node through the independent secure transmission channel, and forms a return reception confirmation record after the scheduling node returns a reception response. The return reception confirmation record includes the scheduling node identifier, the channel session identifier, the task handle of the target computation code, the encrypted fragment packet identifier, the result integrity verification result, the credential integrity verification result, and the reception confirmation time. The return reception confirmation record records the reception status of the computation result and the reception status of the cryptographic credential through the result integrity verification result and the credential integrity verification result, respectively, and then points back to the task handle of the target computation code and the encrypted fragment packet identifier. The technical essence of the vehicle node reporting the encapsulated computation result and the cryptographic credential through the independent secure transmission channel is to simultaneously deliver the trusted execution result and verifiable execution basis to the scheduling node, enabling the scheduling node to perform subsequent verification of the computation result based on the cryptographic credential without needing to read the original plaintext input data of the target computation code.The backhaul reception confirmation record also participates in the start-up judgment of the internal isolation timing hardware, so that the clearing of the trusted sandbox temporary data will not be earlier than the completion of the backhaul action, nor will it be delayed for a long time after the completion of the backhaul action.

[0061] Preferably, the specific implementation process of step "the vehicle node starts the internal isolation timing hardware and monitors the elapsed duration parameter after the sending action is completed" is as follows: After receiving the return reception confirmation record, the vehicle node first reads the reception confirmation time, the task handle of the target computation code, the trusted sandbox isolation running space identifier, and the encrypted fragment packet identifier from the return reception confirmation record, and writes the reception confirmation time, the task handle of the target computation code, the trusted sandbox isolation running space identifier, and the encrypted fragment packet identifier into the clear timing start record. The clear timing start record is used to transform the communication status that the encapsulated computation result and the cryptographic certificate have been confirmed and received by the scheduling node into the timing trigger basis for subsequently clearing the trusted sandbox temporary data. Subsequently, the vehicle node activates its internal isolation timing hardware based on the clear timing start record. The technical essence of this internal isolation timing hardware is a hardware timing unit within the vehicle node used to continuously measure the elapsed time after the data transmission is completed outside the trusted sandbox. This internal isolation timing hardware does not read the temporarily stored data in the trusted sandbox, nor does it read the original plaintext input data of the target computation code; instead, it starts timing only based on the reception confirmation time in the clear timing start record. The internal isolation timing hardware uses a timing path separate from the trusted sandbox's isolated operating space because the trusted sandbox has entered a pending cleanup state after completing the target computation code execution. If the software timing state within the trusted sandbox were still relied upon to trigger the clearing of the temporarily stored data, it would be easily affected by the target computation code's running context, sleep waiting mode, or thread termination state. The vehicle node continuously records the elapsed time from the reception confirmation time through the internal isolation timing hardware and writes this elapsed time into the elapsed duration monitoring record to form the elapsed duration parameter. The technical essence of the elapsed duration parameter is to measure the duration for which the temporarily stored data in the trusted sandbox remains within the physical storage address range mapped by the trusted sandbox after the encapsulated computation result and the cryptographic credential have been successfully transmitted back. The elapsed duration parameter is subsequently compared with the temporary data clearing period on the same time dimension to determine whether the forced overwrite control word should be issued to the underlying memory controller. Through the internal isolated timing hardware and the elapsed duration monitoring record, the vehicle node can fix the technical processing relationship between transmission completion, clearing wait, and forced overwrite triggering into an executable local timing link, ensuring that the temporarily stored data in the trusted sandbox is not retained for an extended period due to the state change after network transmission completion.

[0062] Preferably, in the specific technical implementation of the step "the vehicle node calls the pre-configured temporary data clearing period, and when it is determined that the elapsed duration parameter has reached the temporary data clearing period, the vehicle node issues a forced overwrite control word to the underlying memory controller", after the internal isolation timing hardware is started, the vehicle node first reads the trusted sandbox security cleanup configuration data stored locally, and extracts the temporary data clearing period configuration item, the overwrite round configuration item, the address range read configuration item, and the hardware random number generator call configuration item from the trusted sandbox security cleanup configuration data. The temporary data clearing period configuration item is used to limit the maximum duration for which the trusted sandbox temporary data is allowed to continue to be retained after the operation result and the cryptographic certificate are returned; the overwrite round configuration item is used to limit the execution number of subsequent multiple rounds of hard overwrite operations; the address range read configuration item is used to limit how the vehicle node reads the physical storage address range mapped by the trusted sandbox; the hardware random number generator call configuration item is used to limit how the underlying memory controller triggers the hardware random number generator to generate the noise bit stream. The vehicle node generates a temporary data clearing period record based on the temporary data clearing period configuration item, and writes the temporary data clearing period into the temporary data clearing period record. The configuration principle of the temporary data clearing period is to make the temporary data clearing period later than the confirmation time of the encapsulated calculation result and the cryptographic certificate completion and return, while being shorter than the local exposure time limit caused by the continued retention of the trusted sandbox temporary data; the temporary data clearing period is not a normal waiting time, but rather transforms the retention time constraint of the trusted sandbox temporary data into a trusted sandbox temporary data clearing trigger boundary that can be executed by the vehicle node. The vehicle node reads the elapsed duration monitoring record and compares the elapsed duration parameter with the temporary data clearing period in the temporary data clearing period record under the same time dimension to form a clearing trigger determination record. The clearing trigger determination record establishes a correspondence between the elapsed duration parameter, the temporary data clearing period, the trusted sandbox isolated running space identifier, and the task handle of the target computation code, so that the trusted sandbox temporary data clearing process can correspond to the target computation code that has been returned. The clearing trigger determination record indicates that when the elapsed duration parameter reaches the temporary data clearing period, the vehicle node reads the address range read configuration item and the overwrite round configuration item to generate a forced overwrite control word. The forced overwrite control word includes the trusted sandbox isolated running space identifier, the physical storage address range read flag, the overwrite round flag, the noise bitstream call flag, and the trusted sandbox temporary data clearing task handle.The technical essence of the forced overwrite control word is to transform the clear trigger judgment record into hardware-level clear control data that can be executed by the underlying memory controller. The vehicle node sends the forced overwrite control word to the underlying memory controller, so that the clearing process of the trusted sandbox temporary data is changed from ordinary file deletion to low-level write control of the physical storage address range mapped by the trusted sandbox, thereby reducing the risk of the trusted sandbox temporary data remaining in the local storage medium.

[0063] Preferably, the specific implementation process of step "the underlying memory controller controls the hardware random number generator to generate a noise bitstream based on the forced overwrite control word" is as follows: After receiving the forced overwrite control word, the underlying memory controller first reads the trusted sandbox isolated running space identifier, the physical storage address range read flag, the overwrite round flag, the noise bitstream call flag, and the trusted sandbox temporary data clearing task handle from the forced overwrite control word, and then writes the forced overwrite control word into the memory overwrite execution record. The memory overwrite execution record is used to convert the trusted sandbox temporary data clearing task already triggered by the vehicle node into an overwrite task state that the underlying memory controller can execute, so that the underlying memory controller can perform subsequent processing according to the physical storage address range read flag and the overwrite round flag defined by the forced overwrite control word. Subsequently, the underlying memory controller starts the hardware random number generator according to the noise bitstream call flag and writes a noise bitstream generation request to the hardware random number generator. The noise bitstream generation request establishes a correspondence with the trusted sandbox temporary data clearing task handle, ensuring that the noise bitstream generated by the hardware random number generator is limited to the data source written for this trusted sandbox temporary data clearing task. The hardware random number generator collects random disturbance sources from the internal hardware operating state of the vehicle node according to the noise bitstream generation request and performs bit conversion processing on these random disturbance sources to form the noise bitstream. The hardware random number generator is essentially a hardware data source within the vehicle node used to generate random bit data that cannot be predetermined by the target computation code; the noise bitstream is essentially randomized write data formed by the hardware random number generator and used to overwrite the trusted sandbox temporary data. The underlying memory controller does not directly overwrite the trusted sandbox temporary data with fixed byte values. Instead, it performs subsequent multiple rounds of hard overwrite operations based on the noise bitstream. This is because fixed byte value overwriting easily creates regular residues in the write paths of different storage media, while the noise bitstream ensures that the data content written in each overwrite is different, reducing the risk of deducing the trusted sandbox temporary data from the storage residue state. The underlying memory controller writes the noise bitstream into the memory overwrite execution record and establishes a correspondence between the noise bitstream and the trusted sandbox temporary data clearing task handle, the overwrite round marker, and the trusted sandbox isolated running space identifier. This ensures that the noise bitstream will not be separated from the current trusted sandbox temporary data clearing task and misused by other storage processing processes.Through the continuous processing relationship between the forced overwrite control word, the memory overwrite execution record, the hardware random number generator, and the noise bit stream, the vehicle node can realize the trusted sandbox temporary data clearing requirement triggered by the temporary data clearing period as a source of underlying executable randomized overwrite data.

[0064] Preferably, in the specific technical implementation of the step "the underlying memory controller performs multiple rounds of hard overwrite operations on all physical storage address ranges mapped by the trusted sandbox using the noise bitstream to erase the temporary data stored in the trusted sandbox", after obtaining the noise bitstream, the underlying memory controller first reads the trusted sandbox address mapping record based on the trusted sandbox isolated operating space identifier in the forced overwrite control word. The trusted sandbox address mapping record is formed by the vehicle node when creating the trusted sandbox, and the trusted sandbox address mapping record includes the trusted sandbox isolated operating space identifier, the trusted sandbox virtual address range, the physical storage address range, the address mapping version flag, and the address mapping valid status flag; the trusted sandbox address mapping record is used to convert the trusted sandbox virtual address range visible inside the trusted sandbox into the physical storage address range that the underlying memory controller can directly write. The technical essence of the physical storage address range is the underlying address range actually occupied by the trusted sandbox temporary data in the local storage medium or addressable memory area. The underlying memory controller needs to read the physical storage address range because simply deleting the file index or task handle within the trusted sandbox cannot directly change the underlying storage content where the trusted sandbox temporary data resides. Subsequently, the underlying memory controller performs multiple rounds of hard overwrite operations on the physical storage address range according to the overwrite round marker. In each round of the multiple hard overwrite operations, a bit segment matching the length of the physical storage address range is read from the noise bit stream and written into the physical storage address range to form the overwrite status record for the corresponding round. The multi-round hard overwrite operation is performed in multiple rounds because the trusted sandbox temporary data may be distributed across cache lines, page frames, mapping buffers, and intermediate task state storage areas. A single overwrite is easily affected by write cache, wear leveling, or page remapping. Through the multi-round hard overwrite operation, the underlying memory controller can repeatedly overwrite the physical storage address range, so that the residual state of the trusted sandbox temporary data in multiple underlying storage locations is replaced by the randomized write data corresponding to the noise bitstream. After completing the multi-round hard overwrite operation, the underlying memory controller reads the overwrite state record of each round and performs address coverage integrity verification on the overwrite state record to form a trusted sandbox temporary data clearing record. The trusted sandbox temporary data clearing record includes the trusted sandbox isolated running space identifier, the physical storage address range, the overwrite round marker, the trusted sandbox temporary data clearing task handle, and the address coverage integrity verification result.The trusted sandbox temporary data clearing record is subsequently used to indicate that the trusted sandbox temporary data has been hard overwritten from the physical storage address range; this process, together with the independent secure transmission channel, the return reception confirmation record, the internal isolation timing hardware, the forced overwrite control word, and the noise bit stream, forms a continuous data processing relationship, enabling the vehicle node to perform traceable low-level clearing processing on the trusted sandbox temporary data after completing the encapsulation of the calculation results and the return of the cryptographic credentials.

[0065] like Figure 3 As shown in the figure, a unified open and scheduling device for idle computing power in new energy vehicles is provided according to an embodiment of this application, which includes: The parameter processing module is used to obtain the physical operating parameters of the vehicle node; control the vehicle node to call the abstract layer hardware translation component in the hardware interface to perform conversion on the physical operating parameters to generate computing power feature words; and send the computing power feature words to the scheduling node. The task distribution module is used to control the scheduling node to receive distributed processing task requests and extract task resource identifiers from the distributed processing task requests; control the scheduling node to parse the computing power feature words and construct encrypted fragment packets based on the task resource identifiers and the computing power feature words; and control the scheduling node to send the encrypted fragment packets to the vehicle nodes. The sandbox operation and monitoring module is used to control the vehicle node to decrypt the encrypted fragment packet in a local trusted sandbox to obtain the target computing code and run it; during the process of running the target computing code, the module controls the vehicle node to use the kernel module to monitor the physical operating parameters. When the kernel module finds that the physical operating parameters trigger a hard interrupt condition, the module controls the vehicle node to initiate a system interrupt to suspend the target computing code. The credential return module is used to control the vehicle node to generate cryptographic credentials within the trusted sandbox after the target calculation code has been executed; to control the vehicle node to encapsulate the calculation result and the cryptographic credentials; and to control the vehicle node to return the encapsulated calculation result and the cryptographic credentials to the scheduling node. The data cleanup module is used to control the underlying driver of the vehicle node to clear the temporary data stored in the trusted sandbox.

[0066] like Figure 4 As shown, an electronic device according to an embodiment of this application includes: processor; Memory used to store the processor's executable instructions; The processor is configured to implement the steps of the unified opening and scheduling method for idle computing power in new energy vehicles as described in any one of this application when executing the executable instructions.

[0067] like Figure 5 As shown, a computer-readable storage medium is provided in an embodiment of this application. The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the steps of the unified opening and scheduling method for idle computing power in new energy vehicles as described in any one of this application.

[0068] like Figure 6 As shown, this is a vehicle according to an embodiment of the present application. The vehicle is connected to the computing power scheduling network as a vehicle node. The vehicle includes an on-board computing unit and an on-board communication interface that is communicatively connected to the on-board computing unit. The on-board computing unit is configured to perform the steps executed by the vehicle node in the unified opening and scheduling method for idle computing power in new energy vehicles as described in any one of the present applications.

[0069] like Figure 7 As shown in the figure, a unified open and scheduling system for idle computing power in new energy vehicles is provided in an embodiment of this application. The system includes a scheduling node and at least one vehicle node that is communicatively connected to the scheduling node. The vehicle node is configured to perform the steps executed by the vehicle node in the unified opening and scheduling method for idle computing power in new energy vehicles as described in any one of this application; The scheduling node is configured to perform the steps executed by the scheduling node in the unified opening and scheduling method for idle computing power in new energy vehicles as described in any one of the present applications.

[0070] The above Figures 3-7 For an exemplary description, please refer to the above. Figure 1 This will not be elaborated upon here.

Claims

1. A method for unified opening and scheduling of idle computing power in new energy vehicles, characterized in that, include: Obtain the physical operating parameters of the vehicle node; The vehicle node invokes the abstract layer hardware translation component in the hardware interface to perform conversion on the physical operating parameters in order to generate computing power feature words; The vehicle node sends the computing power feature word to the scheduling node; The scheduling node receives distributed processing task requests and extracts task resource identifiers from the distributed processing task requests. The scheduling node parses the computing power feature word and constructs an encrypted fragment packet based on the task resource identifier and the computing power feature word; The scheduling node sends the encrypted fragmented packet to the vehicle node; The vehicle node decrypts the encrypted fragment packet in a local trusted sandbox to obtain the target computing code and runs it. During the process of running the target computing code, the vehicle node uses the kernel module to monitor the physical operating parameters. When the kernel module finds that the physical operating parameters trigger a hard interrupt condition, the vehicle node initiates a system interrupt to suspend the target computing code. After the target computation code is executed, the vehicle node generates cryptographic credentials within the trusted sandbox. The vehicle node encapsulates the computation result and the cryptographic credential; The vehicle node will send the encapsulated computation result and the cryptographic certificate back to the scheduling node; The vehicle node control underlying driver clears the temporary data stored in the trusted sandbox within the trusted sandbox.

2. The method according to claim 1, characterized in that, The physical operating parameters include the battery's available energy storage ratio; During the process of running the target computation code, the vehicle node uses a kernel module to monitor the physical operating parameters; When the kernel module detects that the physical operating parameters trigger a hard interrupt condition, the vehicle node initiates a system interrupt to suspend the target computation code, including: The vehicle node is pre-configured with a first energy storage protection parameter and a second energy storage protection parameter in the kernel module, wherein the value of the first energy storage protection parameter is greater than the value of the second energy storage protection parameter; The vehicle node reads the available energy storage ratio of the battery in real time through the internal battery management bus; When the available energy storage ratio of the battery drops to the first energy storage protection parameter, the kernel module sends a request packet to the scheduling node to refuse to receive new fragments. The scheduling node stops sending new encrypted fragment packets to the vehicle node based on the refusal to receive new fragment request packets; The kernel module maintains the current execution thread of the target computation code; When the available energy storage ratio of the battery continues to drop to the second energy storage protection parameter, the kernel module determines that the hard interrupt condition is met; The kernel module sends a thread freeze command to the trusted sandbox; The trusted sandbox forcibly suspends the current execution thread of the target computation code based on the thread freeze instruction.

3. The method according to claim 1, characterized in that, The physical operating parameters include the physical junction temperature data of the main control chip node; During the process of running the target computation code, the vehicle node uses a kernel module to monitor the physical operating parameters; When the kernel module detects that the physical operating parameters trigger a hard interrupt condition, the vehicle node initiates a system interrupt to suspend the target computation code, including: The vehicle node is pre-configured in the kernel module with thermal warning limits and thermal threshold upper limits; The kernel module continuously collects the physical junction temperature data within a preset period; When the physical junction temperature data is continuously monitored to reach the thermal warning limit, the kernel module sends a frequency reduction control signal to the underlying clock controller; The clock controller lowers the operating clock frequency of the main control chip node based on the frequency reduction control signaling; When the physical junction temperature data is found to exceed the upper limit of the thermal threshold, the kernel module determines to trigger the hard interrupt condition; The kernel module cuts off the computing resource supply to the trusted sandbox in order to forcibly suspend the target computing code; The kernel module migrates the current execution context of the target computation code to a non-volatile medium for storage; The current running context in the non-volatile medium serves as the basis for hot interrupt recovery when the target computation code resumes operation.

4. The method according to claim 1, characterized in that, The physical operating parameters include autonomous driving intent activation signaling fed back from the vehicle's sensors; During the process of running the target computation code, the vehicle node uses a kernel module to monitor the physical operating parameters; When the kernel module detects that the physical operating parameters trigger a hard interrupt condition, the vehicle node initiates a system interrupt to suspend the target computation code, including: The vehicle node is pre-configured with an absolute latency limit in the kernel module; The vehicle node continuously parses the autonomous driving intent activation signaling broadcast by the vehicle chassis network; When the autonomous driving intention activation signal is captured, the kernel module determines that the hard interrupt condition is triggered; The kernel module injects a preset level interrupt vector into the trusted sandbox within the absolute latency limit; The trusted sandbox responds to the preset level interrupt vector; The trusted sandbox terminates the execution flow of the target computation code; The trusted sandbox releases the corresponding hardware computing core resources; The vehicle node will allocate the released hardware computing core resources to the local autonomous driving perception and decision-making unit. The autonomous driving perception and decision-making unit performs local autonomous driving perception and decision-making processing based on the hardware computing core resources.

5. The method according to claim 1, characterized in that, The vehicle node invokes the abstract layer hardware translation component in the hardware interface to perform a conversion on the physical operating parameters, in order to generate computing power feature words, including: The vehicle node reads the chip manufacturer identification parameter and physical memory capacity parameter stored in the local system register; The vehicle node inputs the physical operating parameters, the chip manufacturer identification parameters, and the physical memory capacity parameters into the pre-deployed abstraction layer hardware translation component; The abstract layer hardware translation component performs low-level field mapping processing on the input data according to the pre-agreed general description protocol rules of the communication network, and encapsulates the processing results based on the low-level field mapping processing to generate the computing power feature word in a unified format that transcends hardware differences. The computing power feature word includes a physical operating parameter field, a chip manufacturer identification field, and a physical memory capacity field, so that the scheduling node can identify the available computing status of the vehicle node based on the computing power feature word.

6. A unified open and scheduling device for idle computing power in new energy vehicles, characterized in that, include: The parameter processing module is used to obtain the physical operating parameters of the vehicle node; control the vehicle node to call the abstract layer hardware translation component in the hardware interface to perform conversion on the physical operating parameters to generate computing power feature words; and send the computing power feature words to the scheduling node. The task distribution module is used to control the scheduling node to receive distributed processing task requests and extract task resource identifiers from the distributed processing task requests; control the scheduling node to parse the computing power feature word and construct encrypted fragment packets based on the task resource identifier and the computing power feature word; And control the scheduling node to send the encrypted fragmented packet to the vehicle node; The sandbox operation and monitoring module is used to control the vehicle node to decrypt the encrypted fragment packet in a local trusted sandbox to obtain the target computing code and run it; during the process of running the target computing code, the module controls the vehicle node to use the kernel module to monitor the physical operating parameters. When the kernel module finds that the physical operating parameters trigger a hard interrupt condition, the module controls the vehicle node to initiate a system interrupt to suspend the target computing code. The credential return module is used to control the vehicle node to generate cryptographic credentials within the trusted sandbox after the target calculation code has been executed; to control the vehicle node to encapsulate the calculation result and the cryptographic credentials; and to control the vehicle node to return the encapsulated calculation result and the cryptographic credentials to the scheduling node. The data cleanup module is used to control the underlying driver of the vehicle node to clear the temporary data stored in the trusted sandbox.

7. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to implement the steps of the method for unified opening and scheduling of idle computing power in new energy vehicles as described in any one of claims 1 to 5 when executing the executable instructions.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the steps of the unified opening and scheduling method for idle computing power in new energy vehicles as described in any one of claims 1 to 5.

9. A vehicle, characterized in that, The vehicle is connected to the computing power scheduling network as a vehicle node. The vehicle includes an on-board computing unit and an on-board communication interface that is communicatively connected to the on-board computing unit. The on-board computing unit is configured to perform the steps executed by the vehicle node in the method for unified opening and scheduling of idle computing power in new energy vehicles as described in any one of claims 1 to 5.

10. A unified open and scheduling system for idle computing power in new energy vehicles, characterized in that, It includes a scheduling node and at least one vehicle node that is communicatively connected to the scheduling node; The vehicle node is configured to perform the steps executed by the vehicle node in the unified opening and scheduling method for idle computing power in new energy vehicles as described in any one of claims 1 to 5; The scheduling node is configured to execute the steps performed by the scheduling node in the unified opening and scheduling method for idle computing power in new energy vehicles as described in any one of claims 1 to 5.

Images