Distributed work order management system based on intelligent dispatching

Abstract

The invention relates to the field of intelligent work order dispatching, in particular to a distributed work order management system based on intelligent dispatching. The invention provides a distributed work order management system based on intelligent assignment, and the system comprises an organizational structure engine module which employs a father-child node tree structure, divides operation and maintenance regions according to the three levels of province, city and district, and carries out the node binding of the responsible person authority level of the region; the intelligent order dispatching module is used for realizing automatic matching of the work order and the operation and maintenance personnel through a preset algorithm; the data analysis module collects work order data in real time to generate a multi-dimensional analysis chart, and predicts the regional fault probability through machine learning; and the early warning feedback module is used for setting an SLA threshold value and automatically upgrading and alarming an overtime work order. The work order system realizes digital management through an automatic and standardized process, greatly reduces the time consumption cost of offline communication, and improves the operation and maintenance efficiency.

Description

Technical Field

[0001] The present invention relates to the field of intelligent dispatching, and in particular to a distributed work order management system based on intelligent dispatching. Background Art

[0002] In traditional equipment management systems, the allocation of repair work orders often relies heavily on manual labor, particularly subjective judgment by maintenance team leaders, who primarily assign new tasks based on the number of work orders currently on hand. This manual dispatching mechanism, often characterized by high communication costs and time consumption, is prone to process loopholes. Manual work alone can be flawed and fails to achieve a closed-loop accounting system. Furthermore, it lacks a fast, transparent billing and settlement system, resulting in low mobilization effectiveness. Summary of the Invention

[0003] In order to solve the technical problems that traditional allocation mechanisms are mostly manual dispatching, with high communication costs, long time consumption, and many process loopholes, manual labor has omissions and cannot complete the closed loop of accounts. In addition, it is impossible to achieve a fast and open order settlement method and the mobilization effect is low, one purpose of the present invention is to provide a distributed work order management system based on intelligent dispatching.

[0004] To achieve the above objectives, an embodiment of the present invention provides a distributed work order management system based on intelligent dispatching, comprising:

[0005] The organizational structure engine module adopts a parent-child node tree structure, dividing the operation and maintenance areas into three levels: province, city, and district. The nodes are bound to the authority level of the regional person in charge;

[0006] The intelligent dispatch module generates dispatch priority weights based on maintenance area, station location, and personnel availability, and automatically matches work orders with maintenance personnel through a preset algorithm.

[0007] The data analysis module collects work order data in real time to generate multi-dimensional analysis charts, predicts regional failure probability through machine learning, and generates preventive maintenance recommendations;

[0008] The early warning feedback module sets SLA thresholds and automatically escalates overdue work orders to alarms.

[0009] In the above technical solution, the organizational structure engine module adopts the RD-Tree data structure, dynamically covering the three-level nodes of provinces, cities, and districts across the country. Each node stores regional managers, available operation and maintenance personnel, and equipment distribution metadata.

[0010] In the above technical solution, the intelligent dispatching module adopts a dynamic optimization algorithm based on geographic location weights. The calculation formula of the algorithm is as follows:

[0011]

[0012] Where: W is the optimal operation and maintenance personnel; D is the real-time distance between the site and the operation and maintenance personnel; S is the skill matching degree; R is the historical response speed; C is the bidding weight.

[0013] In the above technical solution, the data analysis module constructs an LSTM neural network, inputs historical fault data, and outputs a regional fault probability heat map.

[0014] In the above technical solution, the data analysis module adopts

[0015] Use Apache Spark Structured Streaming as the core stream processing framework, combined with Kafka as the message queue, to achieve low-latency transmission and persistent buffering of work order data;

[0016] The core process framework includes an acquisition layer, a processing layer, a storage layer, and an analysis layer.

[0017] In the above technical solution, the collection layer collects the work order data source in real time through Flume or KafkaConnect;

[0018] The processing layer runs predefined processing logic through the Spark engine and writes the calculation results to the storage layer;

[0019] The analysis layer provides an SQL interface through Hive or StarRocks, supporting business personnel to query real-time statistical indicators of work orders by themselves.

[0020] In the above technical solution, the stream processing logic of the stream processing framework is window aggregation, state management, anomaly detection and data persistence in sequence.

[0021] Additional aspects and advantages of the invention will become apparent from the description which follows, or may be learned by practice of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments with reference to the accompanying drawings, in which:

[0023] Figure 1 It is a schematic diagram of the overall process of the present invention; DETAILED DESCRIPTION

[0024] In order to more clearly understand the above-mentioned objects, features and advantages of the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be noted that, in the absence of conflict, the embodiments of the present application and the features therein can be combined with each other.

[0025] In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Therefore, the scope of protection of the present invention is not limited to the specific embodiments disclosed below.

[0026] Refer to the following Figure 1 A distributed work order management system based on intelligent dispatching according to some embodiments of the present invention is described.

[0027] like Figure 1 As shown, an embodiment of the present invention provides a distributed work order management system based on intelligent dispatching, including:

[0028] 1. Organizational structure engine module:

[0029] It adopts a parent-child node tree structure, divides the operation and maintenance areas into three levels: province, city, and district, and supports dynamic expansion; nodes are bound to the authority level of the regional manager (for example, provincial administrators can cover subordinate city-level nodes).

[0030] It adopts the RD-Tree (RegionDistributedTree) data structure, dynamically covering the provincial, municipal and district nodes. Each node stores metadata such as the regional manager, available operation and maintenance personnel, equipment name, equipment distribution, etc., to facilitate operation and maintenance personnel to find the specific location of the equipment; all operation and maintenance personnel involved in the work order have detailed names, contact information and corresponding regions, and personnel with different weights have different levels of management functions.

[0031] Supports dynamic load balancing: When the number of work orders in a certain area exceeds the threshold, the collaborative processing mechanism of adjacent nodes is automatically triggered (for example, when the work orders in Jiangsu Province are overloaded, idle operation and maintenance resources in Anhui Province are called).

[0032] 2. Intelligent dispatch module:

[0033] The dispatch priority weight is generated based on the maintenance area, station location, and personnel availability. A preset algorithm is used to automatically match work orders with maintenance personnel. The specific steps are as follows:

[0034] S1. Multidimensional feature modeling and weight optimization

[0035] S11. Work order feature extraction

[0036] Extract key work order information (such as equipment model, fault code, and urgency) provided by the repair unit based on natural language processing (NLP) technology;

[0037] By associating historical work order data through knowledge graphs, a mapping relationship library between fault types and solutions is constructed.

[0038] S12. Dynamic portrait of resources

[0039] Engineer portrait: A multi-dimensional rating matrix is ​​constructed based on comprehensive skill certificates (static data), historical response speed (dynamic data), geographic location (real-time GPS), and service ratings (customer feedback);

[0040] Equipment profiling: Predict equipment failure probability based on IoT sensor data and generate preventive maintenance work orders.

[0041] S13. Matching weight model

[0042] The intelligent dispatching module uses a dynamic optimization algorithm based on geographic location weights. The algorithm calculation formula is as follows:

[0043]

[0044] Where: W is the optimal operation and maintenance personnel; D is the real-time distance between the site and the operation and maintenance personnel; S is the skill matching degree; R is the historical response speed; C is the bidding weight.

[0045] S2. Dynamic Optimization Strategy and Scheduling Algorithm

[0046] S21. Multi-objective optimization algorithm

[0047] Pareto Optimal ity is used to balance efficiency and cost. The objective function includes:

[0048] Minimize overall response time: Where Ti is the response time of the i-th task;

[0049] Maximize engineer utilization:

[0050] Minimize cross-region dispatch costs: Where: Cj is the unit distance cost, Dj is the dispatch distance;

[0051] S22. Real-time path planning

[0052] Integrate Dijkstra algorithm with real-time traffic data (such as Amap API) to dynamically calculate the optimal route;

[0053] For unexpected situations (such as traffic jams), the A* algorithm is enabled to replan the route.

[0054] S23. Load balancing mechanism

[0055] Predict the number of work orders in each region based on time series, and adjust the distribution of engineers' locations in advance;

[0056] Adopt a preemptive scheduling strategy: allow high-priority work orders to interrupt the allocation of low-priority tasks.

[0057] S3. Algorithm architecture design and engineering implementation

[0058] S31. Distributed computing framework

[0059] Use Apache Flink to process real-time work order stream data and achieve millisecond-level delay in dispatching decisions;

[0060] Historical data is used to train models in batches using Spark (such as LSTM to predict fault hotspots).

[0061] S32. Reinforcement Learning Optimization

[0062] Construct a Monte Carlo Tree Search (MCTS) model to simulate the long-term returns of different order dispatching strategies;

[0063] Dynamically adjust weight parameters through the Q-learning model (for example, if the response speed of a certain area decreases, the distance weight will be automatically increased).

[0064] S33.Exception handling mechanism

[0065] Set dual threshold alarms: When the work order processing time exceeds the SLA standard, it will trigger automatic escalation of the order.

[0066] Abnormal detection of engineer status (such as long-term inactivity) triggers work order reassignment.

[0067] S4. Continuous optimization and effect verification

[0068] S41. Closed-loop feedback system

[0069] Collect work order processing results (resolution time, customer ratings) and update the model through transfer learning;

[0070] Establish an AB testing mechanism to compare the effects of different algorithm versions.

[0071] S42. Performance improvement

[0072] The first-time order success rate increased from 68% to 93%;

[0073] The proportion of cross-regional dispatch has been reduced from 28% to 9%;

[0074] The accuracy of preventive maintenance triggering has increased from 65% to 82%.

[0075] 3. Data Analysis Module:

[0076] 1. Architecture design and technology selection

[0077] S1. Distributed computing engine

[0078] Apache Spark Structured Streaming is used as the core stream processing framework. Its micro-batch mode (Micro-Batch) can split PB-level work order data into small batches for parallel processing, supporting a throughput of more than one million events per second and achieving fault-tolerant recovery through RDD dependencies.

[0079] Combined with Kafka as a message queue, low-latency transmission and persistent buffering of work order data can be achieved.

[0080] Use the Flink stream processing engine to aggregate and compile national work order data (e.g., by province, fault type, or cost range).

[0081] Build an LSTM neural network, input historical failure data (time, location, equipment model), output regional failure probability heat map, and guide preventive maintenance.

[0082] Operation and maintenance personnel upload geo-tagged maintenance images through the mobile app. The system automatically identifies the device model and links it to the knowledge base (e.g., solutions to common faults of a certain inverter model).

[0083] OpenCV is used to perform anomaly detection (such as cable damage identification) on uploaded images to assist manual review.

[0084] After the review is passed, the bank API is called to complete the payment and a structured electronic voucher (including work order number, maintenance item, and amount) is generated simultaneously.

[0085] S2. Layered Architecture

[0086] Collection layer: Use Flume or KafkaConnect to collect work order data sources (such as database Binlog, log files, API interfaces) in real time, and support JSON / CSV and other format parsing.

[0087] Processing layer: The Spark engine runs predefined processing logic (such as field cleaning, status update, and anomaly detection), and writes the calculation results to the real-time OLAP or incremental storage layer.

[0088] Storage layer: Use Hudi or Paimon to store real-time calculation results and historical snapshots, supporting snapshot queries and incremental reads.

[0089] Analysis layer: Provides SQL interfaces through Hive or StarRocks to support business personnel to query real-time statistical indicators of work orders by themselves.

[0090] 2. Real-time data processing flow

[0091] S1. Real-time data collection

[0092] After the data is accessed, the Avro format work order fields (such as work order ID, status change time, and processing personnel) are dynamically parsed through SchemaRegistry.

[0093] S2. Stream processing logic

[0094] Window aggregation: Statistics on the response time distribution of work orders by time window (such as calculating the average processing time using a 5-minute sliding window).

[0095] State management: Track the lifecycle state of a work order (such as the transition path from "pending" to "resolved") through mapGroupsWithState.

[0096] Anomaly detection: Based on the rule engine, it identifies timed tickets (for example, tickets that are not assigned to a customer service representative within 24 hours of creation) and triggers an alert event flow.

[0097] S3. Data persistence

[0098] The calculation results are written into the Paimon table, which supports ACID transaction features to ensure the atomicity of work order status changes. At the same time, historical archive data is stored through HDFS to build a Lambda architecture.

[0099] 3. Performance Optimization Strategy

[0100] Pressure mechanism: Enable Spark dynamic back pressure to prevent data backlog from causing memory overflow;

[0101] Dynamic resource allocation: Based on the elastic scaling strategy of YARN / K8s, the number of executors is automatically increased or decreased according to the load, saving more than 30% of cluster resources;

[0102] Partitioning strategy: HashPartitioner is used for work order IDs to distribute computing load, and RangePartitioner is used for time fields to optimize time series queries and reduce the risk of shuffle data skew.

[0103] Caching mechanism: Enable Alluxio memory caching for frequently accessed dimension tables (such as customer service personnel information) to reduce cross-cluster IO overhead and improve join performance.

[0104] 4. Data Security and Governance

[0105] S1. Permission Control

[0106] Integrate Apache Ranger to implement library, table, and field-level access control, for example, restricting the customer service team to only query the work order details of their department.

[0107] S2. Transmission encryption

[0108] TLS is used to encrypt the Kafka data transmission link, and Kerberos authentication is implemented between Spark and the storage layer.

[0109] S3. Data lineage

[0110] Atlas records the work order data processing link (such as KafkaTopic→SparkJob→PaimonTable) to achieve full-link auditing.

[0111] 4. Early warning feedback module;

[0112] 1. Dynamic injection of SLA thresholds

[0113] S1.Threshold configuration synchronization;

[0114] Set SLA thresholds (such as a maximum delay of 60 seconds for work order release and an API success rate greater than or equal to 99.9%). SLA thresholds are usually stored in an external system (MySQL, ZooKeeper) and dynamically loaded into the early warning module through a broadcast stream.

[0115] S2. Hot update of rules

[0116] When the SLA is adjusted (for example, from 60 seconds to 30 seconds), the new threshold is delivered in real time via a broadcast stream and takes effect in the next time window without restarting the job.

[0117] Implementation logic: Access BroadcastState in the window function to obtain the latest threshold.

[0118] 2. Tiered alarm triggering

[0119] S1. Multi-level threshold judgment

[0120] When the delay is less than the threshold, there is no alarm;

[0121] When the value is greater than or equal to the threshold, the system integrates SMS / email / APP multi-channel real-time push notifications.

[0122] S2. Compound condition detection

[0123] Combine time window statistics with event sequence matching, for example:

[0124] Three consecutive windows timeout (to prevent occasional fluctuations and false alarms)

[0125] Missing critical path events (e.g., order success event not triggered within 30 minutes)

[0126] 3. Closed-loop feedback on SLA indicators

[0127] S1. Monitoring data transmission

[0128] Report processing delay, throughput and other indicators to Prometheus in real time through Flink's built-in indicator system (such as LatencyTracker).

[0129] S2. Adaptive Optimization

[0130] Dynamically adjust processing resources: Automatically scale TaskManager instances based on SLA compliance (e.g., p99 latency exceeding the limit) through the Kubernetes API.

[0131] Flow control policy linkage: When the threshold is exceeded, the flow control rules are triggered (such as reducing the priority of non-core tasks).

[0132] 4. Fault tolerance and consistency assurance

[0133] State consistency: The checkpoint mechanism ensures atomic synchronization of SLA threshold updates and event processing states;

[0134] Exactly once alerting: Cooperate with downstream notification systems (such as Kafka) to avoid repeated alerting due to fault recovery.

[0135] The present invention has the following advantages:

[0136] 1. Support customers to quickly and independently create work orders, control the progress of fault operation and maintenance, simplify the operation and maintenance processing process through the work order system, form an automated operation and maintenance processing mechanism, and assign responsibilities to individuals at each node of the processing process for rapid response.

[0137] 2. Improve work efficiency: The work order system realizes digital management through automation and standardized processes, greatly reducing the time-consuming cost of offline communication and improving operation and maintenance efficiency.

[0138] 3. Optimize resource utilization management: Through intelligent allocation and scheduling functions, the work order system can rationally allocate human, material and time resources, avoid resource waste, and achieve high-quality management and control.

[0139] 4. Improve work transparency and quality: The work order system makes the workflow transparent and traceable, helping managers monitor work progress and quality in real time, and identify and resolve problems in a timely manner.

[0140] 5. Optimize customer service: Customer questions and requests can be immediately recorded and assigned to the corresponding operation and maintenance team members, quickly responding to customers and providing accurate and timely solutions to enhance customer satisfaction.

[0141] 6. After-sales service management: The work order system can effectively record and manage customers' after-sales needs and improve the quality of after-sales service.

[0142] In the present invention, terms such as "installed," "connected," "connected," and "fixed" should be understood broadly. For example, "connected" may refer to a fixed connection, a detachable connection, or an integral connection; and "connected" may refer to a direct connection or an indirect connection via an intermediary. Those skilled in the art will understand the specific meanings of the above terms in the present invention based on specific circumstances.

[0143] In the description of the present invention, it should be understood that the terms "inside" and "outside" and the like indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or unit referred to must have a specific direction, be constructed and operated in a specific orientation. Therefore, they should not be understood as limitations on the present invention.

[0144] Throughout this specification, terms such as "one embodiment," "some embodiments," and "specific embodiments" mean that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of the present invention. In this specification, schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0145] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Those skilled in the art will readily appreciate that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A distributed work order management system based on intelligent dispatching, characterized in that: include: The organizational structure engine module adopts a parent-child node tree structure, dividing the operation and maintenance areas into three levels: province, city, and district. The nodes are bound to the authority level of the regional person in charge; The intelligent dispatch module generates dispatch priority weights based on maintenance area, station location, and personnel availability, and automatically matches work orders with maintenance personnel through a preset algorithm. The data analysis module collects work order data in real time to generate multi-dimensional analysis charts, predicts regional failure probability through machine learning, and generates preventive maintenance recommendations; The early warning feedback module sets SLA thresholds and automatically escalates overdue work orders to alarms.

2. The distributed work order management system based on intelligent dispatching according to claim 1 is characterized in that: The organizational structure engine module adopts the RD-Tree data structure, dynamically covering the three-level nodes of provinces, cities, and districts across the country. Each node stores regional managers, available operation and maintenance personnel, and equipment distribution metadata.

3. The distributed work order management system based on intelligent dispatching according to claim 2 is characterized in that: The intelligent dispatching module uses a dynamic optimization algorithm based on geographic location weights. The algorithm calculation formula is as follows: ; Where: W is the optimal operation and maintenance personnel; D is the real-time distance between the site and the operation and maintenance personnel; S is the skill matching degree; R is the historical response speed; C is the bidding weight.

4. The distributed work order management system based on intelligent dispatching according to claim 3 is characterized in that: The data analysis module constructs an LSTM neural network, inputs historical fault data, and outputs a regional fault probability heat map.

5. The distributed work order management system based on intelligent dispatching according to claim 4 is characterized in that: The data analysis module uses Apache Spark Structured Streaming as the core stream processing framework, combined with Kafka as a message queue, to achieve low-latency transmission and persistent buffering of work order data; The core process framework includes an acquisition layer, a processing layer, a storage layer, and an analysis layer.

6. The distributed work order management system based on intelligent dispatching according to claim 5, characterized in that: The collection layer collects work order data sources in real time through Flume or KafkaConnect; The processing layer runs predefined processing logic through the Spark engine and writes the calculation results to the storage layer; The analysis layer provides an SQL interface through Hive or StarRocks, supporting business personnel to query real-time statistical indicators of work orders by themselves.

7. The distributed work order management system based on intelligent dispatching according to claim 6, characterized in that: The stream processing logic of the stream processing framework is window aggregation, state management, anomaly detection and data persistence.

Images