A cardiovascular monitoring device operation status data acquisition and remote monitoring system

Abstract

This invention discloses a cardiovascular monitoring device operation status data acquisition and remote monitoring system, specifically relating to the field of IoT medical device big data acquisition technology. It addresses the problem in existing remote acquisition methods where silent semantic changes in data frames caused by firmware upgrades of cardiovascular monitoring devices prevent the acquisition end from perceiving semantic migration, leading to data distortion of the device operation status uploaded to a remote server. The system works by comparing firmware version identifiers to determine firmware upgrade events, using device status change event response patterns to locate the semantic migration range, reconstructing the mapping relationship between field offset positions and device operation status parameters based on the migration range, and then parsing the data frames based on the reconstructed mapping to obtain the device operation status parameters before uploading them to a remote server.

Description

Technical Field

[0001] This invention relates to the field of big data acquisition technology for Internet of Things (IoT) medical devices, and more specifically, to a system for acquiring and remotely monitoring the operational status data of cardiovascular monitoring devices. Background Technology

[0002] Cardiovascular monitoring equipment is a key medical device used in clinical diagnosis and treatment to monitor patients' vital signs, including various types such as electrocardiogram (ECG) monitors, Holter monitors, and blood pressure monitors. Currently, hospital monitoring centers mainly rely on regular manual inspections and local storage for exporting the operational status of these devices. Medical staff need to check the device screens one by one or manually download logs to understand the device's working status. To overcome the timeliness limitations of manual inspections, remote data acquisition solutions based on IoT architecture have emerged in the industry. This involves adding data acquisition terminals to the devices and uploading the devices' operating parameters, signal quality indicators, and abnormal alarm information to a remote server via the network, allowing medical staff to view them remotely through monitoring terminals. Furthermore, because different manufacturers and models of cardiovascular monitoring equipment use their own proprietary data output formats and communication protocols, existing systems typically include protocol parsing modules to convert and uniformly store heterogeneous data, forming a dataset of device operational status data that can be queried and analyzed.

[0003] However, during the aforementioned remote data acquisition process, the firmware of cardiovascular monitoring devices may change due to manufacturer maintenance and upgrades. Such upgrades may adjust the physical meaning mapping of specific fields in the device's internal status register without altering the data frame length and verification rules. For example, a field that originally represented electrode detachment at a certain offset position may be changed to represent the remaining capacity of the backup battery. Existing data acquisition terminals only perform format integrity and verification of data frames and cannot perceive the semantic changes of fields after firmware upgrades. This results in the device operating status data stored in the remote database having a field meaning that deviates from the actual device status, even though the storage format appears to be completely normal. Consequently, subsequent device operating status analysis and anomaly judgment based on this data become distorted, reducing the accuracy and reliability of the remote monitoring system's assessment of the device's true status. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, the present invention provides a cardiovascular monitoring device operation status data acquisition and remote monitoring system to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A cardiovascular monitoring device operation status data acquisition and remote monitoring system includes: The version acquisition module is used to receive data frames sent by the cardiovascular monitoring device and obtain the current firmware version identifier of the cardiovascular monitoring device. The upgrade determination module is used to compare the current firmware version identifier with the previous firmware version identifier, and determine that a firmware upgrade event has occurred if they are inconsistent. The pattern comparison module is used to monitor device status change events after a firmware upgrade event is determined, compare the response patterns of fields at different offset positions before and after the upgrade to the same type of device status change event, and identify the field offset positions where the response patterns have shifted. The migration determination module is used to construct a field response association graph with the fields at the field offset positions where the response mode has changed as nodes, perform spectral decomposition on the field response association graph before and after the upgrade and measure the difference in graph features, and determine and obtain the range of field offset positions where field semantic migration has occurred. The relationship reconstruction module is used to rebuild the mapping relationship between field offset positions and device operating status parameters based on the range of field offset positions where field semantic migration has occurred. The parameter parsing module is used to parse subsequent data frames based on the reconstructed mapping relationship, obtain device operating status parameters, and upload them to the remote server.

[0006] Furthermore, the system receives data frames sent by the cardiovascular monitoring device and obtains the current firmware version identifier of the cardiovascular monitoring device, including: Receive data frames sent by cardiovascular monitoring equipment; Extract the firmware version number field carried at the preset field offset position in the data frame; If the firmware version number field is successfully extracted, the value of the firmware version number field will be used as the current firmware version identifier. If the firmware version number field fails to be extracted, a version query command is sent to the cardiovascular monitoring device, and the firmware version information returned by the cardiovascular monitoring device is received and used as the current firmware version identifier.

[0007] Furthermore, the current firmware version identifier is compared with the previous firmware version identifier. If they do not match, a firmware upgrade event is determined, including: Retrieve the identifier of the previous firmware version stored locally; Compare the string identifying the current firmware version with the string identifying the previous firmware version; If the string of the current firmware version identifier is different from the string of the previous firmware version identifier, then a firmware upgrade event is determined to have occurred, and the previous firmware version identifier is updated to the current firmware version identifier. If the string identifying the current firmware version is the same as the string identifying the previous firmware version, it is determined that no firmware upgrade event has occurred, and the previous firmware version identifier remains unchanged.

[0008] Furthermore, after identifying firmware upgrade events, monitor device state change events, compare the response patterns of fields at different offset positions before and after the upgrade to the same type of device state change events, and identify the field offset positions where the response pattern has shifted, including: Once a firmware upgrade event is identified, continuously monitor device status change events generated by the cardiovascular monitoring device. Record the change in value of each field at its offset position before and after the event occurs when a device status change event occurs; Compare the value change of the field at the same offset position under the same type of device status change event before the firmware upgrade with the value change after the firmware upgrade; If the difference in value of a field at the same offset position under the same type of device status change event exceeds a preset change threshold before and after the firmware upgrade, the corresponding field offset position will be determined as the field offset position where the response mode has changed.

[0009] Furthermore, a response association graph between fields is constructed using the fields at the offset positions where the response mode shift occurs as nodes. The response association graphs before and after the upgrade are subjected to spectral decomposition, and the differences in spectral features are measured. The range of field offset positions where semantic migration occurs is determined and obtained, including: The field at the offset position of the field where the response mode shifts is used as the node; Calculate the correlation of the numerical changes of any two nodes in multiple similar device state change events before the firmware upgrade, and use it as the weight of the edge between the corresponding nodes before the firmware upgrade to construct the response association graph between fields before the firmware upgrade. Calculate the correlation of the numerical changes of any two nodes in multiple similar device state change events after firmware upgrade, and use it as the weight of the edge between the corresponding nodes after firmware upgrade to construct the response association graph between fields after firmware upgrade. Spectral decomposition was performed on the adjacency matrix of the field response correlation graph before and after the firmware upgrade to obtain the eigenvalue sequence before and after the firmware upgrade. Calculate the relative entropy between the feature value sequence before firmware upgrade and the feature value sequence after firmware upgrade, as the difference in map features; The field offset positions corresponding to nodes whose graph feature differences exceed the graph difference threshold are determined as the field offset positions where field semantic migration occurs. The range of field offset positions where field semantic migration occurs is formed by all the field offset positions where field semantic migration occurs.

[0010] Furthermore, the correlation of the numerical changes of any two nodes in multiple similar device state change events before the firmware upgrade is calculated as the weight of the edge between the corresponding nodes before the firmware upgrade. This includes: recording the numerical change of the field at the field offset position corresponding to each node under each similar device state change event before the firmware upgrade; and calculating the correlation coefficient of the numerical changes of any two nodes in multiple similar device state change events as the weight of the edge between the two nodes before the firmware upgrade.

[0011] Furthermore, spectral decomposition is performed on the adjacency matrices of the inter-field response association graph before and after the firmware upgrade, respectively, to obtain the eigenvalue sequences before and after the firmware upgrade. This includes: constructing the adjacency matrices of the inter-field response association graph before and after the firmware upgrade; performing eigenvalue decomposition on the adjacency matrix before the firmware upgrade, arranging the eigenvalues ​​in descending order to obtain the eigenvalue sequence before the firmware upgrade; and performing eigenvalue decomposition on the adjacency matrix after the firmware upgrade, arranging the eigenvalues ​​in descending order to obtain the eigenvalue sequence after the firmware upgrade.

[0012] Furthermore, the relative entropy between the feature value sequence before and after the firmware upgrade is calculated as the difference in spectral features. This includes: normalizing the feature value sequence before and after the firmware upgrade to obtain the normalized feature value distribution before and after the firmware upgrade; and calculating the KL divergence between the normalized feature value distribution before and after the firmware upgrade as the difference in spectral features.

[0013] Furthermore, based on the range of field offset positions where semantic migration occurs, the mapping relationship between field offset positions and device operating status parameters is reconstructed, including: Obtain the mapping relationship between the field offset position before firmware upgrade and the device operating status parameters; Remove the field offset position range that has undergone semantic migration from the mapping relationship between the field offset position and the device operating status parameters before the firmware upgrade to obtain the mapping relationship of the unmigrated fields; For each field offset position within the range of field offset positions where field semantic migration occurs, a mapping entry between the corresponding field offset position and the device operating status parameters is established based on the correspondence between the numerical change characteristics of the corresponding field offset position after firmware upgrade and the device operating status parameters. The mapping relationship between the unmigrated fields is merged with the mapping entries established for each field offset position within the range of field offset positions where field semantic migration has occurred, resulting in a reconstructed mapping relationship between the field offset positions and the device operating status parameters.

[0014] Furthermore, subsequent data frames are parsed based on the reconstructed mapping relationship to obtain device operating status parameters, which are then uploaded to a remote server, including: Receive subsequent data frames sent by the cardiovascular monitoring device after a firmware upgrade event; Based on the reconstructed mapping relationship between field offset positions and device operating status parameters, the corresponding field values ​​are extracted from each field offset position in subsequent data frames, and the field values ​​are converted into the corresponding device operating status parameters. The converted device operating status parameters, along with the current firmware version identifier of the cardiovascular monitoring device, are uploaded to the remote server.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention's system, through the cooperation of a version acquisition module and an upgrade determination module, can automatically capture firmware version changes in cardiovascular monitoring devices caused by manufacturer maintenance. This provides a triggering basis for timely detection of firmware upgrade events, avoiding the continuous collection of semantically skewed device operation status data due to undetected firmware upgrades. The pattern comparison module uses device status change events such as electrode detachment alarms and lead switching generated during device operation as detection signals. It can complete the initial identification of field response pattern shifts without interrupting normal device operation, ensuring that the detection of field semantic migration is based on real data from actual operating scenarios, rather than relying on external test injection. The migration determination module constructs a response correlation graph between fields using fields where response patterns have shifted as nodes. Through spectral decomposition and graph feature difference measurement, it determines the range of semantic migration from changes in the relationship structure between fields. This elevates the detection of field semantic migration from the level of single-field numerical statistics to the level of multi-field relationship structure, enabling the capture of hidden migration situations where the numerical distribution of a single field has not changed significantly, but the relationship between fields has been reorganized. This allows for a more complete definition of the range of field offset positions affected by firmware upgrades.

[0016] 2. The relationship reconstruction module, based on the semantic migration range determined by the migration judgment module, retains the mapping relationships of unmigrated fields. It only reconstructs mapping entries for field offsets where semantic migration has actually occurred and merges them with the unmigrated portions. This achieves localized, precise repair of mapping relationships rather than global reconstruction, reducing uncertainty during the reconstruction process while ensuring the correctness of the mapping relationships. The parameter parsing module uses the repaired mapping relationships to parse subsequent data frames, ensuring that the device operating status parameters uploaded to the remote server always maintain a correct correspondence with their physical meaning. This guarantees the semantic consistency and reliability of the large dataset of device operating status data aggregated by the remote monitoring center, providing a reliable data foundation for subsequent device operating status analysis and anomaly detection based on this dataset. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the structure of a cardiovascular monitoring device operation status data acquisition and remote monitoring system according to the present invention. Detailed Implementation

[0018] 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.

[0019] Example: Figure 1 A schematic diagram of a cardiovascular monitoring device operation status data acquisition and remote monitoring system is provided according to the present invention. The cardiovascular monitoring device operation status data acquisition and remote monitoring system includes: The version acquisition module is used to receive data frames sent by the cardiovascular monitoring device and obtain the current firmware version identifier of the cardiovascular monitoring device. The upgrade determination module is used to compare the current firmware version identifier with the previous firmware version identifier, and determine that a firmware upgrade event has occurred if they are inconsistent. The pattern comparison module is used to monitor device status change events after a firmware upgrade event is determined, compare the response patterns of fields at different offset positions before and after the upgrade to the same type of device status change event, and identify the field offset positions where the response patterns have shifted. The migration determination module is used to construct a field response association graph with the fields at the field offset positions where the response mode has changed as nodes, perform spectral decomposition on the field response association graph before and after the upgrade and measure the difference in graph features, and determine and obtain the range of field offset positions where field semantic migration has occurred. The relationship reconstruction module is used to rebuild the mapping relationship between field offset positions and device operating status parameters based on the range of field offset positions where field semantic migration has occurred. The parameter parsing module is used to parse subsequent data frames based on the reconstructed mapping relationship, obtain device operating status parameters, and upload them to the remote server.

[0020] The specific implementation process for receiving data frames sent by the cardiovascular monitoring device and obtaining the current firmware version identifier of the cardiovascular monitoring device is as follows: Cardiovascular monitoring equipment periodically sends data frames out through its data output interface, following a pre-defined communication protocol. Each data frame is a sequence of numbers arranged in byte order, carrying various parameters from the monitoring equipment's operation. Receiving data frames from the monitoring equipment involves listening for and capturing these frames via an IoT communication interface.

[0021] The type of IoT communication interface is determined based on the data output interface of the cardiovascular monitoring device. For example, if the data output interface of the cardiovascular monitoring device is a serial communication interface, the IoT communication interface will be configured accordingly as a serial communication interface; if the data output interface of the cardiovascular monitoring device is an Ethernet interface, the IoT communication interface will be configured accordingly as an Ethernet interface; and if the data output interface of the cardiovascular monitoring device is a wireless LAN interface, the IoT communication interface will be configured accordingly as a wireless LAN interface. After a data frame is captured, all bytes of the data frame are temporarily stored in a buffer.

[0022] Before extracting the firmware version number field carried at a preset field offset position in the data frame, the preset field offset position needs to be determined first. The preset field offset position is pre-generated based on the cardiovascular monitoring device's model and device protocol description. Specifically, for each model of cardiovascular monitoring device, the data frame structure definition document is analyzed beforehand, or the field distribution of the data frame is obtained through protocol reverse engineering. The byte offset of the firmware version number field and the byte length occupied by the firmware version number field are found from the field distribution of the data frame. This byte offset and byte length information are then associated and stored with the cardiovascular monitoring device's model to form the preset field offset position information. When receiving a data frame, the model of the cardiovascular monitoring device sending the data frame needs to be obtained. The model of the cardiovascular monitoring device can be read from the device model field at a fixed offset position in the received data frame, or it can be directly determined based on the device identifier bound to the IoT communication interface. Based on the cardiovascular monitoring device's model, the firmware version number field offset and firmware version number field length corresponding to the cardiovascular monitoring device's model are selected from the stored preset field offset position information.

[0023] The process of extracting the firmware version number field from the preset offset position in the data frame is as follows: Starting from the beginning of the data frame byte sequence in the buffer, locate the corresponding byte position according to the selected firmware version number field offset. Read a continuous sequence of bytes of a specified length from the located byte position; the read contiguous bytes are the firmware version number field. The value of the firmware version number field usually represents the firmware version information in the form of ASCII characters or binary encoding. After reading, the value of the firmware version number field is converted into a readable string or number form as the version identifier to be used.

[0024] The system then checks whether the firmware version number field was successfully extracted. Successful extraction is determined by the following conditions: a complete set of bytes of the specified length can be read from the preset field offset, and the read byte content conforms to the expected format of the firmware version number field. The expected format is validated for methods such as parity checking of the read byte content; if the check is correct, it conforms to the expected format; or by checking whether the read value is within the preset range of valid version number values; if it is, it conforms to the expected format. If the extraction success conditions are met, the converted readable string or number is directly used as the current firmware version identifier of the cardiovascular monitoring device.

[0025] If firmware version number extraction fails—for example, if the bytes read at the preset field offset are empty, a validation error occurs, or the value exceeds the range of valid version numbers—it indicates that the data frame may not contain the firmware version number field, or that a firmware upgrade has changed the field offset, rendering the original preset offset inaccurate. In this case, a backup active query mechanism is activated, sending a version query command to the cardiovascular monitoring device. The version query command is a specific data frame conforming to the cardiovascular monitoring device's proprietary communication protocol. Its format includes a command code, defined by the device manufacturer, used to request the cardiovascular monitoring device to return its current firmware version information. The method of sending the version query command is the same as the communication interface used to receive the data frame; the version query command is sent to the cardiovascular monitoring device through the IoT communication interface used when receiving the data frame.

[0026] Upon receiving a version query command, the cardiovascular monitoring device generates a response data frame containing firmware version information according to its firmware program logic and sends the response data frame back. The system then receives the firmware version information returned by the cardiovascular monitoring device, i.e., listens for and captures the response data frame, extracting the firmware version information field from it. The format of the response data frame is clearly defined in the cardiovascular monitoring device's proprietary communication protocol, thus allowing for the correct parsing of the firmware version information from a predetermined offset position. The parsed firmware version information is used as the current firmware version identifier of the cardiovascular monitoring device.

[0027] The method of passively extracting the firmware version number field from the data frame and then actively sending a version query command and receiving firmware version information to obtain the current firmware version identifier is adopted because the field distribution within the data frame may change after a firmware update, causing the originally preset firmware version number field position to become invalid. Passive extraction can efficiently obtain the version identifier directly in most cases, while active querying can reliably obtain version information when extraction fails due to field offset changes, ensuring that firmware upgrade events are not missed due to field offset changes, and providing an accurate current firmware version identifier for the cardiovascular monitoring device for subsequent accurate determination of firmware upgrade events.

[0028] While obtaining firmware version information through the version query command and using it as the current firmware version identifier, it can also reverse verify and update the offset of the firmware version number field and the length of the firmware version number field corresponding to the device model of the cardiovascular monitoring device in the stored preset field offset position information according to the actual format of the returned response data frame. This allows the firmware version number field to be passively extracted directly from the data frame during subsequent data frame reception, reducing the number of active queries.

[0029] The specific process for determining a firmware upgrade event by comparing the current firmware version identifier with the previous firmware version identifier and identifying discrepancies is as follows: Before comparing the current firmware version identifier with the previous firmware version identifier, it is necessary to first obtain the previously stored firmware version identifier. The previous firmware version identifier is the version identifier information saved during the last firmware upgrade event determination. This identifier is stored in non-volatile storage media, such as flash memory, ensuring that the previous firmware version identifier is not lost after a power outage and restart of the cardiovascular monitoring device or IoT communication interface. When obtaining the previously stored firmware version identifier, the string content of the identifier is read from a specified storage address on the non-volatile storage media. If no previous firmware version identifier has been written to the specified storage address, such as during the first firmware upgrade event determination of the cardiovascular monitoring device, the content read will be empty or a factory default value.

[0030] Comparing the current firmware version identifier string with the previous firmware version identifier string means comparing the two version identifier strings character by character in sequence. The comparison method is as follows: The character encoding values ​​at the same character positions in both version identifier strings are compared sequentially. If the character encoding values ​​at all character positions are the same, the two version identifier strings are considered identical; if the character encoding values ​​at any character position are different, the two version identifier strings are considered inconsistent. The current firmware version identifier string refers to the string corresponding to the current firmware version identifier that has already been obtained, and the previous firmware version identifier string refers to the string corresponding to the previous firmware version identifier read from non-volatile storage media.

[0031] If the string representing the current firmware version identifier is different from the string representing the previous firmware version identifier, a firmware upgrade event is determined to have occurred. Determining a firmware upgrade event means that the firmware of the cardiovascular monitoring device has been updated between the two version identifier comparisons. Firmware updates may involve rearranging the field offset positions in the data frame. After determining that a firmware upgrade event has occurred, the previous firmware version identifier stored in the non-volatile storage medium needs to be updated to the current firmware version identifier. This means writing the string representing the current firmware version identifier to a designated storage address on the non-volatile storage medium, overwriting the original previous firmware version identifier. This ensures that the updated previous firmware version identifier can be used as the comparison benchmark for the next firmware upgrade event determination.

[0032] If the string representing the current firmware version identifier matches the string representing the previous firmware version identifier, it is determined that no firmware upgrade event has occurred. Determining that no firmware upgrade event has occurred indicates that the firmware of the cardiovascular monitoring device has not been updated since the last version identifier comparison, and the field offset position in the data frame has not changed due to a firmware update. In the case of determining that no firmware upgrade event has occurred, the previous firmware version identifier stored in the non-volatile storage medium is retained unchanged; that is, no write operation is performed on the specified storage address of the non-volatile storage medium, so that the previous firmware version identifier continues to be the reference for the current version identifier.

[0033] The method of comparing characters one by one to determine whether the current firmware version identifier is consistent with the previous firmware version identifier is used because the firmware version identifier is usually composed of numbers and separators. Each character position in the version identifier string has a clear semantic meaning. Only when the two version identifier strings are completely identical in all character positions can it be determined that the firmware of the cardiovascular monitoring device has not changed. Differences in the character encoding value at any character position may correspond to changes in the major version number, minor version number, revision number, or build number in the firmware version. Changes in the major version number, minor version number, revision number, or build number in the firmware version may be accompanied by a rearrangement of the field offset positions in the data frame.

[0034] By comparing version identifier strings to determine firmware upgrade events, the system can automatically detect firmware upgrade events as soon as they occur. This provides an accurate time reference point for comparing response patterns of subsequent device state change events, enabling accurate differentiation between device state change events before and after the firmware upgrade. This avoids misjudgment caused by mixing device state change events from two different firmware versions for comparison.

[0035] After identifying firmware upgrade events, monitor device status change events, compare the response patterns of fields at different offset positions before and after the upgrade to the same type of device status change events, and identify the field offset positions where the response pattern has shifted. The specific implementation process is as follows: After confirming a firmware upgrade event, continuous monitoring of device status change events generated by the cardiovascular monitoring device is initiated. Device status change events refer to specific events that occur during the operation of the cardiovascular monitoring device and reflect changes in its working status. These events include, but are not limited to, electrode detachment alarm events, signal overload alarm events, lead switching events, low battery alarm events, and device self-test completion events. Continuous monitoring involves uninterruptedly listening to the data frames reported by the cardiovascular monitoring device through the IoT communication interface and identifying any changes in field values ​​related to device status change events. When a change in a field value related to a device status change event is detected, a device status change event is determined to have occurred, and the specific event type and time of occurrence are recorded.

[0036] While recording device status change events, it is also necessary to record the change in value of each field at its offset position before and after the event. Each field offset position refers to the starting byte offset position of each field carrying device operating parameters in the complete byte sequence of the data frame. For each field offset position in the data frame, the field value within a preset time window before the event is obtained as the pre-event field value, and the field value within a preset time window after the event is obtained as the post-event field value. The time window lengths for the pre-event and post-event field values ​​are determined based on the device model of the cardiovascular monitoring device and the event type of the device status change event. For example, the time window length for an electrode detachment alarm event is set to the maximum response delay time of the device for that event. The change in value refers to the difference between the post-event field value and the pre-event field value, which can be expressed as an absolute difference or a relative change ratio.

[0037] Comparing the numerical changes of the same field at the same offset position under the same type of device status change event before and after the firmware upgrade is a core step in identifying the shift in response pattern. Same-type device status change events refer to device status change events with the same event type identifier, such as both being electrode detachment alarm events or both being lead switching events. The numerical change before the firmware upgrade refers to the numerical change extracted from the device status change event records before the firmware upgrade event occurred, while the numerical change after the firmware upgrade refers to the numerical change extracted from the device status change event records after the firmware upgrade event occurred. The time boundary before and after the firmware upgrade event is used to determine the moment the firmware upgrade event occurred. During the comparison, for the same field offset position, the numerical changes before the firmware upgrade under multiple same-type device status change events are taken as the sample of changes before the firmware upgrade, and the numerical changes after the firmware upgrade under multiple same-type device status change events are taken as the sample of changes after the firmware upgrade.

[0038] The preset change threshold is used to determine whether the difference in numerical change is significant. The preset change threshold is set based on the cardiovascular monitoring device model and the field type where the monitored field offset position is located. The preset change threshold is set as follows: when the cardiovascular monitoring device is in a normal firmware state without firmware upgrade events, collect the numerical changes of the field at each field offset position under multiple similar device state change events as a baseline sample set; calculate the standard deviation and mean of the numerical changes in the baseline sample set, and use the mean plus three times the standard deviation as the preset change threshold for the corresponding field offset position. When setting the threshold, the multiplier parameter can be adjusted according to the hardware specifications and signal characteristics of the cardiovascular monitoring device. For example, the multiplier parameter can be appropriately increased for field types with large signal fluctuations, and appropriately decreased for field types with high signal stability.

[0039] During the comparison process, the specific method for using a preset change threshold as the judgment criterion is as follows: Calculate the average of the change samples before firmware upgrade under multiple similar device status change events, as the average change before firmware upgrade; calculate the average of the change samples after firmware upgrade under multiple similar device status change events, as the average change after firmware upgrade; calculate the absolute value of the difference between the average change before firmware upgrade and the average change after firmware upgrade, as the difference in numerical change before and after firmware upgrade. If the difference in numerical change before and after firmware upgrade exceeds the corresponding preset change threshold, the corresponding field offset position is determined as the field offset position where the response mode has shifted.

[0040] The physical meaning of identifying the corresponding field offset position as the field offset position where the response mode has shifted is as follows: Before the firmware upgrade, the field value at the corresponding field offset position could produce a response change of a specific magnitude to a specific type of device state change event. However, after the firmware upgrade, the response change magnitude of the field value at the corresponding field offset position to the same type of device state change event has changed significantly, indicating that the field semantics carried at the corresponding field offset position may have changed due to the firmware upgrade. The shift in response mode is a direct representation of field semantic migration in the dimension of device state change events, and it is also the basis for subsequently constructing the response correlation graph between fields and measuring the differences in graph features.

[0041] This method identifies the field offset positions where response modes shift by comparing response modes based on device state change events. It utilizes device state change events that occur naturally during the actual operation of cardiovascular monitoring devices as detection signals. This eliminates the need to inject additional test signals into the device or interrupt normal operation. It can complete the preliminary location of field offset positions where response modes shift by continuously operating the device, providing an accurate set of input fields for subsequent construction of response correlation graphs between fields and measurement of graph feature differences. This enables the subsequent migration judgment module to perform more in-depth field semantic migration judgment based on the filtered field offset positions.

[0042] The specific implementation process of constructing an inter-field response association graph using fields at the offset positions where the response mode shift occurs as nodes, performing spectral decomposition on the inter-field response association graphs before and after the upgrade, measuring the differences in graph features, and determining and obtaining the range of field offset positions where semantic migration of fields occurs is as follows: Once the field offset positions where response modes shift are identified, each field at the offset position where the response mode shift occurs is treated as an independent node. The field-to-field response association graph is a graph data structure composed of nodes and edges. A node represents a field, and an edge connects two nodes and has a weight. The edge weight is used to quantify the degree of correlation between the response modes of the corresponding fields of the two nodes during a device state change event.

[0043] The process of constructing the field response correlation graph before firmware upgrade is as follows: From the data of multiple similar device state change events that occurred before the firmware upgrade event, extract the numerical change of the field at the field offset position where the response mode shifts as the node. The number of nodes is denoted as N. For any two nodes, denoted as node i and node j, in the K similar device state change events that have been collected, record the numerical change sequence of the field at the field offset position corresponding to node i in each event, and record the numerical change sequence of the field at the field offset position corresponding to node j in each event. Each element in the numerical change sequence is the numerical change of the corresponding field under the corresponding event. Using the numerical change sequences of node i and node j, calculate the correlation coefficient of the numerical changes of node i and node j in multiple similar device state change events, which serves as the weight of the edge between node i and node j before firmware upgrade. The specific formula for calculating the correlation coefficient is as follows: Where r represents the correlation coefficient between the numerical changes of node i and node j before the firmware upgrade, Xik represents the numerical change of the field at the offset position corresponding to node i in the kth similar device status change event, XiAvg represents the average numerical change of the field at the offset position corresponding to node i in K similar device status change events, Xjk represents the numerical change of the field at the offset position corresponding to node j in the kth similar device status change event, XjAvg represents the average numerical change of the field at the offset position corresponding to node j in K similar device status change events, and K represents the total number of similar device status change events collected.

[0044] If the absolute value of the correlation coefficient r is close to 1, it indicates that the response trends of nodes i and j to the same type of device state change events before the firmware upgrade are highly synchronized; if the absolute value of the correlation coefficient r is close to 0, it indicates that the response trends of the two are almost unrelated. The calculated correlation coefficient is used as the weight of the edge between nodes i and j. The correlation coefficient is calculated for all any two nodes, resulting in a weight matrix composed of the weights between each node. This weight matrix is ​​the adjacency matrix of the field response association graph before the firmware upgrade. The field response association graph before the firmware upgrade is thus constructed.

[0045] The process of constructing the field response association graph after the firmware upgrade is the same as that before the firmware upgrade. The difference lies in the fact that the numerical changes used are derived from multiple similar device state change events recorded after the firmware upgrade event. Similarly, the correlation coefficient of the numerical changes of any two nodes after the firmware upgrade in multiple similar device state change events is calculated and used as the weight of the edge between the corresponding nodes after the firmware upgrade, thereby generating the adjacency matrix of the field response association graph after the firmware upgrade.

[0046] Spectral decomposition is performed on the adjacency matrix of the inter-field response association graph before the firmware upgrade. The adjacency matrix is ​​a real symmetric matrix. Eigenvalue decomposition is performed on the adjacency matrix to obtain a set of real eigenvalues ​​and corresponding eigenvectors. All eigenvalues ​​are arranged in descending order of value to form the eigenvalue sequence before the firmware upgrade. Each eigenvalue in the eigenvalue sequence reflects the structural strength of the inter-field response association graph in the direction of the corresponding eigenvector. Similarly, eigenvalue decomposition is performed on the adjacency matrix of the inter-field response association graph after the firmware upgrade, and the obtained eigenvalues ​​are arranged in descending order to form the eigenvalue sequence after the firmware upgrade.

[0047] The relative entropy between the feature value sequences before and after the firmware upgrade is calculated to measure the overall difference between the two graph structures. The feature value sequences before and after the firmware upgrade are then normalized. The normalization process is as follows: each feature value in the feature value sequence before the firmware upgrade is divided by the sum of all feature values ​​in that sequence, yielding the normalized feature value distribution before the firmware upgrade; similarly, each feature value in the feature value sequence after the firmware upgrade is divided by the sum of all feature values ​​in that sequence, yielding the normalized feature value distribution after the firmware upgrade. The normalized feature value distribution can be viewed as a probability distribution, where the proportion of each feature value represents the importance of the corresponding graph structure component within the overall graph structure.

[0048] The KL divergence is calculated between the normalized eigenvalue distribution before firmware upgrade and the normalized eigenvalue distribution after firmware upgrade. The formula for KL divergence is: D = Σpi × log(pi / qi); where D represents the difference in eigenvalue distribution, pi represents the proportion of the i-th eigenvalue in the normalized eigenvalue distribution before firmware upgrade, qi represents the proportion of the i-th eigenvalue in the normalized eigenvalue distribution after firmware upgrade, and log represents the natural logarithm. If the two eigenvalue distributions are completely identical, the KL divergence is zero; the greater the difference in eigenvalue distributions, the greater the KL divergence value.

[0049] The calculated spectral feature difference D is used as the spectral feature difference of the corresponding node. It is necessary to determine whether the spectral feature difference D exceeds the spectral difference threshold. The spectral difference threshold is set based on the normal fluctuation range of the inter-field response correlation graph under stable operation of the cardiovascular monitoring device without firmware upgrade events. The method for setting the spectral difference threshold is as follows: Under the condition that the cardiovascular monitoring device is in the same firmware version and no firmware upgrade events have occurred, response data generated by the same type of device status change events are collected multiple times within different time periods. Based on each data set, multiple inter-field response correlation graphs are constructed, and the spectral feature difference between any two graphs is calculated to form a baseline difference sample set. The mean and standard deviation of the baseline difference sample set are calculated, and the mean plus three times the standard deviation is used as the spectral difference threshold. Three times the standard deviation is set based on statistical laws; under the assumption of normal distribution, the probability of exceeding the mean plus or minus three times the standard deviation is extremely low, thus effectively distinguishing normal random fluctuations from structural changes caused by firmware upgrades.

[0050] If the graph feature difference D corresponding to a node exceeds the graph difference threshold, it indicates that the connection structure of that node in the field response association graph has changed significantly after the firmware upgrade. That is, the field semantics carried at the field offset position corresponding to that node has shifted. Therefore, the field offset position corresponding to that node is determined as the field offset position where the field semantic shift occurred. The field offset positions corresponding to all nodes exceeding the graph difference threshold are aggregated to form the range of field offset positions where the field semantic shift occurred.

[0051] Using graph feature differences to determine field semantic migration, rather than relying solely on changes in the numerical distribution of a single field, is because field semantic migration essentially alters the relational structure characteristics between multiple fields. Graph structure spectral decomposition can capture this change in relational structure as a whole, and KL divergence, as a difference measure, can quantify the overall degree of offset between two graphs. This provides a global perspective and objective quantitative standards for determining field semantic migration, avoiding misjudgments or omissions that may occur if only a single field statistic is relied upon. It also provides an accurate basis for the migration range in order to correctly reconstruct the mapping relationship between field offset positions and equipment operating status parameters.

[0052] The specific implementation process for reconstructing the mapping relationship between field offset positions and device operating status parameters based on the field offset position range where field semantic migration occurs is as follows: After obtaining the range of field offset positions where semantic migration occurs, it is necessary to reconstruct the mapping relationship between field offset positions and device operating status parameters. The mapping relationship between field offset positions and device operating status parameters refers to a mapping table. Each mapping entry in the mapping table records the correspondence between a specific field offset position in the data frame and a specific device operating status parameter, such as ECG signal quality indication, electrode contact impedance value, battery remaining percentage, and device operating temperature value.

[0053] Obtain the mapping relationship between the field offset positions before the firmware upgrade and the device operating status parameters. The mapping relationship between the field offset positions before the firmware upgrade and the device operating status parameters is a mapping table that has been established and stored before the firmware upgrade event occurs. The mapping table is stored on non-volatile storage media, and the contents of the mapping table contain the correspondence records between the offset positions of each field in the data frame and the corresponding device operating status parameters.

[0054] The field offset ranges that have undergone semantic migration are removed from the mapping relationship between field offsets and device operating status parameters before the firmware upgrade, resulting in unmigrated field mapping relationships. The removal operation involves iterating through each mapping entry in the mapping relationship between field offsets and device operating status parameters before the firmware upgrade. If a field offset in a mapping entry falls within the range of field offsets that have undergone semantic migration, the corresponding mapping entry is deleted from the mapping relationship; if a field offset in a mapping entry does not fall within the range of field offsets that have undergone semantic migration, the corresponding mapping entry is retained. After the removal operation is completed, what remains is the set of all mapping entries between field offsets and device operating status parameters that were not affected by the firmware upgrade; this is called the unmigrated field mapping relationship.

[0055] For each field offset position within the range of field offset positions where semantic migration occurs, a mapping entry between it and the device operating status parameter needs to be established. The establishment method is as follows: for a target field offset position within the range of field offset positions where semantic migration occurs, analyze the correspondence between the numerical change characteristics of the target field offset position after the firmware upgrade and the device operating status parameter. The numerical change characteristics of the target field offset position after the firmware upgrade refer to the change behavior of the field value at the target field offset position when various device status change events occur. These characteristics are obtained from the recorded numerical change data after the firmware upgrade. Device operating status parameters have their own physical characteristics, and different device operating status parameters will exhibit different numerical change characteristics under the same device status change event. For example, the electrode contact impedance parameter will show a significant step change during a lead switching event, while the battery remaining power parameter will show a relatively gradual change. The numerical change characteristics of the target field offset position after the firmware upgrade for various device status change events are matched with the known typical response characteristics of each device operating status parameter under the corresponding device status change event. During matching, the similarity between the change in the target field offset position after the firmware upgrade and the reference change in each device's operating status parameter under the corresponding device status change event is calculated. The similarity is calculated as: S = 1 / (1 + |ΔVtarget - ΔVreference|), where S represents the similarity, ΔVtarget represents the change in the target field offset position after the firmware upgrade, and ΔVreference represents the reference change in the device's operating status parameter under the corresponding device status change event. The device's operating status parameter with the highest similarity is selected as the actual device operating status parameter carried by the target field offset position after the firmware upgrade. The reference change in the device's operating status parameter under the corresponding device status change event is extracted from the cardiovascular monitoring device's specifications and operating logs and pre-stored. After determining the correspondence between the target field offset position and the matched device operating status parameter, a mapping entry is established. The mapping entry contains the offset value of the target field offset position and the parameter identifier of the matched device operating status parameter.

[0056] The unmigrated field mapping relationships are merged with the mapping entries established for each field offset position within the range of field offset positions where field semantic migration has occurred. The merging operation involves appending each mapping entry established for each field offset position within the range of field offset positions where field semantic migration has occurred to the set of mapping entries for the unmigrated field mapping relationships, forming a complete set of mapping entries. The merged complete set of mapping entries constitutes the reconstructed mapping relationship between field offset positions and device operating status parameters. This reconstructed mapping relationship between field offset positions and device operating status parameters covers all field offset positions in the data frame that carry device operating parameters, ensuring that each field offset position corresponds to a correct device operating status parameter.

[0057] The method of first removing, then establishing, and then merging is used to reconstruct the mapping relationship between field offset positions and device operating status parameters. This is because the range of field offset positions that have undergone semantic migration only includes a portion of the field offset positions. Most field offset positions have not undergone semantic migration before and after the firmware upgrade. Retaining the mapping relationship of unmigrated fields can avoid performing a complete reconstruction of the entire mapping table. Only the field offset positions that have actually undergone semantic migration are reconstructed. This ensures the accuracy of the mapping relationship between field offset positions and device operating status parameters and improves the efficiency of mapping relationship reconstruction. It provides an accurate and reliable mapping foundation for subsequent parsing of data frames that rely on the mapping relationship between field offset positions and device operating status parameters.

[0058] The specific implementation process of parsing subsequent data frames based on the reconstructed mapping relationship to obtain device operating status parameters and uploading them to the remote server is as follows: After reconstructing the mapping between field offset positions and device operating status parameters, the system begins receiving subsequent data frames sent by the cardiovascular monitoring device after the firmware upgrade event. Subsequent data frames refer to the data frames that the cardiovascular monitoring device continues to send periodically according to its preset communication protocol after the firmware upgrade event is confirmed. The method for receiving subsequent data frames is the same as that for receiving data frames before the firmware upgrade event: the system listens for and captures data frames from the cardiovascular monitoring device through the IoT communication interface, and temporarily stores all bytes of the captured data frames in a buffer.

[0059] Based on the reconstructed mapping between field offset positions and device operating status parameters, the corresponding field value is extracted from each field offset position in subsequent data frames. The reconstructed mapping between field offset positions and device operating status parameters is a complete mapping table, recording all mapping entries between field offset positions carrying device operating parameters in the data frame and the device operating status parameters. For each mapping entry in the table, the field offset position recorded in the mapping entry is obtained. Based on the field offset position, the corresponding byte position is located from the beginning of the data frame byte sequence in the buffer, and a specified length of consecutive bytes is read. The read consecutive bytes are the field value at the corresponding field offset position. The field value is the original value stored in the data frame in binary encoding form and needs to be converted into the corresponding device operating status parameter.

[0060] The process of converting field values ​​into corresponding device operating status parameters depends on the parameter type of the device operating status parameters recorded in the mapping entry. Different parameter types of device operating status parameters have different value conversion rules. The value conversion rules are preset according to the parameter encoding format defined in the device specifications of the cardiovascular monitoring device, or they can be determined by performing protocol reverse analysis on data frame samples of the cardiovascular monitoring device in a known state. For example, for device operating status parameters encoded with a linear mapping relationship, the value conversion rule is to multiply the read binary value by a predetermined conversion coefficient to obtain the actual physical quantity value. The predetermined conversion coefficient is determined based on the proportional relationship between the physical range of the device operating status parameter and the binary encoding range. For device operating status parameters encoded using a lookup table, the value conversion rule is to use the read binary value as an index value to look up the corresponding physical quantity value in a predetermined parameter value table. The predetermined parameter value table is a lookup table of encoded values ​​and physical quantity values ​​extracted from the device specifications of the cardiovascular monitoring device. After the conversion is completed, a device operating status parameter with actual physical meaning is obtained.

[0061] Perform field value extraction and device operating status parameter conversion operations on all mapping entries in the mapping table to obtain a set of all device operating status parameters for subsequent data frames. This set of all device operating status parameters contains complete operating status information of the cardiovascular monitoring device at the time of sending subsequent data frames.

[0062] The converted device operating status parameters, along with the current firmware version identifier of the cardiovascular monitoring device, are uploaded to a remote server. The current firmware version identifier is the one updated when a firmware upgrade event occurs. During upload, the device operating status parameters and the current firmware version identifier are packaged into a single data packet according to a predetermined data packet format. In addition to the device operating status parameters and the current firmware version identifier, the data packet also includes the cardiovascular monitoring device's device identifier and timestamp information. The device identifier identifies the data source, and the timestamp records the time when the device operating status parameters were generated. The encapsulated data packet is then sent to the remote server via an IoT communication interface in a format specified by a network protocol, such as Message Queuing Telemetry Transport Protocol (MQTP) or Hypertext Transfer Protocol (HTTP). Upon receiving the data packet, the remote server parses, stores, and displays it for remote viewing by medical personnel's monitoring terminals.

[0063] By using the mapping relationship between the reconstructed field offset position and the device operating status parameters to parse subsequent data frames, it is ensured that even if the field semantics are migrated due to firmware upgrades, the device operating status parameters extracted and converted from the data frames still maintain a correct correspondence with the physical meaning of the device operating status parameters. This allows the device operating status data uploaded to the remote server to truly reflect the actual operating status of the cardiovascular monitoring equipment, providing accurate and reliable equipment status information for medical staff in the remote monitoring center.

[0064] All calculations involved in the embodiments are performed using dimensionless numerical values, and the preset parameters and thresholds in the calculations can be set by those skilled in the art according to actual conditions.

[0065] This technical solution can be flexibly deployed, for example, as embedded software running on device hardware, or installed on personal computers or other smart terminals with user interfaces, thus adapting to various hardware environments and usage requirements.

[0066] The above solutions can be implemented in software, hardware, firmware, or a combination thereof. When implemented in software, they are presented, in whole or in part, as a computer program product, containing one or more computer instructions or programs. When these instructions or programs are loaded and executed on a computer, results are produced corresponding to the processes or functions of the embodiments of this application. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one medium to another via wired or wireless means, such as from a website, server, or data center via wired means such as fiber optic cables, twisted-pair cables, or coaxial cables, or wireless means such as infrared or microwaves to another site. A computer-readable storage medium refers to any usable medium that a computer can access or a data storage device such as a server or data center that contains one or more usable media, including magnetic media such as floppy disks, hard disks, and magnetic tapes, optical media such as DVDs, and semiconductor media such as solid-state drives.

[0067] The specific working process of the system, device and module can be found in the method embodiment, and will not be repeated here.

[0068] The disclosed systems, devices, and methods can be implemented in other ways. The device embodiments are for illustrative purposes only, and the module division is only a logical division. In practice, different divisions can be implemented, such as merging or integrating multiple modules or components, or omitting some features. Coupling, direct coupling, or communication connections between the components can be achieved through interfaces, while indirect coupling or communication connections can take electrical, mechanical, or other forms.

[0069] The modules described as separate components may or may not be physically separated. The components shown as modules can be physical hardware or software, and can be deployed centrally or distributed across multiple network nodes. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0070] The functional modules in each embodiment can be integrated into one processing module, or they can exist independently, or two or more modules can be integrated into one.

[0071] If the functionality is implemented as a software module and used as an independent product, it can be stored in a computer-readable storage medium. Under this understanding, the substantial contribution of the technical solution of this application can be embodied in the form of a software product. This computer software product is stored in a storage medium and contains instructions to cause a computer device, such as a personal computer, server, or network device, to execute all or part of the steps of the methods in the embodiments of this application. The storage medium includes any medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory, random access memory, magnetic disk, or optical disk.

[0072] The above are merely specific embodiments of this application, and the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should fall within the scope of protection of this application.

Claims

1. A system for acquiring and remotely monitoring the operational status of cardiovascular monitoring equipment, characterized in that, The method comprises the following steps: A version acquisition module is configured to receive a data frame sent by a cardiovascular monitoring device and acquire a current firmware version identifier of the cardiovascular monitoring device; An upgrade determination module is configured to compare the current firmware version identifier with a previous firmware version identifier and determine that a firmware upgrade event has occurred when the identifiers are inconsistent; A mode comparison module is configured to monitor device state change events after the firmware upgrade event, compare the response modes of fields at different field offset positions to the same type of device state change events before and after the upgrade, and identify field offset positions at which the response modes have shifted; A migration determination module is configured to take fields at the field offset positions at which the response modes have shifted as nodes to construct a field-to-field response correlation graph, perform spectral decomposition on the field-to-field response correlation graphs before and after the upgrade, measure the differences in graph spectral features, and determine and obtain a range of field offset positions at which field semantics have migrated; A relationship reconstruction module is configured to reconstruct the mapping relationship between the field offset positions and the device operating state parameters according to the range of field offset positions at which the field semantics have migrated; A parameter analysis module is configured to analyze subsequent data frames according to the reconstructed mapping relationship, obtain device operating state parameters, and upload the parameters to a remote server.

2. The cardiovascular monitoring device operating state data acquisition and remote monitoring system according to claim 1, characterized in that, The method comprises the following steps: Receiving a data frame sent by a cardiovascular monitoring device; Extracting a firmware version number field carried at a preset field offset position in the data frame; If the firmware version number field is successfully extracted, taking the value of the firmware version number field as the current firmware version identifier; If the firmware version number field is not successfully extracted, sending a version query instruction to the cardiovascular monitoring device, receiving firmware version information returned by the cardiovascular monitoring device, and taking the firmware version information as the current firmware version identifier.

3. The cardiovascular monitoring device operating state data acquisition and remote monitoring system of claim 1, wherein, The method comprises the following steps: Acquiring a previously stored previous firmware version identifier; Comparing the string of the current firmware version identifier with the string of the previous firmware version identifier; If the strings of the current firmware version identifier and the previous firmware version identifier are inconsistent, determining that a firmware upgrade event has occurred and updating the previous firmware version identifier to the current firmware version identifier; If the strings of the current firmware version identifier and the previous firmware version identifier are consistent, determining that no firmware upgrade event has occurred and keeping the previous firmware version identifier unchanged.

4. The cardiovascular monitoring device operating state data acquisition and remote monitoring system of claim 1, wherein, The method comprises the following steps: After determining that a firmware upgrade event has occurred, continuously monitoring device state change events generated by the cardiovascular monitoring device; Recording the value change amounts of fields at different field offset positions before and after the occurrence of a device state change event; Comparing the value change amounts of a field at the same field offset position before and after the firmware upgrade under the same type of device state change event; If a difference between the value change amounts of the field at the same field offset position before and after the firmware upgrade exceeds a preset change amount threshold, the corresponding field offset position is determined as the field offset position where the response mode shifts.

5. The cardiovascular monitoring device operating state data acquisition and remote monitoring system of claim 1, wherein, The field at the field offset position where the response mode shifts is taken as a node to construct a field-to-field response correlation graph, and spectral decomposition is performed on the field-to-field response correlation graphs before and after the upgrade to measure the difference in graph spectrum features, and the range of the field offset position where the field semantics shift is determined and obtained, including: The field at the field offset position where the response mode shifts is taken as a node; The correlation between the value change amounts of any two nodes in multiple same-type device state change events before the firmware upgrade is calculated as the weight of the edge between the corresponding nodes before the firmware upgrade, and a field-to-field response correlation graph before the firmware upgrade is constructed. The correlation between the value change amounts of any two nodes in multiple same-type device state change events after the firmware upgrade is calculated as the weight of the edge between the corresponding nodes after the firmware upgrade, and a field-to-field response correlation graph after the firmware upgrade is constructed. Spectral decomposition is performed on the adjacency matrices of the field-to-field response correlation graph before the firmware upgrade and the field-to-field response correlation graph after the firmware upgrade respectively to obtain the eigenvalue sequence before the firmware upgrade and the eigenvalue sequence after the firmware upgrade. The relative entropy between the eigenvalue sequence before the firmware upgrade and the eigenvalue sequence after the firmware upgrade is calculated as the difference in graph spectrum features. The field offset position corresponding to the node whose difference in graph spectrum features exceeds the graph difference threshold is determined as the field offset position where the field semantics shift, and the range of the field offset position where the field semantics shift is obtained from all the field offset positions where the field semantics shift.

6. The cardiovascular monitoring device operational status data collection and remote monitoring system of claim 5, wherein, The correlation between the value change amounts of any two nodes in multiple same-type device state change events before the firmware upgrade is calculated as the weight of the edge between the corresponding nodes before the firmware upgrade, including: recording the value change amount of the field at the field offset position corresponding to each node in each same-type device state change event before the firmware upgrade; and calculating the correlation coefficient of the value change amounts of any two nodes in multiple same-type device state change events as the weight of the edge between the two nodes before the firmware upgrade.

7. The cardiovascular monitoring device operational status data collection and remote monitoring system of claim 5, wherein, Spectral decomposition is performed on the adjacency matrices of the field-to-field response correlation graph before the firmware upgrade and the field-to-field response correlation graph after the firmware upgrade respectively to obtain the eigenvalue sequence before the firmware upgrade and the eigenvalue sequence after the firmware upgrade, including: constructing the adjacency matrix of the field-to-field response correlation graph before the firmware upgrade and the adjacency matrix of the field-to-field response correlation graph after the firmware upgrade; performing eigenvalue decomposition on the adjacency matrix before the firmware upgrade, and arranging the eigenvalues in descending order to obtain the eigenvalue sequence before the firmware upgrade; and performing eigenvalue decomposition on the adjacency matrix after the firmware upgrade, and arranging the eigenvalues in descending order to obtain the eigenvalue sequence after the firmware upgrade.

8. The cardiovascular monitoring device operational status data collection and remote monitoring system of claim 5, wherein, The relative entropy between the feature value sequence before the firmware upgrade and the feature value sequence after the firmware upgrade is calculated as a graph feature difference, including: the feature value sequence before the firmware upgrade and the feature value sequence after the firmware upgrade are normalized respectively to obtain a normalized feature value distribution before the firmware upgrade and a normalized feature value distribution after the firmware upgrade; the KL divergence of the normalized feature value distribution before the firmware upgrade relative to the normalized feature value distribution after the firmware upgrade is calculated as the graph feature difference.

9. The cardiovascular monitoring device operational status data collection and remote monitoring system of claim 1, wherein, According to the field offset position range where the field semantic migration occurs, the mapping relationship between the field offset position and the device running state parameter is reconstructed, including: Obtaining the mapping relationship between the field offset position and the device running state parameter before the firmware upgrade; Removing the field offset position range where the field semantic migration occurs from the mapping relationship between the field offset position and the device running state parameter before the firmware upgrade to obtain a non-migrated field mapping relationship; For each field offset position in the field offset position range where the field semantic migration occurs, a mapping entry between the corresponding field offset position and the device running state parameter is established according to the corresponding relationship between the numerical change characteristics of the corresponding field offset position after the firmware upgrade and the device running state parameter; Combining the non-migrated field mapping relationship with the mapping entry established for each field offset position in the field offset position range where the field semantic migration occurs to obtain the reconstructed mapping relationship between the field offset position and the device running state parameter.

10. The cardiovascular monitoring device operational status data collection and remote monitoring system of claim 1, wherein, According to the reconstructed mapping relationship, the subsequent data frames are parsed to obtain the device running state parameter and upload it to the remote server, including: Receiving the subsequent data frames sent by the cardiovascular monitoring device after the firmware upgrade event; According to the reconstructed mapping relationship between the field offset position and the device running state parameter, the corresponding field value is extracted from each field offset position of the subsequent data frames, and the field value is converted into the corresponding device running state parameter; The converted device running state parameter is uploaded to the remote server together with the current firmware version identifier of the cardiovascular monitoring device.

Images