A mobile terminal digital billboard operation and maintenance data scene display method and system

Abstract

The present application relates to the field of data processing, and more particularly to a mobile terminal digitalized board operation and maintenance data scene display method and system, first, collecting equipment operation data and storing into operation and maintenance data center; constructing operation and maintenance scene feature library, defining data display strategy for different job types; obtaining the current context information of the user; using scene matching algorithm to identify the matching target job type from the feature library; according to the identification result, extracting the corresponding operation data, and displaying on the mobile terminal board in a hierarchical and interactive form according to the data display strategy of the job type; responding to the interactive operation of the user on the board, providing functions linked with operation and maintenance jobs. The present application enables the board to actively adapt to different job scenes such as inspection and repair, and improves the efficiency of on-site data acquisition and job collaboration.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and system for displaying operation and maintenance data scenarios on a mobile digital dashboard. Background Technology

[0002] Mobile maintenance dashboards have become an important tool for field operations in power information and communication systems. Maintenance personnel can use handheld terminals to view equipment status, performance indicators, and alarm information, supporting daily inspections, emergency repairs, and maintenance tasks. However, current mobile maintenance dashboards still have some shortcomings in matching data display with field operation needs. Most existing dashboards use relatively fixed data views, with little difference in content seen by all users or in most work scenarios. A few systems allow switching views based on user roles, but this switching logic is relatively simple and cannot accurately reflect what maintenance personnel are currently doing. Even among maintenance personnel, those conducting inspections are concerned with whether the basic equipment is functioning normally, while those performing emergency repairs are concerned with upstream and downstream related data and historical alarm records. The required data dimensions and display priorities are significantly different. Due to the lack of effective identification of the current work scenario, existing dashboards often simply pile up data, requiring users to manually search and filter, which is cumbersome and sometimes leads to missing crucial information.

[0003] Secondly, maintenance personnel are frequently interrupted by ad-hoc tasks. For example, while conducting a scheduled inspection, they might suddenly receive a Level 1 alarm from a critical device, requiring an immediate switch to emergency repair mode. With existing dashboards, information such as the previous browsing location, expanded details panels, and entered filter criteria are often lost after switching scenarios. Once the emergency is resolved and the personnel want to return to the original inspection progress, they have to relocate, sometimes even forgetting where they were in the previous view. This loss of context significantly impacts work efficiency in time-sensitive emergency repair scenarios. Summary of the Invention

[0004] To address one or more problems in the existing technology, the main objective of this application is to provide a method and system for displaying operation and maintenance data scenarios on a mobile digital dashboard.

[0005] To achieve the aforementioned objectives, this application proposes a method for displaying operation and maintenance data scenarios on a mobile digital dashboard, the method comprising: Collect operational data from devices in the information and communication system, and store the operational data in the operation and maintenance data center; Construct an operation and maintenance scenario feature library, which is used to define data display strategies corresponding to different job types; Obtain the user's context information in the current job scenario; calling a preset scene matching algorithm, and identifying a matched target job type for the context information from the feature library according to the scene matching algorithm; extracting corresponding operation data from the operation and maintenance data center according to the identified target job type, and displaying the data on a mobile dashboard in a hierarchical and interactive form according to a data display strategy corresponding to the target job type in the feature library; responding to an interactive operation of a user on the dashboard, and providing a function linked with operation and maintenance jobs.

[0006] an embodiment of the present application further provides an operation and maintenance data scene display system of a mobile digital dashboard, comprising: an acquisition module, configured to acquire operation data of devices in an information and communication system, and store the operation data in an operation and maintenance data center; a construction module, configured to construct an operation and maintenance scene feature library, wherein the feature library is used for defining data display strategies corresponding to different job types; an obtaining module, configured to obtain context information of a user in a current job scene; a calling and identifying module, configured to call a preset scene matching algorithm, and identify a matched target job type for the context information from the feature library according to the scene matching algorithm; an extraction module, configured to extract corresponding operation data from the operation and maintenance data center according to the identified target job type, and display the data on a mobile dashboard in a hierarchical and interactive form according to a data display strategy corresponding to the target job type in the feature library; a response module, configured to respond to an interactive operation of a user on the dashboard, and provide a function linked with operation and maintenance jobs.

[0007] the present application further provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of any one of the above methods when executing the computer program.

[0008] the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the steps of any one of the above methods when executed by a processor.

[0009] The mobile digital dashboard operation and maintenance data scenario display method and system of this application embodiment, by constructing an operation and maintenance scenario feature library and obtaining user context information in real time, can automatically identify the current job type of operation and maintenance personnel, such as inspection, emergency repair, or routine maintenance, and dynamically adjust the displayed data content, priority, and visualization form accordingly. This makes the dashboard no longer a dashboard piled with all data, but an intelligent guide tailored to on-site needs, reducing the risk of missing key information. Secondly, it adopts a hierarchical and interactive display method, taking into account both the needs of information overview and in-depth exploration. Important or urgent data is prioritized at the front layer, and users can drill down to obtain more detailed indicators and logs with simple clicks or swipes. At the same time, it supports horizontal switching within the same level to view different devices, achieving a smooth experience from macro to micro, and greatly improving the efficiency of information acquisition in on-site operations. Finally, it deeply integrates data display with operation and maintenance work processes. When users view alarm details in the dashboard, they can directly initiate work orders, and the system automatically fills in the device and alarm information, and supports real-time tracking of subsequent work order progress. This achieves a closed loop from problem discovery to problem resolution, avoiding frequent switching and repetitive data entry between multiple systems, effectively improving the overall efficiency and response speed of on-site operation and maintenance of the power information and communication system, and ensuring the stable operation of the system. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating a method for displaying operation and maintenance data scenarios on a mobile digital dashboard according to an embodiment of this application. Figure 2 This is a flowchart illustrating a method for displaying operation and maintenance data scenarios on a mobile digital dashboard according to an embodiment of this application. Figure 3 This is a schematic block diagram of the structure of a mobile digital dashboard operation and maintenance data scenario display system according to an embodiment of this application; Figure 4 This is a schematic block diagram of the structure of a computer device according to an embodiment of this application.

[0011] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0013] Reference Figure 1 This application provides a method for displaying operation and maintenance data scenarios on a mobile digital dashboard, the method comprising: S1. Collecting operation data of devices in an information and communication system, and storing the operation data in an operation and maintenance data center; S2. Constructing an operation and maintenance scenario feature library, wherein the feature library is configured to define data display policies corresponding to different operation types; S3. Acquiring context information of a user in a current operation scenario; S4. Calling a preset scenario matching algorithm, and identifying a matched target operation type for the context information from the feature library according to the scenario matching algorithm; S5. Extracting corresponding operation data from the operation and maintenance data center according to the identified target operation type, and displaying the extracted operation data in a hierarchical and interactive form on a mobile terminal dashboard according to the data display policy corresponding to the target operation type in the feature library; S6. Providing a function linked with operation and maintenance operations in response to an interactive operation of a user on the dashboard.

[0014] As described in steps S1-S3 above, this solution enables the mobile dashboard to proactively sense what tasks maintenance personnel are currently performing and dynamically adjust the content, priority, and format of the data display based on the task type. This transforms the dashboard from a static information dump into an intelligent assistant tailored to on-site needs. The following section presents a complete mixed inspection and repair scenario. S1 first uses a distributed data acquisition module deployed in the power information communication system to acquire real-time operating status data, performance parameters, and alarm information for various devices. Operating status data may include the online / offline status of devices, link connectivity, CPU and memory usage, etc. These devices may include servers, switches, routers, firewalls, etc. The collected data is often heterogeneous; different manufacturers and models of devices may use different data formats and transmission protocols. The system cleans this raw data, removing obviously abnormal or duplicate records, and then stores the standardized data in a unified format in the maintenance data center. The data center can be a centralized database or a distributed storage system to support subsequent rapid queries and analysis. This builds a high-quality, unified data foundation. Only when the data is accurate, complete, and consistent in format can the subsequent scenario-based display be reliable. Its effect is to provide raw materials for the entire method, ensuring that the data required for any type of operation can be quickly located and extracted. Step S2: Next, a feature library for operation and maintenance scenarios needs to be predefined. In the feature library, each type of operation corresponds to a preset feature template, which contains typical feature values ​​for dimensions such as geographical location, task identifier, and historical habits under that operation type. For example, the geographical location feature of an inspection operation can be set as the coordinate range of each substation area, the task identifier as inspection, and the historical habit feature can be obtained from historical inspection logs. The feature library can be constructed manually according to operation and maintenance procedures, or it can be automatically generated through cluster analysis of historical operation data. This feature library is designed for common operation types in power operation and maintenance sites, such as inspection operations, fault repair operations, and routine maintenance operations. For each type of operation, the feature library will be bound to a corresponding data display strategy. The data display strategy specifically includes: which equipment or indicator data should be filtered, what priority these data should be arranged, how many display levels should be divided, and which visualization components, such as indicator cards, line charts, bar charts, and topology diagrams, should be used for each level. For example, for routine inspections, the strategy might prioritize displaying a summary of the health status of all equipment, presented as green, yellow, and red cards, then sorted by equipment importance, and displaying detailed performance curves after drilling down. For emergency repairs, the strategy might prioritize displaying upstream and downstream correlation information of alarming equipment, highlighting the fault point in red, while placing historical similar alarm records alongside for reference. The principle behind building a feature library lies in making domain knowledge explicit and rule-based.The different data requirements of different job types are objectively real. Defining these differences in advance as configurable strategies, rather than hardcoding them into the code, gives the system strong flexibility and scalability. This provides a clear basis for subsequent scenario matching and dynamic display, and also allows operations teams in different regions to adjust strategies according to their own characteristics. In actual use, when operations personnel open the mobile dashboard, the S3 system automatically obtains a set of contextual information. This information includes, but is not limited to: the user's current geographical location (obtained through the mobile device's GPS or cell tower location), the type of job currently being executed (which can be read from the work order system or manually entered by the user), and the user's historical operating habits (e.g., which devices or metrics the user most frequently viewed in the past period, and the duration of time spent on each view). The purpose of obtaining this information is to allow the system to understand who the user is, where they are, what they are doing, and how they habitually view things. In principle, this is a multi-dimensional perception mechanism that transforms the on-site context that traditional dashboards cannot perceive into computable feature data. This makes the matching results no longer dependent on a single-dimensional judgment, but rather integrates multiple factors such as location, task, and habits, making them more accurate and personalized.

[0015] As described in steps S4-S6 above, after obtaining the context information in S4, the system calls a preset scene matching algorithm. This algorithm quantifies the extracted multi-dimensional features, such as geographical location, task type identifier, and historical habit statistics, and calculates the similarity with the preset feature template corresponding to each task type in the feature library. The similarity calculation for each dimension can employ various similarity measurement methods known in the field. For example, cosine similarity or Euclidean distance can be used for numerical features. The calculation considers the importance weights of each dimension, which can be initially set based on expert experience and dynamically adjusted based on the user's actual matching feedback. Finally, the task type with the highest comprehensive matching score is identified as the target task type that the user should currently activate. After determining the target task type, the identifier of that task type is passed as a parameter to the data display module. The data display module queries the corresponding data display strategy from the feature library based on this identifier and performs subsequent data extraction and rendering accordingly. For example, a user located at substation A has a work order system showing that he has scheduled an inspection task today, and his historical habits show that he frequently checks transformer temperature and load rate. After calculation, the system found that the matching score for "inspection operation" was much higher than that for "emergency repair operation," thus identifying inspection as the target operation type. The principle is to transform qualitative scenario judgment into a quantitative pattern recognition problem. Through weighted similarity comparison, the algorithm can handle incomplete information such as missing geographical locations and unclear task types, and continuously optimize the matching effect using historical feedback. Its effect is to achieve automatic mapping from the original context to the specific operation type, replacing the method of users manually selecting scenarios, reducing the operational burden, and avoiding data mismatch caused by human error in selecting the wrong scenario. Once the S5 determines the target operation type, it retrieves the data display strategy bound to that operation type from the feature library. First, according to the data filtering conditions defined in the strategy, it extracts the required operational data from the operations and maintenance data center. For example, an inspection operation may only require a health status summary of all devices, while an emergency repair operation requires detailed performance data of all devices on a certain link. Next, the system sorts the extracted data according to data priority sorting rules, placing data with high alarm levels, high device importance, or high user historical attention at the top. Then, based on the hierarchical structure definition, the sorted data is divided into multiple levels. For example, the first level is summary cards, the second level is detailed metrics for a specific device, and the third level is historical logs. Each level is bound to a visualization component type; for example, the first level uses status cards, the second level uses line charts, and the third level uses tables. Finally, the visualization view of the current highest level is rendered on the mobile screen, and interactive response interfaces are pre-defined for each data item. These interfaces allow users to perform operations such as data drill-down, horizontal switching between different devices at the same level, and triggering the display of alarm details through gestures such as clicking, long-pressing, and swiping. This achieves a shift from "data push" to "strategy-driven rendering."Data is no longer passively listed, but rather filtered, sorted, layered, and componentized according to the operational scenario, presented in a way best suited for on-site viewing and operation. This significantly reduces the cognitive burden on maintenance personnel searching for key information within massive amounts of data. During inspections, all equipment status can be seen at a glance; during emergency repairs, the fault point and impact range can be identified immediately; and during routine maintenance, performance indicators requiring attention can be quickly located. Simultaneously, the hierarchical and interactive design allows users to gain a comprehensive overview while delving into details as needed, balancing efficiency and depth. S6 users can not only view data on the dashboard but also perform various interactive operations. For example, when a user sees an alarm card and clicks to view details, the system displays detailed alarm information, including alarm content, occurrence time, associated equipment, and suggested handling measures. The system also supports a key linkage function: users can directly initiate a work order on the alarm details interface. The system automatically fills in the current equipment information and alarm content into the work order template, which is then submitted to the work order management platform after user confirmation. After successful submission, the work order number and current processing progress will be displayed on the Kanban board. Users can click to view the work order status at any time, and track the entire process from dispatched to processing to completed on the mobile Kanban board.

[0016] As mentioned above, by building an operation and maintenance scenario feature library and acquiring user context information in real time, the system can automatically identify the current job type of operation and maintenance personnel, such as inspection, emergency repair, or routine maintenance, and dynamically adjust the displayed data content, priority, and visualization format accordingly. This transforms the dashboard from a data-heaped instrument panel into an intelligent guide tailored to on-site needs, reducing the risk of missing critical information. Secondly, a hierarchical and interactive display method is adopted, balancing the needs for information overview and in-depth exploration. Important or urgent data is prioritized at the top, and users can drill down to obtain more detailed indicators and logs with simple clicks or swipes. It also supports horizontal switching between different devices within the same level, achieving a smooth experience from macro to micro, and significantly improving the efficiency of information acquisition in on-site operations. Finally, data display is deeply integrated with the operation and maintenance workflow. When users view alarm details in the dashboard, they can directly initiate a work order. The system automatically fills in the device and alarm information and supports real-time tracking of subsequent work order progress. This achieves a closed loop from problem discovery to problem resolution, avoiding frequent switching and repetitive data entry between multiple systems, effectively improving the overall efficiency and response speed of on-site operation and maintenance of the power information and communication system, and ensuring the stable operation of the system.

[0017] Reference Figure 2 In one embodiment, the step of invoking a preset scene matching algorithm and identifying the target job type from the feature library based on the context information according to the scene matching algorithm includes: S41. Extract feature information from multiple dimensions of the context information, including geographical location, task type identifier and historical operation habit statistics. S42. Based on the extracted feature information from multiple dimensions, configure the corresponding initial weight coefficients for the feature information of different dimensions, and adjust the weight coefficients of each dimension according to the user's historical matching feedback results. S43. Based on the adjustment results, the feature information of each dimension is weighted and similarity is calculated with the preset feature template corresponding to each job type in the feature library. The similarity contribution of each dimension is multiplied by the current weight coefficient corresponding to that dimension to obtain the comprehensive matching score of each job type. S44. Compare the job type with the highest overall matching score with the preset score threshold; S45. Based on the comparison results, if the highest score is greater than or equal to the preset score threshold, then the job type is determined as the target job type to be matched. S46. If the highest score is less than the preset threshold, return the default job type or prompt the user to manually select a job type.

[0018] As described in the steps above, this embodiment addresses how to accurately determine which job type should be activated at any given moment based on the user's current location, the task being executed, and past operating habits. The accuracy of this determination directly determines whether the subsequently displayed data is truly useful. Specifically, after the system obtains the user's context information in the current job scenario (S41), it first needs to extract feature information from multiple dimensions. Specifically, this includes at least three dimensions: the user's current geographical location, the currently executed job task type identifier, and the user's historical operating habit statistics. Geographical location: Mapping GPS coordinates to a predefined area code, such as a substation number, or calculating the distance to typical locations in each job template. Task type identifier: Directly using the enumerated value in the work order; if missing, it is set to empty. Historical habit statistics: Statistics on the number of times the user viewed various devices / indicators and the duration of their stay in the last N days, normalized to a preference vector between 0 and 1. This achieves the quantification of the three-dimensional feature values. Geographical location can be obtained through the positioning function of mobile devices, such as GPS coordinates or indoor positioning beacon numbers, which reflects which area of ​​the substation or which inspection route the user is on. The task type identifier can be read from the work order system. For example, if a user is assigned an inspection task for computer room number two today, the identifier will be "inspection." Historical operation habit statistics are calculated by the system after long-term recording of user behavior. For example, this includes which devices the user most frequently checks, which indicator pages they spend the most time on, and whether they frequently use the drill-down function. This data reflects the user's personal preferences and work patterns, transforming ambiguous on-site contexts into structured, computable features. Geographic location, task identifier, and operation habits represent environmental information, task information, and user preference information, respectively. These three complement each other, forming a complete basis for determining the task type. The importance of different S42 features in determining the task type is not fixed. For example, when the geographic location is very clear and perfectly matches the task order, the weight of location and task identifier can be set higher; however, in some indoor environments without GPS signals, geographic location features may be missing or inaccurate, in which case the weight of historical operation habits should be increased accordingly. Therefore, the system assigns an initial weight coefficient to each dimension, and these initial values ​​can be set based on expert experience or industry practices. More importantly, the system dynamically adjusts these weights based on user feedback for each matching result. Assuming a location matching score of 0.9, a task identifier matching score of 1.0, and a historical habit matching score of 0.6, with current weighting coefficients of 0.4, 0.3, and 0.3 respectively, the overall matching score is 0.9 × 0.4 + 1.0 × 0.3 + 0.6 × 0.3 = 0.84. If the preset threshold is 0.7, a successful match is considered achieved. Feedback can come from user confirmation of the automatic matching result or from the user manually modifying the task type.If the user modifies the job type in an automatically matched task, the system will appropriately reduce the weights of dimensions that led to incorrect judgments, while increasing the weights of other dimensions, making the next match more accurate. A lightweight adaptive learning mechanism is introduced. The dynamic adjustment of weight coefficients allows the matching model to continuously optimize with the increase in usage, gradually approaching the user's true intent in different scenarios. This overcomes the shortcomings of single static weights, which cannot adapt to individual differences and environmental changes, allowing the matching accuracy to gradually improve over time and with increased usage frequency. After obtaining the feature information for each dimension and the current weight coefficients, the system begins matching calculations. For each predefined job type in the feature library, such as inspection, emergency repair, and maintenance, the system has a corresponding preset feature template. This template describes the typical geographical location, task identifier, and approximate range of historical habit statistics for that job type. The currently extracted user feature information is compared dimension-by-dimensionally with the template for each job type, calculating the similarity in each dimension. For example, geographic location similarity can be calculated based on the distance between two coordinates; the closer the distance, the higher the similarity. Task identifier similarity is relatively simple: perfect match results in a perfect score, while mismatch results in a low score. Historical habit similarity compares the user's habit statistics with typical habit values ​​in the template. After obtaining the similarity for each dimension, it is multiplied by the current weight coefficient of that dimension, and then the weighted results of all dimensions are summed to obtain the comprehensive matching score for that task type. The task type with the highest score is the candidate type that the system considers most likely to match. By using a weighted summation method to integrate information from multiple dimensions, the final judgment has both quantitative basis and takes into account the differences in importance between different dimensions. Its effect is that it can handle incomplete information such as missing geographic location or ambiguous task identifiers. Even when information is insufficient, it can make reasonable judgments based on data from other dimensions such as historical habits, improving the robustness of the system. The highest comprehensive matching score calculated by S44 is not necessarily directly adopted. The system will also compare this score with a preset score threshold. This threshold can be understood as the system's minimum confidence requirement for its judgment results. If the highest score is greater than or equal to this threshold, it means the system has sufficient confidence that the match is correct, and this job type is then designated as the final target job type, with subsequent displays following this type. If the highest score is still less than the threshold, it means the current feature information is insufficient for the system to make a reliable judgment. This could be because the user is in a location they've never seen before, the work order task is unclear, and historical habits are lacking reference. In this case, the system will not force a low-confidence result but will instead adopt a safety net strategy: either returning a default job type, such as the most common inspection, or directly prompting the user on the interface to manually select the current job type.The results of user-manual selections are recorded and used as training data for subsequent weight adjustments. A balance is struck between automatic matching and reliability control. A threshold is designed so that the system only switches automatically when confident, and reverts to manual confirmation when uncertain. This leverages the convenience of automation while avoiding the negative experience caused by incorrect matching. The effect is to reduce the risk of mismatches and ensure that the system continues to function predictably even with insufficient information or abnormal environments, preventing the display of completely irrelevant data due to an incorrect scenario judgment.

[0019] In one embodiment, the step of extracting corresponding operational data from the operations and maintenance data center and displaying it on a mobile dashboard in a hierarchical and interactive manner according to the data display strategy corresponding to the target job type in the feature library includes: Based on the identified target job type, a data display strategy bound to the target job type is obtained from the feature library. The data display strategy includes data filtering conditions, data priority sorting rules, hierarchical structure definition, and visualization component types corresponding to each level. Based on the data filtering criteria, operational data that meets the criteria is extracted from the operation and maintenance data center as the dataset to be displayed; According to the data priority sorting rules, the data items in the dataset to be displayed are sorted by importance to generate an ordered data list; Based on the hierarchical structure definition, the ordered data list is divided into multiple display levels, and a corresponding visualization component type is bound to each level; Based on the partitioning results, render the current highest-level visualization view on the mobile dashboard and pre-set interactive response interfaces for each data item; In response to a user's interactive operation on a data item in the current view, the system performs the corresponding view or information update based on the type of the interactive operation and provides functionality to link with operation and maintenance tasks.

[0020] As described above, step one first retrieves the data display strategy bound to the target job type identified in the previous step, such as inspection or emergency repair, from the pre-built operation and maintenance scenario feature library. A complete data display strategy includes at least four elements: data filtering conditions, data priority ranking rules, hierarchical structure definition, and the visualization component type corresponding to each level. Data filtering conditions specify which devices or indicators' data should be extracted. For example, an inspection job only needs a summary of the health status of all devices, while an emergency repair job requires detailed performance data of the faulty device and all its upstream and downstream related devices. Data priority ranking rules define the method for comparing the importance of data items; for example, devices with higher alarm levels are ranked first, and core layer devices are more important than access layer devices. The hierarchical structure defines how the data is organized into several display levels; for example, the first level is an overview card, the second level is a detailed indicator panel for a specific device, and the third level is a historical log list. The visualization component type specifies what graphics or controls are used to present the data at each level, such as dashboards, line charts, bar charts, topology diagrams, or tables. By decoupling job types from specific display parameters, the display logic can be flexibly configured without code modification. The effect is that one display scheme is implemented for each job type, and the display schemes for different job types can be adjusted independently without affecting each other. After clarifying the display strategy in step two, the system queries and extracts operational data that meets the data filtering conditions defined in the strategy from the operations and maintenance data center. Filtering conditions can be device type ranges, list of indicator names, time intervals, alarm level thresholds, etc. For example, for inspection jobs, filtering conditions might be the current health status values ​​of all online devices and key performance indicators within the last fifteen minutes. For emergency repair jobs, filtering conditions might be further limited to real-time operational data of all devices on the link where the faulty device is located and alarm records from the past hour. The system executes database queries or calls data service interfaces, returning the result set as the dataset to be displayed. The principle of this step is to significantly reduce the amount of data through conditional filtering, retaining only the data truly relevant to the current job and avoiding irrelevant information from interfering with the user. This makes the data scale controllable for subsequent sorting, layering, and rendering processing, while also improving the response speed of mobile devices. The dataset extracted in step three typically contains multiple data items, such as health status cards for dozens of devices or hundreds of performance metric records. Directly displaying this data would require users to search for key information, which is inefficient. Therefore, the system prioritizes all data items in the dataset according to the data priority rules defined in the strategy, generating an ordered list from most important to least important. The ranking rules can consider multiple factors. For example, devices with the highest alarm levels are ranked first, and within the same alarm level, core switches are ranked higher than access switches based on their importance score.For data items without alerts, the system can also refer to the user's historical attention frequency, with frequently viewed devices appearing at the top. After sorting, the top of the list contains the data items that the user should focus on most in the current work scenario. This makes the dashboard no longer a simple list of data, but actively highlights the most valuable information. The effect is that users can see the most critical data at a glance when they open the dashboard, greatly reducing scanning and searching time. The ordered data list obtained after sorting in step four may still contain many items, and it is neither possible nor necessary to display them all on a single screen on a mobile device. Therefore, the system will divide the list into multiple display levels according to the hierarchical structure defined in the strategy. The principle of division is usually: the fewest data items with the highest priority are placed in the first level as an initial summary; slightly less important data items are placed in the second level, requiring users to click to drill down to see them; more detailed historical data or raw logs are placed in the third level or even deeper. For each display level, the strategy also defines which type of visualization component should be used. For example, the first level uses status cards, with colors representing health levels; the second level uses line charts to show the trend of indicators over time; and the third level uses tables to list detailed event records. The system records these binding relationships for use in subsequent rendering. A hierarchical design balances the need for information overview and in-depth exploration. The first layer provides a global view for quick judgment, while subsequent layers load details as needed, avoiding information overload. Users can grasp the overall situation at a glance and delve into any details of interest when needed, with a smooth transition between the two. Step five now begins the actual rendering of content on the mobile screen. It retrieves the highest-level division, usually the first layer, and obtains the type of visual component bound to that layer, such as a status card. Then, it extracts the data items belonging to the first layer from the ordered data list and renders the visual graphics or controls according to the component type requirements. For example, each device is displayed as a card containing the device name, health status, key indicator values, and a red, yellow, and green background color. While rendering each data item, the system pre-sets a set of interactive response interfaces for that data item. These interfaces can be triggered by user actions such as tapping, long-pressing, and swiping. Common interactive interfaces include: drill-down to sub-level data (e.g., clicking a device card loads a detailed metric view for that device); horizontal switching between different data items at the same level (e.g., swiping left in the card list to switch to another device's card); and triggering an alarm details pop-up (e.g., clicking the alarm icon on a card displays a floating window with more complete alarm information). This simultaneous data display and interactive capabilities ensures the dashboard is not only readable but also operable. The effect is a clean and concise initial view, yet each visible element is ready to respond to further user exploration, achieving a "what you see is what you can interact with" design. Step Six: When the user clicks, swipes, or performs other gestures, the system executes the corresponding action based on the triggered interactive interface type.For example, when a user clicks on a device card, triggering a drill-down operation, the system loads detailed operational data for that device from the data center based on the device identifier and the current job type. It then renders a new view according to the second-level visualization component type defined in the strategy, replacing or pushing it into the current display area. When a user swipes left to trigger a horizontal switching operation, the system loads and renders a view of another data item at the same level, maintaining the same visualization component type, such as switching from a card for the first device to a card for the second device. When a user clicks an alarm icon to trigger an alarm details pop-up, the system retrieves the complete description of the alarm, its occurrence time, possible causes, and suggested actions from the data center, displaying it in a floating window. Whether drilling down, switching, or displaying pop-ups, the system provides functionality that integrates with maintenance operations while updating views or displaying information. For example, placing a "Submit a Work Order" button in the alarm details pop-up allows the system to automatically retrieve current device information and alarm content, generate a work order, and submit it to the work order management platform. Upon successful submission, the work order number and processing progress are displayed on the dashboard, allowing users to track the work order status at any time. This linkage seamlessly connects data viewing with on-site handling. The system maps user interaction intents to corresponding data queries and view rendering operations, and integrates data flow with business processes. Users can freely navigate between a macro-level and micro-level view of data using natural gestures, and can immediately initiate work orders upon discovering a problem without switching to other applications, ensuring a continuous and efficient workflow.

[0021] In this embodiment, conventional dashboards typically display data in fixed tables or chart lists, meaning all users see the same content and order. This solution dynamically adjusts filtering conditions, sorting rules, and hierarchical divisions based on job type, ensuring completely different dashboard content across different job scenarios. During inspections, users see an overview of equipment health, while during emergency repairs, they see details of the fault chain, truly adapting to different scenarios. Secondly, conventional dashboards usually sort by time or alphabetical order, rarely using multi-factor weighted sorting. This solution introduces priority sorting rules, integrating alarm level, equipment importance, and user historical attention, ensuring the most important data always appears at the top of the list, improving the visibility of key information. Furthermore, conventional dashboard drill-down functionality often involves independent page navigation, requiring users to relocate after returning. This solution pre-defines multiple interactive interfaces for each data item during initial rendering, including drill-down, horizontal switching, and alarm pop-ups, and maintains linkage with the work order system during interaction, achieving a closed loop from data viewing to problem handling.

[0022] In one embodiment, the interactive response interface includes an interface for drilling down to sub-level data, an interface for horizontally switching between different data items at the same level, and an interface for triggering an alarm details pop-up window; The steps of responding to a user's interaction with a data item in the current view and updating the view or information according to the type of the interaction include: When the interactive operation is a drill-down operation, load and render the corresponding next-level view; When the interaction is a horizontal switching operation, load and render the view of another data item within the same level; When the interactive operation is to trigger an alarm details operation, an alarm details pop-up window will be displayed.

[0023] As mentioned above, users can interact with the dashboard by touching the screen to obtain more detailed information or switch between objects of interest as needed. This section specifically discloses three of the most commonly used and best suited interaction methods for operational needs, as well as the response actions the system should perform for each interaction method. When rendering each data item, the system pre-binds three types of interaction response interfaces: drilling down to sub-level data, horizontally switching between different data items at the same level, and triggering an alarm details pop-up. It should be noted that the specific implementation of the above interaction methods is a common technical means in mobile applications, and this solution will not elaborate on it further. These three interfaces cover the core operational needs of operations personnel when viewing data on-site: gaining in-depth understanding of a certain device, viewing another device of the same type, and quickly obtaining complete alarm information. When a user clicks on the details area of ​​a device card or performs a gesture defined as drilling down, the system recognizes this as a drilling down operation. The system first obtains the device identifier or indicator identifier corresponding to the current data item, and then determines what content should be displayed in the next level view based on the current job type and the position of the data item in the hierarchical structure. For example, if a user clicks on a server's card in the first-level card view, the system knows it needs to switch to the second-level view to display the server's detailed performance metrics. Next, the system queries the operations data center for detailed operational data of the device, including but not limited to CPU utilization trends, memory usage changes, disk I / O latency, and a list of recent alarm events. After the query is complete, the system renders the data according to the visualization component type bound to that level, such as using a line chart to display performance trends or a timeline list to display alarm events. Once rendered, the system displays the new view to the user while retaining the ability to return to the previous level, typically via a back button on the interface or by swiping right from the edge of the screen. This allows users to move from an overview to details, completing a drill-down. This is a progressive information acquisition mechanism from macro to micro. Mobile screens are limited, making it impossible to display all detailed information simultaneously. Drill-down operations allow users to access deeper data as needed, ensuring the simplicity of the initial interface without losing detailed information. The effect is that when operations personnel discover an abnormal device status, they can immediately click to view detailed metrics, quickly pinpointing the root cause of the problem without needing to navigate to other pages or re-search for the device. When a user swipes left or right on the touchscreen, or taps the landscape navigation button, the system recognizes this as a landscape navigation action. Landscape navigation typically occurs within the same display hierarchy. For example, in the first-level card list, the user is currently viewing the card for device A and wants to see the card for device B after swiping left. The system maintains an ordered list of data within the current hierarchy and records which data item in the list is currently being displayed.When a horizontal switching operation occurs, the system determines the position of the next data item based on the swipe direction. Swiping left switches to the next data item in the list, and swiping right switches to the previous data item. The system retrieves the running data corresponding to the target data item from the ordered data list and then renders it using the same visualization component type as the current level. For example, it may still use a card style, only replacing the device name, indicator value, and color status in the card. The entire switching process should be smooth and fast, typically requiring only tens of milliseconds. During inspections, maintenance personnel often need to check the health status of multiple devices sequentially. If they have to return to the previous menu and click on the next device each time, the operation path is long and inefficient. Switching directly within the same level by horizontal swiping allows for a continuous and rapid scan of a batch of devices, similar to flipping through cards. This significantly reduces the number of finger movements and clicks, especially in field environments where gloved hands are used to operate mobile devices. Swipe gestures are easier to execute than precise clicks, significantly improving operational convenience. When a user clicks on a data item with an alarm marker, such as a red alarm icon or a highlighted alarm entry, the system recognizes this as an operation to trigger alarm details. Unlike drill-down operations, alarm details typically don't require switching to a completely new full-screen view. Instead, they appear as pop-ups floating above the current screen, preventing users from losing their current viewing context. Based on the alarm identifier associated with the data item, the system retrieves complete alarm information from the data center, including the alarm details, occurrence time, duration, alarm level, possible cause analysis, and suggested handling measures. The system organizes this information into a structured pop-up view, typically including a title section displaying the alarm level and device name, a body section displaying a detailed description and suggestions, and action buttons at the bottom, such as initiating a work order or marking as read. When the pop-up is displayed, the current background view is dimmed or partially visible to highlight the content. Users can close the pop-up after reading the alarm details or directly click the buttons within the pop-up to perform subsequent actions, such as initiating a work order. This process connects the business loop from problem discovery to problem resolution. Important but non-core information is presented in a non-modal or lightweight modal manner. While alert details are important, users sometimes only need a quick glance at key information without needing to navigate to a completely new page. Pop-ups provide sufficient information without interrupting the current workflow. The effect is that users can quickly assess the severity of an alert and decide whether further action is needed without leaving their current view, reducing unnecessary page transitions and improving information retrieval efficiency.

[0024] In one embodiment, the method for providing functionality linked to operations and maintenance includes: In response to the work order initiation command triggered by the user in the alarm details pop-up window, obtain the current alarm information and the device operation data associated with the alarm information; Based on the current alarm information and the associated device operation data, a work order is generated and submitted to the work order management platform; The creation results and progress query entry of the work order are displayed on the mobile dashboard; In response to the user's triggering operation on the progress query entry, the current processing status of the work order is obtained from the work order management platform and displayed.

[0025] As described above, in step one, when a user clicks a button such as "Transfer to Work Order" or "Initiate Work Order" in the alarm details pop-up window, the system recognizes this as a work order initiation command. At this point, the system does not require the user to re-enter any information; instead, it directly extracts the necessary data from the content displayed in the current pop-up window. Specifically, the system obtains complete information about the current alarm, including the alarm content, alarm level, occurrence time, duration, and possible cause description. Simultaneously, the system also obtains the device operating data associated with the alarm, such as the device name, device type, device location in the network topology, key performance indicators in the recent period, and other recent alarm records on that device. The system automatically fills in the basic information required for the work order using the context environment, avoiding manual re-entry. The user is already within the information context of the device when viewing the alarm; the system only needs to extract the key fields from this context. The effect is that the user's work order initiation operation is simplified to a single click, without leaving the pop-up window, switching to the work order application, or manually copying and pasting the device name and alarm content. The entire operation path is extremely short and virtually error-free. Step two involves assembling the alarm information and equipment operation data extracted in step one into a structured work order according to the format required by the work order management platform. The work order should at least include the equipment name, alarm content, occurrence time, and suggested handling priority. Priorities can be automatically mapped based on alarm levels; for example, a level 1 alarm corresponds to an emergency work order, a level 2 alarm corresponds to a high-priority work order, and so on. The system can also add reference information to the work order based on equipment importance scores and historical failure frequencies to help engineers receiving the work order quickly understand the problem context. After assembly, the system calls the application programming interface provided by the work order management platform to submit the work order data to the platform. The submission operation can be synchronous, i.e., waiting for the platform to return a result before proceeding to the next step; or asynchronous, i.e., first displaying a successful submission prompt, and then confirming whether the platform has actually received it. Regardless of the method used, the system will receive a return result from the platform, which at least contains a unique identifier for the work order, such as the work order number or work order serial number. This connects the anomaly detection at the data presentation layer with the task management at the production and maintenance layer. Alarm information and device data, previously only displayed on the dashboard, are now directly converted into actionable work orders, allowing for seamless information flow between the two systems. This shortens the time interval between problem discovery and formal work order dispatch, reduces manual intervention, and lowers obstacles to work order processing caused by missing or incorrect information. After the work order is submitted in step three, the system needs to provide the user with clear feedback on the mobile dashboard, informing them whether the work order was created successfully. If successful, the system will display a success message, such as the work order number and creation time. Simultaneously, the system will place a progress query entry in an appropriate location on the current interface, such as the bottom of the alarm details pop-up or a separate area on the dashboard.This entry point can be a button displaying the progress or status of a work order, or a small icon pointing to the work order details. If a work order submission fails, for example, due to a temporary unavailability of the work order management platform or a network connection error, the system will display an error message and allow the user to retry later. The system can also temporarily store unsuccessfully submitted work orders in the mobile device's local cache, automatically resubmitting them once the network is restored. This fault tolerance ensures that user operations are not lost in weak network environments. Through instant feedback and explicit entry points, users clearly know that their actions have yielded results and how to continue tracking them. The effect is that users don't need to search for their newly created work order in the work order system again; the progress query entry on the dashboard directly points to that work order, forming a convenient and quick access path. Step Four: When the user clicks the progress query entry at a later point in time, the system will send a query request to the work order management platform, carrying the unique work order identifier obtained in Step Two in the request parameters. The work order management platform returns the current processing status of each work order, such as dispatched, in progress, awaiting acceptance, and completed. It can also return more detailed information, such as the name of the engineer currently handling the work, the estimated completion time, and any notes or comments recorded during the process. The system presents this status information on a dashboard in a mobile-friendly format. Common presentation methods include a timeline view, displaying all key milestones from work order creation to the current status in chronological order; or a concise status label view, showing only the current status and the most recent update. Regardless of the method used, users can understand the complete processing progress of a work order without leaving the dashboard. Work order tracking is also embedded in the mobile dashboard, avoiding the need for users to switch between multiple applications. Maintenance personnel can not only identify problems and create work orders while working on-site, but also continuously monitor the processing status of these work orders, forming a closed loop. This improves the transparency of work order management, allowing users to promptly understand whether their reported issues have been accepted, are being processed, and have been resolved, facilitating subsequent on-site review or work closure.

[0026] In one embodiment, the step of invoking a preset scene matching algorithm and identifying the target job type from the feature library based on the context information according to the scene matching algorithm further includes: When multiple target job types are identified, calculate the urgency weight for each target job type; If the urgency weight of the newly identified target job type is greater than the urgency weight of the job type corresponding to the current display scene, then the job type and its display status corresponding to the current display scene are pushed onto the scene stack, and the display view of the new job type is switched. In response to a user-triggered scene recovery command, the job type and its display status at the top of the scene stack are popped from the scene stack, and the corresponding display view is restored.

[0027] As mentioned above, in power operation and maintenance (O&M) sites, O&M personnel rarely face only a single task. Emergency alarms may be received during inspections, and new hidden dangers may be discovered during repairs. If the system can only identify one job type, the original context of the scenario will be lost when handling emergencies. The mechanism described in this section is designed to solve this problem, enabling the system to manage multiple concurrent job scenarios and support emergency preemption and on-site recovery. Step 1: In the aforementioned scenario matching process, the system calculates a similarity score between each job type and the current context information. Typically, the job type with the highest score is determined as the target job type. However, sometimes the second-highest score is very close to the highest score, or new context information indicates the existence of another equally reasonable job type. In this case, the system does not rush to select only one, but instead treats multiple similar job types as candidates and calculates an urgency weight for each candidate. The urgency weight measures the degree to which the job type needs to be prioritized at the current moment. The urgency weight is not a similarity score; similarity reflects the degree of matching, while the urgency weight reflects the urgency of the task itself. For example, a repair task corresponding to a Level 1 alarm has a much higher urgency weight than a regular inspection task. Even if the matching score is slightly lower, the system will still consider the alarm event to require immediate handling. The calculation of urgency weight can incorporate multiple factors, including the highest level of associated alarms, the remaining response time of unprocessed work orders, and the importance score of the equipment. The higher the alarm level, the shorter the remaining response time, and the more critical the equipment, the greater the urgency weight. An independent dimension of task urgency is introduced beyond pure semantic matching. Similarity matching determines whether a task matches, while urgency weight determines whether it should be prioritized. This separation allows the system to both identify the correct task type and make a reasonable choice among multiple correct options. This effectively solves the problem of the system being unable to make a decision when similarity scores are close, or of a low-priority scenario incorrectly covering a high-priority scenario due to a high matching score. Step two: The system maintains the task scenarios currently displayed on the front end and their corresponding urgency weights. When one or more newly identified candidate task types have an urgency weight greater than the urgency weight of the currently displayed scenario, the system determines that scenario preemption is necessary. This means that a new task is more urgent than the currently ongoing task, and the current display should be interrupted to immediately switch to the interface of the new task. For example, maintenance personnel are performing inspection work, and the system is currently displaying the inspection dashboard. At this time, a level 1 alarm appears. The system identifies the emergency repair task and calculates that its urgency weight is much greater than that of the inspection task, thus triggering the preemption process. When triggering preemption, the system does not abruptly switch the interface directly, but first saves the current scene state before performing the switch. Specifically, the system encapsulates the task type corresponding to the currently displayed scene and the current display state of the interface into a data object, and pushes this object into a specially maintained scene stack.The displayed state includes at least the user's current hierarchy index, the scroll offset position of each data item in the view, the identifiers of any expanded collapsible panels or detail windows, and the user's most recent query or filter input. This information is sufficient to accurately reconstruct the current scene in the future. After the stack operation is completed, the system immediately switches to the display view of the new job type, re-extracts, sorts, layers, and renders the data according to the data display strategy corresponding to the new job type. At this time, the mobile dashboard displays the content required for the emergency task, such as the details of the fault link and the list of associated alarms under the repair operation. The principle is to use a stack data structure to manage the nested relationship of multiple scenes. When a new scene occurs, the state of the old scene is saved and pushed onto the top of the stack, and then the system switches to the new scene. This forms a last-in-first-out processing order, which conforms to the natural pattern in reality where emergency tasks interrupt regular tasks, are processed, and then returned. The effect is that the user does not need to manually save the current progress, nor does he / she need to worry about not being able to find the previous position after switching, as the system automatically completes this part of the context management. Step 3: After handling an emergency, such as confirming the root cause of an alarm and submitting a repair order, the user may wish to return to the previously interrupted inspection task. At this point, the user can issue a scene recovery command to the system via the recovery button on the interface or a back gesture. Upon receiving the command, the system pops a scene state object from the top of the scene stack. This object represents the inspection task previously pushed onto the stack and its display status. Based on the popped task type and the parameters in the display status, the system reconstructs the previously interrupted view. Specifically, the system restores the saved hierarchical index, sets the scroll offset back to its original value, re-expands previously expanded folded panels or detail windows, and re-fills in the user's previously entered queries or filters. The entire recovery process should feel as if the user has never left the scene; the interface position, expanded status, and input content are exactly the same as before the interruption. If there are deeper scenes in the scene stack, such as when another emergency was interrupted during repair work, the system will pop up one level each time the user triggers a recovery command, returning to the original scene step by step. This allows users to handle scene nesting at any depth without losing any information. It returns scene management to the user, allowing them to decide when to return to a previous scene, while the system accurately restores the current state. The result is that operations and maintenance personnel no longer need to frantically remember the current progress between multiple tasks, nor do they need to worry about having to start from scratch after an interruption; the entire workflow maintains a high degree of continuity and controllability.

[0028] It should be added that the urgency weight can be calculated using a weighted summation method. As a specific example rather than a limitation, the system first obtains the values ​​of the following three factors for each candidate job type: First, the level score corresponding to the highest level of the associated alarm, for example, a level 1 alarm corresponds to a score of 100, a level 2 alarm corresponds to a score of 60, and no alarm corresponds to a score of 0; Second, the time limit score corresponding to the remaining response time limit of the unprocessed work order, the shorter the remaining time limit, the higher the score, for example, less than 5 minutes corresponds to a score of 100, less than 30 minutes corresponds to a score of 50, and more than 2 hours corresponds to a score of 0; Third, the equipment importance score, with core layer equipment scoring 100, aggregation layer equipment scoring 50, and access layer equipment scoring 20. The system presets weight coefficients for the above three factors, for example, the alarm level weight is 0.5, the remaining time limit weight is 0.3, and the equipment importance weight is 0.2. Then, the system multiplies the score of each factor by its corresponding weight and sums them to obtain the urgency weight of the job type. It should be noted that the above weighting coefficients and score mapping relationships can be configured and adjusted according to the actual management requirements of different operation and maintenance sites. Those skilled in the art can use other equivalent weighting or nonlinear calculation methods to achieve the same purpose of quantifying urgency.

[0029] In one embodiment, after the step of extracting operational data that meets the data filtering conditions from the operations and maintenance data center as the dataset to be displayed, the method further includes: Obtain the current geographical location and determine whether the geographical location falls within a preset security-restricted area; If the geographical location falls into a preset security-restricted area, then the data filtering rules corresponding to the security-restricted area are obtained, and the data filtering rules specify the data types or fields that are prohibited from being displayed. According to the data filtering rules, data items or fields that are prohibited from being displayed are deleted from the dataset to be displayed, and a filtered dataset to be displayed is generated. When the amount of deleted data exceeds a preset threshold, a security compliance message is generated on the mobile dashboard, and the filtering event is recorded in the backend log.

[0030] As mentioned above, the operation and maintenance sites of power information and communication systems are typically divided into different security-level zones. For example, high-voltage substations are classified as red zones, and strict operating procedures and information viewing restrictions apply to entry into these areas. Certain equipment configuration parameters, network topology details, and other information are not permitted to be displayed within red zones to avoid distracting maintenance personnel or creating safety hazards. However, in the preceding processing flow, the system automatically extracts and displays data based on the job type without considering the security constraints of the current location. The mechanism described in this section performs a security filter on the data before display, ensuring that the displayed content complies with on-site safety regulations.

[0031] Specifically, in step one, after the system extracts the dataset to be displayed from the operations and maintenance data center based on data filtering criteria, an additional security check is performed before sorting and display. Specifically, the system obtains the user's current geographic coordinates through the mobile device's location function, such as GPS latitude and longitude or Bluetooth beacon positioning results within the substation. After obtaining the location information, the system compares this location with a pre-configured set of security-restricted areas. Security-restricted areas are pre-defined polygonal fences or circular areas on the geographic information system or operations and maintenance management platform, each bound to its security level and corresponding data display restrictions. The system determines whether the user's current location falls within any security-restricted area. If so, the subsequent data filtering process is triggered; otherwise, the filtering step is skipped, and the dataset to be displayed remains unchanged. Inserting a location-based permission checkpoint into the original data extraction process maps physical space security regulations to digital space data access control. The effect is to achieve security compliance monitoring of the actual location of operations and maintenance personnel, preventing the display of specific types of data in prohibited areas and mitigating the risk of unauthorized display. Step Two: Once the system confirms that the user is currently located within a security-restricted area, it will further retrieve the data filtering rules bound to that area. The filtering rules explicitly specify which data types or specific data fields are prohibited from being displayed within the current area. For example, in a high-voltage power distribution room area, the rules might prohibit the display of detailed equipment configuration parameters, including sensitive information such as IP addresses, port numbers, firmware versions, and login credentials; or prohibit the display of non-urgent predictive maintenance suggestions, allowing only the display of equipment health status and alarm information. Different security-restricted areas may have different filtering requirements. Red zones may prohibit the display of any configuration information, yellow zones may only prohibit the display of data involving operation permissions, and green zones may have no additional restrictions. Filtering rules are stored in the system in a configurable form, allowing security administrators to adjust them at any time according to actual security policies without modifying the program code. This decouples security compliance requirements from business data processing logic, enabling flexible security policy management through rule configuration. The effect is that when security specifications change, only the rule configuration needs to be updated, without redeveloping or re-deploying the application, reducing operational costs. Step Three: After obtaining the filtering rules, the system begins to traverse every data item in the current dataset to be displayed. For each data item, the system checks its data type and included fields. If the data item is found to be of a type prohibited from display according to the rules, or contains a field prohibited from display according to the rules, a deletion operation is performed. Deletion can be performed by removing the entire data item from the dataset, or by deleting only the violating fields while retaining the rest of the data item, depending on the granularity of the rules.For example, if the filtering rule prohibits displaying the IP address field of any device, then the IP address field in each device data in the dataset to be displayed will be deleted, but other fields such as device name, health status, and CPU usage will still be retained. If all fields of a data item are deleted, then that data item itself becomes meaningless, and the system will remove the entire data item. After filtering, the system generates a new dataset to be displayed, which only contains data that is allowed to be displayed within the current security zone. This filtered dataset will then enter the subsequent sorting, layering, and rendering processes. The principle of minimizing exposure is executed during the data assembly stage, retaining only data content that meets the current security level requirements. The effect is to ensure that the final dashboard interface presented to operations personnel does not contain any illegal information, while retaining as much legitimate data as possible, avoiding the dashboard becoming empty and losing its practical value due to excessive filtering. Step four: In actual operation, the strict setting of filtering rules may lead to the deletion of a large amount of data. For example, if a user enters a highly restricted area, the filtering rules may prohibit the display of more than 80% of the content in the dataset to be displayed. At this time, the dashboard may only have a small amount of information left, and the user may wonder why they cannot see the data. Therefore, the system counts the number of deleted data items or fields and compares them to a preset threshold. If the amount of deleted data exceeds this threshold, it indicates that the filtering operation significantly reduces the displayed content. The system generates a security compliance message on the mobile dashboard, such as displaying a line of text at the top of the page: "Security restrictions in the current area are strict; some data has been filtered. Please confirm compliance." This message explains the limited content on the dashboard and reminds users to adhere to security regulations. Simultaneously, the filtering event is logged in the backend log, including user ID, geographic location, security zone, amount of deleted data, and timestamp. These logs can be used for security auditing, helping security managers understand which areas experience frequent data filtering or detect if users are attempting to view illegal data in restricted areas. This increases the observability and interpretability of the filtering operation, allowing users to clearly understand why their data is filtered, and provides audit evidence for security management. The effect is to prevent users from mistakenly believing the system is malfunctioning and to meet the power industry's compliance traceability requirements for safe operations.

[0032] Reference Figure 3 This application embodiment also provides a mobile digital dashboard system for displaying operation and maintenance data scenarios, including: Acquisition module 1 is used to collect operating data of equipment in the information and communication system and store the operating data in the operation and maintenance data center; Module 2 is used to build an operation and maintenance scenario feature library, which is used to define data display strategies corresponding to different job types; Module 3 is used to obtain the user's context information in the current job scenario; The recognition module 4 is invoked to invoke a preset scene matching algorithm, and the target job type is identified from the feature library based on the context information according to the scene matching algorithm. Extraction module 5 is used to extract the corresponding operation data from the operation and maintenance data center according to the identified target job type, and display it on the mobile terminal dashboard in a hierarchical and interactive manner according to the data display strategy corresponding to the target job type in the feature library. Response module 6 is used to respond to user interaction on the dashboard and provides functionality for linkage with operation and maintenance tasks.

[0033] As described above, it is understood that each component of the mobile digital dashboard operation and maintenance data scenario display system proposed in this application can realize the function of any of the mobile digital dashboard operation and maintenance data scenario display methods described above, and the specific structure will not be repeated.

[0034] Reference Figure 4 This application also provides a computer device, which may be a server, and its internal structure may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores monitoring data and other data. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for displaying maintenance data scenarios using a mobile digital dashboard.

[0035] The processor described above executes the mobile digital dashboard operation and maintenance data scenario display method, which includes: collecting operational data of devices in the information and communication system and storing the operational data in the operation and maintenance data center; constructing an operation and maintenance scenario feature library, wherein the feature library is used to define data display strategies corresponding to different job types; obtaining the user's context information in the current job scenario; calling a preset scenario matching algorithm to identify the target job type matching the context information from the feature library according to the scenario matching algorithm; extracting the corresponding operational data from the operation and maintenance data center according to the identified target job type, and displaying it on the mobile dashboard in a hierarchical and interactive manner according to the data display strategy corresponding to the target job type in the feature library; and providing functions that are linked with operation and maintenance operations in response to the user's interactive operations on the dashboard.

[0036] One embodiment of this application also provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements a method for displaying operation and maintenance data scenarios on a mobile digital dashboard, including the following steps: collecting operational data of devices in an information communication system and storing the operational data in an operation and maintenance data center; constructing an operation and maintenance scenario feature library, wherein the feature library is used to define data display strategies corresponding to different job types; obtaining context information of the user in the current job scenario; calling a preset scenario matching algorithm to identify the matching target job type from the feature library based on the scenario matching algorithm; extracting the corresponding operational data from the operation and maintenance data center according to the identified target job type, and displaying it on the mobile dashboard in a hierarchical and interactive manner according to the data display strategy corresponding to the target job type in the feature library; and providing functions linked with operation and maintenance operations in response to the user's interactive operations on the dashboard.

[0037] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in this application and in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-speed SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0038] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method 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, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0039] The above description is only a preferred embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made based on the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for displaying operation and maintenance data scenarios on a mobile digital dashboard, characterized in that, The method includes: Collect operational data from devices in the information and communication system, and store the operational data in the operation and maintenance data center; Construct an operation and maintenance scenario feature library, which is used to define data display strategies corresponding to different job types; Obtain the user's context information in the current job scenario; Invoke a preset scene matching algorithm, and identify the target job type from the feature library based on the context information according to the scene matching algorithm; Based on the identified target job type, the corresponding operation data is extracted from the operation and maintenance data center and displayed on the mobile dashboard in a hierarchical and interactive manner according to the data display strategy corresponding to the target job type in the feature library. In response to user interactions on the dashboard, it provides functionality to be linked with operations and maintenance tasks.

2. The method for displaying operation and maintenance data scenarios on a mobile digital dashboard according to claim 1, characterized in that, The step of invoking a preset scene matching algorithm and identifying the target job type from the feature database based on the context information according to the scene matching algorithm includes: Extract feature information from the context information in multiple dimensions, including geographical location, task type identifier, and historical operation habit statistics. Based on the extracted feature information from multiple dimensions, the corresponding initial weight coefficients are configured for the feature information of different dimensions, and the weight coefficients of each dimension are adjusted according to the user's historical matching feedback results. Based on the adjustment results, the feature information of each dimension is weighted and similarity is calculated with the preset feature template corresponding to each job type in the feature library. The similarity contribution of each dimension is multiplied by the current weight coefficient corresponding to that dimension to obtain the comprehensive matching score of each job type. The task type with the highest overall matching score is compared with a preset score threshold; Based on the comparison results, if the highest score is greater than or equal to the preset score threshold, then the job type is determined as the target job type for matching. If the highest score is less than the preset threshold, the default job type is returned or the user is prompted to manually select a job type.

3. The method for displaying operation and maintenance data scenarios on a mobile digital dashboard according to claim 1, characterized in that, The steps include: extracting the corresponding operational data from the operations and maintenance data center and displaying it on the mobile dashboard in a hierarchical and interactive manner according to the data display strategy corresponding to the target job type in the feature library; Based on the identified target job type, a data display strategy bound to the target job type is obtained from the feature library. The data display strategy includes data filtering conditions, data priority sorting rules, hierarchical structure definition, and visualization component types corresponding to each level. Based on the data filtering criteria, operational data that meets the criteria is extracted from the operation and maintenance data center as the dataset to be displayed; According to the data priority sorting rules, the data items in the dataset to be displayed are sorted by importance to generate an ordered data list; Based on the hierarchical structure definition, the ordered data list is divided into multiple display levels, and a corresponding visualization component type is bound to each level; Based on the partitioning results, render the current highest-level visualization view on the mobile dashboard and pre-set interactive response interfaces for each data item; In response to a user's interactive operation on a data item in the current view, the system performs the corresponding view or information update based on the type of the interactive operation and provides functionality to link with operation and maintenance tasks.

4. The method for displaying operation and maintenance data scenarios on a mobile digital dashboard according to claim 3, characterized in that, The interactive response interface includes an interface for drilling down to sub-level data, an interface for horizontally switching between different data items at the same level, and an interface for triggering an alarm details pop-up window; The steps of responding to a user's interaction with a data item in the current view and updating the view or information according to the type of the interaction include: When the interactive operation is a drill-down operation, load and render the corresponding next-level view; When the interaction is a horizontal switching operation, load and render the view of another data item within the same level; When the interactive operation is to trigger an alarm details operation, an alarm details pop-up window will be displayed.

5. The method for displaying operation and maintenance data scenarios on a mobile digital dashboard according to claim 4, characterized in that, The method for providing functionality that integrates with operation and maintenance tasks includes: In response to the work order initiation command triggered by the user in the alarm details pop-up window, obtain the current alarm information and the device operation data associated with the alarm information; Based on the current alarm information and the associated device operation data, a work order is generated and submitted to the work order management platform; The creation results and progress query entry of the work order are displayed on the mobile dashboard; In response to the user's triggering operation on the progress query entry, the current processing status of the work order is obtained from the work order management platform and displayed.

6. The method for displaying operation and maintenance data scenarios on a mobile digital dashboard according to claim 1, characterized in that, The step of invoking a preset scene matching algorithm and identifying the target job type from the feature library based on the context information according to the scene matching algorithm further includes: When multiple target job types are identified, calculate the urgency weight for each target job type; If the urgency weight of the newly identified target job type is greater than the urgency weight of the job type corresponding to the current display scene, then the job type and its display status corresponding to the current display scene are pushed onto the scene stack, and the display view of the new job type is switched. In response to a user-triggered scene recovery command, the job type and its display status at the top of the scene stack are popped from the scene stack, and the corresponding display view is restored.

7. The method for displaying operation and maintenance data scenarios on a mobile digital dashboard according to claim 3, characterized in that, After the step of extracting operational data that meets the data filtering conditions from the operation and maintenance data center as the dataset to be displayed, the method further includes: Obtain the current geographical location and determine whether the geographical location falls within a preset security-restricted area; If the geographical location falls into a preset security-restricted area, then the data filtering rules corresponding to the security-restricted area are obtained, and the data filtering rules specify the data types or fields that are prohibited from being displayed. According to the data filtering rules, data items or fields that are prohibited from being displayed are deleted from the dataset to be displayed, and a filtered dataset to be displayed is generated. When the amount of deleted data exceeds a preset threshold, a security compliance message is generated on the mobile dashboard, and the filtering event is recorded in the backend log.

8. A mobile digital dashboard system for displaying operational data scenarios, characterized in that, include: The acquisition module is used to collect the operating data of the equipment in the information and communication system and store the operating data in the operation and maintenance data center; The module is used to build an operation and maintenance scenario feature library, which is used to define the data display strategies corresponding to different job types. an acquisition module, configured to acquire context information of a user in a current job scenario; a calling identification module, configured to call a preset scene matching algorithm, and identify a matched target job type matching said context information from said feature library according to said scene matching algorithm; an extraction module, configured to extract corresponding operation data from said operation and maintenance data center according to the identified target job type, and display the data in a hierarchical and interactive form on a mobile terminal dashboard according to a data display strategy corresponding to said target job type in said feature library; a response module, configured to respond to a user's interaction operation on said dashboard and provide a function linked with operation and maintenance jobs.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, when said processor executes said computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, when said computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images