Unified scheduling algorithm based on financial escort vehicle and escort personnel remote identification

Abstract

The invention discloses a unified scheduling algorithm based on financial escort vehicle and escort personnel remote identification. The problems that traditional financial escort is low in efficiency, insufficient in safety and poor in compliance are solved. The algorithm comprises multi-dimensional data modeling and identity verification, and vehicles, people and tasks are ensured to be legal through RFID, OBD and biological feature triple verification. A multi-target intelligent scheduling algorithm is constructed, and global optimal allocation is realized based on task priorities and a resource load model; dynamic monitoring and emergency response are carried out, edge nodes are used for collecting data, a three-level alarm mechanism is established, and resources are dynamically scheduled; and performing full-process data evidence storage and compliance management, encrypting evidence storage key data through a PBFT alliance chain and automatically generating an audit report. According to the scheme, through data driving and intelligent decision making, the task execution efficiency is improved, the safety is enhanced, the escorting process is traceable, the method is suitable for financial escorting scenes, and the industry intelligent management level is remarkably improved.

Description

Technical Field

[0001] The present invention relates to the field of financial escort, and in particular to a unified dispatching algorithm based on remote identification of financial escort vehicles and escort personnel. Background Art

[0002] Financial escort is a core component of ensuring the safe circulation of important assets such as currency and precious metals, and is characterized by high risk and stringent compliance requirements. With the digital transformation of the financial industry, the traditional escort model faces the following challenges: Escalating security risks: Identity forgery, route leaks, and internal theft are common, making traditional manual verification methods inadequate for addressing technologically-driven crimes. Inefficient dispatching: Reliance on manual experience in assigning tasks and a lack of dynamic route planning optimization lead to high idle vehicle rates and slow response times. Regulatory compliance pressure: The People's Bank of China's "Regulations on Public Security Management in the Financial Industry" require the escort process to be traceable and monitorable, but the fragmented data in the traditional model makes it difficult to meet real-time regulatory requirements.

[0003] Overview of existing technologies: Identity recognition technology, traditional methods: manual verification of documents, paper sign-in, easy to forge and time-consuming. Existing technology: RFID tags identify vehicle identities, but there is a risk of label forgery. Static facial recognition verifies personal identity, but cannot distinguish between living people and forged images. Scheduling optimization technology. Manual scheduling: tasks are assigned based on experience, and route planning relies on paper maps or simple navigation software, which cannot respond to changes in road conditions in real time. Preliminary intelligence: single-dimensional optimization, without comprehensive consideration of multiple factors such as personnel experience and vehicle status. Lack of dynamic adjustment mechanism, the task cannot be automatically replanned according to emergencies in the middle of the process. Monitoring and management technology: traditional GPS positioning has a long interval and cannot capture subtle route deviations. Monitoring data is scattered and lacks linkage analysis capabilities.

[0004] The core problems of the existing technology are low efficiency and low safety. Summary of the Invention

[0005] The technical problem to be solved by the present invention is the low efficiency and low security of the existing technology. A new unified dispatching algorithm based on remote identification of financial escort vehicles and escort personnel is provided, which has the characteristics of high efficiency and high security.

[0006] In order to solve the above technical problems, the technical solutions adopted are as follows:

[0007] A unified dispatching algorithm based on remote identification of financial escort vehicles and escort personnel, the dispatching algorithm comprising:

[0008] Step 1: Multidimensional Data Modeling and Identity Verification: Define the Vehicle Set Personnel gathering Task Collection Build a structured data model that includes attributes such as unique identification, real-time status, and permission level, and ensure the legitimacy of vehicles, people, and tasks through triple verification, including vehicle physical identity verification, person biometric chain verification, and task and resource pre-matching verification;

[0009] Step 2: Build a multi-objective intelligent scheduling algorithm: Based on the task priority and resource load model, a mixed integer programming objective function is constructed. The task allocation scheme is solved through iterative optimization strategy to achieve the global optimization of time cost, risk cost, and load balance.

[0010] Step 3: Dynamic Monitoring and Emergency Response: Vehicle-mounted edge nodes collect multi-dimensional data in real time, establish a three-level alarm mechanism, and combine regional resource pools to achieve hierarchical response to abnormal events and dynamic resource rebalancing.

[0011] Step 4: Full-process data storage and compliance management, build a consortium chain, encrypt and store key operation data, and automatically generate compliance audit reports.

[0012] Working Principle of This Solution: This technical solution forms an intelligent management system for the entire financial escort process by constructing a four-layer technical architecture consisting of multi-dimensional data modeling and identity verification, multi-target intelligent scheduling, dynamic monitoring and emergency response, and full-process data storage and compliance management. First, a structured data model for vehicles, personnel, and tasks is defined. Vehicle legitimacy is cross-verified using RFID and OBD data, personnel biometrics are compared with a structured light camera and a public security database, and a matching function integrates distance and authority weights to implement a triple verification mechanism for task-resource pre-matching, eliminating identity forgery and resource mismatching at the source. A mixed integer programming objective function is then constructed based on task priority and resource load. Task allocation solutions are iteratively optimized using a simulated annealing algorithm. By integrating multiple factors such as time cost, risk cost, and load balancing, the idle rate is reduced from over 25% in the traditional model to below 15%, and emergency response time is compressed to within 30 minutes, addressing the inefficiency caused by manual scheduling that relies on experience and single-dimensional optimization. At the same time, on-board edge nodes collect multi-dimensional data such as 10Hz Beidou positioning and escort posture at high frequency, establishing a three-level alarm mechanism. This triggers a response within 5 seconds for emergencies such as illegal door openings, and dynamically replans within 10 minutes for medium-risk situations such as route deviations. Combined with regional resource pool priority scheduling strategies, this reduces security incident processing time from 10 minutes to less than 5 minutes. High-risk areas are proactively avoided and the risk cost is quantified (high-risk area coefficient × 1.5), enhancing the system's risk resistance. Finally, a PBFT consortium chain is used to implement AES-256 encrypted evidence storage for key data. A three-phase consensus process, pre-prepare-prepare-submit, ensures that data cannot be tampered with. Compliance reports, including trajectory playback and operation logs, are automatically generated, reducing audit time from two hours of manual work to less than 10 minutes, addressing the traditional issues of data fragmentation and difficulty in compliance traceability. The overall solution systematically improves the efficiency (task execution efficiency increased by 50%+), security (identity misrecognition rate ≤ 1%) and compliance (real-time supervision adaptation) of financial escort through data-driven intelligent decision-making, dynamic response and blockchain evidence storage, breaking through the technical bottlenecks of low efficiency, multiple security vulnerabilities and chaotic data management in the traditional model.

[0013] In the above scheme, for further optimization, step 1 includes:

[0014] Step 1.1: Define the basic data structure and define the core entity set of the financial escort system, including:

[0015] is a vehicle set containing each vehicle V i Associated properties:

[0016] VID i : Unique identification of the vehicle, which can be achieved by RFID coding;

[0017] Statusi (t): Real-time state vector, including GPS coordinates (x i (t), y i (t)), load W i (t), fuel quantity F i (t);

[0018] is a set of personnel, including each person P j Association attributes;

[0019] PID j : Personnel unique identification, which includes a biometric hash value;

[0020] Auth j : permission level;

[0021] is a set of tasks, including each task T l Associated properties:

[0022] TID l : Unique ID of the task

[0023] Type l : Task type, including urgent, high-value, and ordinary task types;

[0024] Route l :Preset route coordinate sequence [(x l1 ,y l1 ),...,(x le ,y le ])

[0025] Step 1.2: Set up a dynamic identity verification model and design a triple verification mechanism to ensure the legitimacy of the vehicle, person, and task, including;

[0026] Step 1.2.1, vehicle physical identity verification, obtain VID through the reader i , compare static information such as vehicle model and annual inspection status with the vehicle management office database, and analyze OBD data to verify dynamic status:

[0027]

[0028] Among them, MinFuel is the minimum fuel threshold;

[0029] Step 1.2.2: Verify the biometric chain of the person, and collect 3D facial data F through a structured light camera j , and the characteristics of the public security database Calculate cosine similarity:

[0030]

[0031] Among them, TaskLevel l It is the task level requirement;

[0032] Step 1.2.3: Pre-match tasks and resources, including:

[0033] Establish the association matrix M between tasks and vehicles / personnel l，i，j , define the matching function:

[0034] M l，i，j =α·Dis(V i , T l )+β·AuthMatch(P j , T l )

[0035] Where: Dis(V i , T l ) represents the normalized Euclidean distance from the vehicle’s current location to the mission starting point, AuthMatch(P j , T l ) indicates the permission matching degree, A-level tasks require Auth j =A, it is 1, otherwise it is 0; pre-α + β = 1, it is necessary to prioritize authority matching, β = 0.7.

[0036] By defining a structured data model for vehicles, personnel, and tasks, RFID and OBD are used to cross-verify vehicle identities. Structured light cameras are used in conjunction with public security databases to verify personnel biometrics. Finally, a matching function is used to combine distance and authority weights to pre-match task resources. This technology utilizes multi-dimensional data cross-verification and quantitative matching. Its advantage lies in eliminating identity forgery and resource mismatches at the source, improving verification accuracy and task preparation efficiency, and laying a reliable data foundation for subsequent dispatch.

[0037] Furthermore, step 2 includes:

[0038] 2.1 Define task priorities and resource constraints, including:

[0039] Quantify task priorities and define task urgency E l :

[0040]

[0041] Prioritize E during scheduling l High task to good resource ValidV( i )=1∧Valid P (j) = 1;

[0042] Define resource load model, including calculation of vehicle real-time load rate Loadi (t):

[0043]

[0044] Among them, W Max，i The maximum load of the vehicle, the regulations limit the daily mileage to ≤ 300 kilometers;

[0045] 2.2 Construct a mixed integer programming model, including:

[0046] Construct an optimization function with time cost, risk cost, and load balancing as the goals:

[0047]

[0048] The constraints of the function are defined as follows:

[0049] Task assignment uniqueness: ∑ i，j x l，i，j =1, Permission match: x l，i，j Auth j ≥E l , Load limit: ∑ l : Assigned to V i W l ≤W Mmax，i , Time constraint: arrival time l Deadline l ,

[0050] The function's variables are defined as follows:

[0051] x l，i，j : 0-1 variable, 1 represents task T l Assigned to vehicle V i and personnel P j ; C t,l,i :Task T l By vehicle V i Time cost of execution; C r，l，i : route risk cost; γ: load balancing weight (take 0.3)

[0052] 2.3 Start iterating the optimization strategy, including

[0053] A hierarchical iterative algorithm is used to solve the model:

[0054] Initialization: Generate an initial allocation plan based on the nearest neighbor method and calculate the initial cost C init

[0055] Neighborhood search: Randomly swap the assigned vehicles of two tasks, generate a new solution and calculate the cost C new

[0056] Dynamic acceptance criteria:

[0057] Where T is the temperature parameter, which decays exponentially with the number of iterations;

[0058] The termination condition is set as follows: in a predefined number of consecutive iterations, the iteration cost decreases to a predefined threshold of ≤1% for 50 times, or the predefined maximum number of iterations is reached, 200 times.

[0059] By defining a quantitative model for task urgency, assigning priorities based on task type (3 for urgent, 2 for high-value, and 1 for ordinary), and combining the vehicle load factor formula (weighted by load percentage and mileage percentage) to establish resource constraints, the technology transforms scheduling into a mixed integer programming problem and solves the multi-objective function through iterative optimization. The advantage lies in breaking through the limitations of human experience and achieving global optimization of time, risk, and load. The system has reduced the idle rate to below 15%, ensured emergency task response times of ≤30 minutes, and significantly improved resource utilization and task execution efficiency.

[0060] Furthermore, step three includes:

[0061] 3.1 Real-time state perception network establishes an on-vehicle edge computing node and collects multi-dimensional data at a frequency of 10Hz:

[0062] Position data: Beidou positioning (x i (t), y i (t), z i (t)), error ≤ 0.1m;

[0063] Behavioral data: Analyze the escort's posture through camera j (t), determines whether the person is off-duty; the threshold is defined as being stationary for more than 30 seconds;

[0064] Environmental data: Door switch status Door i (t), compartment temperature and humidity (H i (t), T i (t))

[0065] 3.2 Abnormal event graded response defines a three-level alarm mechanism:

[0066] Level 1: The trigger condition is the illegal opening of the door i (t) = 1∧ non-loading and unloading time, the response strategy is to electromagnetically lock the vehicle door, transmit real-time video to the command center through 5G, and automatically send coordinates to the public security platform;

[0067] Level 2: The trigger condition is a route deviation of ≥200m for 5 minutes. The response strategy is for the edge node to generate three alternative routes, and the dispatch center to confirm whether to execute them within 10 minutes.

[0068] Level 3, the trigger condition is personnel fatigue coefficient Fatigue j ≥0.7, the response strategy is to provide onboard voice reminders, assign a rest stop nearby, and adjust the order of tasks;

[0069] 3.3 Dynamic Rebalancing of Resources

[0070] Designing regional resource pools Include:

[0071] Idle resources:

[0072] Neighboring resources:

[0073] Backup resources

[0074] Replace the priority function:

[0075] AuthMatch(V i ) is 1 when the vehicle-associated personnel authority matches the task level, otherwise it is 0.

[0076] A three-level alert mechanism is established by using onboard edge nodes to collect multi-dimensional data at high frequencies (such as 10Hz Beidou positioning and gesture recognition). The technology relies on real-time anomaly detection and tiered responses, combined with priority scheduling from regional resource pools. The advantages include responding to high-risk incidents within 5 seconds and completing route replanning within 10 minutes, reducing security incident processing time from 10 minutes to under 5 minutes, dynamically mitigating risks and improving emergency response efficiency.

[0077] Furthermore, step four includes:

[0078] 4.1 Establish a blockchain evidence storage system and build a consortium chain to store key data:

[0079] 4.1.1 The symbols are defined as follows:

[0080] A collection of alliance chain nodes, N1 is the primary node, and the rest are backup nodes;

[0081] View: current view number, initially 0;

[0082] m: transaction data to be stored, such as task assignments and identity verification results;

[0083] d(m): SHA-256 hash value of data m,

[0084] PrePrepare, Prepare, Commit: consensus phase message types;

[0085] Q c : quorum, p is the total number of nodes;

[0086] Execute the preparatory phase, including:

[0087] Masternode broadcast:

[0088] The master node N1 receives the evidence request data m, generates a unique block number block_id, calculates the hash h=d(m), and sends it to all backup nodes. BroadcastPrePrepare(block_id, VIew, h, m).

[0089] Backup node verification:

[0090] Verification of each node:

[0091] Data Integrity:

[0092] View validity: whether the current view is a View

[0093] Block uniqueness: No request with the same block_id has been received. If the verification passes, the process enters the preparation phase.

[0094] The execution preparation phase includes:

[0095] Backup node response: Each node N i Broadcast Prepare(block_id, View, h, PID) to other nodes i ), PID i is the node identity;

[0096] Quorum confirmation: Node N i Collect Q c -1 valid Prepare message (including itself). After verifying that the block_id, View, and h of all messages are consistent, it enters the submission phase;

[0097] Execute the commit phase, which includes:

[0098] Submit confirmation broadcast: Node N i Broadcast Commit(block_id, View, h, PID) to the entire network i );

[0099] Final confirmation: Nodes collect Q cAfter receiving a valid Commit message, the block is confirmed to be legal, the data is written to the local ledger, and the view is updated:

[0100]

[0101] Execute the view switching phase, including:

[0102] When the master node fails, if PrePrepare is not sent within the timeout period, a view switch is triggered:

[0103] Node N i Broadcast ViewChange(View+1, last_valid_block), where last_valid_block is the last valid block;

[0104] Collect Q c After ViewChange messages, a new master node N is elected new =(N1+1)mod p, update View=View+1, and re-enter the pre-preparation phase;

[0105] 4.1.2 Data Encryption and Storage

[0106] Processing of sensitive data, including:

[0107] The biometric F j 、Route coordinatesRoute l Sensitive information such as ciphertext and ciphertext is encrypted using the following formula:

[0108] E(m)=AES-256(m,k), D(E(m))=m;

[0109] Among them, the key k is distributed by the alliance chain management node;

[0110] The block storage structure is defined as:

[0111] The field block_id, of type String, is a unique block number consisting of a timestamp and a random number.

[0112] The field View, of type Int, is the current view number;

[0113] Field h, of type String, is the data hash value;

[0114] Field m enc , of type String, is the encrypted evidence data;

[0115] The field Sign, of type String, is the node digital signature;

[0116] 4.2 Compliance report generation Automatically generate escort mission audit reports.

[0117] Furthermore, the escort mission audit report includes:

[0118] Track playback: 3D route animation based on Beidou coordinates, time axis error ≤ 1 second;

[0119] Operation log: personnel check-in / check-out time, abnormal event handling records;

[0120] Performance indicators: mission punctuality, vehicle idle rate, abnormal response time and

[0121] This consortium blockchain utilizes a three-phase consensus process: pre-prepare, prepare, and commit, ensuring data immutability. Sensitive data is stored with AES-256 encryption, and compliance reports with track playback and operation logs are automatically generated. This technology leverages blockchain distributed storage and encryption to achieve end-to-end evidence storage. The advantages include generating audit reports within 10 minutes, achieving data traceability accuracy within seconds, and improving compliance to over 99%, addressing traditional data fragmentation and audit inefficiencies. BRIEF DESCRIPTION OF THE DRAWINGS

[0122] The present invention will be further described below with reference to the accompanying drawings and examples.

[0123] Figure 1 , Schematic diagram of the unified scheduling algorithm based on remote identification of financial escort vehicles and escort personnel in Example 1. DETAILED DESCRIPTION

[0124] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0125] Example 1

[0126] This embodiment provides a unified dispatching algorithm based on remote identification of financial escort vehicles and escort personnel, such as Figure 1 , the scheduling algorithm includes:

[0127] Step 1: Multidimensional Data Modeling and Identity Verification: Define the Vehicle Set Personnel gathering Task Collection Build a structured data model that includes attributes such as unique identification, real-time status, and permission level, and ensure the legitimacy of vehicles, people, and tasks through triple verification, including vehicle physical identity verification, person biometric chain verification, and task and resource pre-matching verification;

[0128] Step 2: Build a multi-objective intelligent scheduling algorithm: Based on the task priority and resource load model, a mixed integer programming objective function is constructed. The task allocation scheme is solved through iterative optimization strategy to achieve the global optimization of time cost, risk cost, and load balance.

[0129] Step 3: Dynamic Monitoring and Emergency Response: Vehicle-mounted edge nodes collect multi-dimensional data in real time, establish a three-level alarm mechanism, and combine regional resource pools to achieve hierarchical response to abnormal events and dynamic resource rebalancing.

[0130] Step 4: Full-process data storage and compliance management, build a consortium chain, encrypt and store key operation data, and automatically generate compliance audit reports.

[0131] This embodiment forms an intelligent management system for the entire financial escort process by constructing a four-layer technical architecture encompassing multidimensional data modeling and identity verification, multi-objective intelligent scheduling, dynamic monitoring and emergency response, and full-process data storage and compliance management. First, a structured data model for vehicles, personnel, and tasks is defined. A triple verification mechanism for task-resource pre-matching is implemented by cross-verifying vehicle legitimacy with RFID and OBD data, comparing personnel biometrics with a structured light camera and a public security database, and integrating distance and authority weights into a matching function. This eliminates identity forgery and resource mismatches at the source. A mixed integer programming objective function is then constructed based on task priority and resource load. Task allocation solutions are iteratively optimized using a simulated annealing algorithm. By integrating multiple factors, including time cost, risk cost, and load balancing, the idle rate is reduced from over 25% in the traditional model to below 15%, and emergency response time is compressed to within 30 minutes, addressing the inefficiency caused by manual scheduling that relies on experience and single-dimensional optimization. At the same time, on-board edge nodes collect multi-dimensional data such as 10Hz Beidou positioning and escort posture at high frequency, establishing a three-level alarm mechanism. This triggers a response within 5 seconds for emergencies such as illegal door openings, and dynamically replans within 10 minutes for medium-risk situations such as route deviations. Combined with regional resource pool priority scheduling strategies, this reduces security incident processing time from 10 minutes to less than 5 minutes. High-risk areas are proactively avoided and the risk cost is quantified (high-risk area coefficient × 1.5), enhancing the system's risk resistance. Finally, a PBFT consortium chain is used to implement AES-256 encrypted evidence storage for key data. A three-phase consensus process, pre-prepare-prepare-submit, ensures that data cannot be tampered with. Compliance reports, including trajectory playback and operation logs, are automatically generated, reducing audit time from two hours of manual work to less than 10 minutes, addressing the traditional issues of data fragmentation and difficulty in compliance traceability. The overall solution systematically improves the efficiency (task execution efficiency increased by 50%+), security (identity misrecognition rate ≤ 1%) and compliance (real-time supervision adaptation) of financial escort through data-driven intelligent decision-making, dynamic response and blockchain evidence storage, breaking through the technical bottlenecks of low efficiency, multiple security vulnerabilities and chaotic data management in the traditional model.

[0132] In the above scheme, for further optimization, step 1 includes:

[0133] Step 1.1: Define the basic data structure and define the core entity set of the financial escort system, including:

[0134] is a vehicle set containing each vehicle V i Associated properties:

[0135] VID i : Unique identification of the vehicle, which can be achieved by RFID coding;

[0136] Status i (t): Real-time state vector, including GPS coordinates (x i (t), y i (t)), load W i (t), fuel quantity Fx(t);

[0137] is a set of personnel, including each person P j Association attributes;

[0138] PID j : Personnel unique identification, which includes a biometric hash value;

[0139] Auth j : permission level;

[0140] is a set of tasks, including each task T l Associated properties:

[0141] TID l : Unique ID of the task

[0142] Typex: Task type, including urgent, high-value, and ordinary task types;

[0143] Route l :Preset route coordinate sequence [(x l1 ,y l1 ),...,(x le ,y le )]

[0144] Step 1.2: Set up a dynamic identity verification model and design a triple verification mechanism to ensure the legitimacy of the vehicle, person, and task, including;

[0145] Step 1.2.1, vehicle physical identity verification, obtain VID through the reader i, compare static information such as vehicle model and annual inspection status with the vehicle management office database, and analyze OBD data to verify dynamic status:

[0146]

[0147] Among them, MinFuel is the minimum fuel threshold;

[0148] Step 1.2.2: Verify the biometric chain of the person, and collect 3D facial data F through a structured light camera j , and the characteristics of the public security database Calculate cosine similarity:

[0149]

[0150] Among them, TaskLevel l It is the task level requirement;

[0151] Step 1.2.3: Pre-match tasks and resources, including:

[0152] Establish the association matrix M between tasks and vehicles / personnel l，i，j , define the matching function:

[0153] M l，i，j =α·Dis(V i , T l )+β·AuthMatch(P j , T l )

[0154] Where: Dis(V i , T l ) represents the normalized Euclidean distance from the vehicle’s current location to the mission starting point, AuthMatch(P j , T l ) indicates the permission matching degree, A-level tasks require Auth j =A, it is 1, otherwise it is 0; pre-α + β = 1, it is necessary to prioritize authority matching, β = 0.7.

[0155] By defining a structured data model for vehicles, personnel, and tasks, RFID and OBD are used to cross-verify vehicle identities. Structured light cameras are used in conjunction with public security databases to verify personnel biometrics. Finally, a matching function is used to combine distance and authority weights to pre-match task resources. This technology utilizes multi-dimensional data cross-verification and quantitative matching. Its advantage lies in eliminating identity forgery and resource mismatches at the source, improving verification accuracy and task preparation efficiency, and laying a reliable data foundation for subsequent dispatch.

[0156] Furthermore, step 2 includes:

[0157] 2.1 Define task priorities and resource constraints, including:

[0158] Quantify task priorities and define task urgency E l :

[0159]

[0160] Prioritize E during scheduling l High tasks to resources with good status Valid V (i)=1∧Valid P (j) = 1;

[0161] Define resource load model, including calculation of vehicle real-time load rate Load i (t):

[0162]

[0163] Among them, W Max，i The maximum load of the vehicle, the regulations limit the daily mileage to ≤ 300 kilometers;

[0164] 2.2 Construct a mixed integer programming model, including:

[0165] Construct an optimization function with time cost, risk cost, and load balancing as the goals:

[0166]

[0167] The constraints of the function are defined as follows:

[0168] Task assignment uniqueness: ∑ i，j x l，i，j =1, Permission match: x l，i，j Auth j ≥E l , Load limit: ∑ l : Assigned to V i W l ≤W Max，i , Time constraint: arrival time l ≤Deadlinex,

[0169] The function's variables are defined as follows:

[0170] x l，i，j : 0-1 variable, 1 represents task T l Assigned to vehicle V i and personnel P j ; C t，l，i :Task Tl By vehicle V i Time cost of execution; C r，l，i : route risk cost; γ: load balancing weight (take 0.3)

[0171] 2.3 Start iterating the optimization strategy, including

[0172] A hierarchical iterative algorithm is used to solve the model:

[0173] Initialization: Generate an initial allocation plan based on the nearest neighbor method and calculate the initial cost C init

[0174] Neighborhood search: Randomly swap the assigned vehicles of two tasks, generate a new solution and calculate the cost C new

[0175] Dynamic acceptance criteria:

[0176] Where T is the temperature parameter, which decays exponentially with the number of iterations;

[0177] The termination condition is set as follows: in a predefined number of consecutive iterations, the iteration cost decreases to a predefined threshold of ≤1% for 50 times, or the predefined maximum number of iterations is reached, 200 times.

[0178] By defining a quantitative model for task urgency, assigning priorities based on task type (3 for urgent, 2 for high-value, and 1 for ordinary), and combining the vehicle load factor formula (weighted by load percentage and mileage percentage) to establish resource constraints, the technology transforms scheduling into a mixed integer programming problem and solves the multi-objective function through iterative optimization. The advantage lies in breaking through the limitations of human experience and achieving global optimization of time, risk, and load. The system has reduced the idle rate to below 15%, ensured emergency task response times of ≤30 minutes, and significantly improved resource utilization and task execution efficiency.

[0179] Furthermore, step three includes:

[0180] 3.1 Real-time state perception network establishes an on-vehicle edge computing node and collects multi-dimensional data at a frequency of 10Hz:

[0181] Position data: Beidou positioning (x i (t), y i (t), z i (t)), error ≤ 0.1m;

[0182] Behavioral data: Analyze the escort's posture through camera j (t), determines whether the person is off-duty; the threshold is defined as being stationary for more than 30 seconds;

[0183] Environmental data: Door switch status Door i(t), compartment temperature and humidity (H i (t), T i (t))

[0184] 3.2 Abnormal event graded response defines a three-level alarm mechanism:

[0185] Level 1: The trigger condition is the illegal opening of the door i (t) = 1∧ non-loading and unloading time, the response strategy is to electromagnetically lock the vehicle door, transmit real-time video to the command center through 5G, and automatically send coordinates to the public security platform;

[0186] Level 2: The trigger condition is a route deviation of ≥200m for 5 minutes. The response strategy is for the edge node to generate three alternative routes, and the dispatch center to confirm whether to execute them within 10 minutes.

[0187] Level 3, the trigger condition is personnel fatigue coefficient Fatigue j ≥0.7, the response strategy is to provide onboard voice reminders, assign a rest stop nearby, and adjust the order of tasks;

[0188] 3.3 Dynamic Rebalancing of Resources

[0189] Designing regional resource pools Include:

[0190] Idle resources:

[0191] Neighboring resources:

[0192] Backup resources

[0193] Replace the priority function:

[0194] AuthMatch(V i ) is 1 when the vehicle-associated personnel authority matches the task level, otherwise it is 0.

[0195] A three-level alert mechanism is established by using onboard edge nodes to collect multi-dimensional data at high frequencies (such as 10Hz Beidou positioning and gesture recognition). The technology relies on real-time anomaly detection and tiered responses, combined with priority scheduling from regional resource pools. The advantages include responding to high-risk incidents within 5 seconds and completing route replanning within 10 minutes, reducing security incident processing time from 10 minutes to under 5 minutes, dynamically mitigating risks and improving emergency response efficiency.

[0196] Furthermore, step four includes:

[0197] 4.1 Establish a blockchain evidence storage system and build a consortium chain to store key data:

[0198] 4.1.1 The symbols are defined as follows:

[0199] A collection of alliance chain nodes, N1 is the primary node, and the rest are backup nodes;

[0200] View: current view number, initially 0;

[0201] m: transaction data to be stored, such as task assignments and identity verification results;

[0202] d(m): SHA-256 hash value of data m,

[0203] Preprepare, Prepare, Commit: consensus phase message types;

[0204] Q c : quorum, p is the total number of nodes;

[0205] Execute the preparatory phase, including:

[0206] Masternode broadcast:

[0207] The master node N1 receives the evidence request data m, generates a unique block number block_id, calculates the hash h=d(m), and sends it to all backup nodes. BroadcastPrePrepare(block_id, View, h, m).

[0208] Backup node verification:

[0209] Verification of each node:

[0210] Data Integrity:

[0211] View validity: whether the current view is a View

[0212] Block uniqueness: No request with the same block_id has been received. If the verification passes, the process enters the preparation phase.

[0213] The execution preparation phase includes:

[0214] Backup node response: Each node N i Broadcast Prepare(block_id, View, h, PID) to other nodes i ), PID i is the node identity;

[0215] Quorum confirmation: Node N i Collect Q c-1 valid Prepare message (including itself). After verifying that the block_id, View, and h of all messages are consistent, it enters the submission phase;

[0216] Execute the commit phase, which includes:

[0217] Submit confirmation broadcast: Node N i Broadcast Commit(block_id, View, h, PID) to the entire network i );

[0218] Final confirmation: Nodes collect Q c After receiving a valid Commit message, the block is confirmed to be legal, the data is written to the local ledger, and the view is updated:

[0219]

[0220] Execute the view switching phase, including:

[0221] When the master node fails, if PrePrepare is not sent within the timeout period, a view switch is triggered:

[0222] Node N i Broadcast ViewChange(View+1, last_valid_block), where last_valid_block is the last valid block;

[0223] Collect Q c After ViewChange messages, a new master node N is elected new =(Nx+1)mod p, update View=View+1, and re-enter the pre-preparation phase;

[0224] 4.1.2 Data Encryption and Storage

[0225] Processing of sensitive data, including:

[0226] The biometric F j 、Route coordinatesRoute l Sensitive information such as ciphertext and ciphertext is encrypted using the following formula:

[0227] E(m)=AES-256(m,k), D(E(m))=m;

[0228] Among them, the key k is distributed by the alliance chain management node;

[0229] The block storage structure is defined as:

[0230] The field block_id, of type String, is a unique block number consisting of a timestamp and a random number.

[0231] The field View, of type Int, is the current view number;

[0232] Field h, of type String, is the data hash value;

[0233] Field m enc , of type String, is the encrypted evidence data;

[0234] The field Sign, of type String, is the node digital signature;

[0235] 4.2 Compliance report generation Automatically generate escort mission audit reports.

[0236] Furthermore, the escort mission audit report includes:

[0237] Track playback: 3D route animation based on Beidou coordinates, time axis error ≤ 1 second;

[0238] Operation log: personnel check-in / check-out time, abnormal event handling records;

[0239] Performance indicators: mission punctuality, vehicle idle rate, abnormal response time and

[0240] This consortium blockchain utilizes a three-phase consensus process: pre-prepare, prepare, and commit, ensuring data immutability. Sensitive data is stored with AES-256 encryption, and compliance reports with track playback and operation logs are automatically generated. This technology leverages blockchain distributed storage and encryption to achieve end-to-end evidence storage. The advantages include generating audit reports within 10 minutes, achieving data traceability accuracy within seconds, and improving compliance to over 99%, addressing traditional data fragmentation and audit inefficiencies.

[0241] Unless otherwise specified, the formulas and symbols in this embodiment are based on existing definitions, and the specific values ​​of the parameters can be adjusted and changed as required. Although the above describes the illustrative embodiments of the present invention to facilitate understanding of the present invention by those skilled in the art, the present invention is not limited to the scope of the specific embodiments. For those skilled in the art, as long as various changes are within the spirit and scope of the present invention as defined and determined by the appended claims, all inventions and creations based on the present invention are protected.

Claims

1. A unified dispatching algorithm based on remote identification of financial escort vehicles and escort personnel, characterized by: The scheduling algorithm includes: Step 1: Multidimensional Data Modeling and Identity Verification: Define the Vehicle Set Personnel gathering Task Collection Build a structured data model that includes attributes such as unique identification, real-time status, and permission level, and ensure the legitimacy of vehicles, people, and tasks through triple verification, including vehicle physical identity verification, person biometric chain verification, and task and resource pre-matching verification; Step 2: Build a multi-objective intelligent scheduling algorithm: Based on the task priority and resource load model, a mixed integer programming objective function is constructed. The task allocation scheme is solved through iterative optimization strategy to achieve the global optimization of time cost, risk cost, and load balance. Step 3: Dynamic Monitoring and Emergency Response: Vehicle-mounted edge nodes collect multi-dimensional data in real time, establish a three-level alarm mechanism, and combine regional resource pools to achieve hierarchical response to abnormal events and dynamic resource rebalancing. Step 4: Full-process data storage and compliance management, build a consortium chain, encrypt and store key operation data, and automatically generate compliance audit reports.

2. The unified dispatching algorithm based on remote identification of financial escort vehicles and escort personnel according to claim 1 is characterized by: Step one includes: Step 1.1: Define the basic data structure and define the core entity set of the financial escort system, including: is a vehicle set containing each vehicle V i Associated properties: VID i : Unique identification of the vehicle, which can be achieved by RFID coding; Status i (t): Real-time state vector, including GPS coordinates (x i (t),y i (t)), load W i (t), fuel quantity F i (t); is a set of personnel, including each person P j Association attributes; PID j : Personnel unique identification, which includes a biometric hash value; Auth j : permission level; is a set of tasks, including each task T l Associated properties: TID l : Unique ID of the task Type l : Task type, including urgent, high-value, and ordinary task types; Route l :Preset route coordinate sequence [(x l1 ,y l1 ),...,(x le ,y le )] Step 1.2: Set up a dynamic identity verification model and design a triple verification mechanism to ensure the legitimacy of the vehicle, person, and task, including; Step 1.2.1, vehicle physical identity verification, obtain VID through the reader i , compare static information such as vehicle model and annual inspection status with the vehicle management office database, and analyze OBD data to verify dynamic status: Among them, MinFuel is the minimum fuel threshold; Step 1.2.2: Verify the biometric chain of the person, and collect 3D facial data F through a structured light camera j , and the characteristics of the public security database Calculate cosine similarity: Among them, TaskLevel l It is the task level requirement; Step 1.2.3: Pre-match tasks and resources, including: Establish the association matrix M between tasks and vehicles / personnel l，i，j , define the matching function: M l,i,j =α·Dis(V i ,T l )+β·AuthMatch(P j ,T l ) Where: Dis(V i , T l ) represents the normalized Euclidean distance from the vehicle’s current location to the mission starting point, AuthMatch(P j , T l ) represents the authority matching degree; α+β=1.

3. The unified dispatching algorithm based on remote identification of financial escort vehicles and escort personnel according to claim 1 is characterized by: Step 2 includes: 2.1 Define task priorities and resource constraints, including: Quantify task priorities and define task urgency E l : Prioritize E during scheduling l High tasks to resources with good status Valid V (i)=1∧Valid P (j) = 1; Define resource load model, including calculation of vehicle real-time load rate Load i (t): Among them, W Max，i The maximum load of the vehicle, the regulations limit the daily mileage to ≤ 300 kilometers; 2.2 Construct a mixed integer programming model, including: Construct an optimization function with time cost, risk cost, and load balancing as the goals: The constraints of the function are defined as follows: Task assignment uniqueness: Permission matching: Load limit: Time constraint: arrival time l≤Deadline l , The function's variables are defined as follows: x l，i，j : 0-1 variable, 1 represents task T l Assigned to vehicle V i and personnel P j ; C t，l，i :Task T l By vehicle V i Time cost of execution; C r，l，i : route risk cost; γ: load balancing weight (take 0.3) 2.3 Start iterating the optimization strategy, including A hierarchical iterative algorithm is used to solve the model: Initialization: Generate an initial allocation plan based on the nearest neighbor method and calculate the initial cost C init Neighborhood search: Randomly swap the assigned vehicles of two tasks, generate a new solution and calculate the cost C new Dynamic acceptance criteria: Where T is the temperature parameter, which decays exponentially with the number of iterations; The termination condition is set as follows: after a predefined number of consecutive iterations, the iteration cost drops to a predefined threshold, or the predefined maximum number of iterations is reached.

4. The unified dispatching algorithm based on remote identification of financial escort vehicles and escort personnel according to claim 1 is characterized by: Step three includes: 3.1 Real-time state perception network establishes an on-vehicle edge computing node and collects multi-dimensional data at a frequency of 10Hz: Position data: Beidou positioning (x i (t), y i (t), z i (t)), error ≤ 0.1m; Behavioral data: Analyze the escort's posture through camera j (t), determines whether the person is off-duty; the threshold is defined as the time when the person is stationary for more than a preset time; Environmental data: Door switch status Door i (t), compartment temperature and humidity (H i (t), T i (t)) 3.2 Abnormal event graded response defines a three-level alarm mechanism: Level 1: The trigger condition is the illegal opening of the door i (t) = 1∧ non-loading and unloading time, the response strategy is to electromagnetically lock the vehicle door, transmit real-time video to the command center through 5G, and automatically send coordinates to the public security platform; Level 2: The trigger condition is that the route deviation exceeds the threshold for a duration exceeding a predefined parameter. The response strategy is that the edge node generates an alternative route and the dispatch center confirms whether to execute it within a predefined time; Level 3, the trigger condition is personnel fatigue coefficient Fatigue j ≥0.7, the response strategy is to provide onboard voice reminders, assign a rest stop nearby, and adjust the order of tasks; 3.3 Dynamic Rebalancing of Resources Designing regional resource pools Include: Idle resources: Neighboring resources: Backup resources Replace the priority function: AuthMatch(V i ) is 1 when the vehicle-associated personnel authority matches the task level, otherwise it is 0.

5. The unified dispatching algorithm based on remote identification of financial escort vehicles and escort personnel according to claim 1 is characterized by: Step 4 includes: 4.1 Establish a blockchain evidence storage system and build a consortium chain to store key data: 4.1.1 The symbols are defined as follows: A collection of alliance chain nodes, N1 is the primary node, and the rest are backup nodes; View: current view number, initially 0; m: transaction data to be stored, such as task assignments and identity verification results; d(m): SHA-256 hash value of data m, PrePrepare, Prepare, Commit: consensus phase message types; Q c : quorum, p is the total number of nodes; Execute the preparatory phase, including: Masternode broadcast: The master node N1 receives the evidence request data m, generates a unique block number block_id, calculates the hash h=d(m), and sends it to all backup nodes. BroadcastPrePrepare(block_id, View, h, m). Backup node verification: Verification of each node: Data Integrity: View validity: whether the current view is a View Block uniqueness: No request with the same block_id has been received. If the verification passes, the process enters the preparation phase. The execution preparation phase includes: Backup node response: Each node N i Broadcast Prepare(block_id, View, h, PID) to other nodes i ), PID i is the node identity; Quorum confirmation: Node N i Collect Q c -1 valid Prepare message (including itself). After verifying that the block_id, View, and h of all messages are consistent, it enters the submission phase; Execute the commit phase, which includes: Submit confirmation broadcast: Node N i Broadcast Commit(block_id, View, h, PID) to the entire network i ); Final confirmation: Nodes collect Q c After receiving a valid Commit message, the block is confirmed to be legal, the data is written to the local ledger, and the view is updated: Execute the view switching phase, including: When the master node fails, if PrePrepare is not sent within the timeout period, a view switch is triggered: Node N i Broadcast ViewChange(View+1, last_valid_block), where last_valid_block is the last valid block; Collect Q c After ViewChange messages, a new master node N is elected new =(N1+1)mod p, update View=View+1, and re-enter the pre-preparation phase; 4.1.2 Data Encryption and Storage Processing of sensitive data, including: The biometric F j 、Route coordinatesRoute l Sensitive information such as ciphertext and ciphertext is encrypted using the following formula: E(m)=AES-256(m,k), D(E(m))=m; Among them, the key k is distributed by the alliance chain management node; The block storage structure is defined as: The field block_id, of type String, is a unique block number consisting of a timestamp and a random number. The field View, of type Int, is the current view number; Field h, of type String, is the data hash value; Field m enc , of type String, is the encrypted evidence data; The field Sign, of type String, is the node digital signature; 4.2 Compliance report generation Automatically generate escort mission audit reports.

6. The unified dispatching algorithm based on remote identification of financial escort vehicles and escort personnel according to claim 5 is characterized by: The escort mission audit report includes: Track playback: 3D route animation based on Beidou coordinates; Operation log: personnel check-in / check-out time, abnormal event handling records; Performance indicators: mission punctuality, vehicle idle rate, abnormal response time and

Images