Emergency vehicle computing power requisition and scheduling method and device, electronic equipment, computer readable storage medium, vehicle and system

Abstract

The application provides an emergency vehicle computing power requisition and scheduling method, device, electronic equipment, computer readable storage medium, vehicle and system. The method acquires trigger signaling containing a hierarchical authorization token and verifies it to establish instruction issuing authority for the corresponding level; broadcasts a scheduling request to vehicle nodes in a target area, and filters candidate nodes according to parking prediction parameters; locks associated basic hardware resources of a driving control system, and encapsulates un-locked available hardware resources to form a computing resource pool; distributes to-be-processed tasks based on available hardware resources and geographic distance indicators, so that the tasks run in volatile memory; and terminates the tasks and releases the resources when the hardware running state parameters meet blocking conditions or communication is disconnected.

Description

Technical Field

[0001] This application relates to the fields of vehicle networking, vehicle computing, and emergency dispatch technology. Specifically, it relates to an emergency vehicle computing power requisition and dispatch method, device, electronic device, computer-readable storage medium, vehicle, and system. Background Technology

[0002] In emergency scenarios such as natural disasters, traffic accidents, and urban public safety incidents, a large amount of data awaiting processing is typically generated on-site, including video images, sensor data, communication messages, and event evolution analysis data. This type of data processing has significant regional, sudden, and low-latency requirements, placing high demands on the computing power, communication stability, and task exit mechanisms in the vicinity of the incident site.

[0003] In one existing type of emergency data processing solution, fixed edge servers are typically deployed along urban roads, with the emergency command center centrally accessing data such as video, sensor, and communication messages. The fixed edge servers divide computing instances based on pre-defined capacity, queue and process the uploaded data, and then transmit the processing results back to the command center or field terminals. This solution's computing power supply relies primarily on pre-built fixed sites and central servers, and its scheduling scope, processing capacity, and fault recovery capabilities are all constrained by existing infrastructure.

[0004] However, when fixed infrastructure in the emergency response area is damaged, communication load surges, or fixed edge server capacity is insufficient, existing solutions struggle to quickly establish scalable temporary computing capacity near the event site. Furthermore, existing solutions lack a unified task removal and resource recovery mechanism for changes in the operational status of temporary participating terminals, link anomalies, and core function isolation. This can easily lead to computing tasks running continuously in unstable environments, impacting the continuity of emergency data processing, the efficiency of on-site resource utilization, and the operational security of critical terminal functions. Summary of the Invention

[0005] This application provides an emergency vehicle-mounted computing power requisition and dispatch method, apparatus, electronic device, computer-readable storage medium, vehicle, and system to at least alleviate the aforementioned technical problems.

[0006] An emergency vehicle-mounted computing power requisition and scheduling method includes: Obtain the trigger signaling containing the hierarchical authorization token, perform a verification operation on the hierarchical authorization token, and establish the corresponding level of instruction issuance permission after successful verification; After the authorization to issue the command is established, a scheduling request is broadcast to the vehicle nodes in the target area to obtain the parking prediction parameters of the vehicle nodes. The vehicle nodes whose parking prediction parameters meet the minimum parking time corresponding to the scheduling request are identified as candidate nodes. Locking processing is performed on the basic hardware resources associated with the vehicle control system in the candidate nodes. Under the condition that the basic hardware resources are kept locked, the unlocked available hardware resources in the candidate nodes are extracted, and the available hardware resources are encapsulated into a resource pool to obtain a computing resource pool for carrying the task to be processed. Based on the available hardware resources and geographical distance indicators of each candidate node in the computing resource pool, the task to be processed is assigned to the candidate node, the task to be processed is instructed to reside and run in the volatile memory of the candidate node, and the task to be processed occupies the corresponding available hardware resources in the computing resource pool. Monitor the hardware operating status parameters and communication connection parameters of the candidate node. When the hardware operating status parameters meet the blocking conditions or the communication connection parameters indicate a disconnection, terminate the current task process of the candidate node and release the available hardware resources occupied by the current task process.

[0007] Optionally, the step of performing a verification operation on the hierarchical authorization token, and establishing the corresponding level of instruction issuance permission after successful verification, includes: Identify the level identifier from the hierarchical authorization token contained in the triggering signaling, and use the level identifier as the basis for determining the permission level of the corresponding level; In response to the level identifier pointing to the first set level, the cryptographic verification unit is invoked to verify the signature data of the hierarchical authorization token, and the signature verification operation in the verification operation is executed; Extract the issuance timestamp embedded in the hierarchical authorization token, determine the time interval between the issuance timestamp and the current system time, and perform the timestamp comparison operation in the verification operation; When the signature data is verified and the time interval is within the specified valid duration range corresponding to the hierarchical authorization token, it is determined that the hierarchical authorization token has been verified, the instruction issuance permission matching the first set level is activated, and the instruction issuance permission of the second set level is refused to be assigned to the trigger signaling carrying the first set level. The permission range of the second set level exceeds the permission range of the first set level.

[0008] Optionally, after the instruction issuance permission is established, broadcasting a scheduling request to the vehicle nodes within the target area, obtaining the parking prediction parameters of the vehicle nodes, and determining the vehicle nodes whose parking prediction parameters meet the minimum parking duration corresponding to the scheduling request as candidate nodes includes: After the permission to issue the instruction is established, the geographical boundary coordinates of the target area are defined, and all online vehicle nodes within the geographical boundary coordinates are identified as the broadcast objects of the scheduling request. The scheduling request is pushed to all online vehicle nodes within the geographical boundary coordinates by the vehicle network communication base station, so that the online vehicle nodes return the dwell status prediction data corresponding to the scheduling request; Receive the dwell status prediction data returned by the online vehicle node in response to the scheduling request, and parse the dwell prediction parameters based on the dwell status prediction data; Determine the minimum dwell time corresponding to the scheduling request, compare the dwell prediction parameter with the minimum dwell time, filter out the online vehicle nodes whose dwell prediction parameter reaches the minimum dwell time, and determine the filtered online vehicle nodes as the candidate nodes.

[0009] Optionally, the locking process is performed on the basic hardware resources associated with the vehicle control system in the candidate nodes. While the basic hardware resources remain locked, the unlocked available hardware resources within the candidate nodes are extracted, and these available hardware resources are encapsulated into a resource pool to obtain a computing resource pool for carrying the task to be processed, including: Based on the basic hardware resources associated with the vehicle control system in the candidate nodes, a resource whitelist policy is issued to the candidate nodes. The resource whitelist policy contains the processing core identifiers assigned to the autonomous driving assistance module, braking control module and steering control module. The alternative node is instructed to block the access path of external instructions to the computing unit pointed to by the processing core identifier through the operating system kernel, and to complete the locking process of the basic hardware resources associated with the driving control system based on the resource whitelist policy. After the basic hardware resources associated with the driving control system have completed the locking process and remain locked, the idle processing cores and idle video memory units that are not locked in the candidate nodes are scanned, and the idle processing cores and idle video memory units are identified as the available hardware resources. The available hardware resources provided by multiple candidate nodes are mapped to a uniformly addressed computing resource pool through a distributed computing middleware, thereby completing the resource pool encapsulation process of the available hardware resources, so that the computing resource pool contains only the available hardware resources that are not locked and are used to carry the task to be processed.

[0010] Optionally, the step of allocating the task to be processed to the candidate nodes based on the available hardware resources and geographical distance indicators corresponding to each candidate node in the computing resource pool, instructing the task to be processed to reside and run in the volatile memory of the candidate node, and causing the task to be processed to occupy the corresponding available hardware resources in the computing resource pool, includes: Identify the service type of the task to be processed, determine that the task to be processed belongs to one of the service types in image data structured analysis, communication message relay forwarding and diffusion evolution trend inference, and use the service type as the basis for the task category of the task to be processed. Read the available hardware resources corresponding to each of the candidate nodes from the computing resource pool, and use the available hardware resources as candidate carrier resources for the task to be processed; Obtain the current location coordinate system of the candidate node, take the current location coordinate system and the event source coordinate system as the distance calculation object, determine the spatial straight-line distance between the current location coordinate system and the event source coordinate system, and take the spatial straight-line distance as the geographic distance index; An allocation sequence is established according to the geographical distance index in ascending order, and the candidate nodes for undertaking the task to be processed are determined based on the allocation sequence and the candidate carrying resources. The execution code of the task to be processed is pushed to the candidate node at the front of the sequence in sequence, so that the task to be processed is assigned to the candidate node and the task to be processed occupies the available hardware resources corresponding to the candidate node in the computing resource pool. The alternative node is controlled to directly write the data stream of the task to be processed into the random access memory, which serves as the volatile memory, so that the task to be processed resides and runs in the volatile address space corresponding to the random access memory. After the data stream is processed and a result message is generated, the volatile address space corresponding to the random access memory is cleared, and writing any segmented data of the data stream to the non-volatile disk drive is prohibited.

[0011] Optionally, the hardware operating status parameters include power battery state of charge parameters, battery pack physical surface temperature parameters, and vehicle spatial displacement parameters; monitoring the hardware operating status parameters of the candidate node, and terminating the current task process of the candidate node and releasing the available hardware resources occupied by the current task process when the hardware operating status parameters meet the blocking conditions, includes: During the current task process of the candidate node, the power battery state of charge parameters, battery pack physical surface temperature parameters, and vehicle spatial displacement parameters of the candidate node are periodically collected to monitor the hardware operating status parameters of the candidate node. The power battery state of charge parameters are compared with the power battery state of charge critical ratio point. When the power battery state of charge parameters drop to the power battery state of charge critical ratio point, the first blocking condition is triggered. The physical surface temperature parameter of the battery pack is compared with the critical heat value of the physical surface temperature of the battery pack. When the physical surface temperature parameter of the battery pack rises to the critical heat value of the physical surface temperature of the battery pack, the second blocking condition is triggered. Based on the vehicle spatial displacement parameters, it is determined whether the candidate node has undergone physical position movement. When the vehicle spatial displacement parameters indicate that the vehicle has undergone physical position movement, the third blocking condition is triggered. When any one of the first blocking condition, the second blocking condition, and the third blocking condition is triggered, it is determined that the hardware operating status parameters meet the blocking condition, a process destruction instruction is issued to the system kernel of the alternative node to terminate the current task process and release the available hardware resources occupied by the current task process.

[0012] Optionally, monitoring the communication connection parameters of the candidate node, and terminating the current task process of the candidate node and releasing the available hardware resources occupied by the current task process when the communication connection parameters indicate a disconnection, includes: During the period when the alternative node executes the task to be processed, a heartbeat detection data packet exchange mechanism is established between the alternative node and the alternative node, and the communication connection parameters of the alternative node are monitored through the heartbeat detection data packet exchange mechanism. Continuously monitor the round-trip delay data of the heartbeat detection data packets and use the round-trip delay data as the communication connection parameter; If the duration of not receiving the heartbeat detection data packet returned by the alternative node exceeds the disconnection duration red line corresponding to the heartbeat detection data packet exchange mechanism, the communication connection parameter is determined to indicate a disconnection. Send a sleep signal to the virtual computing container mounted on the alternative node whose communication connection parameters indicate that the connection has been disconnected. The virtual computing container is used to carry the current task process and the available hardware resources occupied by the current task process. Based on the hibernation signaling, the current context state of the virtual computing container is frozen, the current task process is terminated, and the available hardware resources occupied by the current task process are released.

[0013] Optionally, the method further includes: If the level identifier in the hierarchical authorization token points to the regular emergency response level as the first set level, determine that the instruction issuance permission corresponding to the trigger signaling is the regular emergency response level permission, and open the external interrupt trigger port of the vehicle interaction physical button of the alternative node. Receive a hardwire blocking electrical signal transmitted through the external interrupt trigger port, parse the hardwire blocking electrical signal into a forced exit instruction, prioritize responding to the forced exit instruction to terminate the current task process, and release the available hardware resources occupied by the current task process; When the level identifier in the hierarchical authorization token points to the highest mandatory scheduling level as the second set level, the instruction issuance permission corresponding to the trigger signaling is determined to be the highest mandatory scheduling level permission, and the signal reception permission of the external interrupt trigger port is blocked by the underlying firmware. By disabling the signal reception permission of the external interrupt trigger port, the hard-wired blocking electrical signal emitted by the vehicle interaction physical button is blocked, maintaining continuous monitoring of the hardware operating status parameters to trigger the blocking condition, and terminating the current task process and releasing the available hardware resources occupied by the current task process when the hardware operating status parameters meet the blocking condition.

[0014] Optionally, the method further includes: After the pending task is completed or the current task process is terminated, the total number of processor clock cycles consumed and the peak memory usage of the candidate node in the corresponding execution cycle are extracted. The corresponding execution cycle is the period between when the pending task is assigned to the candidate node and when the pending task is completed or the current task process is terminated. Read the unique hardware identification code of the candidate node, and encapsulate the total number of processor clock cycles, the peak memory usage capacity, and the unique hardware identification code of the candidate node into the resource consumption record message according to the data encapsulation format used to generate the resource consumption record message. The resource consumption record message is used to record the resource consumption information generated by the task to be processed occupying the corresponding available hardware resources in the computing resource pool. Perform hash digest extraction on the resource consumption record message to obtain the hash digest associated with the resource consumption record message; The resource consumption record message and its associated hash digest are synchronously written into the immutable storage area of ​​the distributed decentralized ledger node; An open retrieval interface is provided for the distributed decentralized ledger nodes, and a targeted backtracking query function for historical resource consumption details is provided for the corresponding candidate nodes based on the unique hardware identification code.

[0015] An emergency vehicle-mounted computing power requisition and dispatch device includes: The permission establishment module is used to obtain a trigger signal containing a hierarchical authorization token, perform a verification operation on the hierarchical authorization token, and establish the corresponding level of instruction issuance permission after successful verification. The alternative node determination module is used to broadcast a scheduling request to the vehicle nodes in the target area after the permission to issue the instruction is established, obtain the parking prediction parameters of the vehicle nodes, and determine the vehicle nodes whose parking prediction parameters meet the minimum parking time corresponding to the scheduling request as alternative nodes. The computing resource pool generation module is used to perform locking processing on the basic hardware resources associated with the vehicle control system in the candidate nodes. Under the condition that the basic hardware resources are kept locked, the module extracts the unlocked available hardware resources in the candidate nodes, performs resource pool encapsulation processing on the available hardware resources, and obtains a computing resource pool to carry the tasks to be processed. The task allocation module is used to allocate the task to be processed to the candidate node based on the available hardware resources and geographical distance indicators corresponding to each candidate node in the computing resource pool, instruct the task to be processed to reside and run in the volatile memory of the candidate node, and make the task to be processed occupy the corresponding available hardware resources in the computing resource pool. The task termination module is used to monitor the hardware operating status parameters and communication connection parameters of the candidate node. When the hardware operating status parameters meet the blocking conditions or the communication connection parameters indicate a disconnection, the module terminates the current task process of the candidate node and releases the available hardware resources occupied by the current task process.

[0016] An electronic device includes a processor and a memory, the memory storing a computer program, which, when executed by the processor, implements any of the above-mentioned emergency vehicle-mounted computing power requisition and scheduling methods.

[0017] A computer-readable storage medium storing a computer program that, when executed by a processor, implements any of the above-described emergency vehicle-mounted computing power requisition and scheduling methods.

[0018] A vehicle includes an on-board processor, an on-board memory, basic hardware resources associated with a driving control system, volatile memory, and a communication unit; The communication unit is used to receive triggering signaling containing hierarchical authorization tokens, and to receive scheduling requests after the corresponding level of instruction is issued and permissions are established. The on-board processor is used to respond to the scheduling request, generate parking prediction parameters, and when the parking prediction parameters meet the minimum parking duration corresponding to the scheduling request, enable the vehicle to participate as a backup node in emergency on-board computing power requisition and scheduling. The on-board processor is also used to perform locking processing on the basic hardware resources associated with the driving control system. Under the condition that the basic hardware resources are kept locked, the unlocked available hardware resources are extracted and the available hardware resources are used to form a computing resource pool to carry the tasks to be processed. The volatile memory is used to allow the task to reside and run when it is assigned to the vehicle, and to allow the task to occupy the corresponding available hardware resources in the computing resource pool. The on-board processor is also used to monitor the hardware operating status parameters and communication connection parameters of the vehicle. When the hardware operating status parameters meet the blocking conditions or the communication connection parameters indicate a disconnection, the processor terminates the current task process in the vehicle and releases the available hardware resources occupied by the current task process.

[0019] An emergency vehicle-mounted computing power requisition and scheduling system includes a scheduling management node and multiple vehicle-mounted nodes; The scheduling management node is used to obtain triggering signaling containing hierarchical authorization tokens, perform verification operations on the hierarchical authorization tokens, and establish the corresponding level of instruction issuance permission after successful verification. The scheduling management node is also used to broadcast a scheduling request to multiple vehicle nodes in the target area after the instruction issuance permission is established, obtain the parking prediction parameters returned by the multiple vehicle nodes respectively, and determine the vehicle node whose parking prediction parameters meet the minimum parking time corresponding to the scheduling request as a candidate node. The alternative node is used to perform locking processing on the basic hardware resources associated with the driving control system. Under the condition that the basic hardware resources are kept locked, the unlocked available hardware resources are extracted and the available hardware resources are provided to the scheduling management node. The scheduling management node is also used to encapsulate the available hardware resources provided by multiple candidate nodes into a resource pool to obtain a computing resource pool for carrying the tasks to be processed. The scheduling management node is also used to allocate the task to be processed to the candidate node based on the available hardware resources and geographical distance indicators corresponding to each candidate node in the computing resource pool. The alternative node is also used to, after receiving the task to be processed, instruct the task to be processed to reside and run in the volatile memory of the alternative node, and to make the task to be processed occupy the corresponding available hardware resources in the computing resource pool. The scheduling management node is also used to monitor the hardware operating status parameters and communication connection parameters of the candidate node. When the hardware operating status parameters meet the blocking conditions or the communication connection parameters indicate a disconnection, the current task process of the candidate node is terminated and the available hardware resources occupied by the current task process are released.

[0020] The technical advantages of the technical solution provided in this application are: The emergency vehicle-mounted computing power requisition and scheduling method of this application addresses the technical shortcomings of fixed edge servers in the background technology, which are constrained by existing infrastructure and have difficulty forming temporary computing capacity near events. It first obtains a trigger signaling message containing a hierarchical authorization token and performs a verification operation. After successful verification, it establishes the corresponding level of instruction issuance authority. Compared to the traditional approach where fixed sites or central servers directly process tasks within a predetermined scope, this method ensures that emergency scheduling undergoes hierarchical authorization verification before instruction issuance. This reduces the possibility of unauthorized or mismatched instructions entering the subsequent vehicle-mounted node scheduling process, facilitating the formation of a controlled computing power requisition entry point in emergency scenarios.

[0021] After the command issuance authority is established, this application broadcasts a scheduling request to the vehicle-mounted nodes within the target area and selects candidate nodes based on the vehicle-mounted nodes' dwell prediction parameters and minimum dwell time. Compared to traditional fixed edge server solutions that can only rely on pre-deployed locations and fixed capacity, this application, by broadcasting scheduling requests to vehicle-mounted nodes within the target area, includes vehicle-mounted nodes with certain dwell conditions in the candidate range. This helps to form a more flexible temporary computing support base from the vicinity of the event when the fixed infrastructure capacity or coverage is insufficient. At the same time, using the minimum dwell time to select vehicle-mounted nodes can reduce the probability of tasks being assigned to nodes that may leave in a short period of time, thereby improving the continuity of task dwell and operation.

[0022] After identifying candidate nodes, this application performs locking processing on the basic hardware resources associated with the vehicle control system within those candidate nodes. While maintaining the locked state of the basic hardware resources, it extracts only the unlocked, available hardware resources and encapsulates them into a resource pool. Compared to the traditional approach of directly accessing terminal hardware resources, this method restricts the resource usage of emergency computing tasks to the unlocked, available hardware resources. This creates a clearer resource boundary between the emergency task and the basic hardware resources associated with the vehicle control system, mitigating the operational risks arising from the lack of core functional isolation in temporary participating terminals, as described in the background technology.

[0023] After the computing resource pool is formed, this application allocates the tasks to be processed to the candidate nodes based on the available hardware resources and geographical distance indicators corresponding to each candidate node, and instructs the tasks to reside and run in the volatile memory of the candidate nodes. Compared with the traditional fixed edge server's centralized queuing processing of uploaded data, this application can allocate tasks by combining resource carrying capacity and spatial distance conditions, making the tasks to be processed more likely to be carried by candidate nodes that meet the resource conditions and are geographically close, thereby reducing the dependence on remote fixed sites; at the same time, restricting the tasks to reside and run in volatile memory helps to reduce the risk of task data remaining on the vehicle-mounted node for a long time during non-running phases.

[0024] This application also monitors the hardware operating status parameters and communication connection parameters of the candidate nodes. When the hardware operating status parameters meet the blocking conditions or the communication connection parameters indicate a disconnection, the current task process of the candidate node is terminated and the available hardware resources occupied by the current task process are released. Compared with traditional solutions that lack a unified withdrawal mechanism for changes in the operating status of temporary participating terminals and link anomalies, this approach can trigger task termination and resource release when the hardware operating status or communication connection status of the candidate node is no longer suitable for continuing to carry out the task. This prevents unstable nodes from continuously occupying computing resources, thereby alleviating the resource occupation and processing continuity problems caused by the continued operation of tasks in abnormal carrying environments. Attached Figure Description

[0025] Figure 1 This application provides an embodiment of an emergency vehicle-mounted computing power requisition and scheduling method.

[0026] Figure 2 This application provides an embodiment of an emergency vehicle-mounted computing power requisition and dispatch device.

[0027] Figure 3 This is an electronic device according to an embodiment of the present application.

[0028] Figure 4 This application provides an embodiment of a computer-readable storage medium.

[0029] Figure 5 This is a vehicle as described in an embodiment of this application.

[0030] Figure 6 This application provides an embodiment of an emergency vehicle-mounted computing power requisition and dispatch system. Detailed Implementation

[0031] The terms "first" and "second" in the specification and claims of this application are used to distinguish objects of the same kind, and are not used to limit the necessary order, importance, or quantity difference between objects. For example, "first setting level" and "second setting level" are used to distinguish two permission levels, and "first calculation unit" and "second calculation unit" are used to distinguish different calculation units. Without affecting the technical logic, the relevant names can be replaced accordingly based on the system deployment method.

[0032] In this application, "vehicle-mounted node" can be understood as a computing node installed on a vehicle that can communicate with the scheduling and management node or other vehicle-mounted nodes via a vehicle-to-everything (V2X) communication link. This vehicle-mounted node can consist of an onboard processor, onboard memory, volatile memory, communication unit, positioning unit, hardware status acquisition unit, and hardware resources associated with the vehicle control system. The vehicle-mounted node can be an independent onboard computing unit within the vehicle, or it can be a computing entity formed by combining a vehicle domain controller, an onboard edge computing unit, an onboard gateway, and a computing acceleration unit.

[0033] The "emergency vehicle-mounted computing power requisition and scheduling" in this application does not arbitrarily occupy vehicle hardware resources. Instead, under the premise of an emergency event being triggered, authorization verification being passed, the vehicle meeting the parking conditions, and the vehicle control system's associated resources being locked, the unlocked and idle resources such as processing cores and video memory units are temporarily encapsulated into a computing resource pool to carry out pending tasks in emergency scenarios. During the execution of pending tasks, the system continuously monitors the vehicle's hardware operating status and communication connection status. Once the vehicle status or link status is no longer suitable for carrying out the task, the current task process is terminated and resources are released.

[0034] like Figure 1 The illustration shows an emergency vehicle-mounted computing power requisition and scheduling method provided in an embodiment of this application. This method can be executed by a scheduling management node, or by the scheduling management node and multiple vehicle-mounted nodes in collaboration. The scheduling management node can be deployed in an emergency command center, a roadside edge computing station, a vehicle-to-everything (V2X) platform server, or a cloud-edge collaborative node with emergency scheduling permissions. The vehicle-mounted nodes can be distributed around accident sites, disaster sites, or other areas surrounding emergency events.

[0035] In one implementation, the scheduling management node first obtains a trigger signaling message containing a hierarchical authorization token. The trigger signaling message is signaling data used to initiate the emergency vehicle-mounted computing power requisition process; in this application, it is a data packet carrying authorization credentials, event information, and scheduling initiation information. The trigger signaling message may include fields such as event identifier, event source coordinate system, target area identifier, pending task category, task resource requirements, hierarchical authorization token, and trigger time. The hierarchical authorization token is a data structure used to prove that the trigger signaling message possesses the corresponding scheduling authority, typically including a level identifier, signature data, issuance timestamp, token validity period, issuing authority identifier, and authorized operation scope. The level identifier indicates the authorization level corresponding to the trigger signaling message; the signature data verifies whether the token was generated by a legitimate issuing entity; the issuance timestamp determines whether the token is still within its validity period; and the authorized operation scope restricts the types of instructions that the scheduling management node can subsequently issue.

[0036] Upon receiving a trigger signal, the scheduling management node parses the signal, reads the hierarchical authorization token, and performs a verification operation on the token. This verification can be performed by the scheduling management node's built-in permission verification program or by the node invoking a separate cryptographic verification unit. The cryptographic verification unit can be a hardware security module, a security chip, a verification program in a trusted execution environment, or a cryptographic processing component running within a security service. Only after successful verification does the scheduling management node establish the command issuance permission corresponding to the level of the authorization token. The technical function of command issuance permission is to limit which types of scheduling commands, resource locking commands, task allocation commands, and termination commands the scheduling management node can issue to the vehicle-mounted nodes, preventing subsequent scheduling processes from being initiated without authorization.

[0037] When performing hierarchical authorization token verification, the scheduling management node identifies the level identifier from the hierarchical authorization token contained in the trigger signaling and uses the level identifier as the basis for determining the corresponding permission level. The level identifier can be expressed in the form of numerical encoding, string encoding, or binary flags. For example, the normal emergency response level can be recorded as "LEVEL_NORMAL", and the highest mandatory scheduling level can be recorded as "LEVEL_FORCE". The system does not rely on the specific characters themselves, but rather determines the permission level that the trigger signaling can activate based on the correspondence between the level identifier and the local permission mapping table.

[0038] When the level identifier points to the first set level, the scheduling management node invokes the cryptographic verification unit to verify the signature data of the hierarchical authorization token. The signature data can be data generated by calculating the digest of the token body fields and then using the issuing entity's private key. The scheduling management node can use a pre-set issuing entity public key, certificate chain, or trusted key material to verify the signature data. If the verification result indicates that the token body fields have not been tampered with and the issuing entity is legitimate, the signature verification operation passes; if the verification fails, the scheduling management node does not activate the corresponding level's instruction issuance permission and stops the subsequent scheduling request broadcast process.

[0039] The scheduling management node also extracts the issuance timestamp embedded in the hierarchical authorization token and reads the current system time to calculate the time interval between the issuance timestamp and the current system time. This time interval is used to determine whether the hierarchical authorization token is still within its specified validity period. For example, the token's specified validity period can be several minutes or several hours calculated from the issuance time. If the time interval does not exceed the specified validity period, the timestamp comparison operation passes; if the time interval exceeds the specified validity period, it means the token has expired, and the scheduling management node will no longer use the token to activate command issuance permissions.

[0040] When the signature data verification is successful and the time interval is within the specified valid duration of the hierarchical authorization token, the scheduling management node determines that the hierarchical authorization token has been verified and activates the instruction issuance permission matching the first set level. If the token carried by the triggering signaling only corresponds to the first set level, the scheduling management node will not assign the instruction issuance permission of the second set level to the triggering signaling. This "rejection of allocation" can be implemented through a permission mapping table: when the permission scope corresponding to the level identifier only covers operations such as regular emergency scheduling, vehicle node screening, ordinary task allocation, and user interruptible exit, the system will not grant it high-privilege operations such as the highest forced scheduling and blocking physical interrupt ports. The permission scope of the second set level exceeds the permission scope of the first set level, so the permission corresponding to the second set level will only be activated when the level identifier in the token itself points to the second set level and the verification is successful.

[0041] After the command issuance authority is established, the scheduling management node broadcasts a scheduling request to the vehicle-mounted nodes within the target area. The target area is the geographical range within which vehicle-mounted computing power needs to be scheduled for an emergency event; in this application, it is a spatial area defined by geographical boundary coordinates. This target area can be generated from the coordinates of the emergency event source, the road topology range, the base station coverage area, or an electronic fence defined by command personnel. The geographical boundary coordinates can include a polygonal boundary composed of multiple latitude and longitude points, a circular boundary formed by the center point coordinates and the radius, or data that can be converted into spatial coordinate ranges, such as road mileage segments, parking lot boundaries, and service area boundaries.

[0042] After establishing permissions, the dispatch management node defines the geographical boundary coordinates of the target area and, based on the online vehicle list maintained by the vehicle-to-everything (V2X) platform, the heartbeat status of vehicle nodes, base station access information, or vehicle location information, identifies all online vehicle nodes within the geographical boundary coordinates as the broadcast targets for dispatch requests. Online vehicle nodes refer to those that have reported their online status to the V2X platform, V2X communication base stations, or the dispatch management node within a preset time range and are capable of receiving dispatch requests. By defining the target area before determining the broadcast targets, dispatch requests can be sent only to vehicle nodes relevant to the emergency event, reducing the communication and computational overhead caused by the participation of vehicle nodes in unrelated areas in the dispatch process.

[0043] The scheduling management node can push scheduling requests to all online vehicle nodes within the geographical boundary coordinates via a vehicle-to-everything (V2X) communication base station. The V2X communication base station can be a communication device supporting cellular V2X, 5G, LTE-V2X, C-V2X, roadside units, or other vehicle communication protocols. In this application, the scheduling request is a message used to inquire whether a vehicle node can participate in emergency computing power scheduling. The scheduling request may include a task overview, minimum dwell time, desired resource type, target area identifier, event source coordinate system, data stream access method, task runtime limit, and interface information for returning dwell status prediction data. Upon receiving the scheduling request, the vehicle node parses the fields related to dwell prediction and returns the dwell status prediction data corresponding to the scheduling request.

[0044] Dwelling state prediction data is generated by the vehicle-mounted node based on its current operating state, positioning state, and parking state. Its purpose is to derive parking prediction parameters. Dwelling state prediction data may include data such as the vehicle's current speed, gear status, parking brake status, vehicle location type, remaining parking plan, navigation path status, door or charging status, historical parking behavior statistics, and current driving status indicators. Different vehicles can use different algorithms to generate dwell state prediction data, as long as the parking prediction parameters can be parsed from it. In this application, the parking prediction parameter represents the expected duration of continuous parking by the vehicle-mounted node within the target area, and can be expressed in seconds, minutes, or other time units.

[0045] The scheduling management node receives dwell status prediction data returned by online vehicle nodes in response to scheduling requests, and parses dwell prediction parameters based on this data. For example, the vehicle node can directly return the estimated dwell time, which the scheduling management node uses as the dwell prediction parameter; alternatively, it can return multiple dwell status fields, and the scheduling management node calculates the dwell prediction parameter according to a preset prediction model or rules. The scheduling management node further determines the minimum dwell time corresponding to the scheduling request. The minimum dwell time can be set based on the estimated execution time, data transmission time, task start time, and resource release time of the task to be processed, or it can be automatically generated by the emergency scheduling strategy table based on the task category.

[0046] The scheduling management node compares the predicted dwell time parameters of each online vehicle node with the minimum dwell time. When the predicted dwell time parameters reach the minimum dwell time, it indicates that the online vehicle node has the basic conditions to handle the task in the time dimension, and the scheduling management node selects the online vehicle node as a candidate node. When the predicted dwell time parameters are lower than the minimum dwell time, the online vehicle node is not included in the current computing resource pool to reduce the probability that the vehicle leaves the target area before the task is completed. Here, "reaching" can be understood as the predicted dwell time parameters being greater than or equal to the minimum dwell time.

[0047] After identifying candidate nodes, the scheduling and management node performs a locking process on the basic hardware resources associated with the vehicle control system of the candidate nodes. The basic hardware resources associated with the vehicle control system refer to the hardware resources upon which vehicle safety, basic control, and driver assistance functions depend. These resources may include at least the processing cores, memory segments, control bus access permissions, or related hardware queues allocated to the autonomous driving assistance module, braking control module, and steering control module. These basic hardware resources are related to vehicle driving safety and basic vehicle control and are not used as resources for emergency pending tasks.

[0048] In one specific implementation, the scheduling management node issues a resource whitelist policy to the candidate nodes based on the basic hardware resources associated with the vehicle control system in the candidate nodes. The resource whitelist policy is a data structure that specifies which hardware resources must be reserved for the vehicle control system and must not be accessed by external emergency tasks. The resource whitelist policy contains the processing core identifiers assigned to the autonomous driving assistance module, braking control module, and steering control module. The processing core identifier can be the central processing unit core number, graphics processing unit (GPU) number, neural network accelerator core number, real-time control core number, or a combination thereof. The resource whitelist policy may also include fields such as policy version, policy effective time, policy signature, corresponding vehicle identifier, and applicable system mode.

[0049] Upon receiving the resource whitelist policy, the alternative node blocks external commands from accessing the computing unit pointed to by the processing core identifier through the operating system kernel. Here, "external commands" refers to resource access commands from emergency scheduling tasks, distributed computing middleware, virtual computing containers, or non-vehicle control processes. The operating system kernel can prevent external emergency tasks from being scheduled to the whitelist-protected processing core, nor from submitting task queues to the protected computing unit, through processor affinity configuration, control group resource isolation, device access control lists, interrupt routing masking, kernel scheduling domain isolation, IOMMU access restrictions, or security policy hooks. This completes the locking of the basic hardware resources associated with the vehicle control system.

[0050] After the basic hardware resources have been locked and maintained, the candidate nodes or scheduling management nodes scan for unlocked idle processing cores and idle video memory units among the candidate nodes. Idle processing cores refer to processing cores that are not locked by the resource whitelist, are not currently occupied by critical in-vehicle tasks, and can be temporarily scheduled for emergency tasks. Idle video memory units refer to video memory areas that are not locked and are not currently occupied by in-vehicle graphics or intelligent computing tasks. The scan can be performed by the local resource agent program on the candidate node, or triggered by the scheduling management node through the resource query interface. The scan results can be returned in the form of resource descriptors, which may include fields such as node identifier, processing core identifier, core type, current core load rate, video memory unit identifier, video memory capacity, available memory capacity, resource availability time window, and resource access interface.

[0051] The scheduling and management node identifies idle processing cores and idle video memory units as available hardware resources. Available hardware resources are the actual set of resources used to support tasks in this application, and their boundaries are defined by the locking process; only resources that are not locked and can be called by emergency tasks are included in the available hardware resource range. Subsequently, the scheduling and management node maps the available hardware resources provided by multiple candidate nodes into a uniformly addressed computing resource pool through distributed computing middleware. The distributed computing middleware can consist of a resource registration component, a resource addressing component, a task distribution component, and a status monitoring component. Uniform addressing can be achieved by assigning a global resource address to each available hardware resource, for example, by concatenating the vehicle's unique identifier, node communication address, processing core identifier, video memory unit identifier, and resource type into a unified resource index. The scheduling and management node establishes a computing resource pool based on these unified resource indices, enabling the upper-layer task allocation logic to read the available hardware resources provided by different vehicle nodes in a unified format.

[0052] In this application, the computing resource pool is a logical encapsulation of the available hardware resources of multiple candidate nodes. This computing resource pool does not change the physical ownership of the on-board node hardware; instead, it organizes the available processing cores and idle video memory units scattered across different vehicles into a schedulable resource set through resource description, unified addressing, access interfaces, and state synchronization. Through this resource pool encapsulation process, the computing resource pool only contains unlocked available hardware resources used to carry tasks to be processed; whitelisted vehicle control system-related resources will not enter this computing resource pool.

[0053] After the computing resource pool is generated, the scheduling management node allocates the tasks to be processed to the candidate nodes based on the available hardware resources and geographical distance indicators corresponding to each candidate node in the computing resource pool. The tasks to be processed are those that require processing using onboard computing power during emergency events. In this application, a task unit consists of execution code, input data stream, task execution parameters, and result feedback rules. In one implementation, the scheduling management node first identifies the service type of the task to be processed, determining that it belongs to one of the following service types: image data structured analysis, communication message relay forwarding, or diffusion evolution trend prediction. Image data structured analysis can be used for target identification, target counting, area labeling, or structured field extraction from on-site video frames, UAV images, and road monitoring images; communication message relay forwarding can be used for temporary forwarding, buffering, and relay transmission of communication messages when communication pressure is high or links are limited at the emergency site; diffusion evolution trend prediction can be used to calculate the evolution trends of fires, water accumulation, congestion, pollutants, or personnel gatherings. The service type serves as the basis for the task category of the task to be processed, used to select suitable available hardware resources and scheduling order.

[0054] The scheduling and management node reads the available hardware resources corresponding to each candidate node from the computing resource pool and uses these available hardware resources as candidate resources for the tasks to be processed. Candidate resources can be filtered according to resource type, resource capacity, available time window, and node status. For example, image data structured analysis tasks can prioritize candidate nodes with idle video memory units and graphics processing capabilities; communication message relay forwarding tasks can prioritize candidate nodes with good network connectivity; and diffusion evolution trend inference tasks can prioritize candidate nodes with more idle processing cores or memory resources. The above matching method is used to illustrate how available hardware resources participate in task carrying and does not limit the use of a specific sorting algorithm.

[0055] The dispatch management node also obtains the current location coordinate system of the candidate nodes and uses the coordinate system of the event source as the object of distance calculation. The current location coordinate system refers to the data representation of the candidate node's current location, which can be expressed as latitude and longitude, elevation, road coordinates, or local spatial coordinates. The event source coordinate system refers to the data representation of the location of the emergency event source, such as the location coordinates of an accident point, fire point, water accumulation point, communication interruption point, or disaster epicenter. The dispatch management node determines the spatial straight-line distance between the current location coordinate system and the event source coordinate system and uses this spatial straight-line distance as a geographic distance indicator. The spatial straight-line distance can be calculated by converting latitude and longitude to a unified plane coordinate system and then calculating the Euclidean distance, or by calculating the distance between two points in spherical coordinates. This geographic distance indicator is used to reflect the spatial proximity between the candidate nodes and the event source.

[0056] The scheduling management node establishes an allocation sequence based on geographical distance indicators, from shortest to longest. The allocation sequence is a data structure representing the priority order of candidate nodes participating in task acceptance. Candidate nodes at the front of the sequence have shorter linear distances to the event source and are given priority for accepting tasks, provided resource conditions are met. The scheduling management node determines candidate nodes for accepting tasks based on the allocation sequence and candidate resources. Specifically, it can start by checking whether the candidate resources provided by the candidate nodes at the front of the sequence meet the resource requirements of the task to be processed; if they do, the candidate node is selected; if not, the next candidate node in the sequence is checked. If the task to be processed can be divided into multiple sub-tasks, multiple candidate nodes at the front of the sequence can be jointly selected as the accepting node.

[0057] After identifying candidate nodes to handle tasks, the scheduling management node sequentially pushes the execution code of the tasks to the candidate nodes at the front of the sequence. The execution code can be a container image, a binary program, a script package, a function compute package, or a task execution file that can be loaded by the local runtime environment of the candidate node. Once the execution code is pushed to the candidate node, the candidate node starts the current task process according to the task's execution parameters, assigning the task to that candidate node and consuming the available hardware resources corresponding to that candidate node's computing resource pool. This consuming can manifest as processing cores being bound to the task process, video memory units being allocated to the task execution instance, memory space being allocated to the task data buffer, or network ports being bound to the task data stream.

[0058] During task execution, the scheduling and management node controls the backup node to directly write the data stream of the task to be processed into the random access memory (RAM), which serves as volatile memory. This allows the task to reside and run within the volatile address space corresponding to the RAM. In this application, volatile memory is a storage medium whose data is not permanently retained after power failure or process release; typically, it is random access memory. The data stream of the task to be processed may include video frame data, sensor data fragments, communication messages, map grid data, or event evolution parameters. When receiving the data stream, the backup node writes it into the task buffer in the RAM and performs read / write, parsing, calculation, and result generation within this volatile address space. During task execution, the system does not write any segments of the data stream to a non-volatile disk drive, thereby reducing the possibility of persistent residual emergency data in the vehicle-mounted node.

[0059] After the data stream is processed and a result message is generated, the candidate node clears the volatile address space corresponding to the random access memory. The result message is the output of the task to be processed, and may include structured recognition results, message forwarding status, diffusion trend calculation results, task execution status, and result verification fields. Clearing the volatile address space can be achieved by releasing memory pages, overwriting task buffers, destroying container memory space, or terminating the process context. Writing any segmented data of the data stream to non-volatile disk drives is prohibited. This can be achieved by mounting a read-only file system, disabling container disk writes, kernel file write interception, disabling temporary file disk paths, or enabling a memory file system for the task execution directory. Through this operating mode, the data stream of the task to be processed is primarily processed and destroyed within volatile memory.

[0060] During the execution of the current task process by the candidate node, the scheduling management node continuously monitors the hardware operating status parameters and communication connection parameters of the candidate node. Hardware operating status parameters indicate whether the vehicle containing the candidate node is still suitable to continue serving as a task-bearing node. Communication connection parameters indicate whether the communication link between the scheduling management node and the candidate node can still support task control, status reporting, and result feedback. When the hardware operating status parameters meet the blocking conditions, or the communication connection parameters indicate a disconnection, the scheduling management node terminates the current task process of the candidate node and releases the available hardware resources occupied by the current task process.

[0061] In terms of hardware operational status monitoring, hardware operational status parameters include power battery state of charge parameters, battery pack physical surface temperature parameters, and vehicle spatial displacement parameters. The power battery state of charge parameter indicates the current remaining charge percentage of the vehicle's power battery; its technical function is to determine whether continuing to run emergency computing tasks might affect the vehicle's basic energy needs. The battery pack physical surface temperature parameter indicates the surface temperature of the battery pack; its technical function is to determine whether continuing to utilize vehicle computing resources might increase the thermal load. The vehicle spatial displacement parameter indicates whether the vehicle's position has changed; its technical function is to determine whether the candidate node is still stationary or still within the target area.

[0062] During the current task execution of the candidate node, the scheduling and management node can periodically collect the power battery state-of-charge parameters, battery pack physical surface temperature parameters, and vehicle spatial displacement parameters of the candidate node through periodic reporting by the vehicle-mounted node, forwarding by the vehicle-to-everything (V2X) base station, or local agent collection, to monitor the hardware operating status parameters of the candidate node. The collection period can be set according to the task type and emergency level, such as collecting data on a second-by-second or minute-by-minute basis. The power battery state-of-charge parameters can be provided by the vehicle battery management system; the battery pack physical surface temperature parameters can be provided by the vehicle temperature sensor or the battery management system; and the vehicle spatial displacement parameters can be derived from the coordinate difference, vehicle speed signal, or changes in parking status continuously output by the positioning unit.

[0063] The scheduling and management node compares the battery's state of charge (SOC) parameters with the critical SOC ratio point. When the SOC parameters drop to the critical SOC ratio point, the first blocking condition is triggered. The critical SOC ratio point is a parameter used to determine whether the vehicle's remaining battery power is below the lower limit threshold for continuing to undertake emergency computing tasks. Its specific value can be configured according to vehicle type, task level, and emergency strategy. When the first blocking condition is triggered, the system considers the alternative node unsuitable to continue consuming available hardware resources to run the current task process.

[0064] The scheduling and management node also compares the battery pack physical surface temperature parameter with the critical thermal index of the battery pack physical surface temperature. When the battery pack physical surface temperature parameter rises to the critical thermal index, the second blocking condition is triggered. The critical thermal index of the battery pack physical surface temperature is a parameter used to determine whether the thermal state of the vehicle battery has reached the temperature threshold that requires stopping the emergency computing task. Since emergency computing tasks consume processor or accelerator resources and may increase the thermal load inside the vehicle, this temperature comparison allows for timely task withdrawal when the temperature rises.

[0065] The scheduling and management node also determines whether the candidate node has physically moved based on vehicle spatial displacement parameters. These parameters can include the distance difference between the current location coordinates and the mission initiation coordinates, changes in continuous positioning points, and changes in vehicle speed or parking status. If the vehicle spatial displacement parameters indicate physical movement of the vehicle, a third blocking condition is triggered. The significance of this third blocking condition is that when a vehicle changes from a parked state to a moving state, the onboard node's continued operation of the emergency mission may no longer meet the initial parking prediction conditions and may also affect the stability of the mission link; therefore, it is necessary to terminate or migrate the current mission process in a timely manner.

[0066] When any one of the first, second, or third blocking conditions is triggered, the scheduling management node determines that the hardware operating status parameters meet the blocking conditions and issues a process destruction command to the system kernel of the backup node. The process destruction command is a control command used to terminate the current task process and can be executed through system calls, container runtime interfaces, task daemon interfaces, or kernel control interfaces. Upon receiving the process destruction command, the backup node's system kernel terminates the current task process, releases the available hardware resources occupied by the task process, such as processing cores, video memory units, memory space, and communication ports, and returns the release result to the scheduling management node. The released resources can be removed from the computing resource pool or re-added to the computing resource pool after the vehicle status is reassessed.

[0067] In terms of communication connection monitoring, the scheduling management node establishes a heartbeat detection data packet exchange mechanism with the backup nodes during the period when backup nodes are executing pending tasks. The heartbeat detection data packet is a small probe message periodically exchanged between the scheduling management node and the backup nodes to determine whether the communication link between the two parties is connected. The heartbeat detection data packet may include a sending timestamp, node identifier, task identifier, sequence number, and checksum field. The scheduling management node monitors the communication connection parameters of the backup nodes through this heartbeat detection data packet exchange mechanism.

[0068] The scheduling management node continuously monitors the round-trip delay (RTD) data of heartbeat detection packets and uses this data as a communication connection parameter. The RTD data can be determined based on the time difference between when the scheduling management node sends the heartbeat detection packet and when it receives the heartbeat detection packet returned by the candidate node. Communication connection parameters can include not only the single RTD but also the trend of multiple consecutive RTDs, packet loss, and the time of the most recent successful reception. By monitoring these communication connection parameters, the scheduling management node can determine whether the candidate node remains in a controllable connection state.

[0069] When the duration for which the scheduling management node does not receive a heartbeat detection data packet from the backup node exceeds the disconnection duration limit corresponding to the heartbeat detection data packet exchange mechanism, the communication connection parameter indicates a disconnection. The disconnection duration limit is a pre-configured maximum allowable time without a heartbeat response, which can be set according to the emergency task type, communication link quality, and vehicle network conditions. Reaching this limit indicates that the scheduling management node cannot maintain necessary control communication with the backup node within this duration, therefore, the current task process on the backup node needs to be terminated.

[0070] When the communication connection parameters indicate a disconnection, the scheduling management node sends a hibernation signal to the virtual computing container mounted on the backup node. The virtual computing container is an isolated runtime environment on the backup node used to host the current task process and the available hardware resources occupied by it. This virtual computing container can be implemented using a container runtime, a lightweight virtualization environment, a sandbox environment, or other task isolation runtime environments. The role of the virtual computing container is to encapsulate the emergency task process, task memory space, resource binding relationships, and network interfaces in a relatively independent execution context, facilitating freezing, destruction, and release in abnormal situations.

[0071] The hibernation signaling is used to trigger the virtual computing container to freeze its current context state. The current context state can include process running status, memory mapping information, resource binding relationships, task identifiers, and communication status. After freezing the current context state of the virtual computing container based on the hibernation signaling, the backup node terminates the current task process and releases the available hardware resources occupied by the current task process. If the backup node has completely lost connection, the scheduling management node can mark the corresponding resources of the backup node as unavailable locally, and perform supplementary cleanup through the node agent after the node regains connection, so that the computing resource pool will no longer allocate resources to that node.

[0072] In one optional implementation, the method of this application further differentiates the external interrupt trigger port of the in-vehicle interactive physical button based on the level identifier in the hierarchical authorization token. The in-vehicle interactive physical button can be a physical button on the vehicle for the driver, passengers, or on-site personnel to trigger task exit. The external interrupt trigger port is a hardware interrupt input port that connects the physical button to the in-vehicle processor or underlying control firmware. Its technical function is to transmit the hard-wired blocking electrical signal generated by the physical button to the in-vehicle node, enabling the in-vehicle node to trigger task exit logic upon receiving the electrical signal.

[0073] When the level identifier in the hierarchical authorization token points to the standard emergency response level as the first set level, the dispatch management node determines that the instruction issuance permission corresponding to the trigger signaling is the standard emergency response level permission. Under this permission, the system opens the external interrupt trigger port of the vehicle-mounted interactive physical buttons of the backup node. Opening the external interrupt trigger port can be achieved by enabling the corresponding interrupt control register, opening the firmware interrupt mapping, starting the button signal listening program, or setting the external interrupt port to a receiveable state.

[0074] When a backup node receives a hardwire interruption signal transmitted through an external interrupt trigger port, the onboard node interprets this signal as a forced exit command. The hardwire interruption signal is a level change, pulse signal, or interrupt signal directly generated by a physical button press. Under normal emergency response conditions, the onboard node prioritizes responding to this forced exit command, terminating the current task process and releasing the available hardware resources occupied by the current task process. Here, "priority response" means that the processing priority of this forced exit command is higher than the logic for continuing normal task execution; even if the pending task has not yet been completed, its current task process can be terminated and resources released.

[0075] When the level identifier in the hierarchical authorization token points to the highest mandatory scheduling level (the second set level), the scheduling management node determines that the instruction issuance permission corresponding to the trigger signaling is the highest mandatory scheduling level permission. Under this permission, the scheduling management node can disable the signal reception permission of the external interrupt trigger port through the underlying firmware. The underlying firmware can be the vehicle computing unit's startup firmware, security firmware, microcontroller firmware, or interrupt control firmware. Disabling signal reception permission can be achieved by disabling the corresponding interrupt channel, blocking physical button signal mapping, locking the interrupt configuration register, or preventing button signals from being transmitted to the emergency task control process.

[0076] By disabling the signal reception permission of the external interrupt trigger port, the system blocks the hard-wired blocking electrical signals emitted by the in-vehicle interaction physical buttons, preventing tasks at the highest forced scheduling level from exiting due to these physical button signals. However, at this level, the system still maintains continuous monitoring of hardware operating status parameters to trigger blocking conditions, and terminates the current task process and releases the available hardware resources occupied by the current task process when the hardware operating status parameters meet the blocking conditions. In other words, even if the external interrupt trigger port is blocked, hardware safety-related monitoring such as the state of charge of the power battery, the physical surface temperature of the battery pack, and the vehicle's spatial displacement remains effective, and the task will still terminate when the relevant blocking conditions are triggered.

[0077] In another optional implementation, the method of this application further records and backtracks resource consumption information after the pending task is completed or the current task process is terminated. The scheduling management node extracts the total number of processor clock cycles consumed and the peak memory usage of the candidate node within the corresponding execution cycle. The corresponding execution cycle refers to the period from when the pending task is assigned to the candidate node until the pending task is completed or the current task process is terminated. The total number of processor clock cycles is used to represent the amount of computing resources consumed by the task within the corresponding execution cycle, and the peak memory usage is used to represent the maximum amount of volatile memory occupied by the task within the corresponding execution cycle. The above data can be collected by the candidate node's task runtime, operating system performance counters, container monitoring interface, or resource agent program.

[0078] The scheduling management node reads the unique hardware identification code of the candidate node. This unique hardware identification code is data used to identify the hardware identity of the candidate node and can be generated from the vehicle computing unit serial number, trusted platform module identifier, vehicle node certificate identifier, or hardware security module identifier. The scheduling management node encapsulates the total number of processor clock cycles, peak memory usage, and the candidate node's unique hardware identification code into a resource consumption record message according to the data encapsulation format used to generate the resource consumption record message. The resource consumption record message records the resource consumption information generated by the available hardware resources in the computing resource pool occupied by the pending task. This message may also include fields such as task identifier, execution start time, execution end time, resource pool identifier, task termination reason, and message generation time.

[0079] The scheduling and management node performs hash digest extraction on the resource consumption record message to obtain a hash digest associated with the resource consumption record message. The hash digest is data obtained by performing a one-way digest calculation on the content of the resource consumption record message, and is used for subsequent verification of whether the record message has changed. A hash algorithm suitable for system security requirements can be used to generate this hash digest. Subsequently, the scheduling and management node synchronously writes the resource consumption record message and its associated hash digest into the immutable storage area of ​​the distributed decentralized ledger node. The distributed decentralized ledger node can consist of multiple ledger nodes. Each ledger node stores the resource consumption record or its verification information. The immutable storage area is used to store records that have been confirmed to have been written, reducing the possibility of inconsistent audit information caused by single-point modification of records.

[0080] The system further opens up a retrieval interface for distributed decentralized ledger nodes. The retrieval interface can query based on unique hardware identifiers, task identifiers, time ranges, or resource pool identifiers. Based on the unique hardware identifier, the system provides a targeted backtracking query function for the historical resource consumption details of the corresponding candidate nodes. This function can be used for subsequent statistical analysis of the resource contribution of vehicle nodes participating in emergency computing power requisition, analysis of task execution resource consumption, emergency scheduling auditing, and verification of resource release records.

[0081] like Figure 2 The image shows an emergency vehicle-mounted computing power requisition and scheduling device provided in an embodiment of this application. This device can be applied to a scheduling management node or deployed as a software module in a computing device with emergency scheduling permissions. The device includes a permission establishment module, a candidate node determination module, a computing resource pool generation module, a task allocation module, and a task termination module. In optional implementations, the device may further include a permission level execution module, a resource consumption recording module, and a ledger interaction module. The modules can interact with each other via an internal message bus, function calls, shared memory, or service interfaces.

[0082] The permission establishment module is used to acquire triggering signals containing hierarchical authorization tokens, perform verification operations on the hierarchical authorization tokens, and establish the corresponding level of instruction issuance permission upon successful verification. The triggering signals received by the permission establishment module may include data such as event identifier, event source coordinate system, target area identifier, task category, task resource requirements, hierarchical authorization token, and trigger time. The permission establishment module parses the hierarchical authorization token, identifies the level identifier, and uses the level identifier as the basis for determining the corresponding permission level. In response to the level identifier pointing to the first set level, the permission establishment module calls the cryptographic verification unit to verify the signature data of the hierarchical authorization token, performing a signature verification operation. The permission establishment module also extracts the issuance timestamp embedded in the hierarchical authorization token, determines the time interval between the issuance timestamp and the current system time, and performs a timestamp comparison operation. When the signature data is verified and the time interval is within the specified valid duration of the hierarchical authorization token, the permission establishment module determines that the hierarchical authorization token has been verified, activates the instruction issuance permission matching the first set level, and refuses to assign the instruction issuance permission of the second set level to the trigger signaling carrying the first set level, wherein the permission range of the second set level exceeds the permission range of the first set level.

[0083] The permission establishment module can also cooperate with the permission level execution module. When the level identifier in the hierarchical authorization token points to the standard emergency response level (first set level), it determines that the instruction issuance permission corresponding to the trigger signal is the standard emergency response level permission and opens the external interrupt trigger port of the vehicle-mounted interactive physical button on the alternative node. When the permission level execution module receives a hardwired blocking signal transmitted through the external interrupt trigger port, it parses the signal as a forced exit instruction and triggers the task termination module to prioritize the forced exit instruction, terminating the current task process and releasing the available hardware resources occupied by the current task process. When the level identifier in the hierarchical authorization token points to the highest forced scheduling level (second set level), the permission level execution module determines that the instruction issuance permission corresponding to the trigger signal is the highest forced scheduling level permission. It closes the signal reception permission of the external interrupt trigger port through the underlying firmware, blocks the hardwired blocking signal emitted by the vehicle-mounted interactive physical button, and maintains continuous monitoring of the hardware operating status parameters to trigger the blocking conditions. Even when the hardware operating status parameters meet the blocking conditions, the task termination module still terminates the current task process and releases the available hardware resources occupied by the current task process.

[0084] The candidate node determination module broadcasts a scheduling request to all vehicle-mounted nodes within the target area after authorization is granted. It then obtains the vehicle-mounted nodes' parking prediction parameters and identifies those whose parking prediction parameters meet the minimum parking duration required by the scheduling request as candidate nodes. Upon receiving the authorization activation result from the authorization granting module, the candidate node determination module defines the geographical boundary coordinates of the target area and identifies all online vehicle-mounted nodes within these coordinates as the broadcast targets for the scheduling request. The candidate node determination module can call the vehicle-to-everything (V2X) communication base station interface to push the scheduling request to all online vehicle-mounted nodes within the geographical boundary coordinates, causing these nodes to return parking status prediction data corresponding to the scheduling request. Finally, the candidate node determination module receives the parking status prediction data returned by the online vehicle-mounted nodes in response to the scheduling request and parses the parking prediction parameters from this data. The candidate node determination module also determines the minimum dwell time corresponding to the scheduling request. It compares the dwell prediction parameters with the minimum dwell time, filters out online vehicle nodes whose dwell prediction parameters meet the minimum dwell time, and determines the filtered online vehicle nodes as candidate nodes. Thus, the candidate node determination module not only completes node discovery but also performs dwell condition judgment, ensuring that subsequent members of the computing resource pool have a better foundation for task dwell.

[0085] The computing resource pool generation module performs locking processing on the basic hardware resources associated with the vehicle control system in the candidate nodes. While keeping the basic hardware resources locked, it extracts the unlocked available hardware resources within the candidate nodes and encapsulates these resources into a resource pool to obtain a computing resource pool to support the tasks to be processed. Based on the basic hardware resources associated with the vehicle control system in the candidate nodes, the computing resource pool generation module issues a resource whitelist policy to the candidate nodes. This whitelist policy contains the processing core identifiers allocated to the autonomous driving assistance module, braking control module, and steering control module. The computing resource pool generation module instructs the candidate nodes to block external instructions from accessing the computing units pointed to by the processing core identifiers through the operating system kernel, thus completing the locking processing of the basic hardware resources associated with the vehicle control system based on the resource whitelist policy.

[0086] After the basic hardware resources associated with the vehicle control system are locked and maintained, the computing resource pool generation module scans for unlocked idle processing cores and idle video memory units among the candidate nodes, identifying these as available hardware resources. This scanning can be performed by the computing resource pool generation module calling the local resource agent program of the candidate nodes, or by the candidate nodes actively reporting the resource scan results. The computing resource pool generation module maps the available hardware resources provided by multiple candidate nodes into a uniformly addressed computing resource pool through distributed computing middleware, completing the resource pool encapsulation process for the available hardware resources. This ensures that the computing resource pool only contains unlocked available hardware resources used to carry the tasks to be processed. The resource pool data maintained by the computing resource pool generation module can include fields such as node identifier, resource type, processing core identifier, video memory unit identifier, resource availability status, resource occupancy status, resource locking status, and resource access entry.

[0087] The task allocation module allocates tasks to candidate nodes in the computing resource pool based on the available hardware resources and geographical distance indicators. It instructs the tasks to reside and run in the volatile memory of the candidate nodes and to utilize the corresponding available hardware resources in the computing resource pool. The module first identifies the service type of the task, determining whether it falls under one of the following categories: image data structured analysis, communication message relay forwarding, or diffusion evolution trend prediction. This service type is then used as the basis for classifying the task. The module then reads the available hardware resources corresponding to each candidate node from the computing resource pool and uses these resources as candidate bearer resources for the task.

[0088] The task allocation module obtains the current location coordinate system of the candidate nodes, uses the current location coordinate system and the event source coordinate system as the distance calculation object, determines the spatial straight-line distance between the current location coordinate system and the event source coordinate system, and uses the spatial straight-line distance as the geographic distance index. The task allocation module establishes an allocation sequence according to the geographic distance index in ascending order, and determines the candidate nodes to undertake the processing tasks based on the allocation sequence and candidate hosting resources. The task allocation module pushes the execution code of the task to be processed to the candidate node at the front of the sequence in sequence, so that the task to be processed is allocated to the candidate node, and the task to be processed occupies the available hardware resources corresponding to the candidate node in the computing resource pool. The task allocation module also controls the candidate node to directly write the data stream of the task to be processed into the random access memory (RAM), which is used as volatile memory, so that the task to be processed resides and runs in the volatile address space corresponding to the RAM. After the data stream is processed and the result message is generated, the task allocation module controls the candidate node to clear the volatile address space corresponding to the RAM and prohibits the writing of any segmented data of the data stream to the non-volatile disk drive.

[0089] The task termination module monitors the hardware operating status parameters and communication connection parameters of the candidate node. When the hardware operating status parameters meet the blocking conditions or the communication connection parameters indicate a disconnection, the module terminates the current task process of the candidate node and releases the available hardware resources occupied by the current task process. During the execution of the current task process of the candidate node, the task termination module periodically collects the power battery state of charge parameters, battery pack physical surface temperature parameters, and vehicle spatial displacement parameters to monitor the hardware operating status parameters of the candidate node. The task termination module compares the power battery state of charge parameters with the critical ratio point of the power battery state of charge. When the power battery state of charge parameters drop to the critical ratio point, the first blocking condition is triggered. The task termination module compares the battery pack physical surface temperature parameters with the critical temperature of the battery pack physical surface. When the battery pack physical surface temperature parameters rise to the critical temperature of the battery pack physical surface, the second blocking condition is triggered. The task termination module determines whether the candidate node has moved physically based on the vehicle spatial displacement parameters. When the vehicle spatial displacement parameters indicate that the vehicle has moved physically, the third blocking condition is triggered. When any one of the first, second, or third blocking conditions is triggered, the task termination module determines that the hardware operating status parameters meet the blocking conditions, issues a process destruction instruction to the system kernel of the alternative node, terminates the current task process, and releases the available hardware resources occupied by the current task process.

[0090] The task termination module also establishes a heartbeat detection data packet exchange mechanism with the backup node during the execution cycle of the pending task. This mechanism monitors the communication connection parameters of the backup node. The task termination module continuously listens for the round-trip delay data of the heartbeat detection data packets, using this data as a communication connection parameter. When the duration of not receiving a heartbeat detection data packet from the backup node exceeds the disconnection duration limit corresponding to the heartbeat detection data packet exchange mechanism, the task termination module determines that the communication connection parameters indicate a disconnection and sends a hibernation signal to the virtual computing container mounted on the backup node. The virtual computing container is used to host the current task process and the available hardware resources occupied by the current task process. Based on the hibernation signal, the task termination module freezes the current context state of the virtual computing container, terminates the current task process, and releases the available hardware resources occupied by the current task process.

[0091] The resource consumption recording module can extract the total number of processor clock cycles consumed and the peak memory usage of candidate nodes within the corresponding execution cycle after the pending task is completed or the current task process is terminated. The corresponding execution cycle is the period from when the pending task is assigned to a candidate node until the pending task is completed or the current task process is terminated. The resource consumption recording module reads the unique hardware identifier of the candidate node and encapsulates the total number of processor clock cycles, peak memory usage, and the unique hardware identifier of the candidate node into a resource consumption recording message according to the data encapsulation format used to generate the resource consumption recording message. The resource consumption recording message is used to record the resource consumption information generated by the pending task occupying the corresponding available hardware resources in the computing resource pool. The ledger interaction module performs hash digest extraction on the resource consumption recording message to obtain the hash digest associated with the resource consumption recording message, and synchronously writes the resource consumption recording message and its associated hash digest into the immutable storage area of ​​the distributed decentralized ledger node. The ledger interaction module also provides a retrieval interface for the distributed decentralized ledger node, providing a targeted backtracking query function for the historical resource consumption details of the corresponding candidate node based on the unique hardware identifier.

[0092] The modules in the above device embodiments can be implemented through software programs, hardware circuits, or a combination of both. For example, the permission establishment module can be implemented by a permission service program running on a server processor; the cryptographic verification unit can be implemented by a hardware security module or a trusted execution environment; the computing resource pool generation module can be implemented by a resource management service and distributed computing middleware; the task allocation module can be implemented by a scheduler, a task dispatcher, and a container control interface; and the task termination module can be implemented by a monitoring service, a heartbeat detection service, and an onboard node agent. The names of each module are used to describe its main functions and do not limit the functions to be implemented by independent physical devices.

[0093] like Figure 3 The image shows an electronic device provided in an embodiment of this application. This electronic device can serve as a scheduling and management node, or as a server, edge computing device, vehicle networking platform device, or emergency command platform device for deploying emergency vehicle-mounted computing power requisition and scheduling devices. The electronic device includes a processor and a memory. The memory stores a computer program, which, when executed by the processor, implements any of the aforementioned emergency vehicle-mounted computing power requisition and scheduling methods.

[0094] The processor can be a central processing unit, graphics processing unit, network processor, digital signal processor, application-specific integrated circuit, field-programmable gate array, or any combination thereof. Memory can include volatile memory and non-volatile memory. Volatile memory can be used to store intermediate variables, task scheduling state, and resource pool running state during program execution; non-volatile memory can be used to store program code, permission mapping tables, scheduling policies, whitelist policy templates, and ledger interaction configurations, etc. The electronic device may also include a communication interface for data communication with vehicle-to-everything (V2X) communication base stations, multiple vehicle-mounted nodes, distributed decentralized ledger nodes, or emergency command systems.

[0095] When the processor executes a computer program in memory, it first obtains a trigger signal containing a hierarchical authorization token through the communication interface, performs a verification operation on the hierarchical authorization token, and establishes the corresponding level of instruction issuance authority after successful verification. Subsequently, after the instruction issuance authority is established, the processor broadcasts a scheduling request to the vehicle nodes in the target area through the control communication interface, obtains the parking prediction parameters returned by the vehicle nodes, and determines the vehicle nodes whose parking prediction parameters meet the minimum parking duration corresponding to the scheduling request as candidate nodes. The processor also performs locking processing on the basic hardware resources associated with the vehicle control system in the candidate nodes. Under the condition that the basic hardware resources remain locked, the processor extracts the unlocked available hardware resources in the candidate nodes, performs resource pooling processing on the available hardware resources, and obtains a computing resource pool to carry the tasks to be processed. The processor further allocates the tasks to be processed to the candidate nodes based on the available hardware resources corresponding to each candidate node in the computing resource pool and the geographical distance indicators, instructs the tasks to be processed to reside and run in the volatile memory of the candidate nodes, and makes the tasks to be processed occupy the corresponding available hardware resources in the computing resource pool. The processor also monitors the hardware operating status parameters and communication connection parameters of the candidate nodes. When the hardware operating status parameters meet the blocking conditions or the communication connection parameters indicate a disconnection, the processor terminates the current task process of the candidate node and releases the available hardware resources occupied by the current task process.

[0096] In this electronic device, the processor can also perform processes such as hierarchical authorization token level identifier recognition, signature data verification, issuance timestamp comparison, permission activation, permission overstepping denial, target area geographical boundary coordinate definition, vehicle-to-everything (V2X) communication base station scheduling request push, dwell status prediction data reception and dwell prediction parameter parsing, minimum dwell time comparison, resource whitelist policy distribution, processing core access path blocking, idle processing core and idle video memory unit scanning, distributed computing middleware unified addressing, task service type identification, geographical distance index calculation, allocation sequence establishment, execution code push, random access memory dwell operation control, volatile address space clearing, hardware operation status parameter periodic acquisition, communication connection heartbeat detection, virtual computing container sleep signaling transmission, resource consumption record message encapsulation, hash digest extraction, and distributed decentralized ledger writing. Thus, the electronic device can implement the various technical processes involved in the aforementioned method embodiments by executing programs in the memory.

[0097] like Figure 4The illustration shows a computer-readable storage medium provided in an embodiment of this application. The computer-readable storage medium stores a computer program or computer instructions, which, when executed by a processor, cause the processor to implement any of the aforementioned emergency vehicle-mounted computing power requisition and scheduling methods. The computer-readable storage medium can be a read-only memory, random access memory, flash memory, solid-state drive, hard disk drive, optical disk, memory card, removable storage device, or other non-transitory storage medium capable of storing program code.

[0098] The program stored in the computer-readable storage medium may include a permission verification program segment, a node filtering program segment, a resource locking program segment, a resource pool encapsulation program segment, a task allocation program segment, a volatile operation control program segment, a hardware status monitoring program segment, a communication connection monitoring program segment, a task termination program segment, a resource release program segment, and a resource consumption recording program segment. When the permission verification program segment is executed, it is used to obtain a trigger signaling message containing a hierarchical authorization token, perform a verification operation on the hierarchical authorization token, and establish the corresponding level of instruction issuance permission after successful verification. When the node filtering program segment is executed, it is used to broadcast a scheduling request to the vehicle nodes in the target area, obtain the parking prediction parameters of the vehicle nodes, and determine the vehicle nodes whose parking prediction parameters meet the minimum parking duration as candidate nodes. When the resource locking program segment and the resource pool encapsulation program segment are executed, they are used to perform locking processing on the basic hardware resources associated with the driving control system, extract the unlocked available hardware resources, and encapsulate them into a computing resource pool. When the task allocation and volatile operation control segments are executed, they are used to allocate tasks to be processed based on available hardware resources and geographical distance indicators, and to ensure that the tasks reside and run in the volatile memory of the candidate nodes. When the hardware status monitoring, communication connection monitoring, task termination, and resource release segments are executed, they are used to terminate the current task process and release resources when a blocking condition is triggered or communication is lost. When the resource consumption recording segment is executed, it is used to encapsulate the resource consumption record message, extract the hash digest, and write it to the distributed decentralized ledger node.

[0099] like Figure 5 The image shows a vehicle provided in an embodiment of this application. The vehicle includes an onboard processor, an onboard memory, basic hardware resources associated with the vehicle control system, volatile memory, and a communication unit. In some implementations, the vehicle may also include a positioning unit, a battery management unit, a temperature acquisition unit, a vehicle displacement detection unit, onboard interactive physical buttons, and an onboard task operating environment.

[0100] The communication unit receives triggering signals containing hierarchical authorization tokens and receives scheduling requests after authorization is established at the corresponding level. The communication unit supports vehicle-to-everything (V2X) communication, cellular communication, short-range wireless communication, or wired diagnostic interface communication. The triggering signals received by the communication unit can be forwarded by the scheduling management node or directly issued by the emergency platform when the vehicle acts as a local scheduling node. After receiving a scheduling request, the communication unit provides the onboard processor with data such as the minimum dwell time, task resource requirements, target area identifier, event source coordinates, and task type.

[0101] The onboard processor responds to scheduling requests, generates parking prediction parameters, and, when the parking prediction parameters meet the minimum parking duration corresponding to the scheduling request, enables the vehicle to participate as a backup node in emergency onboard computing power requisition and scheduling. When generating parking prediction parameters, the onboard processor can read the vehicle's current speed, parking status, gear status, positioning information, navigation status, charging status, or parking plan information from the onboard system to form parking status prediction data. This data is then used to calculate or output the parking prediction parameters. If the parking prediction parameters reach the minimum parking duration, the onboard processor returns a response message indicating it can participate in scheduling to the scheduling management node via the communication unit. If the parking prediction parameters do not reach the minimum parking duration, the onboard processor can return a response message indicating it will not participate in this scheduling or will not be included as a backup node by the scheduling management node.

[0102] The onboard processor also performs locking processing on the basic hardware resources associated with the vehicle control system. These resources may include the processing cores allocated to the autonomous driving assistance module, braking control module, and steering control module. After receiving the resource whitelist policy from the scheduling management node, the onboard processor reads the processing core identifier recorded in the whitelist policy and blocks external instructions from accessing the computing unit pointed to by the processing core identifier through the vehicle operating system kernel. These external instructions can come from emergency task execution code, virtual computing containers, or distributed computing middleware. Through this locking process, the onboard processor ensures that the basic hardware resources associated with the vehicle control system are not occupied by emergency pending tasks.

[0103] With basic hardware resources locked, the onboard processor extracts unlocked available hardware resources and incorporates them into a computing resource pool to support pending tasks. The onboard processor can scan for unlocked idle processing cores and idle video memory units, generate resource descriptors available from the vehicle, and send them to the scheduling management node via the communication unit. The scheduling management node uniformly addresses the available hardware resources provided by multiple vehicles to form the computing resource pool for this emergency scheduling. The onboard processor can also locally store the resource addresses and occupancy status of its resources in the computing resource pool, enabling rapid binding of corresponding resources when pending tasks are assigned to vehicles.

[0104] Volatile memory is used to allow tasks to reside and run when assigned to a vehicle, consuming corresponding available hardware resources from the computing resource pool. This volatile memory can be random access memory (RAM). After a task is sent to the vehicle, the onboard processor writes the task's data stream into the corresponding volatile address space of the RAM, where it performs task data reading, computation, caching, and result generation. The onboard memory can store the task's runtime environment, system programs, whitelist policies, and vehicle configuration data, but segmented data stream data is not written to non-volatile disk drives. After data stream processing is complete and a result message is generated, the onboard processor clears the volatile address space corresponding to the RAM and returns the result message to the scheduling management node via the communication unit.

[0105] The onboard processor also monitors the vehicle's hardware operating status parameters and communication connection parameters. When the hardware operating status parameters meet the blocking conditions or the communication connection parameters indicate a disconnection, it terminates the current task process in the vehicle and releases the available hardware resources occupied by the current task process. The onboard processor can periodically read the power battery state of charge parameters, battery pack physical surface temperature parameters, and vehicle spatial displacement parameters, and report these parameters to the scheduling and management node through the communication unit. It can also perform blocking condition judgment locally. When the power battery state of charge parameter drops to the critical proportion point of the power battery state of charge, the onboard processor triggers the first blocking condition; when the battery pack physical surface temperature parameter rises to the critical temperature of the battery pack physical surface, the onboard processor triggers the second blocking condition; when the vehicle spatial displacement parameter indicates that the vehicle has moved physically, the onboard processor triggers the third blocking condition. When any blocking condition is triggered, the onboard processor issues a process destruction instruction to the vehicle system kernel, terminating the current task process and releasing resources such as the processing core, video memory unit, and volatile memory address space.

[0106] The vehicle can also exchange heartbeat detection data packets with the scheduling management node via a communication unit. During the execution cycle of a pending task, the onboard processor receives the heartbeat detection data packets sent by the scheduling management node and returns a response, which the scheduling management node uses to monitor round-trip latency data. When the onboard processor detects a sleep signaling command issued by the scheduling management node, it freezes the current context state of the virtual computing container, terminates the current task process, and releases the available hardware resources occupied by the current task process. The virtual computing container can encapsulate emergency task processes, the processing cores, video memory units, and memory space occupied by the task, enabling task termination and resource release to be performed in a relatively isolated manner within the onboard system.

[0107] The vehicle may also include in-vehicle interactive physical buttons and their external interrupt trigger ports. Under normal emergency response levels, the in-vehicle processor opens the external interrupt trigger port, receives hardwired blocking signals from the physical buttons, and interprets these signals as a forced exit instruction, prioritizing the termination of the current task process and releasing resources. Under the highest forced scheduling level, the in-vehicle processor, through its underlying firmware, disables the signal reception permission of the external interrupt trigger port, blocking hardwired blocking signals from the physical buttons, but still maintains monitoring of the battery's state of charge, battery pack surface temperature, and vehicle spatial displacement parameters. When the hardware operating parameters meet the blocking conditions, the current task process is terminated and resources are released.

[0108] like Figure 6 The image shows an emergency vehicle-mounted computing power requisition and scheduling system provided in an embodiment of this application. The system includes a scheduling management node and multiple vehicle-mounted nodes. In optional implementations, the system may further include a vehicle-to-everything (V2X) communication base station, an emergency command platform, distributed computing middleware, a distributed decentralized ledger node, and a task result receiving node.

[0109] The dispatch management node is used to acquire triggering signaling containing hierarchical authorization tokens, perform verification operations on the hierarchical authorization tokens, and establish the corresponding level of instruction issuance authority upon successful verification. The dispatch management node can receive triggering signaling from the emergency command platform or from emergency operational systems with valid issuance authority. The dispatch management node parses the hierarchical authorization token in the triggering signaling, identifies the level identifier, and performs signature data verification and issuance timestamp comparison. After successful verification, the dispatch management node activates the corresponding level of instruction issuance authority based on the level identifier and, according to the authority level, decides whether to enable physical button interruption exit at the regular emergency response level, or whether to enable interrupt port blocking at the highest forced dispatch level.

[0110] The scheduling management node is also used to broadcast scheduling requests to multiple vehicle-mounted nodes within the target area after the command issuance authority has been established. The scheduling management node defines the geographical boundary coordinates of the target area, identifies multiple online vehicle-mounted nodes within these geographical boundary coordinates as the broadcast targets of the scheduling request, and pushes the scheduling request to these online vehicle-mounted nodes through the vehicle-to-everything (V2X) communication base station. Multiple vehicle-mounted nodes respond to the scheduling request, generating and returning parking prediction parameters. The scheduling management node obtains the parking prediction parameters returned by the multiple vehicle-mounted nodes and identifies the vehicle-mounted node whose parking prediction parameters meet the minimum parking duration corresponding to the scheduling request as a candidate node.

[0111] Alternate nodes are used to perform locking processes on the basic hardware resources associated with the vehicle control system. The scheduling management node can issue a resource whitelist policy to each alternative node. The resource whitelist policy contains the processing core identifiers assigned to the autonomous driving assistance module, braking control module, and steering control module. Alternate nodes block external instructions from accessing the computing units pointed to by the processing core identifiers through the operating system kernel, thus keeping the basic hardware resources associated with the vehicle control system locked. Under the condition that the basic hardware resources remain locked, alternative nodes scan for unlocked idle processing cores and idle video memory units on their own nodes, treat these resources as unlocked and available hardware resources, and provide the available hardware resources to the scheduling management node.

[0112] The scheduling management node is also used to encapsulate the available hardware resources provided by multiple candidate nodes into a resource pool, resulting in a computing resource pool to support the tasks to be processed. The scheduling management node can map available hardware resources from different candidate nodes into a uniformly addressed set of resources through distributed computing middleware. The uniform address of each resource can include the vehicle node identifier, resource type, processing core identifier, idle memory unit identifier, communication address, and resource status. After the computing resource pool is formed, the scheduling management node can perform task scheduling based on the type of task to be processed, candidate resources, and geographical distance indicators.

[0113] The scheduling management node allocates tasks to candidate nodes based on the available hardware resources and geographical distance metrics of each candidate node in the computing resource pool. The scheduling management node identifies the task as belonging to a service type within image data structured analysis, communication message relay forwarding, or diffusion evolution trend prediction, and reads the available hardware resources corresponding to each candidate node from the computing resource pool. The scheduling management node obtains the current location coordinate system of the candidate node, calculates the straight-line distance between the current location coordinate system and the event source coordinate system, and uses this straight-line distance as the geographical distance metric. The scheduling management node establishes an allocation sequence according to the geographical distance metric from shortest to longest, and determines the candidate nodes to handle the tasks based on the candidate bearer resources. Subsequently, the scheduling management node pushes the execution code of the task to the candidate node at the front of the sequence, thus assigning the task to the corresponding candidate node.

[0114] After receiving a task, the backup node instructs the task to reside and run in its volatile memory, and allocates the corresponding available hardware resources from the computing resource pool. The backup node can launch a virtual computing container to host the task, binding the processing core, idle video memory unit, and random access memory address space according to the resource addresses issued by the scheduling management node. The data stream of the task is directly written to the random access memory and processed within its corresponding volatile address space. After processing, the backup node generates a result message, clears the volatile address space corresponding to the random access memory, and prohibits any segmented data from being written to the non-volatile disk drive.

[0115] The scheduling and management node is also used to monitor the hardware operating status parameters and communication connection parameters of the candidate nodes. For hardware operating status parameters, the scheduling and management node periodically receives the power battery state of charge (SOC) parameters, battery pack physical surface temperature parameters, and vehicle spatial displacement parameters reported by the candidate nodes. It compares the SOC parameters with the critical SOC ratio point, the battery pack physical surface temperature parameters with the critical thermal index, and determines whether the candidate node has moved physically based on the vehicle spatial displacement parameters. When the SOC parameter drops to the critical SOC ratio point, the battery pack physical surface temperature parameter rises to the critical thermal index, or the vehicle spatial displacement parameters indicate physical movement of the vehicle, the scheduling and management node determines that the hardware operating status parameters meet the blocking conditions.

[0116] For communication connection parameters, a heartbeat detection data packet exchange mechanism is established between the scheduling management node and the backup node. The scheduling management node continuously monitors the round-trip delay data of the heartbeat detection data packets and uses this data as a communication connection parameter. When the duration of not receiving a heartbeat detection data packet from the backup node exceeds the disconnection duration limit, the scheduling management node determines that the communication connection parameter indicates a disconnection. When the hardware operating status parameters meet the blocking conditions or the communication connection parameter indicates a disconnection, the scheduling management node terminates the current task process of the backup node and releases the available hardware resources occupied by the current task process. Specifically, the scheduling management node can issue a process destruction command to the system kernel of the backup node, or send a hibernation signal to the virtual computing container mounted on the backup node to freeze the current context state of the virtual computing container, terminate the current task process, and release resources.

[0117] The system may also include distributed decentralized ledger nodes to store resource consumption records after task execution. After a pending task is completed or the current task process is terminated, the scheduling management node extracts the total number of processor clock cycles consumed and the peak memory usage of the candidate nodes within the corresponding execution cycle, reads the unique hardware identifier of the candidate nodes, and encapsulates the total number of processor clock cycles, peak memory usage, and unique hardware identifier into a resource consumption record message. The scheduling management node performs hash digest extraction on the resource consumption record message to obtain a hash digest associated with the resource consumption record message, and synchronously writes the resource consumption record message and its associated hash digest into the immutable storage area of ​​the distributed decentralized ledger node. The scheduling management node or ledger node provides an open retrieval interface, enabling the system to provide a targeted backtracking query function for the historical resource consumption details of the corresponding candidate nodes based on the unique hardware identifier.

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

Claims

1. A method for emergency vehicle-mounted computing power requisition and scheduling, characterized in that, include: Obtain the trigger signaling containing the hierarchical authorization token, perform a verification operation on the hierarchical authorization token, and establish the corresponding level of instruction issuance permission after successful verification; After the authorization to issue the command is established, a scheduling request is broadcast to the vehicle nodes in the target area to obtain the parking prediction parameters of the vehicle nodes. The vehicle nodes whose parking prediction parameters meet the minimum parking time corresponding to the scheduling request are identified as candidate nodes. Locking processing is performed on the basic hardware resources associated with the vehicle control system in the candidate nodes. Under the condition that the basic hardware resources are kept locked, the unlocked available hardware resources in the candidate nodes are extracted, and the available hardware resources are encapsulated into a resource pool to obtain a computing resource pool for carrying the task to be processed. Based on the available hardware resources and geographical distance indicators of each candidate node in the computing resource pool, the task to be processed is assigned to the candidate node, the task to be processed is instructed to reside and run in the volatile memory of the candidate node, and the task to be processed occupies the corresponding available hardware resources in the computing resource pool. Monitor the hardware operating status parameters and communication connection parameters of the candidate node. When the hardware operating status parameters meet the blocking conditions or the communication connection parameters indicate a disconnection, terminate the current task process of the candidate node and release the available hardware resources occupied by the current task process.

2. The emergency vehicle-mounted computing power requisition and dispatch method according to claim 1, characterized in that, The step of performing a verification operation on the authorization token at the specified level, and establishing the corresponding level of instruction issuance permission after successful verification, includes: Identify the level identifier from the hierarchical authorization token contained in the triggering signaling, and use the level identifier as the basis for determining the permission level of the corresponding level; In response to the level identifier pointing to the first set level, the cryptographic verification unit is invoked to verify the signature data of the hierarchical authorization token, and the signature verification operation in the verification operation is executed; Extract the issuance timestamp embedded in the hierarchical authorization token, determine the time interval between the issuance timestamp and the current system time, and perform the timestamp comparison operation in the verification operation; When the signature data is verified and the time interval is within the specified valid duration range corresponding to the hierarchical authorization token, it is determined that the hierarchical authorization token has been verified, the instruction issuance permission matching the first set level is activated, and the instruction issuance permission of the second set level is refused to be assigned to the trigger signaling carrying the first set level. The permission range of the second set level exceeds the permission range of the first set level.

3. The emergency vehicle-mounted computing power requisition and dispatch method according to claim 1, characterized in that, After the authorization to issue the command is established, a scheduling request is broadcast to the vehicle nodes within the target area to obtain the parking prediction parameters of the vehicle nodes. Vehicle nodes whose parking prediction parameters satisfy the minimum parking duration corresponding to the scheduling request are identified as candidate nodes, including: After the permission to issue the instruction is established, the geographical boundary coordinates of the target area are defined, and all online vehicle nodes within the geographical boundary coordinates are identified as the broadcast objects of the scheduling request. The scheduling request is pushed to all online vehicle nodes within the geographical boundary coordinates by the vehicle network communication base station, so that the online vehicle nodes return the dwell status prediction data corresponding to the scheduling request; Receive the dwell status prediction data returned by the online vehicle node in response to the scheduling request, and parse the dwell prediction parameters based on the dwell status prediction data; Determine the minimum dwell time corresponding to the scheduling request, compare the dwell prediction parameter with the minimum dwell time, filter out the online vehicle nodes whose dwell prediction parameter reaches the minimum dwell time, and determine the filtered online vehicle nodes as the candidate nodes.

4. The emergency vehicle-mounted computing power requisition and dispatch method according to claim 1, characterized in that, The process involves locking the basic hardware resources associated with the vehicle control system in the candidate nodes. While these basic hardware resources remain locked, the unlocked available hardware resources within the candidate nodes are extracted. These available hardware resources are then encapsulated into a resource pool to obtain a computing resource pool for carrying the task to be processed, including: Based on the basic hardware resources associated with the vehicle control system in the candidate nodes, a resource whitelist policy is issued to the candidate nodes. The resource whitelist policy contains the processing core identifiers assigned to the autonomous driving assistance module, braking control module and steering control module. The alternative node is instructed to block the access path of external instructions to the computing unit pointed to by the processing core identifier through the operating system kernel, and to complete the locking process of the basic hardware resources associated with the driving control system based on the resource whitelist policy. After the basic hardware resources associated with the driving control system have completed the locking process and remain locked, the idle processing cores and idle video memory units that are not locked in the candidate nodes are scanned, and the idle processing cores and idle video memory units are identified as the available hardware resources. The available hardware resources provided by multiple candidate nodes are mapped to a uniformly addressed computing resource pool through a distributed computing middleware, thereby completing the resource pool encapsulation process of the available hardware resources, so that the computing resource pool contains only the available hardware resources that are not locked and are used to carry the task to be processed.

5. The emergency vehicle-mounted computing power requisition and dispatch method according to claim 1, characterized in that, The step of allocating the task to be processed to the candidate nodes based on the available hardware resources and geographical distance indicators corresponding to each candidate node in the computing resource pool, instructing the task to be processed to reside and run in the volatile memory of the candidate node, and causing the task to be processed to occupy the corresponding available hardware resources in the computing resource pool includes: Identify the service type of the task to be processed, determine that the task to be processed belongs to one of the service types in image data structured analysis, communication message relay forwarding and diffusion evolution trend inference, and use the service type as the basis for the task category of the task to be processed. Read the available hardware resources corresponding to each of the candidate nodes from the computing resource pool, and use the available hardware resources as candidate carrier resources for the task to be processed; Obtain the current location coordinate system of the candidate node, take the current location coordinate system and the event source coordinate system as the distance calculation object, determine the spatial straight-line distance between the current location coordinate system and the event source coordinate system, and take the spatial straight-line distance as the geographic distance index; An allocation sequence is established according to the geographical distance index from shortest to longest, and the candidate nodes for undertaking the task to be processed are determined based on the allocation sequence and the candidate carrying resources. The execution code of the task to be processed is pushed to the candidate node at the front of the sequence in sequence, so that the task to be processed is assigned to the candidate node and the task to be processed occupies the available hardware resources corresponding to the candidate node in the computing resource pool. The alternative node is controlled to directly write the data stream of the task to be processed into the random access memory, which serves as the volatile memory, so that the task to be processed resides and runs in the volatile address space corresponding to the random access memory. After the data stream is processed and a result message is generated, the volatile address space corresponding to the random access memory is cleared, and writing any segmented data of the data stream to the non-volatile disk drive is prohibited.

6. An emergency vehicle-mounted computing power requisition and dispatch device, characterized in that, include: The permission establishment module is used to obtain a trigger signal containing a hierarchical authorization token, perform a verification operation on the hierarchical authorization token, and establish the corresponding level of instruction issuance permission after successful verification. The alternative node determination module is used to broadcast a scheduling request to the vehicle nodes in the target area after the permission to issue the instruction is established, obtain the parking prediction parameters of the vehicle nodes, and determine the vehicle nodes whose parking prediction parameters meet the minimum parking time corresponding to the scheduling request as alternative nodes. The computing resource pool generation module is used to perform locking processing on the basic hardware resources associated with the vehicle control system in the candidate nodes. Under the condition that the basic hardware resources are kept locked, the module extracts the unlocked available hardware resources in the candidate nodes, performs resource pool encapsulation processing on the available hardware resources, and obtains a computing resource pool to carry the tasks to be processed. The task allocation module is used to allocate the task to be processed to the candidate node based on the available hardware resources and geographical distance indicators corresponding to each candidate node in the computing resource pool, instruct the task to be processed to reside and run in the volatile memory of the candidate node, and make the task to be processed occupy the corresponding available hardware resources in the computing resource pool. The task termination module is used to monitor the hardware operating status parameters and communication connection parameters of the candidate node. When the hardware operating status parameters meet the blocking conditions or the communication connection parameters indicate a disconnection, the module terminates the current task process of the candidate node and releases the available hardware resources occupied by the current task process.

7. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a computer program, which, when executed by the processor, implements the emergency vehicle-mounted computing power requisition and scheduling method as described in any one of claims 1 to 5.

8. 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 emergency vehicle-mounted computing power requisition and scheduling method as described in any one of claims 1 to 5.

9. A vehicle, characterized in that, This includes onboard processors, onboard storage, basic hardware resources associated with the vehicle control system, volatile memory, and communication units; The communication unit is used to receive triggering signaling containing hierarchical authorization tokens, and to receive scheduling requests after the corresponding level of instruction is issued and permissions are established. The on-board processor is used to respond to the scheduling request, generate parking prediction parameters, and when the parking prediction parameters meet the minimum parking duration corresponding to the scheduling request, enable the vehicle to participate as a backup node in emergency on-board computing power requisition and scheduling. The on-board processor is also used to perform locking processing on the basic hardware resources associated with the driving control system. Under the condition that the basic hardware resources are kept locked, the unlocked available hardware resources are extracted and the available hardware resources are used to form a computing resource pool to carry the tasks to be processed. The volatile memory is used to allow the task to reside and run when it is assigned to the vehicle, and to allow the task to occupy the corresponding available hardware resources in the computing resource pool. The on-board processor is also used to monitor the hardware operating status parameters and communication connection parameters of the vehicle. When the hardware operating status parameters meet the blocking conditions or the communication connection parameters indicate a disconnection, the processor terminates the current task process in the vehicle and releases the available hardware resources occupied by the current task process.

10. An emergency vehicle-mounted computing power requisition and dispatch system, characterized in that, This includes a scheduling and management node and multiple vehicle-mounted nodes; The scheduling management node is used to obtain triggering signaling containing hierarchical authorization tokens, perform verification operations on the hierarchical authorization tokens, and establish the corresponding level of instruction issuance permission after successful verification. The scheduling management node is also used to broadcast a scheduling request to multiple vehicle nodes in the target area after the instruction issuance permission is established, obtain the parking prediction parameters returned by the multiple vehicle nodes respectively, and determine the vehicle node whose parking prediction parameters meet the minimum parking time corresponding to the scheduling request as a candidate node. The alternative node is used to perform locking processing on the basic hardware resources associated with the driving control system. Under the condition that the basic hardware resources are kept locked, the unlocked available hardware resources are extracted and the available hardware resources are provided to the scheduling management node. The scheduling management node is also used to encapsulate the available hardware resources provided by multiple candidate nodes into a resource pool to obtain a computing resource pool for carrying the tasks to be processed. The scheduling management node is also used to allocate the task to be processed to the candidate node based on the available hardware resources and geographical distance indicators corresponding to each candidate node in the computing resource pool. The alternative node is also used to, after receiving the task to be processed, instruct the task to be processed to reside and run in the volatile memory of the alternative node, and to make the task to be processed occupy the corresponding available hardware resources in the computing resource pool. The scheduling management node is also used to monitor the hardware operating status parameters and communication connection parameters of the candidate node. When the hardware operating status parameters meet the blocking conditions or the communication connection parameters indicate a disconnection, the current task process of the candidate node is terminated and the available hardware resources occupied by the current task process are released.

Images