Knob screen and master screen cooperative fault reporting method and system

Abstract

The present application relates to the technical field of intelligent terminal fault diagnosis and man-machine interaction, in particular to a fault reporting method and system based on cooperation of a knob screen and a main control screen, comprising: real-time caching of knob screen physical interaction data by a microcontroller independent of a main control screen rendering thread; in response to a system exception interrupt signal, obtaining cached data as a physical interaction fluctuation characteristic vector and obtaining main control screen system snapshot parameters; based on a preset time window, extracting angular acceleration parameters and pressing frequency parameters to obtain an urgency index; comparing the urgency index with a preset urgency threshold to trigger a regular diagnosis mode or a cooperative shunting mode, performing data dump on the system snapshot parameters to obtain a log package to be reported; sending to a preset cloud server and sending a returned work order processing progress task to the knob screen for independent refreshing and display; the present application takes into account both fault reporting efficiency and log integrity.

Description

Technical Field

[0001] This invention relates to the field of intelligent terminal fault diagnosis and human-computer interaction technology, specifically to a fault reporting method and system based on the collaboration of a rotary screen and a main control screen. Background Technology

[0002] In medical terminals, industrial control terminals, and other devices with main control display, human-machine knob interaction, and network diagnostic capabilities, when the main control screen experiences interface lag, graphics service abnormality, business thread blocking, or kernel-level failure, how to retain effective interaction evidence and complete fault reporting at the moment of the abnormality occurs is gradually becoming an important technical direction for improving equipment maintainability and remote diagnostic efficiency.

[0003] Currently, fault reporting solutions in terminal devices generally rely on the application process on the main control screen, system log service, or central processing unit to perform unified collection and uploading. If it is necessary to obtain user operation information when a fault occurs, the main control interface thread usually processes knob input, touch input, or menu interaction data synchronously, and generates a fault log package by combining system logs, memory status, or stack information after the anomaly occurs and uploads it to the cloud server.

[0004] However, when performing fault reporting using the above methods, since physical input data such as knobs are usually attached to the rendering link of the main control interface or the upper-level business thread, once the relevant threads of the main control screen become unstable, the physical interaction data that best reflects the intensity of on-site intervention before and after the fault occurs is easily lost, making it impossible to accurately distinguish between ordinary trial operations and high-urgency operations, resulting in insufficient basis for fault triage. At the same time, this processing method usually treats system snapshot information as a single whole. When main control resources are scarce, network is limited, or abnormal load exceeds the preset load threshold, problems such as incomplete log dumping, upload latency exceeding the preset transmission time, and intensified competition for central processing unit resources are likely to occur. Furthermore, it generally relies on the main control screen to continuously bear the fault guidance, progress display, and status feedback, making it difficult to maintain an independent and usable low-load feedback link during the main control screen's abnormality, screen-off, or recovery process, resulting in the problem that the stability of the fault handling closed loop does not meet the preset judgment threshold. Summary of the Invention

[0005] The purpose of this invention is to provide a fault reporting method and system based on the collaboration of a rotary screen and a main control screen, and to solve the following technical problems:

[0006] To avoid misjudgments caused by relying solely on a single input in the fault process and to avoid incorrect reporting and routing results when hardware is disconnected, it can balance fault reporting efficiency and log integrity, and maintain a usable fault interaction closed loop even when the main control screen is under abnormal load. This enables reliable input collection, reliable log preservation, rapid fault reporting, and low-power feedback of work order status in abnormal scenarios.

[0007] The objective of this invention can be achieved through the following technical solutions:

[0008] A fault reporting method based on the collaboration between the rotary screen and the main control screen, applied to terminal devices including a main control screen, rotary screen, microcontroller, central processing unit, direct memory access controller, and flash memory, includes the following steps:

[0009] The physical interaction data of the rotary screen is cached in real time through a microcontroller that is independent of the main screen rendering thread;

[0010] The system abnormal interrupt signal is obtained through the central processing unit. In response to the system abnormal interrupt signal, the cached physical interaction data is obtained as the physical interaction fluctuation feature vector corresponding to the knob screen, and the system snapshot parameter corresponding to the main control screen is obtained.

[0011] Based on a preset time window starting from the system abnormal interruption signal, feature extraction is performed on the physical interaction fluctuation feature vector to obtain angular acceleration parameters and number of presses parameters. The urgency index is obtained through the angular acceleration parameters and number of presses parameters.

[0012] The urgency index is compared with the preset urgency threshold. If the urgency index is less than the preset urgency threshold, the normal diagnosis mode is triggered. If the urgency index is greater than or equal to the preset urgency threshold, the collaborative diversion mode is triggered to dump the system snapshot parameters and obtain the log package to be reported.

[0013] Send the log package to be reported to the preset cloud server, receive the work order processing progress task returned by the preset cloud server, and send the work order processing progress task to the rotary screen for independent refresh display.

[0014] Preferably, the steps of obtaining the cached physical interaction data as the physical interaction fluctuation feature vector corresponding to the knob screen and obtaining the system snapshot parameters corresponding to the main control screen include:

[0015] The pulse count change rate of the photoelectric encoder configured on the knob screen and the level transition edge of the micro switch are read through the preset bus, and the pulse count change rate and level transition edge are converted into physical interaction fluctuation feature vectors.

[0016] The system kernel log service captures the memory pointer address and runtime data when the system abnormal interrupt signal is triggered. The memory pointer address and runtime data are decoupled into a system summary status word and a full stack dump data. The system snapshot parameters are constructed using the system summary status word and the full stack dump data.

[0017] Preferably, the steps for obtaining the urgency index using angular acceleration and number of presses include:

[0018] Obtain the root mean square value of angular acceleration corresponding to the angular acceleration parameter, and obtain the number of presses corresponding to the number of presses parameter;

[0019] Obtain the first preset weighting coefficient corresponding to the root mean square value of angular acceleration, and obtain the second preset weighting coefficient corresponding to the number of presses;

[0020] Based on the first and second preset weighting coefficients, the root mean square value of angular acceleration and the number of presses are linearly weighted to obtain the urgency index.

[0021] Preferably, the step of linearly weighting the root mean square value of angular acceleration and the number of presses based on the first preset weighting coefficient and the second preset weighting coefficient to obtain the urgency index includes: using the formula Obtain the urgency index;

[0022] in, As an urgency index, This is the root mean square value of angular acceleration. The first preset weighting coefficient, Number of presses This is the second preset weighting coefficient.

[0023] Preferably, the steps for triggering the collaborative traffic splitting mode to dump data from the system snapshot parameters and obtain the log packet to be reported include:

[0024] Suspend the rendering thread of the main control screen and render a floating window with a preset style on the main control screen;

[0025] Trigger the direct memory access controller to extract the full stack dump data from the system snapshot parameters through the direct memory access controller;

[0026] The full stack dump data is bypassed from the pre-reserved area for writing to flash memory by the central processing unit, so that the full stack dump data is packaged into a log package to be reported.

[0027] Preferably, the steps to trigger the routine diagnostic mode include:

[0028] The troubleshooting guide menu is rendered on the main control screen, and an interactive cursor is generated in the troubleshooting guide menu;

[0029] Obtain the current cursor position of the interactive cursor through the rotary screen;

[0030] Obtain the rotation operation signal based on the knob screen, and determine the target fault node in the troubleshooting guide menu based on the rotation operation signal and the current cursor position.

[0031] Preferably, after sending the log packet to be reported to the preset cloud server, the process also includes:

[0032] Receive supplementary recording instructions issued by the preset cloud server based on the missing status data determined by parsing the log packet to be reported;

[0033] In response to the supplementary recording command, the vibration motor configured in the terminal device and linked to the rotary screen is driven to generate physical vibration at a preset frequency to generate a supplementary recording prompt signal.

[0034] Obtain the rotation authorization signal triggered by the supplementary recording prompt signal, and upload the incremental log package in the background based on the rotation authorization signal.

[0035] Preferably, the steps for sending the work order processing progress task to the rotary screen for independent refresh display include:

[0036] Convert the work order processing progress task into a circular progress bar rendering instruction;

[0037] The rendering command for the circular progress bar is sent to the local video memory built into the rotary screen;

[0038] The main control screen enters a sleep mode, and the work order processing progress task corresponding to the rendering instruction is displayed by independently refreshing the circular progress bar on the rotary screen.

[0039] Preferably, before obtaining the cached physical interaction data as the physical interaction fluctuation feature vector corresponding to the knob screen, the method further includes:

[0040] The hardware connection status of the rotary screen is detected, and a physical disconnection signal is generated based on the detected connection level.

[0041] If a physical circuit breaker signal is generated, the acquisition of physical interaction fluctuation feature vectors will stop, and the watchdog timer built into the main control screen will be triggered to perform timeout reset and routine reporting.

[0042] If no physical circuit breaker signal is generated, the step of obtaining the cached physical interaction data as the physical interaction fluctuation feature vector corresponding to the knob screen is executed.

[0043] A fault reporting system based on the collaboration of a rotary screen and a main control screen is applied to terminal devices that include a main control screen, a rotary screen, a microcontroller, a central processing unit, a direct memory access controller, and flash memory. The system includes:

[0044] The caching module is used to cache the physical interaction data of the rotary screen in real time through a microcontroller that is independent of the main screen rendering thread;

[0045] The acquisition module is used to acquire system abnormal interruption signals. In response to the system abnormal interruption signals, it acquires the cached physical interaction data as the physical interaction fluctuation feature vector corresponding to the knob screen, and acquires the system snapshot parameters corresponding to the main control screen.

[0046] The processing module is used to extract features from the physical interaction fluctuation feature vector based on a preset time window starting from the system abnormal interruption signal, so as to obtain the angular acceleration parameter and the number of presses parameter, and obtain the urgency index through the angular acceleration parameter and the number of presses parameter;

[0047] The execution module is used to compare the urgency index with the preset urgency threshold. If the urgency index is less than the preset urgency threshold, the normal diagnosis mode is triggered. If the urgency index is greater than or equal to the preset urgency threshold, the collaborative diversion mode is triggered to dump the system snapshot parameters and obtain the log package to be reported.

[0048] The feedback module is used to send the log package to be reported to the preset cloud server, receive the work order processing progress task returned by the preset cloud server, and send the work order processing progress task to the rotary screen for independent refresh display.

[0049] The beneficial effects of this invention are:

[0050] 1. This invention uses a microcontroller independent of the main screen rendering thread to cache the physical interaction data of the knob screen in real time, and extracts angular acceleration and number of presses to calculate the urgency index when the system is abnormal. This mechanism avoids the loss of interaction evidence caused by the instability of the main screen, can accurately quantify the urgency of the operation, and provides reliable data support for triggering routine diagnosis or collaborative diversion.

[0051] 2. When the collaborative flow splitting mode is triggered, the present invention reduces the load by suspending the main control screen rendering thread and uses the direct memory access controller to write the full stack dump data directly to the flash memory, bypassing the central processing unit. This bypass dumping mechanism effectively alleviates the resource contention of the central processing unit when a fault occurs, and ensures the integrity preservation and rapid reporting of core logs under high-pressure scenarios.

[0052] 3. This invention transfers the work order processing progress task issued by the cloud to the rotary screen for independent refresh display, allows the main control screen to enter a sleep state, and supports incremental log supplementation through rotary motor vibration prompts and physical authorization; this design separates the status feedback from the high-power main screen to the low-load rotary screen link, ensuring that a stable fault handling closed loop can still be maintained during main screen abnormalities or screen-off periods. Attached Figure Description

[0053] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0054] Figure 1 A flowchart illustrating the fault reporting method based on the collaboration of the rotary screen and the main control screen provided in this application embodiment;

[0055] Figure 2This is a schematic diagram of a fault reporting system based on the collaboration of a rotary screen and a main control screen, provided in an embodiment of this application. Detailed Implementation

[0056] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0057] Please see Figure 1 A fault reporting method based on the collaboration between the rotary screen and the main control screen, applied to terminal devices including a main control screen, rotary screen, microcontroller, central processing unit, direct memory access controller, and flash memory, includes the following steps:

[0058] The microcontroller, independent of the main control screen rendering thread, caches the physical interaction data of the rotary screen in real time; the central processing unit obtains the system abnormal interrupt signal, and in response to the system abnormal interrupt signal, obtains the cached physical interaction data as the physical interaction fluctuation feature vector corresponding to the rotary screen, and obtains the system snapshot parameter corresponding to the main control screen.

[0059] Based on a preset time window starting from the system abnormal interruption signal, feature extraction is performed on the physical interaction fluctuation feature vector to obtain angular acceleration parameters and number of presses parameters. The urgency index is obtained through the angular acceleration parameters and number of presses parameters.

[0060] The urgency index is compared with the preset urgency threshold. If the urgency index is less than the preset urgency threshold, the normal diagnosis mode is triggered. If the urgency index is greater than or equal to the preset urgency threshold, the collaborative diversion mode is triggered to dump the system snapshot parameters and obtain the log package to be reported.

[0061] Send the log package to be reported to the preset cloud server, receive the work order processing progress task returned by the preset cloud server, and send the work order processing progress task to the rotary screen for independent refresh display.

[0062] This embodiment provides a fault reporting mechanism based on the collaboration between the rotary screen and the main control screen; specifically, this embodiment uses the bedside environmental control terminal of a hospital negative pressure isolation ward as the main scenario for explanation.

[0063] The terminal is installed at the entrance of the ward. The main control screen is used to display temperature, humidity, pressure difference, air exchange rate and fault information, while the rotary screen is used by medical staff to make quick adjustments while wearing gloves.

[0064] The terminal internally contains a microcontroller, a central processing unit, a direct memory access controller, and flash memory. The microcontroller is responsible for taking over the low-level input acquisition of the rotary screen, the central processing unit is responsible for business logic and network communication, and the flash memory has a reserved fault dump area.

[0065] Furthermore, during normal operation, the photoelectric encoder pulses and push-button switch levels corresponding to the knob screen do not directly depend on the interface thread of the main control screen for processing, but are first continuously cached by the microcontroller in a cyclic buffering manner.

[0066] The principle behind its configuration is that, in the event of a fault, the rendering thread of the main control screen or its upper-level application process is usually the first to become unstable. The physical operation signal of the knob is an input that is closer to the hardware interrupt layer. If it is not cached in advance, the physical interaction data that directly represents the user's high-frequency trigger state will be lost at the moment the fault occurs.

[0067] The physical interaction data here includes not only the rotation step size, but more importantly, whether rapid and repeated rotation and intensive pressing occurred within a preset time period. In engineering terms, these phenomena correspond to the urgency characteristics of the operator triggering the ward control state switching request.

[0068] When the system detects an abnormal interruption signal, such as a graphics service crash, illegal process access, timeout blocking of the main control business thread, or a kernel-level exception, the exception is regarded as the starting point of the fault process.

[0069] On the one hand, the system extracts the cached physical interaction data of the knobs within a preset time window before and after the anomaly occurs, and organizes it into a physical interaction fluctuation feature vector.

[0070] On the other hand, capture the system snapshot parameters corresponding to the current business status of the main control screen; the former reflects the intensity of the operator's real-time intervention, and the latter reflects the internal state of the system at the moment of failure. The two together constitute the input basis for subsequent traffic diversion judgment.

[0071] Furthermore, within a preset time window, the system extracts angular acceleration parameters from the rotation behavior of the knob and press number parameters from the pressing behavior; here, angular acceleration does not simply represent the angular velocity scalar value of the knob's rotation speed, but is closer to the kinematic characterization of whether the rotation action is sudden and violent.

[0072] The number of presses reflects whether the operator has made continuous confirmation or forced recovery attempts; in equipment failure handling scenarios, if the operator only performs routine step adjustments within the preset low volatility threshold, it usually means that the failure has not yet affected the core business.

[0073] If accompanied by rapid rotation and frequent pressing, it often indicates that the on-site personnel are eager to restore the negative pressure, air volume, or alarm confirmation function; based on this, the system obtains an urgency index and compares it with the preset urgency threshold.

[0074] When the urgency index is below the threshold, the system enters the normal diagnosis mode. This indicates that the fault still has a certain degree of interactivity, and the main control screen can still undertake the step-by-step guidance task. Therefore, the main control screen displays the standard fault classification menu, and the rotary screen continues to undertake cursor control and confirmation input, so that medical staff can complete the fault node selection without frequently touching the main screen.

[0075] When the urgency index reaches or exceeds the threshold, the system enters the collaborative traffic splitting mode. At this time, the integrity of the interface is no longer prioritized. Instead, the retention and reporting timeliness of the core logs are prioritized. The system dumps the system snapshot parameters, generates a log package to be reported, and minimizes the number of rendering layers on the main control interface to avoid further aggravating the rendering delay under the unstable state of the main thread.

[0076] After the log packet is sent to the preset cloud server via the network, the cloud side generates a work order processing progress task based on the device serial number, anomaly type and log content; this progress task no longer needs to be continuously displayed on the main control screen, but is sent to the rotary screen for independent refresh;

[0077] Even if the main control screen temporarily enters recovery mode, screen-off mode, or low-power standby mode, on-site personnel can still learn about the status of work orders such as "order received", "diagnosing", "waiting for re-entry", and "remote repair completed" from the rotary screen.

[0078] As a fault-tolerance strategy, if the network is interrupted when an abnormal interruption occurs, the local system first writes the log packet to be reported into the flash memory reserved area, and then resends it after the network is restored.

[0079] If the microcontroller buffer is full when an abnormal interruption occurs, the data of the time period closest to the start of the abnormality will be retained first to ensure that the key segments reflecting the intensity of operation before and after the fault are not overwritten; if the main control screen completely loses its display capability, the rotary screen will at least continue to provide simplified status indication and report result feedback.

[0080] If there is neither a valid network nor local writable space, the system retains a lightweight state digest and triggers a local recovery strategy to avoid secondary anomalies caused by repeated write failures.

[0081] When switching to high ventilation mode in the negative pressure ward at night, the bedside environmental control terminal became unresponsive due to a graphics service memory error. After the on-duty nurse discovered that the pressure difference trend was not being refreshed, she continuously turned the knob and pressed it multiple times within the preset time threshold to try to restore the interface.

[0082] The microcontroller has independently cached the knob behavior. When an abnormal interruption occurs, the system extracts this violent physical operation and the corresponding system snapshot, determines that on-site intervention is urgent, and then reduces the rendering of complex menus on the main control screen, directly generates a fault reporting package and uploads it.

[0083] After a preset communication response time, the cloud returns the progress of the accepted work order and the remote diagnosis in progress. The rotary screen continues to display the progress in an independent refresh mode, while the main control screen enters a low-load recovery state.

[0084] The purpose of this step is to transform the rotary screen from a simple accessory display into a low-level perception and feedback node in the fault handling chain, thereby achieving a balance between fault reporting efficiency and log integrity, and maintaining a usable fault interaction closed loop even when the main control screen is under abnormal load.

[0085] In a preferred embodiment of the present invention, the steps of obtaining cached physical interaction data as a physical interaction fluctuation feature vector corresponding to the rotary screen and obtaining system snapshot parameters corresponding to the main control screen include: reading the pulse count change rate of the photoelectric encoder configured on the rotary screen and the level transition edge of the micro switch through a preset bus, and converting the pulse count change rate and the level transition edge into a physical interaction fluctuation feature vector.

[0086] The system kernel log service captures the memory pointer address and runtime data when the system abnormal interrupt signal is triggered. The memory pointer address and runtime data are decoupled into a system summary status word and a full stack dump data. The system snapshot parameters are constructed using the system summary status word and the full stack dump data.

[0087] This embodiment provides a mechanism for decoupling the acquisition of physical interaction data and system snapshot parameters. Specifically, in the above-mentioned ward environment control terminal, if only the user's operation of the knobs and the system error reports are generally saved, although it can meet the basic traceability, it cannot determine the physical operation jump characteristics before and after the fault occurs, and it is also difficult to distinguish which system data should be uploaded quickly and which system data is suitable for delayed dumping. Therefore, the acquisition process needs to be further refined.

[0088] In one specific implementation, the signal acquisition on the knob screen side is completed through a preset bus, which can be an internal integrated circuit bus, a serial peripheral interface bus, or an isolated serial control bus.

[0089] At the hardware level, the output of the photoelectric encoder is not semantically related to adjusting the air volume to the left or the pressure difference to the right, but rather a pulse count change with directional and frequency characteristics; the micro switch does not directly output confirmation reports, but is manifested as a high-low level transition edge.

[0090] The system combines the pulse count change rate and level transition edge in a certain time series in chronological order to form a physical interactive fluctuation feature vector;

[0091] For example, in a simplified data processing example, the system extracts four consecutive sampling segments P1, P2, P3 and P4, where segments P1 and P2 correspond to slow unidirectional rotation, segment P3 corresponds to rapid reverse rotation, and segment P4 corresponds to a single press jump. This vector does not only indicate that an operation has occurred, but also indicates a temporal structure of first probing adjustment, then rapid correction, and then confirmation.

[0092] Correspondingly, the system snapshot parameters on the main control screen should not all be encapsulated into a single log data packet; otherwise, the storage and transmission burden will be increased when the main process is unstable.

[0093] Therefore, in this embodiment, the memory pointer address and runtime data at the moment of the exception are captured and split through the system kernel log service. After splitting, a part is organized into lightweight status words to quickly characterize the core state when the exception occurs, such as fault module identifier, thread number, exception type, interface tab number, network connection status, etc.

[0094] Another part is organized into full stack dump data for subsequent in-depth investigation; the lightweight status words are not simply compressed, but retain the summary that best guides the rapid creation of cases and initial judgment in the cloud; the full data retains the details needed to locate problems such as memory out-of-bounds, deadlock links, and driver conflicts;

[0095] In a simplified data processing example, the system obtains a state summary L1 corresponding to an exception and a stack dump F1 corresponding to the same exception.

[0096] In this way, the system snapshot parameter is not a single entity, but a hierarchical combination of state summary L1 and stack dump F1; when the network is good and local resources are sufficient, both can be uploaded at the same time.

[0097] When main control resources are scarce or the network is limited, the cloud can be processed first using the status summary L1, and then the stack trace can be uploaded and dumped to F1 at an opportune time. Through this layered construction, the subsequent traffic distribution mode can have a real landing point, rather than remaining at the level of abstract judgment.

[0098] In a fault-tolerant processing mechanism, if the preset bus experiences instantaneous jitter within a preset time threshold, the system can perform de-jittering or resampling confirmation on the pulse count change rate to avoid misjudging bus noise as severe rotation.

[0099] If there is sticking in the microswitch level, mark the segment as an abnormal input segment when constructing the vector to avoid mistaking hardware defects for frequent pressing;

[0100] For the system snapshot side, if the kernel log service can only capture part of the runtime data, a usable lightweight status word will be generated first, and the missing part will be marked with a data integrity mark, and then handed over to the supplementary recording process for processing; if the full stack dump fails to be obtained, the reporting process will not be blocked, but the cloud will be guaranteed to accept the order first in the manner of prioritizing the digest.

[0101] Before the interface of the ward control terminal froze, the nurse first slowly turned the knob to try to switch the ventilation level from medium to high. Because the interface was unresponsive, she quickly turned it in the opposite direction and pressed to confirm.

[0102] The encoder pulses are a continuous sequence in time, consisting of low-rate-of-change segments, high-rate-of-change segments, and press-jump edges. The system constructs this sequence into a physical interactive wave characteristic vector.

[0103] Meanwhile, the kernel logging service captures the abnormal address, thread state, and call chain of the graphical process. The summary part is first formed into a lightweight status word, and the full details are formed into stack dump data, which together constitute the system snapshot parameters.

[0104] The purpose of this step is to construct two links for synchronous evidence collection through hierarchical acquisition of physical input via knobs and hierarchical system snapshots, so as to ensure that the basic data for subsequent urgency judgment, triage reporting and cloud diagnosis are fully public and can be executed in an engineering manner.

[0105] In a preferred embodiment of the present invention, the step of obtaining the urgency index through the angular acceleration parameter and the number of presses parameter includes: obtaining the root mean square value of the angular acceleration corresponding to the angular acceleration parameter, and obtaining the number of presses corresponding to the number of presses parameter;

[0106] Obtain a first preset weighting coefficient corresponding to the root mean square value of angular acceleration, and obtain a second preset weighting coefficient corresponding to the number of presses; based on the first preset weighting coefficient and the second preset weighting coefficient, perform linear weighted calculation on the root mean square value of angular acceleration and the number of presses to obtain the urgency index.

[0107] This embodiment provides a mechanism for obtaining an urgency index. Specifically, in the aforementioned scheme, if the fault handling path is determined solely based on whether rotation or pressing occurs, two types of deviations will occur: one is that routine low-frequency interactions are misjudged as high-urgency response states, causing the system to prematurely enter simplified reporting.

[0108] The first and second preset weight coefficients are obtained by performing regression analysis training on physical interaction time-series data in the historical equipment fault log database and are pre-written into the constant configuration area of ​​flash memory.

[0109] Another type is the omission of real high-pressure scenarios, which still drive operators to perform multi-level interactions on interfaces with response delays exceeding preset thresholds; therefore, it is necessary to include both the intensity of rotation behavior and the density of pressing behavior in the judgment.

[0110] In one specific implementation, the root mean square value of angular acceleration is used to reflect the overall fluctuation level of the knob rotation over a period of time; compared with instantaneous angular velocity, it is more representative of the comprehensive characteristics of multiple sharp turns, sudden stops, and reverse corrections within a preset time period.

[0111] In the scenario of ward control terminal, if the operator adjusts the parameters only within the preset step range, the knob movement is usually smooth and the angular acceleration fluctuation is less than the preset fluctuation threshold. If the emergency parameter adjustment is repeatedly performed due to interface failure, the knob often shows obvious sudden acceleration and sudden stop. This kinematic characteristic is more suitable to be characterized by the root mean square value of angular acceleration.

[0112] The number of presses reflects the frequency with which the operator wants to trigger the confirmation, recovery, or submission action as soon as possible. Combining the two can more closely approximate the actual stress level on the spot.

[0113] To prevent the two types of parameters from becoming unbalanced in the judgment, this embodiment sets a first preset weighting coefficient and a second preset weighting coefficient; the former applies to the root mean square value of angular acceleration, and the latter applies to the number of presses; the setting of the weighting coefficient is not only for algebraic calculation, but also reflects the difference in diagnostic significance of the two types of physical behavior in different scenarios.

[0114] For example, for terminals that mainly rely on rotation to adjust parameters, the intensity of rotation is more indicative of the on-site personnel's urgent need to correct the deviation, and therefore can be given a higher contribution.

[0115] For terminals with a clear one-click confirmation process, the number of presses is also a strong indicator of whether rapid reporting is needed, so the two can be set to have similar weights; through this linear weighting, the urgency index obtained by the system is no longer triggered by a single action, but is a comprehensive mapping of the intensity of multi-source physical interactions.

[0116] To illustrate the data flow, a simplified data processing example can be provided: after a fault occurs, a summary quantity Q1 representing the overall fluctuation level of the knob and a summary quantity Q2 representing the frequency of confirmation actions are generated in the window;

[0117] The system does not make decisions based on the summaries Q1 or Q2 separately, but instead merges them into a unified index U after mapping with corresponding weights. In this way, when the summaries Q1 are greater than the first preset threshold and the summaries Q2 are less than the second preset threshold, the unified index U can still exhibit a drastically fluctuating urgency.

[0118] When the number of abstracts Q1 is within the preset reference range but the number of abstracts Q2 is greater than or equal to the third preset threshold, the uniformity index U can exhibit a continuous confirmation type of urgency.

[0119] In a fault-tolerant mechanism, if only rotation is detected in the window but no pressing is detected, the corresponding part of the pressing count is treated as zero or a default null value, but the role of rotation intensity in urgency is not negated.

[0120] If only pressing is detected without effective rotation, the rotation portion is treated as an invalid segment or zero contribution; if both types of signals are missing due to abnormal acquisition, the system does not output a misleading high urgency judgment, but instead switches to a conservative path and adopts conventional diagnosis or fault degradation strategies.

[0121] If obvious hardware jitter characteristics are detected within the same window, such as dense but equally spaced non-manual level jumps, then de-jitter filtering is performed first, and then the corresponding summary quantity is calculated.

[0122] After the negative pressure ward mode switching failed, the nurse repeatedly and rapidly rotated the knob and tried to press to confirm; the system extracted that the overall fluctuation of the knob movement was significantly enhanced, and the confirmation action repeated within the preset time threshold.

[0123] The two are mapped to rotation intensity summary and press frequency summary respectively, and then merged into a higher urgency index after being weighted by a preset weight, thereby identifying this fault as a scenario that requires priority to complete log saving and rapid reporting;

[0124] The purpose of this step is to unify different types of physical interaction signals under the same urgency metric, thereby achieving stable identification of the intensity of operator intervention on-site and avoiding misjudgments caused by relying on a single input in the fault process.

[0125] In a preferred embodiment of the present invention, the step of obtaining the urgency index by linearly weighting the root mean square value of angular acceleration and the number of presses based on a first preset weighting coefficient and a second preset weighting coefficient includes: using the formula Obtain the urgency index;

[0126] in, As an urgency index, This is the root mean square value of angular acceleration. The first preset weighting coefficient, Number of presses This is the second preset weighting coefficient.

[0127] This embodiment provides a method for linearly weighted urgency index calculation. Specifically, although the previous embodiment explained that the degree of rotation intensity and the frequency of pressing need to be considered, if the synthesis method of the two parameters is not clear, different device versions may use inconsistent judgment logic during actual deployment, affecting the consistency of the fault reporting link. Therefore, this embodiment further adopts a linear weighted summation method to form a unified urgency index.

[0128] Furthermore, the engineering significance of linear weighting lies in its interpretability, calibrability, and suitability for rapid execution in embedded terminals; the system first combines the root mean square value of angular acceleration with the first preset weighting coefficient to obtain the first product; then it combines the number of presses with the second preset weighting coefficient to obtain the second product; the two are added together to form the urgency index;

[0129] The product here can be understood as the contribution of each parameter to the overall decision, while the sum represents the system combining the urgent evidence from two different sources. Since the knob action and the pressing action have clear physical meaning, this sum is not an abstract superposition, but rather a combination of the urgency in rotation and the urgency in confirmation into a unified representation for triage decision-making.

[0130] To facilitate the disclosure of its feasibility, a simplified data processing example can be provided: The system extracts the knob rotation fluctuation summary Q1 corresponding to the root mean square value of angular acceleration and the press frequency summary Q2 corresponding to the number of presses within the window;

[0131] The system first multiplies the knob rotation fluctuation summary Q1 with the first preset weight coefficient to generate the first contribution C1, and multiplies the press frequency summary Q2 with the second preset weight coefficient to generate the second contribution C2. Then, the first contribution C1 and the second contribution C2 are combined to obtain a unified urgency index U.

[0132] In this way, the processing chain is clearly presented as extracting the amount of summary - generating the amount of contribution - synthesizing the total index, which is convenient for deployment on microcontrollers or central processing units. This method also makes it easy to adjust the contribution ratio of the first preset weight coefficient and the second preset weight coefficient according to the scenario during subsequent maintenance, without changing the overall process framework.

[0133] As a fault-tolerance strategy, if a certain type of input contribution is set to zero due to missing data collection, the corresponding contribution can be included in the summation as zero, thus avoiding the inability to generate the entire index due to missing local data; if both types of contribution are unavailable, the system will not perform aggressive diversion, but will adopt a conservative default path.

[0134] If subsequent device versions add other physical input sources, such as independent confirmation buttons or haptic sliders, the contribution interface can be expanded without destroying the existing dual-parameter structure. However, in this embodiment, the sum of the two contribution values ​​is still the main approach.

[0135] Within the ward terminal fault window, the system first generates a rotation contribution from the violent rotation of the knob, then generates a pressing contribution from the continuous confirmation of pressing, and finally summarizes the two contributions into a single urgency index. Subsequently, whether compared with a threshold or recorded in the local diagnostic log, only this unified index needs to be processed, thereby reducing ambiguity in cross-module data interpretation.

[0136] The purpose of this step is to ensure that the urgency determination is consistent across different terminals and firmware versions by using a clear, lightweight, and easily engineered synthesis path, thereby achieving stable triggering of the traffic offloading strategy.

[0137] In a preferred embodiment of the present invention, the steps of triggering a collaborative diversion mode to dump data of system snapshot parameters and obtain log packets to be reported include: suspending the rendering thread of the main control screen and rendering a floating window of a preset style on the main control screen;

[0138] Trigger the Direct Memory Access Controller (DMC) to extract the full stack dump data from the system snapshot parameters; bypass the pre-reserved area for writing the full stack dump data to the flash memory by the CPU, and package the full stack dump data into a log package to be reported.

[0139] This embodiment provides a data dumping mechanism under a collaborative flow splitting mode. Specifically, in the aforementioned scheme, if the main control screen continues to render the complete diagnostic interface after being determined to be in a high-urgency state, and the central processing unit is responsible for stack copying and log packaging, it is easy to cause the negative technical effects of excessive rendering load on the main control screen and limited data dumping resources of the central processing unit.

[0140] Therefore, this embodiment introduces a collaborative diversion path of main screen rendering suspension + direct memory access controller dump in high urgency state;

[0141] In one specific implementation, when the system decides to enter the collaborative streaming mode, the rendering thread of the main control screen is suspended. This suspension does not mean that the monitor stops outputting video signals directly, but rather that the refresh of complex pages, lists, animations, or multi-level menus is stopped, and only a floating window with a preset style is retained.

[0142] The floating window can use a high-contrast background and text elements in quantities below a preset threshold to indicate core statuses such as fault capture, log saving, and the ability to press the knob to confirm reporting.

[0143] The physical significance of doing this is to immediately reduce graphics stack usage and avoid creating further pressure on the display side for memory allocation and thread switching;

[0144] The system triggers the Direct Memory Access Controller to extract the full stack dump data from the system snapshot parameters. Since the Direct Memory Access Controller can complete the data transfer from memory to flash memory without relying on the CPU to move data byte by byte, it is suitable for use during faults where the main controller load is high or some threads are blocked.

[0145] After the full stack dump data is written to the preset reserved area of ​​flash memory bypassing the central processing unit, a log package to be reported can be formed locally. This log package can use a lightweight status word as the header index and the full stack dump data as the subsequent body, thus taking into account the needs of rapid identification and in-depth investigation in the cloud.

[0146] To illustrate its execution logic, a simplified data processing example can be used: the system snapshot parameter consists of a summary block B1 and a stack block B2; under the normal path, the central processing unit needs to manage both the interface refresh and the movement of stack block B2 simultaneously, which can easily lead to resource contention.

[0147] In this embodiment, the interface is compressed into a floating window. Stack block B2 is written to the flash memory reserved area F by the direct memory access controller, and then the network thread reads the contents of area F and encapsulates and sends it at an opportune time. In this way, digest block B1 is responsible for fast identification, and stack block B2 is responsible for fault details. The two are effectively separated in terms of time and resource path.

[0148] In a fault-tolerant mechanism, if the floating window still fails to display successfully after the rendering thread is suspended, the system will not stop the dump due to the display failure, and the rotary screen can be rotated to serve as the sole prompt interface.

[0149] If the direct memory access controller is currently occupied by other high-priority channels, the system first locks the dump task and executes it immediately after it is released. If necessary, only the digest block is saved first to reduce the probability of information loss.

[0150] If the flash memory reserved area is insufficient, the system will write the full stack dump data in segments or retain the critical segment closest to the abnormal starting point according to the preset strategy; if there are bad blocks in the flash memory, they will be transferred to the spare reserved area and the bad block identifier will be recorded for subsequent maintenance.

[0151] When the graphics service on the ward terminal became unstable, causing nurses to repeatedly operate the knobs, the system determined it to be in a high-urgency state; the main control screen no longer attempted to render the complete fault form, but only displayed a prompt floating window; at the same time, the direct memory access controller directly wrote the call chain, memory page information and thread stack at the time of the exception into the flash memory reserved area;

[0152] In this way, even if the central processing unit is still processing network reconnection or device driver recovery, the full log has been reliably saved and can be automatically generated and sent as a log packet to be reported after the network is restored.

[0153] The purpose of this step is to reduce the load on the main controller display and utilize the bypass dump capability of the direct memory access controller to prioritize log preservation under high-pressure fault scenarios, thereby reducing the risk of dump failure caused by CPU resource contention.

[0154] In a preferred embodiment of the present invention, the steps for triggering the conventional diagnostic mode include: rendering a troubleshooting guidance menu on the main control screen and generating an interactive cursor in the troubleshooting guidance menu; obtaining the current cursor position of the interactive cursor through the rotary screen; obtaining a rotation operation signal based on the rotary screen; and determining the target fault node in the troubleshooting guidance menu based on the rotation operation signal and the current cursor position.

[0155] This embodiment provides a human-machine collaborative guidance mechanism under conventional diagnostic mode. Specifically, in the aforementioned process, if the urgency of the situation is not high and the system still enters the simplified reporting mode, although it is beneficial to submit logs quickly, it will lose the opportunity for on-site personnel to provide business context, such as whether they are switching differential pressure mode, adjusting temperature and humidity, or viewing historical alarms when the fault occurs. Therefore, when the urgency does not reach the high pressure threshold, an interactive troubleshooting guidance path needs to be retained.

[0156] Furthermore, in the standard diagnostic mode, the main control screen is responsible for rendering the troubleshooting guide menu; this menu may include multiple levels of fault nodes such as interface lag, differential pressure value not refreshing, knob operation without feedback, and inability to view historical alarms;

[0157] At the same time, the system generates an interactive cursor in the menu, but the movement of the cursor does not depend on finger touch, but is input by the rotary screen; the direction and step amount generated by each rotation of the knob are converted into the current position change of the cursor in the menu hierarchy; when the cursor stops at a certain node and a confirmation press occurs, the target fault node can be identified.

[0158] The key to this design is not just replacing touch operation, but utilizing the discrete stepping characteristics of knob input to keep the fault classification process stable even in environments with gloves, moisture, disinfection, or partial touch lag on the main control screen.

[0159] For hospital ward equipment, when medical staff are undergoing frequent disinfection and wearing protective gear, knob operation is often more reliable than touch screen clicks; by using the main control screen for display and the knob screen for navigation control, the system achieves decoupling of display and input in fault classification;

[0160] For ease of explanation, a simplified data processing example can be provided: The first level of the troubleshooting guide menu contains a first node N1, a second node N2, and a third node N3, with the cursor initially positioned at the first node N1;

[0161] If the knob is turned clockwise one step, the current position is updated to the second node N2; if it is turned clockwise another step, it is updated to the third node N3; after pressing, the system enters the set of subordinate nodes of the third node N3.

[0162] In this way, the cursor position is not actively scanned by the main control screen, but updated by the knob signal; if there are no sub-items under a certain node, the corresponding fault classification label is directly generated and associated with the log package after confirmation;

[0163] As a fault-tolerant strategy, if the main control screen can be displayed but the refresh of some areas is slow, the system can reduce the menu animation effect and only retain the text and cursor box; if the knob continues to rotate in the same direction after moving to the boundary node in the menu, any of the preset strategies of boundary stay, cycle switching or bounce prompt can be executed.

[0164] If the menu data itself fails to load, the system will automatically return to the summary-style fault classification interface, allowing at least the selection of first-level nodes such as interface abnormality, input abnormality, and network abnormality, to avoid failure to report due to menu tree defects.

[0165] When only a slight interface delay occurs on the ward terminal, the on-duty nurse can still see the troubleshooting guide menu on the main control screen; the nurse moves the interactive cursor to the non-updated node on the differential pressure interface by turning the knob and presses to confirm, and the system binds the faulty node with the current log package and submits it to the cloud accordingly.

[0166] After receiving an order in the cloud, maintenance personnel can know in advance that the fault occurred on the differential pressure interface rather than the temperature and humidity curve page, thus narrowing down the scope of troubleshooting.

[0167] The purpose of this step is to retain the ability to classify structured faults while still allowing for interaction during faults, thereby binding log content with business scenarios and improving the targeting of cloud-based acceptance and remote diagnosis.

[0168] In a preferred embodiment of the present invention, after sending the log packet to be reported to a preset cloud server, the method further includes: receiving a supplementary recording instruction issued by the preset cloud server based on the missing status data determined by parsing the log packet to be reported; responding to the supplementary recording instruction, driving a vibration motor configured in the terminal device and linked to the rotary screen to generate physical vibration at a preset frequency to generate a supplementary recording prompt signal; obtaining a rotation authorization signal triggered based on the supplementary recording prompt signal, and uploading an incremental log packet in the background based on the rotation authorization signal.

[0169] This embodiment provides a cloud-based log supplementation closed-loop mechanism. Specifically, although the aforementioned solution can quickly report logs when a fault occurs, in actual deployment, there may still be situations where the initial uploaded information is incomplete. For example, network jitter at an abnormal moment may cause some dump segments to be not uploaded, or the cloud may find that a certain driver layer state is missing after parsing.

[0170] Therefore, a single report is not enough to form a complete closed loop; a follow-up chain of cloud feedback, local supplementary recording, and user authorization is required.

[0171] Furthermore, after the cloud server parses the first log packet to be reported, if it determines that key status data is still missing, it will issue a supplementary recording instruction.

[0172] The supplementary recording instruction can include information such as the missing data category, supplementary recording priority, and suggested upload time. After receiving the instruction, the local terminal does not force the immediate use of main control resources to perform background supplementary recording. Instead, it first generates a physical vibration of a specific frequency through a vibration motor linked to the rotary screen as a supplementary recording prompt signal.

[0173] The reason for using physical vibration instead of relying solely on text prompts on the main control screen is that the main control screen may be in sleep mode, in recovery mode, or has not met the preset conditions for continuous screen illumination. The rotary screen is closer to the operator's frequently used input area, making it easier to provide tactile prompts.

[0174] After the operator senses the supplementary recording prompt, they can generate an authorization signal by rotating or pressing the knob, and the system will then upload the incremental log package in the background accordingly.

[0175] The authorization here has engineering significance: on the one hand, it can avoid reaching the network bandwidth transmission limit or processor load peak during peak ward control periods; on the other hand, it can ensure that the supplementary recording occurs after on-site personnel confirm that the equipment is in an acceptable state; the incremental log packet can contain only the missing segments specified in the cloud, instead of repeatedly uploading the entire first packet of data, thereby reducing network load;

[0176] To illustrate the process, a simplified data processing example can be provided: After parsing the initial reported packet G1, the cloud discovers that the drive state segment D2 is missing, so it issues a supplementary recording instruction M1; after receiving the supplementary recording instruction M1 locally, it outputs a prompt signal H1 through the vibration motor; the operator performs a knob authorization action A1.

[0177] The system uploads only the driver status segment D2 or the related incremental package G2; thus forming a closed loop from the initial reporting package G1, the supplementary recording instruction M1, the prompt signal H1, the authorization action A1 to the incremental package G2, without having to go through the complete fault submission process again;

[0178] As a fault-tolerant strategy, if the terminal is offline when the supplementary recording instruction arrives, the instruction will be cached and executed after the network is restored; if the vibration motor fails and cannot generate haptic feedback, the rotary screen will switch to flashing icons or short text prompts as a substitute.

[0179] If the operator does not provide an authorization signal within the preset time limit, the system will not force the upload of incremental logs, but will remind the operator again in the next idle window of the device to avoid affecting the main ward control business; if the supplementary entry request involves sensitive configurations or historical data that exceeds the preset storage capacity threshold, double confirmation can also be required before execution.

[0180] After the ward terminal reported the fault log for the first time, the cloud determined that it had received the graphics process stack, but still lacked a snapshot of the knob driver register.

[0181] After the system receives the supplementary recording instruction, the linear motor linked to the knob screen vibrates twice. The on-duty nurse senses the prompt during the rounds and rotates the knob once to complete the authorization. The terminal supplements the incremental data of the drive status in the background. The cloud confirms that the root cause of the fault is the contention between the encoder interrupt service and the graphics service, rather than the damage to the motherboard hardware.

[0182] The purpose of this step is to establish a closed loop for subsequent supplementary data entry after an initial report, thereby enabling on-demand completion of cloud-based diagnostic information while reducing interference with core on-site control operations.

[0183] In a preferred embodiment of the present invention, the step of sending the work order processing progress task to the rotary screen for independent refresh display includes: converting the work order processing progress task into a circular progress bar rendering instruction; sending the circular progress bar rendering instruction to the local video memory built into the rotary screen; controlling the main control screen to enter a screen-off sleep state, and independently refreshing and displaying the work order processing progress task corresponding to the circular progress bar rendering instruction through the rotary screen.

[0184] This embodiment provides a mechanism for unloading the display of work order processing progress; specifically, if the main control screen continues to display static pages such as waiting for processing and remote diagnosis after the aforementioned reporting and supplementary recording links are completed, the following technical defects exist: First, if the duration of the main control screen being on exceeds the preset protection threshold, it will lead to excessive system heat dissipation and an increase in hardware attenuation rate.

[0185] Secondly, the main control system still needs to maintain graphics refresh and page keep-alive, which is not conducive to low-power recovery after a failure; therefore, in this embodiment, the work order processing progress is moved to the independent display on the rotary screen.

[0186] Furthermore, the work order processing progress task returned from the cloud is converted into a circular progress bar rendering instruction; the conversion process is not a simple icon replacement, but rather maps discrete work order states such as accepted, processing, pending data entry, and completed into graphic semantics suitable for display on a small-sized rotary screen.

[0187] The circular progress bar is suitable for circular or near-circular display layouts of rotary screens and is consistent with the geometry of the rotary body, maintaining recognizability greater than the preset recognition rate threshold; after the generated rendering command is sent to the local video memory built into the rotary screen, the rotary screen can complete the refresh display without relying on the continuous participation of the main control.

[0188] Once the rotary screen has local video memory and independent refresh capabilities, the main control screen can enter a screen-off sleep state. In this way, the main control processor is freed from waiting for graphics tasks and only needs to maintain communication and low-frequency status checks when necessary. For hospital scenarios, the screen-on time of ward entrance devices at night exceeds the preset nighttime standby standard, which not only consumes energy but may also cause optical environmental interference exceeding the preset index due to strong light. The rotary screen, with its small area and low power consumption, displays the work order progress, which is more in line with the needs of on-site use.

[0189] To illustrate the execution process, a simplified data processing example can be given: the work order status sequence returned by the cloud is as follows: the first status T1 indicates that the order has been accepted, the second status T2 indicates that remote diagnosis is in progress, and the third status T3 indicates that the processing is completed.

[0190] The system converts these three states into corresponding first circular progress bar rendering instructions R1, second circular progress bar rendering instructions R2, and third circular progress bar rendering instructions R3, and writes them into the local video memory of the rotary screen. Even if the main control screen is turned off, the rotary screen can still refresh the display states corresponding to the above three sets of rendering instructions in sequence.

[0191] As a fault-tolerant strategy, if the local video memory of the rotary screen is temporarily unwritable, the system will first display the progress on the main control screen for a short time and periodically retry the download; if the main control screen cannot be turned off immediately due to business requirements, the brightness can be reduced and complex interfaces can be frozen, only the minimum state display can be retained, and the system will enter sleep mode after the rotary screen takes over successfully.

[0192] If the work order status is updated too frequently, the system can merge the updates according to the preset throttling strategy to avoid frequent refreshes affecting the lifespan of the rotary screen.

[0193] After the ward terminal fault log is uploaded, the cloud sequentially returns the task status of accepted orders and remote diagnosis; the system converts it into a circular progress bar rendering instruction that can be recognized by the rotary screen and writes it into the local display memory of the rotary screen;

[0194] The main control screen goes into sleep mode, and staff on duty can see the current processing progress on the rotary screen as soon as they pass through the ward entrance, without having to turn on the main control screen to check.

[0195] The purpose of this step is to migrate the status display during the fault waiting period from the high-power main control display link to the low-power knob display link, thereby reducing energy consumption, releasing the main screen load, and protecting the display lifespan during fault handling.

[0196] In a preferred embodiment of the present invention, before obtaining the cached physical interaction data as the physical interaction fluctuation feature vector corresponding to the knob screen, the method further includes: detecting the hardware connection status of the knob screen, and determining whether to generate a physical disconnection signal based on the detected connection level.

[0197] If a physical circuit breaker signal is generated, the acquisition of physical interaction fluctuation feature vectors will stop, and the watchdog timer built into the main control screen will be triggered to perform timeout reset and routine reporting; if no physical circuit breaker signal is generated, the step of acquiring the cached physical interaction data as the physical interaction fluctuation feature vector corresponding to the knob screen will be executed.

[0198] This embodiment provides an abnormal fallback mechanism for knob screen failure scenarios; specifically, the aforementioned solution is based on the premise that the knob screen can continuously provide reliable physical interaction data, but in the actual device life cycle, connector detachment, encoder power supply abnormality, bus circuit breakage or overall knob module failure may still occur.

[0199] If the knob data is still forcibly used to determine urgency under these circumstances, it will not only fail to reflect the actual operation on site, but may also mislead the fault diversion results due to random voltage levels. Therefore, this embodiment first detects the hardware connection status of the knob screen.

[0200] Furthermore, before formally extracting the physical interaction fluctuation feature vector, the system first detects the connection level of the knob screen; this connection level can come from the bus response status, the dedicated presence detection pin, the pull-up / pull-down identification pin, or the module power readback signal;

[0201] If the test results show that the connection is continuous and stable, it means that the rotary screen is still in a working state, and the system continues to acquire physical interaction data in the cache; if the test results show that the level is floating for a long time, continuously abnormal, or inconsistent with the preset in-position characteristics, a physical circuit breaker signal is generated.

[0202] Once a physical circuit breaker signal is generated, the system immediately stops acquiring subsequent physical interaction fluctuation feature vectors. This is because the knob data no longer has a reliable behavioral mapping meaning at this point, and continuing to calculate the urgency will only amplify the error.

[0203] The system triggers the watchdog timer built into the main control screen to perform a timeout reset and routine reporting; in other words, the system degrades from the collaborative judgment mode to the main control self-recovery mode, at least ensuring that the device can restart and report the knob link abnormality fault type to the cloud.

[0204] To illustrate its boundary logic, a simplified data processing example can be given: the connection detection results in a first state E1 indicating normal connectivity or a second state E2 indicating an untrusted connection; when the detection is the first state E1, the system continues to read the knob buffer and enters the subsequent urgency process;

[0205] When the detection is in the second state E2, the system no longer generates the physical interaction vector V, but instead switches to the watchdog reset path W; in this way, the system clearly isolates the available knob input from the unavailable hardware noise.

[0206] As a fault-tolerance strategy, if the connection level is in a state of level jitter for a duration shorter than the preset debouncing period, the system can set an acknowledgment window. Only when the abnormality lasts for a preset duration will it be judged as a physical open circuit, thus avoiding mistaking a momentary poor contact for a permanent fault. If the knob connection is restored after the watchdog is reset, the collaborative mode can be re-enabled for subsequent fault reporting.

[0207] If the circuit is still detected as open after the reset, the system will add a hardware link abnormality mark in the cloud work order, prompting the user to check the knob module, flexible cable or bus interface first; if the main control screen itself is also in an unrecoverable abnormality, at least the minimum hardware reset action will be reserved to prevent the device from getting stuck in a deadlock state indefinitely.

[0208] After long-term disinfection and maintenance of the ward control terminal, the knob module cable became loose, causing the internal integrated circuit to lose its response. At this time, even if the nurse tries to turn the knob, the system will not treat the abnormal level as a valid interactive fluctuation. Instead, it will first generate a physical circuit breaker signal, stop collaborative calculation, and perform timeout reset and routine reporting through the main control watchdog. After receiving the log, the cloud can directly assign the work order to the on-site hardware repair, instead of misleading it into a general software lag.

[0209] The purpose of this step is to establish a credibility boundary for scenarios where the rotary screen is unavailable, thereby enabling the conditional activation of the collaboration mechanism and avoiding the output of incorrect urgency judgments and incorrect reporting and routing results when the hardware is disconnected.

[0210] Please see Figure 2 A fault reporting system based on the collaboration of the rotary screen and the main control screen is applied to terminal devices that include a main control screen, a rotary screen, a microcontroller, a central processing unit, a direct memory access controller, and flash memory. The system includes:

[0211] The caching module is used to cache the physical interaction data of the rotary screen in real time through a microcontroller that is independent of the main screen rendering thread;

[0212] The acquisition module is used to acquire system abnormal interruption signals. In response to the system abnormal interruption signals, it acquires the cached physical interaction data as the physical interaction fluctuation feature vector corresponding to the knob screen, and acquires the system snapshot parameters corresponding to the main control screen.

[0213] The processing module is used to extract features from the physical interaction fluctuation feature vector based on a preset time window starting from the system abnormal interruption signal, so as to obtain the angular acceleration parameter and the number of presses parameter, and obtain the urgency index through the angular acceleration parameter and the number of presses parameter;

[0214] The execution module is used to compare the urgency index with the preset urgency threshold. If the urgency index is less than the preset urgency threshold, the normal diagnosis mode is triggered. If the urgency index is greater than or equal to the preset urgency threshold, the collaborative diversion mode is triggered to dump the system snapshot parameters and obtain the log package to be reported.

[0215] The feedback module is used to send the log package to be reported to the preset cloud server, receive the work order processing progress task returned by the preset cloud server, and send the work order processing progress task to the rotary screen for independent refresh display.

[0216] This embodiment provides a fault reporting system based on the collaboration of a rotary screen and a main control screen; specifically, the system can be deployed in the aforementioned bedside environmental control terminal of a hospital negative pressure isolation ward, or in other industrial or medical terminals with main control display, rotary input and network diagnostic capabilities;

[0217] The system can be functionally divided into a caching module, an acquisition module, a processing module, an execution module, and a feedback module. Each module can be implemented by an independent hardware unit or by firmware and drivers in a layered manner on the same control board.

[0218] Furthermore, the cache module is deployed on the side close to the knob input link. Its core function is to be independent of the main control screen rendering thread and continuously save the underlying physical interaction data of the knob screen.

[0219] After detecting an abnormal interruption signal, the acquisition module extracts the knob interaction fragments from the cache module and organizes them into a physical interaction fluctuation feature vector. On the other hand, it organizes system snapshot parameters from the system log and memory status.

[0220] The processing module extracts the feature vectors in a windowed manner to form angular acceleration parameters and number of presses parameters, and generates an urgency index based on the two.

[0221] The execution module switches paths based on the urgency threshold: when the urgency is low, it enters the regular diagnostic mode; when the urgency is high, it enters the collaborative diversion mode, prioritizing the protection of fault evidence through main screen suspension, log dumping, and rapid reporting.

[0222] The feedback module is responsible for sending the log package to be reported to the cloud, receiving the work order progress or supplementary entry task returned by the cloud, and then displaying the processing result independently on the rotary screen.

[0223] To further illustrate the data relationships between modules, a simplified data processing example can be provided: the caching module outputs an interaction fragment K1, the acquisition module combines the interaction fragment K1 with the system fragment S1 to form an input set J1; the processing module extracts features from the knob fragments in the input set J1 to generate a unified urgency index U.

[0224] The execution module determines whether to trigger the normal diagnostic mode's boot path P1 or the collaborative diversion mode's fast dump path P2 based on the urgency index U; the feedback module uploads the log results generated by the boot path P1 or the fast dump path P2 and maps the cloud return status to the display task D1.

[0225] It is evident that this system is not a single software interface program, but a complete technical architecture covering input acquisition, anomaly evidence collection, traffic diversion and execution, and status feedback.

[0226] As a fault-tolerance strategy, if the caching module malfunctions, the acquisition module can directly mark the knob input confidence as decreased and switch to a conservative path by the execution module; if the acquisition module can only obtain a partial system snapshot, the processing module can still output the basic urgency based on the existing knob data, but the execution module will prioritize retaining the summary information in the dumping strategy.

[0227] If the network on which the feedback module depends is unavailable, the log packets to be reported will be stored on the ground first and resent after the network is restored; if multiple modules fail at the same time, the system will at least maintain the minimum watchdog reset and local summary reporting capabilities to avoid completely losing the ability to record faults.

[0228] When the graphics service, network service, and knob service of the ward terminal are all in a high-concurrency working state, the cache module continuously saves the operation fragments of the on-duty nurses on the knobs.

[0229] Once the main control interface freezes due to an abnormal interruption, the acquisition module immediately captures this physical interaction and system snapshot. The processing module outputs a high urgency level based on this. The execution module switches to the collaborative routing path and completes the dump. The feedback module sends the log to the cloud and displays the work order progress on the rotary screen.

[0230] Throughout the process, the main control screen, rotary screen, microcontroller, central processing unit, direct memory access controller and flash memory form a clear hardware collaboration relationship;

[0231] The purpose of this system is to expand fault reporting from a simple software submission action into a feasible hardware and software collaborative system, thereby achieving reliable input collection, reliable log preservation, rapid fault reporting, and low-power feedback of work order status in abnormal scenarios.

[0232] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the claims of this invention should still fall within the patent coverage of this invention.

Claims

1. A fault reporting method based on the collaboration of a rotary screen and a main control screen, applied to a terminal device including a main control screen, a rotary screen, a microcontroller, a central processing unit, a direct memory access controller, and flash memory, characterized in that, Includes the following steps: The microcontroller, which operates independently of the main screen rendering thread, caches the physical interaction data of the rotary screen in real time. The system abnormal interrupt signal is obtained through the central processing unit. In response to the system abnormal interrupt signal, the cached physical interaction data is obtained as the physical interaction fluctuation feature vector corresponding to the knob screen, and the system snapshot parameter corresponding to the main control screen is obtained. Based on a preset time window starting from the abnormal interruption signal of the system, feature extraction is performed on the physical interaction fluctuation feature vector to obtain angular acceleration parameters and number of presses parameters, and the urgency index is obtained through the angular acceleration parameters and the number of presses parameters. The urgency index is compared with a preset urgency threshold. If the urgency index is less than the preset urgency threshold, a normal diagnosis mode is triggered. If the urgency index is greater than or equal to the preset urgency threshold, a collaborative diversion mode is triggered to dump the system snapshot parameters and obtain the log package to be reported. The log packet to be reported is sent to a preset cloud server, the work order processing progress task returned by the preset cloud server is received, and the work order processing progress task is sent to the rotary screen for independent refresh display. The steps of obtaining the cached physical interaction data as the physical interaction fluctuation feature vector corresponding to the knob screen and obtaining the system snapshot parameters corresponding to the main control screen include: The pulse count change rate of the photoelectric encoder configured on the knob screen and the level transition edge of the micro switch are read through a preset bus, and the pulse count change rate and the level transition edge are converted into a physical interaction fluctuation feature vector. The system kernel log service captures the memory pointer address and runtime data when the system abnormal interrupt signal is triggered. The memory pointer address and runtime data are decoupled into a system summary status word and a full stack dump data. The system snapshot parameters are constructed using the system summary status word and the full stack dump data.

2. The fault reporting method based on the collaboration of the rotary screen and the main control screen according to claim 1, characterized in that, The steps for obtaining the urgency index using the angular acceleration parameter and the number of presses parameter include: Obtain the root mean square value of angular acceleration corresponding to the angular acceleration parameter, and obtain the number of presses corresponding to the number of presses parameter; Obtain a first preset weighting coefficient corresponding to the root mean square value of the angular acceleration, and obtain a second preset weighting coefficient corresponding to the number of presses; Based on the first preset weighting coefficient and the second preset weighting coefficient, the root mean square value of angular acceleration and the number of presses are linearly weighted to obtain the urgency index.

3. The fault reporting method based on the collaboration of the rotary screen and the main control screen according to claim 2, characterized in that, The step of obtaining the urgency index by linearly weighting the root mean square value of angular acceleration and the number of presses based on the first preset weighting coefficient and the second preset weighting coefficient includes: using the formula Obtain the urgency index; in, As an urgency index, The root mean square value of the angular acceleration. The first preset weighting coefficient, The number of presses. This is the second preset weighting coefficient.

4. The fault reporting method based on the collaboration of the rotary screen and the main control screen according to claim 1, characterized in that, The steps of triggering the collaborative traffic splitting mode to dump data from the system snapshot parameters and obtain the log packet to be reported include: Suspend the rendering thread of the main control screen and render a floating window of a preset style on the main control screen; Trigger the direct memory access controller to extract the full stack dump data from the system snapshot parameters through the direct memory access controller; The full stack dump data is written to the preset reserved area of ​​the flash memory by bypassing the central processing unit, so as to package the full stack dump data into a log package to be reported.

5. The fault reporting method based on the collaboration of the rotary screen and the main control screen according to claim 1, characterized in that, The steps to trigger the standard diagnostic mode include: The troubleshooting guide menu is rendered on the main control screen, and an interactive cursor is generated in the troubleshooting guide menu; The current cursor position of the interactive cursor is obtained through the rotary screen; Obtain the rotation operation signal based on the knob screen, and determine the target fault node in the troubleshooting guidance menu based on the rotation operation signal and the current cursor position.

6. The fault reporting method based on the collaboration of the rotary screen and the main control screen according to claim 1, characterized in that, After sending the log packet to be reported to the preset cloud server, the process also includes: Receive a supplementary recording instruction issued by the preset cloud server based on the missing status data determined by parsing the log packet to be reported; In response to the supplementary recording instruction, a vibration motor configured in the terminal device and linked to the rotary screen is driven to generate physical vibration at a preset frequency to generate a supplementary recording prompt signal; Obtain the rotation authorization signal triggered by the supplementary recording prompt signal, and upload the incremental log package in the background based on the rotation authorization signal.

7. The fault reporting method based on the collaboration of the rotary screen and the main control screen according to claim 1, characterized in that, The steps of sending the work order processing progress task to the rotary screen for independent refresh display include: Convert the work order processing progress task into a circular progress bar rendering instruction; The rendering command for the circular progress bar is sent to the local video memory built into the rotary screen; The main control screen is controlled to enter a screen-off sleep state, and the work order processing progress task corresponding to the circular progress bar rendering instruction is independently refreshed and displayed through the rotary screen.

8. The fault reporting method based on the collaboration of the rotary screen and the main control screen according to claim 1, characterized in that, Before obtaining the cached physical interaction data as the physical interaction fluctuation feature vector corresponding to the rotary screen, the method further includes: The hardware connection status of the rotary screen is detected, and a physical disconnection signal is determined based on the detected connection level. If the physical circuit breaker signal is generated, the acquisition of the physical interaction fluctuation feature vector will stop, and the watchdog timer built into the main control screen will be triggered to perform timeout reset and routine reporting. If the physical circuit breaker signal is not generated, then the step of obtaining the cached physical interaction data as the physical interaction fluctuation feature vector corresponding to the knob screen is executed.

9. A fault reporting system based on the collaboration of a rotary screen and a main control screen, applied to a terminal device including a main control screen, a rotary screen, a microcontroller, a central processing unit, a direct memory access controller, and flash memory, characterized in that, The system includes: A caching module is used to cache the physical interaction data of the rotary screen in real time through the microcontroller, which is independent of the main control screen rendering thread; The acquisition module is used to acquire system abnormal interruption signals, and in response to the system abnormal interruption signals, acquire the cached physical interaction data as the physical interaction fluctuation feature vector corresponding to the knob screen, and acquire the system snapshot parameters corresponding to the main control screen. The processing module is used to extract features from the physical interaction fluctuation feature vector based on a preset time window starting from the abnormal interruption signal of the system, so as to obtain angular acceleration parameters and pressing number parameters, and obtain the urgency index through the angular acceleration parameters and the pressing number parameters. The execution module is used to compare the urgency index with a preset urgency threshold. If the urgency index is less than the preset urgency threshold, the normal diagnosis mode is triggered. If the urgency index is greater than or equal to the preset urgency threshold, the collaborative diversion mode is triggered to dump the system snapshot parameters and obtain the log package to be reported. The feedback module is used to send the log package to be reported to a preset cloud server, receive the work order processing progress task returned by the preset cloud server, and send the work order processing progress task to the rotary screen for independent refresh display. The steps of obtaining the cached physical interaction data as the physical interaction fluctuation feature vector corresponding to the knob screen and obtaining the system snapshot parameters corresponding to the main control screen include: The pulse count change rate of the photoelectric encoder configured on the knob screen and the level transition edge of the micro switch are read through a preset bus, and the pulse count change rate and the level transition edge are converted into a physical interaction fluctuation feature vector. The system kernel log service captures the memory pointer address and runtime data when the system abnormal interrupt signal is triggered. The memory pointer address and runtime data are decoupled into a system summary status word and a full stack dump data. The system snapshot parameters are constructed using the system summary status word and the full stack dump data.

Images