Method and system for unified processing of multi-protocol device data in a domestication industrial computer

Abstract

The application provides a unified processing method and system for multi-protocol device data in a localized industrial computer, and relates to the technical field of computers. The application comprises: in response to a power-on instruction applied to a target board card, collecting a current sequence of the target board card, and receiving device data through a plurality of communication interfaces adopting at least two different communication protocols; dividing the current sequence into a plurality of current response segments and generating a start sequence; analyzing the device data, determining interface activation data of each communication interface from a non-working state to a working state, determining an interface state item and a current response segment corresponding to the interface activation data, and setting an interface gap for a non-activated interface; constructing and displaying a start chain according to the arrangement order of each current response segment, the interface state item and the interface gap, realizing the unified association of the working state of the interface of different communication protocols and the start process of the target board card, and improving the efficiency of start abnormality positioning.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a unified processing method and system for multi-protocol device data in domestically produced industrial computers. Background Technology

[0002] In the design process of domestically produced industrial computers, it is usually necessary to power on and verify the internal circuit boards to determine whether the boards and their connected communication interfaces can enter the working state normally according to the design requirements. As the functions integrated into the boards increase, the same board may have multiple communication interfaces using different communication protocols. Therefore, accurately monitoring the overall startup status of the boards after power-on is an important part of board design verification and fault debugging.

[0003] During the debugging process of existing circuit boards, the power supply and operating status of the board can be determined by monitoring electrical parameters such as voltage and current. Simultaneously, data from different communication interfaces can be acquired using communication testing tools to determine whether the corresponding communication interfaces are functioning correctly. For example, existing board management technologies can acquire the operating status of chips on the board and the status parameters of each power supply, and locate the faulty module on the board when the status parameters are abnormal. For different communication interfaces, interface data is typically acquired and parsed according to the corresponding communication protocol to determine the communication status of the interface.

[0004] However, during the boot verification process of a board with multiple communication interfaces using different communication protocols, the electrical state of the board and the operational state of each communication interface originate from different sources. Various status information is typically observed and judged separately, making it difficult to intuitively reflect the complete process from power-on to each communication interface sequentially entering its operational state. When a communication interface fails to enter its operational state normally, further manual investigation is required, combining the board's status and interface status at different stages, making it difficult to pinpoint the location of the anomaly in a timely manner. Therefore, existing technologies suffer from the technical problem of low efficiency in locating board boot anomalies. Summary of the Invention

[0005] The purpose of this application is to provide a unified processing method and system for multi-protocol device data in domestically produced industrial computers, so as to solve the problem of low efficiency in locating abnormal board startup in the prior art.

[0006] To address the aforementioned technical problems, in a first aspect, this application provides a unified processing method for multi-protocol device data in a domestically produced industrial computer, applicable to domestically produced industrial computers. The method includes: In response to a power-on command applied to a target board, the current sequence of the target board is acquired, and multiple sets of device data are received through multiple communication interfaces connected to the target board, wherein the multiple communication interfaces correspond to at least two different communication protocols. The current sequence is divided into multiple current response segments, and a start-up sequence is generated according to the order in which each current response segment appears. The device data corresponding to each communication interface is parsed according to the communication protocol used by each communication interface. For each communication interface, the data that first indicates the communication interface has changed from a non-working state to a working state in the parsing result is determined as the interface activation data. The interface status item of the interface activation data is determined. Based on the time information of the interface activation data and the start and end times of each current response segment, the current response segment corresponding to the interface activation data is determined. The communication interface that does not contain interface activation data in the parsing result is determined as an inactive interface, and an interface empty space is set corresponding to the inactive interface. The interface empty space is used to represent the logical position of the inactive interface in the expected startup sequence of each communication interface and is associated with the startup sequence, and does not have an activation time. Based on the order of the current response segments, the interface status items, and the interface vacancy slots, a startup chain is constructed to represent the target board from power-on to the entry of each communication interface into the working state, and the startup chain is displayed on the human-machine interface.

[0007] Optionally, the interface status item of the interface activation data is determined, and the current response segment corresponding to the interface activation data is determined based on the time information of the interface activation data and the start and end times of each current response segment, including: The interface identifier of the communication interface, the state change type represented by the interface activation data, and the reception time of the interface activation data are combined into an interface state item; Based on whether the device data corresponding to each communication interface is actively sent by the target board or returned in response to a query command sent by the domestic industrial computer, each communication interface is divided into an active reporting interface and a polling interface. For the active reporting interface, the transmission duration of the interface activation data is determined based on the number of complete message transmission bits of the corresponding interface activation data and the interface transmission rate. The reception time of the interface activation data is shifted forward by the transmission duration to obtain the estimated state change time of the active reporting interface. The current response segment whose start time is no later than the estimated state change time and whose end time is later than the estimated state change time is determined as the current response segment corresponding to the active reporting interface. The interface status item is written into the data record of the corresponding current response segment so that the interface activation data of each communication interface using different communication protocols are uniformly arranged according to the current response segment of the target board.

[0008] Secondly, this application provides a unified processing system for multi-protocol device data in domestically produced industrial computers, applied to domestically produced industrial computers, the system comprising: The acquisition module is used to acquire the current sequence of the target board in response to the power-on command applied to the target board, and to receive multiple sets of device data through multiple communication interfaces connected to the target board, wherein the multiple communication interfaces correspond to at least two different communication protocols. A segmentation module is used to divide the current sequence into multiple current response segments and generate a start-up sequence according to the order in which each current response segment appears. The parsing module is used to parse the corresponding device data according to the communication protocol adopted by each communication interface. For each communication interface, the data that first indicates the communication interface has changed from a non-working state to a working state in the parsing result is determined as the interface activation data. The interface status item of the interface activation data is determined. Based on the time information of the interface activation data and the start and end times of each current response segment, the current response segment corresponding to the interface activation data is determined. The determination module is used to determine communication interfaces that do not contain interface activation data in the parsing results as inactive interfaces, and to set an interface empty slot corresponding to the inactive interface. The interface empty slot is used to represent the logical position of the inactive interface in the expected startup sequence of each communication interface, and is associated with the startup sequence, and does not have an activation time. The module is used to construct a startup chain representing the target board from power-on to the entry of each communication interface into working state, based on the arrangement order of each current response segment, the interface status item, and the interface empty slot, and to display the startup chain on the human-machine interface.

[0009] Thirdly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor, used to execute the computer program to implement the steps of the unified processing method for multi-protocol device data in a domestically produced industrial computer as described in the first aspect above.

[0010] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps of the unified processing method for multi-protocol device data in a domestically produced industrial computer as described in the first aspect above.

[0011] Fifthly, this application provides a computer program product, which includes a computer program that, when executed by a processor, can implement the steps of the unified processing method for multi-protocol device data in a domestically produced industrial computer as described in the first aspect above.

[0012] The unified processing method for multi-protocol device data in domestically produced industrial computers provided in this application has the following beneficial effects: By collecting the current sequence of the target board and device data of different communication protocols, the current changes of the target board and the working information of each communication interface can be synchronously acquired and aligned; by dividing the current response segments and generating the startup sequence, different startup stages of the target board can be distinguished; by determining the interface activation data of each communication interface from the inactive state to the working state, and determining the current response segment corresponding to the interface activation data according to the time information, the correspondence between the working state of each communication interface and the startup stage of the target board can be established, realizing the unified organization of the working states of different communication interfaces; by setting the interface slots corresponding to the inactive interfaces, the position of the inactive interfaces in the expected startup sequence can be retained; by constructing and displaying the startup chain, the process from power-on to each communication interface entering the working state of the target board can be intuitively presented, making it easier to identify the communication interfaces that are not working properly and their startup stages, thereby improving the efficiency of target board startup state analysis and startup anomaly location.

[0013] Furthermore, by combining the interface identifier, state change type, and reception time of the interface activation data of the communication interface into an interface state item, and writing the interface state item into the corresponding current response segment according to the time information, the interface activation data of different communication protocols can be uniformly arranged according to the current response segment. By distinguishing between active reporting interfaces and polling interfaces, for active reporting interfaces, the estimated state change time and the corresponding current response segment can be determined based on the number of bits transmitted in the complete message, the interface transmission rate, and the reception time, which can reduce the time deviation caused by data transmission. For polling interfaces, the state change interval can be determined based on the last response data and the first response data, and the corresponding current response segment can be determined based on the overlap duration with each current response segment. When the estimated state change time is difficult to determine directly, the corresponding current response segment can be matched, thereby improving the accuracy of the correspondence between the working state of different communication interfaces and the startup stage of the target board, and providing a reliable data foundation for startup anomaly location. Attached Figure Description

[0014] To more clearly illustrate the technical solutions of the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art 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.

[0015] Figure 1 A flowchart illustrating a unified processing method for multi-protocol device data in a domestically produced industrial computer, provided as an embodiment of this application; Figure 2 Example diagram of hardware connection provided for embodiments of this application; Figure 3 A schematic diagram illustrating the change of current over time as provided in an embodiment of this application; Figure 4 This is a schematic diagram showing the location of the interface empty space provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of a unified processing system for multi-protocol device data in a domestically produced industrial computer, provided as an embodiment of this application. Detailed Implementation

[0016] In the design and startup verification process of domestically produced industrial computers, target boards typically have multiple communication interfaces using different communication protocols. Under current debugging methods, the board's electrical information and the operational status of each communication interface are usually analyzed separately, making it difficult to establish a correspondence with the actual startup process. When a communication interface fails to enter its normal operational state, it is difficult for personnel to promptly identify the abnormal interface and its startup stage, requiring further investigation using multiple types of data, resulting in low efficiency in locating board startup anomalies.

[0017] To address the aforementioned issues, this application provides a unified processing method for multi-protocol device data in domestically produced industrial computers. This method involves collecting the current sequence of the target board and receiving device data from different communication protocols. The current sequence is divided into current response segments to form a startup sequence. Interface activation data is determined from the device data, and the resulting interface status items are associated with the corresponding current response segments. Simultaneously, interface vacancies are set for inactive interfaces, thereby constructing and displaying the startup chain. This unified organization of board current changes and the working status of different communication interfaces according to the startup process facilitates the identification of malfunctioning communication interfaces and their startup stages, improving the efficiency of board startup anomaly location.

[0018] 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. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] Figure 1 This is a flowchart illustrating a unified processing method for multi-protocol device data in a domestically produced industrial computer, as provided in an embodiment of this application. Figure 1 As shown, the method includes: S11. In response to a power-on command applied to the target board, the current sequence of the target board is acquired, and multiple sets of device data are received through multiple communication interfaces connected to the target board, wherein the multiple communication interfaces correspond to at least two different communication protocols.

[0020] Among them, such as Figure 2 As shown, the domestically produced industrial computer 201 serves as the test host, and the target board 202 is the board under test connected to the test host and requiring power-on debugging. This embodiment uses a verification board with the Phytium FT-2000 / 4 as the main processor as an example. Referring to the interface configuration of the existing COME-B6F241 module, two serial ports, one CAN interface, and one Ethernet interface are selected for testing via the matching baseboard. I1, I2, I3, and I4 are used below to represent the first serial port, CAN interface, second serial port, and Ethernet interface, respectively. These identifiers are used to distinguish the communication interfaces used in this test and do not represent the manufacturer's pin numbers.

[0021] To prepare for data acquisition before the target board is powered on, the test host and acquisition control unit 203 are powered on first, and their power supplies are separate from those of the target board. Each communication interface is connected to the acquisition control unit via a matched level conversion or transceiver circuit. For the power supply to the target board, a power input module 204 can be used in this embodiment, with a shunt resistor 205 and a current acquisition module 206 set in the power supply circuit. The current acquisition module 206 measures the voltage across the shunt resistor and converts it into a current sampling value; the object of the data acquisition is the power input to the target board.

[0022] Based on the above connections, firmware is pre-configured for the target board, enabling I1 and I2 to actively send status messages, and I3 and I4 to respond to Modbus RTU status queries and UDP diagnostic queries, respectively. The status provided by the firmware distinguishes between two scenarios: the interface has not yet completed its scheduled initialization and self-test, and it has completed its scheduled initialization and self-test. These status messages and query responses received by each communication interface constitute the device data for this step.

[0023] After completing the hardware connection and firmware configuration, the test host first clears the reception records from the previous test and then activates the receiving channels of each communication interface through the acquisition control unit, setting the current sampling period, status query interval, and acquisition duration. At this time, the target board is still not powered on, so data from the initial startup phase will not be missed due to the receiving channels being activated too late. The acquisition duration can be determined based on the allowed startup waiting time and data reception margin for this test, used to limit the data range for subsequent judgment of inactive interfaces.

[0024] After preparation, the test host sends a power-on command to the acquisition control unit to power on the target board. The acquisition control unit outputs a power-on control signal, taking the actual output time of this signal as time zero. It then acquires current according to a preset current sampling period, simultaneously receiving active data reports from I1 and I2, and sending status queries to I3 and I4 at preset status query intervals. The acquisition control unit uses the same timer to record each current sampling time and the completion time of receiving complete device data. The test host retains these time records when reading data and does not use the software read time to replace the actual acquisition or reception time.

[0025] After the data acquisition deadline is reached, the current sample values ​​and their corresponding sampling times are arranged chronologically to obtain the current sequence used by S12. The data from each group of devices, along with their interface identifiers and reception completion times, are saved for parsing and time matching by S13. In this way, the current sequence and device data not only come from the same power-on test but also use the same time reference.

[0026] The following steps use the same set of illustrative data: the current sampling period is 1 millisecond, the time recording resolution is 0.01 milliseconds, and the acquisition cutoff time is 12000 milliseconds after power-on. Some device data are shown in Table 1. The processor and module models are used to illustrate the hardware scenario; the firmware, functional domain division, and current and time data are all implementation example settings and are not the factory functions, rated parameters, or actual measurement results of the module.

[0027] Table 1. Interface and device data in the same round of power-on testing

[0028] S12. Divide the current sequence into multiple current response segments, and generate a start-up sequence according to the order in which each current response segment appears.

[0029] As one possible implementation, S12 is implemented through the following process: Step 121: Calculate the change between adjacent current sample values ​​in the current sequence according to the sampling order, and divide the current sequence into current rising interval, current falling interval and current stable interval according to the direction of change of multiple consecutive changes.

[0030] This step, based on the current sequence saved in S11, subtracts the previous current sample value from the subsequent current sample value to obtain the change in each adjacent sample value. A preset change threshold is set to positive. A change greater than the preset change threshold is recorded as an increase; a change less than the preset change threshold (negative) is recorded as a decrease; and a change between the negative and positive values ​​of the preset change threshold is recorded as stable. After the same determination is achieved consecutively a preset number of times, the corresponding interval is confirmed, and the previous sampling time corresponding to the first change in the aforementioned consecutive changes is taken as the starting point of the interval. Sporadic fluctuations that do not meet the consecutive number of times do not form a new interval independently.

[0031] The current stability interval indicates that the variation in adjacent current sample values ​​remains within an acceptable range, and it is not required that the current sample values ​​be exactly the same. The use of a variation threshold and a number of consecutive iterations is to avoid misinterpreting a single sampling fluctuation as a new phase of current change.

[0032] Continuing with the same round of testing as in Table 1, the threshold for change was set to 0.01 amperes, and the number of consecutive determinations was 3. From time 0 to 3 milliseconds, the current values ​​were 0.20, 0.35, 0.50, and 0.65 amperes, respectively. All three adjacent changes were 0.15 amperes, continuously exceeding 0.01 amperes, thus confirming the current rise interval starting from time 0. The current reached 1.40 amperes at 8 milliseconds, and from 9 to 11 milliseconds, the values ​​were 1.401, 1.399, and 1.400 amperes, respectively. Adjacent changes were 0.001, -0.002, and 0.001 amperes, with absolute values ​​not exceeding 0.01 amperes, thus confirming the current stabilization interval starting from 8 milliseconds. The current decline interval was determined in the same way, but the change was required to be continuously less than -0.01 amperes.

[0033] Step 122: Combine at least one of the current rising interval and the current falling interval with the current stable interval that follows the current interval into a current response segment.

[0034] Specifically, starting from the beginning of the current rising or falling interval, subsequent intervals are read sequentially and merged with the immediately following current stabilization interval. When a continuous current change occurs again after stabilization, the current current response segment ends at the starting point of this change and the next current response segment begins. When a continuous rising or falling current occurs before stabilization, the continuous change process is merged with the subsequent stabilization interval, and sampling intervals already assigned to other current response segments are not reused.

[0035] The current response segment includes the start time, end time, and corresponding current sample values. In the example above, combined with... Figure 3It can be seen that the current rises from zero to 8 milliseconds, and then stabilizes at 3000 milliseconds. Therefore, these two adjacent intervals are merged into E1; the next current change starting at 3000 milliseconds is used to form E2. Continuing to process according to the same rules, we obtain Table 2.

[0036] Table 2 Current response segments formed by merging current ranges

[0037] Each current response segment includes a start time, so that the estimated state change time at the boundary of the adjacent segment is included in the next current response segment. The last current response segment ends at the acquisition cutoff time set in S11; if the current change at the end has not yet reached a stable range, the existing sampling records are retained and marked as not having been observed to be stable, and are not interpreted as the start-up being completed.

[0038] The current response segment primarily represents the stage of overall current change on the board, and is not directly equivalent to a specific functional domain. A functional domain is a circuit section defined based on the board's schematic and power supply control relationships. Subsequently, S14 uses the relationship between functional domains and communication interfaces to determine the interface startup sequence. Only when a functional domain is time-sharing powered on, other loads remain essentially unchanged, and the corresponding relationships have been verified, is a current response segment used to further represent the current change process of the corresponding functional domain from the initial power supply to entering a stable operating state; current stability does not directly indicate that the communication interface is ready.

[0039] Step 123: Arrange the current response segments according to the order of their start times to obtain the starting sequence.

[0040] This step is arranged from earliest to latest according to the start time, forming a startup sequence of E1, E2, E3, and E4. Each record in the startup sequence stores the current response segment number, start and end times, and current sampling value, and reserves space for writing the interface status item so that S13 can use these start and end times for time matching and then write the corresponding interface status item into the corresponding record.

[0041] Through steps 121 to 123, the continuous current record can be organized into data segments with clear time boundaries and sequence, providing a common basis for arranging the status information of different communication interfaces.

[0042] S13. Parse the corresponding device data according to the communication protocol used by each communication interface. For each communication interface, determine the data in the parsing result that first indicates that the communication interface has changed from a non-working state to a working state as the interface activation data. Determine the interface status item of the interface activation data. Based on the time information of the interface activation data and the start and end times of each current response segment, determine the current response segment corresponding to the interface activation data.

[0043] In this step, the process of determining the interface activation data is as follows: search for the data in the corresponding device data that first indicates the communication interface has changed from a non-working state to a working state after the power-on command, and determine the found data as the interface activation data of the communication interface.

[0044] To perform the above lookup, the saved device data is first parsed according to the diagnostic protocol configured in S11. The firmware in this embodiment sets independent ready state values ​​for each communication interface: 0 when the predetermined initialization and self-test have not been completed, and 1 after completion. Entering the working state in this embodiment refers to completing the above initialization and self-test, not just being able to exchange basic diagnostic messages. Therefore, the interface can first return to the not-ready state through the basic transceiver channel, and then return to the ready state after having the predetermined communication functions.

[0045] Specifically, the I1 status message is 12 bytes long. Bytes 1 and 2 are the frame headers A5 and 5A, byte 3 is the status value, bytes 4 through 11 are set to zero in this example, and byte 12 is the checksum of the first 11 bytes, with the lower 8 bits being the result. The receiving end confirms the frame header, length, and checksum before reading the third byte. For I2, the receiving end recognizes the status message with the CAN identifier 0x181 and reads the first data byte. For I4, the receiving end recognizes the valid response to the corresponding UDP diagnostic query and reads the first byte of the payload. The positions of these bytes can be pre-set and are not part of the status format specified by the FT-2000 / 4 manufacturer.

[0046] For the I3, the test host reads a 16-bit status value from protocol address 0x0000 via Modbus RTU function code 0x03. 0x0000 indicates not ready, and 0x0001 indicates ready. This protocol address is mapped to the interface ready state by the firmware and is not an internal hardware register address of the processor. The receiving end checks the device address, function code, data length, and CRC check before reading the status value.

[0047] For example, when the device address of I3 is set to 1, the not-ready response is 0103020000B844, and the ready response is 010302 00017984. The first three bytes represent the device address, function code, and number of data bytes, respectively; the next two bytes are the status value; and the last two bytes are the CRC checksum with the least significant byte first. Therefore, the response received at 5800 milliseconds in Table 1 is interpreted as not ready, and the response received at 6400 milliseconds is interpreted as ready.

[0048] This power-on reset brings all interfaces back to a non-working state. After the above analysis, the first valid ready data for each interface is searched according to the reception time: In Table 1, the data received by I1 at 3005 milliseconds, I3 at 6400 milliseconds, and I4 at 10400 milliseconds become the corresponding interface activation data; I2 only appeared in a non-ready state during the acquisition period, and no interface activation data was found. Subsequent repeated ready data will not generate repeated interface activation data.

[0049] After obtaining the interface activation data, the interface status item of the interface activation data is determined. Based on the time information of the interface activation data and the start and end times of each current response segment, the current response segment corresponding to the interface activation data is determined. Specifically: Step 131: Combine the interface identifier of the communication interface, the state change type represented by the interface activation data, and the reception time of the interface activation data into an interface state item.

[0050] The interface status item is a data record that documents an interface activation. The interface identifier corresponding to the interface activation data, the parsed state change type, and the reception completion time saved in S11 are written into the same record to obtain the interface status item. For example, the interface status item for I1 records the interface identifier I1, the state change type from inactive to active, and the reception time of 3005 milliseconds. This reception time is used to retain the original reception data and is not replaced by the estimated state change time in step 132.

[0051] Step 132: Determine the current response segment corresponding to the interface activation data. The interface status item already indicates which interface has undergone a state change, but it hasn't yet determined which current response segment should be written into it. This step uses the time information of the interface activation data to match the segmentation boundary obtained in S12, and selects the chosen current response segment as the corresponding current response segment for writing into the interface status item in step 133.

[0052] Specifically, step 132 is implemented through the following process: Step a1: Based on whether the device data corresponding to each communication interface is actively sent by the target board or returned in response to a query command sent by the domestic industrial computer, classify each communication interface into an active reporting interface and a polling interface.

[0053] In this step, the data acquisition method and transmission / reception records configured in S11 are used to distinguish between interfaces that do not rely on queries and whose status data is sent automatically by the target board: these are active reporting interfaces; interfaces that return status data after receiving a query are polling interfaces. In this example, I1 and I2 are active reporting interfaces, while I3 and I4 are polling interfaces. For interfaces that have already obtained interface activation data, they enter the corresponding time matching process according to their category; I2, which has not yet obtained interface activation data, is processed by S14.

[0054] Step a21: For the active reporting interface, determine the transmission duration of the interface activation data based on the number of complete message transmission bits of the corresponding interface activation data and the interface transmission rate, and shift the reception time of the interface activation data forward by the transmission duration to obtain the estimated state change time of the active reporting interface.

[0055] When actively reported data arrives at the receiving end, it has already undergone the transmission process. Therefore, the transmission duration is first calculated based on the actual number of bits occupied by the complete message on the transmission line and the transmission rate, and then this duration is subtracted from the time of reception completion. The calculation of the number of bits includes the necessary overhead of the corresponding protocol and serial transmission, not just the status field itself.

[0056] Taking I1 as an example, its transmission rate is set to 9600 bits per second. Each byte includes one start bit, eight data bits, and one stop bit, and 12 bytes are transmitted continuously. Therefore, the actual transmission length is the product of 12 and 10, which equals 120 bits. Dividing 120 bits by 9600 bits per second gives 0.0125 seconds, or 12.5 milliseconds. Subtracting 12.5 milliseconds from the reception completion time of 3005 milliseconds gives the estimated state change time of 2992.5 milliseconds.

[0057] This example demonstrates the above backtracking based on the conditions that a message is sent after an interface state change, with no obvious queuing or intermediate forwarding. The resulting time is the estimated state change time. If there are non-negligible firmware processing waits or buffer delays, simply deducting the transmission time cannot eliminate these additional deviations. Therefore, the estimated state change time is used for time matching and does not represent the absolute measured time of the interface state change.

[0058] Step a22: Determine the current response segment whose start time is no later than the estimated state change time and whose end time is later than the estimated state change time as the current response segment corresponding to the active reporting interface.

[0059] It should be understood that after obtaining the estimated state change time, it is compared with the start and end times of each current response segment in the startup sequence. I1's 2992.5 milliseconds falls within the range of 0 to 3000 milliseconds of E1, so E1 is chosen; if the 3005 milliseconds reception time were used directly, it would fall into E2. This can reduce the correlation deviation caused when the message transmission crosses the segment boundary.

[0060] Step a31: For the polling interface, obtain the last response data indicating that the polling interface has not yet entered the working state and the first response data indicating that the polling interface has entered the working state, and determine the time range between the time of receiving the last response data and the time of receiving the first response data as the state change interval.

[0061] It should be understood that the last response is a non-ready response, and the first response is a ready response. Polling obtains the interface status once a response is received. Therefore, after receiving the first ready response, it searches backward for the most recent valid non-ready response and uses the range between the two reception times as the state change interval for subsequent comparison with the current response segment.

[0062] According to Table 1, the last response of I3 is received at 5800 milliseconds and the first response is received at 6400 milliseconds, thus obtaining the state change range of 5800 to 6400 milliseconds; similarly, the state change range of I4 is obtained from 9600 to 10400 milliseconds.

[0063] It should be noted that query timeouts or verification failures are not considered valid unready responses. Interfaces that have not yet received a ready response are handled by S14; if the data in this round is insufficient to determine the state change range according to the above rules, polling and re-collection can be performed, and the power-on time or no-response record should not be used to replace the last response data.

[0064] Step a32: For each current response segment, determine the later time between the start time of the current response segment and the start time of the state change interval as the overlap start point, and determine the earlier time between the end time of the current response segment and the end time of the state change interval as the overlap end point, and determine the overlap duration between the current response segment and the state change interval based on the overlap start point and the overlap end point.

[0065] After obtaining the state change interval, this step sequentially calculates the time length covered by it and each current response segment. If the overlap end point is later than the overlap start point, the difference between the two is the overlap duration; otherwise, it is recorded as zero.

[0066] Taking I3 as an example, its state change interval of 5800 to 6400 milliseconds, compared with E2, has a later start time of 5800 milliseconds and an earlier end time of 6000 milliseconds, with an overlap duration of 6000 minus 5800, which equals 200 milliseconds. Compared with E3, it has a later start time of 6000 milliseconds and an earlier end time of 6400 milliseconds, with an overlap duration of 6400 minus 6000, which equals 400 milliseconds. This state change interval does not overlap with E1 and E4, and the overlap duration is zero for both.

[0067] Step a33: Determine the current response segment with the longest overlap time as the current response segment corresponding to the polling interface.

[0068] For example, the 400-millisecond overlap between I3 and E3 is greater than the 200-millisecond overlap with E2, therefore E3 is identified as the current response segment corresponding to I3.

[0069] The entire 9600 to 10400 millisecond range of I4 falls within E4, and the overlap time is 10400 minus 9600, which equals 800 milliseconds. Therefore, E4 is selected as the current response segment corresponding to I4.

[0070] As one possible implementation, after determining the overlap duration of the current response segment and the state change interval based on the overlap start point and the overlap end point, the method further includes: when the overlap duration of multiple current response segments is the same, determining the current response segment with the latest start time among the multiple current response segments as the current response segment corresponding to the polling interface.

[0071] For example, keeping the current segmentation unchanged, in another set of illustrative data for the same board, the last not-ready response and the first ready response of I3 are received at 5500 ms and 6500 ms, respectively. Its overlap with E2 is 6000 minus 5500, which equals 500 ms; its overlap with E3 is 6500 minus 6000, which also equals 500 ms. Both are maximum values, and the start time of E3 (6000 ms) is later than that of E2 (3000 ms), therefore E3 is selected. This rule handles cases where multiple maximum overlap times are the same, and current response segments with zero overlap times are not considered valid candidates.

[0072] Step 133: Write the interface status item into the data record of the corresponding current response segment so that the interface activation data of each communication interface using different communication protocols are uniformly arranged according to the current response segment of the target board.

[0073] For example, the interface status entry for I1 is written to E1, the interface status entry for I3 is written to E3, and the interface status entry for I4 is written to E4. I2 has no interface activation data, so no corresponding interface status entry is generated, and its interface slot is determined by S14. At this point, the data from different communication protocols have been associated according to the same startup sequence, instead of remaining separately in their respective receive records.

[0074] Through the above processing, the original interface state and receiving basis can be preserved, and it can be classified into the corresponding current response segment according to the time characteristics of active reporting or polling, so as to provide verifiable correlation results for subsequent demonstration of the startup process.

[0075] S14. The communication interface that does not contain interface activation data in the parsing result is determined as an inactive interface, and an interface empty space corresponding to the inactive interface is set. The interface empty space is used to represent the logical position of the inactive interface in the expected startup sequence of each communication interface and is associated with the startup sequence, and does not have an activation time.

[0076] After completing S13, the communication interfaces that have obtained interface activation data have corresponding interface status entries, but the interfaces that have not obtained interface activation data have not yet appeared in these records. This step checks the parsing results of each interface during the entire acquisition period set in S11, determines the interfaces for which interface activation data has not been found as inactive interfaces, and then reserves their position in the expected startup sequence through the interface empty slots.

[0077] The interface empty slot is a data record used to record the expected startup position of an inactive interface. It includes at least the interface identifier of the inactive interface, its inactive state, and the preceding and following interface identifiers and sorting criteria used to determine its logical position. It does not contain fictitious activation times or current response segment numbers. In this example, the data received by I2 at 4000 ms and 8000 ms both indicate that it is not ready. No valid ready state is observed until 12000 ms; therefore, I2 is determined to be an inactive interface. Figure 4 As shown in the first chain, I2 corresponds to an empty interface slot. This result indicates that the interface did not complete its scheduled startup in this round, which is not directly equivalent to interface hardware failure. A final judgment should not be made based on the temporary lack of interface activation data before the data acquisition is completed; if the acquisition is interrupted, the acquisition conditions should be restored first, and data should be acquired again.

[0078] As one possible implementation, the process for setting up empty slots for inactive interfaces includes the following steps: Step 141: Generate an interface startup order table based on the power supply activation order of each functional domain in the target board, the affiliation relationship between each communication interface and each functional domain, and the initialization order of each communication interface within the same functional domain. The interface startup order table records the functional domain corresponding to each communication interface and the startup order relationship between each communication interface.

[0079] Since there is no interface activation data available for time matching for inactive interfaces, it is necessary to determine their expected location using the startup sequence specified in the board design. Specifically, the activation sequence of each functional domain is read from the power supply control configuration of the baseboard, the interface affiliation is determined according to the connection relationship of the control and transceiver circuits in the schematic diagram, and then an interface startup sequence table is generated according to the interface initialization sequence specified in the design; when there are multiple interfaces in the same functional domain, the initialization sequence within that domain is used to further arrange them.

[0080] Table 3 is derived under the example condition that the matching baseboard has a corresponding domain power supply configuration and the power supply process does not stop due to the inability of a single interface to be ready. This table is for illustrative purposes only and does not indicate that the COME-B6F241 finished module has been divided into independent power supply domains in this way.

[0081] Table 3 Interface Startup Order Table

[0082] Table 3 shows the power supply activation sequence and the expected interface startup sequence. The interface startup sequence table is generated based on the power supply activation sequence, interface affiliation, and interface initialization sequence within the same functional domain, and is used to determine the expected location of the following interface slots.

[0083] Step 142: Determine the startup position of the inactive interface in each communication interface according to the interface startup sequence table.

[0084] The startup order of inactive interfaces is obtained by looking up the interface identifier in Table 3. Then, combined with the activated interfaces identified in S13, the nearest activated interface is searched forward and backward in the table. For example, if I2 is in the 2nd position, the preceding activated interface is I1 and the following activated interface is I3. Therefore, the expected startup position of I2 is determined to be between I1 and I3.

[0085] Step 143: When the start position indicates the existence of a preceding interface and a following interface, set the interface vacancy at the logical start position between the interface status item of the preceding interface and the interface status item of the following interface. The preceding interface is the activated interface before the inactive interface, and the following interface is the activated interface after the inactive interface.

[0086] Based on I1 and I3 obtained in the previous step, their interface status entries are searched in the startup sequence, and an interface slot corresponding to I2 is set at the logical startup position between the interface status entries of I1 and I3. This interface slot uses I1 and I3 as the basis for their sequential position, only indicating that I2 should appear between them in the expected order. It does not determine whether I2 has been activated or failed in E2, nor does it fill in its actual activation time or current response segment number.

[0087] When the preceding and following interfaces are located in the same current response segment, an interface space is set between the two interface status items within that segment; when there is no independent current response segment between them, the logical position between the interfaces is retained, and no non-existent current response segment is generated.

[0088] When multiple consecutive communication interfaces are inactive, interface slots corresponding to the multiple inactive interfaces are sequentially set between the preceding and following interfaces according to the startup order.

[0089] For example, in another set of descriptive data for the same board, I2 and I3 did not obtain interface activation data, while I1 and I4 were already activated. Figure 4 As shown in the second chain, according to Table 3, I2 and I3 are set up in sequence between I1 and I4, and the interface identifiers are recorded respectively. The two inactive interfaces are not merged into one blank position.

[0090] As another possible implementation, after determining the activation location of the inactive interface in each communication interface, the method further includes: When the startup position indicates that the inactive interface is at the beginning of the startup sequence of each communication interface, the interface empty slot is set before the interface status item corresponding to the first activated interface; when the startup position indicates that the inactive interface is at the end of the startup sequence of each communication interface, the interface empty slot is set after the interface status item corresponding to the last activated interface.

[0091] These two approaches are suitable for situations where either the preceding or following interface is missing. For example, such as... Figure 4 As shown in the third chain, when I1 is not active while I2, I3, and I4 are active, the empty interface slot corresponding to I1 is set before the interface status item of I2; for example... Figure 4 As shown in the fourth chain, when I4 is not activated while I1, I2, and I3 are activated, the empty interface slot corresponding to I4 is set after the interface status item of I3. When multiple inactive interfaces exist consecutively at the beginning or end, they are set one by one according to the order in Table 3; when all interfaces are inactive, all empty interface slots are arranged according to Table 3 and displayed together with the current response segment, without forcibly determining the actual measurement time position of each empty slot.

[0092] The aforementioned positioning is based on the condition that the order of activated interfaces matches the interface startup order table. If the two are inconsistent, the position of the interface status item obtained by S13 based on the time information is retained, and a message indicating an order discrepancy is displayed. The already obtained interface status items are not moved to forcibly satisfy the preset order. Through the above processing, the startup sequence retains both the obtained interface activation information and the inactive interfaces and their expected positions, avoiding the omission of interfaces that need to be checked in subsequent displays due to a lack of activation data.

[0093] S15. Based on the arrangement order of each current response segment, the interface status item, and the interface empty slot, construct a startup chain representing the target board from power-on to each communication interface entering the working state, and display the startup chain on the human-machine interface.

[0094] As one possible implementation, the startup chain construction process includes the following steps: Step 151: Generate stage nodes according to the order of each current response segment in the startup sequence, write each interface status item into the stage node of the corresponding current response segment, and insert each interface empty space between the corresponding adjacent interface status items according to the interface startup sequence table.

[0095] This step uses the current response segments formed in S12, the interface status items written in S13, and the interface empty slots set in S14. First, each current response segment is read according to the startup sequence, and a stage node is generated for each current response segment. The segment number, start and end times, and associated interface status items are stored in the node. Then, the interface empty slots are reserved according to the sequence determined in S14 so that they can appear between the corresponding interfaces in subsequent displays.

[0096] In this context, the stage node is the data record of the current response segment in the startup chain. Even if a current response segment has no interface status item, the corresponding stage node is retained to avoid missing the current changes that have already been collected. In this example, the stage nodes corresponding to E1, E3, and E4 are written into the interface status items of I1, I3, and I4, respectively, while the stage node corresponding to E2 retains the current record; the empty interface slot in I2 is located between I1 and I3 and is not considered as an actual interface activation event measured within E2.

[0097] Step 152: According to the arrangement order of each stage node and the startup order of each interface status item and interface slot, connect each stage node, interface status item and interface slot in sequence to obtain the startup chain.

[0098] Based on the records obtained in step 151, the stage nodes are connected in the order of E1, E2, E3, and E4, maintaining the association between each interface status item and its corresponding node, as well as the sequential relationship of the interface slots, to form a startup chain. In implementation, the stage nodes are saved as a list in sequence, the interface status items are saved in the corresponding nodes, and the correspondence between the interface slots and their preceding and following interfaces is saved; this allows for reading the board current stage by time, as well as the sequential relationship between activated and inactive interfaces.

[0099] On the human-machine interface, stage nodes and their time ranges are displayed in list order. The corresponding node displays the interface identifier, status, and time correlation basis, and interface empty spaces are displayed between the preceding and following interfaces. The interface status item indicates the activated records that have been obtained, while the interface empty space is displayed as no activation observed, and the position is marked according to the interface start sequence table to distinguish between the actual collected information and the expected start position.

[0100] In the example, the display content of the stage nodes and associated interfaces is shown in Table 4; the empty interface corresponding to I2 is displayed in the expected order position between I1 and I3, and no activation time is assigned to this empty position.

[0101] Table 4. Display content of each stage node in the startup chain

[0102] As shown above, R&D personnel can check the activation status of I1, I3, and I4 along the startup process. They will find that the CAN interface I2, located between I1 and I3, has not yet been activated. This allows them to check the power supply, initialization, and communication connection conditions in conjunction with relevant current records. Unstable sampling records at the end of S12 can also be marked and displayed, preventing incomplete processes from being shown as normal completion. These results are used to assist in troubleshooting and do not directly determine the cause of damage to the FT-2000 / 4 chip or a specific device malfunction.

[0103] Through steps S11 to S15, the current sequence is segmented to provide the time sequence of the startup process. Device data from different communication protocols, after parsing and time matching, provides the activation status of each interface. Interface gaps are filled with the expected locations of inactive interfaces. These three types of information together form a comparable startup chain, reducing the need to separately review current records and interface data, and facilitating the analysis of the target board's startup status and troubleshooting startup anomalies. The above examples can be configured according to the actual board's circuitry, firmware, and data acquisition conditions; this application does not necessarily limit the listed processor models and example values.

[0104] Figure 5 A schematic diagram of the structure of a unified processing system for multi-protocol device data in a domestically produced industrial computer, provided in an embodiment of this application, is shown below. Figure 5 The system may include: The acquisition module 51 is used to acquire the current sequence of the target board in response to a power-on command applied to the target board, and to receive multiple sets of device data through multiple communication interfaces connected to the target board, wherein the multiple communication interfaces correspond to at least two different communication protocols.

[0105] The division module 52 is used to divide the current sequence into multiple current response segments and generate a start-up sequence according to the order of appearance of each current response segment.

[0106] The parsing module 53 is used to parse the corresponding device data according to the communication protocol adopted by each communication interface. For each communication interface, the data that first indicates the communication interface has changed from a non-working state to a working state in the parsing result is determined as the interface activation data. The interface status item of the interface activation data is determined. Based on the time information of the interface activation data and the start and end times of each current response segment, the current response segment corresponding to the interface activation data is determined.

[0107] The determination module 54 is used to determine the communication interface that does not contain interface activation data in the parsing result as an inactive interface, and set an interface empty space corresponding to the inactive interface. The interface empty space is used to represent the logical position of the inactive interface in the expected startup sequence of each communication interface and is associated with the startup sequence, and does not have an activation time.

[0108] The construction module 55 is used to construct a startup chain representing the target board from power-on to the entry of each communication interface into working state according to the arrangement order of each current response segment, the interface status item and the interface empty slot, and to display the startup chain on the human-machine interface.

[0109] The unified processing system for multi-protocol device data in domestically produced industrial computers according to the embodiments of this application is used to implement the aforementioned unified processing method for multi-protocol device data in domestically produced industrial computers. Therefore, the specific implementation of the unified processing system for multi-protocol device data in domestically produced industrial computers can be found in the embodiment section of the unified processing method for multi-protocol device data in domestically produced industrial computers mentioned above. The specific implementation can be referred to the description of the corresponding embodiments, which will not be repeated here.

[0110] This application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the unified processing method for multi-protocol device data in any of the aforementioned domestically produced industrial computers.

[0111] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the unified processing method for multi-protocol device data in any of the above-described domestically produced industrial computers.

[0112] 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 USB flash drives, read-only memory, random access memory, portable hard drives, magnetic disks, or optical disks.

[0113] The embodiments of this application also provide a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements the steps in the embodiments of the unified processing method for multi-protocol device data in any of the domestically produced industrial computers described above.

[0114] 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 implement the described functions using different methods for each specific application, but such implementation should not be considered beyond the scope of this application.

[0115] The above provides a detailed description of a unified processing method and system for multi-protocol device data in a domestically produced industrial computer. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. 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 unified processing of multi-protocol device data in a localized industrial computer, applied to a localized industrial computer, characterized in that, include: In response to a power-on command applied to a target board, the current sequence of the target board is acquired, and multiple sets of device data are received through multiple communication interfaces connected to the target board, wherein the multiple communication interfaces correspond to at least two different communication protocols. The current sequence is divided into multiple current response segments, and a start-up sequence is generated according to the order in which each current response segment appears. The device data corresponding to each communication interface is parsed according to the communication protocol used by each communication interface. For each communication interface, the data that first indicates the communication interface has changed from a non-working state to a working state in the parsing result is determined as the interface activation data. The interface status item of the interface activation data is determined. Based on the time information of the interface activation data and the start and end times of each current response segment, the current response segment corresponding to the interface activation data is determined. The communication interface that does not contain interface activation data in the parsing result is determined as an inactive interface, and an interface empty space is set corresponding to the inactive interface. The interface empty space is used to represent the logical position of the inactive interface in the expected startup sequence of each communication interface and is associated with the startup sequence, and does not have an activation time. Based on the order of the current response segments, the interface status items, and the interface vacancy slots, a startup chain is constructed to represent the target board from power-on to the entry of each communication interface into the working state, and the startup chain is displayed on the human-machine interface.

2. The method of claim 1, wherein, The interface status item of the interface activation data is determined. Based on the time information of the interface activation data and the start and end times of each current response segment, the current response segment corresponding to the interface activation data is determined, including: The interface identifier of the communication interface, the state change type represented by the interface activation data, and the reception time of the interface activation data are combined into an interface state item; Based on whether the device data corresponding to each communication interface is actively sent by the target board or returned in response to a query command sent by the domestic industrial computer, each communication interface is divided into an active reporting interface and a polling interface. For the active reporting interface, the transmission duration of the interface activation data is determined based on the number of complete message transmission bits of the corresponding interface activation data and the interface transmission rate. The reception time of the interface activation data is shifted forward by the transmission duration to obtain the estimated state change time of the active reporting interface. The current response segment whose start time is no later than the estimated state change time and whose end time is later than the estimated state change time is determined as the current response segment corresponding to the active reporting interface. The interface status item is written into the data record of the corresponding current response segment so that the interface activation data of each communication interface using different communication protocols are uniformly arranged according to the current response segment of the target board.

3. The method of claim 2, wherein, After classifying the communication interfaces into active reporting interfaces and polling interfaces, the method further includes: For the polling interface, the last response data indicating that the polling interface has not yet entered the working state and the first response data indicating that the polling interface has entered the working state are obtained, and the time range between the time of receiving the last response data and the time of receiving the first response data is determined as the state change interval. For each current response segment, the later time between the start time of the current response segment and the start time of the state change interval is determined as the overlap start point, and the earlier time between the end time of the current response segment and the end time of the state change interval is determined as the overlap end point. The overlap duration between the current response segment and the state change interval is determined based on the overlap start point and the overlap end point. The current response segment with the longest overlap time is determined as the current response segment corresponding to the polling interface.

4. The method of claim 3, wherein, After determining the overlap duration between the current response segment and the state change interval based on the overlap start point and the overlap end point, the method further includes: When multiple current response segments overlap for the same duration, the current response segment with the latest start time among the multiple current response segments is determined as the current response segment corresponding to the polling interface.

5. The method of claim 1, wherein, Setting up an empty interface slot corresponding to the inactive interface includes: Based on the power supply activation order of each functional domain in the target board, the affiliation relationship between each communication interface and each functional domain, and the initialization order of each communication interface within the same functional domain, an interface startup order table is generated. The interface startup order table records the functional domain corresponding to each communication interface and the startup order relationship between each communication interface. According to the interface startup order table, determine the startup position of the inactive interface in each communication interface; When the start position indicates the existence of a preceding interface and a following interface, the interface vacancy is set at the logical start position between the interface status item of the preceding interface and the interface status item of the following interface. The preceding interface is the activated interface before the inactive interface, and the following interface is the activated interface after the inactive interface.

6. The method of claim 5, wherein, After determining the activation location of the inactive interface in each communication interface, the method further includes: When the startup position indicates that the inactive interface is at the start of each communication interface, the interface empty slot is set before the interface status item corresponding to the first activated interface; When the startup position indicates that the inactive interface is at the end of the startup position of each communication interface, the interface empty slot is set after the interface status item corresponding to the last activated interface.

7. The method of claim 1, wherein, The current sequence is divided into multiple current response segments, and a start-up sequence is generated according to the order in which each current response segment appears, including: The change between adjacent current sample values ​​in the current sequence is calculated according to the sampling order, and the current sequence is divided into a current rising interval, a current falling interval, and a current stable interval according to the direction of change of multiple consecutive changes. Combine at least one of the current rising interval and the current falling interval with the adjacent current steady interval to form a current response segment; The current response segments are arranged in the order of their start times to obtain the starting sequence.

8. The method of claim 1, wherein, The step of determining the data in the parsing result that first indicates the communication interface has changed from a non-working state to a working state as interface activation data includes: The system retrieves the data from the corresponding device data that first indicates the communication interface has changed from a non-working state to a working state after the power-on command, and determines the retrieved data as the interface activation data of the communication interface.

9. The method of claim 5, wherein, The step of constructing a startup chain representing the target board from power-on to the entry of each communication interface into working state, based on the arrangement order of each current response segment, the interface status item, and the interface empty slot, includes: Stage nodes are generated according to the order of each current response segment in the startup sequence. Each interface status item is written into the stage node of the corresponding current response segment, and each interface empty space is inserted between the corresponding adjacent interface status items according to the interface startup sequence table. According to the arrangement order of the nodes in each stage and the startup order of each interface status item and interface slot, the nodes in each stage, interface status items and interface slots are connected in sequence to obtain the startup chain.

10. A system for uniform processing of multi-protocol device data in a localized industrial computer, applied to a localized industrial computer, characterized in that, include: The acquisition module is used to acquire the current sequence of the target board in response to the power-on command applied to the target board, and to receive multiple sets of device data through multiple communication interfaces connected to the target board, wherein the multiple communication interfaces correspond to at least two different communication protocols. A segmentation module is used to divide the current sequence into multiple current response segments and generate a start-up sequence according to the order in which each current response segment appears. The parsing module is used to parse the corresponding device data according to the communication protocol adopted by each communication interface. For each communication interface, the data that first indicates the communication interface has changed from a non-working state to a working state in the parsing result is determined as the interface activation data. The interface status item of the interface activation data is determined. Based on the time information of the interface activation data and the start and end times of each current response segment, the current response segment corresponding to the interface activation data is determined. The determination module is used to determine communication interfaces that do not contain interface activation data in the parsing results as inactive interfaces, and to set an interface empty slot corresponding to the inactive interface. The interface empty slot is used to represent the logical position of the inactive interface in the expected startup sequence of each communication interface, and is associated with the startup sequence, and does not have an activation time. The module is used to construct a startup chain representing the target board from power-on to the entry of each communication interface into working state, based on the arrangement order of each current response segment, the interface status item, and the interface empty slot, and to display the startup chain on the human-machine interface.

Images