Electric vehicle ordered charging system and method based on artificial intelligence

Abstract

The invention discloses an electric vehicle ordered charging system and method based on artificial intelligence, relates to the technical field of electric vehicle charging, and aims to solve the problems that non-subjective default judgment of an existing charging pile reservation system lacks credible verification and is prone to misjudgment. The method comprises the following steps: establishing an alliance chain evidence storage network containing nodes such as a high-speed management bureau and a navigation platform, and uploading original data with an identifier and generating a hash value by the nodes; when default is detected, multi-source data meeting time and space conditions are screened, after smart contract cross validation, an anti-fact causal reasoning model is input, and a causal graph is constructed to calculate a causal probability so as to judge a direct causal relationship; generating a credible report containing a Hash value and a verification process, storing an evidence on a chain, pushing the report, and optimizing a node data range and a model parameter according to user feedback; the system comprises six cooperation modules, and the judgment credibility and the high-speed service area energy complementing efficiency are improved.

Description

Technical Field

[0001] This invention relates to the field of electric vehicle charging technology, specifically to an artificial intelligence-based orderly charging system and method for electric vehicles. Background Technology

[0002] With the increasing demand for long-distance electric vehicle travel, the electric vehicle charging station reservation system in highway service areas has become a key energy replenishment guarantee. Its core function is to allocate charging resources through the reservation mechanism, reduce users' on-site queuing time, and improve the efficiency of orderly charging.

[0003] However, the existing reservation system has a significant flaw in the determination of "default due to non-subjective factors". The existing technology relies on data from a single source, such as navigation traffic jam records or charging pile fault logs, and the authenticity of the data cannot be guaranteed. Moreover, it does not verify the direct causal relationship between non-subjective factors and default, and it is easy to misjudge "data coincidence" as "non-subjective default". For example, if a traffic jam occurs but the user has taken a detour, and the time is still exceeded for other reasons, it may be judged as being caused by traffic jam.

[0004] Such unreliable judgments can directly trigger a chain reaction: on the one hand, users are often marked as defaulters due to misjudgments, resulting in damage to their reservation credit and restrictions on subsequent reservation privileges, which seriously affects the user experience; on the other hand, users' trust in the judgment results continues to decrease, and they gradually abandon the reservation system and choose the plug-and-charge mode instead, which leads to chaotic allocation of charging resources, ultimately reducing the overall energy replenishment efficiency of highway service areas and causing inconvenience to other users with genuine reservation needs.

[0005] To address the above problems, this invention proposes an orderly charging system and method for electric vehicles based on artificial intelligence. Summary of the Invention

[0006] The purpose of this invention is to provide an artificial intelligence-based orderly charging system and method for electric vehicles to solve the problems raised in the prior art.

[0007] To achieve the above objectives, the present invention provides the following technical solution: An artificial intelligence-based method for orderly charging of electric vehicles includes the following steps: S1. Build a consortium blockchain evidence storage network that is not determined by subjective factors. Select consortium blockchain nodes, and each node uploads the original data of the corresponding scenario. After the data is uploaded, a unique hash value is generated. S2. When the system detects that the user has not completed charging within the scheduled time period, it triggers the non-subjective factor judgment process. For the data where the time deviation between the default event and the non-subjective factor data meets the preset time deviation threshold and there are at least two types of nodes in the consortium blockchain, cross-validation is performed. S3. Cross-validate the multi-source data that meets the conditions in S2 through the consortium blockchain smart contract, and input the data that passes all the verifications into the counterfactual causal reasoning model. S4. After receiving the verified data, the counterfactual causal reasoning model performs counterfactual simulation by constructing a causal graph with a preset structure, calculates the probability of causal necessity between non-subjective factors and breach of contract, and determines that there is a direct causal relationship if the probability reaches a preset probability threshold. S5. Generate a trusted report based on the judgment results. The report includes the hash value of the original data of each node, the cross-validation results, the calculation process of the causal necessity probability, and the final judgment conclusion. S6. Push trusted reports to users, collect user feedback on the judgment results, and regularly optimize the data range of the consortium blockchain nodes and the parameters of the counterfactual causal reasoning model based on the feedback data. The optimization results are synchronized to the consortium blockchain smart contract.

[0008] S1 further includes the following: S1.1: The highway administration bureau, navigation platform, car manufacturer, and charging pile manufacturer are selected as fixed nodes of the consortium blockchain. Each node is only responsible for the collection and uploading of raw data in the corresponding scenario, and there is no data modification permission between nodes. They can only view the public data with hash values ​​that have been uploaded by themselves and other nodes. Among them, the highway administration bureau node uploads real-time traffic data and traffic event records within a preset range around the service area; the navigation platform node uploads the planned route data and real-time congestion status data within the user's reservation time period; the car manufacturer node uploads the user's vehicle departure record, real-time driving trajectory data, and vehicle operation status data; and the charging pile manufacturer node uploads the operation status data and fault record data of the reserved charging pile. S1.2: Each node continuously uploads the corresponding type of raw data at a preset frequency. When data is uploaded, the consortium blockchain system generates a unique hash value, which is then bound to the corresponding raw data for storage. In addition, each piece of raw data uploaded by each node must carry identification information in a unified format. The identification information includes the data collection timestamp, the physical location identifier associated with the data, and the identifier of the node to which the data belongs. The physical location identifier adopts a preset geocoding format.

[0009] S2 further includes the following: S2.1: When the system detects that a user has not completed charging within the reserved time period, it extracts the information corresponding to the breach event from the reservation system. The information specifically includes the user identifier, the reserved time period, the associated charging pile identifier, and the time of the breach event. Among them, the associated charging pile identifier must correspond to the physical location identifier carried in the operation status data and fault record data of the reserved charging pile uploaded by the charging pile manufacturer node in S1.1, and the user identifier must correspond to the user vehicle information associated with the user vehicle's departure record, real-time driving trajectory data, and vehicle operation status data uploaded by the vehicle manufacturer node in S1.1. S2.2: Based on the information extracted in S2.1, retrieve non-subjective factor data related to the default event from the consortium blockchain. The retrieval process uses the reservation period corresponding to the default event as the time reference range and the physical location corresponding to the associated charging pile identifier as the spatial reference range. It filters the original data within the aforementioned time and spatial reference ranges from the following: real-time traffic conditions and traffic event records uploaded by the highway administration node, the planned route data and real-time congestion status data uploaded by the navigation platform node during the user's reservation period, the departure records, real-time driving trajectory data, and vehicle operation status data uploaded by the car manufacturer node, and the operation status data and fault record data of the reserved charging pile uploaded by the charging pile manufacturer node. Simultaneously, it records the node type of each retrieved data in real time. S2.3: Based on the setting in S1.2 that each piece of raw data uploaded by each node must carry a unified format of identification information, the collection timestamp of non-subjective factor data is calibrated with the occurrence time of the default event extracted in S2.1; Then, the effective time interval is determined based on the type characteristics of non-subjective factor data: The real-time traffic data from the highway administration node and the real-time congestion data from the navigation platform node are used as continuous time-series data. The effective time interval is from the start time corresponding to the data collection timestamp to the next data collection time of the same type. The vehicle departure records from the car manufacturer's node and the fault records from the charging pile manufacturer's node are instantaneous data, and their effective time interval is from the moment corresponding to the data collection timestamp to the end of the data-related event. Finally, the overlap duration between the target time interval where the default event occurred and the valid time interval of the non-subjective factor data is calculated. If the overlap duration accounts for a proportion of the duration of the default event that meets the preset proportion requirement, and the difference between the start time and the difference between the end time of the two time intervals both meet the preset time deviation threshold, and the number of node types to which the retrieved data belongs reaches at least two, then the non-subjective factor data is determined as multi-source data that meets the conditions and is used to perform cross-validation in S3. If any of the above conditions are not met, the non-subjective factor determination process is terminated.

[0010] S3 further includes the following: S3.1: Retrieve the multi-source data that meets the conditions determined in S2.3, extract the unified format identification information carried by each data, and at the same time, retrieve the unique hash value corresponding to each data chain through the consortium blockchain smart contract, associate it with the type range of data uploaded by each node in S1.1, and confirm the matching of data source with power saving function; S3.2: Cross-validate the preprocessed multi-source data in terms of temporal consistency, spatial consistency, and logical consistency using consortium blockchain smart contracts. Regarding time consistency verification: Compare the effective time intervals of data from different nodes to confirm whether the overlap between the effective time intervals of each node's data and the target time interval of the default event is consistent, and whether the difference between the start and end times of the effective time intervals between each node's data meets the preset verification rules. These rules must be consistent with the logic for determining time deviation in S2.3. In terms of spatial consistency verification: By comparing the physical location identifiers associated with the data of each node, it is confirmed that the service area preset surrounding range of the highway administration node data, the route associated location of the navigation platform node data, and the charging pile location of the charging pile manufacturer node data all correspond to the same physical area, and the physical location identifiers conform to the preset geocoding format in S1.2. Regarding logical consistency verification: Based on the functional attributes of each node's data in S1.1, verify the inherent logical relationships between different node data; the abnormal road condition data recorded by the highway administration node must match the corresponding road segment congestion data recorded by the navigation platform node; the fault data recorded by the charging pile manufacturer node must match the description of the user's inability to start charging; the vehicle driving trajectory data recorded by the car manufacturer node must match the traffic status reflected in the road condition data; eliminate situations where there are logical contradictions between data. S3.3: Execute a judgment based on the results of cross-validation. Only when all three validations of time consistency, spatial consistency, and logical consistency pass, will this batch of multi-source data be marked as validated and a structured validation report containing the validation results of each dimension be generated. If any dimension fails, the smart contract will terminate this non-subjective factor judgment process.

[0011] S4 further includes the following: S4.1: Map the validated data to structured variables that can be identified by the counterfactual causal reasoning model according to the logic of non-subjective factor type-data attribute-variable value; among them, real-time traffic data from the highway administration node is mapped to traffic anomaly variables, real-time congestion status data from the navigation platform node is mapped to route congestion variables, fault record data from the charging pile manufacturer node is mapped to equipment fault variables, and vehicle driving trajectory data from the car manufacturer node is mapped to user driving status variables; at the same time, map the information such as the occurrence time of the default event and the reservation time period extracted in S2.1 to default status variables, ensuring that all input variables correspond one-to-one with the node definitions of the subsequent causal graph; S4.2: Based on the mapped structured variables, construct a causal graph with a predefined structure. The causal graph contains three types of nodes and causal edges between nodes: The first category is the dependent variable node D, which corresponds to the set of non-subjective factors, specifically including abnormal road conditions D1, route congestion D2, and equipment failure D3. The value of each node is determined by the non-subjective factor variable values ​​mapped by S4.1. The second category is the result variable node Y, which corresponds to the default status. A value of 1 indicates that a default has occurred, and a value of 0 indicates that a default has not occurred. It is determined by the default event information extracted from S2.1. The third category is adjustment variable node X, which corresponds to interference variables that exclude subjective factors. Specifically, it includes user departure time X1 and vehicle speed X2, and the values ​​are determined by the vehicle departure record and real-time driving trajectory data of the car company node in S1.1. A causal edge is defined as follows: dependent variable nodes D1, D2, and D3 point to effect variable node Y, forming a direct causal path; moderating variable nodes X1 and X2 point to the causal edge between dependent variable node D and effect variable node Y, forming a moderating path. S4.3: Perform counterfactual simulation based on the constructed causal graph. In the simulation process, fix the value of the adjustment variable node X, calculate the probability of the value of the result variable node Y in two scenarios: the presence of non-subjective factors D=1 and the absence of non-subjective factors D=0. Then, quantify the causal inevitability probability of non-subjective factors and breach of contract through formula. The formula for calculating the probability of causal necessity is as follows: P=P(Y=1|D=1,X)-P(Y=1|D=0,X); Where P represents the probability of causal inevitability between non-subjective factors and default, with a value range of [0,1]; Y=1 indicates that the result variable is a default; D=1 indicates that the dependent variable is a non-subjective factor, which also means that at least one of D1, D2, and D3 has occurred; D=0 indicates that the dependent variable is non-existent, which also means that non-subjective factors D1, D2, and D3 have not occurred; X represents a fixed value of the moderating variable set, representing no change in the user's subjective behavior; P(Y=1|D=1,X) represents the conditional probability of default occurring in a scenario where there are non-subjective factors and the user's subjective behavior is fixed; P(Y=1|D=0,X): The conditional probability of default occurring in a scenario where there are no non-subjective factors and the user's subjective behavior is fixed; S4.4: Compare the obtained causal probability P with the preset probability threshold. If P reaches the preset probability threshold, it is determined that there is a direct causal relationship between the non-subjective factor and the breach of contract, and a causal determination report containing the causal graph structure, counterfactual simulation process, and probability calculation results is generated. If P does not reach the preset probability threshold, it is determined that there is no direct causal relationship between the subjective factor and the breach of contract, and a causal determination report is also generated, indicating the reason for not reaching the threshold in the report.

[0012] S5 further includes the following: S5.1: Obtain the user identifier, reservation time period, associated charging pile identifier, and time of occurrence of the default event from the default event information as the basic information for the credible report. Then, integrate the structured verification report and the causal determination report, and arrange them in a logical order from basic information to cross-validation results, then to the causal determination process, and finally to the final conclusion. After the report is generated, the consortium blockchain system automatically generates a unique hash value corresponding to the report, binds it to the report content, stores it on the consortium blockchain, and associates it with the corresponding default event identifier to complete the trusted storage of the report.

[0013] S6 further includes the following: S6.1: Directly push the trusted report to the user corresponding to the default event; collect user feedback information data on the trusted report and judgment results, including the user's acceptance status of the final judgment conclusion, and a description of the problems with the cross-validation results or the causal necessity probability calculation process in the report; and then store the feedback information data in the feedback database of the consortium blockchain. S6.3: Extract feedback information data from the consortium blockchain feedback database according to a preset cycle, and perform two types of optimizations based on user feedback: First, optimize the data range of consortium blockchain nodes. For cases where incomplete judgments are caused by missing data due to certain non-subjective factors in the feedback, increase the data collection dimensions and range of the corresponding nodes by a preset number. Second, optimize the parameters of the counterfactual causal reasoning model. For cases where the judgment conclusions in the feedback do not match the actual situation, adjust the weights and preset probability thresholds of the causal graph nodes in the model according to the rules of increasing and decreasing. After optimization, synchronize the adjusted consortium blockchain node data range and model parameters to the consortium blockchain smart contract.

[0014] An artificial intelligence-based orderly charging system for electric vehicles includes a consortium blockchain notarization module, a default event handling and data filtering module, a multi-source data cross-validation module, a counterfactual causal reasoning module, a credible report generation and notarization module, and a report push and system optimization module. The consortium blockchain evidence storage module is responsible for building the consortium blockchain evidence storage network, managing the original data uploaded by each node and generating a unique hash value for binding and storage, and restricting the node's data modification permissions. The default event handling and data filtering module is responsible for detecting default events and triggering the judgment process, extracting default information, retrieving consortium blockchain data, and filtering multi-source data that meets the conditions. The multi-source data cross-validation module verifies the temporal, spatial, and logical consistency of multi-source data through the consortium blockchain smart contract. If the verification is successful, a verification report is generated; if the verification fails, the judgment is terminated. The counterfactual causal reasoning module is responsible for mapping the verification data to variables and constructing a causal graph, calculating the probability of causal necessity, determining causal relationships, and generating a report. The trusted report generation and evidence storage module is used to integrate information to generate trusted reports, generate a unique hash value for binding and storage to the consortium blockchain, and associate it with default events. The report push and system optimization module is responsible for pushing trusted reports and collecting user feedback, periodically optimizing the node data range and model parameters, and synchronizing them to the consortium blockchain smart contract.

[0015] Compared with the prior art, the beneficial effects of the present invention are: 1. Address the problem of existing technologies "not verifying the direct causal relationship between non-subjective factors and breach of contract, and being prone to misjudgment": Construct a causal graph containing dependent, effect, and moderating variables through a counterfactual causal reasoning model. After fixing the user's subjective behavior variables, calculate the probability of causal necessity to accurately determine the direct association between non-subjective factors and breach of contract, avoid misjudgment caused by "data coincidence", and prevent users from suffering damage to their reservation credit and subsequent reservation privileges due to misjudgment.

[0016] 2. Addressing the issues of "low user trust, abandoned reservation systems leading to chaotic charging resources, and low charging efficiency": By generating a reliable report containing the original data hash value, verification results, and causal calculation process, users can trace the basis for their judgments. At the same time, based on user feedback, the range of node data and model parameters are continuously optimized to improve the accuracy of judgments, enhance user trust in the judgment results, reduce the number of users abandoning the reservation system, ensure that charging resources are allocated in an orderly manner according to the reservation mechanism, and improve the overall charging efficiency of highway service areas. Attached Figure Description

[0017] Figure 1 This is a flowchart of an artificial intelligence-based orderly charging method for electric vehicles according to the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Example: Figure 1 As shown, the present invention provides a technical solution. An artificial intelligence-based method for orderly charging of electric vehicles includes the following steps: S1. Build a consortium blockchain evidence storage network that is not determined by subjective factors. Select consortium blockchain nodes, and each node uploads the original data of the corresponding scenario. After the data is uploaded, a unique hash value is generated. S2. When the system detects that the user has not completed charging within the scheduled time period, it triggers the non-subjective factor judgment process. For the data where the time deviation between the default event and the non-subjective factor data meets the preset time deviation threshold and there are at least two types of nodes in the consortium blockchain, cross-validation is performed. S3. Cross-validate the multi-source data that meets the conditions in S2 through the consortium blockchain smart contract, and input the data that passes all the verifications into the counterfactual causal reasoning model. S4. After receiving the verified data, the counterfactual causal reasoning model performs counterfactual simulation by constructing a causal graph with a preset structure, calculates the probability of causal necessity between non-subjective factors and breach of contract, and determines that there is a direct causal relationship if the probability reaches a preset probability threshold. S5. Generate a trusted report based on the judgment results. The report includes the hash value of the original data of each node, the cross-validation results, the calculation process of the causal necessity probability, and the final judgment conclusion. S6. Push trusted reports to users, collect user feedback on the judgment results, and regularly optimize the data range of the consortium blockchain nodes and the parameters of the counterfactual causal reasoning model based on the feedback data. The optimization results are synchronized to the consortium blockchain smart contract.

[0020] S1 further includes the following: S1.1: The highway administration bureau, navigation platform, car manufacturer, and charging pile manufacturer are selected as fixed nodes of the consortium blockchain. Each node is only responsible for the collection and uploading of raw data in the corresponding scenario, and there is no data modification permission between nodes. They can only view the public data with hash values ​​that have been uploaded by themselves and other nodes. Among them, the highway administration bureau node uploads real-time traffic data and traffic event records within a preset range around the service area; the navigation platform node uploads the planned route data and real-time congestion status data within the user's reservation time period; the car manufacturer node uploads the user's vehicle departure record, real-time driving trajectory data, and vehicle operation status data; and the charging pile manufacturer node uploads the operation status data and fault record data of the reserved charging pile. S1.2: Each node continuously uploads the corresponding type of raw data at a preset frequency. When data is uploaded, the consortium blockchain system generates a unique hash value, which is then bound to the corresponding raw data for storage. In addition, each piece of raw data uploaded by each node must carry identification information in a unified format. The identification information includes the data collection timestamp, the physical location identifier associated with the data, and the identifier of the node to which the data belongs. The physical location identifier adopts a preset geocoding format.

[0021] S2 further includes the following: S2.1: When the system detects that a user has not completed charging within the reserved time period, it extracts the information corresponding to the breach event from the reservation system. The information specifically includes the user identifier, the reserved time period, the associated charging pile identifier, and the time of the breach event. Among them, the associated charging pile identifier must correspond to the physical location identifier carried in the operation status data and fault record data of the reserved charging pile uploaded by the charging pile manufacturer node in S1.1, and the user identifier must correspond to the user vehicle information associated with the user vehicle's departure record, real-time driving trajectory data, and vehicle operation status data uploaded by the vehicle manufacturer node in S1.1. S2.2: Based on the information extracted in S2.1, retrieve non-subjective factor data related to the default event from the consortium blockchain; The non-subjective factors data specifically include the following: Abnormal real-time traffic conditions around the service area: This refers to real-time traffic data within a preset range around the service area uploaded by the highway administration node, which represents objective road-related factors that may affect users' timely arrival at the reserved charging station. Traffic incidents around service areas: These are traffic incident records within a preset range around the service area uploaded by the highway administration node. They are sudden road traffic disruption factors that are beyond the user's subjective control. Real-time congestion of the planned route during the user's reservation period: This refers to the planned route data and real-time congestion status data uploaded by the navigation platform node during the user's reservation period, which are the objective traffic obstacles on the user's planned driving route. Faulty charging stations: Fault record data of the scheduled charging stations uploaded by the charging station manufacturer, which are factors that prevent users from charging normally due to objective faults of the charging station itself. Abnormal operation status of the reserved charging pile: The operation status data of the reserved charging pile uploaded by the charging pile manufacturer node is an objective status factor that is not a fault of the charging pile but affects normal charging. Abnormal vehicle operation status: The vehicle operation status data of the user's vehicle uploaded to the corresponding car manufacturer node is due to objective faults or abnormalities of the vehicle itself, which prevent the user from completing the charging on time. The retrieval process uses the reservation time period corresponding to the default event as the time reference range and the physical location corresponding to the associated charging pile identifier as the spatial reference range. It filters the original data within the above time and spatial reference ranges from the following: real-time traffic conditions and traffic event records uploaded by the highway administration node in S1.1; planned route data and real-time congestion status data within the user's reservation time period uploaded by the navigation platform node; departure records, real-time driving trajectory data and vehicle operation status data of user vehicles uploaded by the car manufacturer node; and operation status data and fault record data of the reserved charging pile uploaded by the charging pile manufacturer node. At the same time, the node type to which each piece of retrieved data belongs is recorded in real time. S2.3: Based on the setting in S1.2 that each piece of raw data uploaded by each node must carry a unified format of identification information, the collection timestamp of non-subjective factor data is calibrated with the occurrence time of the default event extracted in S2.1; Then, the effective time interval is determined based on the type characteristics of non-subjective factor data: The real-time traffic data from the highway administration node and the real-time congestion data from the navigation platform node are used as continuous time-series data. The effective time interval is from the start time corresponding to the data collection timestamp to the next data collection time of the same type. The vehicle departure records from the car manufacturer's node and the fault records from the charging pile manufacturer's node are instantaneous data, and their effective time interval is from the moment corresponding to the data collection timestamp to the end of the data-related event. Finally, the overlap duration between the target time interval where the default event occurred and the valid time interval of the non-subjective factor data is calculated. If the overlap duration accounts for a proportion of the duration of the default event that meets the preset proportion requirement, and the difference between the start time and the difference between the end time of the two time intervals both meet the preset time deviation threshold, and the number of node types to which the retrieved data belongs reaches at least two, then the non-subjective factor data is determined as multi-source data that meets the conditions and is used to perform cross-validation in S3. If any of the above conditions are not met, the non-subjective factor determination process is terminated.

[0022] S3 further includes the following: S3.1: Retrieve the multi-source data that meets the conditions determined in S2.3, extract the unified format identification information carried by each data, and at the same time, retrieve the unique hash value corresponding to each data chain through the consortium blockchain smart contract, associate it with the type range of data uploaded by each node in S1.1, and confirm the matching of data source with power saving function; S3.2: Cross-validate the preprocessed multi-source data in terms of temporal consistency, spatial consistency, and logical consistency using consortium blockchain smart contracts. Regarding time consistency verification: Compare the effective time intervals of data from different nodes to confirm whether the overlap between the effective time intervals of each node's data and the target time interval of the default event is consistent, and whether the difference between the start and end times of the effective time intervals between each node's data meets the preset verification rules. These rules must be consistent with the logic for determining time deviation in S2.3. In terms of spatial consistency verification: By comparing the physical location identifiers associated with the data of each node, it is confirmed that the service area preset surrounding range of the highway administration node data, the route associated location of the navigation platform node data, and the charging pile location of the charging pile manufacturer node data all correspond to the same physical area, and the physical location identifiers conform to the preset geocoding format in S1.2. Regarding logical consistency verification: Based on the functional attributes of each node's data in S1.1, verify the inherent logical relationships between different node data; the abnormal road condition data recorded by the highway administration node must match the corresponding road segment congestion data recorded by the navigation platform node; the fault data recorded by the charging pile manufacturer node must match the description of the user's inability to start charging; the vehicle driving trajectory data recorded by the car manufacturer node must match the traffic status reflected in the road condition data; eliminate situations where there are logical contradictions between data. S3.3: Execute a judgment based on the results of cross-validation. Only when all three validations of time consistency, spatial consistency, and logical consistency pass, will this batch of multi-source data be marked as validated and a structured validation report containing the validation results of each dimension be generated. If any dimension fails, the smart contract will terminate this non-subjective factor judgment process.

[0023] S4 further includes the following: S4.1: Map the validated data to structured variables that can be identified by the counterfactual causal reasoning model according to the logic of non-subjective factor type-data attribute-variable value; among them, real-time traffic data from the highway administration node is mapped to traffic anomaly variables, real-time congestion status data from the navigation platform node is mapped to route congestion variables, fault record data from the charging pile manufacturer node is mapped to equipment fault variables, and vehicle driving trajectory data from the car manufacturer node is mapped to user driving status variables; at the same time, map the information such as the occurrence time of the default event and the reservation time period extracted in S2.1 to default status variables, ensuring that all input variables correspond one-to-one with the node definitions of the subsequent causal graph; S4.2: Based on the mapped structured variables, construct a causal graph with a predefined structure. The causal graph contains three types of nodes and causal edges between nodes: The first category is the dependent variable node D, which corresponds to the set of non-subjective factors, specifically including abnormal road conditions D1, route congestion D2, and equipment failure D3. The value of each node is determined by the non-subjective factor variable values ​​mapped by S4.1. The second category is the result variable node Y, which corresponds to the default status. A value of 1 indicates that a default has occurred, and a value of 0 indicates that a default has not occurred. It is determined by the default event information extracted from S2.1. The third category is adjustment variable node X, which corresponds to interference variables that exclude subjective factors. Specifically, it includes user departure time X1 and vehicle speed X2, and the values ​​are determined by the vehicle departure record and real-time driving trajectory data of the car company node in S1.1. A causal edge is defined as follows: dependent variable nodes D1, D2, and D3 point to effect variable node Y, forming a direct causal path; moderating variable nodes X1 and X2 point to the causal edge between dependent variable node D and effect variable node Y, forming a moderating path. S4.3: Perform counterfactual simulation based on the constructed causal graph. In the simulation process, fix the value of the adjustment variable node X, calculate the probability of the value of the result variable node Y in two scenarios: the presence of non-subjective factors D=1 and the absence of non-subjective factors D=0. Then, quantify the causal inevitability probability of non-subjective factors and breach of contract through formula. The formula for calculating the probability of causal necessity is as follows: P=P(Y=1|D=1,X)-P(Y=1|D=0,X); Where P represents the probability of causal inevitability between non-subjective factors and default, with a value range of [0,1]; Y=1 indicates that the result variable is a default; D=1 indicates that the dependent variable is a non-subjective factor, which also means that at least one of D1, D2, and D3 has occurred; D=0 indicates that the dependent variable is non-existent, which also means that non-subjective factors D1, D2, and D3 have not occurred; X represents a fixed value of the moderating variable set, representing no change in the user's subjective behavior; P(Y=1|D=1,X) represents the conditional probability of default occurring in a scenario where there are non-subjective factors and the user's subjective behavior is fixed; P(Y=1|D=0,X): The conditional probability of default occurring in a scenario where there are no non-subjective factors and the user's subjective behavior is fixed; This formula quantifies the contribution of non-subjective factors to the occurrence of default by calculating the difference in the probability of default in two scenarios, eliminates the interference of users' subjective behavior in the determination of causality, and ensures that the probability results only reflect the direct correlation between non-subjective factors and default. S4.4: Compare the obtained causal probability P with the preset probability threshold. If P reaches the preset probability threshold, it is determined that there is a direct causal relationship between the non-subjective factor and the breach of contract, and a causal determination report containing the causal graph structure, counterfactual simulation process, and probability calculation results is generated. If P does not reach the preset probability threshold, it is determined that there is no direct causal relationship between the subjective factor and the breach of contract, and a causal determination report is also generated, indicating the reason for not reaching the threshold in the report.

[0024] S5 further includes the following: S5.1: Obtain the user identifier, reservation time period, associated charging pile identifier, and time of occurrence of the default event from the default event information as the basic information for the credible report. Then, integrate the structured verification report and the causal determination report, and arrange them in a logical order from basic information to cross-validation results, then to the causal determination process, and finally to the final conclusion. After the report is generated, the consortium blockchain system automatically generates a unique hash value corresponding to the report, binds it to the report content, stores it on the consortium blockchain, and associates it with the corresponding default event identifier to complete the trusted storage of the report.

[0025] S6 further includes the following: S6.1: Directly push the trusted report to the user corresponding to the default event; collect user feedback information data on the trusted report and judgment results, including the user's acceptance status of the final judgment conclusion, and a description of the problems with the cross-validation results or the causal necessity probability calculation process in the report; and then store the feedback information data in the feedback database of the consortium blockchain. S6.3: Extract feedback information data from the consortium blockchain feedback database according to a preset cycle, and perform two types of optimizations based on user feedback: First, optimize the data range of consortium blockchain nodes. For cases where incomplete judgments are caused by missing data due to certain non-subjective factors in the feedback, increase the data collection dimensions and range of the corresponding nodes by a preset number. Second, optimize the parameters of the counterfactual causal reasoning model. For cases where the judgment conclusions in the feedback do not match the actual situation, adjust the weights and preset probability thresholds of the causal graph nodes in the model according to the rules of increasing and decreasing. After optimization, synchronize the adjusted consortium blockchain node data range and model parameters to the consortium blockchain smart contract.

[0026] An artificial intelligence-based orderly charging system for electric vehicles includes a consortium blockchain notarization module, a default event handling and data filtering module, a multi-source data cross-validation module, a counterfactual causal reasoning module, a credible report generation and notarization module, and a report push and system optimization module. The consortium blockchain evidence storage module is responsible for building the consortium blockchain evidence storage network, managing the original data uploaded by each node and generating a unique hash value for binding and storage, and restricting the node's data modification permissions. The default event handling and data filtering module is responsible for detecting default events and triggering the judgment process, extracting default information, retrieving consortium blockchain data, and filtering multi-source data that meets the conditions. The multi-source data cross-validation module verifies the temporal, spatial, and logical consistency of multi-source data through the consortium blockchain smart contract. If the verification is successful, a verification report is generated; if the verification fails, the judgment is terminated. The counterfactual causal reasoning module is responsible for mapping the verification data to variables and constructing a causal graph, calculating the probability of causal necessity, determining causal relationships, and generating a report. The trusted report generation and evidence storage module is used to integrate information to generate trusted reports, generate a unique hash value for binding and storage to the consortium blockchain, and associate it with default events. The report push and system optimization module is responsible for pushing trusted reports and collecting user feedback, periodically optimizing the node data range and model parameters, and synchronizing them to the consortium blockchain smart contract.

[0027] To address the issue of unreliable non-subjective breach of contract determinations in the electric vehicle charging station reservation system at service areas within its jurisdiction, a provincial expressway group adopted the artificial intelligence-based orderly charging system and method for electric vehicles of this invention. A pilot deployment was conducted at expressway service area A, and the specific implementation process is as follows: First, during the system setup phase, step S1 is executed to establish a consortium blockchain evidence storage network based on non-subjective factor judgment. The highway administration bureau, a navigation platform company, a car manufacturer, and a charging pile manufacturer are selected as fixed nodes in the consortium blockchain. Each node is only responsible for collecting and uploading raw data for its corresponding scenario; it has no data modification permissions and can only view publicly available data with hash values ​​uploaded by other nodes. Specifically, the highway administration bureau uploads real-time traffic data and traffic event records within a 1-kilometer radius of service area A at a preset frequency of once every 5 minutes; the navigation platform uploads planned route data and real-time congestion status data for the user's reserved time slot at a frequency of once every 3 minutes; the car manufacturer uploads user vehicle departure records, real-time driving trajectory data, and vehicle operating status data at a frequency of once every 10 minutes; and the charging pile manufacturer uploads operating status data and fault record data for each reserved charging pile within service area A at a frequency of once every 2 minutes. All raw data uploaded by nodes carries identification information in a unified format, including a UTC timestamp accurate to the second (e.g., “UTC202X-XX-XX08:50:00”), a physical location identifier using GCJ-02 geocoding (e.g., “116.321°E, 39.912°N”), and a node identifier (e.g., “Highway Administration Bureau - Service Area A”). When data is uploaded, the consortium blockchain system automatically generates a unique hash value, which is then bound to and stored with the raw data.

[0028] After the system officially went into operation, on September X, User A reserved charging station No. 1 in service area A through the reservation system, with a reservation time slot of 9:00-9:30 (T0=9:00, T1=9:30). At 9:20, the system detected that User A had not completed charging within the reserved time slot, triggering the non-subjective factor judgment process and executing step S2. First, the default event information was extracted from the reservation system: the user identifier was "U001", the reservation time slot was 9:00-9:30, the associated charging station identifier was "C001" (its physical location identifier is consistent with the geocode "116.321°E, 39.912°N" uploaded by the charging station manufacturer), and the default event occurred at 9:20 (T2=9:20). Subsequently, based on this information, relevant non-subjective factor data was retrieved from the consortium blockchain. The time reference range for retrieval was 9:00-9:30, and the spatial reference range was 1 kilometer around service area A (geographic code matching "116.320°E-116.322°E, 39.911°N-39.913°N"). Finally, three types of node data were selected: real-time traffic data from 8:50 (T3) to 9:20 (T4) uploaded by the highway administration (recording congestion at the entrance of service area A) and traffic event records (no traffic accidents), and data uploaded by the navigation platform. The data includes the planned route data from 8:55 (T5) to 9:25 (T6) (User A's planned route passes through the congested section at the entrance of Service Area A) and the real-time congestion status data (this section has been congested since 8:55). The data also includes the vehicle departure records from 8:30 (T7) to 8:35 (T8) uploaded by the vehicle manufacturer (User A's vehicle departs on time at 8:30) and the real-time driving trajectory data from 9:00 to 9:20 (the vehicle was still in the congested section at the entrance of Service Area A from 9:10 to 9:20). These three types of data are recorded from the nodes of "Highway Administration Bureau", "Navigation Platform" and "Vehicle Manufacturer".

[0029] Next, the retrieved non-subjective factor data underwent format calibration, unifying the data collection timestamps and the default event occurrence time of 9:20 to the "UTC hour: minute: second" format to eliminate time format differences. Subsequently, the valid time intervals were determined based on the characteristics of the data types: the highway administration's traffic condition data and the navigation platform's congestion status data are continuous time-series data, with valid time intervals of 8:50:00-9:20:00 and 8:55:00-9:25:00, respectively; the vehicle departure records from car manufacturers are instantaneous data, with a valid time interval of 8:30:00-8:35:00 (end of departure event). The overlap duration between the target time interval (9:00:00-9:30:00) and each valid time interval of the default event was calculated: 20 minutes of overlap with highway administration data (9:00:00-9:20:00), 25 minutes of overlap with navigation platform data (9:00:00-9:25:00), and no overlap with vehicle manufacturer departure records (8:35:00 < 9:00:00). The total overlap duration was 45 minutes, which accounts for (45 / 30) × 100% = 150% of the 30-minute duration of the default event, satisfying the preset 60%. The ratio requirement was met; at the same time, the difference between the start time of each effective time interval and the target interval (8:50-9:00=10 minutes for the highway administration bureau, 8:55-9:00=5 minutes for the navigation platform) and the difference between the end time (9:20-9:30=10 minutes for the highway administration bureau, 9:25-9:30=5 minutes for the navigation platform) both met the preset 10-minute time deviation threshold, and the retrieved data covered 3 types of nodes, meeting the requirement of "at least two types". Finally, these three types of data were determined as qualified multi-source data for subsequent cross-validation.

[0030] In step S3, cross-validation is performed on the qualified multi-source data through the consortium blockchain smart contract. First, the unified format identifier information of each data item is extracted, and the corresponding hash value is retrieved (e.g., the hash value of the highway administration data is "a7f3d2e8b1c9..."). The data type range of each node's uploaded data is then associated to confirm that the highway administration data belongs to "road condition data", the navigation platform data belongs to "congestion status data", and the car company data belongs to "driving trajectory data", thus matching the node functions. Subsequently, verification was performed from three aspects: In the time consistency verification, the overlap between the effective time intervals and target intervals of the three types of data was found to be "partially overlapping," and the difference in the start time (5 minutes between the highway administration's 8:50 and the navigation platform's 8:55) and the difference in the end time (5 minutes between the highway administration's 9:25 and the navigation platform's 9:25) of the effective time intervals between each data point conformed to the preset verification rules. In the spatial consistency verification, the physical location identifiers of the three types of data all corresponded to a 1-kilometer radius around service area A, conforming to the preset GCJ-02 geocoding format. In the logical consistency verification, the highway administration's record of "congestion at the entrance of service area A" matched the navigation platform's record of "congestion on the route planned by user A"; the vehicle manufacturer's record of "vehicles on the congested section from 9:10 to 9:20" matched the road condition data reflecting "congestion causing slow traffic during this period," with no logical contradictions. All three verifications passed, and the data was marked as "verification passed," generating a structured verification report containing the verification results of each dimension.

[0031] The validated data is input into the counterfactual causal reasoning model, and step S4 is executed. First, the data is mapped into structured variables according to "non-subjective factor type - data attribute - variable value": highway administration traffic data is mapped to the traffic anomaly variable D1 (value 1, representing congestion), navigation platform congestion data is mapped to the route congestion variable D2 (value 1, representing route congestion), vehicle company driving trajectory data is mapped to the user driving status variable (reflecting slow vehicle movement due to congestion), and default event information is mapped to the default status variable Y (value 1, representing default). The moderating variables X include user departure time X1 (value 8:30, representing on-time departure) and vehicle speed X2 (value 40km / h, representing speed on congested sections). Based on these variables, a causal graph is constructed: dependent variable node D (including D1 and D2) points to effect variable node Y, and moderating variable nodes X1 and X2 point to the causal edges between D and Y, respectively.

[0032] Subsequently, a counterfactual simulation was performed, fixing X1=8:30 and X2=40km / h (with no change in user's subjective behavior). The conditional probabilities of the two scenarios were calculated: when non-subjective factors exist (D=1, i.e., D1=1 and D2=1), the conditional probability of default is P(Y=1|D=1,X)=0.85; when non-subjective factors do not exist (D=0, i.e., D1=0 and D2=0), the conditional probability of default is P(Y=1|D=0,X)=0.15. Substituting into the causal necessity probability calculation formula P=P(Y=1|D=1,X)-P(Y=1|D=0,X), we get P=0.85-0.15=0.7. Comparing this probability with a preset probability threshold of 0.6, 0.7≥0.6, it is determined that there is a direct causal relationship between non-subjective factors (road congestion, route congestion) and default, generating a causal determination report including a causal graph structure, the counterfactual simulation process, and the probability calculation results.

[0033] Based on the above judgment results, step S5 is executed to generate a trusted report. The report first includes basic information: user identifier U001, reservation time period 9:00-9:30, associated charging pile identifier C001, and default event occurrence time 9:20; then it presents the cross-validation results, i.e., a detailed description showing that time, space, and logical consistency are all passed; next, it shows the causal judgment process, including variable mapping relationships, causal graph structure, the probability of two types of scenarios in counterfactual simulation, and the calculation process of P=0.7; finally, it gives the final conclusion that "non-subjective factors have a direct causal relationship with the default." After the report is generated, the consortium blockchain system automatically generates its unique hash value "f8e7d6c5b4a3...", binds it to the report content, stores it in the consortium blockchain, and associates it with the default event identifier "WE202X09XX001", completing trusted evidence storage.

[0034] Finally, in step S6, the system pushes the trusted report to user A via the app. The push includes the full report and the hash value "f8e7d6c5b4a3...", which the user can use to query the evidence storage record on the consortium blockchain. After reviewing the report, user A comments "I agree with the judgment conclusion; the report logic is clear." The system stores this feedback information (including the acceptance status and no problem description) in the consortium blockchain feedback database. At the end of each month, the system extracts data from the feedback database to perform optimizations: for some users who reported "vehicle battery anomalies were not included in the judgment," the data range of the car manufacturer node is optimized, and the collection dimension of "vehicle battery status data" is increased; for individual cases where the causal probability is close to the threshold, the node weight of D1 (road condition anomaly) in the counterfactual causal reasoning model is adjusted from 0.3 to 0.35, while keeping the preset probability threshold of 0.6 unchanged. The optimization results are synchronized to the consortium blockchain smart contract to ensure that subsequent judgment processes automatically adopt the updated configuration, forming a closed loop of "evidence storage-judgment-feedback-optimization".

[0035] In this embodiment, the consortium blockchain evidence storage module, the default event processing and data filtering module, the multi-source data cross-validation module, the counterfactual causal reasoning module, the credible report generation and evidence storage module, and the report push and system optimization module work together to fully implement the method flow of the present invention. This effectively solves the problem that the non-subjective default judgment of the existing reservation system is unreliable, and improves user trust and service area replenishment efficiency.

[0036] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. An artificial intelligence-based orderly charging method for electric vehicles, characterized by: The method comprises the following steps: S1, build a non-subjective factor judgment alliance chain storage network, select alliance chain nodes, each node uploads the original data of the corresponding scene, and generates a unique hash value after data uploading; S2, when the system detects that the user does not complete the charging within the reservation period, trigger the non-subjective factor judgment process, for the time deviation of the default event and the non-subjective factor data meeting the preset time deviation threshold, and there are at least two types of node data in the alliance chain Cross-validation is performed; S3, cross-verify the multi-source data meeting the conditions in S2 through the alliance chain smart contract, and input the data passing all verification into the counterfactual causal reasoning model; S4, after the counterfactual causal reasoning model receives the data passing the verification, the counterfactual causal reasoning model performs counterfactual simulation by constructing a preset structure of a causal graph, calculates the causal certainty probability of the non-subjective factor and the default, and if the probability reaches the preset probability threshold, it is determined that there is a direct causal relationship; S5, generate a credible report according to the judgment result, the report contains the hash value of the original data of each node, the cross-validation result, the calculation process of the causal certainty probability and the final judgment conclusion; S6, push the credible report to the user, collect the feedback of the user on the judgment result, and periodically optimize the data range of the alliance chain node and the parameters of the counterfactual causal reasoning model based on the feedback data, and the optimization result is synchronized to the alliance chain smart contract.

2. The method of claim 1, wherein the method is based on artificial intelligence. S1 further includes the following content: S1.1: Select the highway administration, navigation platform, vehicle enterprise and charging pile manufacturer as the fixed nodes of the alliance chain, each node is only responsible for collecting and uploading the original data in the corresponding scene, and each node has no data modification authority, and can only view the public data with hash value uploaded by itself and other nodes; wherein, the highway administration node uploads the real-time road condition data and traffic event record within the preset range around the service area; the navigation platform node uploads the planned route data and real-time congestion state data within the user reservation period; the vehicle enterprise node uploads the departure record, real-time driving track data and vehicle running state data of the user vehicle; and the charging pile manufacturer node uploads the running state data and fault record data of the reserved charging pile; S1.2: Each node continuously uploads the corresponding type of original data according to the preset frequency, and a unique hash value is generated by the alliance chain system when the data is uploaded, and the hash value is stored with the corresponding original data; in addition, each piece of original data uploaded by each node needs to carry identification information in a unified format, which includes data collection timestamp, physical location identifier associated with the data and node identifier to which the data belongs, wherein the physical location identifier adopts a preset geographic coding format.

3. The method of claim 2, wherein the method is based on artificial intelligence. S2 further includes the following content: S2.1: When the system detects that the user does not complete the charging within the appointment period, extract the information corresponding to the breach event from the appointment system, including user identification, appointment period, associated charging pile identification and breach event occurrence time; wherein the associated charging pile identification needs to correspond to the physical location identification carried by the operation state data and fault record data of the charging pile uploaded by the charging pile manufacturer node in S1.1, and the user identification needs to correspond to the user vehicle information associated with the departure record, real-time driving trajectory data and vehicle running state data of the user vehicle uploaded by the vehicle enterprise node in S1.1; S2.2: According to the information extracted in S2.1, retrieve the non-subjective factor data related to the breach event from the alliance chain; the retrieval process takes the appointment period corresponding to the breach event as the time reference range, and the physical location corresponding to the associated charging pile identification as the spatial reference range, and filters the original data in the real-time traffic data and traffic event record within the preset range of the service area uploaded by the highway administration bureau node in S1.1, the planning route data and real-time congestion state data within the user appointment period uploaded by the navigation platform node, the departure record, real-time driving trajectory data and vehicle running state data of the user vehicle uploaded by the vehicle enterprise node, and the operation state data and fault record data of the appointment charging pile uploaded by the charging pile manufacturer node, which are within the above-mentioned time reference range and spatial reference range; at the same time, record the node type to which each piece of retrieved data belongs in real time; S2.3: Based on the setting that each piece of original data uploaded by each node in S1.2 needs to carry identification information in a unified format, format calibrate the non-subjective factor data collection timestamp with the breach event occurrence time extracted in S2.1; Then determine the effective time interval according to the type characteristics of the non-subjective factor data: The real-time traffic data of the highway administration bureau node and the real-time congestion state data of the navigation platform node are continuous time series data, and the effective time interval is from the starting time corresponding to the data collection timestamp to the data collection time of the next piece of data of the same type; The vehicle departure record of the vehicle enterprise node and the fault record of the charging pile manufacturer node are instantaneous data, and the effective time interval is from the time corresponding to the data collection timestamp to the end time of the data associated event; Finally, calculate the overlapping length of the target time interval where the breach event occurs and the effective time interval of the non-subjective factor data, if the overlapping length accounts for a proportion of the breach event duration reaching a preset proportion requirement, and the starting time difference and ending time difference of the two time intervals meet the preset time deviation threshold, and the number of node types of the retrieved data reaches at least two types, then the non-subjective factor data is determined as the multi-source data meeting the conditions, which is used for cross-validation in S3; if any of the above conditions is not met, terminate the non-subjective factor determination process.

4. The method of claim 3, wherein the method is based on artificial intelligence. S3 further includes the following content: S3.1: Call the qualified multi-source data determined in S2.3, extract the unified format identification information carried by each piece of data, at the same time, call the unique hash value corresponding to each piece of data chain through the alliance chain smart contract, associate the type range of each node uploaded data in S1.1, confirm the matching of data source and power saving function; S3.2: Through the alliance chain smart contract, cross verification is performed on the preprocessed multi-source data from three aspects of time consistency, space consistency and logical consistency: Time consistency verification aspect: compare the effective time interval of different node data, confirm whether the overlap relationship of the effective time interval of each node data and the default time interval of the default event is consistent, and the start time difference and end time difference of the effective time interval of each node data meet the preset verification rule, which needs to be consistent with the logic of time deviation determination in S2.3; Space consistency verification aspect: compare the physical location identification associated with each node data, confirm that the service area preset periphery of the highway administration bureau node data, the route associated location of the navigation platform node data and the charging pile location of the charging pile manufacturer node data all correspond to the same physical area, and the physical location identification conforms to the preset geographic code format in S1.2; Logical consistency verification aspect: combined with the functional attributes of each node data in S1.1, the internal logical association between different node data is verified; the road condition abnormal data recorded by the highway administration bureau node needs to match the corresponding congestion data of the navigation platform node recorded on the road section; the fault data recorded by the charging pile manufacturer node needs to match the state description that the user cannot start charging; the vehicle driving trajectory data recorded by the vehicle enterprise node needs to match the traffic state reflected by the road condition data; exclude the case that there is logical contradiction between data; S3.3: According to the result of cross verification, only when time consistency, space consistency and logical consistency pass, mark this batch of multi-source data as passed, and generate a structured verification report containing the verification results of each dimension; if any dimension does not pass, the smart contract will terminate this non-subjective factor determination process.

5. The method of claim 3, wherein the method is based on artificial intelligence. S4 further includes the following contents: S4.1: The data that pass the verification are mapped to the structured variables that can be recognized by the counterfactual causal reasoning model according to the logic of non-subjective factor type-data attribute-variable value; among them, the real-time road condition data of the highway administration bureau node is mapped to the road condition abnormal variable, the real-time congestion state data of the navigation platform node is mapped to the route congestion variable, the fault record data of the charging pile manufacturer node is mapped to the equipment fault variable, and the vehicle driving trajectory data of the vehicle enterprise node is mapped to the user driving state variable; At the same time, the information such as the default event occurrence time and the appointment period extracted in S2.1 is mapped to the default state variable, ensuring that all input variables are one-to-one corresponding to the node definition of the subsequent causal graph; S4.2: Based on the mapped structured variables, a preset structure causal graph is constructed, which includes three types of nodes and the causal edges between the nodes: The first type is the dependent variable node D, corresponding to the non-subjective factor set, specifically including road condition abnormality D1, route congestion D2, and equipment failure D3, and the values of each node are determined by the non-subjective factor variable values mapped by S4.1; The second type is the fruit variable node Y, corresponding to the default state, taking the value of 1, indicating that the default occurs, and taking the value of 0, indicating that the default does not occur, which is determined by the default event information extracted by S2.1; The third type is the adjustment variable node X, corresponding to the interference variable excluding subjective factors, specifically including user departure time X1 and vehicle driving speed X2, and the values are determined by the vehicle departure record of the vehicle enterprise node and real-time driving trajectory data in S1.1; The causal edge is defined as: the dependent variable nodes D1, D2, and D3 point to the fruit variable node Y, forming a direct causal path; the adjustment variable nodes X1 and X2 point to the causal edge of the dependent variable node D and the fruit variable node Y, forming an adjustment path; S4.3: Based on the constructed causal graph, perform counterfactual simulation, fix the values of the adjustment variable nodes X, calculate the probability of the fruit variable node Y in the two scenarios of existing non-subjective factors D=1 and non-existing non-subjective factors D=0, and then quantify the causal certainty probability of non-subjective factors and default through the formula; The causal certainty probability calculation formula is as follows: P=P(Y=1|D=1,X)-P(Y=1|D=0,X); Where P represents the causal certainty probability of non-subjective factors and default, with a value range of [0,1]; Y=1 represents the fruit variable taking the value of default occurrence; D=1 represents the dependent variable taking the value of existing non-subjective factors, also representing at least one of D1, D2, and D3 being in the occurrence state; D=0 represents the dependent variable taking the value of non-existing, also representing that non-subjective factors D1, D2, and D3 are all in the non-occurrence state; X represents the fixed value of the adjustment variable set, representing that the user's subjective behavior does not change; P(Y=1|D=1,X) represents the conditional probability of default occurrence in the scenario of existing non-subjective factors and fixed user subjective behavior; P(Y=1|D=0,X): The conditional probability of default occurrence in the scenario of non-existing non-subjective factors and fixed user subjective behavior; S4.4: Compare the obtained causal certainty probability P with the preset probability threshold value, if P reaches the preset probability threshold value, it is determined that there is a direct causal relationship between non-subjective factors and default, and a causal judgment report containing the causal graph structure, counterfactual simulation process, and probability calculation result is generated; if P does not reach the preset probability threshold value, it is determined that there is no direct causal relationship between subjective factors and default, and a causal judgment report is also generated, and the reason for not reaching the threshold value is indicated in the report.

6. The method of claim 1, wherein the method is based on artificial intelligence. S5 further includes the following content: S5.1: Obtain the user identifier, reservation period, associated charging pile identifier, and default event occurrence time from the default event information as basic information for a trusted report, then integrate the structured verification report and the causal judgment report, arrange them in the logical order from basic information to cross-validation results, then to causal judgment process, and finally to the final conclusion; After the report is generated, the system automatically generates a unique hash value corresponding to the report, stores the report content in the consortium chain, and associates the corresponding default event identifier to complete the trusted storage of the report.

7. The method of claim 1, wherein the method is based on artificial intelligence. S6 further includes the following: S6.1: Directly push the trusted report to the user corresponding to the default event; collect user feedback information data on the trusted report and the determination result, which specifically includes the approval status of the final determination conclusion and the description of the problems in the cross-validation results or the causal certainty probability calculation process in the report; then store the feedback information data in the feedback database of the consortium chain; S6.3: Extract the feedback information data in the feedback database of the consortium chain according to the preset period, and perform two types of optimization based on user feedback: one is to optimize the data range of the consortium chain node, and to increase the data collection dimension and range of the corresponding node according to the preset number for the case where the determination is incomplete due to the lack of data for a certain type of non-subjective factor in the feedback; the second is to optimize the parameters of the counterfactual causal reasoning model, and to adjust the weight and preset probability threshold of the nodes in the causal graph in the model according to the rules of increasing and decreasing for the case where the determination conclusion does not match the actual situation in the feedback; after optimization, synchronize the adjusted consortium chain node data range and model parameters to the consortium chain smart contract.

8. An artificial intelligence-based electric vehicle orderly charging system applied to the artificial intelligence-based electric vehicle orderly charging method of any one of claims 1-7, characterized in that: The consortium chain storage module, the default event processing and data filtering module, the multi-source data cross-validation module, the counterfactual causal reasoning module, the trusted report generation and storage module, and the report pushing and system optimization module are included. The consortium chain storage module is responsible for building a consortium chain storage network, managing the upload of corresponding raw data by each node and generating a unique hash value for binding storage, and limiting node data modification permissions; the default event processing and data filtering module is responsible for detecting default events and triggering the determination process, extracting default information, calling consortium chain data, and filtering multi-source data that meets the conditions; the multi-source data cross-validation module verifies the time, space, and logical consistency of multi-source data through a consortium chain smart contract, generates a verification report for data that passes the verification, and terminates the determination for data that fails the verification; the counterfactual causal reasoning module is responsible for mapping the verification data into variables and constructing a causal graph, calculating the causal certainty probability, determining the causal relationship, and generating a report; the trusted report generation and storage module is used to integrate information to generate a trusted report, generate a unique hash value for binding storage to the consortium chain, and associate the default event; the report pushing and system optimization module is responsible for pushing the trusted report and collecting user feedback, regularly optimizing the node data range and model parameters, and synchronizing to the consortium chain smart contract.

Images