Equipment state identification method and electronic equipment

Abstract

The invention discloses an equipment state recognition method and electronic equipment, and relates to the technical field of I2C equipment, and the method comprises the steps that a transaction containing a target address and at least one data segment is initiated to a bus, an address stage response and a data stage response returned by target equipment are received, and the target address is the address corresponding to the target equipment; determining the device state of the target device according to the address stage response and the data stage response; in response to the fact that the equipment state of the target equipment is abnormal, detecting the target equipment to obtain a detection result; in response to the fact that the detection result is successful, determining an abnormal stage according to the response, and operating the abnormal stage again; and in response to the detection result of failure, determining that the device state of the target device is not in place or has a fault according to the detection data, thereby solving the technical problem of lack of fine-grained sensing and distinguishing capabilities in the aspects of device abnormality, hot plug management and error processing in related technologies, and achieving the technical effect of accurately and quickly diagnosing the device state.

Description

Technical Field

[0001] This invention relates to the field of I2C device technology, and in particular to a device status identification method and electronic device. Background Technology

[0002] Current I2C (Inter-Integrated Circuit, two-wire serial bus) buses suffer from insufficient reliability in service access. Related technologies typically rely on a complete I2C access retry mechanism to determine device functionality, leading to significant service delays when devices are unstable, particularly impacting single-threaded services. Furthermore, in managing hot-swappable devices, the lack of effective on-state determination methods often necessitates additional hardware pins and cross-module communication, increasing hardware design complexity and cost. The time window for status acquisition also increases the likelihood of false alarms, interfering with maintenance judgments. In addition, related technologies treat all errors such as NACK (Negative Acknowledgment) as failures, failing to differentiate the cause of failure, resulting in misjudgments, prolonged blocking, and wasted bus resources. Moreover, the lack of awareness of I2C communication errors makes it difficult to assess the compatibility of multi-slave devices under stress.

[0003] Therefore, in view of the shortcomings of existing technical solutions, the present invention provides a device status identification method. Summary of the Invention

[0004] This application provides a device status identification method and an electronic device to at least solve the problem of lack of fine-grained perception and differentiation capabilities in related technologies regarding device anomalies, hot-plug management, and error handling.

[0005] This application provides a device status identification method, the method comprising: initiating a transaction on a bus including a target address and at least one data segment and receiving an address phase response and a data phase response returned by the target device, wherein the target address is the address corresponding to the target device; determining the device status of the target device based on the address phase response and the data phase response, wherein the device status includes normal and abnormal; in response to the device status of the target device being abnormal, probing the target device and obtaining a probing result; in response to the probing result being successful, determining an abnormal phase based on the response and re-operating on the abnormal phase, wherein the abnormal phase includes an address phase and a data phase; and in response to the probing result being unsuccessful, determining the device status of the target device as absent or faulty based on the probing data.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described device state recognition methods when executing the computer program.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described device state identification methods.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described device state recognition methods.

[0009] This application achieves accurate and rapid diagnosis of device status by initiating a transaction on the bus containing a target address and at least one data segment and receiving address phase and data phase responses from the target device, where the target address is the address corresponding to the target device; determining the device status of the target device based on the address phase and data phase responses, where the device status includes normal and abnormal; probing the target device in response to an abnormal device status and obtaining the probing result; determining the abnormal phase based on the response in response to a successful probing result and re-operating on the abnormal phase, where the abnormal phase includes the address phase and data phase; and determining the target device status as absent or faulty based on the probing data in response to a failed probing result. This significantly reduces performance blocking caused by blind retries in upper-layer services, while improving the observability and maintainability of the system, and significantly improving the reliability and response speed of the entire system without increasing additional hardware costs. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A flowchart illustrating a device status identification method provided in an embodiment of this application; Figure 2 A flowchart illustrating another device status identification method provided in this application embodiment; Figure 3 A structural block diagram of a device status identification device provided in an embodiment of this application; Figure 4 This is an internal structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0013] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0014] It should be noted that the terms "S1," "S2," etc., are used only for descriptive purposes and do not specifically refer to the order or sequence, nor are they intended to limit this application. They are merely for the convenience of describing the method of this application and should not be construed as indicating the sequential order of the steps. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0015] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0016] The embodiments of this application provide a device status identification method, and the method is described in detail below in conjunction with the execution flow of the device status identification method.

[0017] S101: Initiate a transaction on the bus containing a target address and at least one data segment, and receive the address phase response and data phase response returned by the target device, wherein the target address is the address corresponding to the target device.

[0018] Here, the bus can be an I2C bus. The I2C bus is a common serial communication protocol, mainly used for short-distance communication between microcontrollers and various peripheral devices. The I2C bus has two lines: a data line and a clock line.

[0019] Here, the executing entity can be the host, and the target device can be one of multiple slave devices that communicate with the host via a bus.

[0020] Here, a transaction is the entire communication process on the bus from start to finish in order to complete an independent and logically complete unit of operation.

[0021] Here, the response can include an acknowledge signal (ACK) and a no-acknowledge signal (NACK).

[0022] Here, a transaction can include read commands or write commands.

[0023] The master is the entity that initiates the bus start conditions, generates the clock, and issues the address, while the slave is the entity that responds after being addressed and completes the reading or writing of data.

[0024] It can be used in hot-swappable scenarios.

[0025] A complete transaction includes a start, address, data bytes, and stop.

[0026] Specifically, the initial state of the target device can be an unknown state (i.e., UNKNOWN).

[0027] Specifically, if the target device is not in its initial state, and during the next access process, the target device's state is either not in place or faulty, then if one access transaction is cleared, all transactions will be cleared.

[0028] S102: Determine the device status of the target device based on the address phase response and the data phase response, wherein the device status includes normal and abnormal.

[0029] The address phase is used for addressing. On an I2C bus that may have multiple slave devices, the master uses this phase to select a slave device as the target device.

[0030] The data phase is used to transmit data. After successful addressing, the host and the target device begin transmitting actual, valid data.

[0031] Specifically, after the data transmission is completed, an end signal is sent. If there are no unrecoverable errors throughout the process, the access is successful, and the target device's device status is confirmed to be that the device is in place and communication is normal.

[0032] S103: In response to the target device's device status being abnormal, probe the target device and obtain the probe results.

[0033] Here, probing is an operation designed to check whether a slave device exists on the bus and can respond to its address.

[0034] Specifically, the detection can be short-rhythm detection, a specific, optimized, lightweight internal detection protocol.

[0035] Specifically, before probing the target device, the process may include: waiting for a preset time, checking if the bus is idle, and probing if the bus is idle. The preset time can be manually preset.

[0036] S104: In response to a successful probe result, determine the abnormal phase based on the response and re-perform the abnormal phase, which includes the address phase and the data phase.

[0037] Here, the exception phase can include address phase exceptions and data phase exceptions.

[0038] Specifically, the response to the address phase is no response, the exception determination phase is the address phase, the response to the data phase is no response, and the exception determination phase is the data phase.

[0039] Specifically, when the abnormal stage is detected as the address stage, the target address and start signal are resent; when the abnormal stage is detected as the data stage, the operation type of the message is obtained; if the operation type is a read operation, the read operation is re-executed; if the operation type is a write operation, the write progress is obtained, and the write operation is continued according to the write progress.

[0040] S105: In response to a failed detection result, the device status of the target device is determined to be either out of place or faulty based on the detection data.

[0041] Among them, the fault is that the target device is physically connected to the bus, but due to its own or the bus's reasons, it cannot conduct stable and correct communication, and its abnormal behavior has interfered with the normal state of the bus.

[0042] The fault is a long-term fault, not a momentary fault, and can include equipment freezing (internal logic deadlock or program crash), physical damage to internal circuits (such as memory, registers and controllers) or partial functional failure.

[0043] Specifically, when a detection fails but the device status cannot be determined as either out of place or malfunctioning, the issue is reported to a human for handling.

[0044] In one embodiment, if all slave devices on the same I2C bus show a fault during status detection, fault detection is performed on the I2C bus to determine whether a bus fault has occurred.

[0045] It should be noted that this application enables accurate and rapid diagnosis of device status, greatly reducing performance blockage caused by blind retries in upper-layer services, while improving the observability and maintainability of the system. Without increasing additional hardware costs, it significantly improves the reliability and response speed of the entire system.

[0046] In some specific implementations, initiating a transaction on the bus containing a target address and at least one data segment and receiving an address phase response and a data phase response returned by the target device includes: Send the target address and start signal to the bus, and receive the address phase response returned by the target device; The response at the address stage is a normal response, proceeding to the data stage; Send at least one data segment to the target address on the bus and receive a data segment response from the target device.

[0047] The address phase also includes identifying whether the operation corresponding to the transaction is a read operation or a write operation.

[0048] In the data phase, it is necessary to wait for a response byte by byte, that is, a corresponding response must be received after each byte is sent.

[0049] Separating the address phase and the data phase helps to quickly locate the problem and improve diagnostic efficiency.

[0050] In some specific implementations, the device status of the target device is determined based on the address phase response and the data phase response, including: If the address phase response is no response, increase the address phase no response count and the consecutive no response count, and determine that the target device's device status is abnormal. If the response in the address phase is a normal response, the number of consecutive no responses will be cleared to zero, and the process will proceed to the data phase. If the response during the data phase is no response, increase the number of no responses during the data phase and the number of consecutive no responses, and determine that the device status of the target device is abnormal. If the response during the data phase is a normal response, the number of consecutive no-response messages will be cleared to zero, and the device status of the target device will be determined to be normal.

[0051] The number of consecutive no-response events will accumulate regardless of whether the no-response occurs during the address phase or the data phase.

[0052] Specifically, send Start and address, wait for the target device to respond. If ACK occurs, consec_nack_run (i.e., the number of consecutive no-acknowledgment counts) is set to 0, and the normal data phase is entered. If NACK occurs, addr_nack_count (i.e., the number of no-acknowledgment counts in the address phase) is incremented by 1, consec_nack_run is incremented by 1, and the probe phase is entered.

[0053] Specifically, data is read and written according to message type, and responses are waited for byte by byte. If all responses are ACK and the transaction ends legally, the transaction is considered successful and the success count is incremented by 1. If NACK occurs, data_nack_count (i.e., the number of no responses in the data phase) is incremented by 1, consec_nack_run (i.e., the number of consecutive no responses) is incremented by 1, and the probe phase begins.

[0054] This prevents historical errors from affecting the current state and ensures that the system responds promptly and accurately.

[0055] In some specific implementations, in response to an abnormal device status of the target device, the target device is probed, and the probe results are obtained, including: Send the target address and probe signal to the bus, and receive the probe response returned by the target device; If the received probe response is a normal response, the number of consecutive no responses will be cleared to zero, and the probe result will be determined as successful. In response to a received probe response of no response, increment the consecutive no response count, and determine the probe result as either failure or retry based on the consecutive no response count.

[0056] Here, probing refers to any operation designed to check the presence of a slave device on the bus and to respond to its address.

[0057] The probe signal may include a start signal and an address.

[0058] The probe response may consist of only the address phase response, or it may include both the address phase response and the data phase response.

[0059] In response to a received probe response that is no response, the number of no responses in the corresponding stage can be increased accordingly based on the probe response, such as the number of no responses in the address stage and the number of no responses in the data stage.

[0060] Among them, the detection is protocol-level detection.

[0061] Specifically, only a start signal and the target address are sent, and the response from the target device is received. If an ACK (acknowledgment) is received, it is considered that the target device has experienced a transient error and has recovered instantaneously. The consec_nack_run (number of consecutive no-acknowledgments) is cleared to zero. If the failure occurs in the address phase, it returns and continues. If the failure occurs in the data phase, for write operations, if the protocol allows repeatedstart, then data continues. For read operations, the access process is rebuilt, and a read operation is completed in one go. If there is still no NACK (no acknowledgment), the number of retries is increased, and the consec_nack_run (number of consecutive no-acknowledgments) is incremented by 1. If the maximum number of retries has not been exceeded, short-term retries continue.

[0062] Specifically, during hot-swapping, the jitter in the intermediate state of I2C caused by the plugging and unplugging should not be transmitted as an error to the upper layer, as this can easily lead to false alarms and increase the workload of operation and maintenance. Existing designs generally require hardware pin design to determine whether the status is in place. However, obtaining the status requires special hardware design, which increases design costs. Furthermore, since the status must be obtained by another management entity and another driver device to obtain the status and then read other information, there is often a time window, which can lead to errors caused by such unstable states. By probing, this situation can be eliminated without designing additional hardware, saving the difficulty of operation and maintenance and reducing false alarms.

[0063] In one embodiment, the method further includes, prior to probing the target device: Detect the power consumption and load of the target device; In response that the target device is a low-power device, a wake-up command is sent; After waiting for the first preset time, the target device will be detected; In response to a normal reply from the target device, the device status of the target device is determined to be normal. If the target device does not respond, the detection will be repeated. In response to the target device being a high-load device, after waiting for a second preset time, the target device is probed; In response to a normal reply from the target device, the device status of the target device is determined to be normal. If the target device does not respond, the probe will be restarted.

[0064] Specifically, when the target device is a low-power device, there is a possibility that the target device may enter sleep mode and fail to respond, leading to misjudgment. This can be avoided by adding a sleep / wake-up pre-probe, which includes: before the regular probe, sending a "sleep / wake-up command" to the target device (such as an I2C-based Wake-Up signal, a specific register write operation, etc.), waiting 10-100ms (different wake-up times correspond to different device types), and then performing the probe; if it responds after waking up, it is determined that "the device is present (i.e., sleep resumed)"; if there is still no response after waking up, it is determined that the target device is abnormal.

[0065] Specifically, for high-load devices, during high-bandwidth transmission (such as synchronously reading large amounts of data via I2C), there is a possibility of temporary unresponsiveness due to internal resource consumption, leading to misjudgment. This can be avoided by adding a new service status association judgment. Specifically, this includes: obtaining the current service load of the target device through the driver layer (such as the optical power transmission rate of the optical module, and the read / write busyness of the storage controller); if the device load is ≥80% when NACK occurs (the threshold can be dynamically configured), then enter "delay detection mode" (wait 100ms and then probe again to avoid interference during busy periods); if the response resumes after the delay detection, it is judged as "temporary abnormality due to busy service" (not abnormal); if it is still NACK and the load is low, it is determined that the target device is abnormal.

[0066] This greatly reduces the misjudgment rate and improves the accuracy of status diagnosis.

[0067] In one embodiment, the method further includes, prior to probing the target device: The detection level matching rule table is determined according to the priority of business status, historical performance, and device type. Based on the target device's device type, business status, and historical performance, determine the target device's overall score; Based on the overall score, the detection level corresponding to the target device is dynamically determined through the detection level matching rule table, where the detection levels include Level 1, Level 2 and Level 3.

[0068] Here, the probe signal may also include a start signal, an address, and a simple read command (such as reading a known register), and the probe signal may also include a start signal, an address, and a simple write command (such as writing to a non-critical configuration register).

[0069] The detection signal consisting only of a start signal and an address corresponds to the first level of detection; the detection signal consisting of a start signal, an address, and a simple read command corresponds to the second level of detection; and the detection signal consisting of a start signal, an address, and a simple write command corresponds to the third level of detection.

[0070] Specifically, device type parameters may include device function sensitivity and command security level; service status parameters may include service occupancy rate and service request frequency; historical performance parameters may include recent success rate, number of consecutive no-response days, and fault trend value.

[0071] The detection level matching rule table is configured based on the following priority: business status (prioritizing to ensure that the business is not interfered with by detection), historical performance (adjusting the detection depth according to the device stability), and finally device type (basic constraints to avoid unsafe detection).

[0072] Specifically, when the target device is in a busy period, only the first level of detection is performed, and the detection interval is extended to avoid occupying the bus and affecting the service; when the target device is in an idle period, the second or third level of detection is performed, and the detection interval is shortened to quickly capture changes in the device status.

[0073] Specifically, sensor devices should prioritize using Level 2 detection, while power supply devices should prioritize using Level 3 detection.

[0074] In this way, through a multi-dimensional strategy that prioritizes business status, adapts to historical performance, and constrains device type, a business-friendly, efficient monitoring, and secure and reliable technical effect is achieved.

[0075] In this way, by driving internal probing in a short-term manner, it is possible to quickly distinguish between a real failure and an occasional error in I2C, eliminate transient errors, realize system self-checking and self-healing functions, and avoid making the upper layer perform more invalid and complete retries.

[0076] In some specific implementations, in response to a received probe response of no response, the consecutive no-response count is incremented, and the probe result is determined to be either a failure or a retry based on the consecutive no-response count, including: In response to a number of consecutive no-response attempts being less than or equal to a preset number of retries, the target address and probe signal are retransmitted to the bus. If the number of consecutive no-response attempts exceeds the preset number of retries, the detection result is determined to be a failure.

[0077] The number of consecutive no-response counts is recorded and compared with the preset number of retries.

[0078] Specifically, if the number of probes does not exceed the maximum number of retries, short-term probes will continue; if the maximum number of retries is exceeded, the probe will fail.

[0079] This avoids infinite looping of probes, balances recovery attempts and system resource consumption, prevents long waiting times, and speeds up fault handling.

[0080] In some specific implementations, in response to a failed detection result, determining the target device's device status as absent or faulty based on the detection data includes: Acquire probe data within the sliding window and determine at least one of the bus status, number of consecutive no-acknowledgments, number of no-acknowledgments in the address phase, and number of no-acknowledgments in the data phase; In response to the bus being in an idle state, compare the number of consecutive no-acknowledgments with the preset maximum number of no-acknowledgments when not in position. If the number of consecutive no-response events exceeds the preset maximum number of no-response events in the absence phase, the device status of the target device is determined to be absent based on the number of no-response events in the address phase and the number of no-response events in the data phase. In response to a non-idle bus state, compare the number of consecutive no-response counts with the preset maximum number of no-response counts for a fault. If the number of consecutive no-response events exceeds the preset maximum number of no-response events for a fault, the device status of the target device is determined to be faulty based on the number of no-response events in the address phase and the number of no-response events in the data phase.

[0081] Here, "out of place" refers to the state where the target device has been physically or electrically disconnected from the I2C bus.

[0082] The sliding window can be divided by time or by the number of read and write operations performed. For example, a sliding window can record ten transactions.

[0083] Specifically, if the bus is in an idle state, consec_nack_run (i.e., the number of consecutive no-acknowledgments) is greater than or equal to N_absent (i.e., the maximum number of no-acknowledgments when the device is not in place). The changes in the number of no-acknowledgments in the address phase and the number of no-acknowledgments in the data phase are counted within the sliding window. When the result is that addr_nack (i.e., the number of no-acknowledgments in the address phase) increases, but data_nack (i.e., the number of no-acknowledgments in the data phase) does not increase, the device state of the target device is determined to be not in place.

[0084] In one embodiment, the preset maximum number of times there is no response when not in place and the preset maximum number of times there is no response due to fault can be dynamically adjusted based on historical data (such as long-term success rate, distribution of no response types, ambient temperature, etc.) to obtain dynamic judgment conditions.

[0085] Specifically, basic communication quality characteristics (long-term success rate, short-term success rate within a sliding window, success rate decline trend, number of consecutive no-response and the proportion of address NACK to total NACK, etc.), advanced error mode characteristics (such as the standard deviation of the error rate, the speed at which the device recovers from consecutive NACKs, etc.), and context and environment characteristics (such as device type, real-time device temperature, ambient temperature, and cumulative device uptime, etc.) are collected to construct a feature vector; the feature vector is input into the trained prediction model, and the preset maximum number of no-response instances for non-location and the preset maximum number of no-response instances for faults are output.

[0086] In this way, trend anomalies can be identified by detecting data within the sliding window, thereby improving the accuracy of status judgment.

[0087] In some specific implementations, the device status of the target device is determined to be faulty based on the number of no-response events in the address phase and the number of no-response events in the data phase, including: Calculate the increment of the number of no-response instances in the address phase and the increment of the number of no-response instances in the data phase within the sliding window, respectively. Compare the increment of no-response counts during the address phase with the increment of no-response counts during the data phase; In response to an address phase no-response increment greater than a preset multiple, the address phase no-response increment and the data phase no-response increment are read at each time point within the sliding window. The difference between the address phase no-response increment and the data phase no-response increment at each time point is calculated to obtain multiple differences. Calculate the increment among multiple differences. If the increase among multiple differences is non-uniform, determine that the equipment state of the target equipment is faulty.

[0088] Here, non-uniform growth is a specific, uneven, and erroneous growth pattern.

[0089] Among them, the non-uniform increase is that in the most recent communication records (within the sliding window), the increase in the number of no-response records in the address phase is significantly higher than the increase in the number of no-response records in the data phase.

[0090] Specifically, when the bus is in a non-idle state, when consec_nack_run (i.e., the number of consecutive no-acknowledgments) is greater than or equal to N_fault (i.e., the maximum number of no-acknowledgments for a default fault), and within the most recent sliding window, the difference between addr_nack (i.e., the number of no-acknowledgments in the address phase) and data_nack (i.e., the number of no-acknowledgments in the address phase) increases non-uniformly, and the increment of address NACK (i.e., no-acknowledgment) within the sliding window is significantly higher than the increment of data NACK (e.g., the increment of address NACK is greater than the increment of data NACK * 2 + 2), the device state of the target device is faulty.

[0091] Thus, analyzing whether the difference increment is uniform can distinguish between random errors and systematic problems, thereby improving the accuracy of fault classification.

[0092] In some specific implementations, the method further includes: Sample the bus and read the serial clock line and serial data line; The bus state is determined to be idle in response to the serial clock line and serial data line being high. The bus state is determined to be non-idle in response to the presence of a low level on the serial clock line and serial data line.

[0093] Here, the serial clock line is controlled by the master device, providing a synchronous clock rhythm for all data transmission.

[0094] Here, the serial data line transmits data bidirectionally between the master and slave devices, carrying the actual address, command, and data information.

[0095] Specifically, during the start and stop phases, when SCL (the serial clock line) is high, a falling edge of SDA (the serial data line) indicates the start, and a rising edge indicates the stop. During the data transmission phase, 1 bit of data is transmitted within each clock pulse cycle of SCL. When SCL is high, the value of SDA is read; high is '1', and low is '0'. During the acknowledge phase, after transmitting every 8 bits of data, the sender releases the SDA line. During the 9th clock pulse, the receiver needs to pull the SDA line low to indicate an acknowledgement.

[0096] Specifically, if both SCL and SDA are read as high, it means the bus is idle; if either SCL or SDA is continuously pulled low, it means the bus is blocked and is not idle.

[0097] In this way, it can respond quickly to changes in bus status.

[0098] In some specific implementations, the method further includes: Obtain the number of no-response during the address phase, the number of no-response during the data phase, and the number of normal responses within the sliding window, and calculate the first slope. An alarm is generated in response to the first slope being less than the preset slope.

[0099] The first slope can be obtained by dividing the number of normal responses by (the number of no responses in the address phase + the number of no responses in the data phase + the number of normal responses).

[0100] This stage is calculated when the number of consecutive no-response attempts is less than or equal to the preset number of retries.

[0101] Specifically, an intermediate state notification is added. At this time, the device is still working, but its reliability is reduced and there is a high risk of failure. According to the calculation rules above, when the first slope is less than the preset variation slope, it indicates that the device performance is continuously deteriorating. If the value of consec_nack_run (i.e., the number of consecutive no responses) is not greater than the preset number of retries, but occurs frequently, that is, the target device needs to go through multiple retries to succeed, and the stability is deteriorating. When entering the performance degradation state, in addition to returning that the operation was successful, the driver should also report a warning event to the upper layer software.

[0102] In one embodiment, the health status of the upper-layer device can also be returned based on the probability of the fault type in the most recent time, which can provide early warning to the system and avoid greater losses when a real failure occurs.

[0103] In this way, the deterioration trend of the monitoring equipment can be detected and early warnings can be issued.

[0104] In one embodiment, Figure 2 This is a flowchart illustrating an embodiment of this application, such as... Figure 2As shown, the process in this application includes: starting or power-on reset; setting the device to the initial state (i.e., UNKNOWN); initiating a complete I2C transaction; entering the address phase and receiving the address phase response; if the address phase receives a normal response, entering the data phase and receiving the data phase response; if the data phase receives a normal response, the transaction is successful, the success count is incremented by 1, the consecutive no-response count is cleared to 0, and the device state is normal; if there is no response in the data phase, the data phase no-response count is incremented by 1 and the consecutive no-response count is incremented by 1, and the probe process is entered; if there is no response in the address phase, the address phase no-response count is incremented by 1 and the consecutive no-response count is incremented by 1, and the probe process is entered.

[0105] The detection process includes: waiting for the bus to be idle; initiating a short-rhythm detection; determining whether an acknowledgment has been received. If so, the detection is successful, the number of consecutive no-acknowledgments is cleared to zero, and the next transaction is restarted. If no acknowledgment is received, the detection fails, the number of consecutive no-acknowledgments is incremented by 1, and it is determined whether the number of retries has exceeded the limit. If not, it returns to waiting for the bus to be idle; if so, it enters the specific status identification process.

[0106] The specific status identification process includes: sampling and debouncing SCL and SDA to determine the bus status; determining whether the bus is idle; if the bus is idle, determining whether the number of consecutive no-response counts is greater than the preset number of no-response counts; if yes, returning the device status as no-response; if no, reporting to manual diagnosis; if the bus is not idle, determining whether the number of consecutive no-response counts is greater than the preset number of faults; if no, reporting to manual diagnosis; if yes, calculating the non-response difference within the sliding window; determining whether the non-response difference meets the non-uniform increase condition; if yes, returning the device status as fault; if no, reporting to manual diagnosis.

[0107] It should be understood that, although Figure 1 and Figure 2 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 and Figure 2 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0108] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0109] Embodiments of this application also provide a device status identification apparatus, comprising: a first processing module 301, configured to initiate a transaction to the bus including a target address and at least one data segment and receive an address phase response and a data phase response returned by the target device, wherein the target address is the address corresponding to the target device; a second processing module 302, configured to determine the device status of the target device based on the address phase response and the data phase response, wherein the device status includes normal and abnormal; a third processing module 303, configured to probe the target device in response to the device status of the target device being abnormal and obtain a probe result; a fourth processing module 304, configured to determine the abnormal phase based on the response in response to the probe result being successful and re-operate on the abnormal phase, wherein the abnormal phase includes an address phase and a data phase; and a fifth processing module 305, configured to determine the device status of the target device as absent or faulty based on the probe data in response to the probe result being failed.

[0110] In a preferred embodiment of this application, the first processing module 301 is specifically configured to: send a target address and a start signal to the bus, and receive an address phase response returned by the target device; in response to the address phase response being a normal response, enter the data phase; send at least one data segment to the target address to the bus, and receive a data phase response returned by the target device.

[0111] In a preferred embodiment of this application, the second processing module 302 is further configured to: in response to a no-response response in the address phase, increase the number of no-response responses in the address phase and the number of consecutive no-response responses, and determine that the device status of the target device is abnormal; in response to a normal response in the address phase, clear the number of consecutive no-response responses to zero and enter the data phase; in response to a no-response response in the data phase, increase the number of no-response responses in the data phase and the number of consecutive no-response responses, and determine that the device status of the target device is abnormal; in response to a normal response in the data phase, clear the number of consecutive no-response responses to zero, and determine that the device status of the target device is normal.

[0112] In a preferred embodiment of this application, the third processing module 303 is specifically used to: send a target address and a probe signal to the bus, and receive a probe response returned by the target device; in response to a normal probe response, clear the number of consecutive no responses to zero and determine that the probe result is successful; in response to a no response, increase the number of consecutive no responses, and determine whether the probe result is failed or retry based on the number of consecutive no responses.

[0113] In a preferred embodiment of this application, the third processing module 303 is further configured to: resend the target address and probe signal to the bus in response to the number of consecutive no-response counts being less than or equal to a preset retry count; and determine the probe result as a failure in response to the number of consecutive no-response counts being greater than the preset retry counts.

[0114] In a preferred embodiment of this application, the fifth processing module 305 is specifically configured to: acquire probe data within a sliding window, and determine at least one of the bus state, the number of consecutive no-response counts, the number of no-response counts in the address phase, and the number of no-response counts in the data phase; in response to the bus state being idle, compare the number of consecutive no-response counts with a preset maximum number of no-response counts for when the bus is not in place; in response to the number of consecutive no-response counts being greater than the preset maximum number of no-response counts for when the bus is not in place, determine the device state of the target device as when the bus is not in place based on the number of no-response counts in the address phase and the number of no-response counts in the data phase; in response to the bus state being non-idle, compare the number of consecutive no-response counts with a preset maximum number of no-response counts for when the bus is not in place; in response to the number of consecutive no-response counts being greater than the preset maximum number of no-response counts for when the bus is not in place, determine the device state of the target device as faulty based on the number of no-response counts in the address phase and the number of no-response counts in the data phase.

[0115] In a preferred embodiment of this application, the fifth processing module 305 is further configured to: calculate the increment of the number of no-response events in the address phase and the increment of the number of no-response events in the data phase within the sliding window; compare the increment of the number of no-response events in the address phase and the increment of the number of no-response events in the data phase; in response to the increment of the number of no-response events in the address phase being greater than a preset multiple of the increment of the number of no-response events in the data phase, read the number of no-response events in the address phase and the number of no-response events in the data phase corresponding to each time point within the sliding window, calculate the difference between the number of no-response events in the address phase and the number of no-response events in the data phase corresponding to each time point, and obtain multiple differences; calculate the increment between the multiple differences, and in response to the non-uniform increase between the multiple differences, determine that the device status of the target device is faulty.

[0116] In a preferred embodiment of this application, the fifth processing module 305 is further configured to: sample the bus and read the serial clock line and serial data line; determine that the bus state is idle in response to the serial clock line and serial data line being at a high level; and determine that the bus state is non-idle in response to the serial clock line and serial data line being at a low level.

[0117] In a preferred embodiment of this application, the device further includes an alarm module, which is specifically used to: obtain the number of no-response items in the address phase, the number of no-response items in the data phase, and the number of normal responses within the sliding window, and calculate a first slope; and generate an alarm in response to the first slope being less than a preset slope.

[0118] For a description of the features in the embodiment corresponding to the device status identification device, please refer to the relevant description in the embodiment corresponding to the device status identification method, which will not be repeated here.

[0119] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described embodiments of the device state identification method.

[0120] This electronic device can be a server, and its internal structure diagram can be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores device status identification data. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements a device status identification method.

[0121] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the device state identification method when running.

[0122] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0123] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described device state identification method embodiments.

[0124] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described device state identification method embodiments.

[0125] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0126] The foregoing has provided a detailed description of a device status identification method, electronic device, storage medium, and computer program product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A method for identifying device status, characterized in that, The method includes: Initiate a transaction on the bus that includes a target address and at least one data segment and receive an address phase response and a data phase response returned by the target device, wherein the target address is the address corresponding to the target device; The device status of the target device is determined based on the address phase response and the data phase response, wherein the device status includes normal and abnormal. In response to the target device's abnormal device status, the target device is probed, and the probe results are obtained; In response to a successful detection result, an abnormal phase is determined based on the response, and the abnormal phase is re-operated, wherein the abnormal phase includes an address phase and a data phase; In response to a failed detection result, the device status of the target device is determined to be either out of service or faulty based on the detection data.

2. The device status identification method according to claim 1, characterized in that, The step of initiating a transaction on the bus containing a target address and at least one data segment and receiving address phase acknowledgments and data phase acknowledgments returned by the target device includes: Send the target address and start signal to the bus, and receive the address phase response returned by the target device; If the response at the address stage is a normal response, proceed to the data stage; Send at least one data segment to the target address via the bus, and receive a data segment response returned by the target device.

3. The device status identification method according to claim 1, characterized in that, Determining the device status of the target device based on the address phase response and the data phase response includes: In response to the address phase response being no response, the number of no response in the address phase and the number of consecutive no response are increased, and the device status of the target device is determined to be abnormal. If the address phase response is a normal response, the number of consecutive no responses is cleared to zero, and the data phase begins. In response to the data phase response being no response, the number of no response in the data phase and the number of consecutive no responses are increased, and the device status of the target device is determined to be abnormal. In response to the data phase response being a normal response, the number of consecutive no-response events is cleared to zero, and the device status of the target device is determined to be normal.

4. The device status identification method according to claim 1, characterized in that, The response to the target device's device state being abnormal, including probing the target device and obtaining the probing results, includes: Send the target address and probe signal to the bus, and receive the probe response returned by the target device; In response to the received probe response being a normal response, the number of consecutive no responses is cleared to zero, and the probe result is determined to be successful; In response to the received probe response being no response, the consecutive no response count is incremented, and the probe result is determined to be either a failure or a retry based on the consecutive no response count.

5. The device status identification method according to claim 4, characterized in that, The response to a received probe response being no response, incrementing the consecutive no-response count, and determining whether the probe result is a failure or a retry based on the consecutive no-response count, includes: In response to the number of consecutive no-response counts being less than or equal to a preset number of retries, the target address and the probe signal are retransmitted to the bus. If the number of consecutive no-response events exceeds the preset number of retries, the detection result is determined to be a failure.

6. The device status identification method according to claim 1, characterized in that, The response to the detection result being a failure, determining the device status of the target device as absent or faulty based on the detection data, includes: Acquire probe data within the sliding window and determine at least one of the bus status, number of consecutive no-acknowledgments, number of no-acknowledgments in the address phase, and number of no-acknowledgments in the data phase; In response to the bus state being idle, the number of consecutive no-response counts is compared with the preset maximum number of no-response counts when the bus is not in place. In response to the number of consecutive no-response events exceeding the preset maximum number of no-response events in the absence phase, the device status of the target device is determined to be absent based on the number of no-response events in the address phase and the number of no-response events in the data phase. In response to the bus state being non-idle, compare the number of consecutive no-response counts with the preset maximum number of no-response counts for a fault. In response to the number of consecutive no-response events exceeding the preset maximum number of no-response events for a fault, the device status of the target device is determined to be faulty based on the number of no-response events in the address phase and the number of no-response events in the data phase.

7. The device status identification method according to claim 6, characterized in that, The step of determining the device status of the target device as faulty based on the number of no-response events in the address phase and the number of no-response events in the data phase includes: Calculate the increment of the number of no-response instances in the address phase and the increment of the number of no-response instances in the data phase within the sliding window, respectively. Compare the increment of no-response counts in the address phase with the increment of no-response counts in the data phase; In response to the address phase no response number increment being greater than a preset multiple of the data phase no response number increment, the address phase no response number and the data phase no response number corresponding to each time point in the sliding window are read, and the difference between the address phase no response number and the data phase no response number corresponding to each time point is calculated to obtain multiple differences; Calculate the increment among the multiple differences, and in response to the non-uniform increase among the multiple differences, determine that the device state of the target device is faulty.

8. The device status identification method according to claim 6, characterized in that, The method further includes: The bus is sampled to read the serial clock line and serial data line; In response to the serial clock line and the serial data line being at a high level, the bus state of the bus is determined to be idle; In response to a low level on the serial clock line and the serial data line, the bus state of the bus is determined to be non-idle.

9. The device status identification method according to claim 1, characterized in that, The method further includes: Obtain the number of no-response during the address phase, the number of no-response during the data phase, and the number of normal responses within the sliding window, and calculate the first slope. An alarm is generated in response to the first slope being less than a preset slope.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the device state identification method as described in any one of claims 1 to 9 when executing the computer program.

Images