A vehicle-mounted controller network management method

Abstract

The application belongs to the field of vehicle-mounted communication and provides a vehicle-mounted controller network management method, which comprises the following steps: configuring a filter to listen to network management messages of a vehicle-mounted controller, counting a plurality of periods to generate a characteristic vector, and importing a neural network model for training; the state category of the vehicle-mounted controller is preset, a probability vector is output by the neural network model, the vehicle-mounted controller is taken as a node, the point connection for mutual communication is taken as an undirected edge, and the edge weight is calculated comprehensively according to the communication reliability; the communication reliability of the vehicle-mounted controller in multiple scenes is calculated, the connection strength threshold is set according to the average value and the standard deviation, the strength level of the link is judged and sorted, the earlier ones are selected as master nodes, and the remaining ones connected with the master nodes are taken as slave nodes; the flash memory space of the vehicle-mounted controller is divided, the upgrade content is checked, the version is traced back for the failed check, and the state flow and results of different upgrade stages and network management stages of each vehicle-mounted controller are recorded.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of vehicle communication, in particular to a vehicle controller network management method. BACKGROUND

[0002] The vehicle controller is an electronic device responsible for controlling various electronic systems and functions in a car. It achieves real-time management and regulation of subsystems by collecting sensor signals and executing control algorithms.

[0003] In Chinese application No. CN202210859283.X, a vehicle local network management method and system. The configuration method includes: determining the awakened network node according to the local event, and calling the corresponding function scene according to the pre-set function configuration of the network node to obtain the matching function scene; generating the network management parameters of the matching function scene, and sending the corresponding network management message to the gateway according to the network management parameters, wherein the network management message contains a network management identifier, which is used to represent the type of the corresponding network management message; determining the related network segment of the matching function scene according to the network management message, and sending the network management message to the controller on the related network segment to wake up the controller and complete the control of the corresponding function scene.

[0004] In the field of vehicle communication, although there are technologies that associate network nodes with function scenes to send network messages, control the transmission of specific function scene controllers, wake up the related network segment, and improve the overall response processing efficiency, in the OTA scene of medium and low-end intelligent passenger cars, due to the existence of multiple different physical and protocol specification hardware differences in the same vehicle electronic and electrical system, and the constraints of loading timing, software adaptation, and protocol compatibility of vehicle controllers, the existing network management method is difficult to real-time sense and adjust the vehicle controller, which may cause information loss and state unsynchronization during the upgrade of the vehicle controller, increasing the risk of abnormal communication between vehicle modules, and lacking real-time rollback and correction mechanism for network management state. Therefore, a network management method is needed that can real-time sense and adjust the vehicle controller for medium and low-end intelligent passenger cars. SUMMARY

[0005] The present application provides a vehicle controller network management method to address the problem of real-time network management being impossible due to the limitations of vehicle controller software and hardware in the OTA scene of medium and low-end intelligent passenger cars, and the lack of network management state rollback and correction during OTA upgrade.

[0006] The technical solution adopted by the present application to solve the above technical problems is to provide a vehicle controller network management method, comprising:

[0007] The controller communication index is collected, a lightweight neural network is deployed, a filter is configured to monitor network management messages of the vehicle-mounted controller, a feature vector is generated in multiple cycles, time stamp alignment and smoothing processing are performed, a neural network model is imported for training, and the training result is integrated into the flash memory of the vehicle-mounted main controller;

[0008] The controller state is dynamically identified, and a controller communication state diagram is constructed. The state categories of the vehicle-mounted controller are preset, a probability vector is output by the neural network model, the vehicle-mounted controller is taken as a node, the communication points are taken as connection edges, and the communication reliability is calculated and the edge weight is assigned;

[0009] Different connection strength thresholds are defined, and the master-slave communication structure is automatically adjusted. The communication reliability of the vehicle-mounted controller in multiple scenarios is calculated, the connection strength threshold is set according to the average value and the standard deviation, the strength level of the link is judged and sorted, the front ones are selected as the master nodes, and the remaining ones are connected to the master nodes as the slave nodes.

[0010] An upgrade rollback mechanism is established, and the controller processing path and result are recorded. The flash memory space of the vehicle-mounted controller is divided, the upgrade content is verified, the version is traced back for the verification failure, and the state flow and result of different upgrade stages and network management stages of each vehicle-mounted controller are recorded.

[0011] As a preferred embodiment, the specific steps of collecting the controller communication index are as follows: a filter of a controller area network bus controller is configured, a network monitoring ECU is used to monitor network management messages, a system timer is used to calculate the time stamp difference of the network management messages from the same ECU, a counter and an accumulator are established for each ECU, and the network management messages are classified according to the type. When the ECU for special monitoring receives a heartbeat message, the current time stamp is recorded as the heartbeat time stamp. When the confirmation message of the version upgrade is received, the time stamp of the sending completion is recorded as the ACK response time stamp. When the error condition of the reception is detected, the corresponding ECU accumulator is used to add and store in the error counter. All time stamps and counters are retained at the end of each collection cycle, the sending time and confirmation delay of multiple types in the current cycle are counted, and the average value and standard deviation of multiple cycles are taken as the feature vector.

[0012] As a preferred embodiment, the specific steps of deploying the lightweight neural network are as follows: MobileNetV2 is selected as the lightweight neural network model architecture, the feature vectors of multiple cycles are constructed as the training set of MobileNetV2, MobileNetV2 is trained in the TensorFlow framework, the trained MobileNetV2 model is exported, and the model is integrated into the flash memory of the T-Box. After starting, the model is loaded and executed by the local lightweight inference engine.

[0013] As a preferred embodiment, the specific steps of dynamically identifying the state of the controller are: encapsulating the real-time communication indicators monitored by the bus listener into an original feature vector, setting the size of the sliding window, calculating the mean value in the window as the filtering result at the current time, removing incidental noise, and converting the original data into normalized standard scores according to the feature dimension by using Z-Score; inputting the standardized feature vector into the MobileNetV2 model, setting the state category of the vehicle-mounted controller in advance according to the clear stage and typical anomaly divided according to the design OTA upgrade protocol, and determining the state category of the vehicle-mounted controller through the probability vector output by the model.

[0014] As a preferred embodiment, the specific steps of constructing the controller communication state diagram are: grouping all ECUs in the system into an ECU node set according to the unique physical address, adding an undirected edge between any two ECU nodes on the same bus and capable of direct network communication, and in the sliding window, counting the heartbeat success rate, ACK success rate, and error frame rate between the ECU nodes, calculating the communication reliability according to the weights, and assigning values to the corresponding undirected edges, with the formula being:

[0015]

[0016] where j, k represent node j and node k, Reliable j,k represents the undirected edge communication reliability between node j and k, w1 represents the weight of the heartbeat success rate, w2 represents the weight of the ACK success rate, w3 represents the weight of the error frame rate, represents the expected heartbeat success rate, HB j,k represents the actual heartbeat success rate between node j and k, represents the expected ACK success rate, ACK j,k represents the actual ACK success rate between node j and k, F j,k represents the total number of frames between node j and k, error j,k represents the number of error frames between node j and k;

[0017] All (j, k, Reliable j,k ) triples are stored in a list structure, and Reliable j,k is recalculated according to the communication indicators at each collection period, and the triples are updated.

[0018] As a preferred embodiment, the specific steps of defining different connection strength thresholds are: collecting different ECU communication reliabilities under multiple road conditions to form a sample set, calculating the mean and standard deviation, and setting the connection strength threshold according to the mean and standard deviation, with the formula being:

[0019] thre low = aver r - α1devi r , thre strong = aver r + α2devi r ,

[0020] wherein thre low represents a low connection strength threshold, aver r represents an average value of the communication reliability, devi r represents a standard deviation of the communication reliability, α1represents a low connection strength weight, thre strong represents a high connection strength threshold, and α2represents a high connection strength weight.

[0021] The high and low connection strength weights are obtained by sorting the collected connection strength samples from low to high to form an empirical distribution function, dividing the values corresponding to the positions in proportion, normalizing the value corresponding to the 90% quantile as the standard high connection strength weight, and normalizing the value corresponding to the 10% quantile as the standard low connection strength weight.

[0022] As a preferred embodiment, the specific steps of automatically adjusting the master-slave communication structure are as follows: reading the comprehensive connection strength matrix between each pair of ECUs, judging the level of each link according to the pre-set high and low connection strength thresholds, and identifying abnormal nodes.

[0023] When Reliable j,k ≥ thre strong , it is determined that the link belongs to the strong connection level, when thre low ≤ Reliable j,k < thre strong , it is determined that the link belongs to the medium connection level, and when Reliable j,k < thre low , it is determined that the link belongs to the weak connection level; if the edges of more than half of the connections of a certain ECU node belong to the weak connection level, the ECU is marked as an abnormal node; a set of key ECUs is pre-set, the global health score thereof is calculated, the key ECUs in the set are sorted in descending order of the global health score, the top three are selected as master nodes to assume the role of broadcast center, and the remaining key ECUs are slave nodes that receive the node state transmitted by the master nodes without actively sending.

[0024] As a preferred embodiment, the specific step of establishing the rollback mechanism of the upgrade is: dividing each ECU flash memory into a running area and a standby area, storing a pointer pointing to the current running area through a bootloader in the ECU, storing the current running area number and the firmware version number before OTA upgrade, and setting the upgrade state flag to be processed; the OTA scheduling unit writes the upgrade content into the standby area of the ECU, sets the upgrade content switching flag to pass the verification in the standby area, sets the upgrade content switching flag to rollback state in case of verification failure, and performs version rollback according to the previously stored running area number and firmware version number.

[0025] As a preferred embodiment, the specific step of recording the controller processing path and the result is: structurally recording the state transition of different upgrade stages and network management stages of each ECU and the result thereof, defining a unified log item structure in the upgrade state management module of each ECU and the scheduling unit of the T-Box, respectively, constructing the corresponding log item and storing it in the corresponding ECU as soon as the upgrade state management state changes and a key event is triggered.

[0026] The beneficial effects of the present application are:

[0027] 1. The present application introduces a lightweight neural network, periodically collects multi-dimensional communication indicators such as heartbeat interval, ACK delay, error frame rate, etc., and the system can realize real-time perception and prediction of the running state of the vehicle-mounted controller, greatly improving the visual monitoring capability during the upgrade.

[0028] 2. The present application constructs a communication state diagram of the vehicle-mounted controller, sets high and low connection strength thresholds, automatically adjusts the master-slave node roles, places the key controller in the communication center, and sets the abnormal node to receive but not actively send, thereby automatically adjusting the network structure, realizing single-point fault isolation and multi-path redundancy, and reducing the risk of vehicle upgrade failure.

[0029] 3. The present application establishes an OTA upgrade rollback mechanism, uses multi-partition storage, and performs upgrade verification through the CRC algorithm, which can identify verification failure within a short time, automatically rollback to the stable version, thereby shortening the fault recovery time and reducing the safety risk.

[0030] Legend

[0031] Figure 1 A flowchart of a vehicle-mounted controller network management method. DETAILED DESCRIPTION

[0032] In order to make the technical means, creative features, purposes and effects of the present application easy to understand, the following further describes the present application in combination with specific embodiments, but the following embodiments are only preferred embodiments of the present application, not all. Based on the embodiments in the embodiments, other embodiments obtained by those skilled in the art without creative labor are within the protection scope of the present application.

[0033] Embodiment 1, as Figure 1 The application relates to a vehicle-mounted controller network management method, comprising the following steps:

[0034] Collecting controller communication indexes; deploying a lightweight neural network;

[0035] Dynamically identifying controller states; and constructing a controller communication state diagram;

[0036] Defining different connection strength thresholds; and automatically adjusting master-slave communication structures;

[0037] Establishing an upgrade rollback mechanism; and recording controller processing paths and results.

[0038] The following are specific implementation steps: a vehicle-mounted controller network management method, wherein the specific steps of collecting controller communication indexes are as follows:

[0039] Configuring a filter of a controller area network (CAN) controller, listening to network management messages of a special monitoring electronic control unit (ECU) in a vehicle, calculating a time stamp difference value of the network management messages from the same ECU through a system timer, establishing a counter and an accumulator for each ECU, classifying the network management messages according to types, recording a current time stamp as a heartbeat time stamp when the special monitoring ECU receives a heartbeat message, recording a time stamp of sending completion as an ACK response time stamp when a version upgrade confirmation message is received, and adding and storing an error counter through the accumulator of the corresponding ECU when a receiving error or a packet loss is detected; all time stamps and counters are reserved at the end of each collection period, a plurality of types of sending time and confirmation time delay in the current period are counted, and average values and standard deviations of a plurality of periods are taken as feature vectors;

[0040] The specific steps of deploying the lightweight neural network are: selecting MobileNetV2 as a lightweight neural network model architecture, constructing a plurality of period characteristic vectors as a training set of MobileNetV2, training MobileNetV2 in a TensorFlow framework, exporting the trained MobileNetV2 model, integrating it into the flash memory of a vehicle-mounted main controller (Telematics Box, T-Box), and loading and executing it by a local lightweight inference engine after startup, wherein the TensorFlow framework is a full-stack deep learning framework covering model definition, training, optimization, and visualization.

[0041] Specifically, the MobileNetV2 is a lightweight convolutional neural network structure for mobile and embedded devices, which includes four levels of expansion mapping layers, linear projection layers, global feature fusion layers, and output classification layers. The expansion mapping layer first expands the dimension of the feature vector, unifies the tensor form, the linear projection layer linearly reduces the dimension of the feature vector with expanded dimension to remove redundant information, the global feature fusion layer converges and fuses the features after expansion mapping and linear projection to a uniform intermediate dimension, and the output classification layer maps the fused features to an over-the-air (OTA) state category dimension.

[0042] Based on the above steps, the specific steps of dynamically identifying the controller state are: encapsulating the real-time communication indicators monitored by the bus listener into original feature vectors, and removing incidental noise by sliding window mean.

[0043] Specifically, the sliding window mean incidental noise removal is to set the sliding window size to 5, assign a queue with a length of the window size to store the original values of the last 5 times for the feature sequence, and calculate the mean value in the window as the filtering result at the current time; the input vector normalization is to use Z-Score to convert the original data to a distribution with a mean of 0 and a standard deviation of 1 according to the feature dimension, calculate the mean and standard deviation of the features, and use the formula to get the normalized standard score:

[0044]

[0045] where i represents the index of the data, x i represents the feature value of the i-th data, z i represents the standard score of the i-th data, σ represents the standard deviation of the data, and μ represents the mean of the data.

[0046] The standardized feature vector is input into the MobileNetV2 model, and the state category of the vehicle-mounted controller is set in advance according to the clear stages and typical abnormalities divided according to the design OTA upgrade protocol, and the state category of the vehicle-mounted controller such as response lag, no update, update failure and normal is judged through the probability vector output by the model;

[0047] The specific steps of constructing the controller communication state diagram are: all ECUs in the system are grouped into an ECU node set according to unique physical addresses, for any two ECU nodes on the same bus and capable of direct network communication, a non-directed edge is added, in the sliding window, the heartbeat success rate, ACK success rate and error frame rate between ECU nodes are counted, the communication reliability is calculated according to the weights, and the corresponding non-directed edge is assigned, the formula is:

[0048]

[0049] where j, k represent node j and node k, Reliable j,k represents the non-directed edge communication reliability between node j and k, w1 represents the weight of the heartbeat success rate, w2 represents the weight of the ACK success rate, w3 represents the weight of the error frame rate, represents the expected heartbeat success rate, HB j,k represents the actual heartbeat success rate between node j and k, represents the expected ACK success rate, ACK j,k represents the actual ACK success rate between node j and k, F j,k represents the total number of frames between node j and k, error j,k represents the number of error frames between node j and k;

[0050] All (j, k, Reliable j,k ) triples are stored in a list structure, and Reliable j,k is recalculated according to the communication indicators in each collection period, and the triples are updated.

[0051] Based on the above steps, the specific steps of defining different connection strength thresholds are: collecting different ECU communication reliabilities under various road conditions to form a sample set, calculating the average value and standard deviation, and setting the connection strength threshold according to the average value and standard deviation, the formula is:

[0052] thre low =aver r -α1devi r , thre strong =aver r +α2devi r ,

[0053] wherein thre low represents the average value of the communication reliability, devi r represents the average value of the communication reliability, devi r represents the average value of the communication reliability, devi strong represents the average value of the communication reliability, devi

[0054] Specifically, the high and low connection strength weights are obtained by sorting the collected connection strength samples from low to high to form an empirical distribution function, dividing the values corresponding to the positions in proportion, normalizing the value corresponding to the 90% quantile as the standard high connection strength weight, and normalizing the value corresponding to the 10% quantile as the standard low connection strength weight.

[0055] The specific steps of automatically adjusting the master-slave communication structure are as follows: reading the comprehensive connection strength matrix between each pair of ECUs, judging the level of each link according to the pre-set high and low connection strength thresholds, and identifying abnormal nodes.

[0056] Specifically, the level of each link is judged as follows: when Reliable j,k ≥ thre strong , it is determined that the link belongs to the strong connection level; when thre low ≤ Reliable j,k < thre strong , it is determined that the link belongs to the medium connection level; and when Reliable j,k < thre low , it is determined that the link belongs to the weak connection level; if the edges of more than half of the nodes connected to a certain ECU node belong to the weak connection level, the ECU is marked as an abnormal node; a set of key ECUs, such as a gearbox control unit and a body control module, is pre-set, all non-abnormal nodes are counted, and a global health score is calculated, specifically by adding and normalizing the connection strength of the undirected edges formed by the ECU node and all other nodes connected thereto, sorting the key ECU set in descending order of the global health score, and selecting the top 3 as master nodes to assume the role of broadcast center, and the remaining key ECUs as slave nodes to receive node status from the master nodes without actively sending.

[0057] Based on the above steps, the specific steps of establishing the rollback mechanism of the upgrade are: dividing each ECU flash memory into a running area and a standby area, storing a pointer pointing to the current running area through the bootloader in the ECU, before OTA upgrade, the bootloader stores the current running area number and the firmware version number, and sets the upgrade state flag to pending; the OTA scheduling unit writes the upgrade content into the standby area of the ECU, sets the upgrade content switching flag to pass the verification for the upgrade content passing the verification, sets the rollback state for the upgrade content failing the verification, and performs version rollback according to the previously stored running area number and firmware version number;

[0058] Specifically, the verification of the upgrade content is to read the pre-set CRC value from the firmware header, calculate and write the CRC value into the header area by the OTA server when making the package, define the initial and end addresses of the firmware image area, write the length of the data part into the CRC register, perform polynomial division on each byte, and calculate the XOR of the current CRC state. If the pre-set CRC value is consistent, it means that the verification is passed;

[0059] The specific steps of the record controller processing path and result are: structuring the record of the state transition and its result of each ECU in different upgrade stages and network management stages, defining a unified log item structure in the upgrade state management module of each ECU and the scheduling unit of the T-Box, including the absolute timestamp of the event occurrence, the state code, the ECU unique identifier and other parameters, and constructing the corresponding log item and storing it to the corresponding ECU immediately when the upgrade state management state changes and triggers a key event;

[0060] Specifically, the upgrade state management state changes and triggers a key event, the upgrade state management module monitors the local network state, and the OTA scheduling unit undertakes the responsibilities of coordination and notification among the ECUs. After the upgrade package is framed and written, the upgrade state management module performs polling confirmation to ensure that all data blocks have been written to the standby area.

[0061] Embodiment 2, based on the above embodiment 1, application of a vehicle controller network management method in the OTA scene of a medium and low-end intelligent passenger car, specifically the following scheme:

[0062] Step one, collect the heartbeat interval, ACK delay, error frame rate, bus load rate, online response time and other multi-dimensional features of the vehicle controller network communication message, form a time series matrix according to a fixed window, select a time series convolution network for state classification of the vehicle controller, receive the time series matrix by the input layer of the time series convolution network, extract the time series dependence through three layers of causal dilation convolution in the convolution block layer, which can meet both short-term burst and long-term trend, perform global average on the features after three layers of convolution in the time dimension to remove the time position information, and then perform state determination and confidence check.

[0063] Step two, collect communication indicators for each ECU with a 500ms acquisition cycle, including: heartbeat success rate, ACK success rate, error frame rate, Bus-Off times, bus load rate and other indicators, through CAN to send and receive interrupts, use timers to record different types of events such as ACK reception, error frame occurrence, and corresponding time stamps, use counters to count the number of occurrences; For heartbeat success rate, ACK success rate, error frame rate and bus load rate, define three corresponding labels of low, medium and high, map each indicator value to the corresponding label to get the label set, and four indicators are summarized according to the weight to get the comprehensive label, for example, the weight of heartbeat success rate is 0.2, the weight of ACK success rate is 0.2, the weight of error frame rate is 0.3, and the weight of bus load rate is 0.3; According to the ECU, a node set is established, edges are added between the communicable nodes, the comprehensive label is set as the edge weight, and the adjacency matrix is filled.

[0064] Step three, periodically calculate the comprehensive connection strength between each ECU every 500ms to form a sample set, and apply a two-component Gaussian mixture model to the sample set in the vehicle main controller, which is to calculate the responsibility of each sample to the two Gaussian distributions, and update the effective sample number, mixing coefficient, mean, variance and other parameters of the Gaussian mixture model using the responsibility until the parameter increment is small enough to output the current solution; The solution obtained is used as the dynamic connection strength threshold, and the threshold is higher than the threshold. Strong connection, lower than or equal to the threshold is weak connection, and the feature vector center algorithm is applied to the communication state diagram to calculate the score of each ECU node. Set the top 5% nodes as master nodes, and the remaining unselected ECUs that maintain strong connection with at least one master node are configured as slave nodes.

[0065] Step four, divide the flash memory of the ECU into running area, update area and log area, the running area runs the current effective firmware, the update area receives and verifies new firmware, and the log area is used to record previous logs and processing events; When receiving new firmware, perform Hash verification such as SHA-256 on the data, and judge the verification result through incremental calculation and comparison. When it fails, set it to rollback state, generate corresponding log for recording, and store it to the log area of the ECU; Read the ECU log area regularly to rebuild the state stream, package it into JSON format and upload it to the background for fault analysis.

[0066] The above describes the embodiments of the present application, without departing from the embodiments of the present application and its broader aspects, the skilled in the art can make data modification and mode change based on this place in the specific operation, the appended claims are for all such data modification and mode change which does not deviate from the embodiments of the present application.

Claims

1. A method for managing a vehicle-mounted controller network, characterized in that, include: Step 1: Collect controller communication metrics and deploy a lightweight neural network. This involves configuring a filter to monitor the network management messages of the vehicle controller ECU, generating feature vectors over multiple periods, aligning and smoothing them with timestamps, importing them into the neural network model for training, and then integrating the trained neural network model into the vehicle controller ECU flash memory. Step Two: Dynamically identify the controller state and construct a controller communication state diagram. This involves pre-setting the state categories of the vehicle controller ECUs, outputting probability vectors from a neural network model, treating the vehicle controller ECUs as nodes, and the points communicating with each other as edges. The communication reliability is comprehensively calculated and edge weights are assigned. All ECUs in the system are grouped into ECU node sets based on their unique physical addresses. For any two ECU nodes on the same bus that directly communicate with each other, an undirected edge is added. Within a sliding window, the heartbeat success rate, ACK success rate, and error frame rate between ECU nodes are statistically analyzed. The communication reliability is then comprehensively calculated according to the weights and assigned to the corresponding undirected edges. The formula is as follows: ， Where j and k represent nodes j and k, This represents the reliability of undirected edge communication between nodes j and k. The weights representing the success rate of the heartbeat. The weights representing the success rate of ACKs. The weights representing the error frame rate This indicates the expected success rate of the heartbeat. This represents the actual heartbeat success rate between nodes j and k. This indicates the expected ACK success rate. This represents the actual ACK success rate between nodes j and k. This represents the total number of frames between nodes j and k. This represents the number of error frames between nodes j and k; Store all using a list structure The triplet is recalculated based on communication metrics in each acquisition cycle. And update the triples; Step 3: Define different connection strength thresholds and automatically adjust the master-slave communication structure. This involves calculating the communication reliability of the vehicle controller ECU in various scenarios, setting connection strength thresholds based on the average value and standard deviation, judging and sorting the links by strength level, selecting the highest-ranking links as master nodes, and the remaining links connected to the master nodes as slave nodes. The communication reliability of different ECUs under various road conditions is collected to form a sample set. The mean and standard deviation are calculated, and a connection strength threshold is set based on the mean and standard deviation. The formula is as follows: ， ， in This indicates a low connection strength threshold. This represents the average value indicating communication reliability. The standard deviation represents the reliability of communication. Indicates low connection strength weights. Indicates the high connection strength threshold. Indicates high connection strength weights; Read the comprehensive connection strength matrix between each pair of ECUs, determine the level of each link based on the pre-set high and low connection strength thresholds, and identify abnormal nodes; when The link is determined to be at the strong connection level. The link is determined to be of medium connectivity level. If the link is determined to be at the weak connection level, and if the edges between an ECU node and more than half of the connected nodes are at the weak connection level, then the ECU is marked as an abnormal node. A set of key ECUs is pre-defined, and their global health scores are calculated. The key ECUs are sorted from largest to smallest according to their global health scores. The top 3 are selected as master nodes, which act as broadcast centers. The remaining key ECUs are slave nodes that transmit node status to the master nodes. Abnormal nodes only receive and do not actively send. Step 4: Establish an upgrade rollback mechanism, record the controller processing path and results, allocate the flash memory space of the vehicle controller ECU, verify the upgrade content, perform version rollback for those that fail verification, and record the status flow and results of different upgrade stages and network management stages for each vehicle controller ECU.

2. The vehicle controller network management method according to claim 1, characterized in that: The specific steps for the communication indicators of the acquisition controller are as follows: Configure the filter of the Controller Area Network (CLAN) bus controller, utilize the monitoring ECU to listen for network management messages, calculate the received timestamp difference of network management messages from the same ECU using a system timer, establish a counter and accumulator for each monitored ECU, and classify the network management messages according to their type. When the monitoring ECU receives a heartbeat message, it records the current timestamp as the heartbeat timestamp; when it receives a version upgrade confirmation message, it records the timestamp of completion of transmission as the ACK response timestamp. When a receiving error is detected, the error counter is incremented and stored by the accumulator of the corresponding ECU. At the end of each collection cycle, all timestamps and counters are retained, and the various types of sending times and acknowledgment delays of the current cycle are statistically analyzed. The average and standard deviation of multiple cycles are used as feature vectors.

3. The vehicle controller network management method according to claim 1, characterized in that: The specific steps for deploying the lightweight neural network are as follows: MobileNetV2 was selected as the lightweight neural network model architecture. Feature vectors from multiple periods were used to construct the training set of MobileNetV2. MobileNetV2 was trained in the TensorFlow framework, and the trained MobileNetV2 model was exported and integrated into the flash memory of the T-Box. After startup, it was loaded and executed by the local lightweight inference engine.

4. The vehicle controller network management method according to claim 1, characterized in that: The specific steps for dynamically identifying the controller state are as follows: The real-time communication metrics monitored by the bus listener are encapsulated into raw feature vectors. The sliding window size is set, and the mean within the window is calculated as the filtering result at the current moment to remove occasional noise. Z-Score is used to transform the filtered feature vectors into normalized standard scores according to the feature dimensions. The standardized feature vectors are input into the MobileNetV2 model. Based on the clear stages and typical anomalies of the OTA upgrade protocol, the state category of the vehicle controller is pre-defined. The state category of the vehicle controller is determined by the probability vector output by the model.

5. The vehicle controller network management method according to claim 1, characterized in that: The specific steps for defining different connection strength thresholds also include: The high and low connection strength weights are obtained by sorting the collected connection strength samples from low to high to form an empirical distribution function, dividing the values ​​corresponding to the positions proportionally, normalizing the values ​​corresponding to the 90th percentile as the standard high connection strength weights, and normalizing the values ​​corresponding to the 10th percentile as the standard low connection strength weights.

6. The vehicle controller network management method according to claim 1, characterized in that: The specific steps for establishing the upgrade rollback mechanism are as follows: Each ECU flash memory is divided into a running area and a spare area. The bootloader in the ECU stores a pointer to the current running area. Before the OTA upgrade, the bootloader stores the current running area number and firmware version number, and sets the upgrade status flag to pending. The OTA scheduling unit writes the upgrade content to the spare area, switches the status flag of the upgrade content that passes verification to "verification passed", sets the status of the failed verification to "rollback", and performs version rollback according to the previously stored operating area number and firmware version number.

7. The vehicle controller network management method according to claim 1, characterized in that: The specific steps for recording the controller's processing path and results are as follows: The status transitions and results of different upgrade and network management stages for each ECU are recorded in a structured manner. A unified log entry structure is defined in the upgrade status management module and the scheduling unit of the T-Box for each ECU. Whenever the upgrade status management status changes or a critical event is triggered, the corresponding log entry is immediately constructed and stored in the corresponding ECU.

Images