Communication function safety protection method and device, equipment, vehicle and storage medium

Abstract

This application relates to a communication function safety protection method, apparatus, device, vehicle, and storage medium. The method includes: when the communication cycle of a communication node is adjusted to be greater than a preset original cycle, executing at least one of the following protection strategies: a first protection strategy: determining an extended counting verification window based on the scaling factor N of the communication cycle, and performing counting verification on forwarded messages between communication nodes based on the extended counting verification window; wherein N is a rational number greater than 1; a second protection strategy: smoothly reconstructing the control values ​​in the control commands to be sent out by the communication node based on the original demand values ​​and actual feedback values ​​of historical sampling points. This application can improve the ability to identify message anomalies and the verifiability of control outputs under cycle change conditions, enhance the reliability of actuator-level safety mechanism triggering, and improve the effect of vehicle communication function safety protection.

Description

Technical Field

[0001] This application relates to the field of vehicle communication security technology, specifically to a communication function safety protection method, device, equipment, vehicle, and storage medium. Background Technology

[0002] In the distributed electronic and electrical architecture of intelligent connected vehicles, communication between controllers and the outward transmission of control commands within the domain typically adopt fixed-period transmission, combined with E2E verification, CRC verification and timeout detection to ensure functional safety.

[0003] However, under complex operating conditions or load fluctuations, the communication cycle may be adjusted and dynamically lengthened, exhibiting multiple forwarding or a stepped discrete distribution. Existing verification strategies based on the assumption of a fixed cycle are usually unable to adapt to the dynamic changes in the communication cycle, making it difficult to accurately identify message count anomalies and discontinuous instruction sequences. This leads to a decrease in anomaly detection sensitivity and makes it difficult to maintain stable functional safety diagnostic coverage.

[0004] Therefore, how to improve the functional safety diagnostic coverage of message transmission and control command outgoing under the dynamic adjustment of communication cycle has become an urgent technical problem to be solved. Summary of the Invention

[0005] This application provides a communication functional safety protection method, apparatus, device, vehicle, and storage medium to solve the aforementioned technical problems. This method addresses scenarios where the communication cycle of a communication node dynamically adjusts from its original cycle due to changes in its operating state. It establishes a security protection mechanism adapted to cycle changes to mitigate functional safety risks in message forwarding links and control command outgoing processes. Without relying on the assumption of a fixed cycle, it collaboratively handles communication anomaly identification and control security assurance, thereby improving functional safety protection capabilities under dynamically changing communication cycles.

[0006] In a first aspect, this application provides a communication function security protection method, the method comprising:

[0007] When the communication period of a communication node is adjusted to be greater than the preset original period, at least one of the following protection strategies will be executed:

[0008] First protection strategy: Determine an extended counting verification window based on the scaling factor N of the communication period, and perform counting verification on the forwarded messages between the communication nodes based on the extended counting verification window; where N is a rational number greater than 1.

[0009] The second protection strategy is to smoothly reconstruct the control values ​​in the control commands to be sent out by the communication node based on the original demand values ​​and actual feedback values ​​of historical sampling points.

[0010] In one possible implementation, determining the extended count verification window based on the scaling factor N of the communication period includes:

[0011] If N is an integer, then the extended counting verification window contains three count values: N-1, N, and N+1.

[0012] If N is not an integer, the extended counting verification window contains four count values: M-1, M, M+1, and M+2, where M is the integer N rounded down.

[0013] In one possible implementation, the step of performing count verification on the forwarded messages between the communication nodes based on the extended count verification window includes:

[0014] Extract the count value carried in the forwarded message. If the count value carried in the forwarded message does not belong to the count value in the extended count verification window, the count is considered abnormal.

[0015] In one possible implementation, the method further includes:

[0016] When N is an integer and N+1 reaches or exceeds the maximum allowed count value of the forwarded message, or when N is a non-integer and M+2 reaches or exceeds the maximum allowed count value of the forwarded message, the counting verification is performed again according to the preset counting step size.

[0017] In one possible implementation, the method further includes:

[0018] Perform cyclic redundancy check (CRC) and / or timeout check on the forwarded message;

[0019] If any of the following occurs continuously within the preset fault tolerance time interval: abnormal counting, CRC check failure, or check timeout, the forwarding message communication is deemed abnormal.

[0020] In one possible implementation, the smooth reconstruction of the control values ​​in the control commands to be sent out by the communication node based on the original demand values ​​and actual feedback values ​​from historical sampling points includes:

[0021] Obtain multiple historical sampling points prior to the current moment; each historical sampling point includes the original demand value and the actual feedback value at the corresponding sampling moment;

[0022] Curve fitting is performed on the original demand values ​​from the multiple historical sampling points to obtain the original demand fitted values;

[0023] Curve fitting is performed on the actual feedback values ​​from the multiple historical sampling points to obtain the actual feedback fitted values;

[0024] Based on the original demand fitting value and the actual feedback fitting value, the control value in the control command to be sent out by the communication node is determined.

[0025] In one possible implementation, determining the control value in the control command to be sent out by the communication node based on the original demand fitting value and the actual feedback fitting value includes:

[0026] Get the vehicle's current speed;

[0027] Based on the current vehicle speed, determine the weights of the original demand fitting value and the actual feedback fitting value;

[0028] Based on the weights of the original demand fitting value and the actual feedback fitting value, the original demand fitting value and the actual feedback fitting value are weighted and summed to obtain a weighted sum value.

[0029] Based on the weighted summation value, the control value in the control command to be sent out by the communication node is determined.

[0030] In one possible implementation, determining the weights of the original demand fitting value and the actual feedback fitting value based on the current vehicle speed includes:

[0031] If the current vehicle speed is less than the first threshold, then the weight of the original demand fitting value is controlled to be lower than the weight of the actual feedback fitting value;

[0032] If the current vehicle speed is greater than the second threshold, then the weight of the original demand fitting value is controlled to be higher than the weight of the actual feedback fitting value;

[0033] If the current vehicle speed is greater than or equal to the first threshold and less than or equal to the second threshold, then the weight of the original demand fitting value is equal to the weight of the actual feedback fitting value.

[0034] In one possible implementation, determining the control value in the control command to be sent by the communication node based on the weighted sum value includes:

[0035] The weighted summation value is determined as the control value in the control command to be sent out by the communication node;

[0036] Alternatively, based on the rate of change of the weighted summation value relative to the control value sent at the previous sampling time, the weighted summation value is subjected to amplitude limiting processing to obtain an amplitude limiting processing result; and the weighted summation value is subjected to boundary constraints according to a preset safety range to obtain a boundary constraint result; the smaller value between the amplitude limiting processing result and the boundary constraint result is taken as the control value in the control command to be sent by the communication node.

[0037] In one possible implementation, the method further includes:

[0038] Obtain the original demand value at the current moment, and calculate the deviation between the original demand value at the current moment and the original demand fitted value;

[0039] If the deviation is greater than a preset deviation threshold and the duration exceeds a preset time, the current sampling point is removed and the fault is recorded.

[0040] In one possible implementation, the second protection strategy further includes:

[0041] Before the preset conditions are met, the original demand value at the current moment is used as the control value in the control command to be sent out by the communication node.

[0042] After the preset conditions are met, the control value is determined using the smooth reconstruction method.

[0043] The preset conditions include: the number of accumulated historical sampling points reaches a preset value, and / or the system running time reaches a preset duration.

[0044] In one possible implementation, the method further includes:

[0045] When the communication period is not greater than the preset original period, or when the control command is protected during transmission after the second protection strategy is executed, a preset end-to-end communication function security diagnosis mechanism is executed.

[0046] Secondly, embodiments of this application provide a communication function security protection device, the device comprising: a processing unit;

[0047] The processing unit is configured to execute at least one of the following protection strategies when the communication period of a communication node is adjusted to be greater than the preset original period:

[0048] First protection strategy: Determine an extended counting verification window based on the scaling factor N of the communication period, and perform counting verification on the forwarded messages between the communication nodes based on the extended counting verification window; where N is a rational number greater than 1.

[0049] The second protection strategy is to smoothly reconstruct the control values ​​in the control commands to be sent out by the communication node based on the original demand values ​​and actual feedback values ​​of historical sampling points.

[0050] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0051] The memory stores computer-executed instructions;

[0052] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0053] Fourthly, embodiments of this application provide a vehicle for implementing the first aspect and / or various possible implementations of the first aspect.

[0054] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0055] The beneficial effects of this application are:

[0056] The communication functional safety protection method, apparatus, equipment, vehicle, and storage medium provided in this application embodiment, by adjusting the communication cycle of the communication node to be greater than the preset original cycle, selecting an extended counting verification window based on the communication cycle scaling factor to count and verify the forwarded messages between communication nodes, and / or smoothly reconstructing the control values ​​in the outgoing control commands based on the original demand values ​​and actual feedback values ​​of historical sampling points; enables message counting verification and control command output to adapt to the dynamic changes in the communication cycle, reduces abnormal misjudgments and omissions caused by multiple forwarding or stepped discrete distribution, and promotes the effective triggering of the safety mechanism at the actuator level, thereby improving the functional safety diagnostic coverage and system operation safety of message transmission and outgoing control commands. Attached Figure Description

[0057] Figure 1 A flowchart illustrating a communication function security protection method provided in an embodiment of this application;

[0058] Figure 2 A schematic diagram of a process for implementing a first protection strategy provided in an embodiment of this application;

[0059] Figure 3 A schematic diagram illustrating the execution of a second protection strategy provided in an embodiment of this application;

[0060] Figure 4 A flowchart illustrating another communication function security protection method provided in an embodiment of this application;

[0061] Figure 5 A flowchart illustrating a second protection strategy provided in an embodiment of this application;

[0062] Figure 6 A schematic diagram of a communication function security protection device provided in an embodiment of this application;

[0063] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0064] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0065] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0066] Functional safety communication technologies for intelligent connected vehicles are typically applied to multi-domain collaborative control scenarios within a distributed electronic and electrical architecture. They are particularly suitable for vehicle operating environments where high-frequency data interaction and real-time control loops exist between the powertrain, chassis, driver assistance, and body domains. In this type of vehicle architecture, different communication nodes can be domain controllers, sub-controllers, actuator control units, or intermediate nodes responsible for message forwarding. Each node transmits information via in-vehicle Ethernet, CAN bus, or other in-vehicle communication links, and performs functions such as status acquisition, control decision-making, message forwarding, and execution feedback in the control link.

[0067] In actual operation, one typical scenario is that after the forward sensing node identifies an obstacle, it transmits the target information to the decision node, which then issues braking, steering, or torque control commands to the relevant nodes in the chassis. Another typical scenario is when the vehicle is in complex road conditions, high-speed lane changes, emergency obstacle avoidance, or multi-task concurrent processing. In these situations, dynamic competition arises between the node's internal computing resources and bus bandwidth, causing the message sending and control command outgoings, which were originally scheduled at a fixed pace, to gradually become non-strictly constant. Especially with the increasing trend of domain controller centralization, a single node often undertakes multiple application tasks simultaneously, making the communication cycle and control outgoing rhythm more significantly affected by changes in operating status. Since the safety mechanisms at the actuator level typically rely on the identifiability of control value changes and the orderliness of communication messages, once the communication cycle is amplified relative to the original cycle, or the control value output exhibits discrete jumps, it may directly affect the reliability of the fault detection link.

[0068] Existing functional safety solutions for vehicle communication, represented by the end-to-end (E2E) communication protection mechanism defined in the AUTOSAR (Automotive Open System Architecture) standard, are mostly based on the assumption of fixed-period communication. Their basic approach involves sending messages between communication nodes according to a preset initial cycle, and using message counters, CRC checks, timeout monitoring, and end-to-end verification mechanisms to identify problems such as message loss, out-of-order delivery, duplication, and content corruption. In the control command outreach stage, the upper-level controller typically generates control values ​​directly based on real-time demand and sends them to the actuators. The actuators or downstream nodes then determine the legality, timeout status, and continuity of the commands according to established safety rules. This type of solution can meet general functional safety requirements under normal load conditions because the message cycle is stable, the count increment pattern is clear, and control value changes are relatively easy to predict.

[0069] However, when changes in vehicle operating status cause the communication cycle of communication nodes to exceed the preset original cycle, the limitations of existing solutions quickly become apparent. First, message count verification often assumes a fixed step relationship between adjacent cycles. Once message forwarding is adjusted to integer multiples or non-integer rational multiples, the relationship between message arrival rhythm and count changes no longer conforms to the fixed window assumption. This leads to some anomalies that should be identified being misjudged as normal, or normal messages after cycle adjustment being misjudged as abnormal. Second, under resource constraints, control commands may not be continuously and smoothly output, but rather exhibit updates at larger cycles or remain unchanged for a period before jumping. This makes it difficult for safety mechanisms established at the actuator level based on continuity, rate of change, or sequence consistency to be correctly triggered. Furthermore, if control values ​​are directly issued based solely on the current demand value without considering the demand evolution process and actual feedback behavior from historical sampling points, the control values ​​are prone to abrupt changes that do not match the system's actual response. This may weaken the safety mechanism's ability to identify abnormal commands and may induce malfunctions or functional degradation under boundary conditions. In other words, while existing technologies are effective under fixed-cycle models, they lack matching verification window expansion ideas and control value smoothing methods when faced with actual scenarios such as amplified communication cycles, changes in message forwarding rhythm, and discrete outgoing control commands. Consequently, it is difficult to maintain stable functional safety diagnostic coverage for message transmission and outgoing control.

[0070] In view of this, how to ensure that forwarded messages can be effectively verified and that outgoing control commands retain identifiable characteristics sufficient to trigger actuator-level security mechanisms when the communication cycle of a communication node is adjusted to be longer than the original cycle due to changes in operating status has become an urgent technical problem to be solved.

[0071] To address the aforementioned issues, this application proposes a communication functional safety protection method. When an amplification of the communication cycle of a communication node relative to a preset original cycle is detected, at least one protection strategy can be selected to adaptively compensate the original functional safety protection mechanism based on the fixed cycle assumption. This effectively improves the anomaly identification capability and the coverage of functional safety diagnosis, thereby enhancing the functional safety protection effect. One technical approach involves determining an extended counting verification window based on the scaling factor N of the communication cycle, and then using this extended counting verification window to count and verify forwarded messages between communication nodes, adapting to the message arrival patterns after cycle changes. Another technical approach is to smoothly reconstruct the control values ​​in the control commands to be sent out by the communication nodes based on the original demand values ​​and actual feedback values ​​of historical sampling points. This ensures that the output control values ​​still have good continuity and verifiability under dynamic cycle conditions, guaranteeing that the safety mechanism at the actuator level can be effectively triggered. This technical solution can be applied to cross-domain communication between domain controllers and the outgoing control commands within a domain in a distributed electronic and electrical architecture. Related communication nodes form a message transmission link through an in-vehicle Ethernet or CAN bus, completing a closed loop of forwarding, control, and execution within the same vehicle control system. By establishing protection logic around two core methods, namely "extended count verification window" and "smooth reconstruction of control value", the ability to identify anomalies and the effectiveness of functional safety protection in dynamic communication cycle scenarios can be improved without relying on the assumption of a fixed communication cycle.

[0072] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0073] It should be noted that the execution entity of the communication function safety protection method provided in this application embodiment can be a communication function safety protection device. This device can be deployed on communication nodes that need to exchange information, and this application embodiment does not impose any restrictions. For example, in the distributed electronic and electrical architecture of intelligent connected vehicles, communication nodes include, but are not limited to, intelligent driving domain controllers, cockpit domain controllers, chassis domain controllers, etc. Each domain controller can select to deploy a first protection strategy and / or a second protection strategy according to its own functional role, and execute them independently and in parallel during runtime to improve the functional safety diagnostic coverage and the communication function safety protection effect.

[0074] Figure 1 This is a flowchart illustrating a communication function security protection method provided in an embodiment of this application. Figure 1 As shown, the communication function security protection method provided in this application embodiment may include:

[0075] S101. When the communication cycle of a communication node is adjusted to be greater than the preset original cycle, at least one of the following protection strategies shall be executed.

[0076] For example, in this embodiment, a communication node refers to an entity in the vehicular network capable of performing at least one of the following functions: message sending, message receiving, message forwarding, control decision-making, or control command outreach. Specifically, it can be a domain controller (driving domain, cockpit domain, chassis domain, etc.), a sub-controller, an actuator control unit, or a gateway node responsible for relaying messages. The communication cycle refers to the time interval between two adjacent message interactions (including message forwarding and control command outreach), typically measured in milliseconds. The original cycle is a baseline cycle preset for the communication node during the system design phase based on real-time functional requirements. It represents the standard transmission cycle of the node under normal load conditions, and this parameter can be pre-stored in non-volatile memory or a system configuration table.

[0077] This step defines the activation conditions of the protection strategy in this application. Specifically, the protection strategy is not used continuously throughout the entire communication process. Instead, it is triggered only when an amplification of the communication cycle relative to the original cycle is detected, thereby distinguishing between regular communication under a fixed cycle and dynamic communication scenarios under a dynamic cycle. The reason for this design is that existing fixed-window verification and direct outgoing control schemes typically meet functional safety requirements under standard cycle times. However, when the cycle is lengthened, the message arrival pattern, counting progression relationship, and control command change trajectory all change. Therefore, functional safety enhancement processing can be performed only in a targeted manner.

[0078] In practice, the specific execution entity can be a security monitoring module, task scheduling module, or independent functional safety management unit within the communication node. A pre-established original cycle parameter table is created in the system. This table can be written to non-volatile memory during vehicle calibration or distributed to each node by the upper-level controller during initialization. In actual operation, due to factors such as increased processor load, bus congestion, cross-domain forwarding waits, or task priority adjustments, the actual communication cycle of the communication node may be dynamically lengthened, becoming longer than the original cycle. This step requires monitoring changes in the communication cycle. Once it is detected that the communication cycle has been adjusted to be longer than the original cycle due to changes in operating status, subsequent protection strategies are triggered. For example, if the communication cycle is a predictable, fixed change according to preset rules, the monitoring method can be to directly read the current communication cycle and / or scaling factor N from the local configuration parameter table, routing table, or non-volatile memory. However, if the communication cycle is an unpredictable, dynamic change according to changes in operating status, the monitoring method can be that the security monitoring module records the actual arrival time or actual transmission time of adjacent messages through hardware timers, operating system tick counters, or bus message timestamps, and obtains the current communication cycle through a sliding window statistical method. For instance, when the actual communication cycle in multiple consecutive statistical windows is greater than the original cycle and exceeds a set threshold, it can be determined that the communication node has entered a cycle amplification state. This threshold can be set to 1.1 times, 1.2 times, or other proportions defined according to the task tolerance to filter out false triggers caused by instantaneous jitter.

[0079] Furthermore, to ensure the feasibility of the triggering logic, the system can identify the source of changes in operating status. Sources include processor utilization exceeding a preset threshold, bus utilization exceeding a preset threshold, increased buffer queuing depth, scheduled task timeouts, and increased cross-domain message forwarding time. After detecting the above source information, the system does not directly use the source itself as the trigger condition, but rather confirms it by comparing the communication cycle with the original cycle. That is, only when the source change ultimately manifests as a communication cycle greater than the original cycle is it determined that the protection process needs to be initiated. This approach avoids frequent switching of protection logic due to misjudgments based solely on resource status. For example, after the forward sensing node identifies an obstacle, it needs to send braking control commands to the chassis domain actuator via the decision node. When the decision node extends the message output cycle from 10ms to 20ms or 15ms due to load pressure, the system can detect the amplification of the communication cycle relative to the original cycle and subsequently trigger subsequent protection.

[0080] When it is determined that the current communication cycle of a communication node has been adjusted to a period longer than the preset original cycle due to changes in operating status, the system can execute the first protection strategy, the second protection strategy, or both simultaneously, depending on the functional role of the communication node in the architecture. If the node is responsible for message forwarding (e.g., cross-domain routing for a gateway or central domain controller), the first protection strategy is executed; if the node is responsible for sending control commands (e.g., the intelligent driving domain controller sending torque commands to the actuator), the second protection strategy is executed; if the node has both roles, the two strategies can be executed in parallel.

[0081] This step strictly binds the protection activation to the objective condition of communication cycle amplification, so that the protection logic matches the actual dynamic communication scenario. This avoids introducing unnecessary processing overhead under normal fixed cycles, and can promptly enter the adaptation mechanism when cycle changes cause the fixed cycle assumption to fail, thus providing accurate preconditions for forwarding message verification and smooth reconstruction of control values.

[0082] S102. First protection strategy: Determine the extended counting verification window based on the scaling factor N of the communication cycle, and perform counting verification on the forwarded messages between communication nodes based on the extended counting verification window; where N is a rational number greater than 1.

[0083] For example, the first protection strategy addresses the message count verification failure caused by prolonged communication cycles. For instance, it can be used in scenarios involving message forwarding between domains or nodes. When the source domain sends messages with a shorter cycle, and the communication cycle of the receiving or forwarding node is prolonged, the jump in the message count (Counter) received by the receiving end will be greater than the preset step window in standard E2E (End-to-End) protection, causing normal cycle scaling to be misjudged as message loss or out-of-order delivery. This step solves this problem by introducing an extended count verification window adapted to the scaling factor N.

[0084] The scaling factor N quantifies the amplification ratio of the current communication cycle relative to the original cycle, i.e., N = current communication cycle / original cycle. N is a rational number greater than 1, meaning it can be an integer (e.g., 2, 3, 4), a half-integer (e.g., 1.5, 2.5), or other rational numbers (e.g., 1.33, 1.6, etc.). In practical implementation, N is usually a parameter pre-configured during the system design phase based on the cycle mapping relationship between the source and target domains in the communication matrix, and stored in the routing table or configuration file. At runtime, the system directly reads the N value from the configuration without real-time calculation, ensuring the determinism and verifiability of the functional safety mechanism. As an optional implementation, the scaling factor N can also be obtained by dynamically measuring the ratio of the current cycle to the original cycle by the node and then rationalizing it. To ensure the determinism of the functional safety mechanism, it is preferable to pre-configure the N value and supplement it with measurement verification at runtime.

[0085] Unlike the fixed-width window used in traditional E2E protection (e.g., allowing counter step values ​​of 1 to 4), the extended count verification window in this application is a dynamically changing allowed step range, and it is a new window independent of the traditional fixed-period E2E verification window. Its size and shape are related to the scaling factor N, rather than simply expanding the original window. When using the extended count verification window, the original fixed window is no longer used for verification; instead, the extended window is used entirely as the criterion for judging the validity of the count. For example, when N is 2, the allowed step value can be set in an interval around 2; when N is 1.5, the allowed step value may alternate between 1 and 2, so the window needs to cover multiple candidate values. By associating the verification window with N, "large jumps" that would otherwise occur due to the extended period can be considered valid, while abnormal steps caused by actual message loss, duplication, or out-of-order delivery are captured.

[0086] Forwarded messages are information carriers transmitted between communication nodes along in-vehicle Ethernet, CAN (Controller Area Network) bus, or other in-vehicle links. They typically carry a cycle count, a checksum field, and payload data. The count checksum is used to determine whether the count value carried by the forwarded message falls within the allowable range, thereby identifying problems such as message loss, duplication, out-of-order delivery, abnormal delays, or abnormal insertions.

[0087] When implementing the first protection strategy, a typical process might be as follows: First, determine the value of N, and then construct an extended count verification window based on N. The window construction rules can be flexibly designed based on the integer or non-integer characteristics of N, as long as the window can accommodate legitimate transitions caused by the extended period, while maintaining sensitivity to abnormal transitions. Next, the receiving node extracts the count value from the forwarded message and performs differential comparison with the window. To improve the completeness of the diagnosis, the count verification can also be combined with CRC verification and timeout verification. Only when all verifications pass is the message considered valid; otherwise, fault handling is triggered.

[0088] The first protection strategy introduces an extended counting verification window linked to the scaling factor N, enabling the traditional E2E mechanism, which was originally based on a fixed period assumption, to adaptively adapt to the communication patterns after the period is lengthened. On the one hand, large jumps in the count value caused by the amplified period will not be misjudged as message loss or out-of-order delivery, reducing the probability of false alarms and functional degradation. On the other hand, abnormal steps caused by genuine message duplication, missing, or out-of-order delivery can still be effectively detected, thus maintaining a high functional safety diagnostic coverage.

[0089] S103, Second protection strategy: Based on the original demand value and actual feedback value of historical sampling points, the control value in the control command to be sent out by the communication node is smoothly reconstructed.

[0090] For example, the second protection strategy addresses the problem that the extended task cycle of the communication node itself leads to a stepped distribution of outgoing control commands, preventing the actuator's safety mechanisms from being triggered. For instance, it can be used in scenarios where the communication node itself generates and sends outgoing control commands. When the node's internal task cycle is extended due to reduced load, the outgoing control commands will exhibit a sparse, stepped distribution on the timeline, causing safety mechanisms such as incremental change threshold monitoring at the receiving end (actuator) to fail to trigger due to the "diluting" of changes in adjacent commands. This step restores the continuous change characteristics of the commands by performing a smooth reconstruction of the control values ​​at the sending end based on historical trends, ensuring that the actuator-level safety fallback mechanism can be activated normally.

[0091] Historical sampling points refer to data points recorded over several past communication cycles. Each sampling point contains at least three pieces of information: the sampling time, the original demand value, and the actual feedback value. These sampling points are typically stored in a circular buffer, the number of which can be preset according to the dynamic characteristics of the controlled object (e.g., 5, 10, or more). The original demand value refers to the ideal control quantity calculated by the decision-making or planning algorithm within the communication node based on the current perceived information and the target strategy, such as the desired braking pressure, desired steering angle, or desired drive torque. The original demand value reflects the upper-level control intent. The actual feedback value refers to the actual physical quantity corresponding to the original demand value, fed back from the actuator or sensor, such as the measured braking pressure, actual wheel speed, or actual acceleration. The actual feedback value reflects the execution effect of the control command and the actual response of the vehicle or actuator.

[0092] The control command to be sent refers to the message that the communication node will send to downstream actuators (such as brake actuators, steering motors, and drive motors) through the vehicle network. Its core data segment contains one or more control values. Smooth reconfiguration refers to not directly using the current demand value as the control value, but instead using the sequence of original demand values ​​and the sequence of actual feedback values ​​from historical sampling points, and generating a new, time-continuous, and gradually changing control value through mathematical methods (such as curve fitting, filtering, interpolation, or weighted averaging). The goal of smooth reconfiguration is to ensure that even when the communication cycle is lengthened, the sent control command still exhibits a gradual change trajectory similar to that under the original cycle, avoiding sudden jumps after remaining constant for a long time.

[0093] In specific implementation, after S101 identifies the amplified communication cycle, if the current communication node undertakes the function of sending control commands, the control value reconstruction process begins. An exemplary control value reconstruction process can be as follows: Multiple historical sampling points (the number can be set according to the dynamic characteristics of the controlled object, such as the most recent 5 or 10) prior to the current moment are obtained from a buffer, circular queue, or local database. These points are then preprocessed, including time alignment, missing value compensation (such as nearest neighbor completion, linear interpolation, or maintaining the last valid value), and outlier removal (such as threshold determination, median filtering, or slope constraints). Subsequently, curve fitting is performed on the original demand value and the actual feedback value (using linear, low-order polynomial, spline, or exponential smoothing models, depending on the controlled object's requirements for response speed or smoothness), to obtain the fitted value at the current sending moment. Finally, reconstructed control values ​​are generated based on the current operating state (such as vehicle speed, attachment conditions, actuator delay, task load, or control mode). A typical approach is to weight and fuse the demand fitted value and the feedback fitted value, where the weights can be fixed coefficients or dynamically adjusted. In addition, other implementation methods can be used. For example, based on the most recent K historical sampling points, the error sequence between the original demand value and the actual feedback value can be calculated, and then a filtering algorithm (such as exponentially weighted moving average, Kalman filtering, or polynomial fitting) can be used to predict the optimal control output value for the current cycle. The smoothed value can then be sent to the actuator as the final control command. Alternatively, the original demand value can be rate-limited. Based on the rate of change of the actual feedback value in the historical sampling points, the maximum increment or decrement of the current control command relative to the previous command can be limited to avoid command jumps. The embodiments of this application do not impose any limitations.

[0094] The second protection strategy involves smoothly reconstructing the control values ​​at the transmitting end based on historical trends. This ensures that even with a longer communication cycle, outgoing commands maintain temporal continuity and gradual change. Consequently, safety mechanisms configured at the actuator end, such as incremental change threshold monitoring and change rate monitoring, can detect every command change as normally as in the original cycle, thus avoiding the defect of "safety mechanisms never triggering" caused by the stepped distribution of commands. Ultimately, the actuator-level fallback protection capability is restored, and the overall vehicle's functional safety and reliability are significantly enhanced.

[0095] In practical applications, the first and second protection strategies can be executed individually or simultaneously. For example, when the communication cycle doubles due to excessive load, the system can simultaneously enable the extended count verification window (to prevent message security vulnerabilities) and the smooth reconstruction of control values ​​(to prevent sudden changes in control commands). The two strategies do not conflict with each other and each addresses different dimensions of functional safety issues—the former focuses on the integrity / authenticity of the communication content, while the latter focuses on the smoothness / stability of the control output. Therefore, the technical solution provided in this embodiment can comprehensively improve the functional safety of communication nodes under non-ideal cycle conditions.

[0096] Based on the above analysis, the communication function safety protection method provided in this application takes the amplified identification of the communication cycle as the premise for protection triggering, and establishes protection processing mechanisms adapted to dynamic cycle scenarios around the message forwarding link and the control outgoing link respectively. This enables the system to effectively count and verify forwarded messages without relying on the assumption of a fixed communication cycle, and maintains the outgoing control value with identifiable continuous change characteristics. This improves the ability to identify anomalies under dynamic communication cycle conditions, reduces the probability of misjudging normal messages, enhances the triggerability of the actuator-level safety mechanism, and ultimately improves the communication function safety protection effect in the distributed electronic and electrical architecture of intelligent connected vehicles.

[0097] Next, the execution process of the first protection strategy and the second protection strategy will be explained in detail.

[0098] For example, Figure 2 This is a flowchart illustrating the execution of a first protection strategy, provided as an embodiment of this application. The flowchart details how a communication node selects different processing paths based on the actual state of the communication cycle when functional safety protection of forwarded messages is required. Figure 2 As shown, the process of implementing the first protection strategy may include the following steps:

[0099] S201. Determine whether the current communication cycle has been adjusted to be greater than the preset original cycle.

[0100] If yes, proceed to step S202; otherwise, proceed to step S203.

[0101] For example, this step is the trigger judgment of the first protection strategy, the purpose of which is to distinguish whether the current communication scenario belongs to the state of extended cycle, and its implementation method is the same as Figure 1 S101 is the same in the embodiment and will not be described again here. In actual implementation, it can be set that if the current period is continuously greater than the original period and exceeds the preset tolerance (e.g., 1.05 times), it is determined as "yes" and proceeds to step S202; otherwise, it is "no" and proceeds to step S203.

[0102] By using conditional branching design, extended count verification is triggered only when the period is actually lengthened, which avoids introducing unnecessary verification overhead under normal periods and ensures that the system can still operate efficiently with standard end-to-end security mechanisms under normal conditions.

[0103] S202. Determine the extended count verification window based on the scaling factor N of the communication cycle.

[0104] For example, when the judgment result of S201 is "yes", that is, the communication period has been lengthened, this step is executed. The core of this step is to construct a dynamic counting verification window that adapts to the current period amplification ratio based on the scaling factor N.

[0105] Optionally, in one possible embodiment, determining the extended count verification window based on the scaling factor N of the communication period may include: if N is an integer, the extended count verification window contains three count values: N-1, N, and N+1; if N is not an integer, the extended count verification window contains four count values: M-1, M, M+1, and M+2, where M is an integer rounded down from N.

[0106] For example, if the original period is 10ms and the current forwarding period becomes 20ms, then N=2, and the window size is 1, 2, or 3. This means that the receiver allows the count difference between two adjacent valid messages to be 1, 2, or 3. For instance, when N=1.5, M=1, and the window size is 0, 1, 2, or 3; when N=2.5, M=2, and the window size is 1, 2, 3, or 4. A four-value window is used in non-integer scenarios because non-integer scaling causes the message arrival phase to alternate across multiple periods, requiring a larger tolerance range. Understandably, non-integers include half-integers (such as 1.5, 2.5, 3.5, etc.) and other rational numbers greater than 1 (such as 1.33, 2.75, etc.). For half-integers and other rational numbers greater than 1, an extended count check window containing four count values—M-1, M, M+1, and M+2—can be used for verification. In addition, for other rational numbers greater than 1, multiple receiving cycles can be combined into a macro cycle, and an allowed counting difference sequence can be derived within the macro cycle, or N can be approximated as the nearest integer or half-integer for processing. This application does not impose any restrictions.

[0107] For example, after detecting that the communication period has been magnified by a factor, the communication node first obtains the scaling factor N corresponding to the current period and matches N with preset integer and non-integer judgment conditions. When N is determined to be an integer, the controller generates a three-value count set centered on N, namely N-1, N, and N+1, and writes this set into the cache unit of the message verification module for subsequent comparison of the count field of forwarded messages. When N is determined to be a non-integer, the controller first performs a floor operation on N to obtain M, and then generates four count values: M-1, M, M+1, and M+2, which are used as the extended count verification window input to the count verification logic. To avoid count values ​​going out of bounds, the counting module can also combine the maximum allowed count value to truncate or remap the values ​​in the window, thereby ensuring that each count value is within the usable range. In practical applications, this count verification window can be generated by software inside the domain controller or implemented by a hardware count comparison unit; this embodiment does not limit this.

[0108] This alternative approach constructs different counting windows for both integer and non-integer scaling scenarios, ensuring that forwarded messages can still be correctly identified and verified after periodic changes, avoiding misjudgments caused by the fixed window assumption. Since the window range corresponds to the periodic scaling factor, acceptable counting coverage is maintained even when messages are duplicated, lost, or arrive at an offset, thereby improving the accuracy of functional safety diagnostics under dynamic communication conditions and enhancing the stability of cross-domain forwarding links.

[0109] S203. Execute the preset end-to-end communication function security diagnostic mechanism.

[0110] For example, when the judgment result of S201 is "no", that is, the current communication period is not greater than (i.e. less than or equal to) the original period, it indicates that the communication is in a normal fixed period state and there is no need to use extended window verification. At this time, the communication node executes the preset end-to-end communication function safety diagnosis mechanism.

[0111] Optionally, the pre-defined end-to-end communication functional safety diagnostic mechanism can be a communication protection scheme implemented based on E2E standards or other equivalent specifications. It typically includes: counter continuity verification (expected step size of 1, allowing for small deviations), CRC verification (verifying data integrity), timeout verification (ensuring messages arrive within the time limit), and DataID verification. This mechanism can detect common communication faults such as message duplication, loss, delay, insertion, and corruption, meeting functional safety requirements up to ASIL D level.

[0112] Under normal cycle conditions, the standard E2E mechanism provides sufficient protection, thus eliminating the need for enhanced extended window verification and avoiding unnecessary processing overhead. The system performs verification on each forwarded message in the usual manner and decides whether to allow the message to proceed or trigger fault handling based on the verification results.

[0113] S204. Based on the extended counting verification window, perform counting verification on the forwarded messages between communication nodes.

[0114] For example, after the extended count verification window has been determined in S202, this step actually performs the count verification operation. The specific process can be as follows: Extract the count value (Counter) from the received forwarded message. This count value is usually incremented by the sender with each transmission (step size of 1) and cyclically using a modulo operation (e.g., a 4-bit counter modulo 16). Obtain the count value of the last valid message that passed verification (denoted as Ctr_last). If the current message is the first received message, Ctr_last is initialized to the first received count value. Calculate the difference between the current count value and Ctr_last, considering modulo operation: Δ = (Ctr_cur - Ctr_last) mod M, where M is the modulo value of the counter (e.g., 16, 256, etc.). Determine whether Δ belongs to the extended count verification window determined in S202. If it does, the count is considered normal, Ctr_last = Ctr_cur is updated, and the message is passed to the upper-layer application or forwarded again; if it does not, the count is considered abnormal, and a fault event is recorded (e.g., setting a security diagnostic flag, incrementing an error counter, triggering an interrupt, etc.).

[0115] Optionally, in one possible embodiment, performing count verification on forwarded messages between communication nodes based on an extended count verification window may include:

[0116] Extract the count value carried in the forwarded message. If the count value carried in the forwarded message does not belong to the count value in the extended count verification window, the count is considered abnormal.

[0117] For example, the count value is a count field in the forwarded message message, typically encoded with a fixed bit width, used to characterize the message sending order. The extended count check window is used to limit the range of counts that are allowed to pass the check under the condition of communication cycle amplification. It can be pre-set with one or more allowed count values ​​corresponding to the current forwarding cycle to adapt to the order determination after the message arrival interval changes.

[0118] In practical implementation, after receiving a forwarded message, the communication node first parses the message and extracts the count field, then compares the count value with the currently valid extended count verification window. If the extracted count value matches any allowed count value within the window, the forwarded message is deemed to have passed the count verification; if the count value does not match any allowed count value within the window, a count anomaly flag is output, and further anomaly handling such as frame loss, out-of-order delivery, or excessive delay can be triggered. To improve recognition stability, the count value can be encoded using a cyclic increment method, and the allowed count values ​​within the window can be configured according to the discrete beats after the message period is extended, thus ensuring that normal forwarded messages can still be accurately identified after periodic changes.

[0119] Taking a practical application as an example, suppose the source domain sends E2E messages at a period of 10ms, and the forwarding node adjusts the forwarding period to 20ms (N=2) due to increased load. In traditional E2E verification, the receiver expects the count values ​​of adjacent messages to differ by 1, but the actual count values ​​of two received messages may differ by 2, leading to a misjudgment of "message loss". However, after adopting the extended window (1,2,3) in this step, a difference of 2 is considered valid, and the message is forwarded normally; at the same time, if a message is indeed lost (for example, the count value jumps from 5 to 9, with a difference of 4), then 4 is not within the window, and the system can correctly detect the loss fault. Based on this, both communication continuity in the period amplification scenario and the ability to detect real anomalies are maintained.

[0120] This optional approach replaces the fixed-step counting range with an extended counting verification window, enabling the receiving node to perform consistency checks based on the count value even when the communication cycle changes. Since messages with count values ​​outside the window are directly marked as abnormal, transmission anomalies can be identified as early as possible before the message enters the subsequent control link. This approach improves the comprehensive verification capability of forwarded messages between communication nodes, reduces the probability of false positives under amplified communication cycle conditions, and enhances the detection of message loss, duplication, out-of-order delivery, and delay anomalies, thereby improving the functional safety assurance level of the vehicle's distributed communication link.

[0121] Optionally, in one possible embodiment, based on the foregoing embodiments, the method of this embodiment may further include: when N is an integer and N+1 reaches or exceeds the maximum allowed count value of forwarded messages, or when N is a non-integer and M+2 reaches or exceeds the maximum allowed count value of forwarded messages, re-perform the count verification according to a preset counting step size. The re-perform count verification includes: using the current count value as a reference, determining a new expected count value range according to the preset counting step size, and determining whether the count value of subsequently received forwarded messages falls within the new expected count value range.

[0122] For example, the maximum allowed count value for forwarding messages is used to limit the effective upper bound of the counting window in the high-count segment, and the preset counting step size is used to re-divide the counting judgment boundary when the count value approaches the upper bound, so that the re-obtained judgment interval can still cover the count changes of subsequent forwarding messages.

[0123] In the specific implementation, the count value carried in the forwarded message is synchronously written by the communication node when sending or forwarding. After the receiving communication node completes the count extraction, it compares the current count value with the extended count verification window. When N is an integer, if N+1 has reached or exceeded the maximum allowed count value, the original window is no longer used for direct judgment. Instead, the counting range is re-divided according to the preset counting step size, and the subsequent count values ​​are verified again using the re-divided counting boundary. When N is not an integer, if M+2 has reached or exceeded the maximum allowed count value, the counting judgment interval is also re-established based on the preset counting step size to avoid counting distortion caused by the upper bound of the window exceeding the limit. The preset counting step size can be given in advance by the vehicle communication configuration parameters, or it can be set according to the message period, the upper bound of the count, and the forwarding frequency. In practical applications, this parameter can also be adjusted according to different bus types and message loads. This embodiment does not limit this.

[0124] Through the above processing, when the count value approaches the maximum allowable count value, the system can automatically switch to the redefined counting judgment method, thereby maintaining the ability to continuously verify forwarded messages even when the communication cycle is amplified or the counting window changes critically. This processing method frees the counting judgment from the limitations of the original fixed window, avoiding misjudgments and omissions caused by high count segments exceeding the limit, and improving the stability of message verification in dynamic communication scenarios.

[0125] The first protection strategy provided in this embodiment first determines whether the communication period is greater than the original period, and then processes the normal period state and the period lengthening state separately: when the period is normal, the standard end-to-end communication diagnostic mechanism is reused to avoid unnecessary computational overhead, while when the period is lengthened, an extended counting verification window is dynamically constructed according to the scaling factor N to perform counting verification, so that the forwarding node can adaptively tolerate the jump of the legitimate count value caused by the period amplification, while maintaining high sensitivity to anomalies such as loss, duplication, and out-of-order delivery of real messages. Thus, without increasing the processing burden under a fixed period, the functional safety diagnostic coverage of forwarded messages and the reliability of system communication are effectively improved in scenarios with dynamic changes in the period.

[0126] Optionally, in Figure 2 Based on its optional embodiments, in one possible embodiment, the execution flow of the first protection strategy may further include:

[0127] S01. Perform cyclic redundancy check (CRC) and / or timeout check on the forwarded message;

[0128] S02. If any of the following occurs continuously within the preset fault tolerance time interval: count error, CRC check failure, or check timeout, it is considered an abnormal message forwarding communication.

[0129] For example, Cyclic Redundancy Check (CRC) is used to check the integrity of the content of forwarded messages. Typically, a check field is generated at the message sender according to a preset polynomial, and at the receiver, the CRC value of the same forwarded message is recalculated and compared with the carried check field to determine whether bit flipping, field tampering, or link disturbances have occurred during transmission or forwarding. Timeout check is used to determine whether the forwarded message arrives at the receiving node within the expected time limit. It typically combines the message sending timestamp, receiving timestamp, and a preset allowable delay for comparison to identify message delays, loss, or abnormal arrivals caused by bus congestion. A preset fault tolerance time interval is used to suppress misjudgments of single transient fluctuations, preventing occasional single-frame anomalies from directly escalating into communication failures. Within this time interval, if any of the following occurs consecutively: count anomaly, CRC check failure, or check timeout, it indicates that the anomaly is not occasional but persistent and repetitive. Forwarded message communication anomalies refer to a persistent failure state in terms of count consistency, content integrity, or timeliness of the forwarding link. Once this state is confirmed, the system can further trigger alarms, degradation control, or switch to a backup communication link.

[0130] In this embodiment, forwarded messages can be forwarded by domain controllers, intermediate gateways, or actuator front-end nodes in the vehicle Ethernet or CAN link. CRC checks and timeout checks can be performed in the software tasks of the receiving node, or they can be performed collaboratively by the communication controller hardware and interrupt service routines. The CRC field can use common 8-bit, 16-bit, or 32-bit check lengths. The selected length matches the message load, link bandwidth, and fault detection requirements. In practical applications, other specifications can also be selected for the check length, and this embodiment does not limit this. The timeout threshold can be set based on the baseline transmission period of the forwarded message, the link round-trip time, and the system scheduling margin, and can be updated collaboratively with the counting anomaly detection window to adapt to scenarios with amplified communication periods. Thus, when counting anomalies, CRC failures, and timeouts continue to occur within a preset fault tolerance time interval, multi-dimensional cross-validation of the same anomaly source can be formed, thereby improving the reliability of identifying communication anomalies in forwarded messages.

[0131] By adopting the above method, not only can sequence number mismatches in forwarded messages be identified, but it can also simultaneously cover two typical fault modes: message content corruption and timeliness mismatch. Furthermore, it filters out false alarms caused by occasional jitter through continuous judgment. Since anomaly identification is based on a joint judgment of counting, integrity, and timeliness, the coverage of communication anomaly detection for forwarded messages is more comprehensive, and the functional safety diagnostic results are more stable, providing a reliable basis for subsequent degradation control, link switching, and fault logging.

[0132] For example, Figure 3This is a flowchart illustrating the execution of a second protection strategy, provided as an embodiment of this application. The flowchart details how a communication node, when needing to send out control commands, selects between conventional diagnostics and smooth reconfiguration based on the actual state of the communication cycle to address the problem of actuator safety mechanisms failing due to prolonged cycles. Figure 3 As shown, the process of implementing the second protection strategy may include the following steps:

[0133] S301. Determine whether the current communication cycle has been adjusted to be greater than the preset original cycle.

[0134] If yes, proceed to step S302; otherwise, proceed to step S306.

[0135] For example, this step is similar to Figure 2 Similar to S201, this is the trigger judgment for the second protection strategy. The communication node monitors its own task outgoing cycle (i.e., the interval between sending control commands) and compares it with the preset original cycle. If it detects that the current communication cycle is continuously longer than the original cycle (e.g., multiple consecutive sending windows exceed the tolerance threshold), it is judged as "yes" and enters the smooth reconstruction branch S302; otherwise, it is judged as "no" and enters the regular diagnostic branch S306. This judgment ensures that the computationally intensive smooth reconstruction is only activated when the cycle is lengthened, while a lightweight standard protection mechanism is used under normal cycle conditions.

[0136] S302. Obtain multiple historical sampling points prior to the current time; where each historical sampling point includes the original demand value and the actual feedback value at the corresponding sampling time.

[0137] For example, once it is confirmed that the communication cycle has been extended, the communication node first acquires historical data for reconstruction. Historical sampling points refer to data entries recorded over several past control cycles. Each sampling point contains at least three basic elements: the sampling time, the original demand value, and the actual feedback value. The original demand value is the desired control quantity calculated by the upper-level algorithm (such as the planning, decision-making, or control module) within the communication node based on the current perceived information and the target strategy. Examples include the desired braking pressure, desired steering angle, or desired drive torque. This value reflects the control objective the system hopes to achieve at the current moment. The actual feedback value is the actual physical quantity corresponding to the sampling time, fed back from the actuator or sensor. Examples include measured braking pressure, actual wheel speed, or actual acceleration. This value reflects the execution effect of the control command and the true response state of the vehicle or actuator.

[0138] Historical sampling points are typically stored in memory as a circular queue, with the queue length preset according to the dynamic characteristics of the controlled object (e.g., storing the most recent 5, 8, or 10 sampling points). In the initial stage of system startup, if the number of historical sampling points is insufficient, a direct outbound strategy (i.e., directly using the current original demand value) can be executed first, and this process can begin once sufficient data has been accumulated.

[0139] S303. Perform curve fitting on the original demand values ​​from multiple historical sampling points to obtain the original demand fitted values.

[0140] For example, this step utilizes mathematical fitting methods to extract trends from the historical raw demand value sequence. The goal of curve fitting is to find a function curve that best approximates the historical demand data points, thereby inferring the reasonable demand value to be adopted at the current moment (i.e., the moment of outflow). Commonly used fitting methods include linear regression (suitable for approximately uniform demand changes), quadratic or higher-order polynomial fitting (suitable for accelerating or decelerating trends), spline interpolation (suitable for complex nonlinear changes), and exponential smoothing (suitable for noisy time series). The fitting algorithm itself can employ conventional numerical methods such as least squares, and this application embodiment does not impose any limitations.

[0141] The fitted value of the original demand is a scalar that represents the control intent at the current moment predicted based on historical demand evolution patterns. Compared to directly using the original demand value at the current moment, the fitted value can filter out short-term noise and instantaneous jumps, making the control command smoother.

[0142] S304. Perform curve fitting on the actual feedback values ​​from multiple historical sampling points to obtain the actual feedback fitted values.

[0143] For example, this step is similar to S303, and a mathematical fitting method can be used to fit the historical actual feedback value sequence. The actual feedback value reflects the true response dynamics of the actuator. By fitting it, an estimate of the state that the system should actually reach at the current moment can be obtained, i.e., the actual feedback fitting value. This value can compensate for deviations caused by physical characteristics such as actuator delay and response hysteresis.

[0144] Typically, the original demand value and the actual feedback value are aligned in time, meaning they correspond to the same sampling time or within the same control loop period. By fitting the two sequences separately, we can obtain the "desired trend" and the "actual response trend," providing two independent references for subsequent fusion.

[0145] S305. Based on the original demand fitting value and the actual feedback fitting value, determine the control value in the control command to be sent out by the communication node.

[0146] For example, based on the fitted original demand value and the fitted actual feedback value, the communication node can generate the control value in the control command to be sent out by combining the deviation relationship between the two, so that the output result remains continuous in time and avoids discrete jumps. In one implementation, the communication node can use the fitted original demand value as the target trend component and the fitted actual feedback value as the response correction component, and then determine the control value according to the difference, proportional relationship, or weighted fusion relationship between the two. With this method, the control value can reflect both the changing direction of the current demand side and the true response state of the execution side, so that the control command to be sent out is more in line with the closed-loop characteristics in the vehicle control link. In practical applications, the determination of the control value can also be combined with amplitude limiting, slope constraint, or smoothing filtering to further suppress fluctuations caused by instantaneous noise, which is not limited in this embodiment.

[0147] In this embodiment, the demand trend and feedback trend are reconstructed using historical sampling points prior to the current moment, and the output control value is determined based on the two trend curves, thereby converting discrete sampling data into a continuous and smooth control output. Since both the original demand value and the actual feedback value are involved in the fitting process, the control commands to be sent by the communication node not only retain the control intent but also take into account the actual system response. Therefore, the probability of control value abrupt changes is reduced, and the output is more suitable for subsequent actuator safety judgments and continuity detection. With this implementation, the control values ​​in the control commands to be sent by the communication node can be smoothly reconstructed based on historical change patterns, reducing the impact of single sampling fluctuations on the output results, improving the continuity and recognizability of control commands, enhancing the actuator-level safety mechanism's ability to detect control changes, and reducing the risk of false triggering or missed triggering due to discrete jumps.

[0148] Optionally, in one possible embodiment, determining the control value in the control command to be sent out by the communication node based on the original demand fitting value and the actual feedback fitting value may include:

[0149] S1. Obtain the vehicle's current speed;

[0150] S2. Based on the current vehicle speed, determine the weights of the original demand fitting value and the actual feedback fitting value;

[0151] S3. Based on the weights of the original demand fitting value and the actual feedback fitting value, perform a weighted summation on the original demand fitting value and the actual feedback fitting value to obtain the weighted summation value.

[0152] S4. Determine the control value in the control command to be sent out by the communication node based on the weighted sum value.

[0153] For example, the vehicle's current speed is used to characterize the vehicle's operating condition and serves as the basis for adjusting the weight allocation of the two types of fitted values. The original demand fitted value is used to characterize the smoothing result on the control demand side, the actual feedback fitted value is used to characterize the smoothing result on the execution feedback side, the weights are used to describe the relative influence of the two in the composition of the control value, and the weighted sum is used to represent the synthesized result calculated according to the weights.

[0154] In practical implementation, the vehicle's current speed can be obtained from a vehicle speed sensor, wheel speed signal, or vehicle status bus, and filtered by a sampling module within the communication node to eliminate the impact of instantaneous jitter on weight allocation. After receiving the original demand value and actual feedback value from historical sampling points, the communication node can first perform curve fitting on both to obtain smooth and continuous original demand fitting values ​​and actual feedback fitting values, and then set corresponding weights based on the current vehicle speed. The weights can be obtained through table lookup, piecewise function, or continuous mapping function, and can satisfy the constraint that the sum of the two is a preset constant, thereby facilitating weighted summation. This application embodiment does not impose any limitations.

[0155] Optionally, in one possible embodiment, S2, determining the weights of the original demand fitting value and the actual feedback fitting value based on the current vehicle speed includes:

[0156] S21. If the current vehicle speed is less than the first threshold, the weight of the original demand fitting value is lower than the weight of the actual feedback fitting value.

[0157] S22. If the current vehicle speed is greater than the second threshold, the weight of the original demand fitting value is higher than the weight of the actual feedback fitting value.

[0158] S23. If the current vehicle speed is greater than or equal to the first threshold and less than or equal to the second threshold, then the weight of the original demand fitting value is equal to the weight of the actual feedback fitting value.

[0159] For example, in this embodiment, the first threshold is used to divide the low-speed range, and the second threshold is used to divide the high-speed range. Together, they constitute the weight switching boundary. In specific implementation, the communication node can compare the current vehicle speed with the first and second thresholds. When the current vehicle speed is less than the first threshold, a conservative weight configuration is adopted, where the weight coefficient combination that makes the proportion of the original demand fitting value lower than the proportion of the actual feedback fitting value is used, emphasizing the actual feedback fitting value to enhance stability, so that the control value reflects the actual response formed by the vehicle more. When the current vehicle speed is greater than the second threshold, a more aggressive weight strategy is adopted, where the weight coefficient combination that makes the proportion of the original demand fitting value higher than the proportion of the actual feedback fitting value is used, emphasizing the original demand fitting value to improve response speed, and also making the control value follow the changes in driving intention more promptly. When the current vehicle speed is between the two thresholds, a balanced weight scheme is adopted, that is, an equal weight coefficient combination is used, so that the control value takes into account both demand trend and feedback trend. The weight coefficients can be pre-stored in a calibration table, or they can be obtained by the controller through online mapping according to the vehicle speed range. In practical applications, the weight coefficients can also be configured in other ways, which are not limited in this embodiment.

[0160] This weighting method ensures more stable output in low-speed scenarios, more sensitive response in high-speed scenarios, and a balanced output in intermediate speed ranges. This allows the weighted result of the original demand fitting value and the actual feedback fitting value to adapt to different operating states, further improving the continuity and recognizability of outgoing control commands. Consequently, the actuator level can more easily perform consistency checks and safety judgments based on this control value, reducing the risk of false triggering due to sudden changes in control values ​​or response lags, and enhancing the adaptability of communication function safety protection under dynamic speed conditions.

[0161] Furthermore, after the communication node obtains the two types of weights, the original demand fitting value and the actual feedback fitting value are multiplied by their respective weights and then weighted and synthesized to form a weighted sum. Based on this weighted sum, the control value in the control command to be sent out by the communication node can be determined.

[0162] Optionally, in one possible embodiment, S4, determining the control value in the control command to be sent out by the communication node based on the weighted sum value, may include:

[0163] S41. Determine the weighted sum value as the control value in the control command to be sent out by the communication node;

[0164] Alternatively, S42, based on the rate of change of the weighted summation value relative to the control value sent out at the previous sampling time, the weighted summation value is subjected to amplitude limiting processing to obtain the amplitude limiting processing result; and the weighted summation value is subjected to boundary constraints according to the preset safety range to obtain the boundary constraint result; the smaller value between the amplitude limiting processing result and the boundary constraint result is taken as the control value in the control command to be sent out by the communication node.

[0165] For example, the control value, as the final output of the control command to be sent out by the communication node, can directly correspond to the weighted sum value, or it can be output after adding safety constraints to it, to adapt to the actuator's requirements for continuity and boundary conditions. The rate of change limit is used to constrain the change range of the control value between adjacent time moments, preventing the control output from abruptly changing due to computational fluctuations or vehicle speed changes. Boundary constraints are used to limit the control value from exceeding a preset safety upper limit or falling below a preset safety lower limit, thereby preventing the control command from going out of bounds.

[0166] In practical implementation, after calculating the weighted sum, the communication node can further determine whether it is within the allowable range and whether the change trend meets the control requirements. When it is determined that the weighted sum is within the allowable range and the change trend meets the control requirements, the communication node can directly write it into the control field of the control message to be sent. If there is a risk of rapid transition in the weighted sum, the communication node first calculates the maximum rate of change limit based on historical control values ​​and preset allowable slopes, then obtains the maximum allowable boundary constraint value based on the preset control range, and finally takes the smaller of the two as the output control value, so that the value satisfies both the smoothness requirement and the amplitude constraint requirement.

[0167] By adopting the above method, the control value in the control command to be sent out can be flexibly switched between directly using candidate results and safety limiting output, so that the control output can maintain consistency with the vehicle's needs and avoid abnormal triggering caused by sudden changes and out-of-bounds. This is conducive to improving the identifiability of the actuator-level safety mechanism and the stability of the entire communication function safety link.

[0168] The above-mentioned optional embodiments incorporate vehicle speed into the control value generation process, enabling the control output to adaptively adjust according to the vehicle's operating state. This balances smoothness in low-speed scenarios and timeliness in high-speed scenarios. This approach reduces abrupt changes in control values, making the output more consistent with the continuity and identifiability requirements of downstream actuators. With this implementation, communication nodes can dynamically adjust the contribution ratio between the demand side and the feedback side as vehicle operating conditions change, ensuring both responsiveness and stability in the control values, and improving the controllability and consistency of outgoing control commands. Because the control value generation process combines the current vehicle speed and the dual-source fitting results, it reduces the risk of false triggering caused by discrete jumps, enhances the functional safety diagnostics in the execution link, and improves the stability of communication control in complex operating scenarios.

[0169] S306. Execute the preset end-to-end communication function security diagnostic mechanism.

[0170] For example, when the judgment result of S301 is "no," meaning the current communication cycle is not greater than (i.e., less than or equal to) the original cycle, it indicates that the communication is in a normal fixed-cycle state. In this case, there is no need for smooth reconstruction of the control commands, and the system executes a preset end-to-end communication functional safety diagnostic mechanism. For instance, it executes a standard diagnostic process based on the E2E standard. This process typically includes: performing counter continuity verification (expected step size of 1), CRC integrity verification, timeout verification, and DataID verification on the received control commands to ensure that the commands are not lost, duplicated, damaged, or incorrectly addressed during transmission. This mechanism is a baseline protection measure for functional safety communication in vehicular networks.

[0171] Furthermore, after executing the second protection strategy, a preset end-to-end communication function security diagnostic mechanism can also be executed when protecting the transmission of control commands. In some possible embodiments, after executing the second protection strategy, the communication function security diagnostic mechanism of the first protection strategy can also be executed; this application does not impose any limitations.

[0172] By performing routine end-to-end diagnostics when the communication cycle does not exceed the original cycle, and continuing to perform end-to-end diagnostics on control commands protected by transmission after the second protection strategy is completed, message verification, timing verification, and security checks after control value reconstruction can complement each other. This ensures basic functional security coverage in routine cycle communication scenarios, while also guaranteeing that smoothly reconstructed control commands still meet end-to-end consistency requirements under dynamic transmission conditions, thereby improving the anomaly detection capability of the communication link and the security and reliability of outgoing control signals.

[0173] The second protection strategy provided in this embodiment, through conditional branching, uses lightweight standard E2E diagnostics during normal communication cycles to avoid unnecessary computational overhead. When the communication cycle is lengthened, it performs curve fitting using the original demand value and actual feedback value from historical sampling points, and then fuses the two fitted values ​​to generate a smooth and continuous control value. In this way, even if the outgoing cycle becomes sparse, the control command still maintains its gradual change characteristic, allowing the actuator's built-in incremental change threshold monitoring and other safety mechanisms to be triggered normally, thus solving the safety fallback failure problem caused by stepped commands. Simultaneously, the introduction of actual feedback values ​​during the fusion process allows the control value to adapt to the actuator's dynamic response characteristics, improving control accuracy and system stability. This method significantly improves the functional safety and reliability of outgoing control in dynamically changing cycle scenarios without increasing hardware costs.

[0174] Optionally, in Figure 3 Based on its optional embodiments, in one possible embodiment, the execution flow of the second protection strategy may further include:

[0175] S10. Obtain the original demand value at the current moment and calculate the deviation between the original demand value at the current moment and the original demand fitted value.

[0176] S20. If the deviation is greater than the preset deviation threshold and the duration exceeds the preset time, the current sampling point is removed and the fault is recorded.

[0177] For example, in this embodiment, the original demand value at the current moment refers to the actual demand input of the controlled object at that moment, the original demand fitted value is used to characterize the trend reference value obtained by fitting historical sampling points, and the deviation between the two is used to measure the degree of difference between them. The preset deviation threshold is used to limit the allowable deviation range, and the preset time is used to limit how long the deviation state can last before it can be judged as abnormal.

[0178] In practical implementation, the controller can calculate the original demand value based on actual sensing data. After obtaining the original demand value at the current moment, it can compare it with the original demand fitting value formed by fitting multiple historical sampling points, and the difference is timed in real time. When the deviation continues to be greater than the preset deviation threshold and the duration exceeds the preset time, the controller determines that the current sampling point has deviated from the normal evolution pattern, removes the sampling point from the fitting sample set so that it no longer participates in subsequent fitting calculations or control value generation, and marks the abnormal state as a fault, for example, by writing it into the diagnostic storage unit or fault log for subsequent traceability.

[0179] By combining amplitude and duration thresholds for anomaly detection, false rejections due to instantaneous fluctuations can be avoided. Simultaneously, abnormal data can be isolated promptly when sampling points are distorted over a long period, preventing these abnormal sampling points from further contaminating subsequent original requirement fitting results. This improves the effectiveness of historical samples and the stability of the fitted curve, enhances the reliability of the control command generation process, and helps maintain the identifiable characteristics of the actuator-level safety mechanism.

[0180] Optionally, in Figure 3 Based on its optional embodiments, in one possible embodiment, the execution flow of the second protection strategy may further include: before the preset conditions are met, using the original demand value at the current moment as the control value in the control command to be sent out by the communication node; after the preset conditions are met, using a smooth reconstruction method to determine the control value; wherein the preset conditions include: the number of accumulated historical sampling points reaches a preset value, and / or the system running time reaches a preset duration.

[0181] For example, in actual implementation, the communication node can first determine whether the current condition is met after receiving a new raw demand value. When the number of historical sampling points has not reached the preset value, and / or the system running time has not reached the preset duration, the communication node does not reconstruct the current raw demand value, but directly writes the raw demand value into the control command to be sent out, so as to ensure that the control output can quickly follow the changes in vehicle operating conditions. After the historical sampling points continue to accumulate, or after the system runs for the preset duration, the communication node switches to a smooth reconstruction mode, merges the raw demand values ​​and actual feedback values ​​from multiple historical sampling points, and generates a smoothed control value. This smooth reconstruction can be achieved through curve fitting, sliding weighting, or exponential smoothing, so that the control value reduces the abrupt change amplitude while satisfying the actuator's recognizability.

[0182] In one implementation, the preset value can be set according to the dynamic response speed, sampling period, and control stability requirements of the controlled object, while the preset duration can be set according to the initialization process after system power-on, sensor stabilization time, or control link establishment time. When any one condition is met, the system considers itself to have the basis for reconstruction using historical data; when both conditions are met simultaneously, it indicates that the system has fully entered the stable operation phase, at which point a smooth reconstruction method can obtain more reliable control value output. This switching logic can avoid distortion of reconstruction results due to insufficient historical data in the early stages of system operation and can also suppress control value jumps in subsequent operation phases.

[0183] In this way, the system maintains direct output of the original demand value during the startup phase to ensure response speed. After sufficient data accumulation or stable operation, it switches to smooth reconstruction to improve the continuity and verifiability of control values. This ensures that the control commands to be sent out by the communication node can reflect the current demand in a timely manner and meet the requirements of the actuator level for safety triggering and anomaly identification, thereby improving the control stability and protection effect in vehicle functional safety communication scenarios.

[0184] For example, Figure 4 This is a flowchart illustrating another communication function security protection method provided in an embodiment of this application. Figure 5 This is a flowchart illustrating a second protection strategy provided in an embodiment of this application. Figure 4 and Figure 5 This solution can be applied to the distributed electronic and electrical architecture of intelligent connected vehicles, such as in scenarios where the power domain controller and chassis domain controller work together to perform emergency braking. The following example illustrates this: when a vehicle is traveling at 100 km / h on a highway, a stationary obstacle appears ahead. The power domain controller forwards information such as distance and relative speed from the obstacle detection data to the chassis domain controller via the vehicle's Ethernet.

[0185] like Figure 4As shown, depending on whether inter-domain tiered message transmission and forwarding are involved, and whether intra-domain tiered message transmission and outgoing are involved, a first protection strategy and a second protection strategy can be executed in parallel within a domain controller. Specifically, when executing the judgment branch of the first protection strategy, the system first checks whether the current communication node is involved in inter-domain tiered message transmission and forwarding: if not, it directly jumps to the conventional E2E communication functional safety diagnostic mechanism; if so, it further determines whether the communication cycle is an integer multiple of the original cycle. If it is an integer multiple (e.g., 2x, 3x), an extended counting verification window compatible with N-1, N, and N+1 is used; if it is a non-integer forwarding (e.g., 1.5x, 2.5x), an extended counting verification window compatible with M-1, M, M+1, and M+2 is used (M is N rounded down). In the emergency braking example, the operating state of the communication node changes, causing the communication cycle to be adjusted from the original 100ms to 150ms, with a scaling factor N=1.5 (greater than 1), which is a non-integer multiple forwarding. The system rounds N down to obtain M=1, and determines 0, 1, 2, and 3 as the count values ​​in the extended count verification window. During forwarding, the count value carried in the message is extracted and compared with this value. If the count value does not belong to this window, it is considered an anomaly (e.g., sequence number 4 is extracted). When the communication period is not greater than the original period, or when the transmission of the command is protected after the second protection strategy (i.e., the control command is generated using a smooth reconstruction method), the preset end-to-end communication function security diagnostic mechanism (including sequence number verification, CRC verification, and timeout detection) is executed.

[0186] like Figure 5As shown, the process of executing the second protection strategy can be as follows: For the control values ​​in the control commands to be sent out by the chassis domain controller, first determine whether it is in the initial stage (i.e., the preset conditions for switching to smooth reconfiguration have not yet been met, such as the number of accumulated historical sampling points not reaching the preset value or the system running time not reaching the preset duration). When the emergency braking control command is sent out every 200ms, the first 500ms of the initial startup can be regarded as the initial stage. At this time, the current original demand value is sent out directly. For example, when the current real-time braking demand value is 50%, 50% is directly written into the control command to be sent out. When the preset conditions are met, the system enters the predictive optimization mode: simultaneously performing demand curve fitting and feedback curve fitting—acquiring multiple historical sampling points before the current time (taking the last 10 sampling points as an example, each sampling point contains the original demand value and the actual feedback value at the corresponding time), fitting the original demand value sequence to obtain the original demand fitting value, and fitting the actual feedback value sequence to obtain the actual feedback fitting value (for example, the original demand value sequence is 45%, 48%, 50%, 52%..., and the actual feedback value sequence is 43%, 47%, 49%, 51%...). Then, the vehicle's current speed is obtained, and dynamic weighting is performed based on the speed range: when the speed is less than the first threshold (low speed), a conservative weighting configuration is used (the weight of the original demand fitting value is lower than the weight of the actual feedback fitting value); when the speed is greater than the second threshold (high speed), an aggressive weighting configuration is used (the weight of the original demand fitting value is higher than the weight of the actual feedback fitting value); when the speed is between the first and second thresholds, a balanced weighting configuration is used (the weights of the two are equal). Under the high-speed condition of 100km / h, according to the aggressive weighting configuration, the weight of the original demand fitting value is set to 70%, and the weight of the actual feedback fitting value is set to 30%. The two fitting values ​​are then weighted and summed to obtain a weighted sum value (e.g., 52%). The weighted sum can be used directly as the control value, or further evaluated for exceeding the rate amplitude and boundary amplitude: The weighted sum is limited based on its rate of change relative to the previously sent control value (e.g., a change of no more than 5% per 100ms), yielding a limiting result; then, boundary constraints are applied based on a preset safety range (e.g., a braking pressure limit of 100%), yielding a boundary constraint result; finally, a logical comparison operation is performed, taking the smaller value between the limiting result and the boundary constraint result as the final sent control value (e.g., if the limiting constraint result is 51%, then 51% is used). Finally, the determined control value is written into the control command to be sent and transmission processing is executed.

[0187] Based on the above examples of emergency braking, the communication function security protection method provided in this application has the following beneficial effects:

[0188] First, it significantly improves the functional safety diagnostic coverage of inter-domain forwarding messages. When the communication period is adjusted from 100ms to 150ms (N=1.5), traditional E2E verification based on a fixed period assumption will misjudge message loss or out-of-order delivery due to count value jumps exceeding the normal window (such as expected steps 1~4). This application introduces an extended count verification window linked to the scaling factor (window is 0, 1, 2, 3 when M=1), enabling the receiving node to identify normal count value changes caused by period scaling (such as steps 1 or 2) as legitimate, while still accurately detecting real abnormal steps (such as steps 4). This avoids false positive fault alarms caused by the extended period and maintains high sensitivity to message duplication, loss, and out-of-order delivery, increasing the communication anomaly diagnostic coverage of the forwarding link from less than 70% under the conventional fixed window to over 90%.

[0189] Secondly, it ensures the effective triggering of the actuator-level safety mechanism, eliminating the hidden dangers caused by the discretization of control commands. In emergency braking scenarios, if the external transmission cycle of the chassis domain controller changes from the original 10ms to 200ms, the directly transmitted braking commands will exhibit a stepped pattern (e.g., after maintaining 50% for a long time, suddenly jumping to 60%), causing the actuator's built-in incremental change threshold monitoring to never trigger due to the diluted amplitude of adjacent command changes. This application ensures a start-up response through direct external transmission in the initial stage, and then enters a predictive optimization mode after sufficient data accumulation. It utilizes curve fitting of historical demand values ​​and actual feedback values, adaptive weight allocation of vehicle speed, and "smaller than" constraints to generate a continuous and smooth braking command sequence. This allows the actuator to continuously monitor the command change rate as in the original cycle. When a real anomaly occurs (such as a command sudden change exceeding the limit), the safety fallback mechanism can be activated within 50ms, improving the response speed by approximately 70% compared to the passive mode, and increasing the safety mechanism trigger rate from approximately 75% to over 95%.

[0190] Third, it achieves synergistic enhancement of communication link protection and content security protection. In this application, the first and second protection strategies can be deployed independently or run in parallel: when the power domain forwards obstacle information to the chassis domain, the first protection strategy ensures the integrity and orderliness of message transmission; when the chassis domain issues control commands to the brake actuator, the second protection strategy ensures the smoothness and verifiability of the commands. Together, they form a complete functional safety closed loop from "end-to-end communication" to "actuator safety," effectively avoiding systemic diagnostic blind spots caused by dynamic adjustments to the communication cycle.

[0191] Fourth, it possesses excellent engineering adaptability and configurability. The scaling factor N can be a static parameter preset during design, or it can be dynamically measured and rationalized during node runtime. The construction rules for the extended counting verification window (integer multiples / non-integer multiples) are clear and explicit, suitable for various periodic scaling scenarios commonly found in vehicular networks. The switching conditions between the initial stage and smooth reconstruction are based on objective quantitative indicators (number of historical sampling points, runtime), making it easy to implement in standard architectures such as AUTOSAR. The vehicle speed adaptive weighting strategy enables a smooth transition of control output between the differentiated needs of stability at low speeds and speed at high speeds, balancing safety and driving experience.

[0192] In summary, the embodiments of this application effectively solve the problems of decreased diagnostic coverage and failure of fallback protection in dynamic cycle scenarios by synchronously implementing extended count verification of forwarded messages and smooth reconstruction of control instructions during communication cycle amplification. This provides a highly reliable and real-time communication functional safety protection solution for the distributed electronic and electrical architecture of intelligent connected vehicles.

[0193] Figure 6 This is a schematic diagram of a communication function security protection device provided in an embodiment of this application. Figure 6 As shown, the communication function security protection device 60 provided in this application embodiment includes: a processing unit 601.

[0194] The processing unit is configured to execute at least one of the following protection strategies when the communication period of a communication node is adjusted to be greater than the preset original period:

[0195] The first protection strategy is to determine the extended counting verification window based on the scaling factor N of the communication cycle, and to perform counting verification on the forwarded messages between communication nodes based on the extended counting verification window; where N is a rational number greater than 1.

[0196] The second protection strategy is to smoothly reconstruct the control values ​​in the control commands to be sent out by the communication node based on the original demand values ​​and actual feedback values ​​of historical sampling points.

[0197] In one possible embodiment, the processing unit 601 is specifically used for:

[0198] If N is an integer, the extended count check window contains three count values: N-1, N, and N+1.

[0199] If N is not an integer, the extended count check window contains four count values: M-1, M, M+1, and M+2, where M is the integer N rounded down.

[0200] In one possible embodiment, the processing unit 601 is specifically used for:

[0201] Extract the count value carried in the forwarded message. If the count value carried in the forwarded message does not belong to the count value in the extended count verification window, the count is considered abnormal.

[0202] In one possible embodiment, the processing unit 601 is further configured to:

[0203] When N is an integer and N+1 reaches or exceeds the maximum allowed count value for forwarded messages, or when N is a non-integer and M+2 reaches or exceeds the maximum allowed count value for forwarded messages, the counting verification is performed again according to the preset counting step size.

[0204] In one possible embodiment, the processing unit 601 is further configured to:

[0205] Perform cyclic redundancy check (CRC) and / or timeout check on forwarded messages;

[0206] If any of the following occurs continuously within the preset fault tolerance time interval: abnormal counting, CRC check failure, or check timeout, it is considered an abnormal message forwarding communication.

[0207] In one possible embodiment, the processing unit 601 is specifically used for:

[0208] Obtain multiple historical sampling points prior to the current moment; each historical sampling point includes the original demand value and the actual feedback value at the corresponding sampling moment;

[0209] Curve fitting is performed on the original demand values ​​from multiple historical sampling points to obtain the original demand fitted values;

[0210] Curve fitting is performed on the actual feedback values ​​from multiple historical sampling points to obtain the actual feedback fitted values;

[0211] Based on the original demand fitting value and the actual feedback fitting value, the control value in the control command to be sent out by the communication node is determined.

[0212] In one possible embodiment, the processing unit 601 is specifically used for:

[0213] Get the vehicle's current speed;

[0214] Based on the current vehicle speed, determine the weights of the original demand fitting value and the actual feedback fitting value;

[0215] Based on the weights of the original demand fitting values ​​and the actual feedback fitting values, the original demand fitting values ​​and the actual feedback fitting values ​​are weighted and summed to obtain a weighted sum value.

[0216] Based on the weighted sum, determine the control value in the control command to be sent out by the communication node.

[0217] In one possible embodiment, the processing unit 601 is specifically used for:

[0218] If the current vehicle speed is less than the first threshold, the weight of the original demand fitting value is lower than the weight of the actual feedback fitting value.

[0219] If the current vehicle speed is greater than the second threshold, the weight of the original demand fitting value is higher than the weight of the actual feedback fitting value.

[0220] If the current vehicle speed is greater than or equal to the first threshold and less than or equal to the second threshold, then the weight of the original demand fitting value is equal to the weight of the actual feedback fitting value.

[0221] In one possible embodiment, the processing unit 601 is specifically used for:

[0222] The weighted sum is determined as the control value in the control command to be sent out by the communication node;

[0223] Alternatively, based on the rate of change of the weighted summation value relative to the control value sent at the previous sampling time, the weighted summation value is subjected to amplitude limiting processing to obtain the amplitude limiting result; and the weighted summation value is subjected to boundary constraints according to the preset safety range to obtain the boundary constraint result; the smaller value between the amplitude limiting result and the boundary constraint result is taken as the control value in the control command to be sent by the communication node.

[0224] In one possible embodiment, the processing unit 601 is further configured to:

[0225] Obtain the raw demand value at the current moment, and calculate the deviation between the raw demand value at the current moment and the fitted raw demand value;

[0226] If the deviation is greater than the preset deviation threshold and the duration exceeds the preset time, the current sampling point will be removed and the fault will be recorded.

[0227] In one possible embodiment, the processing unit 601 is further configured to:

[0228] Before the preset conditions are met, the original demand value at the current moment is used as the control value in the control command to be sent out by the communication node.

[0229] After the preset conditions are met, the control value is determined by a smooth reconstruction method;

[0230] The preset conditions include: the number of accumulated historical sampling points reaches a preset value, and / or the system running time reaches a preset duration.

[0231] In one possible embodiment, the processing unit 601 is further configured to:

[0232] When the communication period is not greater than the preset original period, or when the control command is protected during transmission after the second protection strategy is executed, the preset end-to-end communication function safety diagnosis mechanism is executed.

[0233] The communication function security protection device provided in this embodiment is used to execute the technical solution in any of the foregoing method embodiments. Its implementation principle and technical effect are similar, and will not be described again here.

[0234] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 7 As shown, the electronic device 70 provided in this embodiment includes at least one processor 701 and a memory 702. Optionally, the device 70 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus 704.

[0235] In a specific implementation, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to perform the above-described method.

[0236] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0237] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0238] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0239] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0240] This application also provides a vehicle that performs the technical solutions in any of the foregoing method embodiments.

[0241] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0242] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0243] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0244] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0245] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0246] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0247] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0248] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0249] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0250] The above embodiments are merely preferred embodiments provided to fully illustrate this application, and the scope of protection of this application is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on this application are all within the scope of protection of this application.

Claims

1. A communication function security protection method, characterized in that, When the communication period of a communication node is adjusted to be greater than the preset original period, at least one of the following protection strategies will be executed: First protection strategy: Determine an extended counting verification window based on the scaling factor N of the communication period, and perform counting verification on the forwarded messages between the communication nodes based on the extended counting verification window; where N is a rational number greater than 1. The second protection strategy is to smoothly reconstruct the control values ​​in the control commands to be sent out by the communication node based on the original demand values ​​and actual feedback values ​​of historical sampling points.

2. The method according to claim 1, characterized in that, Determining the extended count verification window based on the scaling factor N of the communication period includes: If N is an integer, then the extended counting verification window contains three count values: N-1, N, and N+1. If N is not an integer, the extended counting verification window contains four count values: M-1, M, M+1, and M+2, where M is the integer N rounded down.

3. The method according to claim 1, characterized in that, The step of counting and verifying the forwarded messages between the communication nodes based on the extended counting verification window includes: Extract the count value carried in the forwarded message. If the count value carried in the forwarded message does not belong to the count value in the extended count verification window, the count is considered abnormal.

4. The method according to claim 3, characterized in that, The method further includes: When N is an integer and N+1 reaches or exceeds the maximum allowed count value of the forwarded message, or when N is a non-integer and M+2 reaches or exceeds the maximum allowed count value of the forwarded message, the counting verification is performed again according to the preset counting step size.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: Perform cyclic redundancy check (CRC) and / or timeout check on the forwarded message; If any of the following occurs continuously within the preset fault tolerance time interval: abnormal counting, CRC check failure, or check timeout, the forwarding message communication is deemed abnormal.

6. The method according to claim 1, characterized in that, The process of smoothly reconstructing the control values ​​in the control commands to be sent out by the communication node based on the original demand values ​​and actual feedback values ​​from historical sampling points includes: Obtain multiple historical sampling points prior to the current moment; each historical sampling point includes the original demand value and the actual feedback value at the corresponding sampling moment; Curve fitting is performed on the original demand values ​​from the multiple historical sampling points to obtain the original demand fitted values; Curve fitting is performed on the actual feedback values ​​from the multiple historical sampling points to obtain the actual feedback fitted values; Based on the original demand fitting value and the actual feedback fitting value, the control value in the control command to be sent out by the communication node is determined.

7. The method according to claim 6, characterized in that, The step of determining the control value in the control command to be sent out by the communication node based on the original demand fitting value and the actual feedback fitting value includes: Get the vehicle's current speed; Based on the current vehicle speed, determine the weights of the original demand fitting value and the actual feedback fitting value; Based on the weights of the original demand fitting value and the actual feedback fitting value, the original demand fitting value and the actual feedback fitting value are weighted and summed to obtain a weighted sum value. Based on the weighted summation value, the control value in the control command to be sent out by the communication node is determined.

8. The method according to claim 7, characterized in that, The step of determining the weights of the original demand fitting value and the actual feedback fitting value based on the current vehicle speed includes: If the current vehicle speed is less than the first threshold, then the weight of the original demand fitting value is controlled to be lower than the weight of the actual feedback fitting value; If the current vehicle speed is greater than the second threshold, then the weight of the original demand fitting value is controlled to be higher than the weight of the actual feedback fitting value; If the current vehicle speed is greater than or equal to the first threshold and less than or equal to the second threshold, then the weight of the original demand fitting value is equal to the weight of the actual feedback fitting value.

9. The method according to claim 7, characterized in that, The step of determining the control value in the control command to be sent out by the communication node based on the weighted sum value includes: The weighted summation value is determined as the control value in the control command to be sent out by the communication node; Alternatively, based on the rate of change of the weighted summation value relative to the control value sent at the previous sampling time, the weighted summation value is subjected to amplitude limiting processing to obtain an amplitude limiting processing result; and the weighted summation value is subjected to boundary constraints according to a preset safety range to obtain a boundary constraint result; the smaller value between the amplitude limiting processing result and the boundary constraint result is taken as the control value in the control command to be sent by the communication node.

10. The method according to claim 6, characterized in that, The method further includes: Obtain the original demand value at the current moment, and calculate the deviation between the original demand value at the current moment and the original demand fitted value; If the deviation is greater than a preset deviation threshold and the duration exceeds a preset time, the current sampling point is removed and the fault is recorded.

11. The method according to any one of claims 1, 6-10, characterized in that, The second protection strategy also includes: Before the preset conditions are met, the original demand value at the current moment is used as the control value in the control command to be sent out by the communication node. After the preset conditions are met, the control value is determined using the smooth reconstruction method. The preset conditions include: the number of accumulated historical sampling points reaches a preset value, and / or the system running time reaches a preset duration.

12. The method according to claim 1, characterized in that, The method further includes: When the communication period is not greater than the preset original period, or when the control command is protected during transmission after the second protection strategy is executed, a preset end-to-end communication function security diagnosis mechanism is executed.

13. A communication function security protection device, characterized in that, The device includes: a processing unit; The processing unit is configured to execute at least one of the following protection strategies when the communication period of a communication node is adjusted to be greater than the preset original period: First protection strategy: Determine an extended counting verification window based on the scaling factor N of the communication period, and perform counting verification on the forwarded messages between the communication nodes based on the extended counting verification window; where N is a rational number greater than 1. The second protection strategy is to smoothly reconstruct the control values ​​in the control commands to be sent out by the communication node based on the original demand values ​​and actual feedback values ​​of historical sampling points.

14. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-12.

15. A vehicle, characterized in that, The vehicle is used to implement the method as described in any one of claims 1-12.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-12.

Images