Communication module state switching method and system based on event triggering

Abstract

The invention provides a communication module state switching method and system based on event triggering, and relates to the technical field of communication.The method comprises the steps that firstly, multi-source event source information in operation of a communication module is collected, and event influence hierarchy division is conducted; a target association network is generated by combining a current operation state and a historical state switching database of the communication module; generating a dynamic path including a hardware parameter adjustment sequence and the like based on the target association network and the historical stability record; pre-judging the stability of the dynamic path; generating a state switching execution instruction according to the pre-judgment result and generating switching process data; and finally, updating the historical state switching database and the target association network based on the switching process data to form closed-loop optimization, thereby realizing dynamic optimization of communication module state switching, and improving adaptability and stability of switching.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and more specifically, to a method and system for switching the state of a communication module based on event triggering. Background Technology

[0002] With the continuous evolution of communication technology, communication modules, as core components for realizing communication functions, are widely used in various smart terminal devices. During actual operation, communication modules need to flexibly switch states according to different business scenarios and device conditions to ensure efficient and stable communication.

[0003] However, existing communication module state switching methods have many shortcomings. On the one hand, traditional methods often trigger state switching based on information from a single event source, such as switching solely based on software instructions or hardware signals, ignoring the complex relationships and hierarchical impacts between multiple event sources. This may lead to an inability to accurately determine the timing and necessity of state switching in the face of complex and ever-changing communication environments, resulting in unnecessary switching operations, increased system overhead and power consumption, and even impact on communication quality.

[0004] On the other hand, existing state switching paths are usually pre-defined fixed patterns, lacking the ability to dynamically adjust based on real-time events and historical data. In situations where communication scenarios are constantly changing, fixed switching paths may fail to adapt to new requirements, leading to decreased system stability after switching and problems such as communication interruptions and data loss. Furthermore, the lack of an effective mechanism for predicting and evaluating the stability of state switching makes the switching operation somewhat arbitrary, making it difficult to guarantee the reliability and security of the switching process. Summary of the Invention

[0005] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide an event-triggered communication module state switching method, the method comprising: Collect multi-source event source information during the operation of the communication module, perform event impact hierarchy classification on the multi-source event source information, and obtain event layering results. The multi-source event source information includes hardware operation anomaly signals, software instruction interaction information, and external device association request information. Obtain the current operating status and historical state switching database of the communication module, and generate a target association network by combining the event layering results with the current operating status of the communication module. The historical state switching database stores historical event types, corresponding switching paths, and stability records after switching. Based on the stability records in the target association network and the historical state switching database, a dynamic path for the state switching of the communication module is generated. The dynamic path includes a hardware parameter adjustment sequence, a software process scheduling order, and an external interaction adaptation strategy. The dynamic path is subjected to state switching stability prediction processing, and the prediction result is generated by combining the current hardware load threshold of the communication module and the software dependency relationship. Based on the prediction result, the dynamic path is converted into a state switching execution instruction, which is input into the communication module to perform the switching operation and generate switching process data; Based on the switching process data and the stable cycle prediction in the prediction results, the historical state switching database and the target association network are updated to form a state switching closed-loop optimization identifier.

[0006] Furthermore, embodiments of the present invention also provide an event-triggered communication module state switching system, characterized in that it includes: A processor; a machine-readable storage medium for storing machine-executable instructions of the processor; wherein the processor is configured to execute the above-described event-triggered communication module state switching method by executing the machine-executable instructions.

[0007] In another aspect, embodiments of the present invention also provide a computer program product, the computer program product including machine-executable instructions, the machine-executable instructions being stored in a computer-readable storage medium, a processor of a computer device reading the machine-executable instructions from the computer-readable storage medium, the processor executing the machine-executable instructions, causing the computer device to execute the above-described event-triggered communication module state switching method.

[0008] Based on the above, by collecting multi-source event information during the operation of the communication module and classifying the event impact hierarchy, and combining the current operating status of the communication module with the historical state switching database to generate a target association network, the intrinsic relationship between events and states can be deeply explored, making state switching decisions more aligned with actual operating conditions. Dynamic paths are generated based on the stability records in the target association network and the historical state switching database, realizing dynamic optimization of state switching paths. This allows for automatic adjustment of switching strategies based on real-time events and historical experience, improving the adaptability and flexibility of state switching. State switching stability prediction processing is performed on the dynamic paths, fully considering the current hardware load threshold and software dependencies of the communication module, effectively reducing the risk of instability during switching and enhancing the reliability of switching operations. State switching execution instructions and switching process data are generated based on the prediction results. Finally, the historical state switching database and the target association network are updated based on the switching process data, forming a closed-loop optimization mechanism for state switching. This mechanism can continuously accumulate experience, improve itself, and continuously enhance the performance and stability of communication module state switching. Attached Figure Description

[0009] Figure 1This is a schematic diagram of the execution flow of the event-triggered communication module state switching method provided in an embodiment of the present invention.

[0010] Figure 2 This is a schematic diagram of exemplary hardware and software components of the event-triggered communication module state switching system provided in an embodiment of the present invention. Detailed Implementation

[0011] The present invention will now be described in detail with reference to the accompanying drawings. Figure 1 This is a flowchart illustrating an event-triggered communication module state switching method according to an embodiment of the present invention. The following is a detailed description of the event-triggered communication module state switching method.

[0012] Step S110: Collect multi-source event source information during the operation of the communication module, perform event impact hierarchy division processing on the multi-source event source information, and obtain event layering results. The multi-source event source information includes hardware operation anomaly signals, software instruction interaction information, and external device association request information.

[0013] In this embodiment, taking the integration of the communication module into the user-side smart gateway as an example, the user-side smart gateway connects to the user's smartphone, smart TV, smart lights, and security cameras through wired Ethernet, Wi-Fi, Bluetooth, and other interfaces. When collecting multi-source event information, three types of information are obtained through a hardware monitoring chip, a software log parsing module, and an external interaction protocol parser, respectively. Then, the event stratification is completed through an influence coefficient calculation model and hierarchical determination rules.

[0014] Step S111: Collect hardware operation anomaly signals from the hardware monitoring port of the communication module. The hardware operation anomaly signals include power module voltage fluctuations, transmission module signal attenuation, and interface module connection frequency changes.

[0015] The hardware monitoring ports of the communication module include the ADC sampling port of the power module, the signal strength detection port of the transmission module, and the status monitoring pins of the interface module. The ADC sampling port of the power module uses a 12-bit successive approximation ADC, which collects the voltage at the power output terminal through a voltage divider resistor network. The sampling frequency is matched with the output ripple period of the power module. When three consecutive sample values ​​deviate from the reference range, a voltage fluctuation signal is generated. This voltage fluctuation signal contains the sampling timestamp, the current voltage value, and the direction of deviation.

[0016] The signal strength detection port of the transmission module is integrated into the radio frequency front-end chip. It monitors signal attenuation by detecting the RSSI value of the received signal. When the RSSI value drops continuously and the drop exceeds the chip's preset sensitivity threshold, it records the attenuation start time, attenuation rate and current RSSI value to form signal attenuation data.

[0017] The status monitoring pins of the interface module are connected to the connection detection circuits of each physical interface. By detecting changes in the pin level, the number of connection establishments and disconnections per unit time is counted. For Ethernet interfaces, the monitoring pins detect link pulse signals; for Wi-Fi interfaces, the monitoring pins detect the trigger signals of association requests and deassociation frames. Finally, the data is integrated to form connection frequency change data, which is stored according to interface type.

[0018] Step S112: Extract software instruction interaction information from the software log of the communication module. The software instruction interaction information includes instruction sending interval, instruction execution delay, and instruction retry count.

[0019] The communication module's software logs employ a circular storage mechanism, stored in the on-chip Flash log partition. The log recording format follows the syslog protocol, with each log entry containing a timestamp, process ID, instruction type, instruction parameters, and execution status fields. When extracting software instruction interaction information, the log parsing module first filters the instruction interaction logs within the most recent monitoring period by timestamp, and then groups and processes them by instruction type.

[0020] For instruction sending intervals, for instructions of the same type issued by the same process, the sending timestamp of each instruction is extracted, and the time difference between two adjacent instructions is calculated to form a sequence of sending intervals for that type of instruction. For instruction execution delays, the instruction sending timestamp and the execution completion status feedback timestamp are extracted, and the difference between the two is calculated. If there is an interruption during instruction execution, the interruption duration must be included in the execution delay.

[0021] For command retrieval counts, retrieve command records marked "retry" from the log, group them by command ID to count the number of retries, and record the retry reason field, such as "timeout without response" or "verification error", to ensure that the number of retries is associated with the specific cause of the failure.

[0022] Step S113: Collect external device association request information from the external interaction port of the communication module. The external device association request information includes the type of the request initiating device, the amount of request data, and the timeliness requirement for request response.

[0023] The communication module's external interaction ports include an Ethernet RJ45 port, a Wi-Fi 6 wireless port, and a Bluetooth 5.0 port, each equipped with a protocol parsing unit. When an external device initiates an association request, the protocol parsing unit first parses the frame header field of the request frame. For Ethernet frames, the device type is identified by the source MAC address prefix; for Wi-Fi frames, the device type is identified by the device manufacturer information field in the ProbeRequest frame; and for Bluetooth frames, the device type is identified by the device category field in the broadcast packet.

[0024] The requested data volume is obtained by parsing the payload length field of the request frame. For TCP requests, the actual amount of data to be transmitted needs to be determined by combining the window size field in the packet header; for UDP requests, the datagram length field is extracted directly. The required response time is determined by parsing the service type field in the request frame. For example, a real-time preview request for a smart camera corresponds to an immediate response, a status query request for smart lights corresponds to a regular response, and a firmware update request for a smart TV corresponds to a delayed response.

[0025] Step S114: Analyze the impact range of the hardware operation anomaly signal, determine the number of hardware components affected by the signal and the importance of the components, and generate a hardware impact coefficient.

[0026] First, the components affected by each abnormal signal are identified using a hardware correlation diagram. This diagram predefines the connection relationships between the power supply module, transmission module, interface module, and components such as the core processor and memory. If the power supply module voltage fluctuates, the diagram shows the affected power supply unit of the core processor, the power management chip of the memory, and the power supply circuits of each interface module, and counts the number of these components.

[0027] Component importance is categorized into three levels based on functional criticality: core processors and RF transmission chips are at level one; memory and power management chips are at level two; and interface physical layer chips are at level three. Each level corresponds to a preset weighting coefficient. The number of affected components is standardized based on the total number of components, and then weighted and summed with the weighting coefficients of each level. The sum is then normalized and mapped to the 0-1 range to obtain a hardware impact coefficient. The larger the hardware impact coefficient, the more significant the impact of the hardware anomaly.

[0028] Step S115: Perform execution impact analysis on the software instruction interaction information to determine the interruption range of the software process chain and the difficulty of process recovery caused by instruction anomalies, and generate software impact coefficients.

[0029] First, an abnormal instruction is identified through the instruction anomaly detection module. When the instruction execution delay exceeds the preset threshold corresponding to the instruction type, or the number of retries reaches the maximum retry limit set by the process, it is determined to be an instruction anomaly. For abnormal instructions, the process chain to which they belong is traced through the process dependency graph. The process dependency graph stores the call relationships between processes in the form of a directed graph, where nodes are processes, edges are call relationships, and the attributes of the edges are labeled with the call frequency and the amount of data interaction.

[0030] The interruption scope is determined based on the process chain structure. If the process to which the abnormal instruction belongs is an upstream process in the chain, the interruption scope covers that process and all downstream called processes; if it is a downstream process, the interruption scope only includes that process and the upstream processes that directly called it. The difficulty of process recovery is assessed based on the process's startup dependencies, initialization time, and data recovery mechanism. Processes with fewer dependencies, shorter initialization times, and data backup mechanisms have lower recovery difficulty, and the recovery difficulty corresponds to a preset weight value.

[0031] The number of processes corresponding to the interruption range is standardized, and then normalized after being weighted and summed with the recovery difficulty weight value to generate a software impact coefficient with a value range of 0 to 1.

[0032] Step S116: Perform an association impact analysis on the external device association request information to determine the breadth of the impact of the request interruption on the external device interaction link and the link reconstruction cost, and generate an external impact coefficient.

[0033] The breadth of impact is determined based on the user-side device interaction topology map. This user-side device interaction topology map is dynamically constructed by the device discovery module of the communication module, recording the connection relationships between each external device and the communication module, as well as the indirect interaction relationships between devices. When the association request of an external device is interrupted, the topology map displays other devices directly connected to that device and downstream devices that depend on the data of that device. The number of interaction links corresponding to these devices is counted, which is the breadth of impact.

[0034] Link reconstruction costs are assessed from two aspects: time cost and resource cost. Time cost includes link renegotiation time and protocol handshake time; resource cost includes CPU resources, memory resources, and bandwidth resources consumed during the reconstruction process. Based on the cost assessment results and corresponding preset cost weights, the impact breadth is standardized and weighted and summed with the cost weights, and then normalized to obtain the external impact coefficient, with a value ranging from 0 to 1.

[0035] Step S117: The hardware influence coefficient, software influence coefficient and external influence coefficient are correlated and integrated. Referring to the influence level division standard preset by the communication module, an event layering result is generated. The event layering result includes the core influence level, the associated influence level and the indirect influence level. Different influence levels correspond to different state switching response priorities.

[0036] The impact coefficient association module binds the hardware impact coefficient, software impact coefficient, and external impact coefficient according to the event occurrence timestamp, ensuring that the three correspond to the same event source. Preset impact level classification standards are stored in the configuration file. The core impact level requires that the hardware impact coefficient, software impact coefficient, and external impact coefficient are all greater than the first threshold, and at least one coefficient is greater than the product of the first threshold and the correction coefficient. The associated impact level requires that two coefficients are greater than the second threshold, and the third coefficient is greater than the third threshold. The indirect impact level requires that at least one coefficient is greater than the fourth threshold, and the first two levels are not met, where the order is: first threshold > second threshold > third threshold > fourth threshold, and the correction coefficient is an empirical value less than 1.

[0037] After comparing the integrated coefficients with the standard to determine the event level, the highest response priority is assigned to the core impact level, the medium priority is assigned to the related impact level, and the lowest priority is assigned to the indirect impact level, ultimately forming an event stratification result that includes event ID, impact level, response priority, and three impact coefficients.

[0038] Step S120: Obtain the current operating status and historical state switching database of the communication module. Combine the event layering results with the current operating status of the communication module to generate a target association network. The historical state switching database stores historical event types, corresponding switching paths, and stability records after switching.

[0039] The status acquisition module acquires the operating status parameters of the communication module in real time, retrieves historical status switching data from the local database or cloud storage, and then uses the network construction module to associate and map the hierarchical information in the event layering results with the current status elements and historical data to construct a target association network containing nodes and edges, intuitively presenting the influence and mapping relationship between various elements.

[0040] Step S121: Obtain the current operating status of the communication module, which includes the operating parameters of hardware components, the active status of software processes, and the status of external interaction links.

[0041] In this embodiment, the operating parameters of the hardware components are collected by a distributed monitoring unit. The operating parameters of the core processor include the current operating frequency, core temperature, and cache hit rate. The frequency is obtained by reading the processor's PLL configuration register, the temperature is collected by the processor's built-in temperature sensor, and the cache hit rate is statistically analyzed by the processor's performance monitoring unit.

[0042] The operating parameters of the memory include SRAM utilization, Flash erase / write cycles, and data read / write rate. SRAM utilization is obtained by calculating the ratio of allocated memory to total memory. Flash erase / write cycles are stored in the Flash status register, and read / write rate is calculated by counting the amount of data read and written per unit time.

[0043] The operating parameters of each interface module include the link rate and frame error rate of the Ethernet interface, the channel occupancy rate and retransmission rate of the Wi-Fi interface, and the number of connections and frequency hopping interval of the Bluetooth interface. These parameters are read through the status register of the interface controller.

[0044] The active status of software processes is obtained through the process management unit, which periodically traverses the process control block linked list to extract the process name, process ID, current status (running, ready, blocked, terminated), CPU time used, memory usage, and number of open file descriptors for each process.

[0045] For processes in a blocked state, the reason for the blocking needs to be recorded, such as waiting for I / O completion, waiting for a semaphore, or waiting for a timer to time out. Simultaneously, the inter-process communication monitoring module records the interactions between processes via pipes, message queues, and shared memory to determine inter-process dependencies.

[0046] The status of external interaction links is collected through the link monitoring module, which listens to the protocol data units of each external interaction port and extracts the link connection status, the communication protocol version used, the bit error rate of data transmission, the round-trip delay and throughput.

[0047] For established links, the connection status is monitored by sending link probe frames; for links in the connection establishment process, the progress of handshake frame interactions is monitored. The bit error rate is calculated by the ratio of the number of erroneous bits in the received data to the total number of bits. The round-trip time is obtained by recording the time difference between sending and receiving probe frames. The throughput is determined by the total size of successfully transmitted data packets per unit time.

[0048] Step S122: Retrieve the historical state switching database, which includes historical event records, historical switching path records, and historical stability records after switching. The historical event records correspond to the event types in the event hierarchy results. The historical switching path records include historical hardware parameter adjustment sequences, historical software process scheduling sequences, and historical external interaction adaptation strategies.

[0049] The historical state switching database uses SQLite and is deployed on an external SD card of the communication module. The database contains three core tables: an event log table, a switching path table, and a stability log table. When accessing the database, a connection is established through the database driver, and query statements are executed to retrieve data.

[0050] The event log table stores the event ID, event type code, occurrence time, hardware impact coefficient, software impact coefficient, external impact coefficient, and impact level of historical events. The event type code corresponds to the event type in the event stratification results through a preset code mapping table.

[0051] The switching path table is associated with the event record table through the event ID. Each record contains the hardware parameter adjustment sequence (parameter name, adjustment order, value before adjustment, value after adjustment), software process scheduling order (process ID, operation type, operation order, resource allocation ratio), and external interaction adaptation strategy (link ID, protocol adjustment content, cache configuration parameters).

[0052] The stability log table is also linked by event ID and includes the switchover completion time, stable runtime after the switchover, number of anomalies during the period, anomaly type, and anomaly recovery method.

[0053] Step S123: Associate the core impact level of the event in the event layering result with the operating parameters of the hardware components in the current operating state of the communication module, and identify the hardware sensitive parameters corresponding to the core impact level. The hardware sensitive parameters are the parameters that have the most significant impact on the event response during the operation of the hardware components.

[0054] First, extract the event ID, event type, and hardware impact coefficient of the core impact level from the event stratification results. Then, filter the hardware component operating parameters related to the event type in the current operating status of the communication module according to the event type. For example, power-related events are associated with power module parameters, and transmission-related events are associated with transmission module parameters.

[0055] The correlation analysis module calculates the Pearson correlation coefficient between each screened parameter and the hardware influence coefficient. Parameters with an absolute value of the correlation coefficient greater than a preset threshold are initially listed as candidate sensitive parameters. The parameter sensitivity testing module then performs perturbation tests on the candidate parameters, i.e., slightly adjusting the parameter values ​​and observing the change in the hardware influence coefficient. The parameter with the largest change is determined as the hardware sensitive parameter. For example, for power supply voltage fluctuation events, the output voltage regulation coefficient of the power supply module is tested and determined to be a hardware sensitive parameter.

[0056] Step S124: Associate the correlation impact level in the event layering result with the software process activity status in the current running state of the communication module, and identify the software dependent processes corresponding to the correlation impact level. The software dependent processes are the processes in the software system that need to be prioritized for scheduling due to the event.

[0057] The event types and software impact coefficients of the associated impact levels are extracted from the event hierarchy results. Combined with the current software process activity status of the communication module, the initial process affected by the event is determined through the process impact analysis module. The initial process is usually a process directly related to the event type, such as the instruction parsing process corresponding to an instruction execution delay event.

[0058] Based on the process dependencies recorded in the active states of software processes, a process dependency tree is constructed with the initial process as the root node, and the child nodes of the tree are the downstream processes that depend on the initial process. The dependency strength evaluation module calculates the dependency strength between each child node and the root node, and the dependency strength is determined based on the frequency of interaction between processes, the amount of data interaction, and the necessity of interaction.

[0059] Processes with a dependency strength greater than a preset threshold are listed as software dependency processes. At the same time, the priority of dependency processes is determined according to the dependency strength. The higher the priority, the more priority they need to be processed in subsequent scheduling.

[0060] Step S125: Associate the indirect impact level in the event layering result with the external interaction link status in the current operating state of the communication module, and identify the external link node corresponding to the indirect impact level. The external link node is the node in the external interaction that needs to adjust the adaptation strategy due to the event.

[0061] Extract event features and external influence coefficients of the indirect impact level from the event stratification results. Match the current external interaction link status of the communication module with the event features to determine the potentially affected external interaction links. For example, match the abnormal wireless interface connection frequency event with the Wi-Fi link.

[0062] Each external interaction link is categorized by node type into source nodes (communication module interfaces), intermediate nodes (such as wireless routers, if present), and destination nodes (external devices). The importance of each node in the link is assessed using a node importance evaluation module, with importance determined based on the node's impact on link connectivity, data forwarding volume, and difficulty of fault recovery.

[0063] Nodes whose importance exceeds a preset threshold are identified as external link nodes, and their type, IP address or MAC address and current operating status are recorded.

[0064] Step S126: Map and associate the hardware sensitive parameters, software dependent processes, external link nodes with the historical event records and historical switching path records in the historical state switching database to present the correspondence between event hierarchy, current state elements and historical switching data in the form of a graph, and generate a target association network. The target association network includes nodes and association edges. Nodes represent event hierarchy, state elements and historical switching paths, and association edges represent the influence relationship and mapping relationship between each node.

[0065] The target association network adopts a directed graph structure and is constructed using graph theory modeling tools. First, the node types and attributes are defined: event-level nodes include node ID, level type, and event ID attributes; state feature nodes include node ID, feature type, and feature identifier attributes, where feature type is divided into hardware sensitive parameters, software dependent processes, and external link nodes; historical data nodes include node ID, data type, and associated event ID attributes, where data type is divided into historical events and historical switching paths.

[0066] Establish connections between nodes: event-level nodes point to the corresponding state element nodes, and the edge attribute is the degree of influence (determined by the influence coefficient); state element nodes point to historical data nodes, and the edge attribute is the mapping similarity (calculated by the matching degree between the current element and historical data); historical event nodes point to the corresponding historical switching path nodes, and the edge attribute is the corresponding weight.

[0067] The weights of associated edges are determined by the influence after standardization, mapping similarity, and corresponding weights; larger weight values ​​indicate a closer relationship between nodes. The constructed directed graph is stored as a GraphML format file, which can be loaded and viewed using network visualization tools to examine the relationships between nodes and edges, supporting node queries and path analysis.

[0068] Step S130: Based on the stability records in the target associated network and the historical state switching database, generate a dynamic path for the state switching of the communication module. The dynamic path includes a hardware parameter adjustment sequence, a software process scheduling order, and an external interaction adaptation strategy.

[0069] By mining the node relationships in the target network through the network analysis module, and combining historical stability records to analyze the differences in the effects of different adjustment schemes, a dynamic path adapted to the current event and running status is generated through standardized scoring, scheme screening and integration optimization.

[0070] Step S131: Extract the hardware sensitive parameters corresponding to the core impact level of the event from the target association network, and combine them with the historical hardware parameter adjustment sequences under the same hardware sensitive parameters in the historical state switching database to analyze the difference in the first impact of different adjustment sequences on hardware stability. The difference in the first impact is reflected by the hardware stability duration in the stability record after the historical switch.

[0071] By using the node query interface of the target association network, the corresponding hardware sensitive parameter nodes are extracted based on the node ID of the core impact level of the event, and the parameter name and current value are obtained. Using the parameter name as the query condition, all historical hardware parameter adjustment sequences corresponding to the same parameter are retrieved from the switching path table of the historical state switching database. Each sequence includes the parameter adjustment steps, adjustment magnitude, and adjustment order.

[0072] For each historical adjustment sequence, the stability record table in the historical state switching database is linked by the event ID to extract the corresponding hardware stability duration. All historical adjustment sequences are sorted from longest to shortest hardware stability duration, and the difference in stability duration between adjacent sequences is calculated to quantify the difference in the primary impact of different adjustment sequences on hardware stability. Simultaneously, the changes in hardware component operating parameters corresponding to each sequence are recorded, such as voltage values ​​and signal strength before and after the adjustment.

[0073] Step S132: Extract the software dependent processes corresponding to the association influence level from the target association network, and combine the historical software process scheduling order under the same software dependent process in the historical state switching database to analyze the second influence difference of different scheduling orders on the software response speed. The second influence difference is reflected by the software instruction execution delay in the stability record after the historical switch.

[0074] By traversing the node network of the target association, the set of software dependent process nodes corresponding to the nodes of the association influence level is located, and the process ID and functional description of each software dependent process are obtained. Based on the process ID, the corresponding historical software process scheduling order is queried in the switching path table of the historical state switching database. Each scheduling order includes the process start order, shutdown order and resource allocation ratio.

[0075] For each historical scheduling sequence, software instruction execution latency data is extracted by associating the event ID with a stability record table. This latency data is then grouped and statistically analyzed to calculate the average execution latency for different scheduling sequences under the same software dependency process. The difference in average execution latency is used as a quantitative indicator of the second impact difference. Furthermore, the correlation between process operation logic and software instruction execution latency in the scheduling sequence needs to be analyzed; for example, whether starting core dependency processes first can significantly reduce execution latency.

[0076] Step S133: Extract the external link nodes corresponding to the indirect influence level from the target associated network, and combine them with the historical external interaction adaptation strategies under the same external link nodes in the historical state switching database to analyze the differences in the third influence of different adaptation strategies on link stability. The differences in the third influence are reflected by the frequency of link interruption in the stability record after historical switching.

[0077] By utilizing the node filtering function of the target associated network, corresponding external link nodes are extracted based on the event characteristics of the indirect impact level, obtaining the node's MAC address, connection protocol type, and link identifier. Using the link identifier as an index, historical external interaction adaptation strategies corresponding to the same external link node are retrieved from the switching path table of the historical state switching database. These strategies include protocol adjustment schemes, cache configuration parameters, and link monitoring frequencies.

[0078] For each historical adaptation strategy, link outage frequency data is extracted by associating event IDs with the stability record table. The average outage frequency under different adaptation strategies is statistically analyzed, and the differences between frequencies are calculated to determine the third impact difference. Simultaneously, changes in parameters such as link throughput and bit error rate are recorded after the adaptation strategy is adjusted, and the correspondence between the adaptation strategy and link stability indicators is analyzed.

[0079] Step S134: Standardize the first impact difference, the second impact difference, and the third impact difference to convert them into a unified relative impact score. Based on the relative impact score, select the appropriate hardware parameter adjustment direction, software process scheduling priority, and external interaction adaptation method for the current event stratification result.

[0080] First, determine the original value ranges of the first, second, and third impact differences. For the first impact difference (hardware stability duration difference), use the difference between the maximum and minimum values ​​as the denominator and the difference between a certain difference value and the minimum value as the numerator to calculate the standardized value of the difference. For the second impact difference (software instruction execution delay difference) and the third impact difference (link interruption frequency difference), a matching method is used, but the difference needs to be inverted before standardization to ensure that the larger the standardized value, the better the impact.

[0081] The standardized values ​​of the three dimensions are multiplied by preset weighting coefficients. These weighting coefficients are set according to the priority of each influence level in the event stratification results, with the first influence difference corresponding to the core influence level having the highest weight, followed by the second influence difference corresponding to the related influence level, and the third influence difference corresponding to the indirect influence level having the lowest weight. After weighted summation, the relative influence score of each historical adjustment plan is obtained. The hardware parameter adjustment direction, software process scheduling priority, and external interaction adaptation method corresponding to the plan with the highest score are selected as the adaptation plan for the current event.

[0082] Step S135: Convert the hardware parameter adjustment direction into a specific hardware parameter adjustment sequence, including the order of parameter adjustment and the adjustment magnitude gradient.

[0083] Based on the selected direction of hardware parameter adjustment, compile a list of hardware-sensitive parameters that need adjustment, prioritizing those with the greatest impact on hardware stability. For example, if the hardware-sensitive parameters are the output voltage regulation coefficient of the power supply module and the signal gain of the transmission module, the output voltage regulation coefficient has a greater impact on the overall hardware power supply stability and should be adjusted first.

[0084] For each parameter, set an adjustment gradient. The initial adjustment gradient should reference the optimal value from historical adjustment sequences. If the hardware stabilization time after adjustment does not meet expectations, gradually increase or decrease the gradient according to the preset level. Simultaneously, clearly define the adjustment interval for each parameter to ensure that the next parameter is adjusted only after the previous parameter has been adjusted and stabilized for a period of time, avoiding parameter adjustment conflicts. The final hardware parameter adjustment sequence must include the parameter name, adjustment order, initial adjustment gradient, gradient change rule, and adjustment interval.

[0085] Step S136: Convert the software process scheduling priority into a specific software process scheduling order, including the order of process shutdown and startup logic and the process resource allocation ratio.

[0086] Based on software process scheduling priority, the order of process operations is determined. When a process is shut down, non-dependent processes with low relevance to the current event are shut down first, followed by secondary software-dependent processes, and finally primary software-dependent processes, to avoid system anomalies caused by premature shutdown of core processes. When a process is started, the reverse order is followed: primary software-dependent processes are started first, and after their initialization is complete, secondary software-dependent processes and non-dependent processes are started.

[0087] Resource allocation is based on process priority. Processes heavily dependent on major software are allocated the highest proportion of CPU resources and memory, processes dependent on minor software are allocated a moderate proportion, and processes not dependent on major software are allocated basic guaranteed resources. Simultaneously, a dynamic resource adjustment mechanism is implemented for processes. When the instruction execution delay of a process exceeds a threshold, its resource allocation proportion is temporarily increased, and then reverted to the original proportion once the delay returns to normal. This forms a software process scheduling order that includes process operation logic, a baseline resource allocation proportion, and dynamic adjustment rules.

[0088] Step S137: Transform the external interaction adaptation method into a specific external interaction adaptation strategy, including an interaction protocol adjustment method and a data transmission caching mechanism.

[0089] For the selected external interaction adaptation method, determine the adjustment method for the interaction protocol. If the current protocol causes frequent link interruptions, switch to a more compatible protocol version, or adjust parameters such as the transmission window size and retransmission timeout in the protocol. For example, when the Wi-Fi link is frequently interrupted due to retransmission timeouts, increase the retransmission timeout parameter and reduce the retransmission trigger frequency.

[0090] The design incorporates a data transmission caching mechanism, setting the cache size and cache lifespan based on the amount of data requested and the timeliness requirements of external devices. For immediate response requests, a smaller cache and shorter lifespan are used to ensure real-time data transmission; for delayed response requests, a larger cache and longer lifespan are used to prevent data loss. Simultaneously, a priority scheduling mechanism for cached data is established, prioritizing the transmission of cached data with high timeliness requirements. This forms an external interaction adaptation strategy that includes protocol adjustment parameters, cache configuration information, and data scheduling rules.

[0091] Step S138: Integrate the hardware parameter adjustment sequence, software process scheduling order, and external interaction adaptation strategy to generate a dynamic path for communication module state switching. Each link in the dynamic path is set with an association identifier to reflect the collaborative relationship between hardware, software, and external interaction adjustments.

[0092] The hardware parameter adjustment sequence, software process scheduling order, and external interaction adaptation strategy are integrated according to time axis and logical dependencies. When the hardware parameters are adjusted to a preset range, the software process scheduling operation corresponding to the associated identifier is triggered. For example, after the power module voltage is adjusted to a stable value, the instruction parsing process is started. When the software process completes initialization and enters a stable running state, the external interaction adaptation strategy corresponding to the associated identifier is executed. For example, after the software dependent process is started, the protocol adjustment operation of the external link is initiated.

[0093] Each step in the dynamic path is assigned a timestamp, associated step ID, and status identifier. The timestamp records the planned execution time of the step, the associated step ID identifies other steps that trigger or are triggered by this step, and the status identifier records the execution status of the step (pending execution, in execution, completed, or exception). The integrated content is stored as an XML-formatted path file, containing three sub-nodes: hardware adjustment, software scheduling, and external adaptation. Each sub-node lists the specific steps and associated information in execution order, forming a complete dynamic path.

[0094] Step S140: Perform state switching stability prediction processing on the dynamic path, and generate a prediction result by combining the current hardware load threshold of the communication module and the software dependency relationship.

[0095] The dynamic path simulation execution module simulates the operation of each link in the dynamic path. Combining the current hardware load capacity and software dependency structure, it analyzes the potential risks such as overload and dependency breakage, quantifies the risk level and predicts the stabilization period, and finally forms a prediction result that includes path adaptability and stabilization period prediction.

[0096] Step S141: Extract key adjustment nodes from the hardware parameter adjustment sequence in the dynamic path. The key adjustment nodes are nodes whose hardware parameter adjustment range is greater than a set range or which affect multiple hardware components.

[0097] The system iterates through the hardware parameter adjustment sequence in the dynamic path, filtering out nodes whose adjustment magnitude exceeds a preset threshold. These nodes have significantly higher adjustment magnitudes than other regular adjustment nodes. Simultaneously, it identifies nodes whose adjustments will affect the operating parameters of two or more hardware components. For example, adjusting the main power supply voltage of the power module will simultaneously affect the power supply status of the core processor and the transmission module. These two types of nodes are marked as critical adjustment nodes, and the corresponding parameter names, adjustment magnitudes, affected hardware components, and planned adjustment times are recorded.

[0098] Step S142: Obtain the current hardware load threshold of the communication module, wherein the current hardware load threshold of the communication module includes the maximum carrying voltage, maximum transmission rate and maximum heat dissipation capacity of each hardware component.

[0099] The load threshold parameters of each hardware component are collected by the hardware load monitoring module. The maximum load voltage of the core processor is read from its specification. The maximum transmission rate is determined by testing its data processing capability. The maximum heat dissipation capacity is calculated based on the heatsink specifications, fan speed and ambient temperature.

[0100] The maximum voltage that a power module can handle is determined by the design parameters of its voltage regulator circuit, and the maximum output current is determined by the limiting parameters of the power management chip. The maximum transmission rate of a transmission module is referenced to the performance specifications of its RF chip, and the maximum signal transmit power is limited by regulatory certification parameters. The maximum transmission rate of an interface module is determined according to the interface type (e.g., Ethernet, Wi-Fi) standard, and the maximum number of connections is calculated using the resource limits of the interface controller. These parameters are categorized and organized by hardware component to form a list of current hardware load thresholds.

[0101] Step S143: Simulate the hardware parameter adjustment process corresponding to the key adjustment node, calculate the actual load value of each hardware component after adjustment, compare the actual load value with the current hardware load threshold of the communication module, and analyze the risk of hardware load exceeding the limit.

[0102] Step S1431: Establish a load calculation model for each hardware parameter adjustment item corresponding to the key adjustment node. The load calculation model is constructed based on the parameter-load correlation of the hardware components and is used to reflect the correspondence between the parameter adjustment amount and the load change amount.

[0103] For each hardware parameter adjustment item, corresponding data on the parameter adjustment amount and the load change of each hardware component during historical adjustments are collected. A parameter-load correlation equation is established through regression analysis to form a load calculation model. For example, for the power supply voltage adjustment item, the model input is the voltage adjustment amount, and the output is the current load change of components such as the core processor and transmission module; for the signal gain adjustment item, the model input is the gain adjustment amount, and the output is the power load change of the transmission module.

[0104] The model must include the coupling relationships between hardware components. For example, a change in the load of one component may indirectly affect the load of other related components. By introducing a coupling coefficient, the load calculation results can be corrected to ensure the accuracy of the model.

[0105] Step S1432: Input the adjustment range and adjustment duration in the hardware parameter adjustment item into the load calculation model, and output the real-time load change curve of each hardware component during the adjustment process.

[0106] Input the adjustment range, start time, and duration of the hardware parameter adjustment items in the key adjustment nodes into the load calculation model. The model calculates the load value of each hardware component according to the preset time step (e.g., every millisecond), and connects the load values ​​at different time points to form a real-time load change curve. The curve should indicate the load rise stage, the stable stage (if there is a stable period during the adjustment process), and the final stable load value, so as to intuitively present the dynamic changes of the load during the adjustment process.

[0107] Step S1433: Extract the peak load value from the real-time load change curve as the actual load value of each hardware component after adjustment.

[0108] Iterate through all data points on the real-time load change curve to determine the maximum load value, or peak load value, for each hardware component during the adjustment process. If the load first rises and then falls and stabilizes during the adjustment process, the peak load value is the maximum value during the rising phase; if the load continues to rise and stabilizes at a certain value after adjustment, the peak load value is the load value after stabilization. Record the peak load value of each hardware component as the actual load value after adjustment.

[0109] Step S1434: Classify the actual load values ​​according to the hardware component type and compare them item by item with the current hardware load threshold of the corresponding communication module.

[0110] The actual load values ​​are categorized by type, such as core processor, power module, transmission module, and interface module, and compared one by one with the corresponding parameters in the current hardware load threshold. For example, the actual current load value of the core processor is compared with the maximum current carrying capacity threshold, and the actual power load value of the transmission module is compared with the maximum output power threshold. The result of each comparison is recorded (not exceeding the limit, slightly exceeding the limit, severely exceeding the limit).

[0111] Step S1435: Count the number of hardware components whose actual load value exceeds the current hardware load threshold of the communication module and the extent of the over-limit. The extent of the over-limit is the difference between the actual load value and the current hardware load threshold of the communication module.

[0112] The results of each comparison are statistically analyzed to calculate the number of hardware components whose actual load values ​​exceed the threshold, distinguishing between components with slight over-limit (over-limit range less than 10% of the threshold) and those with severe over-limit (over-limit range greater than or equal to 10% of the threshold). Simultaneously, the difference between the actual load value and the threshold for each over-limit component is calculated, i.e., the over-limit range. The over-limit range data is then organized by component type to generate a hardware load over-limit statistical report.

[0113] Step S1436: Based on the number and extent of the overloaded components, and referring to the correlation between overload and fault occurrence in the historical data of communication module hardware faults, determine the hardware overload risk level.

[0114] Historical hardware failure data of the communication module was retrieved to analyze the probability of failure under different numbers of components exceeding limits and different degrees of exceeding limits. For example, when one component slightly exceeds the limit, the probability of failure is low; when two or more components severely exceed the limit, the probability of failure increases significantly.

[0115] Based on the current number and extent of components exceeding limits, similar scenarios are matched with historical fault data to determine the corresponding fault probability range. Risk levels are then categorized according to the fault probability range (e.g., low risk, medium risk, high risk). Low risk corresponds to a fault probability below a preset low threshold, medium risk corresponds to a fault probability between the low and high thresholds, and high risk corresponds to a fault probability above the high threshold.

[0116] Step S1437: Integrate the hardware load over-limit risk level, the number of over-limit components, and the over-limit magnitude into a hardware load prediction sub-result.

[0117] The hardware load overload risk level, the specific type and quantity of overloaded components, the overload extent of each component, and the corresponding load threshold are integrated to form a hardware load prediction sub-result. This sub-result must clearly identify high-risk overloaded components and their potential impact on hardware stability.

[0118] Step S144: Extract the core scheduling link from the software process scheduling order from the dynamic path. The core scheduling link is the link that involves the start or stop of the software dependent processes.

[0119] Traverse the software process scheduling order in the dynamic path, and filter out the stages involving the startup or shutdown of major and minor software dependent processes. These stages directly affect the implementation of the core functions of the software system. For example, the startup stage of the instruction parsing process and the shutdown stage of the resource allocation process are both core scheduling stages. Record the operation type (startup / shutdown), the process IDs involved, the planned execution time, and the associated hardware adjustment nodes (if any) of the core scheduling stages.

[0120] Step S145: Analyze the current software dependencies of the communication module, which include inter-process data interaction dependencies, resource sharing dependencies, and execution order dependencies.

[0121] Process dependency analysis tools are used to traverse all currently running software processes and extract the dependencies between them. Data interaction dependencies refer to the transfer of data between processes via pipes, message queues, etc., such as an instruction parsing process sending parsed data to a data processing process; resource sharing dependencies refer to multiple processes sharing resources such as memory regions and file handles, such as multiple processes accessing configuration files simultaneously; execution order dependencies refer to a process that can only start after another process has finished executing, such as a data storage process that can only start after the data processing process has started.

[0122] The above dependencies are represented in the form of a dependency graph, with nodes representing processes, edges representing dependencies, and edge attributes indicating dependency types, thus forming the current software dependency graph.

[0123] Step S146: Simulate the software process scheduling process corresponding to the core scheduling link, analyze the integrity of the software dependency relationship after scheduling, and determine whether there is a process dependency break or resource competition conflict.

[0124] Step S1461: Present the current software dependencies of the communication module in the form of a dependency graph. The nodes in the dependency graph represent software processes, the edges represent dependencies between processes, and the attributes of the edges are labeled with dependency type and dependency strength.

[0125] Based on the current software dependency graph, a dependency graph is constructed. Each node contains a process ID, process name, and current state attribute. Each edge contains a dependency type (data interaction, resource sharing, execution order) and dependency strength attribute. Dependency strength is determined based on the frequency of interaction between processes, the amount of data, and the necessity of the dependency. The more frequent the interaction, the larger the amount of data, and the more necessary the dependency, the higher the strength.

[0126] Step S1462: Locate the software dependent process nodes involved in the core scheduling link in the dependency graph, and mark the software dependent process nodes that need to be closed and the software dependent process nodes that need to be started.

[0127] Based on the process ID in the core scheduling process, locate the corresponding software dependency process node in the dependency graph, and use different colors or markers to distinguish between nodes that need to be shut down and nodes that need to be started. For example, use red to mark nodes that need to be shut down and green to mark nodes that need to be started, and indicate the planned operation time and operation type next to the node.

[0128] Step S1463: Simulate the shutdown of the software dependent process node to be shut down, delete all dependency edges corresponding to the software dependent process node, and analyze whether there are isolated nodes in the remaining dependency graph. The isolated node is a software dependent process node that has lost all input dependency edges or output dependency edges. The existence of an isolated node indicates that there may be a process dependency break.

[0129] Perform a simulated shutdown operation on the dependency graph, deleting the node to be shut down and all its input and output dependency edges. Traverse the remaining nodes, checking each node for either an input dependency edge (an edge from other nodes to this node) or an output dependency edge (an edge from this node to other nodes). If a node has neither input nor output dependency edges, it is considered an isolated node. Record the process ID, process name, and original dependencies of the isolated node to determine the location of the dependency break.

[0130] Step S1464: Simulate the startup of the software dependent process node to be started, add all the dependency edges corresponding to the software dependent process node, and analyze whether there is a situation in the new dependency graph where the same resource node is pointed to by multiple software dependent process nodes at the same time. The resource node is a memory area, file handle or port resource shared between processes. Multiple software dependent process nodes pointing to the same resource node indicates that there may be a resource competition conflict.

[0131] Perform a simulated startup operation in the dependency graph, adding the node to be started and all its corresponding input and output dependency edges to form a new dependency graph. Identify resource nodes (such as shared memory nodes and file handle nodes) in the new dependency graph, and check if two or more software dependent process nodes simultaneously point to the same resource node, and if the operation types of these process nodes (such as read and write) may cause conflicts (such as simultaneous write operations). If such a situation exists, record the identifier, type (such as shared memory or file handle), the ID of the involved software dependent process node, and the operation type of the resource node, and clarify the specific location and type of resource contention conflict.

[0132] Step S1465: Perform dependency tracing on existing isolated nodes, determine the specific link of dependency breakage, and record the type of broken dependency and the software dependency process nodes involved.

[0133] For the identified isolated nodes, trace back their dependency graph structure before the closure operation, and find the source and target nodes corresponding to the original input and output dependency edges. By comparing the changes in the dependency graph before and after the closure operation, identify the dependency break caused by closing the node to be closed. For example, if the isolated node originally depended on data provided by the node to be closed, this data dependency breaks after the node to be closed is deleted.

[0134] Record the type of dependency break, such as data interaction dependency break, execution order dependency break, etc., and record the IDs and names of the isolated nodes involved and the original dependent nodes that need to be closed, forming a dependency break details record.

[0135] Step S1466: Perform resource occupation analysis on existing resource competition conflicts, determine the types of conflicting resources and competition process nodes, and record the probability of conflict occurrence.

[0136] For resource nodes with resource contention conflicts, analyze the resource usage requirements of each competing software's dependent processes, including usage duration, access frequency, and operation permissions (read / write). Based on process priority, resource usage requirements, and historical resource contention event handling records, assess the probability of the current conflict occurring. For example, the probability of conflict is higher when a high-priority process and a low-priority process simultaneously request to write to the same file handle.

[0137] Record the specific types of conflicting resources, detailed information about the competing process nodes, and the estimated conflict probability.

[0138] Step S1467: Integrate the dependency fracture analysis results, resource competition conflict analysis results, and corresponding record information into a software dependency prediction sub-result.

[0139] By linking and integrating dependency break details with resource competition conflict analysis records, the impact of dependency breaks and resource competition conflicts on the integrity of software dependencies can be clarified. If there are multiple dependency breaks or high-probability resource competition conflicts, the integrity of software dependencies is poor; if there are only a few minor dependency breaks and no resource competition conflicts, the integrity of software dependencies is good.

[0140] The final software dependency prediction sub-result includes the number of dependency breaks, details of the break points, the number of resource contention conflicts, conflict resource information, conflict probability, and software dependency integrity assessment conclusions.

[0141] Step S147: Extract key adaptation items from the external interaction adaptation strategy from the dynamic path. The key adaptation items are items involving external link node protocol adjustments or data transmission mechanism changes.

[0142] Iterate through the external interaction adaptation strategies in the dynamic path, filtering out adaptation items involving changes in external link node communication protocol versions and protocol parameter adjustments (such as transmission window size and retransmission mechanisms), as well as adaptation items involving changes in data transmission mechanisms, such as enabling / disabling caching mechanisms, adjusting data fragmentation strategies, and changing transmission priorities. Mark these adaptation items as key adaptation items and record their corresponding external link node IDs, adaptation content, and planned execution time.

[0143] Step S148: Based on the current external interaction link status of the communication module, simulate the external interaction process corresponding to the key adaptation item, and analyze the compatibility of the interaction protocol and the stability of data transmission.

[0144] First, the current external interaction link status parameters of the communication module, such as protocol version, negotiation parameters, data transmission rate, and bit error rate, are obtained as the initial state for simulating the interaction process. For each key adaptation item, the external interaction scenario is reproduced in the simulation environment. For example, for protocol adjustment adaptation items, the protocol negotiation process between the devices at both ends of the link is simulated; for data transmission mechanism change adaptation items, the data sending, receiving, and buffering processes are simulated.

[0145] When analyzing the compatibility of interactive protocols, check for issues such as handshake failures and parameter mismatches during the protocol negotiation process, and record the protocol compatibility status (fully compatible, partially compatible, incompatible) and the specific parameters of incompatibility. When analyzing data transmission stability, statistically analyze the changes in data loss rate, retransmission count, and transmission latency during the simulation process, compare the differences in transmission stability indicators before and after adaptation, and determine the impact of key adaptation items on transmission stability.

[0146] Step S149: Quantify the hardware load overload risk, software dependency integrity judgment result and external interaction stability analysis result into comparable risk levels, integrate each risk level and refer to the stability record of the dynamic path in the historical state switching database to determine the path adaptability of the current dynamic path.

[0147] Quantitative standards are set for hardware overload risk, software dependency integrity risk, and external interaction stability risk. For example, hardware overload risk is divided into three levels: low, medium, and high, corresponding to different numbers of overloaded components and overload ranges. Software dependency integrity risk is divided into four levels according to the number of dependency breaks and the probability of resource contention conflicts. External interaction stability risk is divided into three levels according to protocol compatibility level and differences in data transmission indicators.

[0148] Based on the analysis results, each risk item is assigned a corresponding risk level quantification value. The three quantification values ​​are then weighted and summed according to preset weights to obtain the comprehensive risk value. Historical path records matching the event type, impact level, and adjustment direction of the current dynamic path are retrieved from the historical state switching database. The correspondence between their comprehensive risk values ​​and actual switching effects is extracted. By comparing the current comprehensive risk value with historical records, the path suitability of the current dynamic path is determined. The suitability range is from 0 to 1, with a higher value indicating a better fit for the current scenario.

[0149] Step S1410: Based on the path adaptability and the stability period after switching of historical matching paths, estimate the stability period after the current dynamic path is executed, and generate a prediction result including the path adaptability and the estimated stability period after switching.

[0150] The system analyzes the post-switch stabilization periods of matching paths with similar adaptability to the current dynamic path in the historical state transition database, and calculates the average of these periods as the baseline stabilization period. Based on the difference between the current path adaptability and the baseline adaptability, the baseline stabilization period is adjusted. For example, if the current adaptability is higher than the baseline adaptability, the estimated stabilization period is appropriately extended; conversely, it is shortened.

[0151] The final prediction results include path adaptability values, estimated duration of the stabilization period after the switch, risk level of each risk item, and specific analysis basis.

[0152] Step S150: Based on the prediction result, the dynamic path is converted into a state switching execution command, which is input into the communication module to perform the switching operation and generate switching process data.

[0153] Based on the path suitability in the prediction results, it is determined whether to execute the dynamic path. If the suitability meets the requirements, it is directly converted into an execution instruction; if it does not meet the requirements, the dynamic path is corrected first and then the instruction is converted. During the execution process, data is collected in real time to form switching process data.

[0154] Step S151: Analyze the path adaptability in the prediction result. If the path adaptability meets the preset adaptability standard, then directly generate a state switching execution instruction based on the dynamic path. If the path adaptability does not meet the preset adaptability standard, then modify the hardware parameter adjustment sequence, software process scheduling order, and external interaction adaptation strategy in the dynamic path according to the hardware load over-limit risk, software dependency breakage risk, and external interaction instability risk in the prediction result.

[0155] The preset adaptation standard is that the path adaptation degree is greater than or equal to a preset threshold. If the current path adaptation degree meets this standard, it directly enters the instruction generation stage. If the standard is not met, to address the risk of hardware overload exceeding limits, the adjustment magnitude or order in the hardware parameter adjustment sequence is adjusted to reduce the load on overloaded components; to address the risk of software dependency breakage, the software process scheduling order is optimized and the process start / stop logic is adjusted to avoid dependency breakage; to address the risk of unstable external interaction, the protocol parameters or transmission mechanism in the external interaction adaptation strategy are modified to improve compatibility and stability.

[0156] During the revision process, the synergy of each adjustment item needs to be reassessed to ensure that the logical connections between each link in the revised dynamic path are maintained, and to avoid new risks arising from the revision of a single risk.

[0157] Step S152: The modified dynamic path is structured according to the communication module instruction format requirements and transformed into a state switching execution instruction containing hardware adjustment sub-instructions, software scheduling sub-instructions and external adaptation sub-instructions. Each sub-instruction contains an execution timing identifier and a collaborative execution identifier.

[0158] The instruction format of the communication module follows the instruction set specification of its main control unit, typically including an instruction header, instruction type, instruction parameters, checksum, and instruction tail fields. During structured processing, the hardware parameter adjustment sequence in the dynamic path is transformed into hardware adjustment sub-instructions, each containing parameters such as parameter identifier, adjustment value, and adjustment duration; the software process scheduling order is transformed into software scheduling sub-instructions, including process ID, operation type, and resource allocation parameters; and the external interaction adaptation strategy is transformed into external adaptation sub-instructions, including link identifier, protocol parameters, and cache configuration.

[0159] Add execution timing identifiers to each sub-instruction to clarify its execution time point in the overall switching process; add coordination execution identifiers to indicate which other sub-instructions the sub-instruction needs to be executed in conjunction with, such as the corresponding software scheduling sub-instruction can only be triggered after the hardware adjustment sub-instruction is completed, to ensure that the switching operation is carried out in an orderly and coordinated manner.

[0160] Step S153: Transmit the state switching execution instruction to the main control unit of the communication module, so that the main control unit of the communication module sequentially issues hardware adjustment sub-instructions to the hardware control module, software scheduling sub-instructions to the software management module, and external adaptation sub-instructions to the external interaction module according to the execution timing identifier and the collaborative execution identifier.

[0161] The state switching execution command is transmitted to the main control unit via the internal bus. The main control unit first parses the execution timing identifier and the cooperative execution identifier in the command to construct an instruction execution timing table. According to the timing table, the main control unit first sends a hardware adjustment sub-command to the hardware control module. After receiving the command, the hardware control module drives the corresponding hardware component to complete the parameter adjustment and returns execution feedback to the main control unit.

[0162] After receiving feedback that the hardware adjustment is complete, the main control unit sends a software scheduling sub-instruction to the software management module. The software management module then performs the startup, shutdown, and resource allocation operations according to the instruction, and also returns execution feedback. Finally, based on the feedback that the software scheduling is complete, the main control unit sends an external adaptation sub-instruction to the external interaction module. The external interaction module performs protocol adjustments and data transmission mechanism configurations, completing the entire switching instruction issuance process.

[0163] Step S154: During the execution of sub-instructions in each module, real-time data on changes in hardware adjustment parameters, changes in software process status, and external interaction links are collected and integrated to generate switching process data. The switching process data includes the execution time of each sub-instruction, parameter comparison before and after execution, and execution exception records.

[0164] When the hardware control module executes sub-instructions, it collects real-time dynamic changes in hardware parameters through ADC sampling, sensor monitoring, and other methods. It records the adjustment start time, parameter values ​​during the adjustment process, and adjustment completion time, calculates the execution duration, and compares the parameter differences before and after execution. When the software management module executes sub-instructions, it collects changes in process status (such as from ready to running), changes in resource utilization, and records the execution duration and results of process operations.

[0165] When the external interaction module executes sub-instructions, it collects link data such as link protocol negotiation status, data transmission rate, and bit error rate, and records the execution time and effect of the adaptation operation. If an exception occurs during the execution of a sub-instruction, such as hardware parameter adjustment failure or process startup timeout, the time of occurrence, exception type, and exception code are recorded in real time. All collected data is categorized and integrated according to sub-instructions to form complete handover process data.

[0166] Step S160: Based on the switching process data and the stable cycle prediction in the prediction result, update the historical state switching database and the target association network to form a state switching closed-loop optimization identifier.

[0167] By comparing the switching process data with the predicted results, the deviation between the switching effect and the prediction is analyzed. The relevant data is entered into the historical database, the node relationship of the target associated network is adjusted, and finally a closed-loop optimization identifier is generated to achieve continuous optimization.

[0168] Step S161: Extract the execution time of each sub-instruction, the comparison of parameters before and after execution, and the execution exception records from the switching process data, and analyze the actual switching effect.

[0169] For example, step S1611: Separate the execution data of the hardware adjustment sub-instruction from the switching process data, extract the execution time of the hardware adjustment sub-instruction, compare the changes in hardware parameters before and after execution with the target changes in the hardware parameter adjustment sequence in the dynamic path, and calculate the hardware parameter adjustment deviation.

[0170] The execution data of hardware adjustment sub-instructions is separated, categorized and organized according to parameter type, and the start and end times of each sub-instruction are extracted to calculate the execution duration. The actual changes in hardware parameters after execution are compared with the target changes set in the dynamic path, and the difference between the two is calculated as the hardware parameter adjustment deviation. The smaller the deviation, the better the hardware adjustment effect meets expectations.

[0171] Step S1612: Collect execution exception records during the hardware adjustment process, determine the hardware component where the exception occurred, the exception type and the duration of the exception, and analyze the impact of the exception on the stable operation of the hardware.

[0172] The system iterates through the execution exception records of hardware adjustment sub-instructions, counts the number of exceptions by hardware component type, and identifies the type of each exception, such as parameter adjustment overshoot and hardware response timeout. It records the start and end times of each exception and calculates its duration. The system analyzes the impact of these exceptions on stable hardware operation; for example, voltage adjustment overshoot may cause momentary overload of hardware components, affecting short-term stability; hardware response timeout may indicate a potential component failure, affecting long-term stability.

[0173] Step S1613: Separate the execution data of the software scheduling sub-instruction from the switching process data, extract the execution time of the software scheduling sub-instruction, compare the number of active software processes and resource utilization before and after execution with the target value of the software process scheduling order in the dynamic path, and calculate the software process scheduling deviation.

[0174] The execution data of software scheduling sub-instructions are separated and categorized by process operation type (start / shutdown), and the execution time of each sub-instruction is extracted. The actual number of active software processes, CPU and memory resource utilization after execution are compared with the target values ​​in the dynamic path. The difference between these two values ​​is calculated as the software process scheduling deviation to evaluate the accuracy of the software scheduling operation.

[0175] Step S1614: Statistically record execution exceptions during the software scheduling process, determine the software process in which the exception occurred, the exception type, and the exception recovery time, and analyze the impact of the exception on the software response speed.

[0176] Analyze anomaly records during software scheduling, identify the process IDs and names involved, and categorize anomaly types, such as process startup failures and insufficient resource allocation. Record the time from anomaly occurrence to recovery and analyze its impact on software response speed. For example, process startup failures can cause delays in the execution of instructions that depend on that process, while insufficient resource allocation can slow down the overall software response.

[0177] Step S1615: Separate the execution data of the external adaptation sub-instruction from the switching process data, extract the execution time of the external adaptation sub-instruction, compare the connection success rate and data transmission rate of the external interaction link before and after execution with the target value of the external interaction adaptation strategy in the dynamic path, and calculate the external interaction adaptation deviation.

[0178] Separate the execution data of external adaptation sub-instructions, categorize them according to adaptation type (protocol adjustment / transmission mechanism change), and extract the execution time. Compare the actual connection success rate and data transmission rate of the external interaction link after execution with the target values ​​in the dynamic path, calculate the difference as the external interaction adaptation deviation, and measure the execution effect of the external adaptation strategy.

[0179] Step S1616: Collect execution exception records during the external adaptation process, determine the external link node where the exception occurred, the exception type and the exception repair time, and analyze the impact of the exception on the stability of external interaction.

[0180] Statistically record anomalies during the external adaptation process to identify the external link node where the anomaly occurred and the anomaly type, such as protocol negotiation failure or data buffer overflow. Record the anomaly repair time and analyze the impact of the anomaly on the stability of external interactions. For example, protocol negotiation failure can lead to link connection interruption, and data buffer overflow can lead to data loss, both of which reduce the stability of external interactions.

[0181] Step S1617: Compare the hardware parameter adjustment deviation, software process scheduling deviation, and external interaction adaptation deviation with the preset deviation thresholds for each stage to obtain the deviation level of each stage; combine the abnormal impact analysis results of each stage to comprehensively judge whether the actual switching effect meets the preset effect standard, and generate the actual switching effect evaluation result, which includes the effect level, the deviation level of each stage, and the anomaly summary.

[0182] Preset deviation thresholds for each stage, and compare hardware parameter adjustment deviations, software process scheduling deviations, and external interaction adaptation deviations with their corresponding thresholds to classify the deviation levels (e.g., no deviation, slight deviation, moderate deviation, severe deviation). Based on the analysis results of abnormal impacts at each stage, if each stage has no or slight deviations and no severe abnormalities, the actual switching effect meets the preset standard; if there are moderate or severe deviations, or severe abnormalities, the standard is not met.

[0183] The effectiveness is graded according to the evaluation results (excellent, good, qualified, unqualified), and the deviation levels, anomaly types and impact analyses of each link are integrated to form the actual switching effect evaluation results.

[0184] Step S162: Compare the actual switching effect with the estimated stable period after switching in the prediction result, and calculate the relative deviation of the prediction. The relative deviation of the prediction is the ratio of the difference between the actual stable period and the estimated stable period to the estimated stable period.

[0185] Continuously monitor the stable operating time of the communication module after state switching to determine the actual stable period. Calculate the difference between the actual stable period and the estimated stable period in the prediction results, and divide this difference by the estimated stable period to obtain the relative deviation of the prediction. If the deviation is positive, it indicates that the actual stable period is longer than the prediction; if it is negative, it indicates that the actual stable period is shorter than the prediction. The larger the absolute value of the deviation, the lower the accuracy of the prediction.

[0186] Step S163: Extract the actual execution effect of the hardware parameter adjustment sequence, the actual execution effect of the software process scheduling order, and the actual execution effect of the external interaction adaptation strategy from the switching process data, and associate the corresponding event layering results with the current running status of the communication module.

[0187] Extract the actual stabilization time and parameter deviation after hardware parameter adjustment from the switching process data as the actual execution effect of the hardware adjustment sequence; extract the actual active state and resource utilization of software processes as the actual execution effect of the software scheduling sequence; extract the connection success rate and transmission rate of external links as the actual execution effect of the external adaptation strategy.

[0188] The actual execution results are associated with the event hierarchy results (event ID, impact level, response priority) that triggered this state switch and the current running status of the communication module before the switch (hardware parameters, software process status, link status) to ensure data traceability.

[0189] Step S164: Enter the event layering results, the current running status of the communication module, the actual dynamic path executed, the actual switching effect and the estimated deviation into the historical state switching database, and update the historical event records, historical switching path records and historical stability records after switching.

[0190] Add the event hierarchy results and associated running status information for this event to the historical event record table; enter the details of the actual dynamic path executed in the historical switch path record table, including the corrected hardware adjustment sequence, software scheduling order and external adaptation strategy; record the actual switch effect evaluation results, actual stabilization period and estimated relative deviation in the historical switch stability record table.

[0191] During the update process, it is necessary to ensure that the tables are correctly associated through event IDs, and to use incremental update method to avoid overwriting the original historical data, so as to ensure the integrity and continuity of the database.

[0192] Step S165: Find the node in the target association network that corresponds to the current event layering result and the current operating state of the communication module, and adjust the association edge weights between nodes based on the actual switching effect.

[0193] By utilizing the node retrieval function of the target association network, the corresponding event-level nodes, status element nodes, and associated historical data nodes are found based on the event ID and running status element identifier of the current event hierarchy result. If the actual switching effect is excellent, it indicates that the association relationship between these nodes is relatively accurate, and the weight of the association edge between nodes is increased; if the actual switching effect is poor, it indicates that the association relationship is biased, and the weight of the association edge is decreased, or the association relationship between nodes is adjusted according to the actual dynamic path executed.

[0194] Step S166: If the actual switching effect is better than the historical records of the same type, then mark the dynamic path as the preferred path in the target association network; if the actual switching effect is abnormal, then mark the corresponding target association node in the target association network.

[0195] Retrieve historical records from the historical state transition database that have the same event type and impact level as the current event, and compare the actual transition effect with the effect level of similar historical records. If the current actual transition effect level is higher than the highest level of similar historical records, add a "preferred path" marker to the corresponding dynamic path node in the target association network and record the key parameters of its excellent effect. If the actual transition effect has serious anomalies, such as hardware adjustment failure or frequent link interruptions, add an "abnormal association" marker to the corresponding event level node and state element node, reminding subsequent path generation to focus on the accuracy of the association relationship of these nodes. At the same time, record the reasons for abnormal associations, such as hardware sensitive parameter identification deviations or unreasonable software dependency process priority settings.

[0196] Step S167: Integrate the update records of the historical state transition database with the adjustment records of the target associated network to generate a state transition closed-loop optimization report. Based on the state transition closed-loop optimization report, form a state transition closed-loop optimization identifier, which includes the optimization time, optimization content, and expected effect after optimization.

[0197] Collect incremental update records from the historical state transition database, including newly added event records, transition path records, and stability records. Simultaneously, summarize records of node adjustments, edge weight modifications, and tag additions in the target associated network. Organize these records chronologically and by optimization type to form a closed-loop optimization report for state transitions.

[0198] The state transition closed-loop optimization report must detail the event types involved in this optimization, the dynamic path adjustments, the specific changes to the target associated network, and the potential impact of these changes on subsequent state transitions. A state transition closed-loop optimization identifier is generated based on the report content, and the optimization time is recorded as the timestamp of the report generation. The optimization content is clearly defined as a brief overview of database update items and network adjustment items. The expected results after optimization, combined with historical data and current adjustment logic, are described as specific effects such as improving the adaptability of dynamic paths under similar events, shortening state transition response time, and reducing the probability of anomalies after transition. This state transition closed-loop optimization identifier will serve as the basis for calling the optimized data and network during the next state transition.

[0199] Based on the same inventive concept, please refer to Figure 2 The diagram shows a schematic block diagram of an event-triggered communication module state switching system 100 for performing the above-described inspection video stream processing method, provided in an embodiment of this application. The event-triggered communication module state switching system 100 may include a communication unit 110, a machine-readable storage medium 120, and a processor 130.

[0200] In this embodiment, both the machine-readable storage medium 120 and the processor 130 are located within the event-triggered communication module state switching system 100 and are separately configured. However, it should be understood that the machine-readable storage medium 120 may also be independent of the event-triggered communication module state switching system 100 and may be accessed by the processor 130 via a bus interface. Alternatively, the machine-readable storage medium 120 may be integrated into the processor 130 and may communicate and interact with external systems through the communication unit 110.

[0201] The processor 130 is the control center of the event-triggered communication module state switching system 100. It connects to various parts of the system via various interfaces and lines. By running or executing software programs and / or modules stored in the machine-readable storage medium 120, and by calling data stored in the machine-readable storage medium 120, it performs various functions and processes data of the event-triggered communication module state switching system 100, thereby providing overall monitoring of the system. Optionally, the processor 130 may include one or more processing cores; for example, the processor 130 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor. The machine-readable storage medium 120 stores machine-executable instructions for executing the scheme of this application, and the processor 130 executes the machine-executable instructions stored in the machine-readable storage medium 120 to implement the inspection video stream processing method provided in the aforementioned method embodiments.

[0202] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. A method for switching the state of a communication module based on event triggering, characterized in that, The method includes: Collect multi-source event source information during the operation of the communication module, perform event impact hierarchy classification on the multi-source event source information, and obtain event layering results. The multi-source event source information includes hardware operation anomaly signals, software instruction interaction information, and external device association request information. Obtain the current operating status and historical state switching database of the communication module, and generate a target association network by combining the event layering results with the current operating status of the communication module. The historical state switching database stores historical event types, corresponding switching paths, and stability records after switching. Based on the stability records in the target association network and the historical state switching database, a dynamic path for the state switching of the communication module is generated. The dynamic path includes a hardware parameter adjustment sequence, a software process scheduling order, and an external interaction adaptation strategy. The dynamic path is subjected to state switching stability prediction processing, and the prediction result is generated by combining the current hardware load threshold of the communication module and the software dependency relationship. Based on the prediction result, the dynamic path is converted into a state switching execution command, which is input into the communication module to perform the switching operation and generate switching process data. Based on the switching process data and the stable cycle prediction in the prediction results, the historical state switching database and the target association network are updated to form a state switching closed-loop optimization identifier.

2. The event-triggered communication module state switching method according to claim 1, characterized in that, The multi-source event information collected during the operation of the communication module is processed by classifying the multi-source event information into event impact levels to obtain event stratification results, including: Hardware operation anomaly signals are collected from the hardware monitoring port of the communication module. These signals include power module voltage fluctuations, transmission module signal attenuation, and interface module connection frequency changes. Extract software instruction interaction information from the software logs of the communication module. The software instruction interaction information includes instruction sending interval, instruction execution delay, and instruction retry count. External device association request information is collected from the external interaction port of the communication module. The external device association request information includes the type of the request initiating device, the amount of request data, and the timeliness requirement for request response. The impact range of the hardware operation anomaly signal is analyzed to determine the number of hardware components affected by the signal and the importance of the components, and a hardware impact coefficient is generated. The execution impact analysis of the software instruction interaction information is performed to determine the scope of interruption of the software process chain and the difficulty of process recovery caused by instruction anomalies, and to generate a software impact coefficient. The external device association request information is analyzed to determine the breadth of the impact of the request interruption on the external device interaction link and the link reconstruction cost, and an external impact coefficient is generated. The hardware influence coefficient, software influence coefficient, and external influence coefficient are correlated and integrated. Referring to the influence level division standard preset by the communication module, an event layering result is generated. The event layering result includes the core influence level, related influence level, and indirect influence level of the event. Different influence levels correspond to different state switching response priorities.

3. The event-triggered communication module state switching method according to claim 1, characterized in that, The step of acquiring the current operating status and historical state switching database of the communication module, and combining the event hierarchical results with the current operating status of the communication module to generate a target association network includes: The current operating status of the communication module is obtained, which includes the operating parameters of hardware components, the active status of software processes, and the status of external interaction links. Retrieve the historical state switching database, which includes historical event records, historical switching path records, and historical stability records after switching. The historical event records correspond to the event types in the event hierarchy results. The historical switching path records include historical hardware parameter adjustment sequences, historical software process scheduling sequences, and historical external interaction adaptation strategies. The core impact level of the event in the event stratification result is associated with the operating parameters of the hardware components in the current operating state of the communication module, and the hardware sensitive parameters corresponding to the core impact level are identified. The hardware sensitive parameters are the parameters that most significantly respond to the event during the operation of the hardware components. The association impact level in the event layering result is associated with the software process activity status in the current running state of the communication module, and the software dependent processes corresponding to the association impact level are identified. The software dependent processes are the processes in the software system that need to be prioritized for scheduling due to the event. The indirect impact level in the event layering result is associated with the external interaction link status in the current operating state of the communication module, and the external link node corresponding to the indirect impact level is identified. The external link node is the node in the external interaction that needs to adjust the adaptation strategy due to the event. The hardware sensitive parameters, software dependent processes, and external link nodes are mapped and associated with the historical event records and historical switching path records in the historical state switching database. The correspondence between event hierarchy, current state elements and historical switching data is presented in the form of a graph, generating a target association network. The target association network includes nodes and association edges. Nodes represent event hierarchy, state elements and historical switching paths, and association edges represent the influence relationship and mapping relationship between each node.

4. The event-triggered communication module state switching method according to claim 1, characterized in that, The step of generating a dynamic path for communication module state switching based on the target association network and the stability records in the historical state switching database includes: Extract hardware sensitive parameters corresponding to the core impact level of the event from the target association network, and combine them with the historical hardware parameter adjustment sequences under the same hardware sensitive parameters in the historical state switching database to analyze the difference in the first impact of different adjustment sequences on hardware stability. The difference in the first impact is reflected by the hardware stability duration in the stability record after the historical switch. Extract the software dependent processes corresponding to the association influence level from the target association network, and combine the historical software process scheduling order under the same software dependent process in the historical state switching database to analyze the second influence difference of different scheduling orders on the software response speed. The second influence difference is reflected by the software instruction execution delay in the stability record after the historical switch. Extract the external link nodes corresponding to the indirect influence level from the target associated network, and combine them with the historical external interaction adaptation strategies under the same external link nodes in the historical state switching database to analyze the differences in the third influence of different adaptation strategies on link stability. The differences in the third influence are reflected by the frequency of link interruption in the stability record after historical switching. The first, second, and third impact differences are standardized and converted into a unified relative impact score. Based on the relative impact score, the appropriate hardware parameter adjustment direction, software process scheduling priority, and external interaction adaptation method are selected for the current event stratification result. The direction of the hardware parameter adjustment is transformed into a specific hardware parameter adjustment sequence, including the order of parameter adjustment and the gradient of adjustment magnitude; The software process scheduling priority is converted into a specific software process scheduling order, including the logic of process shutdown and startup and the process resource allocation ratio. The external interaction adaptation method is transformed into a specific external interaction adaptation strategy, including the interaction protocol adjustment method and the data transmission caching mechanism; By integrating the hardware parameter adjustment sequence, software process scheduling order, and external interaction adaptation strategy, a dynamic path for communication module state switching is generated. Each link in the dynamic path is assigned an association identifier to reflect the collaborative relationship between hardware, software, and external interaction adjustments.

5. The event-triggered communication module state switching method according to claim 1, characterized in that, The process of performing state switching stability prediction on the dynamic path, combined with the current hardware load threshold of the communication module and software dependencies, generates a prediction result, including: Extract key adjustment nodes from the hardware parameter adjustment sequence from the dynamic path. The key adjustment nodes are nodes whose hardware parameter adjustment range is greater than a set range or that affect multiple hardware components. The current hardware load threshold of the communication module is obtained, which includes the maximum carrying voltage, maximum transmission rate and maximum heat dissipation capacity of each hardware component. Simulate the hardware parameter adjustment process corresponding to the key adjustment node, calculate the actual load value of each hardware component after adjustment, compare the actual load value with the current hardware load threshold of the communication module, and analyze the risk of hardware load exceeding the limit. Extract the core scheduling link from the software process scheduling order from the dynamic path. The core scheduling link is the link that involves the start or stop of the software dependent processes. Analyze the current software dependencies of the communication module, which include inter-process data interaction dependencies, resource sharing dependencies, and execution order dependencies; Simulate the software process scheduling process corresponding to the core scheduling link, analyze the integrity of the software dependency relationship after scheduling, and determine whether there is process dependency breakage or resource competition conflict. Extract key adaptation items from the external interaction adaptation strategy from the dynamic path. The key adaptation items are items involving external link node protocol adjustments or data transmission mechanism changes. Based on the current external interaction link status of the communication module, simulate the external interaction process corresponding to the key adaptation item, and analyze the compatibility of the interaction protocol and the stability of data transmission. The hardware load overload risk, software dependency integrity judgment results, and external interaction stability analysis results are quantified into comparable risk levels. The risk levels are integrated and the stability records of the dynamic path are matched in the historical state switching database to determine the path adaptability of the current dynamic path. Based on the path adaptability and the stability period after switching of historical matching paths, the stability period after the execution of the current dynamic path is estimated, and a prediction result including the path adaptability and the estimated stability period after switching is generated.

6. The event-triggered communication module state switching method according to claim 5, characterized in that, The simulation process of adjusting hardware parameters corresponding to the key adjustment nodes involves calculating the actual load values ​​of each hardware component after adjustment, comparing these actual load values ​​with the current hardware load threshold of the communication module, and analyzing the risk of hardware load exceeding limits, including: A load calculation model is established for each hardware parameter adjustment item corresponding to the key adjustment node. The load calculation model is constructed based on the parameter-load correlation of the hardware component and is used to reflect the correspondence between the parameter adjustment amount and the load change amount. Input the adjustment range and adjustment duration from the hardware parameter adjustment items into the load calculation model, and output the real-time load change curves of each hardware component during the adjustment process; Extract the peak load value from the real-time load change curve as the actual load value of each hardware component after adjustment; The actual load values ​​are categorized by hardware component type and compared item by item with the current hardware load threshold of the corresponding communication module. The number of hardware components whose actual load value exceeds the current hardware load threshold of the communication module and the extent of the over-limit are counted. The extent of the over-limit is the difference between the actual load value and the current hardware load threshold of the communication module. Based on the number and extent of the overloaded components, and referring to the correlation between overload and fault occurrence in the historical data of communication module hardware failures, the hardware overload risk level is determined. The hardware load overload risk level, the number of overloaded components, and the overload magnitude are integrated into a hardware load prediction sub-result.

7. The event-triggered communication module state switching method according to claim 5, characterized in that, The simulation of the software process scheduling process corresponding to the core scheduling stage analyzes the integrity of software dependencies after scheduling and determines whether there are process dependency breaks or resource contention conflicts, including: The current software dependencies of the communication module are presented in the form of a dependency graph. The nodes in the dependency graph represent software processes, the edges represent the dependencies between processes, and the attributes of the edges are labeled with the dependency type and dependency strength. Locate the software dependent process nodes involved in the core scheduling process in the dependency graph, and mark the software dependent process nodes that need to be closed and the software dependent process nodes that need to be started. Simulate the shutdown of the software dependent process node that needs to be shut down, delete all the dependency edges corresponding to the software dependent process node, and analyze whether there are isolated nodes in the remaining dependency graph. The isolated node is a software dependent process node that has lost all input dependency edges or output dependency edges. The existence of an isolated node indicates that there may be a process dependency break. Simulate the startup of the software dependent process node to be started, add all the dependency edges corresponding to the software dependent process node, and analyze whether there is a situation in the new dependency graph where the same resource node is pointed to by multiple software dependent process nodes at the same time. The resource node is a memory area, file handle or port resource shared between processes. Multiple software dependent process nodes pointing to the same resource node indicates that there may be a resource competition conflict. For isolated nodes, perform dependency tracing to determine the specific points of dependency breakage, and record the types of broken dependencies and the software dependency process nodes involved. Perform resource utilization analysis on existing resource competition conflicts, determine the types of conflicting resources and competition process nodes, and record the probability of conflict occurrence; The results of dependency fracture analysis, resource competition conflict analysis, and corresponding record information are integrated into software dependency prediction sub-results.

8. The event-triggered communication module state switching method according to claim 1, characterized in that, The step of converting the dynamic path into a state switching execution command based on the prediction result, inputting it into the communication module to execute the switching operation, and generating switching process data includes: The path adaptability in the prediction result is analyzed. If the path adaptability meets the preset adaptability standard, a state switching execution instruction is directly generated based on the dynamic path. If the path adaptability does not meet the preset adaptability standard, the hardware parameter adjustment sequence, software process scheduling order and external interaction adaptation strategy in the dynamic path will be corrected based on the hardware overload risk, software dependency breakage risk and external interaction instability risk in the prediction results. The modified dynamic path is structured according to the communication module instruction format requirements and transformed into a state switching execution instruction that includes hardware adjustment sub-instructions, software scheduling sub-instructions and external adaptation sub-instructions. Each sub-instruction includes an execution timing identifier and a collaborative execution identifier. The state switching execution instruction is transmitted to the main control unit of the communication module, so that the main control unit of the communication module sequentially issues hardware adjustment sub-instructions to the hardware control module, software scheduling sub-instructions to the software management module, and external adaptation sub-instructions to the external interaction module according to the execution timing identifier and the collaborative execution identifier. During the execution of sub-instructions in each module, real-time data on changes in hardware adjustment parameters, changes in software process status, and external interaction links are collected and integrated to generate switching process data. The switching process data includes the execution time of each sub-instruction, parameter comparison before and after execution, and execution exception records.

9. The event-triggered communication module state switching method according to claim 1, characterized in that, The step of updating the historical state transition database and the target association network based on the switching process data and the stable cycle prediction in the prediction results to form a state transition closed-loop optimization identifier includes: The execution time of each sub-instruction, the comparison of parameters before and after execution, and the execution exception records are extracted from the switching process data to analyze the actual switching effect. The actual switching effect is compared with the estimated stable period after switching in the prediction result, and the relative deviation of the prediction is calculated. The relative deviation of the prediction is the ratio of the difference between the actual stable period and the estimated stable period to the estimated stable period. Extract the actual execution effects of the hardware parameter adjustment sequence, the actual execution effects of the software process scheduling order, and the actual execution effects of the external interaction adaptation strategy from the switching process data, and associate the corresponding event layering results with the current running status of the communication module; The event layering results, the current operating status of the communication module, the actual dynamic path executed, the actual switching effect and the estimated deviation are entered into the historical status switching database, and the historical event records, historical switching path records and historical stability records after switching are updated. Find the node that corresponds to the current event layering result and the current operating state of the communication module in the target association network, and adjust the weight of the association edges between the nodes based on the actual switching effect; If the actual switching effect is better than the historical records of the same type, then the dynamic path is marked as the preferred path in the target association network; If the actual switching effect is abnormal, the corresponding target associated node is marked in the target associated network; By integrating the update records of the historical state transition database with the adjustment records of the target associated network, a state transition closed-loop optimization report is generated. Based on the state transition closed-loop optimization report, a state transition closed-loop optimization identifier is formed, which includes the optimization time, optimization content, and expected effect after optimization.

10. An event-triggered communication module state switching system, characterized in that, include: processor; A machine-readable storage medium for storing machine-executable instructions of the processor; The processor is configured to execute the event-triggered communication module state switching method according to any one of claims 1 to 9 by executing the machine-executable instructions.

Images