Methods, devices, equipment, media, and vehicles for opening up idle computing power of parked vehicles to personal devices.

Abstract

This application provides a method, apparatus, electronic device, computer-readable storage medium, and vehicle for opening up idle computing power of parked vehicles to personal devices. The method includes: collecting current powertrain status data and current chassis parking status data of the vehicle; activating a computing power sharing communication node if the conditions for opening up parking computing power are met; establishing a first and a second physical isolation domain within the onboard computing platform; running a low-level hardware daemon process in the first physical isolation domain to continuously collect real-time vehicle chassis signals; receiving and verifying the identity credential sequence of external devices through the communication node to determine the target access device and sending it a list of available computing power resources; receiving pending computing instruction data; and performing logical operations in the second physical isolation domain, generating and transmitting the target computation result data segment, provided that no chassis reset interrupt condition is triggered.

Description

Technical Field

[0001] This application relates to the field of vehicle computing systems and multi-device computing power collaboration technology. Specifically, it relates to a method for opening up idle computing power of a parked vehicle to personal devices, a device for opening up idle computing power of a parked vehicle to personal devices, an electronic device, a computer-readable storage medium, and a vehicle. Background Technology

[0002] With the rapid development of intelligent new energy vehicles, in order to support advanced autonomous driving functions, vehicles are generally equipped with high-performance onboard computing platforms, including neural processing units (NPUs), graphics processing units (GPUs), and central processing units (CPUs). However, private cars are mostly parked during daily use, with relatively short actual driving time. This results in the huge computing resources of the onboard platform being completely idle during the vehicle's parking period, causing a significant waste of computing resources.

[0003] Existing solutions for utilizing idle computing power typically employ a centralized cloud-based distributed network architecture to collect computing power from parked vehicles. Specifically, this solution uses a cloud management platform to centrally schedule vehicle data and computing resources, distributing third-party AI training and other computing tasks to the onboard computing platform for execution. After the onboard platform completes the relevant computing tasks, the system uniformly transmits the calculation results back to a third-party server platform in the cloud for archiving and use.

[0004] However, this computing power allocation scheme has significant technical flaws. Since existing schemes primarily target cloud-based tasks on third-party platforms, they lack local identity verification and radio frequency communication mechanisms between the vehicle and external devices. This prevents vehicle owners from directly granting access to their personal target devices for private use. Furthermore, without a strict distinction between the first and second physical isolation domains, the execution of external computing commands can easily disrupt the underlying hardware daemon's acquisition and response to real-time vehicle chassis signals. This makes it impossible to guarantee the priority reset and secure interruption of core chassis functions, resulting in the idle computing power of parked vehicles being unable to securely and stably serve the vehicle owner's personal devices. Summary of the Invention

[0005] This application provides a method, apparatus, electronic device, computer-readable storage medium, and vehicle for opening up idle computing power of parked vehicles to personal devices, so as to at least alleviate the above-mentioned technical problems.

[0006] A method for opening up idle computing power of parked vehicles to personal devices, the method comprising the following steps: Collect the current powertrain status data and the current chassis parking status data of the vehicle; if the current powertrain status data and the current chassis parking status data meet the parking computing power opening conditions, activate the computing power sharing communication node; A first physical isolation domain and a second physical isolation domain are established within the vehicle computing platform; a low-level hardware daemon process is run in the first physical isolation domain to continuously collect real-time vehicle chassis signals. The computing power sharing communication node receives the identity credential sequence of external devices, verifies the identity credential sequence to determine the target access device, and sends the available computing power resource status list to the target access device. The system receives the pending calculation instruction data issued by the target access device; if the real-time vehicle chassis signal does not trigger the chassis reset interruption condition, it performs logical operation on the pending calculation instruction data in the second physical isolation domain to generate a target calculation result data segment, and transmits the target calculation result data segment to the target access device.

[0007] Optionally, the step of activating the computing power sharing communication node if the current powertrain status data and the current chassis parking status data meet the parking computing power opening conditions includes: Extract the current wheel speed sensor pulse count value from the current powertrain status data; Extract the current drive motor operating current value from the current powertrain status data; Extract the current gear mechanical lock status bit from the current chassis parking status data; Extract the current electronic parking caliper lock flag from the current chassis parking status data; The extracted current wheel speed sensor pulse count value, current drive motor operating current value, current gear mechanical lock status bit, and current electronic parking caliper lock flag bit are used as the logical basis for determining the parking computing power opening condition. If the current wheel speed sensor pulse count value is equal to zero, the current drive motor operating current value is equal to zero, the current gear mechanical lock state is in the locked state, and the current electronic parking caliper lock flag is in the set state, it is determined that the parking computing power opening condition is met. A node wake-up interrupt signal is generated, and a working voltage is provided to the computing power sharing communication node in the dormant state according to the node wake-up interrupt signal to activate the computing power sharing communication node.

[0008] Optionally, the step of establishing the first physical isolation domain and the second physical isolation domain within the vehicle-mounted computing platform includes: Collect the current remaining power battery charge value of the vehicle, and calculate the total upper limit of available resources based on the current remaining power battery charge value; Read the pre-burned system base configuration file and extract the factory-set basic driving core retention count from it; The total number of available physical cores of the vehicle computing platform is subtracted from the number of basic driving reserved cores to obtain the total number of remaining idle cores, and the total number of remaining idle cores is used as a reference benchmark for resource allocation. If the total limit of available resources is less than the total number of remaining idle cores, the total limit of available resources will be set as the target number of open computing cores. If the total upper limit of the available resources is not less than the total number of remaining idle cores, the total number of remaining idle cores is set as the target number of open computing cores; The first processor hardware region is allocated according to the number of basic driving cores, and the first physical isolation domain is constructed using the first processor hardware region. The second processor hardware space is allocated according to the target number of open computing cores, and the second physical isolation domain is constructed using the second processor hardware space to complete the establishment of the first physical isolation domain and the second physical isolation domain within the vehicle computing platform.

[0009] Optionally, the step of receiving the identity credential sequence of an external device through the computing power sharing communication node and verifying the identity credential sequence to determine the target access device includes: The computing power sharing communication node receives the initial handshake message broadcast by the external device and extracts the device's physical hardware address and the identity credential sequence from it. The system calls the pre-stored authorized binding whitelist record table in the vehicle security encryption chip, using the device's physical hardware address and the identity credential sequence as the query index; Check the authorized binding whitelist record table to see if there is a matching record entry; If a matching record is found, the identity credential sequence is verified and a secure socket connection is established with the external device through the computing power sharing communication node. The external device that successfully establishes the secure socket connection is marked as the target access device to identify the target access device.

[0010] Optionally, the step of sending the available computing power resource status list to the target access device includes: Traverse the currently unoccupied computing hardware clusters mounted within the second physical isolation domain; The statistics include the number of available threads of general-purpose processors, the number of available rendering pipelines of graphics accelerators, and the number of available multiply-accumulators of tensor processing units within the currently unused computing hardware clusters. The statistically obtained values ​​are encapsulated into a hardware resource status structure, and the hardware resource status structure is set as the available computing power resource status list. The available computing power resource status list is transmitted to the target access device through the computing power sharing communication node, so as to send the available computing power resource status list to the target access device.

[0011] Optionally, the step of performing logical operations on the computation instruction data to be processed in the second physical isolation domain to generate the target computation result data segment includes: Parse the header control field of the computation instruction data to be processed, and read the instruction computation type identifier code from it; According to the instruction calculation type identifier code, the computing hardware is matched in the second physical isolation domain, and the computing instruction data to be processed is routed to the matched hardware execution unit; If the instruction calculation type identifier is a tensor matrix multiplication identifier, the tensor processing unit in the second physical isolation domain can use a multiply-accumulator to perform the logical operation. If the instruction calculation type identifier is a pixel rasterization calculation identifier, the logical operation can be performed by the graphics accelerator in the second physical isolation domain using the rendering pipeline. Collect the operation cache output data block generated by the logical operation, and concatenate and combine the operation cache output data block to generate the target operation result data segment.

[0012] Optionally, after the step of receiving the processing instruction data issued by the target access device, the method further includes: Extract the process task identifier and the total number of instructions from the computation instruction data to be processed; Real-time statistics are performed on the number of currently consumed instructions that have been completed by the second physical isolation domain for the computation instruction data to be processed; Calculate the progress percentage based on the current number of consumed instructions and the total number of instructions; Obtain the video memory address pointer of the vehicle cockpit domain controller, and write the process task identifier code and the progress percentage value into the physical video memory mapping area corresponding to the video memory address pointer. The cockpit LCD display panel is triggered to read the values ​​in the physical memory mapping area and refresh the display progress graphic component elements to provide feedback on the execution progress of the pending calculation instruction data through the vehicle's local hardware.

[0013] Optionally, the step of the underlying hardware daemon continuously collecting real-time vehicle chassis signals and determining whether a chassis reset interrupt condition is triggered includes: The underlying hardware daemon process is used to extract chassis control action levels from the real-time vehicle chassis signals collected in real time. The extracted chassis control action level is compared with a preset hardware wake-up threshold. If the chassis control action level meets the hardware wake-up threshold, it is determined that the chassis reset interrupt condition is triggered. When the chassis reset interrupt condition is triggered, a hardware interrupt request instruction with the highest priority is sent to the second physical isolation domain; The hardware interrupt request instruction is used to forcibly terminate all logical operations running within the second physical isolation domain. Clear the system hardware resources occupied by the second physical isolation domain and send a session abnormal disconnection notification message to the target access device to execute the interrupt blocking logic when the chassis reset interrupt condition is triggered.

[0014] Optionally, the step of transmitting the target computation result data segment to the target access device includes: Read the target storage path description string carried in the computation instruction data to be processed, and use it as the destination address for data transmission; The end-to-end communication symmetric key within the vehicle-mounted safety computing environment is invoked, and the end-to-end communication symmetric key is used to perform a cryptographic encryption operation on the target computation result data segment to generate a ciphertext payload data block. The encrypted payload data block and the target storage path description string are encapsulated into a standard transport protocol data packet; The standard transmission protocol data packet is pushed to the target access device through the computing power sharing communication node to complete the transmission of the target computation result data segment to the target access device; The target access device is triggered to store the decrypted ciphertext payload data block into the physical storage sector corresponding to the target storage path description string.

[0015] A device for opening up idle computing power of parked vehicles to personal devices, the device comprising: The data acquisition module is used to collect the current powertrain status data and the current chassis parking status data of the vehicle. The node activation module is used to activate the computing power sharing communication node when the current powertrain status data and the current chassis parking status data meet the parking computing power opening conditions. The isolation domain establishment module is used to establish a first physical isolation domain and a second physical isolation domain within the vehicle computing platform. The monitoring module is used to run a low-level hardware daemon process in the first physical isolation domain and to continuously collect real-time vehicle chassis signals using the low-level hardware daemon process. The verification and authentication module is used to receive the identity credential sequence of external devices through the computing power sharing communication node, and to verify the identity credential sequence to determine the target access device; The resource announcement module is used to send a list of available computing resources to the target access device. The task receiving module is used to receive the unprocessed calculation instruction data sent by the target access device; The collaborative computing module is used to perform logical operations on the computation instruction data to be processed in the second physical isolation domain and generate a target computation result data segment when the real-time vehicle chassis signal does not trigger the chassis reset interruption condition. The data return module is used to transmit the target calculation result data segment to the target access device.

[0016] An electronic device, the electronic device comprising: Memory, used to store computer programs; The steps of a method for opening up idle computing power of a parked vehicle to a personal device when the processor executes the computer program stored in the memory.

[0017] A computer-readable storage medium storing a computer program, wherein when executed by a processor, the computer program implements the steps of a method for opening up idle computing power of a parked vehicle to a personal device.

[0018] A vehicle, the vehicle comprising: An in-vehicle computing platform, wherein the in-vehicle computing platform is configured with a first processor hardware area and a second processor hardware area; A communication bus connects the on-board computing platform and the vehicle chassis sensors, and is used to transmit current powertrain status data, current chassis parking status data, and real-time vehicle chassis signals. A computing power sharing communication node, which is connected to the vehicle-mounted computing platform, is used to establish a radio frequency communication link with external devices; The in-vehicle computing platform is configured as follows: The system determines whether the conditions for opening up parking computing power are met based on the data transmitted through the communication bus. If the conditions are met, the computing power sharing communication node is activated. A first physical isolation domain is constructed within the first processor hardware area to run a low-level hardware daemon process to monitor the real-time vehicle chassis signals through the communication bus. A second physical isolation domain is constructed within the second processor hardware area to perform logical operations on the unprocessed computing instruction data of the target access device obtained through the computing power sharing communication node, and to generate a target computing result data segment. When the real-time vehicle chassis signal triggers the chassis reset interrupt condition, the computing process in the second physical isolation domain is forcibly terminated by a hardware interrupt instruction to ensure the rollback priority of basic driving functions.

[0019] The technical advantages of the technical solution provided in this application are: This application's method for opening up idle computing power in parked vehicles to personal devices addresses the technical shortcomings of existing technologies where idle vehicle computing power can only output computing resources to third-party cloud platforms through a distributed architecture. This prevents vehicle owners from securely and privately allocating vast amounts of idle computing power to personal devices. By collecting the vehicle's current powertrain status data and current chassis parking status data, and activating the computing power sharing communication node when conditions are met, this solves the problem of personal devices being unable to directly establish computing power connections with vehicles in traditional solutions. Compared to traditional methods that rely on cloud-based scheduling commands and unified task distribution, this application uses the computing power sharing communication node to receive the identity credential sequence of external devices for low-level verification, thereby directly identifying the target access device. This allows vehicle owners to seamlessly connect their personal devices to the vehicle's computing platform at the local end, significantly improving the privacy and communication efficiency of personal computing task initiation and result return.

[0020] Furthermore, addressing the technical deficiency in existing technologies—the lack of hardware-level isolation mechanisms when vehicles and external devices collaborate, which easily leads to external tasks affecting the underlying vehicle driving safety monitoring—this application innovatively establishes a first physical isolation domain and a second physical isolation domain within the onboard computing platform. In the first physical isolation domain, a low-level hardware daemon continuously collects real-time vehicle chassis signals, while the logical operations of the computational instructions sent by the target access device are confined to the second physical isolation domain. Compared to traditional centralized computing architectures without strict physical separation, this application's dual-isolation domain mechanism effectively isolates the data links between external personal task computation and the vehicle's underlying sensors. This ensures that even when complex, heavy-load computational instructions are sent externally, the target computation result data segment can be safely generated without triggering a chassis reset interruption. This design guarantees the highest priority and immediate interruption response capability of the underlying driving functions, resulting in high system stability and high underlying execution security during the process of opening computing power to the owner's personal devices. Attached Figure Description

[0021] Figure 1 This application provides an embodiment of a scenario where idle computing power of parked vehicles is made available to personal devices. Figure 2 This application provides a method for opening up idle computing power of parked vehicles to personal devices. Figure 3 This application provides an embodiment of a device that allows idle computing power of parked vehicles to be accessed by personal devices. Figure 4 This is an electronic device according to an embodiment of the present application. Figure 5 This is a computer-readable storage medium according to an embodiment of the present application. Figure 6 This is a vehicle as described in an embodiment of this application. Detailed Implementation

[0022] like Figure 1 The image shows a scenario where idle computing power from parked vehicles is made available to personal devices, according to an embodiment of this application. Figure 2 The image shows a method for opening up idle computing power of parked vehicles to personal devices according to an embodiment of this application. The method includes the following steps: Collect the current powertrain status data and the current chassis parking status data of the vehicle; if the current powertrain status data and the current chassis parking status data meet the parking computing power opening conditions, activate the computing power sharing communication node; A first physical isolation domain and a second physical isolation domain are established within the vehicle computing platform; a low-level hardware daemon process is run in the first physical isolation domain to continuously collect real-time vehicle chassis signals. The computing power sharing communication node receives the identity credential sequence of external devices, verifies the identity credential sequence to determine the target access device, and sends the available computing power resource status list to the target access device. The system receives the pending calculation instruction data issued by the target access device; if the real-time vehicle chassis signal does not trigger the chassis reset interruption condition, it performs logical operation on the pending calculation instruction data in the second physical isolation domain to generate a target calculation result data segment, and transmits the target calculation result data segment to the target access device.

[0023] Optionally, the step of activating the computing power sharing communication node if the current powertrain status data and the current chassis parking status data meet the parking computing power opening conditions includes: Extract the current wheel speed sensor pulse count value from the current powertrain status data; Extract the current drive motor operating current value from the current powertrain status data; Extract the current gear mechanical lock status bit from the current chassis parking status data; Extract the current electronic parking caliper lock flag from the current chassis parking status data; The extracted current wheel speed sensor pulse count value, current drive motor operating current value, current gear mechanical lock status bit, and current electronic parking caliper lock flag bit are used as the logical basis for determining the parking computing power opening condition. If the current wheel speed sensor pulse count value is equal to zero, the current drive motor operating current value is equal to zero, the current gear mechanical lock state is in the locked state, and the current electronic parking caliper lock flag is in the set state, it is determined that the parking computing power opening condition is met. A node wake-up interrupt signal is generated, and a working voltage is provided to the computing power sharing communication node in the dormant state according to the node wake-up interrupt signal to activate the computing power sharing communication node.

[0024] Preferably, the specific implementation process of activating the computing power sharing communication node if the current powertrain status data and the current chassis parking status data meet the parking computing power opening conditions is as follows: After collecting the current powertrain status data and the current chassis parking status data of the vehicle, a parking judgment sampling window is first established according to the vehicle's underlying time reference, and the current powertrain status data and the current chassis parking status data are read respectively within the parking judgment sampling window. The vehicle's underlying time reference is used to limit the sampling time reference of the current powertrain status data and the current chassis parking status data. The parking judgment sampling window is formed according to the vehicle's underlying time reference and is used to convert instantaneous sampling values ​​into continuous sampling states, avoiding the brief sampling jitter state formed when the vehicle has just completed braking, shifted gears, or executed electronic parking directly participating in the determination of the parking computing power opening conditions. The current powertrain status data provides the current wheel speed sensor pulse count and the current drive motor operating current value within the parking determination sampling window. The current chassis parking status data provides the current gear mechanical lock status and the current electronic parking caliper lock status within the parking determination sampling window. Therefore, the parking determination sampling window unifies the vehicle motion state, vehicle driving state, vehicle gear lock status, and vehicle brake holding state under the vehicle's underlying time reference. This ensures that the subsequent determination of the parking computing power opening condition is not based on a single vehicle interface state or a single sensor signal, but rather on the combined vehicle motion state, vehicle driving state, vehicle gear lock status, and vehicle brake holding state. When the brief sampling jitter state is confined outside the parking determination sampling window, the current wheel speed sensor pulse count, the current drive motor operating current value, the current gear mechanical lock status, and the current electronic parking caliper lock status enter the subsequent determination process, thus providing continuous sampling basis for determining the parking computing power opening condition.

[0025] Preferably, when extracting the current wheel speed sensor pulse count value from the current powertrain status data, the pulse count records corresponding to each wheel speed sensor are first read from the vehicle control bus used to transmit the current powertrain status data. Then, the pulse count records are windowed and merged according to the parking determination sampling window to form the current wheel speed sensor pulse count value. The vehicle control bus provides the underlying data source for the current powertrain status data. The pulse count records characterize the pulse change state formed by each wheel speed sensor within the parking determination sampling window. The window merging process unifies the pulse count records corresponding to multiple wheels into the current wheel speed sensor pulse count value. The current wheel speed sensor pulse count value characterizes whether a pulse increment caused by wheel rotation occurs in the parking determination sampling window. When the current wheel speed sensor pulse count value is equal to zero, it indicates that no pulse increment triggered by wheel rotation is detected in the parking determination sampling window. To reduce the impact of single sampling errors on the judgment results, the current wheel speed sensor pulse count values ​​that are all equal to zero within multiple consecutive parking judgment sampling windows can be organized into a continuous zeroing judgment record. This continuous zeroing judgment record continues to participate in the judgment of the parking computing power opening condition. The continuous zeroing judgment record is used to reflect the time continuity of the vehicle speed remaining at zero. The continuous zeroing judgment duration can be configured according to the sampling frequency of the vehicle platform (e.g., configured as several consecutive sampling windows, or configured as the number of consecutive sampling windows corresponding to 30 seconds). The continuous zeroing judgment duration is used to limit the generation conditions of the continuous zeroing judgment record, thereby distinguishing between a short pause in the vehicle and the vehicle entering a parking state where computing power can be opened.

[0026] Preferably, when extracting the current drive motor operating current value from the current powertrain status data, the current drive motor operating current value is obtained from the drive current sampling record corresponding to the traction drive branch, without including the cabin low-voltage power supply state, the on-board computing platform standby power supply state, or the computing power sharing communication node sleep-maintaining power supply state in the current drive motor operating current value. The traction drive branch is used to characterize the energy output branch corresponding to the drive motor outputting driving power. The drive current sampling record originates from the traction drive branch. The cabin low-voltage power supply state, the on-board computing platform standby power supply state, and the computing power sharing communication node sleep-maintaining power supply state all belong to non-traction drive branch power supply states, and the non-traction drive branch power supply states are not used as the source of the current drive motor operating current value. Through the above source definition, the current drive motor operating current value is used to characterize whether the drive motor is still in a state of outputting traction power or maintaining driving power preparation, rather than characterizing whether the vehicle as a whole is completely powered off. After zero-point reference correction is performed on the drive current sampling record, the current operating current value of the drive motor corresponding to the traction drive branch is obtained. The zero-point reference correction is used to filter out the static offset in the drive current sampling record, so that the current driving motor operating current value can be used to determine whether the vehicle drive state has exited the driving power output. When the current driving motor operating current value is equal to zero, a zero drive current determination record is generated. The zero drive current determination record continues to participate in the determination of the parking computing power opening condition together with the continuous zeroing determination record. By having the zero drive current determination record and the continuous zeroing determination record participate in the determination together, it is possible to avoid erroneous activation of the computing power sharing communication node only when the vehicle stops briefly but the drive motor is still in the driving power preparation state.

[0027] Preferably, when extracting the current gear mechanical lock-up status bit from the current chassis parking status data, the gear lock-up code fed back by the vehicle gear actuator is first read from the vehicle control bus used to transmit the current chassis parking status data, and then the gear lock-up code is converted into the current gear mechanical lock-up status bit. The gear lock-up code is used to characterize the feedback state of the mechanical lock-up component corresponding to the parking gear. The current gear mechanical lock-up status bit is obtained by converting the gear lock-up code and is used to characterize whether the mechanical lock-up component corresponding to the parking gear has entered the locked state. When the current gear mechanical lock-up status bit is in the locked state, a mechanical lock-up determination record is generated. The mechanical lock-up determination record is used to indicate that a vehicle drive-side parking holding constraint has been formed on the vehicle drive side. The vehicle drive-side parking holding constraint originates from the mechanical lock-up component corresponding to the parking gear entering the locked state. The vehicle drive-side parking holding constraint continues to participate in the determination of the vehicle chassis parking holding state together with the subsequent brake-side parking holding constraint. When extracting the current electronic parking caliper lock flag from the current chassis parking status data, the caliper holding code fed back by the electronic parking actuator is first read, and then the caliper holding code is converted into the current electronic parking caliper lock flag. The caliper holding code is used to characterize the feedback status of the electronic parking caliper, and the current electronic parking caliper lock flag is obtained from the caliper holding code and is used to characterize whether the electronic parking caliper has entered the lock holding state. When the current electronic parking caliper lock flag is in the set state, a caliper lock determination record is generated. The caliper lock determination record is used to indicate that the brake-side parking holding constraint has been formed. The caliper lock determination record and the mechanical lock determination record are used together to indicate that the vehicle chassis parking holding state has been established, and the vehicle chassis parking holding state continues to participate in the determination of the parking computing power opening condition.

[0028] Preferably, when using the extracted current wheel speed sensor pulse count value, current drive motor operating current value, current gear mechanical lock status bit, and current electronic parking caliper lock flag bit as the logical basis for determining the parking computing power opening condition, the continuous zeroing determination record, the zero drive current determination record, the mechanical lock determination record, and the caliper lock determination record are first written into the parking computing power opening determination record. The parking computing power opening determination record stores each determination record in the order of vehicle movement state, vehicle drive state, vehicle gear lock status, and vehicle brake holding state, so that the continuous zeroing determination record can correspond to the vehicle movement state, the zero drive current determination record can correspond to the vehicle drive state, the mechanical lock determination record can correspond to the vehicle gear lock status, and the caliper lock determination record can correspond to the vehicle brake holding state. Before proceeding to the next stage of the parking computing power access determination record, the pre-configured computing power contribution mode enable flag in the vehicle interface is read. The initial state of the computing power contribution mode enable flag is off. This flag is pre-configured through the computing power contribution mode configuration item in the vehicle interface and serves as the basis for the local configuration state of the parking computing power access determination record. Only when the computing power contribution mode enable flag is in the enabled state does the parking computing power access determination record proceed to the item-by-item determination of the parking computing power access conditions. Thus, the activation of the computing power sharing communication node depends not only on the underlying vehicle state but also on the local configuration state corresponding to the computing power contribution mode enable flag, ensuring that the node wake-up process only continues after the vehicle's parking state and the computing power access intention are simultaneously established at the data level.

[0029] Preferably, if the current wheel speed sensor pulse count is zero, the current drive motor operating current is zero, the current gear mechanical lock status is locked, the current electronic parking caliper lock flag is set, and the computing power contribution mode enable flag is enabled, then a parking computing power open confirmation record is generated based on the parking computing power open determination record. The parking computing power open confirmation record retains the correspondence between the continuous zeroing determination record, the zero drive current determination record, the mechanical lock determination record, and the caliper lock determination record, indicating that the parking computing power open condition is jointly satisfied by the vehicle's motion state, the vehicle's drive state, the vehicle's gear lock status, and the vehicle's brake holding state. If any one of the continuous zeroing determination record, the zero drive current determination record, the mechanical lock determination record, the caliper lock determination record, or the computing power contribution mode enable flag does not meet the corresponding condition, then a parking computing power open rejection record is generated based on the parking computing power open determination record, and the computing power sharing communication node remains in a dormant state. The parking computing power open rejection record continues to retain the continuous zeroing judgment record, the zero drive current judgment record, the mechanical lock judgment record, the caliper lock judgment record, or the computing power contribution mode enable flag bit that did not meet the conditions, so that when the parking judgment sampling window is entered again, the underlying vehicle status and the computing power contribution mode enable flag bit can be read again, instead of using the judgment result of the previous round that did not meet the conditions.

[0030] Preferably, when generating a node wake-up interrupt signal, the parking computing power opening confirmation record is used as the basis for signal generation, and the determination source in the parking computing power opening confirmation record is written into the node wake-up reason field. The node wake-up reason field is used to record the source information that the continuous zeroing determination record, the zero drive current determination record, the mechanical locking determination record, the caliper lock determination record, and the computing power contribution mode enable flag bit jointly satisfy the parking computing power opening conditions. The node wake-up interrupt signal also includes a computing power sharing communication node identifier field and a working voltage request field; the computing power sharing communication node identifier field is used to indicate the computing power sharing communication node that needs to switch from the dormant state to the working state, and the working voltage request field is used to instruct the vehicle power management node to provide working voltage to the computing power sharing communication node. The node wake-up reason field, the computing power sharing communication node identifier field, and the working voltage request field together constitute the data content of the node wake-up interrupt signal, so that the node wake-up interrupt signal can characterize both why the computing power sharing communication node needs to be woken up, and which computing power sharing communication node needs to be woken up and what power supply state is provided to that computing power sharing communication node. After the node wake-up interrupt signal is generated, the node wake-up reason field continues to serve as the source verification basis for subsequent power supply switching, the computing power sharing communication node identifier field continues to serve as the target location basis for subsequent power supply switching, and the working voltage request field continues to serve as the power supply status basis for subsequent power supply switching.

[0031] Preferably, when providing operating voltage to the computing power sharing communication node in a dormant state according to the node wake-up interrupt signal, the vehicle power management node first parses the computing power sharing communication node identifier field in the node wake-up interrupt signal to identify the computing power sharing communication node in a dormant state. Subsequently, the vehicle power management node parses the operating voltage request field in the node wake-up interrupt signal and switches the dormant holding voltage of the computing power sharing communication node to the communication operating voltage. The dormant holding voltage is used to maintain the computing power sharing communication node in a low-power, wait-to-wake state, and the communication operating voltage is used to enable the computing power sharing communication node to enter a working state capable of performing radio frequency communication initialization. After the communication operating voltage is established, the vehicle power management node generates an operating voltage establishment status record, which is written back to the parking computing power open confirmation record, so that the parking computing power open confirmation record is further extended from the vehicle status determination result to the node power supply status determination result. The node power supply status determination result is used to indicate that the computing power sharing communication node has completed the switch from the dormant holding voltage to the communication operating voltage according to the node wake-up interrupt signal. Through the above processing, the computing power sharing communication node does not remain in full-function working state continuously after the vehicle is powered on, but only enters working state from dormant state after the parking computing power opening condition is met, thereby reducing invalid radio frequency broadcasts and invalid external access attempts in non-parking scenarios.

[0032] Preferably, after obtaining the communication operating voltage, the computing power sharing communication node first reads the operating voltage establishment status record and loads radio frequency (RF) communication initialization parameters according to the operating voltage establishment status record. The RF communication initialization parameters include a local broadcast identifier, a near-field discovery method, and a secure session entry point. The local broadcast identifier enables external devices to discover the computing power sharing communication node; the near-field discovery method limits the initial handshake message exchange between the external device and the computing power sharing communication node to a short-range communication method; and the secure session entry point is used to subsequently receive the external device's identity credential sequence. The RF communication initialization parameters are loaded by the computing power sharing communication node after the communication operating voltage is established, ensuring that the local broadcast identifier, the near-field discovery method, and the secure session entry point are all based on the node power supply status determination result represented by the operating voltage establishment status record. After loading the RF communication initialization parameters, the computing power sharing communication node generates a node operating status record, which represents that the computing power sharing communication node has switched from a dormant state to an operating state capable of receiving initial handshake messages. The node's working status record continues to participate in the subsequent identity credential sequence reception process, so that the determination process of the target access device is based on the completion of the parking status determination and node power supply switching; the determination process of the target access device also continues to use the identity credential sequence received by the secure session entry, so that the target access device originates from the computing power sharing communication node that has completed the node working status confirmation.

[0033] Preferably, in one scenario, when the vehicle is parked in a fixed parking space and the vehicle's driving power is turned off, the fixed parking space only indicates that the vehicle is in a parking usage scenario, and the fact that the vehicle's driving power is turned off indicates that the vehicle's driving state is no longer in a driving power output state. The parking determination sampling window first continuously reads the pulse count value of the current wheel speed sensor to form the continuous zeroing determination record; then it reads the current drive motor operating current value for the traction drive branch to form the zero drive current determination record; subsequently, it reads the current gear mechanical lock status bit and the current electronic parking caliper lock flag bit to form the mechanical lock determination record and the caliper lock determination record, respectively. The continuous zeroing determination record, the zero drive current determination record, the mechanical lock determination record, and the caliper lock determination record are jointly written into the parking computing power open determination record. When the computing power contribution mode enable flag bit is in the allowed state, the parking computing power open determination record is further converted into the parking computing power open confirmation record. The parking computing power access confirmation record triggers the generation of the node wake-up interrupt signal. This signal causes the vehicle power management node to provide the communication operating voltage to the computing power sharing communication node in its dormant state. Once the communication operating voltage is established, the computing power sharing communication node enters a working state capable of receiving external device identity credential sequences. This process ensures that the process of opening up idle computing power in a parked vehicle begins with a determination of the vehicle's underlying state and gradually transitions to the activation of the computing power sharing communication node. This avoids opening external computing power access before the vehicle has completed its parking hold state or before the vehicle's driving state has ceased outputting driving power.

[0034] Optionally, the step of establishing the first physical isolation domain and the second physical isolation domain within the vehicle-mounted computing platform includes: Collect the current remaining power battery charge value of the vehicle, and calculate the total upper limit of available resources based on the current remaining power battery charge value; Read the pre-burned system base configuration file and extract the factory-set basic driving core retention count from it; The total number of available physical cores of the vehicle computing platform is subtracted from the number of basic driving reserved cores to obtain the total number of remaining idle cores, and the total number of remaining idle cores is used as a reference benchmark for resource allocation. If the total limit of available resources is less than the total number of remaining idle cores, the total limit of available resources will be set as the target number of open computing cores. If the total upper limit of the available resources is not less than the total number of remaining idle cores, the total number of remaining idle cores is set as the target number of open computing cores; The first processor hardware region is allocated according to the number of basic driving cores, and the first physical isolation domain is constructed using the first processor hardware region. The second processor hardware space is allocated according to the target number of open computing cores, and the second physical isolation domain is constructed using the second processor hardware space to complete the establishment of the first physical isolation domain and the second physical isolation domain within the vehicle computing platform.

[0035] Preferably, the specific implementation process of establishing the first physical isolation domain and the second physical isolation domain within the vehicle computing platform is as follows: After the computing power sharing communication node is activated, the resource topology record of the vehicle computing platform is first read, and the physical core number, physical core operating status, and computing unit type of the physical core that can participate in the isolation domain division are marked in the resource topology record. The resource topology record originates from the hardware enumeration result formed during the startup phase of the vehicle computing platform. The hardware enumeration result is used to indicate whether each physical core in the vehicle computing platform is in a schedulable state, and a physical core exclusion status record is formed based on the hardware enumeration result. The physical core exclusion status record is used to mark physical cores in a fault-masking, temperature-limited, or low-level driver-occupied state. The resource topology record excludes the aforementioned physical cores from the open range of the second physical isolation domain based on the physical core exclusion status record. Through the resource topology record, the vehicle computing platform can first obtain the underlying source of the total number of available physical cores, and then enter the construction process of the first physical isolation domain and the second physical isolation domain, so that the first physical isolation domain and the second physical isolation domain are not divided on the abstract computing power value, but on the physical core number that can be actually scheduled.

[0036] Preferably, when collecting the current remaining battery power value of the vehicle, the current remaining battery power sample value is first read from the battery management record, and the current remaining battery power sample value is subjected to sampling stabilization processing to generate the current remaining battery power value. The battery management record is used to provide the remaining energy status of the vehicle that can continuously supply power to the on-board computing platform when the vehicle is parked. The sampling stabilization processing is used to eliminate battery power display jumps caused by short-term load fluctuations, so that the current remaining battery power value can be used as the input basis for subsequent calculation of the total upper limit of openable resources. The current remaining battery power value is not directly compared with the number of physical cores, but is first entered into a pre-configured power resource conversion record. The power resource conversion record is pre-written into the read-only configuration storage area of ​​the vehicle computing platform. The power resource conversion record includes a power range identifier and an upper limit of the number of open computing cores corresponding to the power range identifier. The power resource conversion record is used to map different power ranges to different upper limits of the number of open computing cores, so that the conversion between the power dimension and the physical core quantity dimension is completed through configuration mapping, avoiding the direct mixing and calculation of power value and core quantity.

[0037] Preferably, when calculating the total upper limit of available resources based on the current remaining power battery charge, the current remaining power battery charge is first input into the power resource conversion record to obtain the upper limit record of available cores corresponding to the power charge. This upper limit record expresses the upper limit of the number of computing cores allowed to be opened under the remaining power charge condition corresponding to the current power battery charge, and is further adjusted by combining it with the resource depreciation record. The resource depreciation record is formed from the vehicle computing platform temperature status record and the power battery health status record. The vehicle computing platform temperature status record is derived from the temperature sampling data of the vehicle computing platform and is used to describe the thermal state of the vehicle computing platform before the computing power is opened; the power battery health status record is derived from the power battery management record and is used to describe the power battery's energy supply capacity during the current usage phase. After applying the upper limit adjustment process to the upper limit record of available cores corresponding to the power charge and the resource depreciation record, the total upper limit of available resources is formed. The unit of the total upper limit of openable resources is the number of openable computing cores, which is used to limit the upper limit of the number of openable computing cores that the second physical isolation domain can obtain, rather than to change the retention range of the resources corresponding to the basic driving resource retention records in the first physical isolation domain.

[0038] Preferably, when reading the pre-burned system base configuration file, the system base configuration file is first obtained from the read-only configuration storage area of ​​the vehicle computing platform, and the integrity of the system base configuration file is verified to form a system base configuration read record. The system base configuration file is written to the read-only configuration storage area during the vehicle factory configuration stage. The system base configuration file includes the number of basic driving reserved cores, the basic driving reserved core numbering rules, and the isolation domain permission boundary configuration record. The number of basic driving reserved cores indicates the number of physical cores that still need to be fixedly reserved from the vehicle computing platform during the period when the idle computing power of the parked vehicle is open. The basic driving reserved core numbering rules indicate the physical core number selection method corresponding to the number of basic driving reserved cores. The isolation domain permission boundary configuration record restricts the resource access range between the first physical isolation domain and the second physical isolation domain. Through the system base configuration read record, the subsequent extraction of the number of basic driving reserved cores can be mapped to the factory configuration source in the system base configuration file, avoiding the temporary rewriting of the number of basic driving reserved cores during the computing power open session.

[0039] Preferably, when extracting the factory-set number of basic driving reserved cores from the system base configuration file, the number of basic driving reserved cores is located according to the system base configuration read record, and written into the basic driving resource reservation record. The basic driving resource reservation record is used to fixate the basic driving wake-up computing power required for the core driving functions of the vehicle in subsequent resource allocation, enabling the underlying hardware daemon process, the vehicle chassis signal monitoring task, and the chassis reset interrupt response task to run within the first physical isolation domain. The underlying hardware daemon process is used to continuously collect real-time vehicle chassis signals, the vehicle chassis signal monitoring task is used to monitor the real-time vehicle chassis signals, and the chassis reset interrupt response task is used to respond to interrupts when the real-time vehicle chassis signals trigger the chassis reset interrupt condition. The number of basic driving reserved cores is not dynamically changed according to the computing tasks of subsequent target access devices, but is formed by the factory setting in the system base configuration file; the basic driving resource reservation record continues to participate in the allocation of the first processor hardware area, ensuring that the number of physical cores in the first processor hardware area remains consistent with the number of basic driving reserved cores.

[0040] Preferably, when subtracting the number of basic driving-reserved cores from the total number of available physical cores of the onboard computing platform, the number of physical cores in a schedulable state is first counted based on the resource topology record to form the total number of available physical cores. Both the total number of available physical cores and the number of basic driving-reserved cores are measured in units of physical cores, thus allowing for deduction with the same unit of measurement. After subtracting the number of basic driving-reserved cores from the total number of available physical cores, the remaining number of idle cores is formed. This remaining number of idle cores represents the basic number of physical cores that the onboard computing platform can provide to the second physical isolation domain without occupying the resources corresponding to the basic driving resource reservation record. This remaining number of idle cores continues to serve as a reference benchmark for resource allocation in determining the subsequent target number of open computing cores, ensuring that the open range of the second physical isolation domain is limited to the actual idle range after deducting the number of basic driving-reserved cores.

[0041] Preferably, when determining the target number of open computing cores, the upper limit of the total number of openable resources is compared with the total number of remaining idle cores using the same dimensions. If the upper limit of the total number of openable resources is less than the total number of remaining idle cores, it indicates that the upper limit of the total number of openable resources, as defined by the current remaining power battery charge, the temperature status record of the vehicle computing platform, and the health status record of the power battery, is lower than the total number of remaining idle cores. In this case, the upper limit of the total number of openable resources is set as the target number of open computing cores. If the upper limit of the total number of openable resources is not less than the total number of remaining idle cores, it indicates that the total number of remaining idle cores is lower than or equal to the upper limit of the total number of openable resources. In this case, the total number of remaining idle cores is set as the target number of open computing cores. The target number of open computing cores is formed by the smaller value between the upper limit of the total number of openable resources and the total number of remaining idle cores. This number does not exceed the power supply and thermal status limitations corresponding to the upper limit of the total number of openable resources, nor does it consume the basic driving wake-up computing power required for the core driving functions of the vehicle corresponding to the number of basic driving reserved cores.

[0042] Preferably, after determining the target number of open computing cores, a first processor hardware region is allocated according to the number of basic driving reserved cores. When allocating the first processor hardware region, a physical core number corresponding to the number of basic driving reserved cores is first selected from the resource topology record according to the basic driving reserved core numbering rules, and then the selected physical core number is written into the first processor hardware region allocation record. The first processor hardware region allocation record is used to characterize the range of physical core numbers, the running permissions of the underlying hardware daemon process, and the chassis reset interrupt response permissions of the first processor hardware region. After the first processor hardware region allocation record is formed, the first physical isolation domain is constructed using the first processor hardware region, enabling the first physical isolation domain to carry the underlying hardware daemon process and allowing the underlying hardware daemon process to continuously collect the real-time vehicle chassis signals. Since the first physical isolation domain is constructed based on the number of basic driving reserved cores, the pending computing instruction data executed subsequently in the second physical isolation domain will not occupy the physical core number corresponding to the first processor hardware region.

[0043] Preferably, when allocating the second processor hardware region according to the target number of open computing cores, the physical core numbers already written into the first processor hardware region allocation record are first excluded from the resource topology record. Then, physical core numbers corresponding to the target number of open computing cores are selected from the remaining schedulable physical core numbers to form the second processor hardware region allocation record. The second processor hardware region allocation record is used to characterize the range of physical core numbers, the execution permission of the pending computing instruction data, and the volatile cache usage permission of the second processor hardware region. The execution permission of the pending computing instruction data is used to limit the pending computing instruction data subsequently issued by the target access device to only run in the second physical isolation domain. The volatile cache usage permission is used to limit the pending computing instruction data subsequently issued by the target access device to only use the temporary cache area allocated during task execution when running in the second physical isolation domain. The temporary cache area is cleared after the task ends. Through the second processor hardware region allocation record, the resource source of the second physical isolation domain can be mapped to the target number of open computing cores, and a distinction is formed at the physical core number level between it and the first processor hardware region.

[0044] Preferably, when constructing the second physical isolation domain using the second processor hardware interval, the allocation record of the second processor hardware interval is written into the isolation domain resource scheduling table, and the types of computing units that can be called by the second physical isolation domain are marked in the isolation domain resource scheduling table. The computing unit types include general-purpose computing cores corresponding to general-purpose processors, rendering acceleration resources corresponding to graphics accelerators, and inference computing resources corresponding to tensor processing units; the isolation domain resource scheduling table establishes a correspondence between the general-purpose computing cores corresponding to general-purpose processors, the rendering acceleration resources corresponding to graphics accelerators, and the inference computing resources corresponding to tensor processing units and the physical core numbers within the second processor hardware interval, so that the subsequent available computing power resource status list can read the actual openable resources from the second physical isolation domain. The actual openable resources include the number of available threads of the general-purpose processor related to the general-purpose computing cores corresponding to the general-purpose processors, the number of available rendering pipelines of the graphics accelerators related to the rendering acceleration resources corresponding to the graphics accelerators, and the number of available multiplies and accumulators of the tensor processing units related to the inference computing resources corresponding to the tensor processing units. The isolation domain resource scheduling table also retains the target number of open computing cores, so that the computing instruction data to be processed issued by the target access device can only be scheduled within the range limited by the target number of open computing cores, and cannot access the first processor hardware area by bypassing the second processor hardware area.

[0045] Preferably, when constructing the first physical isolation domain and the second physical isolation domain, a first physical isolation domain access boundary record and a second physical isolation domain access boundary record are also established based on the isolation domain permission boundary configuration record. The first physical isolation domain access boundary record is used to limit the first physical isolation domain to access real-time vehicle chassis signals, underlying hardware daemon process running data, and chassis reset interrupt response data; the second physical isolation domain access boundary record is used to limit the second physical isolation domain to access the pending calculation instruction data issued by the target access device, the operation cache output data block formed during task execution, and the target operation result data segment used for return transmission. The second physical isolation domain access boundary record does not include vehicle raw data access permissions, which include driving record data access permissions, driving behavior data access permissions, and map data access permissions. The driving record data access permissions, driving behavior data access permissions, and map data access permissions are not written into the second physical isolation domain access boundary record, so that when the pending calculation instruction data performs logical operations in the second physical isolation domain, it cannot access the vehicle raw data through the second physical isolation domain. The first physical isolation domain access boundary record and the second physical isolation domain access boundary record are jointly written into the isolation domain resource scheduling table to complete the access boundary configuration between the first physical isolation domain and the second physical isolation domain.

[0046] Preferably, after the first and second physical isolation domains are established, the vehicle-mounted computing platform generates an isolation domain establishment status record. The isolation domain establishment status record includes the first processor hardware interval allocation record, the second processor hardware interval allocation record, the basic driving resource reservation record, the target number of open computing cores, the first physical isolation domain access boundary record, the second physical isolation domain access boundary record, and the isolation domain resource scheduling table. The isolation domain establishment status record continues to participate in the subsequent generation process of the available computing power resource status list: when traversing the currently unoccupied computing hardware clusters mounted within the second physical isolation domain, the second processor hardware interval allocation record and the isolation domain resource scheduling table in the isolation domain establishment status record are read first. Then, based on the second processor hardware interval allocation record and the isolation domain resource scheduling table, the computing resources within the second physical isolation domain that can be opened to the target access device are counted to form a statistical record of currently unoccupied computing hardware clusters. The statistical record of currently unoccupied computing hardware clusters continues to participate in the generation process of the available computing power resource status list, ensuring that the available computing power resource status list is consistent with the actual hardware intervals of the second physical isolation domain, rather than being a general declaration based on all the hardware resources of the vehicle-mounted computing platform.

[0047] Preferably, in one scenario, when the vehicle enters a parked state and the computing power sharing communication node has been activated, the vehicle computing platform first uses the power battery management record to determine the current remaining power battery charge value, and uses the power resource conversion record and the resource deduction record to determine the total upper limit value of openable resources. Subsequently, the vehicle computing platform extracts the number of basic driving reserved cores from the system base configuration file and calculates the total number of available physical cores based on the resource topology record. The total number of available physical cores minus the number of basic driving reserved cores results in the total number of remaining idle cores. This remaining idle core number is then compared with the total upper limit value of openable resources to determine the target number of open computing cores. Next, the number of basic driving reserved cores is written into the first processor hardware interval allocation record, and the target number of open computing cores is written into the second processor hardware interval allocation record. The first processor hardware interval allocation record is used to construct the first physical isolation domain, and the second processor hardware interval allocation record is used to construct the second physical isolation domain. The above processing enables a traceable allocation relationship at the physical core number level for the basic driving wake-up computing power required for the vehicle's core driving functions corresponding to the number of basic driving cores retained, the parking open computing power corresponding to the number of target open computing cores, and the computing resources subsequently used by the target access device. This allows the first physical isolation domain and the second physical isolation domain to respectively undertake real-time vehicle chassis signal monitoring and pending computing instruction data processing when the idle computing power of the parked vehicle is opened to personal devices.

[0048] Optionally, the step of receiving the identity credential sequence of an external device through the computing power sharing communication node and verifying the identity credential sequence to determine the target access device includes: The computing power sharing communication node receives the initial handshake message broadcast by the external device and extracts the device's physical hardware address and the identity credential sequence from it. The system calls the pre-stored authorized binding whitelist record table in the vehicle security encryption chip, using the device's physical hardware address and the identity credential sequence as the query index; Check the authorized binding whitelist record table to see if there is a matching record entry; If a matching record is found, the identity credential sequence is verified and a secure socket connection is established with the external device through the computing power sharing communication node. The external device that successfully establishes the secure socket connection is marked as the target access device to identify the target access device.

[0049] Preferably, the specific implementation process of receiving the identity credential sequence of the external device through the computing power sharing communication node and verifying the identity credential sequence to determine the target access device is as follows: After the computing power sharing communication node enters the working state that can receive the initial handshake message, the node working state record of the computing power sharing communication node is first read, and the near-field discovery channel is opened according to the node working state record. The near-field discovery channel includes a Bluetooth Low Energy Broadcast channel, a Wi-Fi Point-to-Point Discovery channel, and a Vehicle High-Speed ​​Physical Interface Access Channel; the Bluetooth Low Energy Broadcast channel is used to receive the initial handshake message sent by the external device through the low-power broadcast method, the Wi-Fi Point-to-Point Discovery Channel is used to receive the initial handshake message sent by the external device through the point-to-point discovery method, and the Vehicle High-Speed ​​Physical Interface Access Channel is used to receive the initial handshake message when the external device accesses through the Vehicle High-Speed ​​Physical Interface Access Channel. After receiving the initial handshake message, the near-field discovery channel writes it into the handshake message buffer. The handshake message buffer continues to provide the initial handshake message to subsequent message parsing processes, ensuring that the discovery process of the external device is based on the fact that the computing power sharing communication node has completed the parking status determination, node power supply switching, and node working status confirmation. The node working status record, the near-field discovery channel, the handshake message buffer, and the initial handshake message form a sequential access processing relationship. Subsequent verification of the identity credential sequence does not begin directly from uncontrolled external broadcasts, but rather after the computing power sharing communication node confirms that it can receive the initial handshake message.

[0050] Preferably, when parsing the initial handshake message, the initial handshake message format of the initial handshake message in the handshake message buffer is first checked to form an initial handshake message format check record. The initial handshake message format check is used to determine whether the initial handshake message contains a device physical hardware address field, an identity credential sequence field, an access link source field, and a message timestamp field; the initial handshake message format check record is used to record the check results of whether the device physical hardware address field, the identity credential sequence field, the access link source field, and the message timestamp field exist. The device physical hardware address field carries the device physical hardware address, the identity credential sequence field carries the identity credential sequence, the access link source field indicates that the initial handshake message originates from the Bluetooth Low Energy Broadcast channel, the Wi-Fi point-to-point discovery channel, or the vehicle high-speed physical interface access channel, and the message timestamp field limits the temporal position of the initial handshake message in the current access session. The device physical hardware address and the identity credential sequence are extracted from the initial handshake message only if the initial handshake message format verification record indicates that the device physical hardware address field, the identity credential sequence field, the access link source field, and the message timestamp field all exist. If any field indicated by the initial handshake message format verification record does not exist, the initial handshake message is retained as an invalid handshake message record, and the invalid handshake message record prevents the initial handshake message from entering the subsequent whitelist query process.

[0051] Preferably, when extracting the device physical hardware address and the identity credential sequence from the initial handshake message, the device physical hardware address field and the identity credential sequence field are first located according to the initial handshake message format verification record. Then, the device physical hardware address in the device physical hardware address field and the identity credential sequence in the identity credential sequence field are read respectively to generate an initial handshake parsing record. The device physical hardware address is used to represent the hardware layer identifier of the external device, and the identity credential sequence is used to represent the access credential content formed by the external device in the pre-authorization binding phase. The device physical hardware address and the identity credential sequence are jointly written into the initial handshake parsing record. The initial handshake parsing record also retains the access link source field and the message timestamp field, so that the subsequent verification process can not only identify the external device that initiated the access, but also identify which near-field discovery channel the external device used to initiate access and the temporal position of the initial handshake message in the current access session. The initial handshake parsing record continues to serve as the data source for subsequent whitelist query requests, ensuring that the device physical hardware address, the identity credential sequence, the access link source field, and the message timestamp field do not deviate from the source relationship of the initial handshake message during subsequent queries.

[0052] Preferably, the authorized binding whitelist record table is pre-stored in the vehicle-mounted security encryption chip, and the authorized binding whitelist record table is formed during the vehicle local binding stage. During the vehicle local binding stage, the authorized device physical hardware address field, authorized identity credential digest field, first access confirmation status field, and session permission field are written through the vehicle-mounted local binding entry point. The vehicle-mounted local binding entry point is used to receive the binding request from the external device locally in the vehicle and write the information corresponding to the bound external device into the authorized binding whitelist record table. The authorized device physical hardware address field is used to record the hardware layer identifier of the bound external device; the authorized identity credential digest field is used to record the credential digest content corresponding to the bound external device; the first access confirmation status field is used to record the access confirmation status written back by the vehicle-mounted screen confirmation control; and the session permission field is used to record the scope of computing power access permissions allowed for the bound external device. The vehicle-mounted screen confirmation control is used to receive the access confirmation status during the first access confirmation process, and the access confirmation status is written back to the first access confirmation status field through the vehicle-mounted screen confirmation control. The authorized device physical hardware address field, the authorized identity credential summary field, the first access confirmation status field, and the session permission field together constitute the record entries in the authorized binding whitelist record table, enabling the authorized binding whitelist record table to simultaneously constrain the device source, credential source, first access confirmation status, and session permission range.

[0053] Preferably, when invoking the pre-stored authorized binding whitelist record table in the vehicle-mounted security encryption chip, a whitelist query request is first generated based on the initial handshake parsing record, and then sent to the vehicle-mounted security encryption chip. The whitelist query request includes the device's physical hardware address, the identity credential sequence, the access link source field, and the message timestamp field. After receiving the whitelist query request, the vehicle-mounted security encryption chip performs credential digest processing on the identity credential sequence to form a credential digest to be queried. The credential digest to be queried originates from the identity credential sequence and is used to compare with the authorized identity credential digest field in the authorized binding whitelist record table; the device's physical hardware address is used to compare with the authorized device physical hardware address field in the authorized binding whitelist record table. By writing the device's physical hardware address, the identity credential sequence, the access link source field, and the message timestamp field into the whitelist query request, the subsequent query index can simultaneously include the hardware layer identifier, credential layer identifier, access channel source, and access timing source, instead of relying solely on a single broadcast identifier to complete the access judgment. The whitelist query request continues to participate in the subsequent query index generation process, and the identity credential summary to be queried continues to participate in the subsequent identity credential summary query item generation process.

[0054] Preferably, when using the device physical hardware address and the identity credential sequence as a query index, the device physical hardware address is first converted into a device physical hardware address query item, and the identity credential summary to be queried is converted into an identity credential summary query item. Then, the device physical hardware address query item and the identity credential summary query item together form the query index. The device physical hardware address query item is used to locate record entries in the authorized binding whitelist record table that have the same hardware layer identifier. The identity credential summary query item is used to continue comparing the credential summary content among the already located record entries. The query index also reads the access link source field to form an access link source query item; the access link source query item is used to determine whether the near-field discovery channel currently used by the external device falls within the access channel range allowed by the session permission field. Through the above query index construction method, the query of the authorized binding whitelist record table is not simply a matter of determining whether the device physical hardware address exists, but rather simultaneously determining whether the device physical hardware address query item, the identity credential summary query item, and the access link source query item all meet the constraints of the corresponding record entry. The query index continues to participate in the retrieval process of subsequent candidate record entries, so that the device physical hardware address, the identity credential summary corresponding to the identity credential sequence, and the access link source field all have a clear subsequent participation relationship.

[0055] Preferably, when querying the authorized binding whitelist record table for a matching record entry, the authorized device physical hardware address field is first retrieved using the device physical hardware address query item to obtain candidate record entries. These candidate record entries represent record entries in the authorized binding whitelist record table that have a hardware-level matching relationship with the device physical hardware address. If no candidate record entry is found, a whitelist query failure record is generated, and an access rejection message is returned to the external device through the computing power sharing communication node. The whitelist query failure record records the query result where the device physical hardware address query item fails to match the authorized device physical hardware address field, and the access rejection message is used to report the access rejection status corresponding to the whitelist query failure record to the external device. If a candidate record entry is found, the authorized identity credential digest field in the candidate record entry is compared using the identity credential digest query item, and the session permission field in the candidate record entry is compared using the access link source query item. A candidate record entry is confirmed as a matched record entry only when the authorized identity credential digest field in the candidate record entry matches the identity credential digest query item, and the access link source query item falls within the access channel range allowed by the session permission field. The matched record entry continues to participate in the subsequent initial access confirmation status field reading process, ensuring that the matched record entry not only serves as the whitelist hit result but also as the basis for status verification before the establishment of a secure socket connection.

[0056] Preferably, if a matching record exists, the initial access confirmation status field in the matching record also needs to be read. If the initial access confirmation status field is not in a completed state, the vehicle computing platform displays an external device access confirmation interface through the vehicle screen confirmation control, and writes back the confirmation result corresponding to the external device access confirmation interface as an initial access confirmation status write-back record. The external device access confirmation interface is used to display the device's physical hardware address, the access link source field, and the session permission field, enabling the vehicle screen confirmation control to receive the confirmation result based on the external device access confirmation interface. The initial access confirmation status write-back record originates from the confirmation result and continues to write the initial access confirmation status field in the matching record; only when the initial access confirmation status field is in a completed state is the matching record confirmed to meet the subsequent identity credential sequence verification conditions. By involving the initial access confirmation status field in the validity judgment of the matching record, the number of near-field access requests that have not undergone the vehicle's local confirmation process entering the subsequent secure socket connection establishment process can be reduced. The identity credential sequence verification conditions continue to participate in the subsequent identity credential verification pass record generation process, so that the status result of the first access confirmation status field will not remain at the interface confirmation stage.

[0057] Preferably, upon confirmation that the identity credential sequence verification passes, the vehicle-mounted security encryption chip generates an identity credential verification pass record based on the matching record entry. The identity credential verification pass record includes the device's physical hardware address, the summary of the identity credential to be queried, the access link source field, the session permission field, and the first access confirmation status field. The identity credential verification pass record indicates that the external device satisfies the corresponding constraints in the authorized binding whitelist record table in terms of hardware layer identifier, credential layer identifier, access channel range, and first access confirmation status. The identity credential verification pass record also retains the correspondence between the matching record entry and the query index, enabling the subsequent secure socket connection establishment process to trace the verification source of the device's physical hardware address, the identity credential sequence, and the access link source field. The identity credential verification pass record continues to participate in the secure socket connection establishment process, ensuring that the secure socket connection is not established simply after discovering the external device, but after multi-field verification is completed in the authorized binding whitelist record table.

[0058] Preferably, when establishing a secure socket connection with the external device through the computing power sharing communication node, the vehicle-mounted security encryption chip first generates a session establishment request based on the identity credential verification record, and sends the session establishment request to the external device through the computing power sharing communication node. The session establishment request includes session random data, a session permission field, and a connection validity timing field; the session random data is used to distinguish the current access session from historical access sessions in terms of encrypted input; the session permission field is derived from the matched record entry and is used to limit the scope of computing power that the external device can subsequently request; and the connection validity timing field is used to limit the valid access timing corresponding to the secure socket connection. After the external device returns a session response message based on the session establishment request, the computing power sharing communication node sends the session response message to the vehicle-mounted security encryption chip for session response verification. The session response verification is used to determine whether the session response message corresponds to the identity credential verification record, the session random data, the session permission field, and the connection validity timing field, so that the establishment process of the secure socket connection is continuously connected with the identity credential verification record, the session permission field, and the connection validity timing field.

[0059] Preferably, when the vehicle-mounted security encryption chip performs session response verification on the session response message, it generates an end-to-end communication symmetric key based on the identity credential verification success record, the session random data, and the session response message. The end-to-end communication symmetric key is formed internally within the vehicle-mounted security encryption chip and is used to subsequently encrypt and encapsulate data transmitted through the secure socket connection. The end-to-end communication symmetric key is not written to the vehicle-mounted security encryption chip in plaintext; instead, the vehicle-mounted security encryption chip encrypts and encapsulates the data to be sent before handing it over to the computing power sharing communication node for transmission. After the session response verification passes, the vehicle-mounted security encryption chip generates a secure socket connection establishment record. This record includes the device's physical hardware address, the identity credential verification success record, the key index corresponding to the end-to-end communication symmetric key, and the connection validity timing field. The key index is used to internally call the end-to-end communication symmetric key within the vehicle-mounted security encryption chip and serves as the internal calling basis for the end-to-end communication symmetric key during subsequent transmission of the target computation result data segment. The secure socket connection establishment record continues to participate in the subsequent target access device marking process, so that the external device only enters the target access device determination process after the secure socket connection establishment record is formed.

[0060] Preferably, when marking the external device that has successfully established the secure socket connection as the target access device, the secure socket connection establishment record is first read, and a target access device marking record is generated based on the device's physical hardware address in the secure socket connection establishment record. The target access device marking record includes the device's physical hardware address, the secure socket connection establishment record, the session permission field, and the connection validity timing field; the target access device marking record is used to identify the same access object during subsequent sending of the available computing power resource status list, receiving pending computing instruction data, and returning the target operation result data segment. After the external device is written into the target access device marking record, it is identified as the target access device; when subsequently sending the available computing power resource status list to the target access device, the session permission field in the target access device marking record is first read, and then the resource range that can be declared to the target access device in the available computing power resource status list is determined based on the session permission field. The target access device marking record also retains the connection validity timing field, so that when receiving the pending calculation instruction data issued by the target access device, it can determine whether the current access session is still within the valid access timing based on the connection validity timing field.

[0061] Preferably, in a scenario where multiple external devices simultaneously broadcast the initial handshake message, the computing power sharing communication node sequentially writes each initial handshake message into the handshake message buffer according to the message timestamp field, and forms an initial handshake parsing record corresponding to each external device. Each initial handshake parsing record independently generates a whitelist query request, each whitelist query request independently forms a query index, and each query index independently queries the corresponding matching record entry in the authorized binding whitelist record table. Only external devices with matching record entries and whose first access confirmation status field is in a completed state enter the secure socket connection establishment process; external devices that have not formed a secure socket connection establishment record will not be written into the target access device mark record. Through the above-described parsing and verification process, the access requests of multiple external devices can complete identity credential sequence verification and target access device determination under the same computing power sharing communication node, without mismatch between the identity credential sequence, the device physical hardware address, and the session permission field due to the simultaneous occurrence of multiple initial handshake messages.

[0062] Optionally, the step of sending the available computing power resource status list to the target access device includes: Traverse the currently unoccupied computing hardware clusters mounted within the second physical isolation domain; The statistics include the number of available threads of general-purpose processors, the number of available rendering pipelines of graphics accelerators, and the number of available multiply-accumulators of tensor processing units within the currently unused computing hardware clusters. The statistically obtained values ​​are encapsulated into a hardware resource status structure, and the hardware resource status structure is set as the available computing power resource status list. The available computing power resource status list is transmitted to the target access device through the computing power sharing communication node, so as to send the available computing power resource status list to the target access device.

[0063] Preferably, the specific implementation process of sending the available computing power resource status list to the target access device is as follows: After the target access device has been determined through the secure socket connection establishment record, the target access device marking record is read first, and the session permission field and the connection validity timing field are extracted from the target access device marking record. The secure socket connection establishment record is used to characterize that the target access device has completed the identity credential sequence verification and secure socket connection establishment process. The target access device marking record is derived from the secure socket connection establishment record and is used to identify the same target access device in the subsequent process of sending the available computing power resource status list, receiving pending computing instruction data, and returning the target operation result data segment. The session permission field is used to limit the open range of computing power that the target access device can receive in the current access session, and the connection validity timing field is used to limit the valid timing of the target access device being able to receive the available computing power resource status list in the current access session. Subsequently, the isolation domain establishment status record is read, and the second processor hardware interval allocation record, the second physical isolation domain access boundary record, and the isolation domain resource scheduling table are extracted from the isolation domain establishment status record. The second processor hardware range allocation record is used to provide the range of physical core numbers corresponding to the second physical isolation domain. The second physical isolation domain access boundary record is used to limit the pending computation instruction data and temporary cache areas that the second physical isolation domain can access. The isolation domain resource scheduling table is used to provide the correspondence between the computing unit types and physical core numbers within the second physical isolation domain. Through the above reading process, the starting point for generating the available computing power resource status list is limited to the technical state where identity credential sequence verification has been completed, secure socket connections have been established, and the second physical isolation domain has been constructed.

[0064] Preferably, when traversing the currently unoccupied computing hardware clusters mounted within the second physical isolation domain, the range of traversable physical core numbers corresponding to the second physical isolation domain is first determined based on the second processor hardware interval allocation record. Then, the computing hardware cluster occupancy status, computing hardware cluster mounting status, and computing hardware cluster computing unit type of each computing hardware cluster are read within the range of traversable physical core numbers according to the isolation domain resource scheduling table. The range of traversable physical core numbers is derived from the second processor hardware interval allocation record and serves as the basis for subsequent traversal of the number range of the computing hardware clusters. The computing hardware cluster is used to represent a combination of schedulable computing resources associated with the same computing unit type within the second physical isolation domain. The computing hardware cluster occupancy status is used to represent whether the computing hardware cluster has been occupied by running pending computing instruction data, and the computing hardware cluster mounting status is used to represent whether the computing hardware cluster has been configured within the second physical isolation domain. After filtering the occupancy and mounting states of the computing hardware clusters, the computing hardware clusters whose mounting state is "mounted" and whose occupancy state is "not occupied by pending computing instruction data" are retained to form the currently unoccupied computing hardware clusters. These currently unoccupied computing hardware clusters continue to participate in subsequent resource value statistics, ensuring that the subsequently calculated values ​​of available threads for general-purpose processors, available rendering pipelines for graphics accelerators, and available multiply-accumulators for tensor processing units all originate from the currently unoccupied computing hardware clusters that are actually accessible within the second physical isolation domain, rather than from all hardware resources of the in-vehicle computing platform.

[0065] Preferably, before statistically analyzing the currently unoccupied computing hardware clusters, the total upper limit of available resources and the target number of available computing cores are read, and the upper limit of available computing hardware clusters is filtered based on the target number of available computing cores. The total upper limit of available resources is derived from the upper limit correction result formed by the current remaining power battery charge, the temperature status record of the vehicle computing platform, and the health status record of the power battery. The upper limit correction result is used to characterize the upper bound of computing resources that the vehicle is allowed to access under the current power supply state, current thermal state, and power battery health state. The target number of available computing cores is derived from the same-dimensional comparison result between the total upper limit of available resources and the total number of remaining idle cores. The target number of available computing cores is used to constrain the range of physical cores that the second physical isolation domain can declare to the target access device. When filtering the upper limit of available computing hardware clusters, currently unoccupied computing hardware clusters with a number not exceeding the target number of available computing cores are retained to form candidate available computing hardware clusters. The candidate open computing hardware clusters are used to express the range of computing resources that can be declared to the target access device under the joint constraints of the current power supply state, the current thermal state, the power battery health state, and the second processor hardware range. Therefore, the computing resource declaration content in the available computing resource status list is adjusted according to changes in the current power supply state and the current thermal state during the vehicle's parking period, and computing resources exceeding the target number of open computing cores will not be declared to the target access device.

[0066] Preferably, when calculating the number of available threads of the general-purpose processor within the currently unoccupied computing hardware cluster, the general-purpose computing core corresponding to the general-purpose processor is first identified in the candidate open computing hardware clusters, and the thread scheduling slot status corresponding to the general-purpose computing core is read. The general-purpose computing core originates from the computing unit type of the computing hardware cluster corresponding to the general-purpose processor in the isolation domain resource scheduling table. The thread scheduling slot status is used to characterize whether the execution slot on the general-purpose computing core that can receive general-purpose computing instruction data to be processed is in an idle state. After counting the idle thread scheduling slot statuses, the number of available threads of the general-purpose processor is formed. The number of available threads of the general-purpose processor is used to characterize the general-purpose computing concurrency capability that the second physical isolation domain can open to the target access device, and is further written into the subsequent hardware resource status structure. By limiting the number of available threads of the general-purpose processor to the general-purpose computing cores in the candidate open computing hardware clusters, the general-purpose computing instruction data to be processed subsequently submitted by the target access device can be correlated with the actual general-purpose computing resources in the second physical isolation domain, thereby enabling the number of available threads of the general-purpose processor to participate in the task routing judgment of the subsequent instruction data to be processed.

[0067] Preferably, when calculating the available rendering pipeline value of the graphics accelerator within the currently unoccupied computing hardware cluster, the rendering acceleration resources corresponding to the graphics accelerator are first identified in the candidate open computing hardware clusters, and the occupancy status of the rendering pipeline corresponding to the rendering acceleration resources is read. The rendering acceleration resources originate from the computing unit type of the computing hardware cluster corresponding to the graphics accelerator in the isolation domain resource scheduling table. The rendering pipeline occupancy status is used to characterize whether the pipelines in the rendering acceleration resources capable of performing pixel rasterization calculations, image compositing calculations, or video rendering calculations are in an idle state. After counting the occupancy statuses of the rendering pipelines in an idle state, the available rendering pipeline value of the graphics accelerator is formed. The available rendering pipeline value of the graphics accelerator is used to characterize the graphics rendering acceleration capabilities that the second physical isolation domain can open to the target access device, and is further written into the hardware resource status structure. By limiting the available rendering pipeline value of the graphics accelerator to the rendering acceleration resources in the candidate open computing hardware cluster, the target access device can identify whether the second physical isolation domain has the available rendering pipeline value of the graphics accelerator that can be used for rendering tasks based on the available computing power resource status list when submitting video rendering-type pending computing instruction data.

[0068] Preferably, when calculating the available multiply-accumulator value of tensor processing units within the currently unoccupied computing hardware clusters, the inference computing resources corresponding to the tensor processing units are first identified in the candidate open computing hardware clusters, and the occupancy status of the multiply-accumulators corresponding to the inference computing resources is read. The inference computing resources originate from the computing unit type of the computing hardware cluster corresponding to the tensor processing unit in the isolation domain resource scheduling table. The multiply-accumulator occupancy status is used to characterize whether the multiply-accumulators in the inference computing resources capable of performing tensor matrix multiplication, vector accumulation, or inference computing tasks are in an idle state. After counting the occupancy statuses of the multiply-accumulators in an idle state, the available multiply-accumulator value of the tensor processing unit is formed. The available multiply-accumulator value of the tensor processing unit is used to characterize the inference computing capabilities that the second physical isolation domain can open to the target access device, and is further written into the hardware resource status structure. Since the available multiply-accumulator values ​​of the tensor processing unit originate from the inference computing resources that have been mounted within the second physical isolation domain and are not occupied by the pending computing instruction data, the tensor matrix multiplication type pending computing instruction data subsequently submitted by the target access device can select whether to request the corresponding inference computing resources based on the available multiply-accumulator values ​​of the tensor processing unit.

[0069] Preferably, when encapsulating the statistically obtained values ​​into a hardware resource status structure, the available thread value of the general-purpose processor, the available rendering pipeline value of the graphics accelerator, and the available multiply-accumulator value of the tensor processing unit are first written into the resource quantity field. Then, the session permission field, the connection validity timing field, and the access boundary record of the second physical isolation domain are written into the resource constraint field. The resource quantity field is used to describe to the target access device the quantity status of the requestable general-purpose computing resources, graphics rendering acceleration resources, and inference computing resources. The resource constraint field is used to describe to the target access device the permission boundary, timing boundary, and access boundary of resource requests in the current access session. Subsequently, the computing unit type of the computing hardware cluster corresponding to the candidate open computing hardware cluster is written into the resource type field, and the description of the temporary cache area corresponding to the volatile cache usage permission is written into the cache attribute field. The resource type field is used to describe to the target access device the computing unit type of the computing hardware cluster included in the candidate open computing hardware cluster. The cache attribute field is used to indicate that the subsequent pending computing instruction data only uses the temporary cache area allocated during task execution when running in the second physical isolation domain, and the temporary cache area is cleared after the task ends. Through the above field encapsulation, the hardware resource status structure includes not only the available quantity, but also the session permission field, the connection validity timing field, the second physical isolation domain access boundary record, and the cache attribute field.

[0070] Preferably, when setting the hardware resource status structure as the available computing power resource status list, a field consistency check is first performed on the hardware resource status structure to form a hardware resource status structure check record. The field consistency check is used to determine whether the available thread values ​​of the general-purpose processor, the available rendering pipeline values ​​of the graphics accelerator, and the available multiply-accumulator values ​​of the tensor processing unit in the resource quantity field all originate from the candidate open computing hardware clusters, and whether they all do not exceed the resource open range limited by the target number of open computing cores. If the hardware resource status structure check record indicates that the field consistency check passed, the hardware resource status structure is set as the available computing power resource status list; if the hardware resource status structure check record indicates that the field consistency check failed, the isolation domain establishment status record and the candidate open computing hardware clusters are reread to regenerate the hardware resource status structure. By having the hardware resource status structure undergo the field consistency check before forming the available computing power resource status list, the available computing power resource status list can maintain a correspondence with the actual resource status of the second physical isolation domain. The hardware resource status structure verification record continues to serve as the basis for generating the available computing power resource status list, enabling the available computing power resource status list to be traced back to the candidate open computing hardware clusters and the statistical source of the resource quantity field.

[0071] Preferably, the available computing power resource status list further includes a resource declaration timestamp field and a resource status version field. The resource declaration timestamp field originates from the local clock record read by the onboard computing platform when generating the available computing power resource status list, and is used to indicate the sampling time corresponding to the available thread value of the general-purpose processor, the available rendering pipeline value of the graphics accelerator, and the available multiply-accumulator value of the tensor processing unit; the resource status version field originates from the update sequence number of the isolation domain resource scheduling table, and is used to indicate the resource status version of the second physical isolation domain corresponding to the available computing power resource status list. The local clock record provides the time source of the resource declaration timestamp field, and the update sequence number of the isolation domain resource scheduling table provides the version source of the resource status version field. The resource declaration timestamp field and the resource status version field continue to participate in the subsequent receiving process of pending computing instruction data, enabling the target access device to carry the resource status version field corresponding to the available computing power resource status list when issuing the pending computing instruction data, thereby enabling the onboard computing platform to determine whether the pending computing instruction data is formed based on the currently valid available computing power resource status list. Therefore, the available computing power resource status list will not only serve as a static resource indicator, but will also serve as the basis for subsequent task routing and resource verification.

[0072] Preferably, when the available computing power resource status list is transparently transmitted to the target access device through the computing power sharing communication node, the secure socket connection establishment record is first read, and the end-to-end communication symmetric key is invoked according to the key index in the secure socket connection establishment record. The key index is derived from the secure socket connection establishment record and is used to invoke the end-to-end communication symmetric key within the vehicle-mounted security encryption chip; the end-to-end communication symmetric key is used to encrypt and encapsulate the available computing power resource status list. Subsequently, the available computing power resource status list is encrypted and encapsulated using the end-to-end communication symmetric key to form a encrypted resource status list message. The encrypted resource status list message includes the encrypted available computing power resource status list, the resource declaration timestamp field, the resource status version field, and the connection validity time sequence field. The computing power sharing communication node sends the encrypted resource status list message to the target access device, enabling the target access device to receive the available computing power resource status list within the valid access time sequence corresponding to the current secure socket connection. Because the list of available computing resources is transmitted encrypted via the secure socket connection, the available thread values ​​of the general-purpose processor, the available rendering pipeline values ​​of the graphics accelerator, and the available multiply-accumulator values ​​of the tensor processing unit will not be exposed in an unencrypted state in the near-field discovery channel.

[0073] Preferably, after receiving the encrypted resource status list message, the target access device first decrypts and parses the encrypted resource status list message within the secure socket connection session context corresponding to the secure socket connection to read the available computing power resource status list. The secure socket connection session context originates from the secure socket connection establishment record and is used to provide the basis for decrypting and parsing the encrypted resource status list message. The target access device identifies the requestable general computing resources, graphics rendering acceleration resources, and inference computing resources based on the resource quantity field in the available computing power resource status list, identifies the permission boundaries, timing boundaries, and access boundaries in the current access session based on the resource constraint field, and identifies the temporary cache area usage method during the execution of subsequent pending computing instruction data based on the cache attribute field. When generating pending computing instruction data later, the target access device writes the resource status version field into the header control field of the pending computing instruction data, so that the pending computing instruction data can establish a correspondence with the available computing power resource status list received this time. Through the above processing, the available computing power resource status list is not only used to inform the target access device of the current available resources, but also to restrict the data of pending computing instructions subsequently issued by the target access device from matching the current resource status of the second physical isolation domain.

[0074] Preferably, in one scenario, when the target access device is a laptop computer and requests to use the idle computing power of a parked vehicle through the secure socket connection, the vehicle-mounted computing platform first reads the target access device tag record, the isolation domain establishment status record, and the isolation domain resource scheduling table, and then filters the currently unoccupied computing hardware clusters from the second physical isolation domain. The currently unoccupied computing hardware clusters are filtered by the number of target open computing cores and the session permission field to form the candidate open computing hardware clusters; subsequently, the available thread value of the general-purpose processor, the available rendering pipeline value of the graphics accelerator, and the available multiplier-accumulator value of the tensor processing unit are counted from the candidate open computing hardware clusters, and the available thread value of the general-purpose processor, the available rendering pipeline value of the graphics accelerator, and the available multiplier-accumulator value of the tensor processing unit are written into the hardware resource status structure. The hardware resource status structure, after undergoing field consistency verification, forms the available computing power resource status list. This list is then encapsulated into a encrypted resource status list message using the end-to-end communication symmetric key and sent by the computing power sharing communication node to the target access device. This process ensures that the available computing power resource status list received by the target access device originates from real, unused computing resources within the second physical isolation domain, and remains consistent with the current access session's permission scope, effective timing, and access boundaries.

[0075] Optionally, the step of performing logical operations on the computation instruction data to be processed in the second physical isolation domain to generate the target computation result data segment includes: Parse the header control field of the computation instruction data to be processed, and read the instruction computation type identifier code from it; According to the instruction calculation type identifier code, the computing hardware is matched in the second physical isolation domain, and the computing instruction data to be processed is routed to the matched hardware execution unit; If the instruction calculation type identifier is a tensor matrix multiplication identifier, the tensor processing unit in the second physical isolation domain can use a multiply-accumulator to perform the logical operation. If the instruction calculation type identifier is a pixel rasterization calculation identifier, the logical operation can be performed by the graphics accelerator in the second physical isolation domain using the rendering pipeline. Collect the operation cache output data block generated by the logical operation, and concatenate and combine the operation cache output data block to generate the target operation result data segment.

[0076] Preferably, the specific implementation process of the step of performing logical operations on the computation instruction data to be processed in the second physical isolation domain to generate the target computation result data segment is as follows: After receiving the computation instruction data to be processed from the target access device, the target access device marking record, the secure socket connection establishment record, and the isolation domain establishment status record are read first. The target access device marking record is used to confirm that the computation instruction data to be processed originates from the target access device that has completed identity credential sequence verification. The secure socket connection establishment record is used to confirm that the computation instruction data to be processed is transmitted within the current access session. The isolation domain establishment status record is used to confirm that the second physical isolation domain has been established and has the operating conditions to receive the computation instruction data to be processed. Subsequently, based on the connection validity timing field in the secure socket connection establishment record, it is determined whether the computation instruction data to be processed falls within the valid access timing of the current access session, and based on the session permission field in the target access device marking record, it is determined whether the computation instruction data to be processed falls within the computing power open range allowed by the target access device. Only when the pending computation instruction data simultaneously satisfies the constraints of the connection validity timing field and the session permission field will the pending computation instruction data be written into the second physical isolation domain task entry cache. The second physical isolation domain task entry cache continues to provide the pending computation instruction data to the subsequent header control field parsing process, so that the source verification, session timing verification, and permission boundary verification of the pending computation instruction data are all executed before the logical operation.

[0077] Preferably, when parsing the header control field of the computation instruction data to be processed, the computation instruction data to be processed in the task entry buffer of the second physical isolation domain is first subjected to a boundary check to form a boundary check record. The boundary check record indicates whether the computation instruction data to be processed contains a header control field, a task payload field, and a result return description field. The header control field carries the instruction computation type identifier, resource status version field, process task identifier, and task fragmentation order field. The task payload field carries the data blocks to be processed that need to participate in logical operations. The result return description field carries the target storage path description string or target receiving channel description information required for the return of the target computation result data segment. The target storage path description string provides the data storage location during the subsequent target computation result data segment transmission stage, and the target receiving channel description information provides the data receiving channel during the subsequent target computation result data segment transmission stage. The header control field will only be parsed if the boundary verification record of the pending computation instruction data indicates that the header control field, the task payload field, and the result return description field all exist. If any field of the boundary verification record of the pending computation instruction data does not exist, an invalid computation instruction data record will be generated, and a task reception failure notification message will be returned to the target access device through the computing power sharing communication node, so that the incomplete pending computation instruction data will not enter the logical operation in the second physical isolation domain.

[0078] Preferably, when reading the instruction calculation type identifier from the header control field, the header control field is first located based on the boundary verification record of the computation instruction data to be processed. Then, the instruction calculation type identifier, the resource status version field, the process task identifier, and the task fragmentation order field are read from the header control field to form a computation instruction data parsing record to be processed. The instruction calculation type identifier is used to characterize the type of computation requested by the computation instruction data to be processed. The resource status version field is used to characterize the version of the available computing power resource status list on which the computation instruction data to be processed is based. The process task identifier is used to mark the task corresponding to the computation instruction data to be processed within the second physical isolation domain. The task fragmentation order field is used to mark the execution order and result concatenation order among multiple data blocks to be processed. The pending computation instruction data parsing record includes the instruction computation type identifier, the resource status version field, the process task identifier, and the task fragmentation order field. It continues to participate in subsequent resource status validity verification, computing hardware matching, and pending computation instruction data routing processes, so that the pending computation instruction data is not directly sent to any hardware execution unit, but is first formed into a routable and traceable task description through the pending computation instruction data parsing record.

[0079] Preferably, when performing resource status validity verification based on the resource status version field, the most recently sent available computing power resource status list to the target access device is first read, and the corresponding resource status version field, resource quantity field, and resource constraint field are read from the available computing power resource status list. The resource status version field in the parsing record of the computation instruction data to be processed is compared with the resource status version field in the available computing power resource status list to form a resource status version verification record. If the resource status version verification record indicates that the resource status version consistency verification passes, it means that the computation instruction data to be processed is formed based on the currently valid available computing power resource status list, and the computation hardware matching continues to be performed according to the resource quantity field and the resource constraint field; if the resource status version verification record indicates that the resource status version consistency verification fails, an updated available computing power resource status list is regenerated, and the updated available computing power resource status list is sent to the target access device through the computing power sharing communication node. By using the resource status version verification record, the pending computing instruction data can be kept in correspondence with the current resource status of the second physical isolation domain, thus preventing the target access device from issuing the pending computing instruction data based on the already invalid list of available computing power resources.

[0080] Preferably, when matching computing hardware within the second physical isolation domain according to the instruction calculation type identifier, the isolation domain resource scheduling table and candidate open computing hardware clusters are first read. The isolation domain resource scheduling table provides the correspondence between the computing unit type and physical core number of the computing hardware cluster within the second physical isolation domain, and the candidate open computing hardware cluster provides the range of computing resources that the second physical isolation domain can currently open to the target access device. The instruction calculation type identifier is matched with the computing unit type of the computing hardware cluster in the isolation domain resource scheduling table to form a computing hardware matching record. If the instruction calculation type identifier corresponds to general computing class unprocessed computing instruction data, then the general computing core corresponding to the general processor is matched in the candidate open computing hardware cluster; if the instruction calculation type identifier is a tensor matrix multiplication identifier, then the inference computing resource corresponding to the tensor processing unit is matched in the candidate open computing hardware cluster; if the instruction calculation type identifier is a pixel rasterization computing identifier, then the rendering acceleration resource corresponding to the graphics accelerator is matched in the candidate open computing hardware cluster. The computing hardware matching record continues to participate in the subsequent unprocessed computing instruction data routing process, so that a correspondence is established between the instruction computing type identifier code and the matched hardware execution unit.

[0081] Preferably, when routing the computation instruction data to be processed to a matching hardware execution unit, a second physical isolation domain task routing record is first generated based on the computation hardware matching record. The second physical isolation domain task routing record includes the process task identifier, the task fragmentation order field, the instruction computation type identifier, the type of the matching computation hardware cluster, and the range of matching physical core numbers. The second physical isolation domain task routing record indicates which type of matching hardware execution unit the computation instruction data to be processed enters within the second physical isolation domain, and restricts the computation instruction data to be processed to run only within the range of physical core numbers defined by the second processor hardware interval allocation record. Subsequently, based on the second physical isolation domain task routing record, the data block to be processed in the task payload field is written to the task input buffer corresponding to the matching hardware execution unit, and the process task identifier in the header control field is written to the task execution index record. The task execution index record continues to participate in the subsequent computation cache output data block acquisition process, enabling the computation cache output data blocks generated from each of the data blocks to be processed to be combined and concatenated under the same process task identifier.

[0082] Preferably, if the instruction calculation type identifier is a tensor matrix multiplication identifier, the logical operation is performed using the available multipliers and adders in the tensor processing unit within the second physical isolation domain. Specifically, based on the task routing record of the second physical isolation domain, the tensor input data block in the task payload field is written into the task input buffer of the tensor processing unit, and the tensor input data block is divided into multiple tensor computation fragments according to the task fragmentation order field. The tensor input data block is used to carry the numerical data required for matrix multiplication or vector accumulation, and the tensor computation fragments are used to enable the tensor input data block to enter the inference computation resources in batches according to the idle multiplier and adder resources corresponding to the available multiplier and adder values ​​of the tensor processing unit. Subsequently, the available multiplier and adder values ​​of the tensor processing unit are read, and multiplier and adder execution slots are allocated to the tensor computation fragments according to the available multiplier and adder values ​​of the tensor processing unit, so that each tensor computation fragment completes the multiplication and accumulation processing in the corresponding multiplier and adder execution slot. The multiply-accumulator execution slot is used to characterize the allocation position of the available multiply-accumulator in the tensor matrix multiplication type of computation instruction data to be processed in this tensor matrix multiplication. The multiplication accumulation process forms a tensor fragmented operation cache output data block. The tensor fragmented operation cache output data block carries the process task identifier code and the task fragmentation order field, and continues to participate in the subsequent operation cache output data block acquisition process.

[0083] Preferably, if the instruction calculation type identifier is a pixel rasterization calculation identifier, the logical operation is executed using the available rendering pipeline of the graphics accelerator within the second physical isolation domain. Specifically, according to the task routing record of the second physical isolation domain, the pixel input data block in the task payload field is written into the graphics accelerator task input buffer, and the pixel input data block is divided into multiple pixel calculation slices according to the task slice order field. The pixel input data block is used to carry the image data required for pixel rasterization calculation, image compositing calculation, or video rendering calculation. The pixel calculation slices are used to enable the pixel input data block to enter the rendering acceleration resources in batches according to the idle rendering pipeline resources corresponding to the available rendering pipeline value of the graphics accelerator. Subsequently, the available rendering pipeline value of the graphics accelerator is read, and rendering pipeline execution slots are allocated to the pixel calculation slices according to the available rendering pipeline value of the graphics accelerator, so that each pixel calculation slice completes pixel filling, texture sampling, or image compositing processing in the corresponding rendering pipeline execution slot. The rendering pipeline execution slot is used to characterize the allocation position of the available rendering pipeline of the graphics accelerator in the processing instruction data of the current pixel rasterization calculation class. The pixel filling, texture sampling or image compositing processing forms a pixel piece operation cache output data block. The pixel piece operation cache output data block carries the process task identifier code and the task piece order field, and continues to participate in the subsequent operation cache output data block acquisition process.

[0084] Preferably, if the instruction calculation type identifier code corresponds to general computing class processing instruction data, then according to the task routing record of the second physical isolation domain, the general computing core corresponding to the available thread value of the general processor in the second physical isolation domain is used to execute the logical operation. Specifically, the general input data block in the task payload field is written into the general processor task input buffer, and the general input data block is divided into multiple general computing fragments according to the task fragmentation order field. The general input data block is used to carry the data content required for text processing, file compression, data format conversion, or general numerical calculation, and the general computing fragments are used to enable the general input data block to enter the general computing core in batches according to the available thread value of the general processor. Subsequently, the thread scheduling slot status is read, and thread execution slots are allocated to the general computing fragments according to the idle thread scheduling slot status, so that each general computing fragment completes general logical operation processing in the corresponding thread execution slot. The thread execution slot is used to represent the allocation position of the thread resources corresponding to the available thread value of the general processor in the general computing instruction data to be processed in this general computing class. The general logic operation processing forms a general fragmented operation cache output data block. The general fragmented operation cache output data block carries the process task identifier code and the task fragmentation order field, and continues to participate in the subsequent operation cache output data block acquisition process.

[0085] Preferably, when collecting the computation cache output data blocks generated by the logical operation, a temporary cache area corresponding to the same process task identifier is first read according to the task execution index record, and tensor fragmented computation cache output data blocks, pixel fragmented computation cache output data blocks, or general fragmented computation cache output data blocks are retrieved in the temporary cache area. The temporary cache area originates from the volatile cache usage permission in the second physical isolation domain access boundary record and is allocated only during the execution of the computation instruction data to be processed. The tensor fragmented computation cache output data blocks, the pixel fragmented computation cache output data blocks, and the general fragmented computation cache output data blocks all belong to the computation cache output data blocks generated by the logical operation. The retrieved computation cache output data blocks are subjected to computation cache output data block integrity verification to form a computation cache output data block integrity verification record. The computation cache output data block integrity verification record is used to determine whether each computation cache output data block under the same process task identifier carries the corresponding task fragmentation order field and whether they all come from the matching hardware execution unit indicated by the task routing record of the second physical isolation domain. Only when the integrity verification record of the operation cache output data block indicates that the integrity verification of the operation cache output data block has passed will the splicing and combination process continue.

[0086] Preferably, when concatenating the output data blocks of the computation cache, the arrangement order of each output data block in the target computation result data segment is first determined according to the task fragmentation order field. Then, the output data blocks of the computation cache are written into the result concatenation cache area according to the arrangement order to form a target computation result candidate data segment. The result concatenation cache area is a temporary cache area within the second physical isolation domain, and the target computation result candidate data segment is used to carry the concatenation result that has not yet been verified. Subsequently, the target computation result candidate data segment is verified according to the instruction calculation type identifier code in the pending computation instruction data parsing record to form a target computation result candidate data segment verification record. The target computation result candidate data segment verification is used to determine whether the result format of the target computation result candidate data segment matches the computation type corresponding to the instruction calculation type identifier code. If the verification record of the target operation result candidate data segment indicates that the target operation result candidate data segment has passed the verification, then the target operation result candidate data segment is set as the target operation result data segment; if the verification record of the target operation result candidate data segment indicates that the target operation result candidate data segment has failed the verification, then the corresponding operation cache output data block is re-collected according to the task execution index record. Through the above concatenation and combination processing, the target operation result data segment can retain the correspondence between itself and the process task identifier code, the task fragmentation order field, and the instruction calculation type identifier code.

[0087] Preferably, during the execution of the logical operation in the second physical isolation domain, the chassis reset interrupt status record corresponding to the real-time vehicle chassis signal collected by the underlying hardware daemon process in the first physical isolation domain is continuously read. The chassis reset interrupt status record is used to indicate whether the real-time vehicle chassis signal has triggered the chassis reset interrupt condition. If the chassis reset interrupt status record indicates that the chassis reset interrupt condition has not been triggered, the second physical isolation domain is allowed to continue executing the logical operation according to the task routing record of the second physical isolation domain; if the chassis reset interrupt status record indicates that the chassis reset interrupt condition has been triggered, the logical operation running in the second physical isolation domain is terminated according to the hardware interrupt request instruction, and the task running index record, the task routing record of the second physical isolation domain, and the intermediate data in the temporary cache area are marked as interrupt cleanup objects. The interrupt cleanup objects are cleared in the interrupt blocking logic, and a session abnormal disconnection notification message is sent to the target access device through the computing power sharing communication node. The session abnormal disconnection notification message is used to inform the target access device that the logical operation has been terminated due to the chassis reset interruption condition, so that the logical operation will not affect the response of the first physical isolation domain to the real-time vehicle chassis signal.

[0088] Preferably, in one scenario, when the instruction calculation type identifier code carried by the computation instruction data to be processed issued by the target access device is a tensor matrix multiplication identifier code, the vehicle-mounted computing platform first performs boundary verification on the computation instruction data to be processed, and reads the instruction calculation type identifier code, the resource status version field, the process task identifier code, and the task fragmentation order field from the header control field. Subsequently, it completes the resource status validity verification according to the resource status version field, and generates the computing hardware matching record according to the instruction calculation type identifier code. After the computing hardware matching record points to the inference computing resource in the second physical isolation domain, the tensor input data block in the task payload field is written into the task input buffer of the tensor processing unit, and the multiplication accumulation processing is performed according to the available multiplier-accumulator value of the tensor processing unit. The tensor fragmentation operation buffer output data block formed by the multiplication accumulation processing enters the result concatenation buffer according to the task fragmentation order field, thereby forming the target operation result data segment. The above processing ensures that the target computation result data segment originates from the matching hardware execution unit within the second physical isolation domain that matches the instruction computation type identifier code, and maintains a correspondence in task source and fragmentation order with the computation instruction data to be processed submitted by the target access device.

[0089] Optionally, after the step of receiving the processing instruction data issued by the target access device, the method further includes: Extract the process task identifier and the total number of instructions from the computation instruction data to be processed; Real-time statistics are performed on the number of currently consumed instructions that have been completed by the second physical isolation domain for the computation instruction data to be processed; Calculate the progress percentage based on the current number of consumed instructions and the total number of instructions; Obtain the video memory address pointer of the vehicle cockpit domain controller, and write the process task identifier code and the progress percentage value into the physical video memory mapping area corresponding to the video memory address pointer. The cockpit LCD display panel is triggered to read the values ​​in the physical memory mapping area and refresh the display progress graphic component elements to provide feedback on the execution progress of the pending calculation instruction data through the vehicle's local hardware.

[0090] Preferably, after the step of receiving the pending computation instruction data issued by the target access device, the pending computation instruction data parsing record, the target access device marking record, and the second physical isolation domain task routing record are read first. The pending computation instruction data parsing record is used to provide the header control field in the pending computation instruction data. The target access device marking record is used to confirm that the pending computation instruction data originates from the identified target access device. The second physical isolation domain task routing record is used to confirm that the pending computation instruction data has been routed to a matching hardware execution unit within the second physical isolation domain. Subsequently, the header control field is located according to the pending computation instruction data parsing record, and the process task identifier and total number of instructions are extracted from the header control field. The process task identifier is used to mark the currently executing pending computation instruction data within the second physical isolation domain, and the total number of instructions represents the total number of instruction units that the pending computation instruction data needs to be consumed by the second physical isolation domain. The process task identifier and the total number of instructions are written together into the task progress tracking record, so that the subsequent statistics of the number of currently consumed instructions, the calculation of the progress percentage, and the local hardware display can all correspond to the same data of the computational instructions to be processed.

[0091] Preferably, when extracting the total number of instructions from the pending computation instruction data, the total number of instructions is also validated to form a total instruction count validation record. This record indicates whether the total number of instructions has a valid counting basis for progress calculation. When the total number of instructions does not have a valid counting basis for progress calculation, the task progress tracking record is marked as not displayable and a task progress field anomaly notification message is returned to the target access device via the computing power sharing communication node. When the total number of instructions has a valid counting basis for progress calculation, the total number of instructions is written into the total quantity field of the task progress tracking record. This total quantity field continues to participate in subsequent progress percentage calculations, ensuring that the progress percentage value is not estimated based on computation time or resource utilization, but rather calculated based on the total number of instruction units to be consumed in the pending computation instruction data. The task progress field anomaly notification message confirms to the target access device that the total number of instructions in the pending computation instruction data cannot be used for local hardware display, preventing the vehicle cockpit domain controller from generating an incorrect progress percentage value based on an invalid counting basis.

[0092] Preferably, when counting the number of currently consumed instructions completed by the second physical isolation domain for the processing instruction data in real time, the task execution index record is first read according to the process task identifier in the task progress tracking record. The task execution index record is used to provide the running position of the processing instruction data in the second physical isolation domain, the task fragmentation order field, and the matching hardware execution unit. Subsequently, an instruction consumption count record is established in the second physical isolation domain for the process task identifier. The instruction consumption count record is used to record the number of data blocks to be processed corresponding to each task fragmentation order field that have been taken and consumed by the matching hardware execution unit. Whenever the matching hardware execution unit completes the consumption of an instruction unit, the corresponding consumption status is written to the instruction consumption count record; then, the instruction consumption count record is summarized to form the current number of consumed instructions. The current number of consumed instructions is continued to be written to the consumed field of the task progress tracking record, so that the current number of consumed instructions and the total number of instructions are under the same counting caliber. The consumed field continues to participate in the subsequent progress percentage value calculation, so that the progress percentage value can correspond to the pending calculation instruction data marked by the process task identifier.

[0093] Preferably, when counting the number of currently consumed instructions, the instruction calculation type identifier code in the task routing record of the second physical isolation domain is also read. If the instruction calculation type identifier code is a tensor matrix multiplication identifier code, the instruction consumption count record updates the number of currently consumed instructions based on the state of the tensor calculation slice entering the multiply-accumulate execution slot and completing the multiplication accumulation process; if the instruction calculation type identifier code is a pixel rasterization calculation identifier code, the instruction consumption count record updates the number of currently consumed instructions based on the state of the pixel calculation slice entering the rendering pipeline execution slot and completing pixel filling, texture sampling, or image compositing processing; if the instruction calculation type identifier code corresponds to general calculation type pending calculation instruction data, the instruction consumption count record updates the number of currently consumed instructions based on the state of the general calculation slice entering the thread execution slot and completing the general logic operation processing. By making the number of currently consumed instructions derived from the actual consumption state of different matching hardware execution units, the task progress tracking record can reflect the execution progress status of the pending calculation instruction data within the second physical isolation domain. The execution progress status continues to enter the progress percentage value calculation process through the number of currently consumed instructions, so that the pending calculation instruction data of different calculation types all use the same progress statistics link.

[0094] Preferably, when calculating the progress percentage value based on the current number of consumed instructions and the total number of instructions, the total number field and the consumed field are first read from the task progress tracking record. Then, the current number of consumed instructions and the total number of instructions are converted to the same dimension to form the progress percentage value. The progress percentage value is used to characterize the proportion of the computational instruction data to be processed that has been consumed by the second physical isolation domain, and is continued to be written into the progress field of the task progress tracking record. To make the progress percentage value adaptable to the display refresh mode of the vehicle cockpit domain controller, the progress percentage value can also be processed to achieve a display granularity adjustment to form a display progress percentage value. The display progress percentage value and the progress percentage value maintain the same source relationship and are used for subsequent writing to the physical video memory mapping area. Thus, the calculation process of the progress percentage value has a continuous correspondence with the current number of consumed instructions, the total number of instructions, and the process task identifier code. The display progress percentage value adapts to the display refresh mode of the cockpit LCD display panel while retaining this continuous correspondence.

[0095] Preferably, before obtaining the video memory address pointer of the vehicle cockpit domain controller, the display resource mapping record of the vehicle cockpit domain controller is read first. The display resource mapping record provides a physical video memory mapping area in the vehicle cockpit domain controller that can be used for local hardware feedback, and records the mapping relationship between the physical video memory mapping area and the display progress graphic component element on the cockpit LCD panel. Based on the display resource mapping record, the physical video memory mapping area corresponding to the execution progress of the computational instruction data to be processed is located, and the video memory address pointer corresponding to the physical video memory mapping area is read from the display resource mapping record. The video memory address pointer indicates the physical video memory mapping area where the process task identifier code and the progress percentage value are subsequently written. The physical video memory mapping area carries the process task identifier code and the progress percentage value that the vehicle cockpit domain controller can directly read. Through the display resource mapping record, the video memory address pointer is not a temporarily selected address, but has a pre-configured display mapping relationship with the display progress graphic component element on the cockpit LCD panel.

[0096] Preferably, when writing the process task identifier and the progress percentage value into the physical memory mapping area corresponding to the memory address pointer, the task identifier writing area and the progress percentage value writing area in the physical memory mapping area are first located according to the memory address pointer. The task identifier writing area is used to write the process task identifier, and the progress percentage value writing area is used to write the progress percentage value or the display progress percentage value. Subsequently, the process task identifier is written into the task identifier writing area, and the progress percentage value or the display progress percentage value is written into the progress percentage value writing area to form a memory progress write record. The memory progress write record is used to indicate that the execution progress corresponding to the pending calculation instruction data has entered the physical memory mapping area that can be read by the vehicle cockpit domain controller. The memory progress write record continues to participate in the subsequent cockpit LCD panel refresh process, enabling the cockpit LCD panel to read the progress percentage value or the display progress percentage value corresponding to the process task identifier from the physical memory mapping area.

[0097] Preferably, after the memory progress write record is formed, a write consistency check is performed on the physical memory mapping area to form a memory progress write check record. The memory progress write check record is used to determine whether the process task identifier code in the task identifier write area is consistent with the process task identifier code in the task progress tracking record, and to determine whether the progress percentage value in the progress percentage value write area or the displayed progress percentage value originates from the current number of consumed instructions and the total number of instructions. If the memory progress write check record indicates that the write consistency check has passed, the cockpit LCD display panel is allowed to read the physical memory mapping area; if the memory progress write check record indicates that the write consistency check has failed, the task progress tracking record is reread, and the process task identifier code and the progress percentage value are written again according to the memory address pointer. Through the above write consistency check, the number of times the cockpit LCD display panel reads a process task identifier code and a progress percentage value that do not correspond to the current pending calculation instruction data can be reduced.

[0098] Preferably, when the cockpit LCD panel is triggered to read the values ​​in the physical video memory mapping area, the vehicle cockpit domain controller first generates a display refresh trigger record based on the video memory progress write record. The display refresh trigger record instructs the cockpit LCD panel to read the task identifier write area and the progress percentage value write area in the physical video memory mapping area, and sends the read process task identifier code and the progress percentage value to the display progress graphic component element. The display progress graphic component element determines the task display object that needs to be updated based on the process task identifier code. The task display object is used to display the pending calculation instruction data marked by the process task identifier code on the cockpit LCD panel. The display progress graphic component element refreshes the progress bar length, progress value text, or task running status identifier based on the progress percentage value. The refreshed display progress graphic component element continues to be displayed on the cockpit LCD panel, enabling the vehicle's local hardware to provide feedback on the execution progress of the pending calculation instruction data, without requiring the target access device to separately query the task execution status of the second physical isolation domain through an external application interface.

[0099] Preferably, during the logical operation of the computational instruction data to be processed in the second physical isolation domain, the task progress tracking record is updated according to a progress refresh cycle. The progress refresh cycle is pre-configured in the display resource mapping record of the vehicle cockpit domain controller, and is used to limit the refresh frequency of the currently consumed instruction count, the progress percentage value, and the physical memory mapping area. Each time the progress refresh cycle is reached, the instruction consumption count record is reread, the currently consumed instruction count is updated, and the progress percentage value is recalculated based on the updated currently consumed instruction count and the total number of instructions. The updated progress percentage value is written to the physical memory mapping area through the memory address pointer, triggering a refresh of the display progress graphics component element. Through the progress refresh cycle, the execution progress is updated according to the vehicle's local display rhythm, avoiding unnecessary display refresh burden on the vehicle cockpit domain controller caused by frequent writing to the physical memory mapping area. The progress refresh cycle, the memory address pointer, and the display progress graphics component element all originate from the display resource mapping record, ensuring that the progress refresh process is consistent with the display resource configuration of the vehicle cockpit domain controller.

[0100] Preferably, after the logical operation corresponding to the pending computation instruction data is completed, the second physical isolation domain forms a task completion status record based on the task execution index record. The task completion status record indicates that the pending computation instruction data corresponding to the process task identifier has completed the logical operation, and triggers the current number of consumed instructions to be updated to a completion status consistent with the total number of instructions. Subsequently, the progress percentage value in the completion status is calculated based on the task completion status record, and the process task identifier and the progress percentage value in the completion status are written into the physical memory mapping area. After the cockpit LCD display panel reads the physical memory mapping area, it refreshes the display progress graphic component element to a completion display status. The completion display status indicates that the logical operation corresponding to the pending computation instruction data has been completed. The completion display status continues to be connected with the return process of the target computation result data segment, ensuring that the execution progress displayed by the local hardware remains consistent with the generation status of the target computation result data segment.

[0101] Preferably, during the execution of the pending computation instruction data in the second physical isolation domain, if the underlying hardware daemon triggers a chassis reset interrupt condition based on real-time vehicle chassis signals, it terminates the logical operation within the second physical isolation domain according to a hardware interrupt request instruction, and reads the process task identifier and the most recently formed progress percentage value from the task progress tracking record. Subsequently, the process task identifier and interrupt status identifier are written into the physical memory mapping area, and the cockpit LCD display panel is triggered to read the physical memory mapping area to refresh the display progress graphic component element to an interrupt display state. The interrupt status identifier is used to indicate that the logical operation corresponding to the pending computation instruction data has been terminated due to the chassis reset interrupt condition, and the interrupt display state is used to indicate that the execution progress of the pending computation instruction data has stopped updating due to the chassis reset interrupt condition, and corresponds to the session abnormal disconnection notification message sent to the target access device through the computing power sharing communication node. Thus, the vehicle's local hardware feedback can not only display the normal execution progress, but also display a task status consistent with the interruption blocking logic when the chassis reset interrupt condition is triggered.

[0102] Preferably, in one scenario, when the target access device issues video rendering-type pending computation instruction data, the header control field carries the process task identifier and the total number of instructions. The second physical isolation domain routes the video rendering-type pending computation instruction data to the available rendering pipeline of the graphics accelerator according to the instruction computation type identifier, and updates the instruction consumption count record after each pixel computation slice completes pixel filling, texture sampling, or image compositing processing. The updated instruction consumption count record forms the current number of consumed instructions, and the current number of consumed instructions and the total number of instructions are used to calculate the progress percentage value. The vehicle cockpit domain controller writes the process task identifier and the progress percentage value into the physical memory mapping area according to the video memory address pointer, and the cockpit LCD display panel reads the physical memory mapping area and refreshes the display progress graphics component element. The above processing enables the video rendering-type pending computation instruction data initiated by the target access device to form an execution progress on the vehicle's local hardware, and the execution progress originates from the actual instruction consumption status of the video rendering-type pending computation instruction data by the second physical isolation domain.

[0103] Optionally, the step of the underlying hardware daemon continuously collecting real-time vehicle chassis signals and determining whether a chassis reset interrupt condition is triggered includes: The underlying hardware daemon process is used to extract chassis control action levels from the real-time vehicle chassis signals collected in real time. The extracted chassis control action level is compared with a preset hardware wake-up threshold. If the chassis control action level meets the hardware wake-up threshold, it is determined that the chassis reset interrupt condition is triggered. When the chassis reset interrupt condition is triggered, a hardware interrupt request instruction with the highest priority is sent to the second physical isolation domain; The hardware interrupt request instruction is used to forcibly terminate all logical operations running within the second physical isolation domain. Clear the system hardware resources occupied by the second physical isolation domain and send a session abnormal disconnection notification message to the target access device to execute the interrupt blocking logic when the chassis reset interrupt condition is triggered.

[0104] Preferably, the specific implementation process of the underlying hardware daemon continuously collecting real-time vehicle chassis signals and determining whether a chassis reset interrupt condition is triggered is as follows: After the first physical isolation domain is established, the first processor hardware interval allocation record and the first physical isolation domain access boundary record are read first, and the underlying hardware daemon is started according to the first processor hardware interval allocation record. The first physical isolation domain access boundary record is used to limit the underlying hardware daemon's access to the real-time vehicle chassis signals, chassis reset interrupt response data, and hardware interrupt request instruction generation data; the hardware interrupt request instruction generation data is used to generate a hardware interrupt request instruction when the chassis reset interrupt condition is triggered subsequently. After the underlying hardware daemon is started, a real-time vehicle chassis signal sampling record is established according to the first physical isolation domain access boundary record. The real-time vehicle chassis signal sampling record is used to continuously write vehicle braking trigger signals, ignition wake-up signals, gear release request signals, electronic parking release request signals, and chassis controller wake-up request signals, so that when extracting chassis control action levels subsequently, the underlying control signal source related to the vehicle exiting the parking state can be read from the same real-time vehicle chassis signal sampling record.

[0105] Preferably, when extracting chassis control action levels from the real-time vehicle chassis signals acquired in real time using the underlying hardware daemon process, the underlying hardware daemon process first filters out chassis reset candidate signal frames from the real-time vehicle chassis signal sampling records. The chassis reset candidate signal frames carry underlying control signals that can cause the vehicle to switch from a stationary computing power open state to a basic driving wake-up state. Each chassis reset candidate signal frame includes a signal source identifier, a sampling timestamp, and an original action level value. The original action level value is used to retain the original level expression formed during acquisition of the chassis reset candidate signal frames and continues to participate in level semantic normalization processing. Subsequently, the original action level value in the chassis reset candidate signal frames undergoes level semantic normalization processing to form the chassis control action level. The level semantic normalization processing is used to convert the high-level active, low-level active, or edge-triggered active expression methods in different vehicle chassis signals into a unified action level expression method. Therefore, the chassis control action level no longer depends on the original encoding of a single chassis sensor signal, but is formed by the chassis reset candidate signal frame after the level semantic normalization processing, and is continued to be written into the chassis control action level extraction record; the chassis control action level extraction record is used to retain the source correspondence between the chassis control action level and the chassis reset candidate signal frame.

[0106] Preferably, after the chassis control action level extraction record is formed, the chassis control action level extraction record and the real-time vehicle chassis signal sampling record are subjected to source correspondence verification. The source correspondence verification is used to determine whether all chassis control action levels originate from the chassis reset candidate signal frame, and whether all chassis reset candidate signal frames originate from the real-time vehicle chassis signal sampling record. If the source correspondence verification passes, the chassis control action level extraction record is written into the chassis reset determination buffer; the chassis reset determination buffer is used to provide the chassis control action level verified by the source correspondence to the subsequent hardware wake-up threshold comparison process. If the source correspondence verification fails, the real-time vehicle chassis signal sampling record is reread to re-form the chassis reset candidate signal frame and the chassis control action level. By maintaining a correspondence between the chassis control action level extraction record and the real-time vehicle chassis signal sampling record, the situation where the chassis reset interruption condition is formed based on action levels of unknown origin can be reduced.

[0107] Preferably, before comparing the extracted chassis control action level with a preset hardware wake-up threshold, a hardware wake-up threshold configuration record is read first. This hardware wake-up threshold configuration record is pre-written into a read-only configuration area accessible by the first physical isolation domain. The record includes brake trigger level thresholds, ignition wake-up level thresholds, gear release request level thresholds, electronic parking brake release request level thresholds, and chassis controller wake-up request level thresholds. All thresholds in the hardware wake-up threshold configuration record are measured in action level units and are compared using the same metric as the chassis control action level. The record also includes a threshold source verification field, which indicates that the hardware wake-up threshold originates from the chassis reset response configuration formed during the vehicle's factory configuration phase. This chassis reset response configuration limits the underlying level conditions that should be triggered when the vehicle switches from the parking computing power open state to the basic driving wake-up state. Through this hardware wake-up threshold configuration record, the comparison between the chassis control action level and the hardware wake-up threshold has the same metric basis, rather than directly mixing the original chassis signal encoding with the threshold for comparison.

[0108] Preferably, when comparing the extracted chassis control action level with a preset hardware wake-up threshold, the chassis control action level extraction record is first read from the chassis reset determination buffer, and the hardware wake-up threshold corresponding to the chassis control action level is located in the hardware wake-up threshold configuration record based on the signal source identifier in the chassis control action level extraction record. Subsequently, the chassis control action level and the corresponding hardware wake-up threshold are compared using a level trigger to form a chassis control action level comparison record. The chassis control action level comparison record is used to indicate whether any of the vehicle braking trigger signal, the ignition wake-up signal, the gear release request signal, the electronic parking brake release request signal, and the chassis controller wake-up request signal satisfies the hardware wake-up threshold. If any chassis control action level satisfies the corresponding hardware wake-up threshold, the chassis control action level comparison record is written to the chassis reset interrupt determination queue; if all chassis control action levels fail to satisfy the corresponding hardware wake-up threshold, the chassis control action level comparison record is written to the chassis non-reset determination queue. The chassis reset interruption determination queue and the chassis non-reset determination queue continue to participate in the chassis reset interruption status record generation process.

[0109] Preferably, if the chassis control action level meets the hardware wake-up threshold, and the chassis reset interrupt condition is triggered, the underlying hardware daemon process generates a chassis reset interrupt status record based on the chassis reset interrupt determination queue. The chassis reset interrupt status record includes the chassis control action level that meets the hardware wake-up threshold, the corresponding signal source identifier, the corresponding sampling timestamp, and the corresponding hardware wake-up threshold. The chassis reset interrupt status record indicates that the chassis reset interrupt condition has been triggered by the underlying control action in the real-time vehicle chassis signal, and continues to serve as the basis for subsequently issuing hardware interrupt request instructions to the second physical isolation domain. If the chassis non-reset determination queue indicates that all chassis control action levels do not meet the hardware wake-up threshold, the underlying hardware daemon process generates a chassis non-reset status record. This record allows the second physical isolation domain to continue executing the currently received pending calculation instruction data and is used to update the chassis control action level comparison record the next time the underlying hardware daemon process collects the real-time vehicle chassis signal.

[0110] Preferably, before issuing the highest-priority hardware interrupt request instruction to the second physical isolation domain when the chassis reset interrupt condition is triggered, the chassis reset interrupt status record and the isolation domain establishment status record are read first. The isolation domain establishment status record is used to provide a first processor hardware interval allocation record, a second processor hardware interval allocation record, and an isolation domain resource scheduling table. The isolation domain resource scheduling table is used to indicate the hardware execution unit where the currently running logical operation in the second physical isolation domain is located. A hardware interrupt request instruction is generated based on the chassis reset interrupt status record, the second processor hardware interval allocation record, and the isolation domain resource scheduling table. The hardware interrupt request instruction includes an interrupt source field, an interrupt target field, an interrupt priority field, and an interrupt execution field. The interrupt source field is derived from the chassis reset interrupt status record, the interrupt target field is derived from the second processor hardware interval allocation record, the interrupt priority field is used to indicate that the hardware interrupt request instruction is higher than the logical operation in the second physical isolation domain, and the interrupt execution field is used to indicate that the second physical isolation domain enters the task termination and resource cleanup process. After the hardware interrupt request instruction is generated, the hardware interrupt request instruction generation data is associated with the chassis reset interrupt status record and stored to retain the basis for the generation of the hardware interrupt request instruction.

[0111] Preferably, after the hardware interrupt request instruction is generated, the first physical isolation domain writes the hardware interrupt request instruction into the interrupt delivery queue of the second physical isolation domain. The interrupt delivery queue of the second physical isolation domain is used to transmit data containing only interrupt control information between the first physical isolation domain and the second physical isolation domain, without transmitting the real-time vehicle chassis signal in the first physical isolation domain. The second physical isolation domain reads the hardware interrupt request instruction according to the interrupt delivery queue of the second physical isolation domain, and suspends the reception of new pending calculation instruction data according to the interrupt priority field in the hardware interrupt request instruction. Subsequently, the second physical isolation domain generates a task termination preparation record according to the interrupt execution field. The task termination preparation record is used to switch the currently running logical operation from the normal execution state to the termination preparation state. Through the interrupt delivery queue of the second physical isolation domain, the hardware interrupt request instruction can be transmitted from the first physical isolation domain to the second physical isolation domain, while maintaining the data access boundary between the first physical isolation domain and the second physical isolation domain.

[0112] Preferably, when forcibly terminating all running logical operations within the second physical isolation domain according to the hardware interrupt request instruction, the task execution index record, the second physical isolation domain task routing record, and the task termination preparation record are read first. The task execution index record provides the process task identifier code corresponding to the running pending computation instruction data. The second physical isolation domain task routing record provides the hardware execution unit and physical core number range corresponding to the pending computation instruction data. The task termination preparation record indicates that the logical operation has entered the termination preparation state. Subsequently, the running logical operation is located according to the process task identifier code, and a termination flag is issued to the corresponding task input buffer, execution slot, and result concatenation buffer according to the hardware execution unit and the physical core number range. The termination flag prevents tensor computation fragments, pixel computation fragments, or general computation fragments from continuing to enter the corresponding hardware execution unit. After the termination flag is written, a logical operation termination record is formed. The logical operation termination record indicates that the logical operation corresponding to the process task identifier code has stopped execution according to the hardware interrupt request instruction and continues to participate in the subsequent system hardware resource cleanup process.

[0113] Preferably, after forming the logical operation termination record, when clearing the system hardware resources occupied by the second physical isolation domain, the task input buffer, temporary buffer, result concatenation buffer, thread execution slot, rendering pipeline execution slot, and multiply-accumulator execution slot corresponding to the process task identifier are first read according to the logical operation termination record. The task input buffer is used to temporarily store the data blocks to be processed in the computation instruction data to be processed; the temporary buffer is used to temporarily store the output data blocks of the computation buffer; the result concatenation buffer is used to temporarily store the candidate data segments of the target computation result; and the thread execution slot, the rendering pipeline execution slot, and the multiply-accumulator execution slot are used to carry logical operation operations of different computation types. Subsequently, data clearing processing is performed on the task input buffer, the temporary buffer, and the result concatenation buffer, and occupation release processing is performed on the thread execution slot, the rendering pipeline execution slot, and the multiply-accumulator execution slot to form a system hardware resource cleanup record. The system hardware resource cleanup record is used to indicate that the system hardware resources occupied by the second physical isolation domain have been released from the running state corresponding to the pending computing instruction data, and continue to participate in subsequent cleanup integrity verification.

[0114] Preferably, after the system hardware resource cleanup record is formed, a cleanup integrity check is performed based on the second physical isolation domain access boundary record. The second physical isolation domain access boundary record is used to limit the task data, temporary cache range, and hardware execution unit range that the second physical isolation domain can access; the cleanup integrity check is used to determine whether the system hardware resource cleanup record covers the task input cache area, temporary cache area, result concatenation cache area, and execution slot associated with the current process task identifier in the second physical isolation domain access boundary record. If the cleanup integrity check passes, a second physical isolation domain cleanup completion record is generated; if the cleanup integrity check fails, the uncleaned task input cache area, temporary cache area, result concatenation cache area, or execution slot is relocated based on the second physical isolation domain access boundary record, and the data clearing process and the occupation release process are performed again. The second physical isolation domain cleanup completion record continues to participate in the subsequent session abnormal disconnection notification message generation process, so that the session abnormal disconnection notification message can correspond to the interruption state that has completed resource cleanup.

[0115] Preferably, when sending a session abnormal disconnection notification message to the target access device, the target access device marking record, secure socket connection establishment record, chassis reset interruption status record, and second physical isolation domain cleanup completion record are read first. The target access device marking record is used to determine the target access device that needs to receive the session abnormal disconnection notification message. The secure socket connection establishment record is used to provide the connection validity timing field and key index corresponding to the current access session. The chassis reset interruption status record is used to provide the source of the underlying control signal that triggers the chassis reset interruption condition. The second physical isolation domain cleanup completion record is used to provide the status that the system hardware resources occupied by the second physical isolation domain have been cleared. Subsequently, the session abnormal disconnection notification message is generated based on the target access device marking record, the secure socket connection establishment record, the chassis reset interruption status record, and the second physical isolation domain cleanup completion record. The session abnormal disconnection notification message includes a process task identifier code, an interruption reason field, a resource cleanup status field, and a connection termination field. The interruption reason field is derived from the chassis reset interruption status record, the resource cleanup status field is derived from the second physical isolation domain cleanup completion record, and the connection termination field is used to instruct the target access device to stop sending pending calculation instruction data to the second physical isolation domain.

[0116] Preferably, after the session abnormal disconnection notification message is generated, the end-to-end communication symmetric key is invoked based on the key index in the secure socket connection establishment record, and the session abnormal disconnection notification message is encrypted and encapsulated using the end-to-end communication symmetric key to form a session abnormal disconnection ciphertext message. The session abnormal disconnection ciphertext message is sent to the target access device through the computing power sharing communication node, enabling the target access device to receive the interruption status notification corresponding to the chassis reset interruption condition in the current access session. After the computing power sharing communication node sends the session abnormal disconnection ciphertext message, it generates a session abnormal disconnection sending record. The session abnormal disconnection sending record is used to indicate that the session abnormal disconnection notification message has been sent to the target access device through the encrypted transmission channel corresponding to the secure socket connection. The session abnormal disconnection sending record continues to be associated and stored with the chassis reset interruption status record and the second physical isolation domain cleanup completion record, so as to distinguish between new access sessions and disconnected access sessions when re-entering the stopped computing power open condition determination.

[0117] Preferably, in one scenario, when the vehicle is in a stationary computing power open state and the second physical isolation domain is executing video rendering-type pending computational instructions issued by the target access device, the underlying hardware daemon continuously reads vehicle braking trigger signals, ignition wake-up signals, gear release request signals, electronic parking brake release request signals, and chassis controller wake-up request signals from the real-time vehicle chassis signal sampling record. If the chassis control action level corresponding to the vehicle braking trigger signal meets the hardware wake-up threshold, the underlying hardware daemon generates a chassis reset interrupt status record based on the chassis control action level, and generates a hardware interrupt request instruction based on the chassis reset interrupt status record. After the hardware interrupt request instruction enters the second physical isolation domain via the interrupt delivery queue of the second physical isolation domain, the second physical isolation domain terminates the running logical operation based on the task running index record and the second physical isolation domain task routing record, and clears the system hardware resources occupied by the second physical isolation domain based on the second physical isolation domain access boundary record. Subsequently, the computing power sharing communication node sends the session abnormal disconnection notification message to the target access device, extending the interrupt blocking logic triggered by the chassis reset interrupt condition from the underlying signal judgment, hardware interrupt request instruction issuance, logical operation termination, and system hardware resource cleanup to the target access device notification.

[0118] Optionally, the step of transmitting the target computation result data segment to the target access device includes: Read the target storage path description string carried in the computation instruction data to be processed, and use it as the destination address for data transmission; The end-to-end communication symmetric key within the vehicle-mounted safety computing environment is invoked, and the end-to-end communication symmetric key is used to perform a cryptographic encryption operation on the target computation result data segment to generate a ciphertext payload data block. The encrypted payload data block and the target storage path description string are encapsulated into a standard transport protocol data packet; The standard transmission protocol data packet is pushed to the target access device through the computing power sharing communication node to complete the transmission of the target computation result data segment to the target access device; The target access device is triggered to store the decrypted ciphertext payload data block into the physical storage sector corresponding to the target storage path description string.

[0119] Preferably, the specific implementation process of transmitting the target computation result data segment to the target access device is as follows: After the target computation result data segment is generated, the pending computation instruction data parsing record, the target access device marking record, the secure socket connection establishment record, and the second physical isolation domain result pending return status record are read first. The pending computation instruction data parsing record is used to provide the result return description field, process task identifier code, and task fragmentation order field in the pending computation instruction data. The target access device marking record is used to confirm that the target computation result data segment should be returned to the target access device that has passed the identity credential sequence verification. The secure socket connection establishment record is used to provide the connection validity timing field and key index corresponding to the current access session. The second physical isolation domain result pending return status record is used to indicate that the target computation result data segment is still in the result splicing buffer or temporary buffer area that is allowed to be accessed in the second physical isolation domain, and is used to trigger the data cleanup process corresponding to the process task identifier code after the target computation result data segment is returned. Through the above record reading, the return process of the target operation result data segment can maintain a corresponding relationship with the task source of the computation instruction data to be processed, the current access session, and the result splicing cache area or temporary cache area in the second physical isolation domain.

[0120] Preferably, when reading the target storage path description string carried in the computation instruction data to be processed, the result return description field is first located according to the parsing record of the computation instruction data to be processed, and then the target storage path description string is read from the result return description field. The target storage path description string is used to describe the storage location description of the target access device side for receiving the target operation result data segment. The target storage path description string includes the storage partition identifier, directory location identifier, result file name identifier, and write method identifier of the target access device side. After the target storage path description string is read, it is written into the result return path record. The result return path record is used to receive the target storage path description string in the result return description field and continue to participate in the subsequent path boundary verification, standard transmission protocol data packet encapsulation, and target access device side storage write process, so that the target operation result data segment is not retained locally by the vehicle, but is transmitted according to the return location carried by the target access device in the computation instruction data to be processed.

[0121] Preferably, before using the target storage path description string as the destination address for data transmission, a path boundary check is performed on the target storage path description string based on the result return path record to form a target storage path description string check record. The path boundary check is used to determine whether the target storage path description string corresponds to the storage range within which the target access device is allowed to receive data, and whether the target storage path description string matches the session permission field in the target access device tag record. If the target storage path description string check record indicates that the path boundary check passed, the target storage path description string is written into the result return destination record; if the target storage path description string check record indicates that the path boundary check failed, a default target storage path description string is generated based on the target access device tag record, and the default target storage path description string is written into the result return destination record. The result return destination record continues to serve as the destination address in the standard transmission protocol data packet, preventing the target computation result data segment from being written to a storage location that does not correspond to the current access session.

[0122] Preferably, when invoking the end-to-end communication symmetric key within the vehicle-mounted secure computing environment, the key index in the secure socket connection establishment record is first read, and then the end-to-end communication symmetric key corresponding to the current access session is located in the vehicle-mounted secure computing environment based on the key index. The vehicle-mounted secure computing environment is provided by the key retrieval space of the vehicle-mounted secure encryption chip. The end-to-end communication symmetric key is formed within the vehicle-mounted secure computing environment and corresponds to the session context formed when the target access device establishes the secure socket connection. The end-to-end communication symmetric key is not written in plaintext to the temporary buffer area of ​​the second physical isolation domain; instead, the vehicle-mounted secure computing environment performs encryption encapsulation on the data to be sent. After the end-to-end communication symmetric key is located, an end-to-end communication symmetric key retrieval record is formed. This record continues to participate in subsequent cryptographic encryption operations, ensuring a one-to-one correspondence between the return process of the target computation result data segment and the current access session.

[0123] Preferably, when performing cryptographic encryption on the target computation result data segment using the end-to-end communication symmetric key, the end-to-end communication symmetric key is first called to confirm its correspondence with the current access session. Then, the target computation result data segment is read from the result concatenation buffer area indicated by the result pending return status record of the second physical isolation domain according to the process task identifier code. A result segment boundary check is performed on the target computation result data segment to form a target computation result data segment boundary check record. This record is used to determine whether the target computation result data segment originates from the same computation buffer output data block corresponding to the process task identifier code, and whether the target computation result data segment has passed the result format check corresponding to the target computation result candidate data segment check record. If the target computation result data segment boundary check record indicates that the result segment boundary check has passed, the target computation result data segment is sent to the vehicle-mounted secure computing environment, and the cryptographic encryption operation is performed on the target computation result data segment using the end-to-end communication symmetric key to generate a ciphertext payload data block. The encrypted payload data block is used to carry the encrypted target computation result data segment and continues to participate in the subsequent standard transmission protocol data packet encapsulation process.

[0124] Preferably, after generating the encrypted payload data block, the encrypted payload data block is associated with the process task identifier code, the task fragmentation order field, and the result return destination record corresponding to the target operation result data segment to form an encrypted payload data block association record. The encrypted payload data block association record is used to indicate which of the pending computation instruction data the encrypted payload data block originates from, which of the target operation result data segments it corresponds to, and which target storage path description string it should be returned to. The encrypted payload data block association record continues to participate in the standard transmission protocol data packet encapsulation, ensuring a continuous correspondence between the payload field, task identifier field, and destination address field in the standard transmission protocol data packet.

[0125] Preferably, when encapsulating the encrypted payload data block and the target storage path description string into a standard transport protocol data packet, the associated record of the encrypted payload data block, the result return destination record, and the secure socket connection establishment record are read first. Then, the encrypted payload data block is written into the payload field of the standard transport protocol data packet, the target storage path description string is written into the destination address field of the standard transport protocol data packet, the process task identifier is written into the task identifier field of the standard transport protocol data packet, and the connection validity timing field is written into the timing constraint field of the standard transport protocol data packet. The payload field carries the encrypted target computation result data segment, the destination address field carries the target storage path description string, the task identifier field enables the target access device to identify the pending computation instruction data corresponding to the standard transport protocol data packet, and the timing constraint field restricts the standard transport protocol data packet to be received only within the valid access timing of the current access session. Through the above encapsulation, the standard transport protocol data packet simultaneously carries the encrypted target computation result data segment, the target storage path description string, the process task identifier, and the connection validity timing field.

[0126] Preferably, after the standard transmission protocol data packet is formed, a transmission consistency check is performed on the standard transmission protocol data packet to form a standard transmission protocol data packet check record. The transmission consistency check is used to determine whether the encrypted payload data block in the standard transmission protocol data packet originates from the target computation result data segment, and to determine whether the target storage path description string in the standard transmission protocol data packet originates from the result feedback description field or the default target storage path description string in the computation instruction data to be processed. If the standard transmission protocol data packet check record indicates that the transmission consistency check has passed, the standard transmission protocol data packet is written into the computing power sharing communication node's sending queue; if the standard transmission protocol data packet check record indicates that the transmission consistency check has failed, the encrypted payload data block association record and the result feedback destination record are reread to repackage the standard transmission protocol data packet. The computing power sharing communication node's sending queue continues to be used by the computing power sharing communication node to push the standard transmission protocol data packet to the target access device.

[0127] Preferably, when the standard transmission protocol data packet is pushed to the target access device through the computing power sharing communication node, the secure socket connection is first confirmed to be within the valid access time sequence defined by the connection validity time sequence field based on the secure socket connection establishment record. Then, the target access device is confirmed to be the recipient of the standard transmission protocol data packet based on the target access device marking record. After confirmation, the computing power sharing communication node reads the standard transmission protocol data packet from the computing power sharing communication node's sending queue and pushes the standard transmission protocol data packet to the target access device through the secure socket connection to form a standard transmission protocol data packet sending record. The standard transmission protocol data packet sending record is used to indicate that the target computation result data segment has left the vehicle-side temporary buffer area in the form of the encrypted payload data block and continues to participate in the subsequent second physical isolation domain temporary buffer area cleanup process.

[0128] Preferably, after receiving the standard transport protocol data packet, the target access device first parses the standard transport protocol data packet within the session context corresponding to the current access session to read the payload field, the destination address field, the task identifier field, and the timing constraint field. The target access device determines whether the standard transport protocol data packet is within the valid access timing of the current access session based on the timing constraint field, and matches the standard transport protocol data packet with the pending calculation instruction data previously issued by the target access device based on the task identifier field to form a standard transport protocol data packet reception verification record. If the standard transport protocol data packet reception verification record indicates that the standard transport protocol data packet passes the timing constraint field verification and the task identifier field correspondence verification, the target access device reads the encrypted payload data block in the payload field and the target storage path description string in the destination address field. The encrypted payload data block and the target storage path description string continue to participate in the decryption and storage writing process on the target access device side.

[0129] Preferably, when the target access device is triggered to store the decrypted ciphertext payload data block into the physical storage sector corresponding to the target storage path description string, the target access device first decrypts the ciphertext payload data block within the session context corresponding to the current access session to restore the decrypted ciphertext payload data block into the target computation result data segment. Subsequently, the target access device generates a physical storage sector location record based on the target storage path description string. This physical storage sector location record describes the storage partition, directory location, and physical storage sector corresponding to the target storage path description string. The target access device then writes the target computation result data segment into the physical storage sector based on the physical storage sector location record, forming a target computation result data segment storage record. This target computation result data segment storage record indicates that the target computation result data segment has been written to the storage location on the target access device side according to the target storage path description string.

[0130] Preferably, after the target computation result data segment storage record is formed, the target access device further generates a result reception confirmation message and sends the result reception confirmation message to the computing power sharing communication node through the secure socket connection. The result reception confirmation message includes the process task identifier, the target storage path description string, and the target computation result data segment storage status field; the target computation result data segment storage status field is used to indicate whether the target computation result data segment has been written to the physical storage sector. After receiving the result reception confirmation message, the computing power sharing communication node writes the result reception confirmation message into the result return completion record. The result return completion record continues to participate in the temporary cache area cleanup in the second physical isolation domain, so that after the vehicle side confirms that the target access device has completed the storage write, it can release the result splicing cache area and the data content corresponding to the process task identifier in the temporary cache area.

[0131] Preferably, after forming the result return completion record, the second physical isolation domain reads the result pending return status record of the second physical isolation domain according to the process task identifier code, and cleans up the data content corresponding to the target operation result data segment in the result splicing buffer area and the temporary buffer area according to the result pending return status record of the second physical isolation domain, so as to form a target operation result data segment cleanup record. The target operation result data segment cleanup record is used to indicate that the vehicle side will no longer retain the target operation result data segment and the encrypted payload data block. The target operation result data segment cleanup record is also associated with the standard transmission protocol data packet sending record, the result reception confirmation message and the result return completion record, so that only the transmission status is retained in the future, and the calculation content of the target operation result data segment is not retained. Through the above cleanup process, the storage location of the target operation result data segment is limited to the physical storage sector corresponding to the target storage path description string on the target access device side.

[0132] Preferably, in one scenario, when the target access device is a laptop and the computational instruction data to be processed is video rendering type computational instruction data, the result return description field in the computational instruction data to be processed carries the target storage path description string. After the second physical isolation domain generates the target computation result data segment, it first forms the result return destination record according to the target storage path description string, and then uses the end-to-end communication symmetric key to perform the cryptographic encryption operation on the target computation result data segment to generate the ciphertext payload data block. The ciphertext payload data block and the target storage path description string are jointly encapsulated into the standard transmission protocol data packet, and pushed to the target access device by the computing power sharing communication node through the secure socket connection. After receiving the standard transmission protocol data packet, the target access device restores the decrypted ciphertext payload data block to the target computation result data segment, and writes the target computation result data segment into the physical storage sector corresponding to the target storage path description string. The above processing ensures that the generation, encryption, encapsulation, transmission, decryption, and storage of the target operation result data segment all revolve around the same process task identifier, the same secure socket connection, and the same target storage path description string.

[0133] like Figure 3 The image shows an embodiment of this application of a device for opening up idle computing power of parked vehicles to personal devices. The device includes: The data acquisition module is used to collect the current powertrain status data and the current chassis parking status data of the vehicle. The node activation module is used to activate the computing power sharing communication node when the current powertrain status data and the current chassis parking status data meet the parking computing power opening conditions. The isolation domain establishment module is used to establish a first physical isolation domain and a second physical isolation domain within the vehicle computing platform. The monitoring module is used to run a low-level hardware daemon process in the first physical isolation domain and to continuously collect real-time vehicle chassis signals using the low-level hardware daemon process. The verification and authentication module is used to receive the identity credential sequence of external devices through the computing power sharing communication node, and to verify the identity credential sequence to determine the target access device; The resource announcement module is used to send a list of available computing resources to the target access device. The task receiving module is used to receive the unprocessed calculation instruction data sent by the target access device; The collaborative computing module is used to perform logical operations on the computation instruction data to be processed in the second physical isolation domain and generate a target computation result data segment when the real-time vehicle chassis signal does not trigger the chassis reset interruption condition. The data return module is used to transmit the target calculation result data segment to the target access device.

[0134] like Figure 4 As shown, this is an embodiment of an electronic device according to this application. The electronic device includes: Memory, used to store computer programs; A processor, when executing the computer program stored in the memory, implements the steps of a method for opening up idle computing power of parked vehicles to personal devices as described in any one of this application.

[0135] like Figure 5 As shown, this is an embodiment of a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the method for opening up idle computing power of parked vehicles to personal devices as described in any one of this applications.

[0136] like Figure 6 As shown, this is a vehicle according to an embodiment of the present application, the vehicle comprising: An in-vehicle computing platform, wherein the in-vehicle computing platform is configured with a first processor hardware area and a second processor hardware area; A communication bus connects the on-board computing platform and the vehicle chassis sensors, and is used to transmit current powertrain status data, current chassis parking status data, and real-time vehicle chassis signals. A computing power sharing communication node, which is connected to the vehicle-mounted computing platform, is used to establish a radio frequency communication link with external devices; The in-vehicle computing platform is configured as follows: The system determines whether the conditions for opening up parking computing power are met based on the data transmitted through the communication bus. If the conditions are met, the computing power sharing communication node is activated. A first physical isolation domain is constructed within the first processor hardware area to run a low-level hardware daemon process to monitor the real-time vehicle chassis signals through the communication bus. A second physical isolation domain is constructed within the second processor hardware area to perform logical operations on the unprocessed computing instruction data of the target access device obtained through the computing power sharing communication node, and to generate a target computing result data segment. When the real-time vehicle chassis signal triggers the chassis reset interrupt condition, the computing process in the second physical isolation domain is forcibly terminated by a hardware interrupt instruction to ensure the rollback priority of basic driving functions.

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

Claims

1. A method for opening up idle computing power of parked vehicles to personal devices, characterized in that, The method for opening up idle computing power of parked vehicles to personal devices includes the following steps: Collect the current powertrain status data and the current chassis parking status data of the vehicle; if the current powertrain status data and the current chassis parking status data meet the parking computing power opening conditions, activate the computing power sharing communication node; A first physical isolation domain and a second physical isolation domain are established within the vehicle computing platform; a low-level hardware daemon process is run in the first physical isolation domain to continuously collect real-time vehicle chassis signals. The computing power sharing communication node receives the identity credential sequence of external devices, verifies the identity credential sequence to determine the target access device, and sends the available computing power resource status list to the target access device. The system receives the pending calculation instruction data issued by the target access device; if the real-time vehicle chassis signal does not trigger the chassis reset interruption condition, it performs logical operation on the pending calculation instruction data in the second physical isolation domain to generate a target calculation result data segment, and transmits the target calculation result data segment to the target access device.

2. The method for opening up idle computing power of parked vehicles to personal devices as described in claim 1, characterized in that, The step of activating the computing power sharing communication node if the current powertrain status data and the current chassis parking status data meet the parking computing power opening conditions includes: Extract the current wheel speed sensor pulse count value from the current powertrain status data; Extract the current drive motor operating current value from the current powertrain status data; Extract the current gear mechanical lock status bit from the current chassis parking status data; Extract the current electronic parking caliper lock flag from the current chassis parking status data; The extracted current wheel speed sensor pulse count value, current drive motor operating current value, current gear mechanical lock status bit, and current electronic parking caliper lock flag bit are used as the logical basis for determining the parking computing power opening condition. If the current wheel speed sensor pulse count value is equal to zero, the current drive motor operating current value is equal to zero, the current gear mechanical lock state is in the locked state, and the current electronic parking caliper lock flag is in the set state, it is determined that the parking computing power opening condition is met. A node wake-up interrupt signal is generated, and a working voltage is provided to the computing power sharing communication node in the dormant state according to the node wake-up interrupt signal to activate the computing power sharing communication node.

3. The method for opening up idle computing power of parked vehicles to personal devices as described in claim 1, characterized in that, The steps of establishing the first physical isolation domain and the second physical isolation domain within the vehicle-mounted computing platform include: Collect the current remaining power battery charge value of the vehicle, and calculate the total upper limit of available resources based on the current remaining power battery charge value; Read the pre-burned system base configuration file and extract the factory-set basic driving core retention count from it; The total number of available physical cores of the vehicle computing platform is subtracted from the number of basic driving reserved cores to obtain the total number of remaining idle cores, and the total number of remaining idle cores is used as a reference benchmark for resource allocation. If the total limit of available resources is less than the total number of remaining idle cores, the total limit of available resources will be set as the target number of open computing cores. If the total upper limit of the available resources is not less than the total number of remaining idle cores, the total number of remaining idle cores is set as the target number of open computing cores; The first processor hardware region is allocated according to the number of basic driving cores, and the first physical isolation domain is constructed using the first processor hardware region. The second processor hardware space is allocated according to the target number of open computing cores, and the second physical isolation domain is constructed using the second processor hardware space to complete the establishment of the first physical isolation domain and the second physical isolation domain within the vehicle computing platform.

4. The method for opening up idle computing power of parked vehicles to personal devices as described in claim 1, characterized in that, The step of receiving the identity credential sequence of an external device through the computing power sharing communication node and verifying the identity credential sequence to determine the target access device includes: The computing power sharing communication node receives the initial handshake message broadcast by the external device and extracts the device's physical hardware address and the identity credential sequence from it. The system calls the pre-stored authorized binding whitelist record table in the vehicle security encryption chip, using the device's physical hardware address and the identity credential sequence as the query index; Check the authorized binding whitelist record table to see if there is a matching record entry; If a matching record is found, the identity credential sequence is verified and a secure socket connection is established with the external device through the computing power sharing communication node. The external device that successfully establishes the secure socket connection is marked as the target access device to identify the target access device.

5. The method for opening up idle computing power of parked vehicles to personal devices as described in claim 1, characterized in that, The step of sending the available computing power resource status list to the target access device includes: Traverse the currently unoccupied computing hardware clusters mounted within the second physical isolation domain; The statistics include the number of available threads of general-purpose processors, the number of available rendering pipelines of graphics accelerators, and the number of available multiply-accumulators of tensor processing units within the currently unused computing hardware clusters. The statistically obtained values ​​are encapsulated into a hardware resource status structure, and the hardware resource status structure is set as the available computing power resource status list. The available computing power resource status list is transmitted to the target access device through the computing power sharing communication node, so as to send the available computing power resource status list to the target access device.

6. The method for opening up idle computing power of parked vehicles to personal devices as described in claim 1, characterized in that, The step of performing logical operations on the computation instruction data to be processed in the second physical isolation domain to generate the target computation result data segment includes: Parse the header control field of the computation instruction data to be processed, and read the instruction computation type identifier code from it; According to the instruction calculation type identifier code, the computing hardware is matched in the second physical isolation domain, and the computing instruction data to be processed is routed to the matched hardware execution unit; If the instruction calculation type identifier is a tensor matrix multiplication identifier, the tensor processing unit in the second physical isolation domain can use a multiply-accumulator to perform the logical operation. If the instruction calculation type identifier is a pixel rasterization calculation identifier, the logical operation can be performed by the graphics accelerator in the second physical isolation domain using the rendering pipeline. Collect the operation cache output data block generated by the logical operation, and concatenate and combine the operation cache output data block to generate the target operation result data segment.

7. The method for opening up idle computing power of parked vehicles to personal devices as described in claim 1, characterized in that, After the step of receiving the computational instruction data to be processed issued by the target access device, the method further includes: Extract the process task identifier and the total number of instructions from the computation instruction data to be processed; Real-time statistics are performed on the number of currently consumed instructions that have been completed by the second physical isolation domain for the computation instruction data to be processed; Calculate the progress percentage based on the current number of consumed instructions and the total number of instructions; Obtain the video memory address pointer of the vehicle cockpit domain controller, and write the process task identifier code and the progress percentage value into the physical video memory mapping area corresponding to the video memory address pointer. The cockpit LCD display panel is triggered to read the values ​​in the physical memory mapping area and refresh the display progress graphic component elements to provide feedback on the execution progress of the pending calculation instruction data through the vehicle's local hardware.

8. The method for opening up idle computing power of parked vehicles to personal devices as described in claim 1, characterized in that, The steps of the underlying hardware daemon process continuously collecting real-time vehicle chassis signals and determining whether the chassis reset interrupt condition is triggered include: The underlying hardware daemon process is used to extract chassis control action levels from the real-time vehicle chassis signals collected in real time. The extracted chassis control action level is compared with a preset hardware wake-up threshold. If the chassis control action level meets the hardware wake-up threshold, it is determined that the chassis reset interrupt condition is triggered. When the chassis reset interrupt condition is triggered, a hardware interrupt request instruction with the highest priority is sent to the second physical isolation domain; The hardware interrupt request instruction is used to forcibly terminate all logical operations running within the second physical isolation domain. Clear the system hardware resources occupied by the second physical isolation domain and send a session abnormal disconnection notification message to the target access device to execute the interrupt blocking logic when the chassis reset interrupt condition is triggered.

9. The method for opening up idle computing power of parked vehicles to personal devices as described in claim 1, characterized in that, The step of transmitting the target computation result data segment to the target access device includes: Read the target storage path description string carried in the computation instruction data to be processed, and use it as the destination address for data transmission; The end-to-end communication symmetric key within the vehicle-mounted safety computing environment is invoked, and the end-to-end communication symmetric key is used to perform a cryptographic encryption operation on the target computation result data segment to generate a ciphertext payload data block. The encrypted payload data block and the target storage path description string are encapsulated into a standard transport protocol data packet; The standard transmission protocol data packet is pushed to the target access device through the computing power sharing communication node to complete the transmission of the target computation result data segment to the target access device; The target access device is triggered to store the decrypted ciphertext payload data block into the physical storage sector corresponding to the target storage path description string.

10. A device for opening up idle computing power of parked vehicles to personal devices, characterized in that, The device that allows idle computing power from parked vehicles to be accessed by personal devices includes: The data acquisition module is used to collect the current powertrain status data and the current chassis parking status data of the vehicle. The node activation module is used to activate the computing power sharing communication node when the current powertrain status data and the current chassis parking status data meet the parking computing power opening conditions. The isolation domain establishment module is used to establish a first physical isolation domain and a second physical isolation domain within the vehicle computing platform. The monitoring module is used to run a low-level hardware daemon process in the first physical isolation domain and to continuously collect real-time vehicle chassis signals using the low-level hardware daemon process. The verification and authentication module is used to receive the identity credential sequence of external devices through the computing power sharing communication node, and to verify the identity credential sequence to determine the target access device; The resource announcement module is used to send a list of available computing resources to the target access device. The task receiving module is used to receive the unprocessed calculation instruction data sent by the target access device; The collaborative computing module is used to perform logical operations on the computation instruction data to be processed in the second physical isolation domain and generate a target computation result data segment when the real-time vehicle chassis signal does not trigger the chassis reset interruption condition. The data return module is used to transmit the target calculation result data segment to the target access device.

11. An electronic device, characterized in that, The electronic device includes: Memory, used to store computer programs; When a processor executes the computer program stored in the memory, it implements the steps of the method for opening up idle computing power of parked vehicles to personal devices as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method for opening up idle computing power of parked vehicles to personal devices as described in any one of claims 1 to 9.

13. A vehicle, characterized in that, The vehicles include: An in-vehicle computing platform, wherein the in-vehicle computing platform is configured with a first processor hardware area and a second processor hardware area; A communication bus connects the on-board computing platform and the vehicle chassis sensors, and is used to transmit current powertrain status data, current chassis parking status data, and real-time vehicle chassis signals. A computing power sharing communication node, which is connected to the vehicle-mounted computing platform, is used to establish a radio frequency communication link with external devices; The in-vehicle computing platform is configured as follows: The system determines whether the conditions for opening up parking computing power are met based on the data transmitted through the communication bus. If the conditions are met, the computing power sharing communication node is activated. A first physical isolation domain is constructed within the first processor hardware area to run a low-level hardware daemon process to monitor the real-time vehicle chassis signals through the communication bus. A second physical isolation domain is constructed within the second processor hardware area to perform logical operations on the unprocessed computing instruction data of the target access device obtained through the computing power sharing communication node, and to generate a target computing result data segment. When the real-time vehicle chassis signal triggers the chassis reset interrupt condition, the computing process in the second physical isolation domain is forcibly terminated by a hardware interrupt instruction to ensure the rollback priority of basic driving functions.

Images