Electronic ticket intelligent checking system and method
Patent Information
- Application Number
- CN202610663321.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2026-05-14
- Publication Date
- 2026-10-20
- Estimated Expiration
- 2046-05-14
AI Technical Summary
[0002]当前,电子票证已广泛应用于各类作业场景的合规管控中,但其校验过程仍存在技术瓶颈:一是人工依赖度高,无论是票证开具、资质校验还是作业条件核查,均需大量人工介入,不仅效率低下,还易出现人为失误;二是校验模式滞后,多为静态核查、事后补验,无法实现实时校验与异常预判,易出现显性合规、隐性违规的问题;三是多模块脱节,电子票开具、资质校验、作业条件校验、合规管控等环节相互独立,无协同联动机制,易出现单一环节合规、整体违规的情况;四是隐性风险难以识别,现有技术仅能识别显性违规,无法识别资质文件隐性瑕疵、票证内容语义违规、虚假填报等隐性风险;五是效率与合规难以平衡,要么校验过严影响作业效率,要么校验过松导致合规风险
[0049]1.本发明提出一种电子票证智能校验系统,并进行了架构、运行步骤和流程上的优化改进,系统具备流程简单,投资运行费用低廉,生产工作成本低的优点。
Smart Images

Figure CN122492241B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of information verification technology, specifically an intelligent verification system and method for electronic tickets. Background Technology
[0002] Currently, electronic tickets are widely used in compliance management across various operational scenarios, but their verification process still faces technical bottlenecks: First, they are highly reliant on manual labor. Whether it's ticket issuance, qualification verification, or operational condition checks, extensive manual intervention is required, leading to low efficiency and susceptibility to human error. Second, the verification model is outdated, primarily relying on static checks and post-event verification, failing to achieve real-time verification and anomaly prediction, easily resulting in both explicit compliance and implicit violations. Third, multiple modules are disconnected; electronic ticket issuance, qualification verification, operational condition verification, and compliance management are independent processes without a collaborative mechanism, easily leading to situations where a single step is compliant while the entire system is non-compliant. Fourth, implicit risks are difficult to identify; existing technologies can only identify explicit violations, failing to recognize implicit risks such as flaws in qualification documents, semantic violations in ticket content, and false reporting. Fifth, balancing efficiency and compliance is difficult; either overly strict verification affects operational efficiency, or overly lenient verification leads to compliance risks. Existing electronic ticket verification methods largely rely on preset rules and manual intervention, failing to achieve deep integration with cutting-edge technologies such as artificial intelligence, the Internet of Things, and blockchain, making it difficult to meet the needs of efficient compliance management in high-risk operational scenarios. Therefore, developing a highly innovative and creative intelligent verification method for electronic tickets to solve the above-mentioned technical pain points has become an urgent technical problem to be solved. Summary of the Invention
[0003] To address the shortcomings of existing technologies, this invention proposes an intelligent verification system and method for electronic tickets. The system receives target entity information and generates an electronic ticket draft containing hierarchical ticket codes. It extracts associated qualification document information, performs qualification verification through interface verification and AI-based latent defect identification, and collects on-site time-series signal data for real-time verification and anomaly prediction. The system converts the hierarchical ticket codes and time-series signal data into embedded representations, fuses them in non-Euclidean space to form an aligned feature set, and generates a compliance risk level. Tickets exceeding the standard are marked as abnormal, and the root cause is traced, generating rectification and disposal plans, which are then assigned to disposal nodes. The verification process is dynamically adjusted based on the disposal results. Verified electronic tickets are archived and uploaded to the blockchain for evidence storage. This application achieves intelligent verification of the entire electronic ticket process, improving the accuracy and timeliness of verification and ensuring the immutability and traceability of ticket information.
[0004] To achieve the above objectives, the present invention provides the following technical solution:
[0005] An intelligent verification method for electronic tickets includes:
[0006] Receive target entity information and generate an electronic ticket draft containing hierarchical ticket codes;
[0007] Extract the qualification document information associated with the electronic ticket draft, verify it through the interface and identify hidden defects with AI, and output the qualification verification result. If the qualification verification is passed, the continuous time-series signal data of the on-site operation conditions is collected by the on-site IoT sensing device set for real-time verification and anomaly prediction.
[0008] The hierarchical ticket code and the continuous time-series signal data are respectively converted into a first embedding representation and a second embedding representation, and then fused in non-Euclidean space to form an aligned feature set.
[0009] Compliance risk levels are generated based on the alignment feature set. If the risk level exceeds the preset threshold, the corresponding electronic ticket draft is marked as an abnormal ticket and a review is notified. The abnormal ticket is traced back to its source and a rectification plan is generated. After review, the abnormal ticket is registered as a ticket to be disposed of. A disposal path plan is generated and the disposal path plan is assigned to the dynamically specified disposal node.
[0010] The verification process is dynamically adjusted based on the processing results of the processing nodes. For electronic tickets that pass the verification, they are made effective and archived, and then uploaded to the blockchain for evidence storage.
[0011] Specifically, the step of receiving target entity information and generating an electronic ticket draft containing hierarchical ticket codes includes:
[0012] Based on the entity type and entity identifier indicated by the target entity information, a pre-set coding rule library is invoked to generate a hierarchical ticket code consisting of project code, region code, job type code and unique serial number connected in sequence.
[0013] The generated hierarchical ticket code is bound to the target entity information, and the work content, planned work time, and responsible personnel information extracted from the target entity information are filled in according to the preset electronic ticket template to form an electronic ticket draft.
[0014] Specifically, the extraction of qualification document information associated with the draft electronic ticket, after interface verification and AI-based hidden defect identification, outputs qualification verification results, including:
[0015] Extract the responsible personnel identifier and work type code from the electronic ticket draft, and query the corresponding set of qualification documents from the pre-set qualification database based on the responsible personnel identifier;
[0016] The qualification numbers in the qualification document set are compared online with the pre-set official qualification database through a pre-set qualification verification interface to obtain the interface verification result. At the same time, the qualification document set is input into a pre-trained deep learning defect recognition model. The deep learning defect recognition model includes a convolutional neural network layer, a long short-term memory network layer and a fully connected classification layer in sequence. The convolutional neural network layer is used to extract image features of the qualification documents, the long short-term memory network layer is used to capture the contextual dependencies of the text sequence of the qualification documents, and the fully connected classification layer is used to output the latent defect recognition result.
[0017] By combining the interface verification result and the hidden defect identification result, if the interface verification result indicates that it is valid and the hidden defect identification result indicates that there is no defect, then the qualification verification is deemed to have passed.
[0018] Specifically, the real-time verification and anomaly prediction of continuous time-series signal data of on-site operating conditions collected by on-site IoT sensing devices includes:
[0019] Once the qualification verification is passed, the IoT sensor set deployed at the work site is triggered; the IoT sensor set includes temperature sensors, gas concentration sensors and vibration sensors;
[0020] The IoT sensor set is controlled to collect continuous time-series signal data of ambient temperature, harmful gas concentration, and equipment vibration at a fixed sampling frequency;
[0021] The continuous time-series signal data is input into a pre-trained anomaly prediction model. The anomaly prediction model adopts a structure that combines a one-dimensional convolutional neural network with a self-attention mechanism. The one-dimensional convolutional neural network is used to extract the local temporal features of the continuous time-series signal data, and the self-attention mechanism is used to capture the global dependencies between different sensor signals and output real-time verification results and anomaly prediction indicators.
[0022] Specifically, the step of converting the hierarchical ticket encoding and the continuous time-series signal data into a first embedding representation and a second embedding representation, respectively, and fusing them in non-Euclidean space to form an aligned feature set includes:
[0023] A word embedding model is used to convert each level of the hierarchical ticket encoding into a fixed-dimensional word vector, and the word vectors of all levels are weighted and concatenated to obtain the first embedding representation;
[0024] The continuous temporal signal data is processed using a temporal feature encoder; the temporal feature encoder includes stacked temporal convolutional layers and gated recurrent unit layers, used to extract multi-scale temporal features and encode them into a second embedding representation;
[0025] Using the first and second embedded representations as nodes, a heterogeneous graph is constructed. The heterogeneous graph is then input into a graph neural network. Through the message passing mechanism in the graph neural network, the first and second embedded representation nodes perform multiple rounds of feature interaction and information aggregation in non-Euclidean space, ultimately outputting an aligned feature set.
[0026] Specifically, the process of generating compliance risk levels based on alignment feature sets, and marking the corresponding electronic ticket draft as an abnormal ticket and notifying the reviewer if it exceeds a preset risk level threshold, includes:
[0027] The alignment feature set is input into the risk level classifier; the risk level classifier is a multilayer perceptron containing multiple fully connected layers and a Softmax output layer, used to calculate and output the compliance risk level corresponding to the electronic ticket draft;
[0028] The compliance risk level is compared with a preset risk level threshold. If the compliance risk level is greater than the risk level threshold, an anomaly marking instruction is generated, the electronic ticket draft is marked as an abnormal ticket in the electronic ticket database, a notification message containing the hierarchical ticket code and the reason for the anomaly is generated, and sent to the predefined reviewer terminal through the message push interface.
[0029] Specifically, the step of tracing the root cause of abnormal tickets and generating a rectification plan includes:
[0030] Based on the hierarchical ticket coding of the abnormal tickets, retrieve the historical operation records and historical continuous time-series signal data associated with the abnormal tickets from the operation log database and the signal history database;
[0031] The association rule mining algorithm was used to analyze the retrieved historical operation records and historical continuous time series signal data to identify the combination of operation factors and signal patterns that caused the compliance risk level to exceed the standard, and determined them as the root cause factors.
[0032] Based on the root causes, matching rectification measures are retrieved from a pre-set rectification measures knowledge graph, and a rectification plan for the abnormal tickets is generated by combining them.
[0033] Specifically, after review, the abnormal tickets are registered as tickets to be processed, a processing path plan is generated, and the processing path plan is assigned to dynamically designated processing nodes, including:
[0034] Upon receiving the review confirmation instruction from the review terminal, the status of the abnormal ticket is updated to pending ticket and stored in the pending ticket queue.
[0035] Based on the operation type code, root cause factors, and status of all available disposal nodes of the tickets to be disposed of, the shortest path algorithm is used to calculate the optimal disposal path in the predefined disposal flowchart, and a disposal path scheme containing the sequence of disposal steps, expected time consumption, and resource requirements is generated.
[0036] Based on the resource requirements of each disposal step in the disposal path scheme, a qualified disposal node is dynamically selected from the disposal node resource pool, and each disposal step is assigned to the corresponding disposal node.
[0037] Specifically, the process of making verified electronic tickets effective and archived, and uploading them to the blockchain for evidence storage, includes:
[0038] For electronic ticket drafts that are not marked as abnormal and whose compliance risk level does not exceed the preset risk level threshold, add an electronic signature and timestamp, and change their status to effective electronic ticket.
[0039] The entire process information of the effective electronic ticket is packaged into an archive data package and stored in the electronic ticket archive database; the entire process information includes hierarchical ticket code, target entity information, qualification verification results, continuous time series signal data, alignment feature set and compliance risk level;
[0040] The archived data packets are used to generate a Merkle tree, its root hash value is calculated, and the root hash value is submitted to the blockchain network along with the hierarchical ticket code to complete the evidence storage transaction.
[0041] An intelligent verification system for electronic tickets includes:
[0042] The ticket draft generation module is used to receive target entity information and generate electronic ticket drafts with hierarchical ticket codes.
[0043] The verification module is used to extract the qualification document information associated with the electronic ticket draft, and after interface verification and AI hidden defect identification, it outputs the qualification verification result. If the qualification verification is passed, it collects continuous time-series signal data of on-site working conditions through on-site IoT sensor devices for real-time verification and anomaly prediction.
[0044] The feature fusion processing module is used to perform feature transformation and non-Euclidean space fusion of hierarchical ticket codes and continuous time-series signal data collected on site, and output an aligned feature set.
[0045] The risk level determination module is used to calculate the compliance risk level and mark abnormal tickets based on the alignment feature set, generate notification information containing hierarchical ticket codes and abnormal reasons, and send it to the review terminal through the message push interface;
[0046] The abnormal ticket handling module is used to locate the root cause of risk exceeding the standard by using association rule mining algorithm based on the hierarchical ticket code of abnormal tickets, and generate rectification plan. After receiving the review and confirmation instruction, the abnormal ticket is registered as a ticket to be handled. Combining the operation type, root cause and handling node status, the module generates and allocates handling path plan.
[0047] The dynamic optimization module is used to make dynamic adjustments based on the actual disposal results of the disposal nodes.
[0048] Compared with the prior art, the beneficial effects of the present invention are:
[0049] 1. This invention proposes an intelligent verification system for electronic tickets, and optimizes and improves its architecture, operation steps and processes. The system has the advantages of simple process, low investment and operating costs, and low production and working costs.
[0050] 2. This invention proposes an intelligent verification method for electronic tickets, integrating multiple technologies such as the Internet of Things, artificial intelligence, and blockchain to achieve intelligent verification of electronic tickets throughout the entire process, improving the accuracy and timeliness of verification. It identifies latent defects in qualifications by combining interface verification with a deep learning defect recognition model containing convolutional neural networks and long short-term memory networks. It relies on IoT sensor devices to collect multi-dimensional time-series signals and verifies them in real time through an anomaly prediction model. Furthermore, it converts ticket codes and time-series signals into embedded representations and fuses them into an aligned feature set in non-Euclidean space, thereby generating a compliance risk level. This upgrades ticket verification from a single qualification check to a multi-dimensional, in-depth comprehensive risk assessment, effectively avoiding the oversights of traditional verification methods.
[0051] 3. This invention proposes an intelligent verification method for electronic tickets, constructing a comprehensive system for handling and dynamically optimizing abnormal tickets. For abnormal tickets exceeding risk limits, it enables root cause tracing and automatic generation of rectification plans. It also uses a shortest path algorithm to match the optimal handling path and dynamically allocates handling nodes, ensuring the efficiency of abnormal ticket handling. Simultaneously, verified tickets are stored on the blockchain, achieving tamper-proof and traceable ticket information. Furthermore, the verification process can be dynamically adjusted based on the handling results, improving the standardization and intelligence of electronic ticket management. Attached Figure Description
[0052] Figure 1 This is a schematic diagram of an intelligent verification method for electronic tickets according to the present invention;
[0053] Figure 2 This is a flowchart illustrating the principle of an intelligent verification method for electronic tickets according to the present invention.
[0054] Figure 3 This is an architecture diagram of an intelligent verification system for electronic tickets according to the present invention. Detailed Implementation
[0055] Example 1:
[0056] Please see Figure 1 and Figure 2 The present invention provides an embodiment of an intelligent verification method for electronic tickets, the method comprising steps S1 to S5, including the following steps:
[0057] S1: Receive target entity information and generate an electronic ticket draft containing hierarchical ticket codes;
[0058] S2: Extract the qualification document information associated with the electronic ticket draft, verify it through the interface and identify hidden defects with AI, and output the qualification verification result. If the qualification verification is passed, the continuous time-series signal data of the on-site operation conditions is collected through the on-site IoT sensor device set for real-time verification and anomaly prediction.
[0059] S3: Convert the hierarchical ticket code and the continuous time-series signal data into a first embedded representation and a second embedded representation, respectively, and fuse them in non-Euclidean space to form an aligned feature set;
[0060] S4: Generate compliance risk levels based on the alignment feature set. If the risk level exceeds the preset threshold, mark the corresponding electronic ticket draft as an abnormal ticket and notify for review. Trace the root cause of the abnormal ticket and generate a rectification plan. After review, register the abnormal ticket as a ticket to be disposed of, match and generate a disposal path plan, and allocate the disposal path plan to the dynamically specified disposal node.
[0061] S5: Dynamically adjust the verification process based on the processing results of the processing nodes, complete the activation and archiving of qualified electronic tickets, and upload them to the blockchain for evidence storage.
[0062] The process of receiving target entity information and generating an electronic ticket draft containing hierarchical ticket codes includes:
[0063] S1.1: Based on the entity type and entity identifier indicated by the target entity information, call the preset coding rule library to generate a hierarchical ticket code consisting of project code, area code, operation type code and unique serial number connected in sequence;
[0064] Furthermore, the specific steps of S1.1 include:
[0065] (1) Parse the received target entity information and extract key data items, namely entity type and entity identifier; the entity type is used to define the business scope, such as construction project or equipment maintenance unit; the entity identifier is the unique identification code of the entity in the system, which is in the form of a project number or equipment number composed of 18 digits.
[0066] (2) Based on the entity type obtained from the parsing, call the corresponding encoding rule sub-library from the preset encoding rule library; the encoding rule sub-library stores specific encoding rules for the entity type and defines the generation logic and format specifications of each component of the hierarchical ticket encoding.
[0067] (3) Based on the definition of the encoding rule sub-library, the four components of the hierarchical ticket code are generated sequentially, including:
[0068] Project code generation: Extract the project number from the entity identifier, and according to the rule in the coding rule sub-library that the project code length is four digits, extract the last four digits of the number to form the project code;
[0069] Region code generation: Based on the region division criteria defined in the encoding rule sub-library, and combined with the geographic location information associated with the entity identifier, a three-digit alphanumeric code is matched and generated as the region code;
[0070] Job type code generation: Parse the job nature described in the target entity information, match it with the job type code table in the coding rule sub-library, and obtain the corresponding two-digit code as the job type code;
[0071] Unique serial number generation: A unique context identifier is formed by the current date and the previously generated project code, region code, and job type code. Based on this identifier, a sequential number for the current day is requested from the central serial number counter. This sequential number is fixed as a six-digit number, starting from 000001 and incrementing sequentially, and is used as the unique serial number.
[0072] (4) Arrange the generated project code, area code, job type code and unique serial number in the order predefined by the coding rule sub-library, and use underscores as connectors to splice them together, and finally output the complete hierarchical ticket code.
[0073] S1.2: Bind the generated hierarchical ticket code to the target entity information, and fill in the work content, planned work time, and responsible personnel information extracted from the target entity information according to the preset electronic ticket template to form an electronic ticket draft.
[0074] The extracted qualification document information associated with the electronic ticket draft is verified through interface verification and AI-based hidden defect identification, and the qualification verification results are output, including:
[0075] S2.1: Extract the responsible personnel identifier and work type code from the electronic ticket draft, and query the corresponding set of qualification documents from the pre-set qualification database based on the responsible personnel identifier;
[0076] Furthermore, the specific steps of S2.1 include:
[0077] (1) Access the generated electronic ticket draft and extract the responsible person identifier and job type code from the predetermined fields of the electronic ticket draft; the responsible person identifier is a ten-digit alphanumeric code that uniquely represents the responsible person; the job type code is a two-digit code used to distinguish different job types;
[0078] (2) Using the responsible personnel identifier extracted from the electronic ticket draft as the query condition, a query is initiated to the pre-set qualification database. The qualification database stores the correspondence between personnel and qualifications. This query aims to obtain all registered qualification documents under the responsible personnel identifier to form an initial qualification document set. Each record in the initial qualification document set contains attributes such as qualification type, qualification number, issuing authority, effective date and expiration date.
[0079] (3) Based on the job type code extracted from the electronic ticket draft, query the pre-set job type and qualification mapping relationship table in the system, and determine one or more specific qualification types that must be possessed to perform the job represented by the job type code;
[0080] (4) Compare the obtained initial qualification document set with the determined required qualification types, and select qualification documents from the initial qualification document set that meet the following two conditions: the qualification type must be a required qualification type; secondly, the qualification document must be in a valid state, that is, the current system date is between the effective date and the expiration date of the qualification document.
[0081] (5) After screening, a final set of qualification documents is generated, which includes all valid qualification documents held by the responsible personnel specified in the current electronic ticket draft and applicable to the current job type.
[0082] S2.2: The qualification numbers in the qualification document set are compared online with the pre-set official qualification database through a pre-set qualification verification interface to obtain the interface verification result. At the same time, the qualification document set is input into a pre-trained deep learning defect recognition model. The deep learning defect recognition model includes a convolutional neural network layer, a long short-term memory network layer, and a fully connected classification layer in sequence. The convolutional neural network layer is used to extract image features of the qualification documents, the long short-term memory network layer is used to capture the contextual dependencies of the text sequence in the qualification documents, and the fully connected classification layer is used to output the latent defect recognition result.
[0083] Furthermore, the specific connection and data processing methods of the convolutional neural network layer and the long short-term memory network layer in the deep learning defect recognition model are as follows:
[0084] (1) The convolutional neural network layer consists of multiple alternating convolutional layers and pooling layers, which are used to extract features and reduce dimensions layer by layer from the input qualification file image, and finally output a feature map sequence;
[0085] (2) Flatten the feature map sequence along the spatial dimension into a feature vector sequence, and use it as the input of the long short-term memory network layer;
[0086] (3) The Long Short-Term Memory network layer contains two stacked LSTM units. The first LSTM unit is used to encode the input feature vector sequence in the forward direction to capture the context information from front to back. The second LSTM unit is used to encode the same feature vector sequence in the reverse direction to capture the context information from back to front.
[0087] (4) The forward encoding output and the reverse encoding output of each time step are concatenated to form a bidirectional encoding feature, and the bidirectional encoding feature of the last time step is passed to the fully connected classification layer for latent defect classification.
[0088] Furthermore, the specific steps of S2.2 include:
[0089] (1) The system extracts the official qualification number corresponding to each qualification document from the qualification document set. Then, the system calls the pre-set qualification verification interface. The qualification verification interface has a secure data channel with the official qualification database. The system uses the extracted qualification number as a query parameter and sends it to the official qualification database in batches through the qualification verification interface for online comparison.
[0090] (2) After receiving the query request, the official qualification database performs matching verification in its database and returns the verification result. The system receives the result data stream and parses it. The verification result contains at least one of the three states of each qualification number: state one is that the number exists and the information is completely matched; state two is that the number exists but key information such as personnel name or scope of practice does not match; state three is that the number does not exist or has been cancelled. The system records this parsed state information as the preliminary interface verification result.
[0091] (3) While calling the qualification verification interface, the system starts the artificial intelligence hidden defect identification process in parallel, including: firstly, obtaining the digital image of the qualification document from the qualification document set, wherein the digital image is uniformly preprocessed, including scaling the image size to a fixed width of 256 pixels and height of 192 pixels, and normalizing the pixel value to the range of zero to one, to obtain the preprocessed digital image.
[0092] (4) The preprocessed digital images are input into the first part of the deep learning defect recognition model, namely the convolutional neural network layer. The convolutional neural network layer consists of four convolutional modules connected in series. The first convolutional module uses 64 3×3 convolutional kernels with a stride of 1 for convolution operation, and then passes through a 2×2 max pooling layer. The second convolutional module uses 128 3×3 convolutional kernels, the third convolutional module uses 256 3×3 convolutional kernels, and the fourth convolutional module uses 512 3×3 convolutional kernels. Each module is followed by 2×2 max pooling. After each convolution operation, a linear rectified function is used as the activation function. Through layer-by-layer processing, the preprocessed digital images are converted into feature maps.
[0093] (5) Flatten the feature map output by the convolutional neural network layer in the spatial dimension to form a feature vector sequence, and feed it into the long short-term memory network layer; the long short-term memory network layer consists of two stacked long short-term memory units, each containing 128 hidden units. The first long short-term memory unit processes the feature vector sequence from the beginning to the end in the forward direction, and the second long short-term memory unit processes the same feature vector sequence from the end to the beginning in the reverse direction; for each position in the feature vector sequence, the hidden state generated by the forward processing and the hidden state generated by the reverse processing are concatenated to form a bidirectional encoded feature containing complete context information;
[0094] (6) The bidirectional encoded features of the final output of the long short-term memory network layer are input into the fully connected classification layer of the deep learning defect recognition model. The fully connected classification layer is first a multilayer perceptron containing 512 neurons, and is activated again using a linear rectified function. Then there is a final output layer. The output layer uses the Softmax function to transform the activation values of the neurons into probability distributions corresponding to different defect categories, and takes the category with the highest probability as the result of the latent defect recognition of the qualification document.
[0095] S2.3: Combine the interface verification result with the hidden defect identification result. If both indicate that the result is valid and without defects, the qualification verification is deemed to have passed.
[0096] Furthermore, the system logically merges the interface verification results for each qualification number with the hidden defect identification results of the corresponding qualification document. Only when the interface verification result is in state one, i.e. the information is completely matched, and the hidden defect identification result is flawless, is the specific qualification document determined to have passed the verification. Finally, the verification results of all qualification documents are summarized to generate a comprehensive qualification verification result.
[0097] The method of collecting continuous time-series signal data of on-site operating conditions through on-site IoT sensing devices for real-time verification and anomaly prediction includes:
[0098] S2.4: Once the qualification verification is passed, the IoT sensor set deployed at the work site is triggered; the IoT sensor set includes temperature sensors, gas concentration sensors and vibration sensors;
[0099] S2.5: Control the IoT sensor set to collect continuous time-series signal data of ambient temperature signal, harmful gas concentration signal and equipment vibration signal at a fixed sampling frequency;
[0100] Furthermore, the specific steps of S2.5 include:
[0101] (1) When the system determines that the qualification verification is passed, a device start command is generated. The device start command is sent to the IoT gateway deployed at the work site through a secure wireless network protocol. After receiving the device start command, the IoT gateway performs identity verification and integrity verification on the device start command. After the verification is passed, the IoT gateway sends a wake-up and initialization signal to the IoT sensor device set it manages. The IoT sensor device set includes temperature sensors, harmful gas concentration sensors and equipment vibration sensors.
[0102] (2) The IoT gateway performs unified parameter configuration for each sensor that has been initialized, including setting all sensors to collect data at a frequency of ten times per second. At the same time, the IoT gateway sets the data packet interval to transmit a data packet after every 50 data points collected, i.e., 5 seconds of data.
[0103] (3) After the parameters are configured, the IoT gateway sends a timestamp with clock synchronization information to all sensors and commands all sensors to start data acquisition synchronously according to this timestamp. Among them, the temperature sensor starts to measure the ambient temperature, with a range of -40 degrees Celsius to 125 degrees Celsius and an accuracy of 0.5 degrees Celsius; the gas concentration sensor starts to detect the volume concentration of specific harmful gases, with a range of zero to 100% Ringelmann concentration and a resolution of 0.000001; the vibration sensor starts to capture the vibration acceleration of the equipment, with a range of ±16 gravitational accelerations and a sensitivity of 100 millivolts per gravitational acceleration.
[0104] (4) The original analog signals collected by each sensor are first processed by the built-in signal conditioning circuit. Among them, the temperature sensor performs anti-aliasing filtering to filter out high-frequency noise above five Hz, the gas concentration sensor performs signal amplification and linearization compensation, and the vibration sensor performs DC bias elimination and sensitivity calibration. The conditioned analog signals are sent to a sixteen-bit analog-to-digital converter and converted into digital quantities at a rate of ten times per second. The temperature signal is converted into a sixteen-bit integer representing degrees Celsius, the harmful gas concentration signal is converted into a sixteen-bit integer representing percentage concentration, and the vibration signal is converted into a sixteen-bit integer representing gravitational acceleration.
[0105] (5) When the IoT gateway receives a new data point from any sensor, it adds a precise millisecond-level timestamp to it. The timestamp is derived from the high-precision clock inside the gateway. The IoT gateway packages a total of 50 timestamped data points generated by each sensor in the last five seconds into an independent data packet according to the preset packaging interval. Each data packet contains a sensor identifier, a timestamp sequence and a corresponding data sequence.
[0106] (6) The IoT gateway transmits the encapsulated temperature data packets, gas concentration data packets, and vibration data packets to the central processing system in real time via the wireless network. After receiving these data packets, the central processing system first unpacks them and stores them in a first-in-first-out circular data buffer according to the timestamp order. The circular data buffer reserves the capacity to store the most recent hour's data, i.e., 7200 data points, for each signal type, thereby forming a continuous time-series signal data stream for real-time verification and anomaly prediction.
[0107] S2.6: Input the continuous time-series signal data into the pre-trained anomaly prediction model; the anomaly prediction model adopts a structure combining a one-dimensional convolutional neural network and a self-attention mechanism, wherein the one-dimensional convolutional neural network is used to extract the local time-series features of the continuous time-series signal data, and the self-attention mechanism is used to capture the global dependency relationship between different sensor signals and output real-time verification results and anomaly prediction indicators.
[0108] Furthermore, the system obtains the latest continuous time-series signal data from the circular data buffer, including three types of signals: temperature, harmful gas concentration, and equipment vibration. Each signal is a time series. The system first normalizes these three signals, mapping the temperature value to between zero and one, the harmful gas concentration value to between zero and one, and the vibration acceleration value to between negative one and positive one. Then, a multivariate time series is extracted using a sliding window with a fixed length of 50 time points, i.e., 5 seconds. The multivariate time series is organized into a three-dimensional data tensor, whose three dimensions represent a batch size of 1, a time step of 50, and a feature dimension of 3, respectively. This three-dimensional data tensor is the direct input to the anomaly prediction model.
[0109] Furthermore, the data tensor is input into the one-dimensional convolutional neural network part of the anomaly prediction model. This convolutional neural network part consists of two consecutive one-dimensional convolutional layers. The first one-dimensional convolutional layer uses 32 convolutional kernels with a width of 3, performs convolution operations along the time dimension with a stride of 1, and uses a linear rectified function as the activation function, followed by a max pooling layer with a width of 2. The second one-dimensional convolutional layer uses 64 convolutional kernels with a width of 3, also performs convolution with a stride of 1, uses a linear rectified function for activation, and is again connected to a max pooling layer with a width of 2. After these two convolution and pooling operations, the input data is compressed in the time dimension and converted into a local temporal feature map, outputting local features.
[0110] Furthermore, the local temporal feature maps output by the one-dimensional convolutional neural network are concatenated and flattened along the channel dimension to form a new feature matrix. This new feature matrix is then input into the self-attention mechanism of the anomaly prediction model. In the self-attention mechanism, the input features are first converted into a query matrix, a key matrix, and a value matrix through three different fully connected layers. Then, the dot product between the transpose of the query matrix and the key matrix is calculated, and the result is scaled by dividing by the square root of the key vector dimension. The attention weights are then calculated using the Softmax function. Finally, the calculated attention weights are used to perform a weighted summation of the value matrix to obtain the output of the self-attention mechanism. This process captures the global dependencies of temperature, gas concentration, and vibration signals within the current time window, thus obtaining global features.
[0111] Furthermore, the global features output by the self-attention mechanism are concatenated with the local features output by the one-dimensional convolutional neural network to form a comprehensive feature vector that integrates local details and global correlations. This comprehensive feature vector is then input into a multi-layer fully connected neural network containing two hidden layers: the first hidden layer has 100 neurons activated by a linear rectified function, and the second hidden layer has 50 neurons activated by a linear rectified function. The output of the multi-layer fully connected neural network is passed to the final output layer, which consists of two parallel sub-output heads. The first sub-output head is a fully connected layer with one neuron and a sigmoid activation function, which outputs a real-time verification result score between zero and one. A higher score indicates safer operating conditions at the current moment. The second sub-output head is also a fully connected layer with one neuron and a linear activation function, which outputs an anomaly prediction index value. The magnitude of this value directly reflects the risk level of anomalies occurring in the near future; a larger positive value indicates a higher risk.
[0112] Furthermore, the anomaly prediction model requires supervised training before deployment. The training data consists of labeled historical continuous time-series signal data, with labels indicating whether the current moment is normal and whether anomalies will occur subsequently. The model training uses the Adam optimizer, with an initial learning rate of 0.001, a batch size of 32, and a loss function that is the weighted sum of the binary cross-entropy loss of the real-time validation results and the mean squared error loss of the anomaly prediction index. The model training stops when the validation set loss no longer decreases significantly, and the resulting final model parameters are deployed in the system for real-time inference, ultimately outputting an assessment of the current state and subsequent risk predictions.
[0113] The step of converting the hierarchical ticket encoding and the continuous time-series signal data into a first embedding representation and a second embedding representation, respectively, and fusing them in non-Euclidean space to form an aligned feature set includes:
[0114] S3.1: The word embedding model is used to convert each level of the hierarchical ticket coding into a fixed-dimensional word vector, and the word vectors of all levels are weighted and concatenated to obtain the first embedding representation;
[0115] Furthermore, the specific steps of S3.1 include:
[0116] (1) Receive the complete hierarchical ticket code. The hierarchical ticket code is a string composed of multiple code segments connected by underscores. According to the predefined hierarchical order, including the order of project code, area code, job type code, and unique serial number, the string is divided into four independent code segments using underscores as delimiters. Each code segment represents an independent discrete symbol.
[0117] (2) Maintain a dedicated vocabulary for hierarchical ticket codes. This vocabulary is constructed by analyzing all historical hierarchical ticket codes before system deployment. Each possible code value in the vocabulary is assigned a unique integer index. For example, all the project codes that have appeared, such as 1234, all the area codes that have appeared, such as 3A2, all the job type codes that have appeared, such as 06, and all possible serial number patterns are included in the vocabulary and numbered. Subsequently, the system initializes a word vector for each index in the vocabulary. In the initial stage, each word vector is a 100-dimensional random vector. The initial value of each element in the random vector is randomly sampled from a uniform distribution.
[0118] (3) The initialized word vectors are trained through a neural network model to learn meaningful representations. The training data consists of historical hierarchical ticket codes. During training, the neural network model adopts a skip-word model architecture. This neural network model takes a code as input and aims to predict other codes that may appear in its context. Specifically, the neural network model sets the context window size to 2. For each training sample, for example, the complete code of project code 1234, region code 3A2, job type code 06, and serial number 000001, the neural network model sequentially takes each code as the center word and attempts to predict the two codes before and after it. The core is a hidden layer, which is a lookup table that maps the index of the input code to the corresponding word vector. This word vector is then passed through a fully connected layer and a Softmax function to predict the context code. The training objective is to minimize the cross-entropy loss between the predicted result and the true context code. The neural network model is optimized using the stochastic gradient descent algorithm with a learning rate of 0.01. The training process iterates through the entire dataset for 50 rounds. After training, the word vectors in the lookup table are no longer random but are numerical representations that capture the semantic relationships between codes. The stochastic gradient descent algorithm is existing technology in this field and is not an inventive solution of this application, so it will not be described in detail here.
[0119] It needs to be explained that the neural network model is a word-skipping model training architecture used to train word vectors. It only runs during the offline training phase and is responsible for training the initialized random word vectors into effective vectors with semantic relationships. The word embedding model, on the other hand, is an online inference module that encapsulates the trained vocabulary and word vector lookup table. It runs after the system is deployed and directly converts the codes at each level of the hierarchical ticket encoding into word vectors. The neural network model produces word vectors through training, and the word embedding model provides online encoding services based on these word vectors.
[0120] (4) During the model deployment phase, when a new hierarchical ticket code needs to be processed, the system first performs the parsing operation in (1) to obtain four code fragments. Then, it queries the lookup table in the trained word embedding model. For each code fragment, the system uses its integer index in the word list to retrieve the corresponding pre-trained 100-dimensional word vector from the lookup table. Thus, the four code fragments are transformed into four 100-dimensional real vectors.
[0121] (5) The system predefines different importance weights for the four levels of code. These importance weights are set based on business knowledge. For example, the weight of project code is 0.4, the weight of region code is 0.3, the weight of job type code is 0.2, and the weight of unique serial number is 0.1. The system multiplies the word vector corresponding to each code by its corresponding weight. Then, the four weighted 100-dimensional vectors are connected in the order of project code vector, region code vector, job type code vector, and unique serial number vector to form a 400-dimensional long vector.
[0122] (6) Input the 400-dimensional vector into a fully connected layer for dimensionality reduction and smoothing. The fully connected layer has 128 output units and uses the hyperbolic tangent function as the activation function. The output of this fully connected layer is a 128-dimensional numerical vector that integrates all layer information and considers layer weights. This vector is the final first embedding representation. The hyperbolic tangent function is a prior art in this field and is not an inventive solution of this application. It will not be described in detail here.
[0123] S3.2: The continuous temporal signal data is processed using a temporal feature encoder; the temporal feature encoder includes stacked temporal convolutional layers and gated recurrent unit layers, used to extract multi-scale temporal features and encode them into a second embedding representation;
[0124] Furthermore, the specific steps in S3.2 include:
[0125] (1) The system obtains the latest continuous time-series signal data from the circular data buffer; the continuous time-series signal data includes the continuous measurement values of three signals in time: temperature, gas concentration and vibration.
[0126] (2) The system truncates the continuous time-series signal data with a fixed time window length, such as 50 time points, to obtain a multivariate time series and organizes it into a three-dimensional data tensor. Its first dimension represents the number of samples, which is usually 1; the second dimension represents the time step, which is 50; and the third dimension represents the number of feature channels, which is 3, corresponding to three types of sensor signals. This three-dimensional data tensor is the input of the time-series feature encoder.
[0127] (3) The three-dimensional data tensor is preprocessed to obtain the preprocessed data tensor and input into the temporal convolutional layer of the temporal feature encoder. The temporal convolutional layer consists of two stacked one-dimensional convolutional modules. The first convolutional module uses 32 convolutional kernels of length 5 and performs convolution operation along the time dimension with a stride of 1. It can capture local patterns in a short time range. After convolution, it is activated by a linear rectified function and followed by a max pooling operation of length 2 to reduce the time dimension and enhance the robustness of the features. The second convolutional module uses 64 convolutional kernels of length 3 and performs convolution with a stride of 1. It is activated by a linear rectified function and then performs max pooling of length 2 again. After processing by these two convolutional modules, the input signal is compressed in the time dimension and converted into a series of high-level multi-scale temporal feature maps.
[0128] (4) The multi-scale temporal feature maps output by the temporal convolutional layer are concatenated in the channel dimension, and then the time dimension and channel dimension are merged to form a two-dimensional feature matrix. The number of rows of the two-dimensional feature matrix corresponds to the number of compressed time steps, and the number of columns corresponds to the total number of feature channels. This two-dimensional feature matrix can be regarded as a reorganized feature sequence on a new abstract time step.
[0129] (5) The recombined feature sequence is input into the gated recurrent unit layer of the temporal feature encoder. The gated recurrent unit layer is composed of a single-layer structure, and the dimension of its internal hidden state is set to 64. The gated recurrent unit processes the input recombined feature sequence in the order of time steps. For each time step in the recombined feature sequence, the gated recurrent unit selectively fuses the input information of the current step with the hidden state information of the previous step through its update gate and reset gate mechanism. This mechanism enables it to effectively capture the long-range dependency relationship in the time series, that is, the influence of distant time points on the current state. After processing the entire recombined feature sequence, the hidden state of the last time step of the gated recurrent unit layer is extracted, and the hidden state vector of the last time step is finally output. The hidden state vector is 64-dimensional and summarizes the global temporal information of the entire input sequence.
[0130] (6) Input the hidden state vector of the last time step output by the gated recurrent unit layer into a fully connected layer for final compression and transformation. The output dimension of this fully connected layer is set to 128-dimensional, and the hyperbolic tangent function is used as the activation function so that the output value is between negative one and positive one. The output of this fully connected layer is a 128-dimensional numerical vector that integrates multi-scale local features and long-range global dependencies, which is the final second embedding representation.
[0131] Furthermore, the temporal feature encoder needs to undergo supervised training before deployment. The training data consists of labeled historical continuous temporal signal data. The training objective can be to predict the signal value at the next time point or to determine whether the sequence is abnormal. The training uses the Adam optimizer with an initial learning rate of 0.001 and a batch size of 32. The training process continues until the performance of the temporal feature encoder on an independent validation dataset no longer shows a significant improvement. After training, all parameters of the temporal feature encoder, including convolutional kernel weights, weights inside gated recurrent units, and weights of fully connected layers, are fixed and deployed to the production environment for real-time generation of the second embedding representation.
[0132] S3.3: Using the first embedded representation and the second embedded representation as nodes, construct a heterogeneous graph, and input the heterogeneous graph into a graph neural network. Through the message passing mechanism in the graph neural network, the first embedded representation node and the second embedded representation node perform multiple rounds of feature interaction and information aggregation in non-Euclidean space, and finally output an aligned feature set.
[0133] Furthermore, the specific steps of S3.3 include:
[0134] (1) The first embedded representation and the second embedded representation are treated as two independent nodes. The first embedded representation node represents the static attribute information of the ticket itself, and its dimension is 128. The second embedded representation node represents the dynamic temporal information of the on-site environment, and its dimension is also 128. The system establishes an undirected edge between the two nodes, thereby constructing a simple heterogeneous graph containing two nodes and one edge.
[0135] (2) The constructed heterogeneous graph is input into the graph neural network, which needs to perform two rounds of complete message passing: Before the message passing begins, each node uses an independent linear transformation layer to initialize its hidden state. For the first embedded representation node, the output dimension of its initial transformation layer is 64-dimensional and it is activated using a linear rectified function; for the second embedded representation node, its initial transformation layer also outputs 64-dimensional data and is activated using a linear rectified function; after initialization, the initial hidden state dimension of both nodes is 64-dimensional.
[0136] (3) In the first round of message passing, each node receives messages from its neighboring nodes. Specifically, the first embedded representation node receives a message from the second embedded representation node. This message is the result of the current hidden state of the second embedded representation node being processed by a message transformation layer, which outputs a 64-dimensional vector. Similarly, the second embedded representation node receives a message from the first embedded representation node. This message is the result of the current hidden state of the first embedded representation node being processed by another message transformation layer, which also outputs a 64-dimensional vector. After receiving a message, each node aggregates the received message with its own hidden state. The aggregation function uses a weighted summation. The weight coefficients are calculated through an attention mechanism, which is a single-layer neural network. The input is the hidden state of the node itself and its neighbors, and the output is a weight value between zero and one. The aggregated feature vector is then updated through a gated recurrent unit. The number of hidden units in the gated recurrent unit is set to 64. After the update, both nodes obtain a new hidden state that incorporates the information of their neighbors.
[0137] (4) In the second round of message passing, the process of (3) is repeated. Each node receives the transformed message from its neighbor node again, calculates the aggregation weight using the attention mechanism, and updates its own hidden state through the gated loop unit. After two rounds of message passing, the hidden state of each node fully integrates the information of the other node. After the message passing ends, the system reads the final hidden state of the two nodes.
[0138] (5) The system concatenates the final 64-dimensional hidden state of the first embedded representation node with the final 64-dimensional hidden state of the second embedded representation node to form a 128-dimensional joint feature vector. This joint feature vector is the alignment feature set, which integrates the static attributes of the ticket and the dynamic temporal information of the scene, and the two types of information are fully aligned in the interaction space defined by the graph structure.
[0139] Furthermore, the graph neural network needs to be trained end-to-end before deployment. The training data consists of historical ticket data and its corresponding continuous time-series signal data from the site. The training objective can be to predict the final risk level. The model training uses the Adam optimizer with an initial learning rate of 0.001 and a batch size of 16. During training, all parameters in the graph neural network, including the weights of each linear transformation layer, the parameters of the attention mechanism, and the parameters of the gated recurrent unit, are optimized. Training continues until the loss function of the model converges on the validation set. After training, the fixed model parameters are used to perform real-time feature alignment in the production environment.
[0140] The process of generating compliance risk levels based on alignment feature sets, and marking the corresponding electronic ticket draft as an abnormal ticket and notifying the reviewer if it exceeds a preset risk level threshold, includes:
[0141] S4.1: Input the alignment feature set into the risk level classifier; the risk level classifier is a multilayer perceptron containing multiple fully connected layers and a Softmax output layer, used to calculate and output the compliance risk level corresponding to the electronic ticket draft;
[0142] Furthermore, the specific steps of S4.1 include:
[0143] (1) The alignment feature set output by the graph neural network is used as the input of the risk level classifier. Before inputting into the risk level classifier, the joint feature vector in the alignment feature set is batch normalized. Specifically, the mean and variance of each dimension of all joint feature vectors in the batch are calculated, and then the mean and variance are used to standardize each joint feature vector so that the numerical distribution of each dimension is close to a normal distribution with a mean of zero and a standard deviation of one, so as to obtain the preprocessed joint feature vector.
[0144] (2) The preprocessed joint feature vector is input to the first fully connected layer of the risk level classifier; the first fully connected layer contains 256 neurons, each neuron has a connection weight with each dimension of the input preprocessed joint feature vector, and a bias term is set. The value of each dimension of the preprocessed joint feature vector is multiplied by the corresponding weight, summed and then the bias is added; then a nonlinear transformation is performed through the linear rectified activation function, which sets all negative values to zero and keeps positive values unchanged; the output is a new 256-dimensional feature vector that captures more complex combination relationships in the input features;
[0145] (3) The output of the first fully connected layer then passes through a random deactivation layer. During the model training phase, the random deactivation layer randomly sets the output of the neurons in the previous layer to zero with a 50% probability. This mechanism forces the network to not rely on the output of any single neuron, thereby enhancing the generalization ability of the model and preventing it from overfitting the training data. Finally, the output is the joint feature vector after passing through the random deactivation layer.
[0146] (4) The joint feature vector after the random deactivation layer is input into the second fully connected layer. The second fully connected layer contains 128 neurons and operates in the same way as the first fully connected layer. It is used to extract the key patterns most relevant to the risk level determination.
[0147] (5) The 128-dimensional feature vector output by the second fully connected layer is fed into the final output layer. This output layer is a fully connected layer, and the number of its neurons strictly corresponds to the number of risk levels to be classified. Assuming that the system divides compliance risks into four levels, such as low risk, medium risk, high risk, and extremely high risk, this layer is set with four neurons. Each neuron calculates a score. Specifically, the input vector is multiplied by the weight vector corresponding to each neuron, and a bias is added to obtain the original score of the risk level. Then, these four original scores are fed into the Softmax function for calculation. The Softmax function first takes the exponent of each score, and then divides each exponent value by the sum of all four exponent values. This process transforms the four original scores into a probability distribution. Each risk level corresponds to a probability value between zero and one, and the sum of all probabilities is one.
[0148] (6) The system selects the risk level corresponding to the highest probability among the four probability values output by the Softmax function as the final compliance risk level of the electronic ticket draft. For example, if the probability of the extremely high risk level is the highest, the system determines that the compliance risk level of the ticket is extremely high.
[0149] Furthermore, the risk level classifier, as a multilayer perceptron, requires supervised training before deployment. The training data consists of a set of aligned features from historical tickets and their manually labeled true risk level labels. The model training uses the Adam optimizer with an initial learning rate of 0.001 and a batch size of 64. The loss function is the standard cross-entropy loss function used in classification tasks, which measures the difference between the probability distribution predicted by the risk level classifier and the true label distribution. The training process continues until the accuracy of the risk level classifier on the validation dataset no longer significantly improves. After training, the weights and bias parameters of each layer of the risk level classifier are fixed and used to automatically classify the risk level of new electronic ticket drafts.
[0150] Furthermore, the number of neurons in the input layer of the multilayer perceptron is the same as the dimension of the aligned feature set. The first hidden layer contains 512 neurons, uses the ReLU activation function, and applies Dropout regularization. The second hidden layer contains 256 neurons, uses the ReLU activation function, and applies Dropout regularization. The output layer is a Softmax layer, and the number of output neurons corresponds to the number of compliance risk levels.
[0151] S4.2: Compare the compliance risk level with the preset risk level threshold. If the compliance risk level is greater than the risk level threshold, generate an anomaly marking instruction, mark the electronic ticket draft as an abnormal ticket in the electronic ticket database, generate a notification message containing the hierarchical ticket code and the reason for the anomaly, and send it to the predefined reviewer terminal through the message push interface.
[0152] Furthermore, the specific steps in S4.2 include:
[0153] (1) The system obtains the compliance risk level output by the risk level classifier, such as low risk, medium risk, high risk, and extremely high risk, corresponding to 1-4 respectively. At the same time, it reads the preset risk level threshold. The risk level threshold is a corresponding level label. For example, setting it to 1 represents low risk, setting it to 2 represents medium risk, setting it to 3 represents high risk, and setting it to 4 represents extremely high risk. The system compares the value corresponding to the compliance risk level with the value corresponding to the risk level threshold. If the value of the compliance risk level is greater than the value of the risk level threshold, it is determined that the threshold is exceeded and the exception handling process is triggered. For example, if the compliance risk level is 3, which is high risk, and the risk level threshold is 2, then 3>2, and the condition is met.
[0154] (2) When the comparison result is confirmed to exceed the risk level threshold, the system generates a structured anomaly marking instruction. The structured anomaly marking instruction contains key information: the unique identifier of the electronic ticket draft to be marked, i.e. its hierarchical ticket code, and the anomaly status identifier to be marked. According to the structured anomaly marking instruction, the system locates the record corresponding to the hierarchical ticket code in the electronic ticket database. Then, the system writes the anomaly identifier into the status field of the record, for example, updating the status value from pending review to anomaly. At the same time, a record is appended to the dedicated log field of the record, which includes the marking timestamp and the triggered risk level value.
[0155] (3) While marking the database, compile the notification information to be sent to the reviewers, including: first, extract the following core elements from the current processing context: the complete hierarchical ticket code of the ticket marked as abnormal; then, according to the specific compliance risk level output by the risk level classifier, match the corresponding abnormal reason text from the predefined description library, and the system organizes this information according to the predetermined template to form a complete notification text.
[0156] It should be explained that the description library is a template library that maps risk levels to textual descriptions of anomalies. It is a standard pre-configured library, which is a template library of textual descriptions of anomalies that is pre-configured by the system and bound to risk levels. It is a configuration module that is understood by those skilled in the art and will not be elaborated on here.
[0157] For example, if the compliance risk level is 2, i.e. medium risk, then the description library is retrieved as: there is a slight compliance deviation; if the compliance risk level is 3, i.e. high risk, then the description library is retrieved as: there is a significant deviation between the on-site dynamic data and the safety specifications required by the ticket operation type; if the compliance risk level is 4, i.e. extremely high risk, then the description library is retrieved as: the operating conditions seriously fail to meet safety requirements.
[0158] (4) The system determines the reviewers who need to receive this notification according to predefined rules. These rules may be based on the job type, area code, or risk level itself. The system queries the terminal contact information of these reviewers from the personnel information database, such as mobile phone number or internal communication account. Then, the system binds the compiled notification text with the terminal information of the reviewers and encapsulates it into the data format required by the message push interface. The data format usually includes fields such as message header, recipient address, and message body.
[0159] (5) Call the internal message push interface to send out the formatted and encapsulated message data packet. After the interface is called, receive the response code returned by the interface synchronously and check the response code to confirm whether the message has been successfully received and is waiting to be sent. Regardless of whether the message is successfully sent, record the information of this notification operation, including the notification content, recipient, sending timestamp and interface response status, in the system operation log for verification.
[0160] The process of tracing the root causes of abnormal tickets and generating rectification plans includes:
[0161] S4.3: Based on the hierarchical ticket code of the abnormal ticket, retrieve the historical operation records and historical continuous time-series signal data associated with the abnormal ticket from the operation log database and the signal history database;
[0162] Furthermore, the specific steps of S4.3 include:
[0163] (1) Obtain the complete hierarchical ticket code of the ticket marked as abnormal, parse the hierarchical ticket code and decompose it into four independent parts: project code, area code, job type code and unique serial number. Set the search time range to 360 days before the current abnormal occurrence time. The target data source for the search is the job log database and the signal history database.
[0164] (2) Based on the parsed code components, construct a query statement, including: For the job log database, the core logic of the query statement is to find records that meet all of the following conditions: the project code field is completely consistent with the project code of the abnormal ticket; the area code field is completely consistent with the area code of the abnormal ticket; the job type code field is completely consistent with the job type code of the abnormal ticket; the job timestamp is within the set 360-day time range; For the signal history database, the query logic is similar, but it searches for all data packets whose project code, area code and job type code attached to the signal data packet match the abnormal ticket and whose signal record timestamp is within the 360-day range;
[0165] (3) Send the constructed query statement to the operation log database and the signal history database respectively. After the operation log database executes the query, it returns a result set containing all historical operation records that meet the conditions. Each record may contain information such as operation time, responsible personnel, operation content summary, and completion status. After the signal history database executes the query, it returns a result set containing all historical signal data packets that meet the conditions. Each data packet contains a timestamp sequence and the corresponding temperature, gas concentration, and vibration signal sequence.
[0166] (4) For the operation log records, the system directly retains them all as a set of historical operation records; for the signal historical data, the system needs to associate them with the operation records in time, check the operation time period of each operation log record, such as the start time and end time, and then extract all signal data packets whose timestamps fall within any operation time period from the result set of historical signal data packets. In this way, discrete signal data packets are associated with specific operation activities to form historical continuous time-series signal data corresponding to each historical operation.
[0167] (5) For historical job records, they are arranged in reverse order of job time, that is, the most recent job is listed first. For each job, the corresponding job log information is bound together with its associated historical continuous time-series signal data, and finally a structured list is output. Each item in the list represents a historical job event, which contains the detailed log and complete time-series signal data of the event. This list is the historical job record and historical continuous time-series signal data associated with the current abnormal ticket.
[0168] S4.4: The association rule mining algorithm is used to analyze the retrieved historical operation records and historical continuous time series signal data to identify the combination of operation factors and signal patterns that cause the compliance risk level to exceed the standard, and determine them as the root cause factors;
[0169] Furthermore, the specific steps of S4.4 include:
[0170] (1) Obtain the retrieved historical operation records and historical continuous time series signal data. For each historical operation, the system constructs a transaction. The transaction consists of multiple items, which come from two aspects: one is the discrete attributes extracted from the historical operation records, such as operation time, responsible personnel, and operation content; the other is the discrete events identified by analyzing the associated historical continuous time series signal data, such as temperature exceeding limits and vibration abnormalities. The transaction set corresponding to all historical operations constitutes the transaction database.
[0171] (2) The system scans the entire transaction database for the first time, counts the number of times each event item appears, and obtains the support count of each item. The system presets a minimum support threshold, for example, setting the minimum support threshold to 10%. The system only retains items whose support count is greater than or equal to the total number of transactions multiplied by the minimum support threshold as frequent items, and sorts the frequent items according to their support count from high to low to form a list of frequent items.
[0172] (3) The system scans the transaction database for the second time and begins to build a frequent pattern tree. The root node of the frequent pattern tree is an empty node. For each transaction in the transaction database, the system first reorders the items in the transaction according to the order of the generated frequent item list. Then, starting from the root node, the system inserts the items in the sorted transaction into the tree one by one. If the current node has a child node with the same item name as the item to be inserted, the count of the child node is incremented by one. Otherwise, a new child node is created and its count is set to one. In this way, all transactions are integrated into a tree structure. Transactions that share the same prefix will share the same path in the tree, thus compressing data storage.
[0173] (4) The system starts from the bottom of the list of frequent items, i.e. the item with the lowest support, and traverses upwards to generate a conditional pattern base for each item. The conditional pattern base refers to the set of prefix paths of all paths containing the item and the count of the path. For example, for the item "exceeding the limit of hazardous gas concentration", find all paths from the root node to the node containing the item. The other items on these paths besides the item itself and their counts constitute the conditional pattern base of the item "exceeding the limit of hazardous gas concentration". Then, using this conditional pattern base as a new transaction database, a new conditional frequent pattern tree is recursively constructed, and frequent itemsets under this condition are mined. This process is recursively carried out until the conditional pattern base is empty or contains only a single item. In this way, all frequent itemsets that meet the minimum support threshold are found, i.e., those event combinations that often appear together.
[0174] (5) Based on all the frequently mined itemsets, generate association rules, including: for each frequent itemset, such as a frequent itemset containing the work time being at night and the vibration amplitude exceeding the limit, the rule can be generated: if the work time is at night, then the vibration amplitude exceeds the limit. The system calculates the confidence of each rule. The confidence is equal to the support of the itemset corresponding to the rule divided by the support of the antecedent itemset. The system presets a minimum confidence threshold, such as 70%. The system selects those rules with a confidence greater than or equal to 70%, which are called strong association rules. The antecedents of these strong association rules, that is, the event combinations that cause the consequent, are identified and determined as root cause factors. For example, if the work time is at night and the responsible person is A, the confidence is as high as 85%. Then the combination of the work time being at night and the responsible person being A is determined to be a root cause factor.
[0175] S4.5: Based on the root cause factors, query the pre-set rectification measures knowledge graph to find matching rectification measure items, and combine them to generate a rectification plan for the abnormal ticket.
[0176] Furthermore, the specific steps of S4.5 include:
[0177] (1) Obtain the root cause factors, standardize the root cause factors, and map them to the entity types and entity identifiers defined in the knowledge graph of pre-set rectification measures. For example, map the working time as night as the entity type working condition and the entity identifier night work; map the responsible person as A as the entity type personnel and the entity identifier A; map the vibration amplitude exceeding the limit as the entity type equipment risk and the entity identifier vibration exceeding the limit.
[0178] (2) The system takes the mapped entity set as the starting point and performs a traversal query in the rectification measures knowledge graph. The rectification measures knowledge graph consists of nodes and edges. Nodes represent entities such as risk factors, rectification measures, equipment types, etc., and edges represent relationships between entities such as causing, needing to be taken, applicable, etc. The query starts from each root cause entity node and expands in multiple steps along the predefined relationship edges. For example, starting from the vibration exceeding limit node, the equipment failure node may be found along the cause relationship edge. Then, from the equipment failure node, the two rectification measures nodes of strengthening inspection and immediate shutdown are found along the need to be taken relationship edge. At the same time, starting from the night operation node, the two rectification measures nodes of increasing lighting and double monitoring may be found along the need to be taken relationship edge. All rectification measure nodes that can be reached from the root cause entity node through one to three hop relationship paths are traversed.
[0179] (3) Merge all the rectification measure nodes obtained from the query, remove duplicates, and form a candidate rectification measure set. Calculate a priority score for each measure based on its attributes in the rectification measure knowledge graph and its path relationship with the root cause node. Factors considered when calculating the priority score include: the path distance between the measure and the root cause node (the closer the distance, the higher the score); the importance weight attribute of the measure node itself (the higher the weight, the higher the score); and the number of times the measure has been verified as effective in historical cases (the more times, the higher the score). Sort the candidate rectification measures from high to low priority scores.
[0180] (4) Based on the sorted list of candidate rectification measures, a structured rectification plan is generated. The rectification plan first lists the root cause analysis summary of the abnormality. Then, the core part of the rectification plan is the specific rectification measures list. For each selected rectification measure, the system will extract its detailed description, expected effect, required resources and execution steps from the rectification measures knowledge graph. For example, for strengthening inspection measures, it will be specified that the inspection frequency should be increased to once per hour, and the key inspection area is the equipment connection that generates vibration. For increasing lighting measures, it will be specified that the specific illuminance requirement of the added lighting equipment is more than 50 lux. These measures are arranged in a logical order, such as taking immediate corrective measures such as stopping the machine for inspection first, and then taking preventive measures such as strengthening inspection and double monitoring.
[0181] (5) Fill the generated structured rectification plan into the predefined template to form a complete and executable rectification plan document, and associate it with the corresponding abnormal ticket record. The rectification plan document includes a title, unique number, associated abnormal hierarchical ticket code, root cause, list of specific rectification measures, suggestions for the person in charge of each measure, suggestions for completion time limit, and verification standards.
[0182] After review, the abnormal tickets are registered as pending tickets, a processing path plan is generated, and the processing path plan is assigned to dynamically specified processing nodes, including:
[0183] S4.6: Upon receiving a review confirmation instruction sent by the reviewer through the reviewer's terminal, update the status of the abnormal ticket to a pending ticket and store it in the pending ticket queue.
[0184] Furthermore, the specific steps of S4.6 include:
[0185] (1) When the reviewer performs a confirmation operation on the abnormal ticket on his / her terminal, the terminal generates a structured review confirmation instruction and sends it to the system through the network. The review confirmation instruction contains the following key fields: the instruction type is review confirmation, the unique hierarchical ticket code of the corresponding abnormal ticket, the timestamp of the review operation and the identity of the person performing the review operation. After receiving the review confirmation instruction, the system performs security verification, including verifying the integrity of the data packet and the operation permission of the reviewer. After the verification is passed, the review confirmation instruction is parsed and the hierarchical ticket code is extracted.
[0186] (2) Using the parsed hierarchical ticket code as the query condition, the system accurately searches for the corresponding ticket record in the electronic ticket database. To prevent data inconsistency caused by concurrent operations, the system applies a row-level lock to the ticket record before reading it, and verifies whether the current state of the ticket record is abnormal. If the current state is abnormal, the operation is terminated, the lock is released and an error log is recorded. Only when the current state is confirmed to be abnormal will the database update operation be performed, and the status field of the ticket record will be updated from abnormal to pending. At the same time, a new log entry is added to the audit log field of the ticket record. The log entry records the following information in detail: the timestamp of the status change, i.e. the current system time; the reason for the status change, recorded as review confirmation; and the identity of the reviewer who triggered the change. After the update is completed, the system immediately commits the database transaction and releases the previously applied row-level lock to ensure that the data change is persisted and allows non-processes to access the record.
[0187] S4.7: Based on the operation type code, root cause factors, and status of all available disposal nodes of the ticket to be disposed of, calculate the optimal disposal path in the predefined disposal flowchart using the shortest path algorithm, and generate a disposal path scheme that includes the sequence of disposal steps, expected time consumption, and required resources.
[0188] Furthermore, the specific steps in S4.7 include:
[0189] (1) Obtain the predefined processing flowchart skeleton. The processing flowchart is a directed graph. Nodes represent different processing states, such as pending allocation, on-site inspection, waiting for spare parts, maintenance in progress, verification testing in progress, and processing completed. Directed edges represent the processing steps required to transition from one state to another. The system dynamically calculates the weight of each edge in the graph based on the specific attributes of the current ticket to be processed. The weight calculation comprehensively considers two core factors: first, the estimated time of the processing step in the standard operating procedure, in minutes, for example, the estimated time of the on-site inspection step is 60 minutes; second, the resource cost complexity required to execute the step, which is a dimensionless score comprehensively evaluated based on the required skill level, equipment scarcity, etc. For example, the resource cost complexity of conventional skills is recorded as one, and the resource cost complexity of special skills is recorded as five. The system multiplies the estimated time by the resource cost complexity to obtain a comprehensive weight value. For example, an edge with a time of 60 minutes and a resource cost complexity of 3 has a weight of 180. In this way, the processing flowchart generates a dynamic weight with practical significance for the current specific ticket.
[0190] (2) The starting node of the path planning is the current state of the ticket to be processed, i.e. the node to be assigned, and the target node is fixed as the final state of the processing flow, i.e. the processing completed node. The system locates these two nodes in the processing flow diagram.
[0191] (3) Initialize the data structures required for Dijkstra's algorithm, including: First, create a distance dictionary to record the current known shortest distance from the starting node to each other node in the graph. Initially, set the distance of the starting node to the node to be assigned to to zero, and set the distance of all other nodes in the graph to infinity; Second, create a predecessor node dictionary to record the previous node on the shortest path to each node. Initially, set the predecessor nodes of all nodes to empty; Finally, create an unvisited node set, which initially contains all nodes in the graph.
[0192] (4) Enter the loop. In each iteration, select the node with the smallest current distance value from the set of unvisited nodes as the current node. This includes: In the first iteration, the current node is the starting node with a distance of zero. Then, Dijkstra's algorithm checks all the neighboring nodes of the current node, that is, the nodes that can be directly reached through directed edges. For each neighboring node, Dijkstra's algorithm calculates the distance of a path from the current node to it. This distance is equal to the distance of the current node plus the weight of the edge connecting the two nodes. If this calculated new distance is less than the distance recorded in the distance dictionary of the neighboring node, then update the distance dictionary of the neighboring node. The distance to the neighbor node is this smaller new distance, and the predecessor of the neighbor node in the predecessor node dictionary is updated to the current node. After checking all neighbors, the current node is marked as visited and removed from the set of unvisited nodes. Then the next iteration begins, and the node with the smallest distance from the unvisited nodes is selected as the new current node. The above process is repeated until the target node is marked as visited after being processed, or the smallest distance in the set of unvisited nodes is infinite, indicating that the target node is unreachable. The Dijkstra algorithm is prior art in this field and is not an inventive solution of this application, so it will not be described in detail here.
[0193] (5) When Dijkstra's algorithm terminates due to the access to the target node, the system backtracks through the predecessor node dictionary. Starting from the completion of the target node's processing, it searches backwards for its predecessor node until it backtracks to the starting node to be assigned. After this reversed node sequence is reversed, a node sequence from the starting node to the target node is obtained. The directed edge between two adjacent nodes in this node sequence represents a processing step. Therefore, the sequence of edges is the sequence of processing steps contained in the optimal processing path.
[0194] (6) Based on the obtained sequence of disposal steps, generate the final disposal path plan. The disposal path plan clearly lists the name of each step. At the same time, the disposal path plan queries and fills in the estimated time of each step and the specific resource type and quantity required to execute the step from the disposal flowchart and standard operation library.
[0195] S4.8: Based on the resource requirements of each disposal step in the disposal path scheme, dynamically select qualified disposal nodes from the disposal node resource pool, and allocate each disposal step to the corresponding disposal node.
[0196] Furthermore, the specific steps of S4.8 include:
[0197] (1) Analyze the generated optimal disposal path scheme, extract each disposal step contained in the optimal disposal path scheme, and for each disposal step, obtain its detailed resource requirement specifications from the pre-set knowledge base, including the professional skill tags that the disposal node must have, such as an advanced electrical maintenance certificate or a crane operation qualification; the estimated time of the disposal step, such as 120 minutes; and the expected response time based on business rules, such as requiring that the interval from the allocation of the step to the start of execution of the node does not exceed 30 minutes.
[0198] (2) The system sends a status query request to the resource pool of disposal nodes. Each disposal node in the resource pool, which can be a person, a team, or an automated device, will return its real-time status information. The real-time status information includes: the current load, i.e., the total number of disposal steps that the node has been assigned but not yet completed; a list of all professional skill tags it holds; and its current geographical coordinates. The system collects the responses of all nodes and constructs a global resource status snapshot at the current time.
[0199] (3) The system constructs a multi-objective optimization function for the node allocation problem of the entire disposal path scheme. The multi-objective optimization function aims to minimize three objectives simultaneously. The first objective is to minimize the total load imbalance, which is calculated as the standard deviation of the final load of all selected disposal nodes. The final load of each disposal node is the initial load plus one, with the aim of making the task allocation as even as possible. The second objective is to minimize the total skill matching gap, which is calculated as the sum of the matching degree differences between the professional skill tags required for each step and the tags possessed by the assigned nodes. When the matching degree is completely matched, the time difference is zero, and when the matching degree is not completely matched, the time difference is positive. The third objective is to minimize the total expected delay, which is calculated as the sum of the difference between the expected response time calculated based on the estimated distance between the node's geographical location and the work site and the node's current load and the expected response time.
[0200] (4) The system uses an improved genetic algorithm to solve this multi-objective optimization problem. The improved genetic algorithm first initializes a population containing 50 individuals, i.e., 50 possible allocation schemes. Each individual is represented by a chromosome, the length of which is equal to the number of disposal steps. Each gene locus represents a disposal step, and the gene value represents the disposal node number assigned to that step. The population initialization adopts a heuristic method, prioritizing the selection of the node with the lowest current load and the required skill for each step. Then, iterative optimization is performed, with the number of iterations set to 100 generations. In each generation, the three objective function values for each individual, i.e., each allocation scheme, are calculated. Then, fast non-dominated sorting is used to divide the individuals into different Pareto front levels, and in the same... Within the frontier level, crowding degree calculation is used to assess individual diversity. Based on ranking and crowding degree, a binary tournament selection method is used to select parent individuals. Then, a single-point crossover operation is performed on the selected parent individuals with a probability of 0.85 to generate offspring. Then, a mutation operation is performed on the offspring individuals with a probability of 0.01, randomly changing any assigned node. The newly generated offspring are merged with the parent individuals, and the non-dominated ranking and crowding degree comparison are performed again to select the 50 best individuals to form a new generation of population. After 100 generations of iteration, the Pareto optimal solution set is selected from the final population. The fast non-dominated ranking, the binary tournament selection method, and the crowding degree calculation formula are all prior art in this field and are not inventive solutions of this application, and will not be described in detail here.
[0201] (5) Select a final allocation scheme from the obtained Pareto optimal solution set according to the current strategy. For example, select the scheme with the smallest total load imbalance to achieve load balancing. After the scheme is determined, the system officially sends a task allocation instruction to each selected processing node. The task allocation instruction contains information such as specific processing steps, expected completion time, and work location. At the same time, the system updates the status of these nodes in the resource pool, increments their current load by one, and persists the allocation relationship to the database to ensure that the task status is traceable.
[0202] The process of making the verified electronic tickets effective and archived, and uploading them to the blockchain for evidence storage, includes:
[0203] S5.1: For draft electronic tickets that are not marked as abnormal and whose compliance risk level does not exceed the preset risk level threshold, add an electronic signature and timestamp, and change their status to effective electronic ticket;
[0204] Furthermore, the specific steps in S5.1 include:
[0205] (1) In the final stage of the processing flow, the system performs a final qualification verification on the electronic ticket draft. The verification includes two parallel conditions that must be met simultaneously: First, the system queries the status flag of the electronic ticket draft in the electronic ticket database to confirm that it has not been marked as an abnormal ticket; Second, the system checks the compliance risk level output by the risk level classifier again to confirm that its corresponding value does not exceed the preset risk level threshold; Only when both of these conditions are met will the system determine that the electronic ticket draft is qualified to take effect. If either condition is not met, the process will terminate and the ticket will not take effect.
[0206] (2) The core data of the electronic ticket draft is digitally signed using an asymmetric encryption algorithm to ensure the integrity and non-repudiation of the data. The specific steps are as follows: First, the key data fields of the electronic ticket draft are extracted, including the hierarchical ticket code, target entity information, qualification verification results, hash value of continuous time series signal data, hash value of alignment feature set and compliance risk level; then, a 256-bit hash value is calculated for the key data using SHA-256 as a data digest; then, the data digest is encrypted using a pre-allocated private key representing the system authority to generate an electronic signature; the length of the private key used is 1024 bits, and the encryption algorithm is RSA algorithm. SHA-256 and RSA algorithms are existing technologies in this field and are not the inventive solutions of this application, and will not be elaborated here.
[0207] (3) The obtained data digest is sent to an authoritative and trusted timestamp service provider. After receiving the hash value, the trusted timestamp service provider binds the current standard time information with the hash value and signs the binding information with its own private key to generate a trusted timestamp token. The system receives and stores this timestamp token. This timestamp provides legal evidence of the effective time of the electronic ticket.
[0208] (4) The system finds the corresponding electronic ticket draft record in the electronic ticket database and performs a database update operation: changes the status field of the record from under review or pending to effective to effective. At the same time, the generated electronic signature and the obtained trusted timestamp token are written as metadata into the specified field of the record. In addition, the system timestamp of the effective operation and the automatic process identifier of the operation will also be recorded in the audit log.
[0209] (5) After the database update operation is successfully submitted, an internal event notification that the electronic ticket has taken effect is generated. The internal event notification contains the hierarchical ticket code and the effective timestamp of the effective electronic ticket. The system publishes this event to the internal message bus. At this point, the electronic ticket is officially effective.
[0210] S5.2: Package the entire process information of the effective electronic ticket into an archive data package and store it in the electronic ticket archive database; the entire process information includes hierarchical ticket code, target entity information, qualification verification results, continuous time series signal data, alignment feature set and compliance risk level;
[0211] Furthermore, the specific steps in S5.2 include:
[0212] (1) Based on the hierarchical ticket code of the effective electronic ticket, extract its complete full-process information from multiple data sources in the system, specifically including: extracting static information from the electronic ticket master database, including the hierarchical ticket code itself, target entity information and final compliance risk level; extracting process information from the verification process database, including detailed results of qualification verification, such as the original return code of interface verification and the confidence score of artificial intelligence hidden defect identification; extracting dynamic information from the time series data buffer, that is, all continuous time series signal data corresponding to the ticket, including the original numerical sequence of temperature, gas concentration and vibration signal and the corresponding timestamp; extracting analysis process information from the feature repository, that is, the alignment feature set generated by the model; ensuring that all these scattered data are correctly associated with the same ticket through the hierarchical ticket code;
[0213] (2) The collected end-to-end information is converted into a unified format suitable for long-term storage and exchange. In this embodiment, the system adopts the lightweight data exchange format JavaScript object representation. For structured data, such as target entity information, its fields and values are directly mapped to key-value pairs in JavaScript object representation. For semi-structured or unstructured data, such as log text in qualification verification results or numerical arrays in alignment feature sets, they are also encapsulated into a specific JavaScript object representation structure. For example, the feature array is placed under a key called feature vector. For continuous time-series signal data, it is organized into a JavaScript object representation object containing timestamp sequence and signal value sequence. The entire dataset is serialized into a single, well-structured JavaScript object representation document, and finally, the serialized JavaScript object representation document is obtained.
[0214] (3) Process the serialized JavaScript object representation document, including: compressing the document using the DEFLATE compression algorithm, wherein the compression level is set to 6. After compression, the system uses advanced encryption standards to encrypt the compressed data. The encryption key is provided by the system key management system. The key length is 128 bits. The encryption mode is Galois / counter mode. Galois / counter mode provides both confidentiality and integrity protection. Finally, a ciphertext data block is output.
[0215] (4) The encrypted ciphertext data block is packaged together with metadata to form the final archive data package. The metadata includes: a unique identifier for the archive data package, which is generated using the version four variant one format of the Universal Unique Identifier; the hierarchical ticket code of the original effective electronic ticket; the system timestamp of the data package completion; the DEFLATE compression algorithm identifier; the Advanced Encryption Standard 128-bit Galois / counter mode encryption algorithm identifier; and the ciphertext of the data encryption key used for decryption, which is encrypted and protected by the system master key. This metadata is placed in plaintext in the header of the archive data package.
[0216] (5) Write the generated archived data packet to the electronic ticket archived database. The electronic ticket archived database is a system optimized for cold data storage. The system establishes a connection through the database application programming interface and stores the archived data packet as a complete binary large object in a predefined data table. The primary key of the database table is the unique identifier of the archived data packet. At the same time, the system records the mapping relationship between the hierarchical ticket code and the corresponding archived data packet identifier in the index table of the database so as to quickly retrieve its complete archived data according to the ticket code. After the write operation is completed, the system closes the database connection and records a log of successful archiving operation.
[0217] S5.3: Generate a Merkle tree from the archived data package, calculate its root hash value, and submit the root hash value and the hierarchical ticket code to the blockchain network to complete the evidence storage transaction.
[0218] Furthermore, the specific steps in S5.3 include:
[0219] (1) Obtain the generated archive data packet. The archive data packet is a binary data block. The system first divides the archive data packet into multiple fixed-size data blocks. The fixed size is set to 1024 bytes. If the size of the last data block is less than 1024 bytes, it is filled with zero bytes to reach 1024 bytes. After the division is completed, the SHA-256 secure hash algorithm is used to calculate the hash value of each data block in turn, and outputs a 256-bit, i.e. 32-byte hash value. Each hash value calculated will be used as a leaf node of the Merkle tree.
[0220] (2) After obtaining the hash values of all leaf nodes, the intermediate levels of the Merkle tree are constructed from bottom to top, including: the system groups all the obtained leaf node hash values into pairs. If the number of leaf nodes is odd, the hash value of the last leaf node is copied to make it even. For each pair of adjacent leaf node hash values, the system concatenates them in order to form a 64-byte merged data block. Then, the SHA-256 algorithm is applied to this merged data block again to calculate its hash value. This newly calculated hash value is used as the hash value of the parent node of the two leaf nodes.
[0221] (3) Treat all the obtained parent node hash values as the node set of the new layer, and then repeat (2) to obtain the parent nodes of the higher layer. For example, the first layer has 8 leaf nodes, and after (2), four parent nodes are obtained. The four parent nodes are grouped and hashed in pairs to obtain two grandparent nodes. The two grandparent nodes are hashed together to obtain a unique root node hash value. This root node hash value is the Merkle root hash value of the entire archive data packet, which represents the integrity and unique fingerprint of the entire data packet.
[0222] (4) The system is preparing to submit a notarized transaction to the blockchain network. Its core content includes two parts: the first part is the Merkel root hash value calculated in (3), which is a 32-byte hexadecimal string; the second part is the hierarchical ticket code of the effective electronic ticket corresponding to the archived data packet, which is a plaintext string. The system encodes and encapsulates these two parts of information, along with the necessary timestamps and system identifiers, in accordance with the transaction data format specified by the blockchain network.
[0223] (5) The constructed data packet of evidence storage is submitted to the blockchain network through the application programming interface provided by the blockchain node software. The transaction is broadcast to each node in the peer-to-peer network. The node collects the transaction into the transaction pool to be packaged. When the verification node successfully generates a new block, it selects the transaction from the transaction pool and includes it in the new block. The system continuously listens to the blockchain until it finds that the block containing the transaction has been successfully added to the main chain and six more blocks have been generated in succession. At this time, it is considered that the transaction has been fully confirmed and cannot be tampered with. The system records the block height and transaction hash value of the transaction as proof of the completion of evidence storage.
[0224] Example 2:
[0225] Please see Figure 3 Another embodiment of the present invention provides: an intelligent verification system for electronic tickets, comprising:
[0226] Ticket draft generation module 10 is used to receive target entity information and generate electronic ticket drafts with hierarchical ticket codes;
[0227] The verification module 20 is used to extract the qualification document information associated with the electronic ticket draft, and output the qualification verification result after interface verification and AI hidden defect identification. If the qualification verification is passed, the continuous time-series signal data of the on-site operation conditions are collected by the on-site IoT sensor device set for real-time verification and anomaly prediction.
[0228] The feature fusion processing module 30 is used to perform feature transformation and non-Euclidean space fusion of hierarchical ticket codes and continuous time-series signal data collected on site, and output an aligned feature set.
[0229] The risk level determination module 40 is used to calculate the compliance risk level and mark abnormal tickets based on the alignment feature set, generate notification information containing hierarchical ticket codes and abnormal reasons, and send it to the reviewer's terminal through the message push interface to achieve accurate risk identification and abnormal warning.
[0230] The abnormal ticket handling module 50 is used to locate the root cause of risk exceeding the standard by using the association rule mining algorithm based on the hierarchical ticket code of the abnormal ticket, and generate a rectification plan. After receiving the review and confirmation instruction, the abnormal ticket is registered as a ticket to be handled. Combining the operation type, root cause and handling node status, the optimal handling path plan is generated and accurately allocated, realizing the integrated processing of root cause tracing, plan generation and path allocation of abnormal tickets.
[0231] The dynamic optimization module 60 is used to make dynamic adjustments based on the actual disposal results of the disposal nodes.
[0232] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments under the guidance of the present invention without departing from the spirit and scope of the present invention. All of these variations are within the protection scope of the present invention.
Claims
1. An intelligent verification method for electronic tickets, characterized in that, include: Receive target entity information and generate an electronic ticket draft containing hierarchical ticket codes; Extract the qualification document information associated with the draft electronic ticket, verify it through the interface and identify hidden defects using AI, and output the qualification verification result. If the qualification verification is passed, the continuous time-series signal data of the on-site working conditions is collected by the on-site IoT sensor set for real-time verification and anomaly prediction. The IoT sensor set includes temperature sensors, gas concentration sensors and vibration sensors. The hierarchical ticket code and the continuous time-series signal data are respectively converted into a first embedding representation and a second embedding representation, and then fused in non-Euclidean space to form an aligned feature set. Compliance risk levels are generated based on the alignment feature set. If the risk level exceeds the preset threshold, the corresponding electronic ticket draft is marked as an abnormal ticket and a review is notified. The abnormal ticket is traced back to its source and a rectification plan is generated. After review, the abnormal ticket is registered as a ticket to be disposed of. A disposal path plan is generated and the disposal path plan is assigned to the dynamically specified disposal node. The verification process is dynamically adjusted based on the processing results of the processing nodes. For electronic tickets that pass the verification, they are made effective and archived, and uploaded to the blockchain for evidence storage. The step of converting the hierarchical ticket encoding and the continuous time-series signal data into a first embedding representation and a second embedding representation, respectively, and fusing them in non-Euclidean space to form an aligned feature set includes: A word embedding model is used to convert each level of the hierarchical ticket encoding into a fixed-dimensional word vector, and the word vectors of all levels are weighted and concatenated to obtain the first embedding representation; The continuous temporal signal data is processed using a temporal feature encoder; the temporal feature encoder includes stacked temporal convolutional layers and gated recurrent unit layers, used to extract multi-scale temporal features and encode them into a second embedding representation; Using the first and second embedded representations as nodes, a heterogeneous graph is constructed. The heterogeneous graph is then input into a graph neural network. Through the message passing mechanism in the graph neural network, the first and second embedded representation nodes perform multiple rounds of feature interaction and information aggregation in non-Euclidean space, ultimately outputting an aligned feature set.
2. The intelligent verification method for electronic tickets as described in claim 1, characterized in that, The process of receiving target entity information and generating an electronic ticket draft containing hierarchical ticket codes includes: Based on the entity type and entity identifier indicated by the target entity information, a pre-set coding rule library is invoked to generate a hierarchical ticket code consisting of project code, region code, job type code and unique serial number connected in sequence. The generated hierarchical ticket code is bound to the target entity information, and the work content, planned work time, and responsible personnel information extracted from the target entity information are filled in according to the preset electronic ticket template to form an electronic ticket draft.
3. The intelligent verification method for electronic tickets as described in claim 1, characterized in that, The extracted qualification document information associated with the electronic ticket draft is verified through interface verification and AI-based hidden defect identification, and the qualification verification results are output, including: Extract the responsible personnel identifier and work type code from the electronic ticket draft, and query the corresponding set of qualification documents from the pre-set qualification database based on the responsible personnel identifier; The qualification numbers in the qualification document set are compared online with the pre-set official qualification database through a pre-set qualification verification interface to obtain the interface verification result. At the same time, the qualification document set is input into a pre-trained deep learning defect recognition model. The deep learning defect recognition model includes a convolutional neural network layer, a long short-term memory network layer and a fully connected classification layer in sequence. The convolutional neural network layer is used to extract image features of the qualification documents, the long short-term memory network layer is used to capture the contextual dependencies of the text sequence of the qualification documents, and the fully connected classification layer is used to output the latent defect recognition result. By combining the interface verification result and the hidden defect identification result, if the interface verification result indicates that it is valid and the hidden defect identification result indicates that there is no defect, then the qualification verification is deemed to have passed.
4. The intelligent verification method for electronic tickets as described in claim 1, characterized in that, The method of collecting continuous time-series signal data of on-site operating conditions through on-site IoT sensing devices for real-time verification and anomaly prediction includes: Once the qualification verification is passed, the set of IoT sensor devices deployed at the work site will be triggered. The IoT sensor set is controlled to collect continuous time-series signal data of ambient temperature, harmful gas concentration, and equipment vibration at a fixed sampling frequency; The continuous time-series signal data is input into a pre-trained anomaly prediction model. The anomaly prediction model adopts a structure that combines a one-dimensional convolutional neural network with a self-attention mechanism. The one-dimensional convolutional neural network is used to extract the local temporal features of the continuous time-series signal data, and the self-attention mechanism is used to capture the global dependencies between different sensor signals and output real-time verification results and anomaly prediction indicators.
5. The intelligent verification method for electronic tickets as described in claim 1, characterized in that, The process of generating compliance risk levels based on alignment feature sets, and marking the corresponding electronic ticket draft as an abnormal ticket and notifying the reviewer if it exceeds a preset risk level threshold, includes: The alignment feature set is input into the risk level classifier; the risk level classifier is a multilayer perceptron containing multiple fully connected layers and a Softmax output layer, used to calculate and output the compliance risk level corresponding to the electronic ticket draft; The compliance risk level is compared with a preset risk level threshold. If the compliance risk level is greater than the risk level threshold, an anomaly marking instruction is generated, the electronic ticket draft is marked as an abnormal ticket in the electronic ticket database, a notification message containing the hierarchical ticket code and the reason for the anomaly is generated, and sent to the predefined review terminal through the message push interface.
6. The intelligent verification method for electronic tickets as described in claim 5, characterized in that, The process of tracing the root causes of abnormal tickets and generating rectification plans includes: Based on the hierarchical ticket coding of the abnormal tickets, retrieve the historical operation records and historical continuous time-series signal data associated with the abnormal tickets from the operation log database and the signal history database; The association rule mining algorithm was used to analyze the retrieved historical operation records and historical continuous time series signal data to identify the combination of operation factors and signal patterns that caused the compliance risk level to exceed the standard, and determined them as the root cause factors. Based on the root causes, matching rectification measures are retrieved from a pre-set rectification measures knowledge graph, and a rectification plan for the abnormal tickets is generated by combining them.
7. The intelligent verification method for electronic tickets as described in claim 6, characterized in that, After review, the abnormal tickets are registered as pending tickets, a processing path plan is generated, and the processing path plan is assigned to dynamically specified processing nodes, including: Upon receiving the review confirmation instruction from the review terminal, the status of the abnormal ticket is updated to pending ticket and stored in the pending ticket queue. Based on the operation type code, root cause factors, and status of all available disposal nodes of the tickets to be disposed of, the shortest path algorithm is used to calculate the optimal disposal path in the predefined disposal flowchart, and a disposal path scheme containing the sequence of disposal steps, expected time consumption, and resource requirements is generated. Based on the resource requirements of each disposal step in the disposal path scheme, a qualified disposal node is dynamically selected from the disposal node resource pool, and each disposal step is assigned to the corresponding disposal node.
8. The intelligent verification method for electronic tickets as described in claim 1, characterized in that, The process of making the verified electronic tickets effective and archived, and uploading them to the blockchain for evidence storage, includes: For draft electronic tickets that are not marked as abnormal and whose compliance risk level does not exceed the preset risk level threshold, add an electronic signature and timestamp, and change their status to effective electronic tickets. The entire process information of the effective electronic ticket is packaged into an archive data package and stored in the electronic ticket archive database; the entire process information includes hierarchical ticket code, target entity information, qualification verification results, continuous time series signal data, alignment feature set and compliance risk level; The archived data packets are used to generate a Merkle tree, its root hash value is calculated, and the root hash value is submitted to the blockchain network along with the hierarchical ticket code to complete the evidence storage transaction.
9. An intelligent verification system for electronic tickets, used to implement the intelligent verification method for electronic tickets according to any one of claims 1-8, characterized in that, include: The ticket draft generation module is used to receive target entity information and generate electronic ticket drafts with hierarchical ticket codes. The verification module is used to extract the qualification document information associated with the electronic ticket draft, and after interface verification and AI hidden defect identification, it outputs the qualification verification result. If the qualification verification is passed, it collects continuous time-series signal data of on-site working conditions through on-site IoT sensor devices for real-time verification and anomaly prediction. The feature fusion processing module is used to perform feature transformation and non-Euclidean space fusion of hierarchical ticket codes and continuous time-series signal data collected on site, and output an aligned feature set. The risk level determination module is used to calculate the compliance risk level and mark abnormal tickets based on the alignment feature set, generate notification information containing hierarchical ticket codes and abnormal reasons, and send it to the review terminal through the message push interface; The abnormal ticket handling module is used to locate the root cause of risk exceeding the standard by using association rule mining algorithm based on the hierarchical ticket code of abnormal tickets, and generate rectification plan. After receiving the review and confirmation instruction, the abnormal ticket is registered as a ticket to be handled. Combining the operation type, root cause and handling node status, the module generates and allocates handling path plan. The dynamic optimization module is used to make dynamic adjustments based on the actual disposal results of the disposal nodes.
Citation Information
Patent Citations
Invoice risk control management method and system based on multi-source data linkage
CN121120289A
Method, system, and device for online ticket checking based on a client interface
US20190318280A1