A work order processing method, device, system and storage medium

Abstract

This application discloses a work order processing method, apparatus, system, and storage medium, belonging to the field of information technology service technology. It includes: responding to a fault handling request sent by any terminal; generating a fault report work order based on voice data, image data, and structured fields in the fault handling request; the fault report work order includes a work order type, a group organization tree node associated with the fault handling request, a terminal device identifier, and fault description information; matching the fault handling request to the fault handling group and dispatching the work order based on the work order type and the group organization tree node; generating a work order identifier for the fault report work order based on the terminal device identifier, fault description information, and a preset time identifier, and performing deduplication based on the work order identifier; when the link between the edge node and the enterprise management system is interrupted, encapsulating the fault report work order into a buffer event and storing it; when the link is restored, reading the buffer event, and resubmitting the fault report work order after deduplication based on the work order identifier.

Description

Technical Field

[0001] This application belongs to the field of information technology service technology, specifically relating to a work order processing method, apparatus, system and storage medium. Background Technology

[0002] In enterprise information technology (IT) services and cloud service operations and maintenance scenarios, service tickets are typically used to handle fault reporting, configuration consultation, project delivery, and after-sales support. With the deepening of digital transformation in large enterprises, the number of IT devices and industrial terminals in branch offices has surged, leading to increasingly complex maintenance and fault reporting needs. Traditional maintenance and fault reporting solutions typically employ a centralized cloud architecture, meaning that fault processing equipment is uniformly deployed in the group's headquarters' cloud data center. Users or on-site maintenance personnel need to directly access the cloud portal via the internet or dedicated line to submit fault information.

[0003] However, traditional operation and maintenance fault reporting solutions often encounter weak networks and link interruptions in the on-site inspection area, which can cause terminal lag and lead to duplicate work orders. Summary of the Invention

[0004] The purpose of this application is to provide a work order processing method, apparatus, system, and storage medium that can solve the problem of duplicate work order submissions in scenarios with weak networks or link interruptions.

[0005] The technical solution adopted by this application to solve its technical problem is: In a first aspect, embodiments of this application provide a work order processing method applied to an edge node, wherein the edge node is connected to an enterprise management system and multiple terminals respectively, and the method includes: In response to a fault handling request sent by any of the terminals, a fault reporting work order is generated based on the voice data, image data, and structured fields in the fault handling request; the fault reporting work order includes the work order type, the group organization tree node associated with the fault handling request, the terminal device identifier, and fault description information; Based on the work order type and the group organization tree node, match the fault handling group of the fault handling request and dispatch the work order; Based on the terminal device identifier, the fault description information, and the preset time identifier, a work order identifier is generated for the fault reporting work order, and duplicates are checked based on the work order identifier; If the link between the edge node and the enterprise management system is interrupted, the fault report work order is encapsulated as a buffer event and stored. If the link status is restored, read the buffer event, and resubmit the fault report work order after checking for duplicates based on the work order identifier.

[0006] Secondly, a work order processing device is applied to an edge node, the edge node being connected to an enterprise management system and multiple terminals respectively, the device comprising: The work order generation module is used to respond to a fault handling request sent by any of the terminals and generate a fault reporting work order based on the voice data, image data and structured fields in the fault handling request; the fault reporting work order includes work order type, group organization tree node associated with the fault handling request, terminal device identifier and fault description information; The work order dispatch module is used to match the fault handling group of the fault handling request and dispatch the work order according to the work order type and the group organization tree node. The work order deduplication module is used to generate a work order identifier for the fault reporting work order based on the terminal device identifier, the fault description information, and a preset time identifier, and to perform deduplication based on the work order identifier; The offline processing module is used to encapsulate the fault report work order into a buffer event and store it when the link between the edge node and the enterprise management system is interrupted. The recovery and retransmission module, when the link status is restored, reads the buffer event, checks for duplicates based on the work order identifier, and resubmits the fault report work order.

[0007] Thirdly, embodiments of this application provide a work order processing system, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the steps of the work order processing method as described in the first aspect.

[0008] This application provides a readable storage medium storing a program or instructions that, when executed by a processor, implement the steps of the work order processing method as described in the first aspect.

[0009] The beneficial effects of this application are: In this embodiment, firstly, fault handling groups are matched according to the work order type and the group's organizational tree node, fully considering the organizational characteristics of large group enterprises with multiple regions, multiple levels, and multiple business lines. This effectively reduces problems such as cross-regional misassignment and unauthorized assignment, improving the accuracy of assignment. Secondly, a work order identifier is generated by combining the terminal device identifier, fault description information, and time identifier, and deduplication is checked before the order is created. This can identify repeated reporting of the same fault and reduce the probability of duplicate assignment. Thirdly, when the link between the edge node and the enterprise management system is interrupted, the fault reporting work order is encapsulated as a buffer event and stored. Compared with traditional technologies that directly discard or only store in terminal memory, this can ensure the security of fault reporting data. Finally, when the link is restored, the buffer event is read and the work order identifier is called again for deduplication, solving the problem of duplicate work order submission in scenarios with weak networks and link interruptions. Attached Figure Description

[0010] Figure 1 This is a flowchart of a work order processing method provided in an embodiment of this application.

[0011] Figure 2 This is a flowchart illustrating the specific steps of a work order processing method provided in an embodiment of this application.

[0012] Figure 3 This is a flowchart of another work order processing method provided in the embodiments of this application.

[0013] Figure 4 This is a block diagram of a work order processing method apparatus provided in an embodiment of this application.

[0014] Figure 5 This is a block diagram of a work order processing system provided in an embodiment of this application. Detailed Implementation

[0015] The present application will be further described below with reference to the accompanying drawings and embodiments.

[0016] The following will clearly and completely describe the concept, specific structure, and resulting technical effects of this application in conjunction with embodiments and accompanying drawings, so as to fully understand the purpose, features, and effects of this application. Obviously, the described embodiments are only a part of the embodiments of this application, not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are all within the scope of protection of this application. Furthermore, all connections / linkages involved in the patent do not simply refer to direct contact between components, but rather to the ability to form a better connection structure by adding or reducing connecting accessories according to specific implementation conditions. The various technical features in this application can be combined interactively without contradicting each other.

[0017] Traditional group-level maintenance and fault reporting systems generally adopt a centralized cloud portal deployment architecture, with all fault reporting, work order parsing, and status synchronization logic deployed on the group's cloud service. However, existing work order processing solutions have the following drawbacks: 1. On-site inspection PDAs, mobile terminals, and Internet of Things (IoT) devices are mostly deployed in areas with weak network coverage, such as factory areas, outdoors, and underground data centers. When the uplink jitters or is interrupted, the fault text, on-site photos, and voice recordings submitted by the terminals cannot be uploaded to the cloud in time, and the submission request fails directly. On-site personnel cannot record faults offline, check work order progress, or perform status operations such as accepting / completing orders. They must wait for the network to be restored and re-enter the data, which greatly reduces the efficiency of on-site operation and maintenance.

[0018] 2. All fault reports and multimedia attachments from subsidiaries and regional sites need to be uploaded to the group's cloud across the wide area network. During peak periods, cloud message queues are congested and cross-regional network latency is superimposed. Work order routing and status synchronization are delayed by seconds or even minutes, which cannot meet the requirements for rapid dispatch of high-priority faults and compliance control of Service Level Agreement (SLA).

[0019] 3. The protocols and message fields of inspection terminals and IoT alarm devices in different factories and subsidiaries are not uniform. The cloud portal needs to continuously iterate and add new adaptation parsing logic, and the cloud code changes frequently. At the same time, a large number of concurrent requests from terminals flood the cloud, causing concentrated pressure on the gateway, which can easily lead to gateway rate limiting and interface timeouts.

[0020] 4. The cloud portal and the local Enterprise Resource Planning (ERP) and Information Technology Service Management (ITSM) business systems of each subsidiary are connected across networks. Once the link between the group and the subsidiary business systems is interrupted, the on-site fault reporting work orders cannot be synchronized to the local business systems. The status of internal and external work orders is disconnected for a long time, the workload of manual reconciliation is large, and data errors such as missing work orders, duplicate work orders, and inverted status are likely to occur, and the audit traceability chain will be broken.

[0021] To address the aforementioned problems, this application provides a work order processing method, apparatus, system, and storage medium. The work order processing method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0022] Figure 1 This is a flowchart of a work order processing method provided in an embodiment of this application. It is applied to an edge node, which is connected to an enterprise management system and multiple terminals. The method includes the following steps.

[0023] Step 101: In response to a fault handling request sent by any terminal, generate a fault reporting work order based on the voice data, image data and structured fields in the fault handling request.

[0024] In this embodiment, the fault reporting work order includes the work order type, the group organization tree node associated with the fault handling request, the terminal device identifier, and the fault description information.

[0025] In some embodiments, step 101 may include: the edge node receiving a terminal request, voice data, image data, and structured fields through a unified fault reporting interface gateway.

[0026] In some embodiments, the semantic adapter within the edge node receives fault handling requests and maps the field formats specific to different terminals to a unified work order semantic model for the group.

[0027] For example, voice data includes audio streams of "abnormal equipment noises" recorded on-site, and image data includes photos of the equipment dashboard and screenshots of the faulty parts.

[0028] In this embodiment, structured fields are used to represent form information entered by the user on the terminal. For example, structured fields include the device identifier (Asset ID), geographical location, and fault-reporting information from the fault log table.

[0029] For example, structured fields could be fault log forms filled out on the terminal, including: device identifier (Asset ID) obtained via QR code scanning or NFC, GPS latitude and longitude coordinates, the organization to which the person reporting the fault belongs, and contact information. The "latitude / longitude" reported by the mobile phone is mapped to a unified "geographic coordinates" field, the "XXXXX" obtained by PDA scanning is mapped to a unified "asset number" field, and the user-selected "emergency" is mapped to a unified "urgency level" field.

[0030] In some embodiments, step 101 may further include: in response to a fault handling request, performing speech recognition on the voice data to obtain text fault information, and performing feature extraction on the image data to obtain image fault feature information; performing fusion analysis on the text fault information, image fault feature information, and structured fields to obtain fused fault reporting information; performing semantic matching between the fused fault reporting information and a plurality of preset candidate fields to obtain the matching confidence of each candidate field; and generating a fault reporting work order based on the candidate fields whose matching confidence is greater than or equal to a preset range.

[0031] In this embodiment of the application, the fault reporting work order can be a request data packet initiated by the edge node to the group's backend ERP / ITSM system to create a new work order.

[0032] Step 102: Match the fault handling group of the fault handling request with the work order type and the group organization tree node, and dispatch the work order.

[0033] In this embodiment, the edge nodes pre-enter a group organizational tree node set and a mapping diagram. The mapping diagram stores the binding relationships between each organizational node, fault work order type, work order pool, and maintenance processing group. The hierarchical structure of the group organizational tree node set, from top to bottom, includes: group headquarters, regional offices, subsidiaries, and workshop departments. For example, the mapping diagram might be: East China subsidiary - equipment leakage fault - leakage repair work order pool - leakage processing group one / two.

[0034] In some embodiments, work order types include core business interruption, safety production accident, infrastructure failure, general equipment failure, consultation and assistance, etc.

[0035] In some embodiments, step 102 may include: selecting at least one candidate processing group associated with the work order type from multiple processing groups according to a preset correspondence between work order types and processing groups; selecting the processing group closest to the candidate processing group as the fault processing group according to the group organization tree node; and sending the work order associated with the fault reporting work order to the fault processing group.

[0036] In some embodiments, step 102 may further include: selecting the processing group associated with the nearest ancestor node as the fault processing group according to the work order type and the group organization tree node; dispatching work orders according to the work order type, the load of the fault processing group, and the remaining time of the service level agreement; wherein, the group organization tree node includes any one of the group, region, subsidiary, and department levels, the ancestor node is all the parent nodes on the path from the group organization tree node to the root node, and the processing group is a preset virtual queue with corresponding fault processing capabilities.

[0037] Step 103: Generate a work order identifier for the fault reporting work order based on the terminal device identifier, fault description information, and preset time identifier, and perform duplicate checks based on the work order identifier.

[0038] In some embodiments, the fault description information includes an asset number and gridded geographic location information. The asset number can be a unique identifier for the physical device or facility that has malfunctioned, and the gridded geographic location information can refer to the conversion of precise GPS latitude and longitude coordinates into a grid code within a certain accuracy range. For example, the gridded geographic location information is "Building X, XX Science and Technology Park, XX City" obtained by converting the specific coordinates "XXX North Latitude, XXX East Longitude".

[0039] In some embodiments, the work order identifier can be an idempotency key generated by the edge node based on the content fingerprint, the terminal device identifier, and a preset time identifier.

[0040] For example, the time identifier can be a time bucket number. Assuming the time window (Tw) is 10 minutes, extract the timestamp (Unix) of the fault reporting time, divide the timestamp by Tw and round down to obtain the time bucket number to which the current request belongs. Concatenate the terminal device identifier, time bucket number, and the first 16 bits of the content fingerprint into segments to form a global idempotent key.

[0041] It's understandable that if the same terminal repeatedly submits fault reports for the same device and the same fault scenario within the same 10-minute time window, it will generate completely identical idempotent keys. Therefore, deduplication can be performed based on the idempotent keys within a time window. Correspondingly, if any of the terminal device identifier, fault description information, or time window changes, the idempotent key will change accordingly.

[0042] Step 104: If the link between the edge node and the enterprise management system is interrupted, encapsulate the fault report work order into a buffer event and store it.

[0043] In this embodiment, the offline processing mode encapsulates fault reports as buffer events and stores them in a local queue. This ensures that offline work order data is not lost in the event of server power failure, crash, or process failure.

[0044] In some embodiments, when the number of fault reports is single, step 104 may include: when the link between the edge node and the enterprise management system is interrupted, encapsulating the fault report as a buffer event and writing it to a local persistent queue.

[0045] In some embodiments, when there are multiple fault reports, step 104 may include: when the link between the edge node and the enterprise management system is interrupted, assigning an integer identifier to each buffer event according to its timing; and sequentially writing multiple buffer events into a local persistent queue in ascending order of their storage sequence numbers. For example, the local persistent queue may be an SQLite database, and the storage sequence number may be... .

[0046] In some embodiments, when the link between the edge node and the enterprise management system is interrupted, the buffer event object is converted into a compact JSON string, written to the buffer.wal file, and the fsync system call is executed after writing to force a disk flush.

[0047] In some embodiments, the above-mentioned work order processing method may further include: encapsulating the work order status change event associated with the fault reporting work order into a buffer event associated with the fault reporting work order; storing the work order status change events in a local queue according to the reporting time sequence; wherein, different types of work order status change events are distinguished by the event type field to determine the association relationship belonging to the same work order, and all status change events under the same work order are bound to the work order identifier of the corresponding fault reporting work order.

[0048] In some embodiments, a heartbeat detection request is sent to the enterprise management system according to a preset heartbeat cycle, and the number of consecutive detection failures and the number of consecutive detection successes are recorded; if the number of consecutive detection failures reaches a preset first threshold, the link status is determined to be interrupted.

[0049] Step 105: If the link status is restored, read the buffer event, check for duplicates based on the work order identifier, and resubmit the fault report work order.

[0050] In this embodiment, the buffered events have a storage sequence number. The storage sequence number of a buffered event is an integer identifier assigned by the edge node to each buffered event written to the local persistent queue when the link state is interrupted.

[0051] In some embodiments, the fault report data corresponding to the buffer event is read sequentially according to the buffer event storage sequence number from smallest to largest.

[0052] It is understandable that when the network is interrupted, it means that the link between the edge node and the enterprise management system is interrupted. The fault report work order is first stored in the local buffer queue, and after the link is restored, the fault report work orders are resubmitted to the enterprise management system in batches.

[0053] In some embodiments, if the link status is interrupted and the number of consecutive successful probes reaches a preset second threshold, the link status is determined to be restored.

[0054] In summary, in this embodiment, firstly, by matching fault handling groups according to work order type and group organizational tree nodes, the organizational characteristics of large group enterprises—multi-regional, multi-level, and multi-business line—are fully considered, effectively reducing cross-regional misassignment and unauthorized assignment, thus improving the accuracy of assignment. Secondly, by jointly generating work order identifiers using terminal device identifiers, fault description information, and time identifiers, and performing deduplication checks before creation, duplicate reporting of the same fault can be identified, reducing the probability of duplicate assignments. Thirdly, when the link between the edge node and the enterprise management system is interrupted, the fault reporting work order is encapsulated as a buffer event and stored, which, compared to traditional technologies that directly discard or store only in terminal memory, ensures the security of the fault reporting data. Finally, when the link is restored, the buffer event is read and the work order identifier is called again for deduplication, solving the problem of duplicate work order submissions in scenarios with weak networks or link interruptions.

[0055] Figure 2 This is a flowchart illustrating the specific steps of a work order processing method provided in an embodiment of this application. The method includes the following steps.

[0056] Step 201: In response to the fault handling request, perform speech recognition on the speech data to obtain text fault information, and perform feature extraction on the image data to obtain image fault feature information.

[0057] In some embodiments, the image fault feature information includes image fault labels. Step 201 may include: for voice data, performing speech recognition (ASR) transcription, removing invalid interjections and silent segments to obtain text fault information; for image data, performing feature extraction, optical character recognition (OCR) text recognition and fault label matching to identify various fault features such as equipment damage, leakage, and abnormal noise, and generating image fault labels.

[0058] In some embodiments, the fault handling request includes: a fault record table, a voice attachment, and an image attachment; performing voice recognition on the voice attachment to obtain text fault information; performing feature extraction on the image data to obtain image fault feature information; and performing feature processing on the fault record table to obtain structured fields.

[0059] For example, various types of terminals, such as smartphones, industrial PDAs, or IoT sensor gateways, can fill out a fault record form and upload voice and image attachments through a unified fault reporting interface. The edge node receives the submitted fault record form, voice attachments, and image attachments. The fault record form requires the following fields: work order type, group organizational tree node, geographical coordinates, terminal device identifier, and asset number; the voice attachment can be a recorded abnormal sound, and the image attachment can be a photo of the device indicator light.

[0060] Step 202: Perform fusion analysis on text fault information, image fault feature information and structured fields to obtain fused fault reporting information.

[0061] In some embodiments, step 202 may include: the edge node calling the multimedia fusion module to parse the text fault information and image fault feature information, mapping the text fault information, image fault feature information and structured fields to a unified work order semantic model, and generating fused fault reporting information.

[0062] In some embodiments, the semantic adapter within the edge node receives fault handling requests and maps the field formats specific to different terminals to a unified work order semantic model for the group. For example, the "latitude / longitude" reported by the mobile terminal is mapped to a unified "geographic coordinates" field, the "XXXX" obtained by scanning the code on the PDA is mapped to a unified "asset number" field, and the "urgent" selected by the user is mapped to a unified "urgency level" field.

[0063] Step 203: Perform semantic matching between the fused fault reporting information and multiple preset candidate fields to obtain the matching confidence of each candidate field.

[0064] In this embodiment, a fault type dictionary is pre-set within the edge node, wherein the fault type dictionary includes dictionary description text corresponding to multiple candidate fields.

[0065] In some embodiments, step 203 may include: calculating the matching confidence of each candidate work order field according to the joint matching utility function of the preset fault type dictionary and field template.

[0066] For example, for a fault handling request j, let the speech-to-text be... The image parsing label set is The terminal structured fields are For each candidate field Corresponding dictionary description text A joint matching utility function for fault type dictionary and field template. As shown below.

[0067] .

[0068] in, , , These represent the matching weights for voice text, image tags, and terminal structured fields, respectively. , , The sum equals 1; This is a pre-trained semantic similarity calculation function, with a value range of 0 to 1. The higher the value, the higher the semantic matching degree between the speech-to-text and the dictionary description text. This means that after calculating the matching degree between each image fault label and the dictionary description text, the maximum value of the matching degree between each image fault label and the dictionary is taken; This is an indicator function. If the terminal structured field contains valid data for the candidate field, it takes the value 1; otherwise, it takes the value 0.

[0069] Step 204: Generate a fault report work order based on candidate fields whose matching confidence is greater than or equal to a preset range.

[0070] For example, the preset range is a preset threshold of 0.55 to 0.75.

[0071] In some embodiments, candidate work order fields with a confidence level greater than or equal to a preset range are selected as candidate fields; a fault reporting work order is generated based on all candidate fields, and a candidate field vector is output. The fault reporting work order carries information such as work order type, group organization tree node, terminal device identifier, and standardized fault description, which is used to send it to the permission routing engine to complete the subsequent work order allocation process.

[0072] For example, the speech-to-text transcription is The image parsing label set is The terminal structured fields are The fusion module outputs a vector of candidate fields. As shown below.

[0073] .

[0074] in, The standardized fields with the best matching effect among the candidate fields constitute the basic field set for work order generation; U is a joint matching utility function based on a preset fault type dictionary and field templates.

[0075] For example, preset range It means that, in Greater than or equal to In this case, the matching result of the candidate field is deemed reliable, and it is written into the candidate field vector. .

[0076] In some embodiments, after step 203, the above-mentioned work order processing method may further include: marking fields with utility values ​​lower than a preset range as pending manual confirmation and outputting them.

[0077] For example, in Less than In such cases, if the matching credibility of the candidate field is deemed insufficient, it is marked as requiring manual confirmation and saved to the work order interface for maintenance personnel to manually check, modify, and supplement.

[0078] In this way, the system uses a weighted fusion scoring of three types of information: voice, image, and terminal form. It comprehensively assesses the credibility of fields based on multi-dimensional fault information, ensuring that the identification deviation of information from a single channel will not directly lead to errors in work order fields. At the same time, it distinguishes between automatically filled fields and manually reviewed fields by using configurable confidence thresholds. This ensures the efficiency of automated work order generation while reducing the problem of incorrect work orders caused by multimedia identification errors, and is suitable for scenarios such as weak network conditions, network outages, and offline fault reporting in the factory area.

[0079] Step 205: Based on the work order type and the group organization tree node, select the processing group associated with the nearest ancestor node as the fault handling group.

[0080] Among them, the group organization tree node includes any one of the group, region, subsidiary and department levels, the ancestor node is all the superior nodes on the path from the group organization tree node to the root node, and the processing group is a preset virtual queue with corresponding fault handling capabilities.

[0081] In this embodiment, a complete group organizational tree is pre-entered, which includes four levels: group headquarters, regional offices, subsidiaries, and front-line workshop departments. All level nodes constitute the group organizational tree node set. At the same time, multiple virtual processing groups are pre-configured, each corresponding to a fault handling professional capability, such as circuit fault handling group, equipment leakage handling group, and mechanical noise handling group.

[0082] In this embodiment, a mapping table is pre-stored to record the binding associations between each organization node, work order type, and virtual processing group.

[0083] In some embodiments, step 205 may include: using a routing function to retrieve all ancestral nodes on the path from the group organization tree node to the root node of the organization tree, determining whether each ancestral node is configured with a processing group that matches the current work order type, until the processing group of the nearest ancestor node is selected as the fault processing group.

[0084] In one possible implementation, the search order proceeds from nearest to farthest, prioritizing the verification of the node in the department where the person reporting the fault is located; if the department node does not have a processing group corresponding to the fault type, the search continues upwards to the node of its subsidiary; if the subsidiary does not have a matching processing group, the search continues to the node in its region; until the first ancestor node bound to the processing group of the work order type is found, the virtual processing group associated with that node is determined as the candidate fault processing group for this work order.

[0085] For example, let the set of group organization tree nodes be O, and the group organization tree nodes be... The work order type is τ. The routing function Route is shown below.

[0086] .

[0087] Where G is a configurable mapping graph of "organization node - work order pool - processing group"; π is a routing function used to select the queue that matches τ on the nearest ancestor node.

[0088] For example, if the person reporting the fault belongs to Workshop A node, and there is no corresponding leakage repair team in the workshop, then the search will go up to the subsidiary node. If the subsidiary has a leakage work order pool, then all processing groups in the subsidiary's leakage pool will be selected as candidates.

[0089] Step 206: Dispatch the work order based on the work order type, the load of the fault handling group, and the remaining time of the service level agreement.

[0090] In this embodiment, the load of the fault handling group represents the number of pending work orders currently backlogged in the fault handling group, and the remaining time of the service level agreement (SLA) of the fault handling group is the average remaining fulfillment time of the service level agreement for the work orders in the fault handling group.

[0091] In some embodiments, step 206 may include: determining the urgency of a work order based on its type; calculating a score by weighting the urgency of the work order, the load of the fault handling group, and the remaining time of the service level agreement; and dispatching work orders in descending order of their scores.

[0092] For example, suppose the urgency of the work order is... The load of the fault handling group is For work order G, calculate the score. As shown below.

[0093] .

[0094] Among them, work order urgency Faults can be rated on a scale of 1 to 5, with 5 being the highest priority. , , These are the urgency levels of the work orders. Load of the fault handling group Weighted by the remaining SLA time , , The sum of them equals 1. For example, =0.5, =0.3, =0.2.

[0095] In some embodiments, among all candidate processing groups capable of processing this type of work order, the processing group with the highest score is selected as the fault processing group, and the fault work order is assigned to this fault processing group. For example, the work order is preferentially assigned to g*=argmax Score(g).

[0096] In some embodiments, fault reporting work orders are routed to the work order pool message queue of the fault handling group, without immediately invoking the enterprise management system to create the work order. The consumer, bound to the organization's scope, retrieves the message from the queue and then invokes the enterprise management system to complete the work order creation. The consumer holds an organization scope lock, allowing it to pull only messages matching its authorized organization tree node, and prohibiting access to pending work order messages at other organization levels, thereby avoiding misallocation of work orders across organizations and permissions.

[0097] In this way, the group organization tree enables the nearest routing, reducing the delay caused by cross-regional dispatch and cross-group transfer of work orders and improving the efficiency of work order processing. By combining urgency, remaining time of service level agreement, and multi-dimensional load scoring to dynamically balance work orders, it is possible to prevent work orders from piling up in a certain fault handling group and thus affecting the efficiency of work order processing.

[0098] Step 207: The terminal device identifier, asset number, and gridded geographic location information are concatenated and hashed to obtain the content fingerprint.

[0099] In this embodiment, the content fingerprint is a normalized summary of the fault handling request, used to determine whether the fault handling request is a duplicate report of the same fault. The content fingerprint is obtained by filtering volatile fields in the fault handling request and extracting normalized fields that characterize the essence of the fault service.

[0100] In this embodiment of the application, the terminal device identifier is used to distinguish the source of the fault report. For example, the terminal device identifier can be the physical address (Media Access Control Address, MAC) of the PDA or a universally unique identifier (UUID).

[0101] In this embodiment of the application, the asset ID is a unique identifier for the faulty device. For example, the asset ID can be a product serial number (SN) or an asset code parsed from a QR code.

[0102] In this embodiment, the gridded geographic location information is obtained by multiplying the original latitude and longitude coordinates by a preset factor and rounding down to eliminate minor fluctuations in geographic location. For example, the gridded geographic location is obtained by multiplying the latitude and longitude by 10 to the power of 5 and then rounding down.

[0103] In some embodiments, step 207 may include: the edge node concatenating the terminal device identifier, asset number, and gridded geographic location information into a string, performing a hash calculation on the concatenated complete string, and generating a content fingerprint that uniquely represents the faulty object and the reporting location. This content fingerprint is strongly correlated only with the device, location, and reporting terminal, and can stably identify the physical faulty object.

[0104] For example, the SHA256 algorithm is used to perform a hash operation on the original feature string, and the hexadecimal format hash string is output as the content fingerprint FP of this fault report. In other words, the first 16 characters of the content fingerprint are extracted for subsequent idempotent key concatenation.

[0105] In some embodiments, before step 207, the above-mentioned work order processing method may further include: deleting all whitespace characters and punctuation marks from the text fault information; converting the remaining characters to lowercase; and outputting a normalized string in UTF-8 encoding format. If no images or audio attachments are uploaded in this fault report, the multimedia summary is assigned an empty string; if an image file is uploaded, a SHA256 hash operation is performed on the original image byte stream to obtain an image summary; if an audio file is uploaded, the audio byte stream can be hashed, or the above-mentioned text normalization hash can be performed on the speech-transcribed text to serve as the audio attachment summary.

[0106] In some embodiments, the content fingerprint also includes an attachment fingerprint, wherein the attachment fingerprint is a fixed empty string when there is no attachment; a thumbnail or the original image SHA-256 when there is an image; and an audio file SHA-256 or a hash of the transcribed text when there is audio. An exemplary content fingerprint FP is shown below.

[0107] .

[0108] in, This represents the unique identifier of the terminal device. Indicates the asset / equipment number. Indicates the fault type code. This represents a normalized description of the text. Represents gridded geographic location information. This indicates the fingerprint in the attachment.

[0109] Step 208: Combine the content fingerprint, terminal device identifier, and time identifier to generate a work order identifier.

[0110] In some embodiments, the time identifier is a time bucket number identifier within a preset time window, used to distinguish normal repeated fault reports from the same device at the same location in different time periods, and to avoid mistakenly intercepting reasonable secondary repair reports.

[0111] In some embodiments, step 208 may include: the edge node extracting the bucket ID of the current time; and combining the generated content fingerprint, the current terminal device identifier, and the bucket ID to generate a globally unique request identifier corresponding to this fault handling request.

[0112] In some embodiments, the work order identifier can be an idempotency key generated by the edge node based on the content fingerprint, the terminal device identifier, and a preset time identifier.

[0113] For example, the time window Tw is 10 minutes. The Unix timestamp of the fault reporting time is extracted, divided by Tw, and rounded down to obtain the bucket to which the current request belongs. The terminal device identifier, bucket number, and the first 16 bits of the content fingerprint are concatenated to form a global idempotent key. If the same terminal repeatedly submits fault reports for the same device and the same fault scenario within the same 10-minute time window, a completely identical idempotent key will be generated; if any of the fault content, reporting device, or reporting time period changes, the idempotent key will change accordingly.

[0114] Step 209: Use the work order identifier to query the preset identifier index table to determine whether the fault handling request is a duplicate fault report.

[0115] In some embodiments, the edge node locally maintains a persistent identifier index table, which stores the request identifier and acceptance status corresponding to all historically accepted fault handling requests. In each fault reporting, offline cache writing, and link recovery retransmission scenario, the currently generated request identifier is used to retrieve the identifier index table.

[0116] In some embodiments, step 209 may include: if the same request identifier exists in the identifier index table and has been marked as successfully accepted or synchronized with the backend, then the current fault handling request is determined to be a duplicate fault report, and the system directly discards the duplicate request and does not create a duplicate order; if there is no matching record in the index table, then it is determined to be a brand new fault handling request, and the subsequent work order generation and synchronization process is allowed.

[0117] For example, the work order identifier is used to query the preset identifier index table to determine whether the fault handling request is a duplicate fault report, as shown below.

[0118] 1. Scenario of repeated submissions on the terminal: Maintenance personnel click the fault report submission button consecutively within a short period. The standardized results of all fields in the two requests are completely identical, with the same content fingerprint (FP), time bucket, and idempotent key match. The edge node retrieves the index table to identify duplicate requests, and instead of creating a new work order or writing it to the buffer queue, directly returns the locally generated temporary work order number.

[0119] 2. PDA and IoT device co-reporting scenario: When the same asset device simultaneously receives an IoT automatic temperature alarm and a field PDA photo fault report, and the fault type, grid location, and normalized fault text of the two are highly similar, the system can enable an asset-level merging strategy. During the multimodal fusion phase, the two reports will be grouped into the same fault reporting session. When calculating the content fingerprint, the terminal identifier will be replaced with the asset number to generate a unified content fingerprint, which will then be merged into a single work order.

[0120] 3. Offline caching and retransmission scenarios after network interruption: When the network is interrupted, work order events are stored in a local buffer queue. After the link is restored, the buffered events are resubmitted in batches. If the terminal repeatedly initiates a report due to network timeout, the idempotent keys of the two are consistent. The retransmission scheduler first queries the local index table. If the idempotent key has received synchronous confirmation ACK from the backend management system, the upload of this event is skipped. The terminal directly returns the official work order number to the backend for newly submitted duplicate requests, and duplicate work orders will not be generated.

[0121] 4. Different fault scenarios for the same equipment at different times: The same terminal and the same asset reported equipment noise and equipment leakage faults at 20-minute intervals. The normalized text and fault type codes of the two requests were significantly different, the content fingerprints (FP) were different, and the reporting interval exceeded the 10-minute time window. The time buckets were also different, and the idempotent keys were independent of each other. The system normally created two independent work orders to distinguish between the two faults.

[0122] 5. Independent Idempotent Verification of Work Order Status Changes: For work order status operations such as order acceptance, completion, and cancellation, the fault report fingerprint (FP) is not reused. A unique idempotent key is generated based on the unique work order number, target status change, operator account, and minute-level time bucket hash. A separate table lookup is used to intercept duplicate status changes, preventing status errors such as duplicate completions or order acceptances during the retransmission phase.

[0123] In this way, a stable and unique identifier is generated based on multiple dimensions such as device, asset, location, and time window, which can accurately identify duplicate reporting behavior, effectively avoid duplicate work orders caused by weak network retries, multiple repeated clicks, and resubmission, and improve the consistency between edge offline fault reporting and backend work order data.

[0124] Step 210: If the link between the edge node and the enterprise management system is interrupted, encapsulate the fault report work order into a buffer event and store it.

[0125] In this embodiment of the application, step 210 can refer to step 104, and will not be repeated here to avoid repetition.

[0126] In some embodiments, a buffer event is a persistent data structure that encapsulates a terminal fault report request or a work order status change operation when the link is interrupted.

[0127] In one possible implementation, the buffered event includes at least the following fields: storage sequence number, event type (event_type), business payload (payload), idempotent key, content fingerprint, local temporary ticket identifier (local_ticket_id), event creation time (created_at), and synchronization status (sync_status).

[0128] In one possible implementation, a sequence number is stored to determine the order in which buffered events are read and assurance work orders are resubmitted when the link status is recovered, and to ensure that the creation event of the same work order is processed before the status change event.

[0129] In one possible implementation, an event type is used to distinguish between new fault reporting events (REPORT) and work order status change events (STATE_CHANGE).

[0130] In one possible implementation, the service payload is used to carry a unified fault reporting model or state transition information that has been semantically adapted.

[0131] In one possible implementation, the local temporary work order identifier is a temporary order number assigned during the offline phase, which is used to associate all buffered events of the same support work order and is mapped to the work order identifier of the support work order after successful retransmission.

[0132] In one possible implementation, the event generation time is used for capacity eviction and audit traceability.

[0133] In one possible implementation, a synchronization state is used to identify whether the buffered event is in a state of pending synchronization, in transmission, acknowledged, or failed, thereby driving the processing logic of the retransmission scheduler.

[0134] In some embodiments, prior to step 210, the above-described work order processing method may further include steps A1 to A3.

[0135] Step A1: Send a heartbeat detection request to the enterprise management system according to the preset heartbeat cycle, and record the number of consecutive detection failures and the number of consecutive detection successes.

[0136] Step A2: If the number of consecutive failed probes reaches a preset first threshold, the link status is determined to be interrupted.

[0137] Step A3: If the link status is interrupted and the number of consecutive successful probes reaches a preset second threshold, determine that the link status is restored.

[0138] In this embodiment of the application, the first threshold is greater than the second threshold.

[0139] For example, the heart rate cycle is 20 seconds, the first threshold is set to 3 times, and the second threshold is 2 times.

[0140] In one possible implementation, step A1 may include: periodically sending heartbeat detection requests to the enterprise management system, and counting the number of consecutive detection failures and the number of consecutive detection successes based on the response messages returned by the enterprise management system.

[0141] In one possible implementation, the edge node maintains two independent counters to record the number of consecutive failed heartbeat probes and the number of consecutive successful heartbeat probes, respectively. After each heartbeat probe is completed, the corresponding counter is updated based on the response message: if no normal response is received from the enterprise management system, the number of consecutive failed heartbeat probes is incremented by 1, and the number of consecutive successful heartbeat probes is reset to zero; if a normal response message is received, the number of consecutive successful heartbeat probes is incremented by 1, and the number of consecutive failed heartbeat probes is reset to zero.

[0142] For example, the heartbeat probe request uses a lightweight HTTPS HEAD request or calls a dedicated health check interface; if a valid HTTP 200 response or interface receipt is received, the probe is considered successful; if a TCP timeout, TLS handshake failure, HTTP 5xx error, or adapter unreachable occurs, the probe is considered unsuccessful.

[0143] In one possible implementation, step A2 may include: when the cumulative number of consecutive probe failures reaches a preset first threshold, the edge node determines that the current link status is interrupted.

[0144] In one possible implementation, after step A2, the above-mentioned work order processing method may further include: switching to offline processing mode. Offline processing mode encapsulates work order creation requests and work order status change events into buffered events and persistently stores them in a local ordered queue, while continuously and periodically sending heartbeat probes to continuously monitor link recovery status.

[0145] In one possible implementation, after step A3, the above work order processing method may further include: exiting the offline acceptance mode and initiating the retransmission process. The retransmission process reads local cached data in ascending order according to the buffer event storage sequence number, performs idempotent deduplication checks before retransmitting each event, prioritizes synchronizing work order creation events, and then synchronizes the corresponding work order status change events, completing the batch synchronization of local cached data to the backend.

[0146] Understandably, if the number of consecutive failed probes does not reach 3, it will not be mistakenly judged as an interruption; even if it is mistakenly judged, it will only be able to recover after 2 consecutive successful probes, thus avoiding the oscillation of "interruption-repair-interruption".

[0147] In this way, by designing differentiated thresholds, with a higher threshold for disconnection and a lower threshold for recovery, the system effectively avoids frequent mode switching and repeated start-stop retransmission tasks caused by instantaneous network jitter, thereby improving the stability of system operation.

[0148] Step 211: If the link status is restored, read the fault report work order according to the storage sequence number of the buffer event.

[0149] In this embodiment, the storage sequence number of the buffer event is a monotonically increasing unique integer identifier assigned by the edge node to each buffer event written to the local persistent queue when the link state is interrupted.

[0150] It should be noted that different types of events are distinguished by the event type field, and all status change events under the same work order are bound to the local temporary work order identifier of the corresponding fault reporting work order.

[0151] In some embodiments, step 211 may include: reading the fault report work orders corresponding to the buffer events in ascending order of the buffer event storage sequence number.

[0152] For example, the local persistent queue can be an SQLite database, and the stored sequence number can be... .

[0153] Step 212: For any fault report work order read, use the work order identifier to query the preset identifier index table to determine whether the fault report work order has been successfully marked and confirmed by the enterprise management system.

[0154] In this embodiment of the application, successful confirmation (ACK) from the enterprise management system means that the edge node server has received a confirmation receipt from the group's backend ERP / ITSM system. The confirmation receipt indicates that the fault report work order has been officially created or updated in the enterprise management system, and the data of both parties has reached an agreement.

[0155] In some embodiments, step 212 may include: for any fault report work order read, extracting the work order identifier bound to the buffer event, querying a locally stored identifier index table, the index table recording whether each work order has received a successful confirmation receipt returned by the enterprise management system; if the work order identifier exists in the index table, determining that the fault report work order has received a successful confirmation receipt returned by the enterprise management system; if the work order identifier does not exist in the index table, determining that the fault report work order has not received a successful confirmation receipt returned by the enterprise management system.

[0156] For example, the work order identifier can be an idempotency key. The idempotency key is extracted from the buffer event and used to query the preset identifier index table. If the identifier exists in the index table and the status is ACKED, the enterprise management system has successfully created the work order. If the identifier does not exist in the index table or the status is PENDING, the enterprise management system has not yet successfully created the work order.

[0157] Step 213: If the fault report work order is not successfully confirmed by the enterprise management system, suspend the resubmission of all work order status change events corresponding to the fault report work order until the fault report work order is confirmed.

[0158] Understandably, in the event of a link interruption, if a worker performs actions such as accepting or completing an order on their PDA, these actions are encapsulated as work order status change events and written to a local buffer queue, but are not sent out. Once the link is restored, the work order status change events need to be read from the local queue and re-uploaded to the enterprise management system. This allows the enterprise management system to catch up on the missing status transitions and maintain data consistency between the edge nodes and the enterprise management system.

[0159] In some embodiments, step 213 may include: if the query determines that the fault report work order has not received a successful confirmation receipt from the enterprise management system, then immediately suspend the resubmission process of all work order status change events corresponding to the current work order, stop reading and uploading any status change buffer events under the work order, and only continue to retry uploading the work order creation request of the work order.

[0160] In some embodiments, after step 212, the above-mentioned work order processing method may further include: if the query result shows that the fault report work order has been marked as successfully confirmed by the enterprise management system, then the retransmission operation of this buffer event is performed normally.

[0161] In some embodiments, after step 212, the above-mentioned work order processing method may further include: updating the retry counter if the work order status change event synchronization fails; adopting an exponential backoff strategy and waiting for a preset time; if the synchronization still fails after the number of retries reaches the preset maximum number of retries, permanently marking this event as a failure and outputting it.

[0162] For example, updating the retry counter involves incrementing the retry counter by 1. = +1; An exponential backoff strategy is used to control the retry interval, with the nth retry waiting 2 seconds. n The maximum waiting interval is 300 seconds. The preset maximum retries... The retry count is set to 5. If synchronization still fails after reaching the threshold, this event will be permanently marked as FAILED and an operation and maintenance alarm will be pushed. In this way, even if the synchronization of the event corresponding to the current storage sequence number fails, the subsequent work order status change events of the same work order will not be skipped, maintaining serial blocking and preventing the status change from being synchronized to the backend before the work order is successfully created, resulting in status inversion and backend data anomalies.

[0163] In this way, by storing sequence numbers to ensure that the timing of event reporting remains unchanged, and by using an identifier index table to verify the completion status of work order creation, the problem of missing work order data and disordered status flow caused by the premature uploading of status events in the context of network outage caching is solved, thus ensuring the consistency of work order data timing between the edge and enterprise management systems.

[0164] In some embodiments, after step 212, the above-mentioned work order processing method may further include: receiving the returned formal work order identifier when the fault reporting work order is successfully created in the enterprise management system; writing the formal work order identifier back to the identifier index table to establish a mapping relationship between the local temporary identifier and the formal work order identifier.

[0165] In some embodiments, after step 212, the above-described work order processing method may further include steps 301 to 304.

[0166] Step 301: Obtain the mapping table between the internal work order status set of the edge node and the external status set of the enterprise management system.

[0167] In this embodiment, the mapping table establishes a one-to-one correspondence between the internal work order status set of the edge node and the external work order status set of the enterprise management system. For example, the edge node "pending dispatch" corresponds to the enterprise management system "pending allocation", the edge node "completed" corresponds to the enterprise management system "processed", and the edge node "closed" corresponds to the enterprise management system "verified", thus realizing the mutual translation and conversion of different status codes at both ends.

[0168] Step 302: In response to a work order status switch at the edge node, the internal status is synchronized to the enterprise management system through a mapping table.

[0169] In some embodiments, when maintenance personnel complete operations such as accepting orders, completing tasks, and closing tasks on the edge side, the edge node undergoes a work order status switch.

[0170] In some embodiments, step 302 may include: the edge node reading the bidirectional mapping table, converting the switched internal state into an external standard state recognizable by the enterprise management system, actively initiating a synchronization request, and uploading the latest work order status to the enterprise management system to complete the remote status update.

[0171] For example, when a user performs a "submit completed" operation on the terminal, the work order state machine module of the edge node server responds to the operation instruction by switching its internal state from "processing" to "pending verification". The edge node calls the ERP / ITSM adapter, which uses a mapping table to convert the internal state "pending verification" into a "To be Verified" instruction that the enterprise management system can recognize, and then sends the instruction to the enterprise management system.

[0172] Step 303: In response to the work order status write-back in the enterprise management system, update the external status of the enterprise management system through the mapping table.

[0173] In some embodiments, when the enterprise management system performs downstream operations such as work order status review, backend reset, and order write-back, the enterprise management system will write the latest external status back to the edge node. After receiving the write-back status, the edge node will also reverse the parsing and matching through a bidirectional mapping table to translate the external status in the cloud into the corresponding internal status of the edge node, and synchronously update the external status image of the local work order storage, thereby realizing the downward overlay and synchronization of the backend status.

[0174] For example, bidirectional synchronization is achieved through a mapping table M, and each state transition generates the following reconciliation record: 。

[0175] in, For internal work order status sets, This is an external system status set. id is an abbreviation for local_ticket_id, which represents the local temporary work order identifier bound to this reconciliation difference record.

[0176] Step 304: If the internal state is inconsistent with the external state and exceeds the preset reconciliation window, trigger the compensation synchronization task to correct the state according to the timestamp and the preset source priority.

[0177] In this embodiment, the reconciliation window is a time threshold for edge nodes to determine whether the inconsistency between the internal and external states constitutes an abnormal conflict. The reconciliation window is used to eliminate errors caused by network latency.

[0178] It is understandable that the internal state and the external state may be inconsistent for a short period of time, possibly due to network latency. When the timeout occurs, it is considered that they are indeed inconsistent and need to be compensated and synchronized.

[0179] For example, the reconciliation window is set to 30-120 seconds.

[0180] In some embodiments, edge nodes continuously compare the local internal state of each work order with its remote external state mirror in real time. If an inconsistency is detected between the internal and external states, and the duration of this inconsistency exceeds a preset reconciliation window, it is determined to be a synchronization lag or synchronization anomaly, and a global compensation synchronization task is automatically triggered. The compensation task obtains the change timestamps corresponding to the states at both ends, and, combined with the system's preset data source priority strategy, uses the authoritative state with the more recent update time and higher priority as the benchmark to automatically correct the inconsistent work order states at both ends, completing cross-system state alignment.

[0181] For example, if detected With writing back Inconsistencies exceeding the reconciliation window trigger a compensation synchronization task: the side with the newest timestamp and higher source priority is used, or it is marked as awaiting manual reconciliation. (In internal state) Entering the closed equivalent state, external state Once the system enters the reconciliation-equivalent state, the internal and external states are confirmed to be equivalent through the mapping table M. At this point, the system writes the final reconciliation record Δ into the immutable Audit Chain, and the entire lifecycle of the fault report ends.

[0182] In this way, the problem of inconsistent internal and external system status is solved by bidirectional mapping, the status is kept consistent within seconds in most scenarios by bidirectional real-time synchronization, and the status disorder caused by network jitter, offline retransmission and asynchronous write-back is repaired by timeout reconciliation and priority compensation mechanism, which greatly improves the consistency of work order data and system reliability under the edge offline acceptance architecture.

[0183] In summary, in this embodiment, firstly, a preset threshold is set to filter low-confidence fields, and only content with high matching scores is written into the standard field, effectively eliminating noisy data and ensuring that the generated work order creation request accurately reflects the actual fault situation, thus guaranteeing the accuracy of subsequent work order dispatch from the source. Secondly, based on the matching processing group, the processing group load and remaining SLA time are further introduced as the basis for work order dispatch, realizing dynamic balance of workload and preventing some processing groups from exceeding their SLA due to task backlog while other groups are idle, thus optimizing the overall utilization of operation and maintenance resources. Thirdly, by concatenating the asset number, gridded geographical location, and normalized description text and performing hash calculation to generate content fingerprints, the same fault occurring on the same device at the same location can be identified more accurately. Finally, by maintaining a bidirectional mapping table and a reconciliation window mechanism, the inconsistency between the edge nodes and the backend management system caused by network latency, operation concurrency, and other reasons can be effectively solved.

[0184] In some embodiments, edge nodes, an enterprise management system, and multiple terminals constitute a work order processing system. The work order processing system includes a terminal access layer, an edge access layer, a core processing layer, and a backend interaction and output layer.

[0185] In some embodiments, the terminal access layer is used to collect on-site fault information. For example, it collects information from mobile devices used by ordinary employees or inspection personnel, PDAs used in industrial scenarios such as factories and warehouses, and IoT sensor gateways.

[0186] In some embodiments, the edge access layer includes a unified fault reporting interface gateway, which is used to receive fault handling requests from different devices and forward them to the semantic adapter, and to provide multi-protocol access endpoints such as Representational State Transfer (REST), Message Queuing Telemetry Transport (MQTT), and private protocols.

[0187] In some embodiments, the core processing layer is used for parsing fault reports, making routing decisions, and managing state.

[0188] For example, the core processing layer includes a terminal semantic adapter, a multimedia fusion parsing module, a permission and organization routing engine, a work order state machine module, a cross-terminal synchronization module, an offline buffering and retransmission module, and a message queue and idempotency module. The terminal semantic adapter maps heterogeneous fault reports to a unified work order semantic model for the group. Upstream, the terminal semantic adapter connects to the unified fault reporting interface gateway, and downstream, it connects to the multimedia module and the permission engine. The multimedia fusion parsing module performs Automatic Speech Recognition (ASR) transcription on speech, extracts tags from images, and performs Optical Character Recognition (OCR). The system integrates Recognition (OCR) into structured fields and outputs standard fields with confidence scores for work order creation. The permission and organization routing engine is used to determine the visibility range and allocation pool of work orders based on the group's organizational tree, roles, and regions, and to constrain message queuing and allocation strategies. The work order state machine module is used to manage states such as pending, processing, pending verification, and closed, as well as transition rules, and to drive cross-terminal synchronization and ERP / ITSM mapping. When the link is interrupted, the local transition is written to the buffer queue. The cross-terminal synchronization module is used to subscribe to state machine events to ensure that the same work order has the same state on the mobile phone and PDA, and to handle concurrent update conflicts. The offline buffer and retransmission module is used to work with the idempotency module, state machine, and adapter. When the link is interrupted, the fault reporting request and state change event are written to the local persistent queue, and retransmitted in order according to the sequence number after recovery. The message queue and idempotency module is used to connect the state machine and the offline buffer, and to jointly determine duplicates in online / retransmission scenarios using terminal ID, time window, and content fingerprint to avoid duplicate work order creation.

[0189] In some embodiments, the backend interaction and output layer is used for synchronization with the enterprise management system and for notification services.

[0190] For example, the backend interaction and output layer includes an ERP / ITSM adapter for field mapping, bidirectional state synchronization, and abnormal reconciliation.

[0191] Figure 4 This is a block diagram of a work order processing device provided in an embodiment of this application, such as... Figure 4 As shown, the work order processing device 400 is applied to an edge node, which is connected to the enterprise management system and multiple terminals, and includes the following modules.

[0192] The work order generation module 401 is used to respond to a fault handling request sent by any terminal and generate a fault reporting work order based on the voice data, image data and structured fields in the fault handling request. The fault reporting work order includes the work order type, the group organization tree node associated with the fault handling request, the terminal device identifier and fault description information. The work order dispatch module 402 is used to match the fault handling group of the fault handling request and dispatch the work order according to the work order type and the group organization tree node. The work order deduplication module 403 is used to generate a work order identifier for a fault reporting work order based on the terminal device identifier, fault description information and preset time identifier, and to perform deduplication based on the work order identifier. The offline processing module 404 is used to encapsulate the fault report work order into a buffer event and store it when the link between the edge node and the enterprise management system is interrupted. The recovery module 405 reads the buffered events when the link status is restored, and resubmits the fault report work order after checking for duplicates based on the work order identifier.

[0193] Optionally, the fault description information includes the asset number and gridded geographic location information. The work order deduplication module 403 is specifically used for: The content fingerprint is obtained by concatenating and hashing the terminal device identifier, asset number, and gridded geographic location information. The content fingerprint, terminal device identifier, and time identifier are combined to generate a work order identifier; Use the work order identifier to query the preset identifier index table to determine whether the fault handling request is a duplicate fault report.

[0194] Optionally, the work order generation module 401 is specifically used for: In response to a fault handling request, speech recognition is performed on the speech data to obtain text fault information, and feature extraction is performed on the image data to obtain image fault feature information. By fusing and analyzing text fault information, image fault feature information, and structured fields, fused fault reporting information is obtained. The integrated fault reporting information is semantically matched with multiple preset candidate fields to obtain the matching confidence of each candidate field; A fault report is generated based on candidate fields whose matching confidence level is greater than or equal to a preset range.

[0195] Optionally, the work order dispatch module 402 is specifically used for: Based on the work order type and the group organization tree node, select the processing group associated with the nearest ancestor node as the fault handling group; Work orders are dispatched based on the work order type, the load of the fault handling group, and the remaining time of the service level agreement. Among them, the group organization tree node includes any one of the group, region, subsidiary and department levels, the ancestor node is all the superior nodes on the path from the group organization tree node to the root node, and the processing group is a preset virtual queue with corresponding fault handling capabilities.

[0196] Optionally, the work order processing device 400 also includes a link detection module for: The system sends heartbeat detection requests to the enterprise management system according to a preset heartbeat cycle, and records the number of consecutive failed detections and the number of consecutive successful detections. If the number of consecutive failed probes reaches a preset first threshold, the link status is determined to be interrupted; If the link status is interrupted and the number of consecutive successful probes reaches a preset second threshold, the link status is determined to be restored; the first threshold is greater than the second threshold.

[0197] Optionally, the recovery retransmission module 405 is specifically used for: If the link status is recovered, read the fault report work order according to the storage sequence number of the buffer event; For any fault report work order read, use the work order identifier to query the preset identifier index table to determine whether the fault report work order has been successfully marked and confirmed by the enterprise management system. If a fault report is detected as not being successfully confirmed by the enterprise management system, the resubmission of all fault report status change events will be suspended until the fault report is confirmed.

[0198] Optionally, the work order processing device 400 also includes a status synchronization module for: Obtain the mapping table between the internal work order status set of the edge node and the external status set of the enterprise management system; In response to work order status switching at edge nodes, the internal status is synchronized to the enterprise management system through a mapping table; In response to a work order status write-back from the enterprise management system, the external status of the edge node is updated through the mapping table; If the internal and external states are inconsistent and exceed the preset reconciliation window, a compensation synchronization task is triggered to correct the state based on the timestamp and preset source priority.

[0199] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0200] Figure 5 This is a structural block diagram illustrating a work order processing system according to an exemplary embodiment. For example... Figure 5 As shown, the work order processing system includes: a processor, a memory, a communication interface, and a communication bus. The processor, memory, and communication interface communicate with each other through the communication bus. The memory is used to store at least one executable instruction, which causes the processor to execute the steps of the work order processing method described in the previous embodiment.

[0201] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory including instructions that can be executed by a processor of a work order processing system to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0202] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described work order processing method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0203] This application also provides a computer program product, including a computer program, which implements a work order processing method when executed by a processor.

[0204] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar parts between the various embodiments can be referred to each other.

[0205] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0206] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0207] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a predictive manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0208] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0209] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0210] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0211] The above is a detailed description of the preferred embodiments of this application. However, the invention of this application is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A work order processing method, characterized in that, Applied to edge nodes, which are connected to an enterprise management system and multiple terminals, the method includes: In response to a fault handling request sent by any of the terminals, a fault reporting work order is generated based on the voice data, image data, and structured fields in the fault handling request; the fault reporting work order includes the work order type, the group organization tree node associated with the fault handling request, the terminal device identifier, and fault description information; Based on the work order type and the group organization tree node, match the fault handling group of the fault handling request and dispatch the work order; Based on the terminal device identifier, the fault description information, and the preset time identifier, a work order identifier is generated for the fault reporting work order, and duplicates are checked based on the work order identifier; If the link between the edge node and the enterprise management system is interrupted, the fault report work order is encapsulated as a buffer event and stored. If the link status is restored, read the buffer event, and resubmit the fault report work order after checking for duplicates based on the work order identifier.

2. The method according to claim 1, characterized in that, The fault description information includes asset number and gridded geographical location information. The process of generating a work order identifier for the fault report based on the terminal device identifier, the fault description information, and a preset time identifier, and then performing duplicate checks based on the work order identifier, includes: The content fingerprint is obtained by concatenating and hashing the terminal device identifier, the asset number, and the gridded geographic location information. The content fingerprint, the terminal device identifier, and the time identifier are combined to generate the work order identifier; The work order identifier is used to query a preset identifier index table to determine whether the fault handling request is a duplicate fault report.

3. The method according to claim 1, characterized in that, The method of responding to a fault handling request sent by any of the terminals, generating a fault reporting work order based on the voice data, image data, and structured fields in the fault handling request, includes: In response to the fault handling request, speech recognition is performed on the speech data to obtain text fault information, and feature extraction is performed on the image data to obtain image fault feature information; The text fault information, the image fault feature information, and the structured fields are fused and analyzed to obtain fused fault reporting information; The fused fault reporting information is semantically matched with multiple preset candidate fields to obtain the matching confidence of each candidate field; The fault report is generated based on the candidate fields whose matching confidence is greater than or equal to a preset range.

4. The method according to claim 1, characterized in that, The step of matching the fault handling request to the fault handling group and dispatching the work order based on the work order type and the group organization tree node includes: Based on the work order type and the group organization tree node, select the processing group associated with the nearest ancestor node as the fault processing group; The work order is dispatched based on the work order type, the load of the fault handling group, and the remaining time of the service level agreement. The group organization tree node includes any one of the group, region, subsidiary and department levels, the ancestor node is all the parent nodes on the path from the group organization tree node to the root node, and the processing group is a preset virtual queue with corresponding fault handling capabilities.

5. The method according to claim 1, characterized in that, Before encapsulating the fault report as a buffered event and storing it when the link between the edge node and the enterprise management system is interrupted, the method further includes: According to the preset heartbeat cycle, a heartbeat detection request is sent to the enterprise management system, and the number of consecutive detection failures and the number of consecutive detection successes are recorded; If the number of consecutive detection failures reaches a preset first threshold, the link status is determined to be interrupted; If the link status is interrupted and the number of consecutive successful probes reaches a preset second threshold, the link status is determined to be restored; the first threshold is greater than the second threshold.

6. The method according to claim 1, characterized in that, When the link status is restored, reading the buffered event and resubmitting the fault report work order after checking for duplicates based on the work order identifier includes: If the link status is restored, the fault report work order is read according to the storage sequence number of the buffer event; For any of the reported work orders read, the work order identifier is used to query a preset identifier index table to determine whether the reported work order has been successfully marked and confirmed by the enterprise management system. If the enterprise management system detects that the fault report work order has not been successfully confirmed, the resubmission of all work order status change events corresponding to the fault report work order will be suspended until the fault report work order is confirmed.

7. The method according to claim 1, characterized in that, When the link status is restored, after reading the buffered event and resubmitting the fault report work order after checking for duplicates based on the work order identifier, the method further includes: Obtain the mapping table between the internal work order status set of the edge node and the external status set of the enterprise management system; In response to a work order status switch at the edge node, the internal status is synchronized to the enterprise management system through the mapping table; In response to a work order status write-back from the enterprise management system, the external status of the edge node is updated through the mapping table; If the internal state is inconsistent with the external state and exceeds the preset reconciliation window, a compensation synchronization task is triggered to correct the state based on the timestamp and the preset source priority.

8. A work order processing device, characterized in that, Applied to edge nodes, which are connected to an enterprise management system and multiple terminals, the device includes: The work order generation module is used to respond to a fault handling request sent by any of the terminals and generate a fault reporting work order based on the voice data, image data and structured fields in the fault handling request; the fault reporting work order includes work order type, group organization tree node associated with the fault handling request, terminal device identifier and fault description information; The work order dispatch module is used to match the fault handling group of the fault handling request and dispatch the work order according to the work order type and the group organization tree node. The work order deduplication module is used to generate a work order identifier for the fault reporting work order based on the terminal device identifier, the fault description information, and a preset time identifier, and to perform deduplication based on the work order identifier; The offline processing module is used to encapsulate the fault report work order into a buffer event and store it when the link between the edge node and the enterprise management system is interrupted. The recovery and retransmission module, when the link status is restored, reads the buffer event, checks for duplicates based on the work order identifier, and resubmits the fault report work order.

9. A work order processing system, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the work order processing method as described in any one of claims 1-7.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the work order processing method as described in any one of claims 1-7.

Images