UDP (User Datagram Protocol) communication fault diagnosis and recovery method based on multi-dimensional perception of health degree of protocol stack

Abstract

The invention relates to a UDP communication fault diagnosis and recovery method based on protocol stack health degree multi-dimensional perception, and belongs to the technical field of embedded systems and computer network communication. According to the method, aiming at a difficult fault that Ping communication is carried out between devices but UDP applications cannot carry out communication, an internal state of a network protocol stack is actively sensed through a built-in diagnosis agent module, and a traditional external packet capturing means is replaced. The diagnosis process comprises the steps of link layer reachability verification, protocol stack load channel detection, Socket interface state auditing and memory pool and task health degree inspection. The system constructs a protocol stack health degree vector through multi-dimensional sensing data, and performs fault mode matching based on a preset rule base. Once the fault root cause is positioned, the system can automatically trigger a repair action or report an accurate alarm. According to the invention, through automatic and intelligent diagnosis and self-healing embedded in the system, the reliability and maintainability of the embedded network equipment are greatly improved.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of embedded systems and computer network communication, and particularly relates to a UDP communication fault diagnosis and recovery method based on protocol stack health multi-dimensional perception. BACKGROUND

[0002] In the embedded systems in the fields of industrial control, aerospace, network equipment, etc., VxWorks is widely used due to its excellent real-time performance and reliability. These devices often communicate critical data through the Ethernet UDP protocol. In actual deployment and maintenance, a tricky problem is often encountered: two devices can reach each other through the ICMP protocol (Ping command), proving that the physical link and the protocol stack below the IP layer are normal, but the application program running on the UDP protocol cannot communicate. No UDP data packets can be captured using network packet capture tools (such as Wireshark) on the mirror port of the switch or the local machine, and Telnet commands cannot be connected.

[0003] The traditional troubleshooting method highly depends on the experience of engineers and needs external tools for assistance. The troubleshooting process usually includes: confirming the firewall, checking the network card power saving mode, verifying the switch configuration, checking the network task status, memory pool status, Socket configuration, etc. in the VxWorks system. This process has obvious disadvantages: 1. Low efficiency: manual intervention is required, and the process is time-consuming and laborious.

[0004] 2. Experience-dependent: checking the deep system kernel status (such as Socket specific parameters, memory pool details) requires engineers to have a deep understanding of the VxWorks kernel.

[0005] 3. Blind area exists: external packet capture tools cannot capture internal exceptions of the system kernel protocol stack (such as Socket configuration errors causing data packets not to be correctly sent), resulting in a diagnostic blind area of "seeing Ping and not capturing packets".

[0006] 4. Cannot self-heal: even if the problem is located, manual restart of the application or system is usually required, and automatic recovery cannot be achieved.

[0007] Therefore, an innovative solution is urgently needed that can be built into the system, can see through the internal status of the protocol stack, and can automatically diagnose and recover such difficult faults. SUMMARY

[0008] (I) Technical problems to be solved The present application provides a UDP communication fault intelligent diagnosis and recovery method based on protocol stack health multi-dimensional perception, which solves the problems in the VxWorks operating system: 1. Depend on system external packet capture, can not peep inside the real situation of system kernel protocol stack.

[0009] 2. Need engineers to check each system parameter manually through command line, the process is tedious.

[0010] 3. For internal problems such as socket configuration error, memory pool leakage, etc., only rely on guess and trial and error.

[0011] 4. After finding the problem, usually need manual intervention to restart or reconfigure, can not automatically recover. Technical scheme

[0012] In order to solve the above technical problems, the application provides a UDP communication fault diagnosis and recovery method based on protocol stack health degree multi-dimensional perception, comprising the following steps: S1: deploying a diagnostic agent in the VxWorks embedded operating system, the diagnostic agent is designed to have the ability to access and detect the internal state of the embedded operating system kernel network protocol stack; S2: in response to the UDP application communication fault event, the diagnostic agent performs link layer reachability verification to confirm the network interface driver and physical link state; S3: in response to the UDP application communication fault event, the diagnostic agent program performs protocol stack load channel detection, sends diagnostic UDP packets to the target port and listens to the response to verify the protocol stack upper layer data path; S4: in response to the UDP application communication fault event, the diagnostic agent program performs Socket interface state audit, checks the configuration parameters, state and binding relationship of the Socket handle associated with the fault application; S5: in response to the UDP application communication fault event, the diagnostic agent program performs system resource health check, including checking network memory pool, protocol stack task state and related semaphore; S6: the results of steps S2 to S5 generate a protocol stack health vector; S7: match the protocol stack health vector with the pre-set fault rule library to locate the fault root cause; S8: according to the fault root cause matched in step S7, execute the predefined recovery action or generate the alarm information containing the fault root cause.

[0013] (Three) beneficial effects The innovation of the present application compared with the traditional method is: 1, creatively deploy a diagnostic agent with the highest authority in the operating system kernel. This agent no longer depends on external packet capture, but directly reads the key data structure of the protocol stack to obtain the first-hand fault information; 2. Completely bypass the application Socket interface, directly with the "heart bypass" way to test the protocol stack transceiver function; 3. Through the "multi-dimensional perception - rule matching - automatic execution" closed loop system, build a complete intelligent diagnosis and self-healing system; 4. Deeply coupled to the kernel characteristics of embedded real-time systems such as VxWorks, greatly improving the diagnostic accuracy and effectiveness.

[0014] The application is applicable to the field of industrial control, network equipment and other embedded fields, and can significantly improve the network fault diagnosis efficiency of VxWorks operating system. DETAILED DESCRIPTION

[0015] In order to make the purpose, content and advantages of the present application more clear, the specific embodiments of the present application are further described in combination with examples.

[0016] The present application provides a UDP communication fault intelligent diagnosis and recovery method based on protocol stack health multi-dimensional perception for embedded systems (especially VxWorks). The method is aimed at the difficult fault that Ping is available between devices but UDP application cannot communicate. The internal state of network protocol stack is actively perceived by the built-in diagnostic agent module, replacing the traditional external packet capture means. The diagnosis process includes: link layer reachability verification, protocol stack load channel detection, Socket interface state audit and memory pool and task health check. The system constructs a "protocol stack health vector" through multi-dimensional perception data, and performs fault mode matching based on the pre-set rule library. Once the fault root cause is located, the system can automatically trigger repair action or report accurate alarm. The present application greatly improves the reliability and maintainability of embedded network equipment through the built-in, automatic and intelligent diagnosis and self-healing.

[0017] The present application provides a UDP communication fault intelligent diagnosis and recovery method based on protocol stack health multi-dimensional perception, which provides an intelligent UDP communication fault diagnosis and recovery scheme deeply integrated in the internal of embedded system. The scheme actively perceives the complete data path state of network protocol stack from driver to interface through a built-in "diagnostic agent", realizes the detection of "blind area" which cannot be touched by traditional external tools, and can automatically trigger repair, greatly improving the availability of the device.

[0018] Only by adopting the scheme of the application, the technical pain points existing in the current VxWorks system network troubleshooting and positioning method can be effectively solved. The intelligent diagnosis and recovery method of UDP communication fault proposed in the application changes the previous passive and blind fault troubleshooting process which relies on external tools and expert experience into an active, visual and automatic intelligent self-healing process built in the system. It directly hits the blind area of the traditional external packet capture tool, can find and solve deep problems such as Socket configuration error and kernel resource depletion, significantly improves the reliability and maintainability of the embedded network device, and reduces the system downtime.

[0019] The intelligent diagnosis and recovery method of UDP communication fault based on protocol stack health degree multi-dimensional perception proposed in the application comprises the following steps: S1: deploying a diagnostic agent program in the VxWorks embedded operating system, wherein the diagnostic agent program is designed to have the ability to access and detect the internal state of the kernel network protocol stack of the embedded operating system; The deployment mode of the diagnostic agent program is as follows: (1) source code level integration: when compiling and building the final VxWorks operating system image, the source code of the diagnostic agent program and other kernel components of the VxWorks operating system will be compiled and linked together to become an inseparable part of the image file.

[0020] (2) starting when the VxWorks operating system is initialized: the VxWorks operating system is powered on and started, and after the network protocol stack is initialized, the main task (for example, named tDiagTask) of the diagnostic agent program is started by calling the kernel task creation function in the usrRoot() function. This main task has a very high priority to ensure that it can respond in time when diagnosis is needed.

[0021] (3) static configuration and rule library embedding: the rule library (i.e. the mapping table of fault modes and recovery strategies) required by the diagnostic agent program is directly coded in the source code of the diagnostic agent program in the form of a constant data structure, or loaded into the fixed area of the kernel memory as a configuration file when the VxWorks operating system is started.

[0022] The function module of the diagnostic agent program is designed to include: The self-checking and monitoring module is used for internal self-checking and external monitoring; it regularly checks whether the diagnostic program itself is running healthily (such as whether the core task is alive and whether the resource consumption is normal), to ensure that it has reliable ability to diagnose; it is responsible for monitoring and receiving diagnostic commands sent from the outside, verifying the legality thereof, triggering the internal diagnosis process, and reporting the results to the external user after the diagnosis is completed; Multi-dimensional perception diagnosis module, for automatically performing a complete set of inspection procedures in sequence, including: (a) Link connectivity check: performing Ping operation; (b) Protocol stack load channel test: autonomously constructing and sending probe UDP packets; (c) Socket state audit: traversing and checking all key configurations of the Socket used by the application program; (d) VxWorks operating system resource check: checking the remaining space of the network memory pool and the state of the core network task; Rule base and decision engine module, for storing pre-defined "if-then" (IF-THEN) rules, which receives the inspection results (i.e. "health vector") from the multi-dimensional perception diagnosis module, and matches it with the rule base, thereby drawing the fault diagnosis conclusion and determining the recovery strategy, and sending the instruction for recovery operation to the automatic execution and recovery module; Automatic execution and recovery module, for directly invoking kernel functions to perform repair operations according to the instructions of the rule base and decision engine module; Result reporting module, for sending the final fault diagnosis conclusion, the recovery action (repair operation) taken, and the recovery execution result to the external requester through the log or directly through its communication interface, completing a complete diagnosis report.

[0023] The capabilities of the diagnostic agent program to access and detect the internal state of the operating system kernel network protocol stack include: The diagnostic agent program has kernel-level permissions and identity The main task (tDiagTask) of the diagnostic agent program is assigned the highest execution permission level (usually running in kernel mode in VxWorks) when created, which means that the VxWorks operating system does not impose any restrictions on its access to memory and hardware, and it can access any memory address and data structure; (2) The diagnostic agent program can directly access memory, including the following operations: Check Socket: The VxWorks kernel maintains a linked list of all Sockets, and the diagnostic agent program can directly traverse this linked list to read the field values in each Socket structure; Check memory pool: The diagnostic agent program can obtain the symbol name and memory address of the network memory pool, directly read the "free block number" field in this memory pool (structure), and thus determine whether it is exhausted; Check task status: The diagnostic agent calls the taskInfoGet() function provided by the kernel, passing in the ID of the target task (such as tNetTask), and the kernel returns a structure containing all the status information of the target task (status, priority, stack, etc.). The diagnostic agent parses this structure to obtain the task status.

[0024] (3) The diagnostic agent can directly call kernel functions.

[0025] Send probe packets: Instead of sending probe packets through the application's Socket API, the diagnostic agent directly calls lower-level sending functions within the protocol stack and injects the manually constructed data packets into the protocol stack. Perform recovery: When fixing Socket options, the diagnostic agent directly calls the setsockopt() function provided by the kernel; when restarting tasks, the diagnostic agent directly calls the taskRestart() function.

[0026] S2: In response to a UDP application communication failure event, the diagnostic agent performs link layer reachability verification to confirm the status of the network interface driver and physical link. The link layer reachability verification specifically includes the diagnostic agent calling the ping command or directly sending an ICMP echo request message to the peer device to confirm whether the physical network card, driver, and IP protocol stack are functioning normally.

[0027] S 21 : Select and configure the test interface To lock the target hardware to be tested, the diagnostic agent first determines which physical network interface to use for testing. The diagnostic agent accesses the network device list of the VxWorks operating system (a global data structure maintained by the kernel that contains all network card information) directly to obtain detailed information about the interface. S 22 : Construct a raw, harmless data link layer test frame Instead of constructing a complete IP packet (like ping), the diagnostic agent manually creates a test frame in memory that can test the ability to send and receive raw bit streams, while ensuring that the test frame is not mistaken by the VxWorks operating system's own protocol stack as a data packet that needs to be processed, thereby avoiding interference with the VxWorks operating system itself. This test frame is usually in Ethernet protocol format and contains: (1) Destination MAC address: Set to the MAC address of the peer device (if known) or set to the broadcast address (FF:FF:FF:FF:FF:FF); (2) Source MAC address: set to the MAC address of the local interface; (3) EtherType: set to a protocol number that is not in common use or is for experimental use (e.g. 0xAAAA), or set to the standard ARP protocol number (0x0806). The key is that this protocol number should not be processed by the higher layer protocol (such as the IP protocol stack) of the local or peer device, so as to avoid unpredictable interaction; (4) Payload: fill in a simple, pre-defined data pattern, such as repeated 0x55 or 0xAA, which is convenient for the receiving end to detect.

[0028] S 23 : directly call the underlying packet sending function (driver sending function) to send the test frame The diagnostic agent program, by virtue of its kernel permission, bypasses the entire TCP / IP protocol stack and directly finds the underlying packet sending function provided by the network interface device driver, and calls the underlying packet sending function to send the test frame (original frame) constructed in step S 22 with the memory address and length as parameters. 22 Construct the test frame; S 24 : Collaborative reception by the diagnostic agent program (companion agent) deployed on the peer device On the peer device, the diagnostic agent program of the present application is also running. The diagnostic agent program will instruct its network card driver to enter a "promiscuous mode" to listen to a specific EtherType. In this mode, the network card driver will receive all frames flowing through its port, not just frames whose target MAC address is its own.

[0029] S 25 : Verify reception and response (1) Receive the test frame The network card driver of the diagnostic agent program of the peer device, upon receiving the test frame of the specific EtherType, will not hand it over to the protocol stack, but will directly hand it over to the waiting diagnostic agent program; The diagnostic agent program of the peer device checks the content of the test frame to confirm that its source MAC address and payload data are consistent with expectations; If the test frame is received and the content is correct, it proves that the physical link (network cable, switch port) and the basic receive and transmit functions of the network card drivers of both parties are completely normal.

[0030] (2) Request ARP response The diagnostic agent program of the local device constructs a standard ARP request broadcast frame (EtherType 0x0806) to inquire the MAC address of a fictitious, non-existent IP address; This ARP request broadcast frame will be received by all devices on the link. Although no device owns this fictitious IP, the network interface and driver of the peer device will perform hardware-level checks (such as CRC check) on the broadcast frame when it is received, confirming that it is a correctly formatted frame; The diagnostic agent of the peer device will capture this broadcast frame in "promiscuous mode"; If the diagnostic agent of the peer device can capture this locally originated ARP request broadcast frame, it is also a proof that the basic functionality of the physical link and driver is intact. This method takes advantage of the standard ARP protocol mechanism, and is more reliable and universal.

[0031] S 26 : Result determination After sending the test frame, the diagnostic agent of the local device waits for a short timeout, and receives the "successful reception" confirmation signal sent back by the diagnostic agent of the peer device through an internal communication channel (such as a simple TCP connection); If the confirmation is received: the diagnostic agent of the local device records "link layer reachability verification: passed".

[0032] If the confirmation is not received within the timeout: it means that the fault may be in one of the links in the path of the local driver, physical network cable, switch port, peer driver. This will generate a clear alarm, indicating the engineer to check the physical connection and driver, instead of wasting time in the application layer.

[0033] S3: In response to the UDP application communication failure event, the diagnostic agent performs protocol stack payload channel detection, sends a diagnostic UDP packet to the target port and listens for a response to verify the protocol stack upper layer data path; The protocol stack payload channel detection specifically includes: the diagnostic agent of the local device constructs a standard UDP protocol data packet in the kernel state, and sends it to the corresponding port of the target device (i.e. the peer device) through the local protocol stack, while opening a temporary listening port on the local device to receive the response packet of the diagnostic agent of the peer device, so as to determine whether the protocol stack application layer data transmission and reception function is normal.

[0034] S 31 : Create a temporary listening socket Before sending the probe packet, the diagnostic agent of the local device first creates a brand new, clean UDP socket on the local device, i.e. calls the socket() function of the kernel to create a socket with the protocol family AF_INET and the type SOCK_DGRAM. Subsequently, it calls the bind() function to bind this socket to a specific, idle high port (for example, the pre-defined port number 55555). S 32 : Constructing a diagnostic UDP packet as a probe packet in kernel mode The native diagnostic agent does not go through any application interface, but directly does the following: (1) Allocating raw data: calling a kernel memory management function (such as netClBlkGetO), directly allocating a memory buffer (called clBlk) of appropriate size from the network memory pool. This memory buffer will be used to load the raw data to be constructed; (2) Manually filling in the protocol headers: the native diagnostic agent manually fills in the protocol headers at the head of the memory buffer, like assembling a model: IP header: setting the source IP (the local IP), the destination IP (the peer device IP), the protocol number (17, representing UDP), the TTL value, etc. UDP header: setting the source port (the temporary listening port created in the previous step, such as 55555), the destination port (the target port of the application to be tested), the packet length, and the checksum.

[0035] Filling in the payload data: after the UDP header, fill in a specific and easily identifiable data content, such as the string "VXWORKS_DIAG_PROBE". This payload data is equivalent to the "password" of the probe packet; Through the above operations, a UDP data packet with absolutely correct format is generated. This packet is perfect in protocol, and if it still cannot communicate, the problem must not be in the protocol format itself.

[0036] S 33 : Submitting the probe packet to the protocol stack for sending The native diagnostic agent also does not go through the standard Socket sending interface (such as sendtoO), but directly calls a more low-level protocol stack sending function provided by the VxWorks operating system kernel for internal module use. It passes the address of the memory buffer assembled in step S 32 to this protocol stack sending function as a parameter. This operation can bypass the application's Socket interface and directly "inject" the perfect probe packet into the IP layer of the protocol stack to test whether the protocol stack sending function is normal.

[0037] S 34 : Synchronously listening on the temporary port In order to open a clean, reliable monitoring channel, used to receive the response of this test, to avoid being disturbed by other application data, while sending the probe packet, the local diagnostic agent calls the recvfrom() function on the previously created temporary Socket, and sets a reasonable timeout (such as 3 seconds), waiting for the response from the peer device.

[0038] S 35 : Peer device's collaborative response The diagnostic agent of the peer device works in "promiscuous mode" or through the registration service, listening to that specific target port. When the diagnostic agent of the peer device receives the probe packet with the destination port "the port of the application to be tested" and the data content "special password VXWORKS_DIAG_PROBE", it will not hand it over to the suspicious application being tested, but will be immediately captured by the diagnostic agent of the peer device.

[0039] Response: The diagnostic agent of the peer device will actively construct a response packet. The source port of this response packet is the target port, and the destination port is the source port in the probe packet (i.e. the temporary port 55555 of the local agent), and the payload data can be a response password such as "VXWORKS_DIAG_ACK". Then, the diagnostic agent of the peer device sends this response packet back to the local machine through the kernel sending function.

[0040] S 36 : Result analysis and conclusion (1) Success scenario: The diagnostic agent of the local machine receives the UDP packet sent back by the peer device, containing the expected response password, from its temporary Socket within the timeout period.

[0041] Conclusion: The protocol stack payload channel is completely normal. This proves: (a) The local protocol stack can correctly send UDP packets; (b) The protocol stack of the peer device can correctly receive UDP packets and deliver them to the target port; (c) The protocol stack of the peer device can correctly send back the response packet; (d) The local protocol stack can correctly receive the response packet and hand it over to the correct Socket.

[0042] Inference: Since the protocol stack itself is not a problem, the root cause of the application communication failure is most likely a Socket configuration error of the application itself (e.g. broadcast option not enabled, binding error, etc.). This will guide the agent to enter the next phase of Socket state audit.

[0043] (2) Failure scenario: No response is received within the timeout period.

[0044] Conclusion: The protocol stack load channel is faulty. The fault point may be located in the upper layer of the protocol stack (UDP layer or Socket layer) of the local or peer device.

[0045] Inference: The problem may be more complex, possibly related to system resources (such as network memory pool depletion) or protocol stack task exceptions. This will guide the agent into the system resource health check phase.

[0046] S4: In response to the UDP application communication failure event, the diagnostic agent performs a Socket interface state audit to check the configuration parameters, state, and binding relationship of the Socket handle associated with the faulty application. The Socket interface state audit specifically includes: the local diagnostic agent program traverses the system Socket list to check the following parameters of the target Socket: Socket type, protocol family, local IP address and port number binding state, broadcast permission setting, option setting, and compares them with the expected configuration of the application.

[0047] When the "protocol stack load channel detection" confirms that the protocol stack itself is functioning normally, the root cause of the failure is highly concentrated on the configuration and state of the specific Socket used by the application. The goal of this step is: to deeply operate the system kernel, find the Socket created by the faulty application, and comprehensively check all key configuration parameters and state information, and compare them with the correct configuration, to find the error configuration.

[0048] S 41 : Find the Socket of the application The diagnostic agent first accesses this global Socket link table to find the Socket belonging to the faulty application from the Socket link table. This is achieved by one of the following two ways: (1) Through task ID association: Each Socket has a field in its internal structure to record the ID of the task (Task) that created it. The diagnostic agent obtains the task ID of the faulty application through system functions (such as taskNameToId()), and then traverses the Socket link table, compares the "creator task ID" field of each Socket, and the matching Socket is the target; (2) Through known port number: If the port number that the application should use is known, the diagnostic agent will traverse the link table to check whether the local port number (sin_port field) bound by each Socket matches the port number that the application should use.

[0049] S 42 : Deep scanning, checking key configuration parameters one by one After finding the target Socket, the diagnostic agent starts directly reading various fields in its kernel data structure (usually struct socket or struct sockaddr, etc.), including: Socket type and protocol family, binding status and address information, Socket options, sending and receiving buffer status.

[0050] S 43 : Compare with "health standard" To achieve automatic judgment, the diagnostic agent is built-in with a set of "health standards". This set of standards can be pre-stored in the rule library. The diagnostic agent will compare the actual parameters audited one by one with this set of health standards.

[0051] S 44 : Generate diagnostic conclusion According to the comparison results of step S 43 , the diagnostic agent provides immediate action and accurate fault location information, replacing the previous vague guess of "may be a port problem, may be an option problem". The example conclusion is as follows: "Fault root cause positioning success: Socket broadcast option (SO_BROADCAST) is not turned on." "Warning: Socket is not bound to the specified port, currently using a random port." "Abnormal: Socket sending buffer is continuously full, which may indicate a too fast sending loop problem." S5: In response to the UDP application communication failure event, the diagnostic agent performs system resource health check, including checking network memory pool, protocol stack task status and related semaphore; The system resource health check specifically includes: checking the number of remaining blocks of the network memory pool, checking whether the network task state is suspended, deleted or ready, and checking whether the related semaphore is abnormal.

[0052] This step detects the status of key global resources supported by the VxWorks operating system kernel for network communication. Once these key global resources are abnormal, it will cause the protocol stack to be unable to allocate memory, process data or schedule tasks.

[0053] S 51 : Check network memory pool (1) Locate resources: the diagnostic agent directly accesses the memory pool data structure through the symbol name or memory address of the memory pool, reads the key fields in it, and the most important field is "the number of current free blocks"; (2) Analysis and judgment: the diagnosis agent compares the number of free blocks numBlocksFree with a preset safety threshold (e.g., 10% of the total number of blocks), and draws a conclusion about the health or failure state of the memory pool.

[0054] Healthy state: numBlocksFree > threshold, indicating that the memory is sufficient.

[0055] Failure state: numBlocksFree <= threshold, even 0. Conclusion: the network memory pool has run out or is severely insufficient, which is usually caused by memory leakage or encountering a traffic storm.

[0056] S 52 : Check the task state of the protocol stack (1) The diagnosis agent parses the task ID from the task name (e.g., tNetTask), and then calls the taskInfoGet(ID, &taskInfo) function of the kernel, which fills in a taskInfo structure containing detailed state information of the task; (2) Analyze the key state field: the diagnosis agent focuses on checking the status state field in the taskInfoGet(ID, &taskInfo) function (taskInfo structure): Healthy state: status is READY, indicating that the task is normal and can be scheduled and run; Failure state: (a) status is PEND: the network task is suspended while waiting for a never-coming semaphore or message queue, which means the network task has "stuck"; (b) status is SUSPEND: the network task is suspended; (c) status is DELETED or UNKNOWN: the network task has died or does not exist, and the protocol stack has completely stopped working.

[0057] S 53 : Check the relevant semaphore (1) The diagnosis agent can obtain the identifier (semId) of the key global semaphore used by the protocol stack, and call the semInfoGet(semId, &semInfo) function of the kernel to obtain the information structure semInfo of the key global semaphore.

[0058] (2) The pendedTasks parameter of the semInfo structure: used to check whether there are tasks waiting (PEND) for this key global semaphore. If there are, and the waiting time is abnormally long, it may indicate a deadlock; semInfo structure's count parameter: the semaphore's count value. For mutex semaphores, its normal usable value should be 1. If it is 0 and never recovers, it means it is being exclusively held by some task and can not be released.

[0059] (3) Fault status: This step can detect that the semaphore <semid>Possibly deadlocked, and how many tasks are currently pending on this semaphore.

[0060] Based on the accurate conclusions of the above network memory pool, protocol stack task state and semaphore checks in step S5, the system can attempt to automate recovery, for example: (1) Automatically expand the size of netPool; (2) Automatically force restart tNetTask in abnormal state; (3) Automatically release the semaphore that is deadlocked.

[0061] S6: The results of steps S2 to S5 generate a protocol stack health vector This step converts the results from different dimensions of checks into a standardized, machine-readable, and matchable composite data structure, turning complex fault phenomena into a "code" that can be pattern matched. By associating multi-dimensional information together, the system can identify the root cause of complex faults.

[0062] S 61 : Define the structure of the protocol stack health vector The protocol stack health vector is a structure or a fixed-length array, where each "slot" stores the conclusion of a specific check. Its typical structure is as follows: Health Vector = [Link Layer Status, Load Path Status, Socket Option Status, Memory Pool Status, Network Task Status, Semaphore Status] (1) Link Layer Status Value Domain: PASS (pass) / FAIL (fail); (2) Load Path Status Value Domain: PASS (pass) / FAIL (fail) / TIMEOUT (timeout); (3) Socket Option Status Value Domain: BROADCAST_OFF (broadcast option off), BROADCAST_ON (broadcast option on), NOT_BOUND (unbound), PORT_IN_USE (port in use), OK (normal); (4) Memory Pool Status Value Domain: OK (normal), LOW (low), CRITICAL (critical), FULL (full); (5) Network Task Status Value Domain: READY (ready), PEND (pending), SUSPEND (suspend), DELETED (deleted); (6) Semaphore Status Value Domain: OK (normal), PENDED (pending), DEADLOCK (suspected deadlock).

[0063] S 62 Generation and fusion of protocol stack health vector (1) Data collection: the diagnostic agent sequentially executes the four checking steps S2, S3, S4 and S5, and temporarily stores the original output of each step; (2) Data standardization (quantization): the diagnostic agent internally has a "translation" logic that uniformly maps the original output of steps S2, S3, S4 and S5 to the standardized value range defined in the protocol stack health vector, obtaining the standardized result.

[0064] For example: "the number of current free blocks" greater than 50 is mapped to OK (normal); "the number of current free blocks" greater than 10 and less than or equal to 50 is mapped to LOW (insufficient); "the number of current free blocks" less than or equal to 10 is mapped to CRITICAL (severe shortage).

[0065] (3) Vector assembly: the diagnostic agent creates an empty data structure (vector), and then fills the standardized result into the corresponding slot in the order of the predefined sequence, thereby generating a complete and uniformly formatted protocol stack health vector.

[0066] S7: match the protocol stack health vector with the pre-set fault rule library to locate the fault root cause The fault rule library is defined as follows: The fault rule library is a structured data set that is pre-designed and stored in the VxWorks operating system kernel; each rule in it clearly defines: (1) Condition (IF part): describes a specific fault phenomenon, whose expression language completely corresponds to the slot of the protocol stack health vector; (2) Conclusion (THEN part): indicates the fault root cause and the recommended recovery action corresponding to the fault phenomenon; the recovery action includes: automatically releasing invalid sockets and recreating, dynamically adjusting the size of the network memory pool, and automatically restarting the network task in an abnormal state.

[0067] Rule example: Rule 1: IF [link state == PASS] and [payload channel state == FAIL] and [Socket option == BROADCAST_OFF] THEN fault root cause = "application Socket broadcast option is not turned on"; action = "automatically call setsockopt() to turn on the option".

[0068] Matching the protocol stack health vector with the pre-set fault rule library specifically includes: (1) Get the protocol stack health vector which has been formatted and standardized by step S6, for example: [PASS, FAIL, BROADCAST OFF, OK, READY, OK]; (2) Fault rule base traversal and pattern matching. Scan each rule in the fault rule base one by one. For each rule, compare the condition specified in the "IF part" of the rule with the value in the corresponding slot of the protocol stack health vector; (3) Execute the conclusion of the matched rule. Once a rule that completely matches is found, the fault root cause is located, the scanning is stopped immediately, and the recovery action defined in the "THEN part" of the rule is executed; (4) Handle the case of no match. If all rules are traversed and no completely matched rule is found, enter the default processing flow: Generate an alarm: "Cannot accurately match the fault pattern, please manually analyze in combination with the following protocol stack health vector: [PASS, FAIL, BROADCAST OFF, OK, READY, OK]"; Report this unknown vector to the tester for subsequent rule base optimization and learning.

[0069] S8: According to the fault root cause matched in step S7, execute the predefined recovery action or generate accurate alarm information containing the fault root cause The core idea of this step is: according to the certainty level and risk level of the diagnosis conclusion, adopt a hierarchical response strategy: (1) For faults with strong certainty, low risk, and standard repair solutions: the system automatically executes the predefined recovery action to achieve "self-healing"; (2) For faults with high uncertainty, high risk, or no standard solutions: the system generates an alarm information containing the accurate root cause and hands it over to manual processing, but this information is sufficient for engineers to take immediate action without further troubleshooting.

[0070] Executing predefined recovery actions (automated repair) includes: When the matched rule specifies a clear recovery action, the diagnosis agent program directly calls the VxWorks operating system underlying function to perform the repair by virtue of its kernel-level permissions.

[0071] (1) Repair for "Socket broadcast option not enabled" Matching rule: IF [link PASS, payload FAIL, Socket option BROADCAST OFF] THEN action: automatically enable the broadcast option.

[0072] The execution process is as follows: (a) Parameter preparation: the diagnostic agent has acquired the kernel handle of the faulty socket in the previous step. It prepares the repair parameters: option parameter SO_BROADCAST, option value 1 (representing on); (b) Call to kernel function: the diagnostic agent directly calls the system function setsockopt() provided by the VxWorks operating system kernel; (c) Verification of the result: the system function setsockopt() returns a value (success or failure), which the diagnostic agent checks to confirm whether the operation was successful; (d) Feedback loop: after a successful operation, the diagnostic agent automatically triggers a new "protocol stack payload channel probe". If the probe is successful, it verifies that the repair is effective, and the VxWorks operating system can log: "Fault automatically repaired". If it still fails, it escalates to an alarm, prompting "Automatic repair failed, please intervene manually".

[0073] (2) Repair of "network memory pool depletion" Matching rule: IF [link PASS, payload FAIL, memory pool CRITICAL] THEN action: try to expand the memory pool.

[0074] The execution process is as follows: (a) The diagnostic agent calls the memory pool management function (such as netPoolExpand()), requesting the VxWorks operating system to add a certain number of memory blocks (for example, 50 blocks) to the memory pool; (b) After a successful operation, the "number of current free blocks" field is checked again to confirm that the memory pool has been expanded; (c) Since memory depletion can cause existing operations to fail, the diagnostic agent may suggest or automatically attempt to restart the affected network task or application to restore business.

[0075] (3) Repair of "network task suspension" Matching rule: IF [link PASS, payload FAIL, task status PEND] THEN action: try to restart the network task.

[0076] The execution process is as follows: (a) Risk assessment: restarting the core task is a high-risk operation. The diagnostic agent will first attempt a gentle recovery, such as calling semGive() to release the semaphore it may be waiting for, trying to wake it up; (b) Force restart: If the soft recovery fails, the diagnostic agent will call taskDelete() to forcibly delete the hung tNetTask, and then immediately call taskSpawn() to restart a new tNetTask; Note: The initialization data of the protocol stack is usually saved in memory, so a restart task can usually restore the function of the protocol stack without restarting the entire system, greatly reducing downtime.

[0077] For cases that cannot be automatically repaired or the rule matching result is "unknown fault", an alarm message is generated: The diagnostic agent generates an alarm message containing the following key elements: (1)

Fault root cause

[0078] (2)

Fault object positioning

[0079] (3)

Key evidence

[0080] (4)

Suggested action

[0081] Output of the alarm: This structured alarm information can be reported through various ways: (1) Write to the system log; (2) Send to the network management system through a dedicated communication interface (such as a UDP port); (3) Print on the system console.

[0082] The above is only the preferred embodiment of the present application, it should be noted that for those skilled in the art, without departing from the technical principles of the present application, a number of improvements and modifications can be made, these improvements and modifications should also be considered as the protection scope of the present application.< / semid>

Claims

1. A UDP communication fault diagnosis and recovery method based on multi-dimensional awareness of protocol stack health, characterized in that, Comprising the following steps: S1: deploying a diagnostic agent in the VxWorks operating system, which is designed to have the ability to access and detect the internal state of the network protocol stack of the embedded operating system kernel; S2: in response to a UDP application communication failure event, the diagnostic agent performs a link layer reachability verification to confirm the network interface driver and physical link state; S3: in response to a UDP application communication failure event, the diagnostic agent performs a protocol stack payload channel probe, sends a diagnostic UDP packet to the target port and listens to the response to verify the protocol stack upper layer data path; S4: in response to a UDP application communication failure event, the diagnostic agent performs a Socket interface state audit, checks the configuration parameters, state and binding relationship of the Socket handle associated with the failed application; S5: in response to a UDP application communication failure event, the diagnostic agent performs a system resource health check, including checking the network memory pool, protocol stack task state and related semaphores; S6: generating a protocol stack health vector based on the results of steps S2 to S5; S7: matching the protocol stack health vector with the pre-set fault rule library to locate the fault root cause; S8: performing a predefined recovery action or generating an alarm information containing the fault root cause according to the fault root cause matched in step S7.

2. The method of claim 1, wherein, The deployment method of the diagnostic agent is as follows: (1) Source code level integration: when compiling and building the final VxWorks operating system image, the source code of the diagnostic agent and other kernel components of the VxWorks operating system will be compiled and linked together to become part of the image file; (2) Start when the VxWorks operating system initializes: the VxWorks operating system is powered on and starts, and after the network protocol stack initialization is completed, the main task of the diagnostic agent is started by calling the kernel task creation function in the usrRoot() function, named tDiagTask; (3) Static configuration and rule library embedding: the fault rule library required by the diagnostic agent is directly coded in the source code of the diagnostic agent in the form of a constant data structure, or loaded into the fixed region of the kernel memory as a configuration file when the VxWorks operating system starts; The function module of the diagnostic agent is designed to include: Self-checking and listening module, for internal self-checking and external listening; regularly check whether the diagnostic program itself is running healthily; responsible for listening and receiving diagnostic commands sent from the outside, verifying its legality, triggering the internal diagnostic process, and reporting the results to the external user after the diagnosis is completed; Multi-dimensional perception diagnosis module, for automatically executing a complete set of checking process in order, including: (a) link connectivity check: perform Ping operation; (b) protocol stack payload channel test: autonomously construct and send probe UDP packet; (c) Socket state audit: traverse and check all key configurations of the Socket used by the application program; (d) VxWorks operating system resource check: check the remaining space of the network memory pool and the state of the core network task; The fault rule base and decision engine module is used for storing pre-defined "if-then" rules, receiving the check results from the multi-dimensional perception diagnosis module, matching the check results with the fault rule base, obtaining a fault diagnosis conclusion and determining a recovery strategy, and sending a recovery operation instruction to the automatic execution and recovery module; The automatic execution and recovery module is used for directly calling a kernel function to perform a repair operation according to the instruction of the fault rule base and decision engine module; The result reporting module is used for sending the final fault diagnosis conclusion, the recovery action taken and the recovery execution result to an external requester through a log or directly through a communication interface, and completing a complete diagnosis report; The access and detection capabilities of the diagnosis agent program for the internal state of the network protocol stack of the operating system kernel include: The diagnosis agent program has a kernel-level permission and identity The main task of the diagnosis agent program is assigned with the highest execution permission level when created, which means that the VxWorks operating system does not impose any restrictions on its access to memory and hardware, and any memory address and data structure can be accessed; (2) The diagnosis agent program can directly access memory, including the following operations: Check Socket: The VxWorks kernel maintains a linked list of all sockets, and the diagnosis agent program can directly traverse the linked list to read the field values in each socket; Check memory pool: The diagnosis agent program can obtain the symbol name and memory address of the network memory pool, and directly read the "free block number" field in the memory pool to determine whether it is exhausted; Check task state: The diagnosis agent program calls the taskInfoGet() function provided by the kernel, inputs the ID of the target task, and the kernel returns a structure containing all state information of the target task, which is parsed by the diagnosis agent program to obtain the task state; (3) The diagnosis agent program can directly call kernel functions Send probe packet: The diagnosis agent program directly calls the lower-layer sending function in the protocol stack to inject the constructed data packet into the protocol stack; Perform recovery: When repairing the socket option, the diagnosis agent program directly calls the setsockopt() function of the kernel; when restarting the task, the diagnosis agent program directly calls the taskRestart() function.

3. The method of claim 2, wherein, The link layer reachability verification specifically includes that the diagnosis agent calls a ping command or directly sends an ICMP echo request message to the opposite end device to confirm whether the physical network card, driver and IP protocol stack bottom layer are normal; step S2 includes: S 21 : Select and configure test interface In order to lock the target hardware to be tested, the diagnosis agent program first determines which physical network interface to use for testing; the diagnosis agent program obtains the interface information by directly accessing the network device linked list of the VxWorks operating system; The diagnosis agent program can directly access the network device linked list of the VxWorks operating system to obtain the interface information; S 22 : constructing a test frame for a data link layer The diagnostic agent does not need to construct a complete IP packet, but directly creates a test frame in memory that can test the "send and receive raw bit stream" capability, while ensuring that the test frame is not mistaken by the VxWorks operating system's own protocol stack as a packet that needs to be handed over for processing; the test frame adopts an Ethernet protocol format, and contains: (1) Destination MAC address: set to the MAC address of the opposite device, or set to the broadcast address; (2) Source MAC address: set to the MAC address of the local interface; (3) Ethernet type field: set to an experimental protocol number, or set to the ARP protocol number (0x0806); (4) Data payload: fill in a pre-defined data pattern for easy detection by the receiving end; S 23 : directly invoke the underlying packet send function to send the test frame The diagnostic agent, by virtue of its kernel privileges, bypasses the entire TCP / IP protocol stack and directly finds the underlying packet sending function provided by the network interface device driver, and calls the underlying packet sending function to send the test frame constructed in step S 22 22 The diagnostic agent, by virtue of its kernel privileges, bypasses the entire TCP / IP protocol stack and directly finds the underlying packet sending function provided by the network interface device driver, and calls the underlying packet sending function to send the test frame constructed in step S 22 The diagnostic agent, by virtue of its kernel privileges, bypasses the entire TCP / IP protocol stack and directly finds the underlying packet sending function provided by the network interface device driver, and calls the underlying packet sending function to send the test frame constructed in step S 22 The diagnostic agent, by virtue of its kernel privileges S 24 : Coordinated reception of diagnostic agents deployed on end devices On the opposite device, a diagnostic agent is also running, and the diagnostic agent of the opposite device instructs its network card driver to enter a "promiscuous mode" to listen to a specific Ethernet type, in which the network card driver receives all frames flowing through its port, not just the frames whose destination MAC address is its own; S 25 : verifying receipt and response (1) Receive test frame The network card driver of the diagnostic agent of the opposite device directly hands over the test frame of the specific Ethernet type to the diagnostic agent that is waiting; The diagnostic agent of the opposite device checks the content of the test frame, and confirms that the source MAC address and the payload data are consistent with the expectations; If the test frame is received and the content is correct, it proves that the physical link and the basic transceiving function of the network card drivers of both parties are completely normal; (2) Request ARP response The diagnostic agent of the local device constructs a standard ARP request broadcast frame to inquire about the MAC address of a fictitious, non-existent IP address; this ARP request broadcast frame will be received by all devices on the link; although no device has this fictitious IP, the network interface and driver of the opposite device will perform hardware-level verification on the broadcast frame when it is received, and confirm that it is a correctly formatted frame; The diagnostic agent of the opposite device captures the broadcast frame in "promiscuous mode", and if the diagnostic agent of the opposite device can capture the ARP request broadcast frame sent by the local device, it also proves that the physical link and the function of the driver are perfect; S 26 : result determination After sending the test frame, the diagnostic agent of the local device waits for a short timeout, and receives the "successful reception" confirmation signal sent back by the diagnostic agent of the opposite device through an internal communication channel; If the confirmation is received: the diagnostic agent of the local device records "link layer reachability verification: passed"; If the confirmation is not received within the timeout: it means that the fault may be in one of the links in the path of the driver of the local device, the physical network cable, the switch port, and the driver of the opposite device.

4. The method of claim 3, wherein, The protocol stack payload channel detection specifically includes: the diagnostic agent of the local device constructs a standard UDP protocol packet in the kernel state, and sends it to the corresponding port of the target device, i.e., the opposite device, through the local protocol stack, while opening a temporary listening port on the local device to receive the response packet of the diagnostic agent of the opposite device, so as to judge whether the protocol stack application layer data transceiving function is normal; step S3 includes: S 31 : create temporary listening socket Before sending the probe packet, the local diagnostic agent first calls the socket() function of the kernel to create a socket with the protocol family AF_INET and the type SOCK_DGRAM, and then it calls the bind() function to bind the socket to a specific, free high port; S 32 : Construct diagnostic UDP packet as probe packet in kernel mode The local diagnostic agent directly performs the following operations: (1) Apply raw data: call the kernel memory management function to directly apply a block of memory buffer of appropriate size from the network memory pool, which will be used to load the raw data to be constructed; (2) Manually fill in the protocol headers of each layer: the local diagnostic agent fills in the protocol headers of each layer at the head of the memory buffer: IP header: set the source IP, destination IP, protocol number, TTL value; UDP header: set the source port, destination port, packet length, checksum; Fill in the payload data: fill in a specific, easily identifiable data content, i.e., the string "VXWORKS_DIAG_PROBE", after the UDP header, to generate a correctly formatted UDP packet; S 33 : submit the probe packet to the protocol stack for transmission The native diagnostic agent likewise directly invokes a more low-level protocol stack send function provided by the VxWorks operating system kernel for use by internal modules, which passes as a parameter the address of the assembled memory buffer of step S 32 to this protocol stack send function; S 34 : In temporary port sync listening In order to open a listening channel for receiving the response of this test, the local diagnostic agent calls the recvfrom() function on the created temporary socket at the same time as sending the probe packet, and sets a timeout time to wait for the response from the peer device; S 35 : coordinated response to peer device The diagnostic agent of the peer device works in "promiscuous mode" or listens to the target port through service registration; when the diagnostic agent of the peer device receives the probe packet with the destination port "the port of the application to be tested" and the data content "the special password VXWORKS_DIAG_PROBE", it immediately captures the probe packet; Response: the diagnostic agent of the peer device actively constructs a response packet, with the source port being the target port, the destination port being the source port in the probe packet, and the payload data being a response password "VXWORKS_DIAG_ACK", and then the diagnostic agent of the peer device sends the response packet back to the local device through the kernel sending function; S 36 : Results analysis and conclusion (1) Success scenario: the local diagnostic agent receives the UDP packet sent back by the peer device within the timeout time, containing the expected response password; Conclusion: the protocol stack payload channel is completely normal, which proves: (a) the local protocol stack can correctly send UDP packets; (b) the protocol stack of the peer device can correctly receive UDP packets and deliver them to the target port; (c) the protocol stack of the peer device can correctly send back the response packet; (d) the local protocol stack can correctly receive the response packet and deliver it to the correct socket; (2) Failure scenario: no response is received within the timeout time Conclusion: the protocol stack payload channel has a fault, and the fault point is located in the upper layer of the protocol stack of the local or peer device.

5. The method of claim 4, wherein, The Socket interface state auditing specifically includes: the native diagnostic agent program traverses the system Socket list, checks the following parameters of the target Socket: Socket type, protocol family, local IP address and port number binding state, broadcast permission setting, option setting, and compares with the expected configuration of the application; After the "protocol stack load channel detection" confirms that the protocol stack itself is functioning properly, the root cause of the fault is highly concentrated on the configuration and state of the specific Socket used by the application program; the goal of step S4 is: to deeply operate the system kernel, find the Socket created by the faulty application program, and comprehensively check all key configuration parameters and state information, compare with the correct configuration, and thus find the error configuration.

6. The method of claim 4, wherein, Step S4 includes: S 41 : Find the socket for the application The diagnostic agent program first accesses this global Socket link table, finds the Socket belonging to that faulty application program from the Socket link table, and is implemented by one of the following two ways: (1) Through task ID association: each Socket has a field in its internal structure to record the ID of the task that created it; the diagnostic agent program obtains the task ID of the faulty application program through a system function, and then traverses the Socket link table, compares the "creator task ID" field of each Socket, and the matching Socket is the target; (2) Through known port number: if the port number that the application program should use is known, the diagnostic agent program traverses the link table and checks whether the local port number bound by each Socket matches the port number that the known application program should use; S 42 : Deep scan, checking key configuration parameters one by one After finding the target Socket, the diagnostic agent program starts to directly read the fields in the kernel data structure of the Socket, including: Socket type and protocol family, binding state and address information, Socket options, and sending and receiving buffer state; S 43 : comparison with "health criteria" built into the diagnostic agent S 44 : generating a diagnostic conclusion According to the results of the comparison of step S 43 the diagnostic agent provides fault localization information.

7. The method of claim 6, wherein, The system resource health degree checking specifically includes: checking the remaining block number of the network memory pool, checking whether the network task state is suspended, deleted or ready, and checking whether the related semaphore is abnormal; step S5 detects the state of the key global resources in the VxWorks operating system kernel that provide support for network communication, including: S 51 : check network memory pool (1) Locating resources: the diagnostic agent program directly accesses the memory pool data structure through the symbol name or memory address of the memory pool, and reads the key fields therein, including "current free block number"; (2) Analysis and judgment: the diagnostic agent program compares the free block number numBlocksFree with the preset safety threshold to obtain the conclusion of the health or fault state of the memory pool; Healthy state: numBlocksFree > threshold, indicating that the memory is sufficient; Fault state: numBlocksFree <= threshold, or even 0; Conclusion: the network memory pool has run out; S 52 : check protocol stack task status (1) The diagnostic agent resolves its task ID from the task name, and then calls the taskInfoGet(ID, &taskInfo) function of the kernel, which fills a taskInfo structure containing the status information of the task; (2) Analyzing the key status field: the diagnostic agent checks the status field in the taskInfoGet(ID, &taskInfo) function: Healthy status: the status is READY, indicating that the task is normal and can be scheduled and run; Fault status: (a) The status is PEND: the network task is suspended while waiting for a never-coming semaphore or message queue, which means that the network task has "stuck"; (b) The status is SUSPEND: the network task is suspended; (c) The status is DELETED or UNKNOWN: the network task has died or does not exist, and the protocol stack has completely stopped working; S 53 : check relevant semaphore (1) The diagnostic agent can obtain the identifier semId of the key global semaphore used by the protocol stack, and call the semInfoGet(semId, &semInfo) function of the kernel to obtain the information structure semInfo of the key global semaphore; (2) The pendedTasks parameter of the semInfo structure: used to check whether there are tasks waiting for this key global semaphore, if there are, and the waiting time is timeout, indicating deadlock; The count parameter of the semInfo structure: the count value of the semaphore; for mutual exclusion semaphore, its normal available value is 1; if it is 0 and has never recovered, it means that it is being exclusively occupied by a task and cannot be released.

8. The method of claim 7, wherein, Step S6 includes: S 61 : structure defining a protocol stack health vector The protocol stack health vector is a structure or a fixed-length array, and each "slot" in it stores the conclusion of one check, and its structure is as follows: Health vector = [link layer state, load channel state, Socket option state, memory pool state, network task state, semaphore state] (1) Link layer state value domain: PASS / FAIL; (2) Load channel state value domain: PASS / FAIL / TIMEOUT; (3) Socket option state value domain: BROADCAST_OFF, BROADCAST_ON, NOT_BOUND, PORT_IN_USE, OK; (4) Memory pool state value domain: OK, LOW, CRITICAL, FULL; (5) Network task state value domain: READY, PEND, SUSPEND, DELETED; (6) Semaphore state value domain: OK, PENDED, DEADLOCK; S 62 : Generation and fusion of protocol stack health vectors (1) Data standardization: the diagnostic agent has built-in "translation" logic to map the original output of steps S2, S3, S4 and S5 to the standardized value domain defined by the above protocol stack health vector, and get the standardized result; (3) Vector assembly: the diagnostic agent creates an empty data structure, and then fills it with the normalized results in a predefined order, thus generating a complete and uniform protocol stack health vector.

9. The method of claim 8, wherein, The fault rule base is a structured data set that is pre-designed and stored in the VxWorks operating system kernel; each rule in it defines the following: (1) Condition: describes a specific fault phenomenon, whose expression language corresponds completely to the slot of the protocol stack health vector; (2) Conclusion: indicates the fault root cause corresponding to the fault phenomenon and the recommended recovery action; the recovery action includes: automatically releasing invalid sockets and recreating, dynamically adjusting the network memory pool size, and automatically restarting the network task in an abnormal state; Matching the protocol stack health vector with the pre-set fault rule base specifically includes: (1) Obtain the protocol stack health vector that has been formatted and normalized in step S6; (2) Fault rule base traversal and pattern matching: scan each rule in the fault rule base one by one; for each rule, it compares the condition specified by the rule with the value in the corresponding slot of the protocol stack health vector one by one; (3) Execute the conclusion of the matched rule: once a completely matched rule is found, the fault root cause is located, the scanning is stopped immediately, and the recovery action defined in the conclusion of the rule is executed; (4) Handle the unmatched case: if all rules are traversed and no completely matched rule is found, enter the default processing flow: Generate an alarm: "Unable to match fault patterns, please manually analyze in combination with the following protocol stack health vector: [PASS, FAIL, BROADCAST_OFF, OK, READY, OK]”.

10. The method of claim 9, wherein, Step S8 executes the pre-defined recovery action, which includes: When the matched rule indicates the recovery action, the diagnostic agent directly calls the VxWorks operating system underlying function to perform the repair based on its kernel-level permissions: (1) Repair for "Socket broadcast option not turned on" Matched rule: IF [link PASS, payload FAIL, Socket option BROADCAST_OFF] THEN action: automatically turn on the broadcast option; The execution process is as follows: (a) Parameter preparation: the diagnostic agent prepares the repair parameters: the option parameter is SO_BROADCAST, and the option value is 1; (b) Call kernel function: the diagnostic agent directly calls the system function setsockopt() provided by the VxWorks operating system kernel; (c) Verify the result: the function setsockopt() returns a value, which is checked by the diagnostic agent to confirm whether the operation is successful; (d) Feedback loop: after the operation is successful, the diagnostic agent automatically triggers the "protocol stack payload channel detection" again; if the detection is successful, it verifies that the repair is effective, and the VxWorks operating system can record the log: "Fault has been automatically repaired”; if it still fails, it is upgraded to an alarm, prompting "Automatic repair failed, please manually intervene”; (2) Fix for "Network Memory Pool Exhausted" Match rule: IF [link PASS, payload FAIL, memory pool CRITICAL] THEN action: Attempt to expand the memory pool. The process is as follows: (a) The diagnostic agent invokes the memory pool management function to request a certain number of memory blocks from the VxWorks operating system for the memory pool; (b) After the operation is successful, the "number of current free blocks" field is checked again to confirm that the memory pool has been expanded; (c) The diagnostic agent attempts to restart the affected network task or application to restore service; (3) Fix for "Network Task Hung" Match rule: IF [link PASS, payload FAIL, task status PEND] THEN action: Attempt to restart the network task. The process is as follows: (a) Risk assessment: The diagnostic agent first attempts a gentle recovery, including invoking semGive() to release the semaphore it is waiting for, attempting to wake it up; (b) Forced restart: If the gentle recovery fails, the diagnostic agent will invoke taskDelete() to forcibly delete the hung tNetTask, and then immediately invoke taskSpawn() to restart a new tNetTask.