An alarm and work order handling platform device and method for an intelligent operation and maintenance system
Patent Information
- Application Number
- CN202610509455.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-04-17
- Publication Date
- 2026-08-18
AI Technical Summary
[0004]本发明的目的在于克服现有技术的上述缺陷,提供一种用于智能运维系统的报警与工单处置平台装置及方法,基于 uni-app 框架实现跨平台统一适配,系统性解决现有运维系统开发效率低、用户体验不一致、硬件调用受限、告警推送实时性差、报警与工单数据流转不规范、个性化配置能力弱等核心问题,实现告警信息的低延迟推送、报警到工单的自动化结构化转换、工单的全生命周期精细化管理,同时提升运维数据的可视化展示能力和系统的个性化适配能力,最终提高智能运维的响应速度与协同处理效率
1.实现跨平台统一开发,大幅降低开发与维护成本:基于 uni-app 跨平台开发框架结合 UnoCSS 样式适配机制,实现一套代码在微信小程序、H5、Android、iOS 及鸿蒙Next 等多个平台无缝运行,无需为各平台单独开发代码和编写样式,从根本上解决了传统原生开发代码复用率低、多端维护困难的问题,显著提升开发效率,降低开发与后续维护成本;
Smart Images

Figure CN122601435A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of intelligent operation and maintenance technology, and more specifically, to an alarm and work order processing platform device and method for intelligent operation and maintenance systems. Background Technology
[0002] In the field of intelligent operations and maintenance (O&M), mobile O&M management systems have become a key vehicle for improving O&M efficiency and achieving rapid fault response. Existing mobile O&M systems mainly adopt three technical solutions: native development, web development (H5), or hybrid development. Among them, the native development model develops code separately for different operating systems such as iOS, Android, and HarmonyOS. Although it can ensure system performance and native experience, it suffers from low code reusability, difficulty in synchronizing logic across multiple devices, and high development and maintenance costs. The web development model runs based on a browser and cannot deeply utilize the hardware capabilities of mobile devices such as cameras and GPS. In high-concurrency alarm push scenarios, the reliance on polling mechanisms leads to high message latency and poor data real-time performance, making it difficult to meet the real-time requirements of O&M. Although the hybrid development model enables a single codebase to run on multiple devices, it still has significant shortcomings in performance and native experience and cannot adapt to complex O&M operation scenarios.
[0003] Furthermore, existing operation and maintenance (O&M) systems have significant deficiencies in the collaborative handling of alarms and work orders. During the transfer of fault information from alarms to work orders, manual input or simple field copying is often relied upon, lacking standardized and structured data mapping protocols. This easily leads to problems such as lost fault information and inconsistent formats, directly impacting the efficiency and accuracy of O&M responses. Simultaneously, existing systems suffer from weak data visualization capabilities and low customization options. They cannot customize the user interface according to the roles or business needs of O&M personnel, and struggle to achieve multi-dimensional dynamic display of O&M data such as device status, alarm distribution, and work order processing progress, failing to provide efficient data analysis support for O&M decisions. In summary, the shortcomings of existing intelligent O&M systems in development efficiency, multi-terminal adaptation, real-time performance, data collaboration, and functional flexibility have become key issues hindering the improvement of intelligent O&M capabilities. Summary of the Invention
[0004] The purpose of this invention is to overcome the aforementioned deficiencies of the prior art and provide an alarm and work order processing platform device and method for intelligent operation and maintenance systems. Based on the uni-app framework, it achieves unified cross-platform adaptation and systematically solves the core problems of existing operation and maintenance systems, such as low development efficiency, inconsistent user experience, limited hardware access, poor real-time alarm push, non-standard alarm and work order data flow, and weak personalized configuration capabilities. It realizes low-latency alarm information push, automated and structured conversion of alarms to work orders, and refined management of the entire lifecycle of work orders. At the same time, it improves the visualization capabilities of operation and maintenance data and the personalized adaptation capabilities of the system, ultimately improving the response speed and collaborative processing efficiency of intelligent operation and maintenance.
[0005] To achieve the above-mentioned objectives, the present invention adopts the following technical solution: An alarm and work order processing platform device for intelligent operation and maintenance systems Built on the uni-app framework, this device features a unified cross-platform architecture that adapts to various terminal platforms including WeChat Mini Programs, H5, iOS, Android, and HarmonyOS. The device consists of a three-layer architecture: a front-end application layer, a core business layer, and a back-end data layer. The front-end application layer interacts with the core business layer via HTTP / WebSocket protocols, while the core business layer and back-end data layer handle data reading, writing, and persistence. The functional modules of each layer work together to provide core operational functions such as real-time alarm processing, work order management, and data visualization. 1. Front-end application layer: It is a multi-platform adapted application developed based on uni-app. It can be compiled into WeChat mini program, H5 page, iOS / Android / HarmonyOS APP. It supports drag-and-drop interface layout and functional module customization mechanism, and can realize personalized workbench configuration of "a thousand people with a thousand faces". It also integrates ECharts visualization library, has map positioning and trajectory playback capabilities, and can realize multi-dimensional dynamic display of operation and maintenance data. 2. Core Business Layer: As the core processing unit of the device, it includes a real-time communication engine, a visualization engine, an alarm processing engine, and a work order management engine. The real-time communication engine uses WebSocket to establish a long-term connection channel, combined with heartbeat detection, automatic reconnection after disconnection, and a local caching mechanism based on uni-app Storage, to ensure low-latency push and reliable delivery of key information such as alarms and work orders. The visualization engine provides runtime support for the ECharts visualization library, realizing the parsing and visualization of operation and maintenance data. The alarm processing engine realizes the reception, classification, retrieval of alarm information and linkage with the work order management engine. The work order management engine builds a complete work order lifecycle management system, realizing the entire process of work order creation, assignment, processing, querying, cancellation, and deletion. 3. Backend Data Layer: Provides data storage and management support for the device, including the device / monitoring database, alarm event database, and work order database. These are used to store device operation monitoring data, full alarm event data, and work order lifecycle data, respectively, to achieve classified and persistent storage of various types of operation and maintenance data, while also supporting efficient data read and write for the core business layer.
[0006] Furthermore, the cross-platform unified adaptation architecture is equipped with the UnoCSS style adaptation mechanism. It automatically determines the platform type through the UNI_PLATFORM environment variable. For mini-program platforms (starting with mp), it uses presetApplet() and presetRemRpx() presets to automatically convert atomic styles to 32rpx units. For non-mini-program platforms, it uses presetUno() and presetAttributify() presets to automatically convert atomic styles to 1rem units, achieving pixel consistency across different platforms. At the same time, it calls CSS variables such as env(safe-area-inset-top) and env(safe-area-inset-bottom) through custom UnoCSS rules to achieve automatic adaptation to device notch screens and bottom safe areas. Moreover, this mechanism adopts the atomic CSS design concept, supports icon library integration and CSS directive conversion, and realizes modular management and reuse of styles.
[0007] Furthermore, a structured alarm-to-work-order data conversion protocol is established between the alarm processing engine and the work order management engine, supporting automated mapping of alarm information to fault work order data, and supporting both single-item and batch conversion processing modes. The work order management engine is constructed with three major modules: fault work orders, temporary work orders, and historical work orders, which can realize the full lifecycle management of work orders, including creation, assignment, processing, viewing details, cancellation, and deletion. The preset work order status flow path is: Pending → Assigned → Completed, and it also supports Invalid and Deleted operations.
[0008] Furthermore, the work order database in the backend data layer is configured with multi-dimensional query interfaces, supporting filtering by multiple conditions such as line, site, system type, work order type, work order status, and time range. It also supports paginated queries and historical record backtracking. It is also configured with work order assignment interfaces and work order processing record interfaces, which respectively realize the fine-grained task distribution of work orders and the recording and storage of key information in the processing process.
[0009] A method for alarm and work order processing in intelligent operation and maintenance systems Based on the aforementioned platform device, the specific steps include: 1. Cross-platform adaptation and deployment: Based on the uni-app framework, a unified code foundation is written. The API differences of different operating systems are handled through conditional compilation and platform abstraction layer. Combined with the UnoCSS style adaptation mechanism, the style and function adaptation of mini-programs, H5, iOS, Android and HarmonyOS terminal platforms are completed, realizing the seamless operation of a set of code on multiple terminal platforms without the need to develop code and write styles separately for each platform. 2. Real-time Alarm Reception and Processing: A two-way real-time communication is established between the server and the mobile device via a WebSocket long connection channel to receive real-time alarm information generated by the device. Combined with Elasticsearch, historical alarm data is indexed and efficiently retrieved, enabling categorized display and multi-dimensional retrieval of alarm information. When the device is offline, alarm messages are cached locally in a uni-app Storage-based storage module. Once the network is restored, the cached messages are automatically synchronized to the server, ensuring that alarm information is not lost. 3. Automatic conversion of alarms to work orders: Based on a structured alarm-to-work-order data conversion protocol, standardized mapping of alarm fields and work order fields is performed, and alarm data is converted into standard work order data according to the mapping rules; a unique number is generated for each work order through an automatic generation algorithm, and preset status fields are initialized for newly created work orders; the converted work order data is submitted to the backend work order system via HTTP POST protocol. After the backend completes data validity verification and format conversion, the work order data is uniformly stored in the work order database, awaiting assignment and processing; 4. Full Lifecycle Management of Work Orders: After receiving work order data, the backend work order system initializes the work order to a Pending status. Maintenance personnel assign the work order to designated personnel or work teams via the work order assignment interface, and the work order status is updated to Assigned. Personnel execute work order processing operations at the frontend application layer and record key information during the processing process through the work order processing record interface. Once the work order is processed, the status is updated to Completed, forming a closed loop for work order handling. Simultaneously, the system supports work order cancellation, deletion, return / reassignment operations, enabling full-process tracking and management of work order status. 5. Visualization of Operation and Maintenance Data: The visualization engine at the front-end application layer retrieves operation and maintenance data such as device status, alarm distribution, and work order processing progress from the back-end data layer. Through the ECharts visualization library combined with map positioning and trajectory playback capabilities, it realizes multi-dimensional dynamic display of operation and maintenance data. Operation and maintenance personnel can customize the front-end interface layout and functional modules according to their own roles or business needs through drag-and-drop operations. It also supports switching between dashboard and large screen modes to realize personalized workbench configuration.
[0010] Furthermore, the standardized mapping relationship between the alarm field and the work order field in step 3 is as follows: line_name→lineName (line name), area_name→station (station / train number), dev_type→devType (system type), summary_info→faultReason (fault cause), alarm_time→faultTime (fault occurrence time), detail_content→comments (comments information).
[0011] Furthermore, the format for generating the work order number in step 3 is: prefix + 14-digit year, month, day, hour, minute, second + 3-digit random number. The prefix is either FAULT or TEMP, corresponding to fault work orders and temporary work orders respectively, to ensure the uniqueness and traceability of the work order number.
[0012] Furthermore, the initialization preset fields for the newly created work order in step 3 include: orderType is set to fault_order (fault work order) or temp_order (temporary work order) according to the alarm type; assignStatus is unassigned (unassigned) by default; and orderStatus is Pending (pending processing) by default, thereby achieving standardized initialization of work order status.
[0013] Furthermore, the key information in the processing procedure described in step 4 includes the processing mode (processMode), processing guide (processGuide), completion time (completeTime), and replaced device number (replacedDeviceId), to ensure the traceability and integrity of the work order processing procedure.
[0014] Furthermore, the specific adaptation process of the UnoCSS style adaptation mechanism described in step 1 is as follows: The platform type is automatically identified through the UNI_PLATFORM environment variable. For the mini-program platform, presetApplet() and presetRemRpx() are used to convert atomic styles to 32rpx units. For non-mini-program platforms, presetUno() and presetAttributify() are used to convert atomic styles to 1rem units. At the same time, CSS variables such as env(safe-area-inset-top) and env(safe-area-inset-bottom) are used to achieve automatic adaptation of the device safety area, ensuring that the interface is displayed completely on different devices.
[0015] By adopting the technical solution of the present invention, the following beneficial effects can be achieved: 1. Achieve unified cross-platform development and significantly reduce development and maintenance costs: Based on the uni-app cross-platform development framework and the UnoCSS style adaptation mechanism, a single codebase can run seamlessly on multiple platforms such as WeChat Mini Programs, H5, Android, iOS, and HarmonyOS Next. There is no need to develop separate code and styles for each platform, which fundamentally solves the problems of low code reusability and difficult multi-platform maintenance in traditional native development, significantly improving development efficiency and reducing development and subsequent maintenance costs. 2. Improve the real-time performance and reliability of alarm push notifications to ensure no loss of operation and maintenance information: A two-way real-time communication channel is established using WebSocket long connection technology. Combined with heartbeat detection, automatic reconnection after disconnection, and local caching mechanism, alarm information is pushed in milliseconds. This solves the message delay problem caused by the traditional Web development polling mechanism. At the same time, the local cache during network outages and the automatic synchronization after network recovery ensure that key information such as alarms and work orders are delivered reliably without loss. 3. Achieve automated and structured conversion of alarms to work orders to improve operation and maintenance response speed: Through a standardized alarm-to-work-order data conversion protocol, the system automatically maps alarm information to work order data and performs single / batch conversion, replacing the traditional manual entry or simple field copying method. This ensures data semantic consistency, avoids information loss or inconsistent formats, simplifies the operation process for operation and maintenance personnel, and achieves a rapid response closed loop from alarm to work order handling. 4. Construct a complete work order lifecycle management system to achieve refined and traceable management: By dividing work orders into three modules—fault work orders, temporary work orders, and historical work orders—and combining them with preset work order status flow paths, the system enables full lifecycle management of work orders from creation, assignment, processing to completion, cancellation, and deletion. Simultaneously, the configuration of multi-dimensional query interfaces, work order assignment interfaces, and processing record interfaces enables refined task distribution, multi-condition retrieval, and full recording of the processing process, ensuring the mobility, standardization, and traceability of the fault handling process. 5. Enhance system's personalized configuration capabilities and data visualization level to assist in rapid decision-making in operations and maintenance: Support drag-and-drop personalized workbench configuration, allowing operations and maintenance personnel to customize interface layout and functional modules according to roles or business needs, achieving a "personalized" operating interface; at the same time, integrate the ECharts visualization library with map positioning and trajectory playback capabilities to achieve multi-dimensional dynamic display of operations and maintenance data such as device status, alarm distribution, and work order processing progress, providing efficient data analysis support for rapid decision-making by operations and maintenance personnel; 6. Optimize mobile interaction experience and improve operation and maintenance efficiency: Reduce mobile operation and maintenance latency through preloading and local caching mechanisms. The front-end application layer features tabbed work order display, pull-to-refresh / pull-to-load, saving of filter conditions, and integrated operation of details page, which optimize the interaction logic and operation experience of mobile terminals. At the same time, the implementation of functions such as batch assignment and batch processing further improves the operation efficiency of operation and maintenance personnel. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings will be briefly introduced below. Obviously, the drawings described below are only three embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 This is a diagram showing the overall system architecture and data flow of the platform device of the present invention; Figure 2 This is a flowchart illustrating the automatic conversion process from alarm to work order in this invention. Figure 3 This is a flowchart of the entire lifecycle status of a work order in this invention. Detailed Implementation
[0018] To make the objectives, technical solutions, and beneficial effects of this invention clearer, the invention will be further described in detail below with reference to specific embodiments and comparative examples. These embodiments are only for explaining the invention and are not intended to limit the scope of protection of this invention. All equivalent modifications based on the technical solutions of this invention fall within the scope of protection of this invention.
[0019] Example 1
[0020] This embodiment is a concrete implementation of an intelligent operation and maintenance system alarm and work order processing platform device and method based on the example content of the disclosure document. The core is built around three major modules: cross-platform style adaptation, alarm-to-work order data conversion protocol, and mobile work order management platform. The specific implementation is as follows: 1.1 Cross-platform style adaptation implementation Based on the uni-app framework and equipped with the UnoCSS style adaptation mechanism, the terminal platform type is automatically identified through the UNI_PLATFORM environment variable. For the mini-program platform (starting with mp), the presetApplet() and presetRemRpx() presets are called to automatically convert atomic styles such as mt-4 to 32rpx units. For non-mini-program platforms such as H5, iOS, Android, and HarmonyNext, the presetUno() and presetAttributify() presets are called to convert the same atomic styles to 1rem units, so as to achieve pixel display consistency across different platforms.
[0021] By using custom UnoCSS rules to call CSS variables env (safe-area-inset-top) and env (safe-area-inset-bottom), it automatically adapts to the notch screen and bottom safe area of different devices, ensuring that the interface is unobstructed and fully displayed. It adopts atomic CSS design, replacing redundant code such as flex justify-centeritems-center with shortcut statements such as center. At the same time, it integrates an icon library and supports CSS directive conversion such as @apply and () grouping, reducing the amount of style code by more than 60%, realizing modular style management and reuse, and a single style configuration can adapt to all target platforms.
[0022] 1.2 Implementation of Alarm to Work Order Data Conversion Protocol Define a conversion protocol for structured JSON data format to automate and standardize the mapping of alarm information to work order data, while supporting single-item / batch conversion modes: 1. Field mapping: Strictly follow the mapping rules of line_name→lineName (line name), area_name→station (station / train number), dev_type→devType (system type), summary_info→faultReason (fault cause), alarm_time→faultTime (fault occurrence time), detail_content→comments (remarks information) to achieve semantically consistent conversion of alarm data to work order data; 2. Work order number generation: The algorithm uses a prefix + 14-digit year, month, day, hour, minute, second + 3-digit random number. The prefix for fault work orders is FAULT, and the prefix for temporary work orders is TEMP, generating a unique work order number such as FAULT20240615143052123. 3. Initial status settings: When a new work order is created, the orderType is automatically initialized to fault_order / temp_order, the assignStatus to Unassigned, and the orderStatus to Pending; 4. Data transmission: The converted work order data is submitted to the backend interface via the HTTP POST protocol, supporting batch submissions of up to 100 records at a time. After the backend completes the data validity verification, it is synchronized to the work order database.
[0023] 1.3 Implementation of Mobile Work Order Management Platform Composed of a front-end mobile application and a back-end service system, it enables full lifecycle management of work orders: Backend service system: Receives work order data via HTTP POST interface and stores it in the fault_work_order table. The default work order status flow path is Pending→Assigned→Completed, and it also supports Invalid and Deleted operations. It provides multi-dimensional query interfaces for line, site, system type, time range, etc., and is equipped with work order assignment interface and processing record interface to record assignment information and key processing information such as processMode, processGuide, completeTime, and replacedDeviceId. The front-end mobile application uses a tabbed interface divided into three main modules: "Fault Work Orders," "Temporary Work Orders," and "Historical Work Orders." Key information such as work order number, line, and fault cause are displayed in card format, supporting pull-to-refresh and pull-to-load. It provides entry points for all operations, including creation, assignment, and processing, and dynamically displays available operations based on the work order status, supporting batch assignment / processing. Multi-dimensional filtering conditions can be saved as frequently used items, and work order details are displayed in pop-up windows, supporting direct execution of processing operations from the details page, achieving integrated "view-operation."
[0024] This embodiment is applied in a real-world intelligent operation and maintenance scenario for rail transit, enabling a single codebase to adapt to WeChat Mini Programs, Android Apps, HarmonyOS Next Apps, and H5 pages. The development cycle is shortened by 70% compared to native development, and maintenance costs are reduced by 65%. The conversion time from alarm to work order is ≤1 second, and the batch conversion time for 50 alarm messages is ≤3 seconds. There is no loss of fault information and no format deviation in the flow of fault information. The response speed of work order processing is improved by 50%, the entire processing process can be traced, and the operation efficiency of operation and maintenance personnel is improved by 40%.
[0025] Example 2
[0026] This embodiment is a specific implementation of the invention's innovative points in real-time communication and alarm processing. Based on Embodiment 1, it enhances the real-time push, reliable transmission, and efficient retrieval capabilities of alarm information, adapting to high-concurrency alarm scenarios. The specific implementation is as follows: 2.1 WebSocket Long-Connection Real-Time Communication Mechanism WebSocket technology is integrated into the real-time communication engine of the core business layer to establish a bidirectional long-lived connection channel between the server and the mobile device. A heartbeat detection mechanism is set up every 30 seconds. If no heartbeat is detected for three consecutive times, it is considered a disconnection, triggering automatic reconnection logic. The reconnection intervals are 1 second, 3 seconds, and 5 seconds respectively, with a maximum of 5 reconnections. Local caching is implemented based on uni-app's Storage. When the device loses network access, alarm information is automatically cached locally on the mobile device, with a maximum cache capacity of 1000 entries, arranged in reverse chronological order, with the newest alarm overwriting the oldest expired alarm. After the network is restored, the locally cached alarm information is automatically synchronized to the server via WebSocket. After synchronization is complete, the local cache is cleared to ensure that alarm information is not lost or duplicated.
[0027] 2.2 Elasticsearch Alarm Data Indexing and Retrieval All alarm data is synchronized to the Elasticsearch search engine, and multi-dimensional indexes are built by line, site, device type, alarm level, and alarm time to achieve efficient alarm data retrieval. The front-end application layer provides a multi-dimensional alarm search interface, supporting searches by single or multiple conditions, as well as fuzzy searches (such as fault cause keywords) and time range searches (such as the last 1 hour / 24 hours / 7 days). Search results are sorted in reverse chronological order by alarm time and support pagination. For high-concurrency scenarios, a batch alarm processing function is implemented, which can perform batch marking and batch work order generation operations on multiple alarms in the search results, supporting the processing of up to 200 alarms per batch.
[0028] This embodiment is applied to an intelligent operation and maintenance scenario in an industrial park. This scenario generates approximately 800 alarm messages per day, with 3-5 alarms per second during peak periods. Through the technical solution of this embodiment, alarm messages are pushed in milliseconds with a push latency of ≤200ms; after network outage and network recovery, the synchronization success rate of locally cached alarm messages is 100%; Elasticsearch retrieval response time is ≤500ms, and batch processing of 200 alarms takes ≤5s. Compared with the traditional polling mechanism of the web-based operation and maintenance system, the alarm response speed is improved by 90%, and there are no message delay or loss issues in high-concurrency scenarios.
[0029] Example 3
[0030] This embodiment is a specific implementation of the invention's innovative points regarding personalized configuration and data visualization. Building upon Embodiments 1 and 2, it achieves customized "personalized" operation and maintenance interfaces and multi-dimensional dynamic display of operation and maintenance data to assist in operation and maintenance decision-making. The specific implementation is as follows: 3.1 Configurable personalized workbench The front-end application layer features a drag-and-drop custom layout function. Operations personnel can freely drag, add, delete, and sort functional modules of the workbench according to their roles (such as administrators, frontline operations personnel, and technical leads) and business needs. Supported functional modules include: real-time alarm dashboards, work order pending statistics, equipment status monitoring, data reports, and quick operation entry points. The workbench supports switching between dashboard and large screen modes. Dashboard mode is adapted for small mobile screens, focusing on core operations and key data; large screen mode is adapted for projection display in the operations center, displaying multi-dimensional operations data in full screen. It supports multi-terminal configuration synchronization, meaning that the workbench layout configured on one terminal is automatically synchronized to all logged-in terminals of that user. It also provides preset role templates for common roles such as administrators and frontline operations personnel, supporting one-click application and customization based on the templates.
[0031] 3.2 ECharts Multi-Dimensional Data Visualization Engine Integrating the ECharts visualization library and combining it with map positioning and trajectory playback capabilities, this system enables dynamic visualization of operational data. The core visualization modules include: Equipment status monitoring: Displays the online / offline / fault status percentage of all equipment using pie charts and bar charts, supports filtering by line and site, and allows you to view equipment details and historical fault records by clicking on the equipment icon; Alarm distribution display: The number of alarms at each site is marked on the electronic map, and different colors are used to distinguish the alarm levels (general, important, urgent). Clicking on a site will display the alarm details for that site. Work order processing progress: Displays the number of work orders created, processed, and completed using line charts and progress bars, with statistics by time dimension (hour / day / week), supporting work order processing efficiency analysis; Equipment trajectory playback: For mobile maintenance equipment (such as inspection vehicles and mobile testing terminals), its historical operating trajectory is played back on the map, and the correlation between faults and equipment operation is analyzed by combining the alarm markers on the trajectory.
[0032] All visualized data is refreshed in real time via WebSocket, with a customizable refresh rate (10s / 30s / 1min) to ensure that maintenance personnel see the latest data.
[0033] This embodiment is applied to the intelligent operation and maintenance scenario of urban transportation. It configures personalized workbenches for operation and maintenance personnel in different roles. The workbenches of front-line operation and maintenance personnel focus on work order processing and rapid alarm response, while the workbenches of technical leaders focus on data statistics and fault analysis. The core operation steps of operation and maintenance personnel are reduced by 50%. Multi-dimensional visualization displays enable operation and maintenance personnel to quickly locate alarm distribution and grasp the progress of work order processing, improving fault troubleshooting efficiency by 60% and significantly enhancing the scientific nature and timeliness of operation and maintenance decisions.
[0034] Comparative Example 1 This comparative example uses a traditional native development model to build an intelligent operation and maintenance alarm and work order processing system. Separate app code was developed for iOS, Android, and HarmonyOS, with separate development for the web and mini-program ends. The styles and functions of each end were written and maintained separately. Alarm push notifications use a polling mechanism, with the front end requesting alarm data from the server every 30 seconds, lacking a real-time communication channel. The conversion from alarm to work order relies on manual input; operation and maintenance personnel must manually fill in alarm information into the work order form, and work order numbers are manually generated. Work order management only supports basic creation and processing functions, lacking a standardized status transition mechanism. Data retrieval only supports single searches by work order number. The system lacks personalized configuration functions; all users use a unified interface, and data is displayed as a plain text list with no visualization capabilities.
[0035] This comparative example is applied in the same intelligent operation and maintenance scenario of rail transit as Example 1. The development cycle is more than 3 times that of Example 1. Synchronous updates of functions on iOS, Android, and HarmonyOS require separate code modifications, and the maintenance cost is 4 times that of Example 1. The alarm push delay is ≥30s, and message backlog is likely to occur during peak hours. The average time for converting alarms to work orders is ≥5min, and manual entry is prone to information errors and loss. The work order retrieval efficiency is low, there is no traceability of the processing process, and the operation efficiency of operation and maintenance personnel is reduced by 70% compared to Example 1, and the fault response speed is reduced by 80%.
[0036] Comparative Example 2 This comparative example uses the traditional hybrid development framework Cordova to build an intelligent operation and maintenance alarm and work order processing system, achieving multi-platform operation with a single codebase, compatible with iOS, Android apps, and H5 pages, but not currently supporting HarmonyOS and WeChat Mini Programs. It uses WebSocket + local storage for alarm push notifications, but lacks heartbeat detection and automatic reconnection mechanisms, making it prone to connection interruptions and alarm push failures during network fluctuations. Alarm-to-work-order conversion is a simple field copy and conversion without a standardized field mapping protocol, resulting in some mismatches between alarm and work-order fields requiring manual correction. Work order management provides basic full lifecycle management, but the front-end interaction is poor, lacking batch processing, filtering condition saving, and other functions. Data visualization uses static charts, requiring manual data refresh, and lacks map positioning and trajectory playback capabilities. The system supports simple function module hiding, lacks drag-and-drop custom layout, and cannot achieve a personalized workbench.
[0037] This comparative example was applied in the same intelligent operation and maintenance scenario in an industrial park as Example 2. Although it achieved multi-terminal operation of a single codebase, it did not support HarmonyOS and mini-programs, resulting in insufficient compatibility. The connection interruption rate reached 30% during network fluctuations, and the alarm push failure rate was about 25%. The conversion from alarm to work order required manual correction of about 30% of the fields, resulting in low batch conversion efficiency. Static chart visualization could not reflect operation and maintenance data in real time, the front-end operation experience was poor, the operation efficiency of operation and maintenance personnel decreased by 40% compared to Example 2, and the alarm processing success rate decreased by 20% compared to Example 2.
[0038] Based on the combined application effects of Examples 1-3 and Comparative Examples 1-2, the technical solution of the present invention is significantly superior to traditional technical solutions in terms of cross-platform adaptability, development and maintenance costs, alarm real-time performance, work order processing efficiency, personalized configuration, and data visualization. Specific core indicators are compared in the table below: Number of supported terminal platforms Mini Program + H5 + iOS + Android + HarmonyOS Separate platform development (iOS / Android / HarmonyOS) + standalone web H5 + iOS + Android (without HarmonyOS / Mini Programs) Development cycle reduction ratio ≥70% None (benchmark) ≥30% (Insufficient compatibility) Maintenance cost reduction ratio ≥65% None (benchmark) ≥20% (Difficulty in synchronizing logic across multiple devices) Alarm push delay ≤200ms (milliseconds) ≥30s (polling) ≥500ms (no disconnection and reconnection) Time taken to convert alarm to work order Single order ≤ 1s, batch of 50 orders ≤ 3s Each entry takes ≥5 minutes (manual entry). Single record ≤ 3s (30% of fields require manual correction) Increase in operational efficiency of maintenance personnel ≥40% None (benchmark) ≤10% (Poor user experience) Fault information loss rate 0% ≥15% (manual entry) ≥5% (Field mapping is not standard) Data visualization capabilities Multi-dimensional dynamic visualization + map positioning + trajectory playback Plain text list, no visualization Static charts, no real-time refresh / track playback Personalized configuration capabilities Drag-and-drop custom layout + multiple modes + character templates None, unified interface Simple module hiding, no custom layout As can be seen from the above comparison, this invention systematically solves the core problems of traditional intelligent operation and maintenance systems, such as low development efficiency, insufficient real-time performance, non-standard data flow, and low operational efficiency, by integrating technologies such as uni-app cross-platform architecture, WebSocket real-time communication, standardized alarm work order conversion, work order full lifecycle management, personalized workbench, and ECharts visualization. This significantly improves the response speed and collaborative processing capabilities of intelligent operation and maintenance.
[0039] In summary, Examples 1-3 fully realize the technical solution of the alarm and work order processing platform device and method for intelligent operation and maintenance systems of this invention from three core dimensions: cross-platform adaptation and implementation, real-time alarm processing optimization, and intelligent display of operation and maintenance data. They respectively verified the practical application effects and feasibility of key technologies such as cross-platform style adaptation, standardized alarm-work order conversion, mobile work order lifecycle management, WebSocket real-time communication, efficient Elasticsearch retrieval, personalized workbench configuration, and ECharts multi-dimensional visualization. The technical modules of each example can be deployed independently or integrated collaboratively, adapting to different intelligent operation and maintenance scenarios such as rail transit, industrial parks, and urban transportation. Significant technical breakthroughs have been achieved in shortening development cycles, reducing maintenance costs, improving alarm response speed, increasing work order processing efficiency, and assisting in scientific decision-making in operation and maintenance. This fully demonstrates the practicality, adaptability, and advancement of the technical solution of this invention, solving the core technical deficiencies of traditional operation and maintenance systems in terms of multi-terminal adaptation, real-time performance, data collaboration, and functional flexibility. It provides a feasible technical solution and implementation reference for the mobile, intelligent, and efficient development of the intelligent operation and maintenance field.
[0040] The scope of protection of this invention is not limited to the specific embodiments described above. All equivalent transformations made based on the technical concept and principles of this invention, or direct / indirect applications in other related technical fields, are similarly included within the scope of protection of this invention.
Claims
1. An alarm and work order processing platform device for an intelligent operation and maintenance system, characterized in that, The device is built on the uni-app framework to create a cross-platform unified adaptation architecture that is compatible with mini-programs, H5, iOS, Android and HarmonyOS terminal platforms. The device includes a front-end application layer, a core business layer and a back-end data layer. The front-end application layer interacts with the core business layer via HTTP / WebSocket to achieve data interaction, and the core business layer and the back-end data layer complete data reading, writing and data persistence. The front-end application layer is a multi-terminal application developed based on uni-app, which supports drag-and-drop interface layout and custom functional modules, integrates the ECharts visualization library and has map positioning and trajectory playback capabilities. The core business layer includes a real-time communication engine, a visualization engine, an alarm processing engine, and a work order management engine; The backend data layer includes a device / monitoring database, an alarm event database, and a work order database; The real-time communication engine uses WebSocket to establish a long-term connection channel, and combines heartbeat detection, automatic reconnection after disconnection and local caching mechanism to realize message transmission. The local cache is implemented based on uni-app's Storage.
2. The apparatus according to claim 1, characterized in that, The cross-platform unified adaptation architecture is equipped with the UnoCSS style adaptation mechanism, which automatically determines the platform type through the UNI_PLATFORM environment variable, and uses different style presets for mini-program platforms and non-mini-program platforms to achieve automatic conversion of atomic style units. At the same time, it achieves device safety area adaptation by calling CSS variables through custom UnoCSS rules, adopts atomic CSS design and supports icon library integration and CSS directive conversion.
3. The apparatus according to claim 1, characterized in that, The alarm processing engine and the work order management engine establish a structured data conversion protocol, which supports automatic mapping of alarm information to fault work order data and single-item and batch conversion processing modes. The work order management engine is built with three major modules: fault work orders, temporary work orders, and historical work orders, realizing full lifecycle management of work order creation, assignment, processing, viewing details, cancellation, and deletion.
4. The apparatus according to claim 1, characterized in that, The work order database in the backend data layer has a preset work order status flow path as follows: Pending → Assigned → Completed. It also supports Invalid and Deleted operations and is configured with a multi-dimensional query interface that filters by multiple conditions such as line, site, system type, work order type, work order status, and time range.
5. A method for alarm and work order processing in an intelligent operation and maintenance system, implemented based on the device described in any one of claims 1-4, characterized in that, Includes the following steps: S1. Cross-platform adaptation and deployment: Based on the uni-app framework, a unified code foundation is written. The API differences of different operating systems are handled through conditional compilation and platform abstraction layer. Combined with the UnoCSS style adaptation mechanism, the style and function adaptation of mini-programs, H5, iOS, Android and HarmonyOS terminal platforms are completed, so as to realize the operation of one set of code on multiple platforms. S2. Real-time alarm reception and processing: Establish bidirectional real-time communication between the server and the mobile terminal through a WebSocket long connection channel to receive real-time alarm information generated by the device, index and retrieve historical alarm data in conjunction with Elasticsearch, classify and display alarm information and perform multi-dimensional retrieval, cache alarm messages locally when the network is disconnected, and automatically synchronize them to the server after the network is restored. S3. Automatic conversion of alarms to work orders: Based on a structured alarm-to-work order data conversion protocol, it performs standardized mapping between alarm fields and work order fields, automatically generates a unique work order number, initializes preset fields for new work orders, and submits the converted work order data to the backend work order system via HTTP POST protocol. After completing data validity verification and format conversion, it is stored in the work order database. S4. Work Order Lifecycle Management: After receiving work order data, the backend work order system initializes the work order to a pending state. Through the work order assignment interface, the work order is assigned to a designated handler or work team and updated to an assigned state. The handler performs work order processing operations at the frontend application layer, records key information in the processing process, and updates the work order to a completed state after processing, forming a closed loop. It also supports work order cancellation, deletion, return / reassignment operations, realizing full-process tracking of work order status. S5. Operation and Maintenance Data Visualization: The ECharts visualization library integrated into the front-end application layer combines map positioning and trajectory playback capabilities to retrieve device status, alarm distribution, and work order processing progress data from the back-end data layer, achieving multi-dimensional dynamic display. Users can also customize the front-end interface layout and functional modules through drag-and-drop operations, and switch between dashboard and large screen modes.
6. The method according to claim 5, characterized in that, The standardized mapping relationship between the alarm fields and work order fields mentioned in step S3 is as follows: line_name→lineName (line name), area_name→station (station / train number), dev_type→devType (system type), summary_info→faultReason (fault reason), alarm_time→faultTime (fault occurrence time), detail_content→comments (comment information).
7. The method according to claim 5, characterized in that, The format for generating the work order number in step S3 is: prefix + 14-digit year, month, day, hour, minute, second + 3-digit random number. The prefix is either FAULT or TEMP, which correspond to fault work orders and temporary work orders, respectively.
8. The method according to claim 5, characterized in that, The initial preset fields for creating a new work order in step S3 include: orderType is set to fault_order (fault work order) or temp_order (temporary work order) according to the alarm type; assignStatus defaults to Unassigned (not assigned); and orderStatus defaults to Pending (pending processing).
9. The method according to claim 5, characterized in that, The key information in the processing procedure described in step S4 includes the processing mode (processMode), processing guide (processGuide), completion time (completeTime), and replaced device ID (replacedDeviceId).
10. The method according to claim 5, characterized in that, The adaptation process of the UnoCSS style adaptation mechanism described in step S1 is as follows: the mini-program platform uses presetApplet() and presetRemRpx() to convert atomic styles to 32rpx units, and the non-mini-program platform uses presetUno() and presetAttributify() to convert atomic styles to 1rem units. Device safety area adaptation is achieved through the CSS variables env(safe-area-inset-top) and env(safe-area-inset-bottom).