SOME / IP ethernet signal dynamic fusing method based on QNX side SOA service, electronic device, storage medium and car machine system

Abstract

The application discloses a SOME / IP Ethernet signal dynamic fusing method based on QNX side SOA service, an electronic device, a storage medium and a vehicle-machine system, and relates to the field of communication management and control. The method comprises the following steps: performing real-time frequency statistics on the SOME / IP Ethernet signal received by the QNX side SOA service; releasing the key signals in the white list and performing single-signal frequency threshold judgment on the non-white list signals; selecting to perform global signal total amount threshold judgment according to the single-signal frequency threshold judgment result; and performing multi-granularity fusing decision according to the threshold judgment result, specifically comprising the following steps: determining a fault range based on the level to which the signal judged as an abnormal signal belongs, selecting a corresponding fusing granularity according to the fault range, and performing fusing management and control on the abnormal signal; wherein the fusing state of the fused signal is maintained during the fusing management and control, and specifically comprising the following steps: managing the adaptive fusing duration by using a silent listening mechanism, an early recovery mechanism and a ladder punishment mechanism.

Description

Technical Field

[0001] This invention relates to the field of communication management and control, and in particular to a method for dynamic fuse breaking of SOME / IP Ethernet signals based on QNX-side SOA services, electronic devices, storage media, and vehicle infotainment systems. Background Technology

[0002] 1. In-vehicle Ethernet and SOME / IP protocol:

[0003] With the deep evolution of automotive electrification and intelligence, traditional vehicle buses (CAN, LIN, FlexRay, etc.) are constrained by bandwidth bottlenecks and can no longer meet the communication needs of big data and low latency services such as smart cockpits, advanced driver assistance systems (ADAS), and autonomous driving.

[0004] Automotive Ethernet (IEEE 100BASE-T1 / 1000BASE-T1), with its bandwidth of hundreds to gigabits, full-duplex communication capabilities, and native IP network ecosystem, has become the backbone communication medium for next-generation domain controllers and zone controllers.

[0005] In the automotive Ethernet protocol family, SOME / IP (Scalable service-Oriented Middleware IP), as the core middleware protocol within the AUTOSAR standard system, implements service-oriented architecture (SOA) communication paradigms such as service discovery, remote method invocation, and event notification. It is widely deployed in key automotive electronic systems such as smart cockpits, body domains, and driver assistance systems.

[0006] 2. Application of QNX real-time operating system in vehicle systems:

[0007] The QNX Neutrino real-time operating system (RTOS) dominates the market for safety-critical ECUs such as smart cockpit domain controllers, digital instruments, and gateways, thanks to its microkernel architecture, deterministic real-time response, strict memory isolation mechanism, and comprehensive functional safety certification (ISO 26262 ASIL-D).

[0008] In a typical intelligent cockpit platform architecture, the QNX Hypervisor serves as the underlying virtualization layer, supporting safety-critical applications. The upper layer uses an SOA-based service framework to manage the reception, distribution, and processing of various signals. The SOME / IP protocol stack runs in the QNX user space, with SOA services uniformly responsible for the subscription, reception, and forwarding of Ethernet signals.

[0009] 3. Existing signal reception and processing architecture:

[0010] Under the existing automotive QNX+SOA platform architecture, the typical workflow for SOME / IP Ethernet signal reception is as follows:

[0011] 1) Each domain ECU (such as IVI, ADAS, BCM, etc.) sends signals to the QNX side via the SOME / IP protocol in a publish / subscribe or request / response mode.

[0012] 2) After receiving the signal, the QNX-side SOME / IP protocol stack directly passes it through to the SOA service's receive queue.

[0013] 3) SOA services parse, route, and forward signals according to preset business logic, and finally deliver them to the upper-layer application process.

[0014] The above architecture operates stably under normal network load. However, when network anomalies occur, the existing architecture lacks an active signal frequency control mechanism, resulting in several systemic defects.

[0015] (1) Lack of signal-level frequency anomaly detection and automatic current limiting mechanism: The existing QNX-side SOME / IP signal receiving framework does not set any frequency upper limit monitoring for a single signal. When a specific signal (such as a data frame from an ADAS sensor) causes the sender to be abnormal due to hardware failure, software bug, or network attack, and continues to be sent at a frequency far exceeding the normal frequency (such as 1000 times / second or even higher), the QNX-side SOA service will receive all messages indiscriminately and push them into the processing queue.

[0016] Such signal flooding will quickly exhaust the SOA service's receive buffer, consume a large amount of CPU processing resources, cause a surge in the processing delay of normal signals, and in severe cases, cause QNX process blocking or even functional paralysis of the entire domain control system, seriously threatening the functional safety of the entire vehicle.

[0017] (2) Lack of global signal overload protection mechanism: Even if the frequency of each individual signal does not exceed the abnormal threshold, the total amount of multiple signals may cause system overload. The existing architecture lacks global monitoring of the total amount of Ethernet signals received per second on the QNX side. When multiple ECU nodes malfunction at the same time, or when the whole vehicle is powered on / off, etc., causing legitimate traffic peaks, the system does not have a total circuit breaker protection mechanism and cannot perform global overload protection.

[0018] (3) Lack of multi-granularity fault isolation capability: The existing signal receiving architecture processes all communication from the perspective of a flat single signal, lacking the ability to isolate faults at multiple granularities such as service instance, ECU node, and network domain. When multiple signals of the same ECU node are abnormal at the same time, the system can only process each signal one by one, which can neither quickly locate the fault source nor efficiently contain the fault spread through node-level isolation.

[0019] (4) Lack of anti-false triggering mechanism and inability to adapt to the traffic characteristics of vehicle scenarios: There are many legitimate instantaneous traffic peak scenarios in vehicle networks: centralized reporting by each ECU when the vehicle is powered off and woken up, short-term data bursts from ADAS sensors when driving on highways, centralized diagnostic requests during vehicle self-checks, etc. The existing architecture cannot distinguish between these legitimate instantaneous peaks and real abnormal floods, which can easily lead to false triggering, causing normal signals to be erroneously interrupted and affecting the normal function of the system.

[0020] (5) Lack of non-fuse protection mechanism for critical signal channels: Diagnostic communication (UDS over SOME / IP), OTA remote upgrade signals, and vehicle safety monitoring signals are core protection signals of the vehicle system. The availability of their channels is the basic guarantee for vehicle maintenance, upgrades, and safety monitoring. The existing architecture treats all signals equally. Once a circuit breaker is triggered, the above-mentioned critical signals will be equally restricted, which poses a serious systemic risk of diagnostic channel failure, OTA upgrade interruption, and loss of safety monitoring due to false circuit breakers.

[0021] (6) Lack of proactive perception and reporting of network health status: The existing architecture lacks the ability to dynamically compare and analyze the received signal frequency with the configured expected frequency. It cannot proactively determine whether the current network signal status is in a healthy range, nor can it report the network health status to the vehicle diagnostic platform or functional safety monitoring module. This results in maintenance personnel being unable to perceive network anomalies in a timely manner and missing the best opportunity to deal with them. Summary of the Invention

[0022] The purpose of this invention is to provide a method for dynamic fuse breaking of SOME / IP Ethernet signals based on QNX-side SOA services, an electronic device, a storage medium, and an in-vehicle system, thereby solving at least one of a number of technical problems.

[0023] Core technical issues:

[0024] How to implement real-time frequency monitoring of a single SOME / IP signal in the SOA service layer on the QNX side, and automatically trigger signal-level fuse when the signal frequency is abnormal to prevent the abnormal signal from continuously occupying system resources;

[0025] How to implement overload protection for the total global signal volume based on single-channel signal monitoring, and quickly restore the system to a safe load range using quantified and configurable circuit breaker rules;

[0026] How to construct a sliding time window mechanism to accurately distinguish between legitimate instantaneous traffic peaks and real abnormal floods in vehicle scenarios, and avoid false triggering of circuit breakers;

[0027] How to achieve multi-granularity fault isolation at the signal level, interface level, service level, ECU node level, and network domain level to improve fault location and isolation efficiency;

[0028] How to maintain silent monitoring of the circuit-breaker signal during the circuit breaker period, achieve adaptive early recovery and a stepped penalty mechanism, and avoid circuit breaker-recovery oscillation;

[0029] How to protect critical signal channels such as diagnostic UDS, OTA upgrades, and security monitoring to ensure their continuous availability under any load conditions;

[0030] How to proactively sense and report network health status based on the dynamic comparison between signal frequency configuration and real-time received frequency.

[0031] This invention provides the following solution:

[0032] According to a first aspect of the present invention, a method for dynamic circuit breaking of SOME / IP Ethernet signals based on QNX-side SOA services is provided, comprising:

[0033] Perform real-time frequency statistics on the SOME / IP Ethernet signals received by the SOA service on the QNX side;

[0034] Allow key signals within the whitelist to pass, perform single-signal frequency threshold judgment on non-whitelist signals, and select to perform global signal total quantity threshold judgment based on the single-signal frequency threshold judgment result;

[0035] Based on the threshold judgment result, a multi-granularity circuit breaker decision is made, which specifically includes: determining the fault range based on the level of the signal judged as abnormal, selecting the corresponding circuit breaker granularity according to the fault range, and controlling the abnormal signal through circuit breaker.

[0036] During the circuit breaker management period, the circuit breaker status of the circuit breaker signal is maintained, which specifically includes: managing the adaptive circuit breaker duration through a silent monitoring mechanism, an early recovery mechanism, and a tiered penalty mechanism.

[0037] Furthermore, real-time frequency statistics include: employing a layered window mechanism, with separate detections for short-time and long-time time layers.

[0038] For the short time layer, a second-level sliding time window is used, and a sliding window counter is independently maintained for each signal to detect sudden anomalies;

[0039] For the longer time frame, a minute-level periodic statistical window is used for slow flood detection.

[0040] Furthermore, a second-level sliding time window is used, and a sliding window counter is independently maintained for each signal to perform sudden anomaly detection, including:

[0041] One second is divided into multiple consecutive millisecond-level sliding evaluation windows. When the frequency statistics of N1 consecutive sliding evaluation windows all exceed the single signal frequency threshold, an anomaly is reported to trigger the circuit breaker decision process.

[0042] Furthermore, slow flooding detection is performed using a minute-level periodic statistical window, including:

[0043] Chronic overload determination includes: calculating the average continuous deviation of the signal receiving frequency from the configured expected frequency using a statistical window with a duration of minutes;

[0044] When the average value of the continuous deviation exceeds the preset deviation threshold continuously, it is determined to be a chronic overload, triggering current limiting and / or an alarm;

[0045] The progressive flooding determination includes: constructing a time series of the signal reception frequency and fitting the frequency change slope of the most recent N2 minute-level periodic statistical windows;

[0046] When the slope is consistently positive and all M consecutive minute-level periodic statistical windows are positive, it is determined to be a gradual flooding trend, triggering flow restriction and / or an early warning.

[0047] Furthermore, selecting the corresponding fuse granularity based on the fault range includes:

[0048] Based on the level to which the abnormal signal belongs, the fault range is determined, and the fuse granularity is automatically selected, specifically including:

[0049] Signal level L1: When a single non-whitelisted signal exceeds the single signal frequency threshold, the signal is blown off.

[0050] Interface-level L2: When multiple non-whitelisted signals on the same interface malfunction, the circuit breaker will trip the Event or Method interface.

[0051] Service Level 3: When multiple interfaces of the same service fail, the service instance is tripped.

[0052] ECU node level L4: When multiple or multiple interfaces of the same ECU are abnormal, all non-whitelisted communications of the ECU will be shut down.

[0053] Network domain level L5: When multiple ECUs in the same network domain have abnormal non-whitelist signals, all non-whitelist communication in the entire network domain will be shut down.

[0054] Furthermore, when the total global signal volume exceeds the total global signal volume threshold, the circuit breaker decision includes:

[0055] Calculate the reception frequency of each non-whitelisted signal within the current second, and sort the signals that have triggered single signal anomalies from high to low according to their reception frequency;

[0056] Starting with the most frequent abnormal signal, the signal level L1 fuse is triggered sequentially, and the total number of global signals is recalculated after each signal is fused.

[0057] Repeat the above process until the total global signal volume drops below the total global signal volume threshold, then stop the circuit breaker.

[0058] Furthermore, the adaptive circuit breaker duration management includes:

[0059] The default value for the circuit breaker duration is preset, and the circuit breaker signal is not forwarded to upper-layer applications during the circuit breaker control period;

[0060] During circuit breaker control, maintain the circuit breaker status of the circuit breaker signal, including:

[0061] Silent monitoring mechanism: During the circuit breaker control period, the underlying protocol stack continuously receives the circuit breaker signal and counts its reception frequency at a preset statistical period;

[0062] Early recovery mechanism: If the receiving frequency of the circuit-broken signal during the circuit breaker control period is continuously lower than the single signal frequency threshold for multiple preset statistical periods, the circuit breaker will be terminated early and normal forwarding will be restored.

[0063] Tiered penalty mechanism: If multiple statistical cycles are preset during the circuit breaker control period and the receiving frequency triggers the circuit breaker, the circuit breaker duration of that signal will be doubled in a tiered manner according to the default value.

[0064] According to a second aspect of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0065] The memory stores a computer program that, when executed by the processor, causes the processor to perform steps such as the dynamic fuse breaking method for SOME / IP Ethernet signals based on QNX-side SOA services.

[0066] According to a third aspect of the present invention, a computer-readable storage medium is provided, comprising: storing a computer program executable by an electronic device, wherein when the computer program is run on the electronic device, the electronic device performs steps such as a dynamic fuse-breaking method for SOME / IP Ethernet signals based on QNX-side SOA services.

[0067] According to a fourth aspect of the present invention, a vehicle infotainment system is provided, comprising:

[0068] Electronic devices for implementing steps such as a dynamic fuse-breaking method for SOME / IP Ethernet signals based on QNX-side SOA services;

[0069] The processor runs a program that, when running, executes steps such as the dynamic fuse-breaking method for SOME / IP Ethernet signals based on QNX-side SOA services from data output by the electronic device.

[0070] Storage medium for storing programs that, when running, execute steps such as the SOME / IP Ethernet signal dynamic fuse method based on QNX-side SOA services for data output from electronic devices.

[0071] The above solution achieves the following beneficial technical effects:

[0072] This invention employs a signal-level frequency monitoring and automatic circuit breaker mechanism. When any abnormal signal exceeds a threshold of 100 times / second, a circuit breaker is immediately triggered, fundamentally preventing signal flooding from encroaching on system resources and effectively protecting the stable operation of SOA service processes. This meets the ISO 26262 functional safety requirements for system robustness, significantly enhancing the system's resistance to signal flooding and ensuring functional safety.

[0073] When the total global signal volume exceeds 8000 times / second, this invention employs a "highest frequency signal priority fuse" strategy for tiered current limiting until the total volume recovers to a safe range. This effectively prevents system-level crashes in scenarios where multiple ECUs experience simultaneous abnormalities, significantly improving overall system availability. It achieves global overload protection, preventing system crashes caused by multiple simultaneous signals.

[0074] This invention is based on a statistical model with a 10×100ms sliding time window. It requires that the circuit breaker be triggered only if the threshold is exceeded for N consecutive windows. This effectively identifies and allows legitimate instantaneous peak traffic such as vehicle wake-up and self-test, minimizing the false circuit breaker rate and ensuring the normal operation of the vehicle system is not subject to unintended interference. The anti-false trigger mechanism effectively adapts to the characteristics of vehicle traffic, reducing the false circuit breaker rate.

[0075] This invention's five-level multi-granularity fault isolation capability (signal level → interface level → service level → ECU node level → network domain level) enables the system to automatically select the optimal isolation granularity based on the fault range. When multiple signals from the same ECU are simultaneously abnormal, it directly escalates to node-level isolation, significantly shortening fault propagation time and response time. Multi-granularity fault isolation accurately locates the fault source and accelerates fault handling.

[0076] This invention features continuous silent monitoring during the circuit breaker period, and supports early release of the circuit breaker after the frequency naturally recovers, reducing unnecessary signal limitation duration. A tiered penalty mechanism (2min→4min→8min) effectively suppresses circuit breaker-recovery oscillations, achieving an optimal balance between "rapid recovery" and "oscillation prevention." An adaptive circuit breaker duration mechanism improves system recovery efficiency and reduces excessive current limiting.

[0077] This invention provides permanent access protection for UDS diagnostics, OTA upgrades, and security monitoring signals through a whitelist mechanism. This ensures uninterrupted access under any traffic conditions and guarantees the availability of channels for vehicle diagnostics, remote upgrades, and security monitoring from a systemic perspective, mitigating the risk of system outages. The whitelist protection mechanism ensures the permanent availability of critical channels.

[0078] This invention, through dynamic comparison of the configured expected frequency and the real-time received frequency, enables the system to proactively generate a network health score and report it to the vehicle diagnostic platform. This allows maintenance personnel to detect network anomalies in advance and intervene before the fault escalates, achieving a shift from a passive response to a proactive prevention-based maintenance model. Proactive network health status perception empowers vehicle maintenance and preventative maintenance. Attached Figure Description

[0079] Figure 1 This is a flowchart of a dynamic fuse-breaking method for SOME / IP Ethernet signals based on QNX-side SOA services provided in one or more embodiments of the present invention.

[0080] Figure 2 This is a structural diagram of a dynamic fuse-breaking system for SOME / IP Ethernet signals based on QNX-side SOA services, provided by one or more embodiments of the present invention.

[0081] Figure 3 This is a schematic diagram of a layered architecture for a vehicle infotainment system provided in a specific embodiment of the present invention.

[0082] Figure 4This is a schematic diagram of the circuit breaker decision-making process provided in a specific embodiment of the present invention.

[0083] Figure 5 This is a block diagram of an electronic device structure for a dynamic fuse-breaking method for SOME / IP Ethernet signals based on QNX-side SOA services, provided by one or more embodiments of the present invention. Detailed Implementation

[0084] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0085] Figure 1 This is a flowchart of a dynamic fuse-breaking method for SOME / IP Ethernet signals based on QNX-side SOA services provided in one or more embodiments of the present invention.

[0086] Example 1, as Figure 1 The SOME / IP Ethernet signal dynamic fuse breaking method based on QNX-side SOA services, as shown, includes:

[0087] Step Q1: Perform real-time frequency statistics on the SOME / IP Ethernet signals received by the SOA service on the QNX side;

[0088] Step Q2: Based on prioritizing the release of key signals within the whitelist, single signal frequency threshold judgment and global signal total quantity threshold judgment are performed sequentially for signals outside the whitelist.

[0089] Step Q3: Based on the threshold judgment result, make a multi-granularity circuit breaker decision.

[0090] Based on the threshold judgment results, multi-granularity circuit breaking decisions are made, specifically including: determining the fault range based on the level of the signal judged as abnormal, selecting the corresponding circuit breaking granularity according to the fault range, and controlling the abnormal signal to achieve rate limiting of SOME / IP Ethernet;

[0091] During circuit breaker control, maintain the circuit breaker status of the circuit breaker signal;

[0092] Maintaining the circuit breaker status of the circuit breaker signal includes managing the adaptive circuit breaker duration through a silent monitoring mechanism, an early recovery mechanism, and a tiered penalty mechanism.

[0093] In this embodiment, real-time frequency statistics include: using a layered window mechanism, corresponding to short-time layers and long-time layers, for detection;

[0094] For short time layers, a second-level sliding time window is used to detect sudden anomalies, and a sliding window counter is maintained independently for each signal.

[0095] For the long-term layer, a minute-level periodic statistical window is used for slow flooding detection to detect chronic overload.

[0096] In this embodiment, for sudden anomaly detection, a second-level sliding time window is used, and a sliding window counter is independently maintained for each signal, including:

[0097] When the frequency statistics of N1 consecutive sliding evaluation windows all exceed the single signal frequency threshold, an anomaly is reported to trigger the circuit breaker decision process.

[0098] in,

[0099] The time axis is divided into continuous 100ms fine-grained statistical units, and a sliding evaluation window is formed by 10 continuous fine-grained statistical units.

[0100] In this embodiment, for chronic overload detection, a minute-level periodic statistical window is used to perform slow flooding detection, including:

[0101] Chronic overload determination includes: calculating the average continuous deviation of the signal receiving frequency from the configured expected frequency within a statistical window of 5 minutes;

[0102] When the average deviation continuously exceeds the preset deviation threshold, it is determined to be a chronic overload, triggering current limiting and / or an alarm;

[0103] Slow flooding determination includes: constructing a time series of the signal reception frequency and fitting the frequency change slope of the most recent N2 minute-level periodic statistical windows;

[0104] When the slope is consistently positive and the statistical windows for M consecutive minute periods are all positive, it is determined to be a gradual flooding trend, triggering flow restriction and / or an early warning.

[0105] In this embodiment, selecting the corresponding fuse granularity based on the fault range includes:

[0106] Based on the level to which the abnormal signal belongs, the fault range is determined, and the fuse granularity is automatically selected, specifically including:

[0107] Signal level L1: When a single non-whitelisted signal exceeds the single signal frequency threshold, the signal is blown off.

[0108] Interface-level L2: When multiple non-whitelisted signals on the same interface malfunction, the Event / Method interface will be shut down.

[0109] Service Level 3: When multiple interfaces of the same service fail, the service instance is tripped.

[0110] ECU node level L4: When multiple / multi-interface non-whitelisted signals of the same ECU are abnormal, all non-whitelisted communications of that ECU will be shut down.

[0111] Network domain level L5: When multiple ECUs in the same network domain have abnormal non-whitelist signals, all non-whitelist communication in the entire network domain will be shut down.

[0112] In this embodiment, when the total global signal volume exceeds the total global signal volume threshold, the circuit breaker decision includes:

[0113] Calculate the reception frequency of each non-whitelisted signal within the current second, and sort the signals that have triggered single signal anomalies from high to low according to their reception frequency;

[0114] Starting with the most frequent abnormal signal, the signal level L1 fuse is triggered sequentially, and the total number of global signals is recalculated after each signal is fused.

[0115] Repeat the above process until the total global signal volume drops below the total global signal volume threshold, then stop the circuit breaker.

[0116] In this embodiment, adaptive circuit breaker duration management includes:

[0117] Based on the default circuit breaker duration of 2 minutes, the circuit breaker signal will not be forwarded to upper-layer applications during the circuit breaker control period.

[0118] During circuit breaker control, maintain the circuit breaker status of the circuit breaker signal, including:

[0119] Silent monitoring mechanism: During the circuit breaker control period, the underlying protocol stack continuously receives the circuit breaker signal and counts its reception frequency at a preset statistical period;

[0120] Early recovery mechanism: If the receiving frequency of the signal that is interrupted during the circuit breaker control period is lower than the single signal frequency threshold for multiple consecutive preset statistical periods and the second-level sliding evaluation window is lower than the single signal frequency threshold, the circuit breaker will be terminated early and normal forwarding will be restored.

[0121] Tiered penalty mechanism: If multiple statistical cycles are preset during the circuit breaker control period and the receiving frequency triggers the circuit breaker, the circuit breaker duration of that signal will be doubled in a tiered manner according to the default value.

[0122] In this embodiment, the tiered penalty mechanism further includes an upper limit constraint step:

[0123] Set an absolute upper limit for the circuit breaker duration;

[0124] The absolute upper limit of the circuit breaker duration includes: the preset total vehicle driving cycle duration;

[0125] Among them, the upper limit constraint is that the duration of a single circuit breaker interruption must not exceed the absolute upper limit.

[0126] When the cumulative duration of the signal interruption exceeds the preset vehicle driving cycle duration, the current signal interruption control will be forcibly unlocked, the penalty level will be reset, and an alarm will be reported to the vehicle diagnostic platform.

[0127] It also includes: after the vehicle is powered off and restarted, the fuse status and penalty count of all signals are automatically reset to zero.

[0128] In this embodiment, the whitelist mechanism also includes a fault tolerance protection step:

[0129] The built-in hard-coded fallback whitelist contains identifiers for UDS diagnostic signals and vehicle safety monitoring signals, and is independent of external configuration files.

[0130] It supports two whitelist configuration files, a primary and a secondary one. If the primary configuration file fails to load, it automatically switches to the backup configuration file. If both configuration files fail, the built-in fallback whitelist is activated.

[0131] In this embodiment, a configuration management step is also included: validating all configurable parameters, including parameter type and range verification and logical consistency verification between parameters. When a parameter fails verification, the system continues to run using the last valid configuration.

[0132] In this embodiment, in the multi-level threshold judgment, the single signal frequency threshold is a configurable 100 times / second, and the global signal total threshold is a configurable 8000 times / second.

[0133] Specifically, in addition to performing single-signal frequency threshold judgment and global signal total threshold judgment sequentially on non-whitelisted signals, the present invention also includes a global signal total threshold judgment based on a common global signal total threshold judgment for both whitelisted and non-whitelisted signals.

[0134] Frequency fluctuations are also possible in whitelists. However, since signals under the whitelist are given priority, the single-signal frequency threshold and the total global signal threshold can be dynamically configured to adapt to both whitelist priority and frequency fluctuations that may occur in both whitelisted and non-whitelisted signals. For example, a circuit breaker strategy may occur in non-whitelisted signals, but its goal is to ensure that whitelisted signals occupy the channel. This can be achieved by sequentially judging the single-signal frequency threshold and dynamically configuring the threshold for non-whitelisted signals.

[0135] Whitelisted and non-whitelisted signals can be placed in a queue. Frequency statistics of the whitelist determine the current single-signal frequency threshold for the non-whitelisted signals. Based on the single-signal frequency thresholds of all non-whitelisted signals, a global total signal threshold is generated. This global total signal threshold cannot exceed the physical limit of the channel system; it's set to ensure certain functions and prioritize certain functions (e.g., identifiers for UDS diagnostic signals and vehicle safety monitoring signals in the whitelist). Under full system load, significant heat generation is inevitable. Setting a threshold upper limit and the whitelist's preemptive share can temporarily handle data surges. However, if the surge persists for an extended period, the global total signal threshold can be compressed to accommodate chronic overload detection and systematically maintain system stability.

[0136] Figure 2 This is a structural diagram of a dynamic fuse-breaking system for SOME / IP Ethernet signals based on QNX-side SOA services, provided by one or more embodiments of the present invention.

[0137] Example 2, as Figure 2 The SOME / IP Ethernet signal dynamic fuse system based on QNX-side SOA services shown includes:

[0138] The frequency statistics module is used to perform real-time frequency statistics on the SOME / IP Ethernet signals received by the SOA service on the QNX side.

[0139] The threshold judgment module is used to prioritize the release of key signals within the whitelist, and to sequentially perform single signal frequency threshold judgment and global signal total amount threshold judgment on non-whitelist signals.

[0140] The circuit breaker decision module is used to make multi-granularity circuit breaker decisions based on the results of threshold judgment;

[0141] The circuit breaker control module is used to make multi-granularity circuit breaker decisions based on the results of threshold judgment, including: determining the fault range based on the level of the signal judged as abnormal, selecting the corresponding circuit breaker granularity according to the fault range, and performing circuit breaker control on the abnormal signal to achieve rate limiting of SOME / IP Ethernet;

[0142] The fuse maintenance module is used to maintain the fuse status of the fused signal during fuse control.

[0143] Maintaining the circuit breaker status of the circuit breaker signal includes managing the adaptive circuit breaker duration through a silent monitoring mechanism, an early recovery mechanism, and a tiered penalty mechanism.

[0144] It is worth noting that although this system / device only discloses the above-mentioned modules / units, it does not mean that this system / device is limited to the above-mentioned basic functional modules. On the contrary, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can add one or more functional modules in combination with the prior art to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. It cannot be assumed that the scope of protection of the claims of this invention is limited to the above-disclosed basic functional modules just because this embodiment only discloses a few basic functional modules.

[0145] Example 3, in a specific embodiment, discloses a dynamic circuit breaking method for SOME / IP Ethernet signals. Using an SOA service running on the QNX real-time operating system as the core execution entity, it achieves real-time monitoring, dynamic circuit breaking, and adaptive recovery of SOME / IP Ethernet signals by embedding multi-layered detection and control logic in the signal receiving link. The overall system architecture is as follows: Figure 2 As shown, the system is divided into four layers from bottom to top:

[0146] 1. In-vehicle Ethernet domain: Includes ECUs in various domains such as IVI, ADAS, instrument panel, BCM, etc., serving as the sender of SOME / IP signals;

[0147] 2. SOME / IP protocol stack: runs in QNX user space and is responsible for signal reception and reporting;

[0148] 3. SOA Dynamic Circuit Breaker Engine: The core module, comprising six sub-modules, is responsible for all monitoring, decision-making, and control logic;

[0149] 4. Upper-layer application services: Receive filtered normal signals and maintain stable operation of business logic.

[0150] In this embodiment, the core module includes:

[0151] 1. Signal receiving and monitoring module:

[0152] This module continuously performs real-time frequency statistics on all SOME / IP Ethernet signals received by the QNX-side SOA service, acting as the "sensory nerve" of the entire circuit breaker engine. To avoid false triggering caused by occasional fluctuations in the single-second statistical window, this module introduces a sliding time window mechanism:

[0153] 1) Divide the time axis into continuous 100ms fine-grained statistical units;

[0154] 2) A 1-second sliding evaluation window is formed by 10 consecutive 100ms windows;

[0155] 3) Maintain an independent sliding window counter for each signal channel and count the signal reception within each fine-grained window;

[0156] 4) An abnormal event is reported to the judgment module and the subsequent circuit breaker decision process is triggered only when the frequency statistics of N consecutive sliding windows (N can be set by the configuration file) all exceed the threshold.

[0157] 5) Effectively filters legitimate traffic peaks and normal instantaneous jitter such as single-frame bursts during vehicle wake-up to avoid accidental circuit breakers.

[0158] 2. Multi-level threshold judgment module

[0159] This module performs two levels of threshold judgment based on the statistical data reported by the signal reception monitoring module:

[0160] 1) Level 1: Single Signal Frequency Threshold Judgment – ​​Independently judges whether the receiving frequency of each signal exceeds 100 times / second (default value, configurable). If it exceeds, a signal-level fuse is triggered to isolate the single abnormal signal;

[0161] 2) Second level: Global signal volume threshold judgment – ​​Count the total number of SOME / IP signals received by the QNX-side SOA service per second and determine whether it exceeds 8000 times / second (default value, configurable). If it exceeds, the global total volume circuit breaker mechanism is triggered to control and limit the global signal traffic.

[0162] Before performing any threshold judgment, the whitelist is checked first. Signals in the whitelist are allowed to pass directly and do not participate in any threshold judgment or circuit breaker decision.

[0163] Among them, the implementation of slow flood attack detection:

[0164] Fixed-frequency threshold schemes (e.g., 100 times / second) are effective for detecting bursty signal flooding, but they have a potential blind spot in the face of "slow flooding" attack modes: that is, the signal transmission frequency remains below the threshold for a long time (e.g., 95 times / second), or increases at an extremely slow rate, so that the frequency per second never triggers the threshold, but the accumulated system resources consumed have far exceeded the normal level. Therefore, this invention proposes the following supplementary mechanism for slow flooding detection:

[0165] (a) Long-term window cumulative deviation detection

[0166] Based on the second-level sliding window, a minute-level long window statistical dimension is added: with a statistical period of 5 minutes, the average continuous deviation of the signal receiving frequency from the configured expected frequency (Persistent Deviation Score, PDS) is calculated. If the PDS continuously exceeds the threshold (such as 60% of the expected frequency for 5 minutes), it is judged as "chronic overload", triggering current limiting or alarm, without relying on a single second frequency exceeding the absolute threshold.

[0167] (b) Frequency trend slope detection

[0168] A time series of signal reception frequencies is constructed, and linear regression is used to fit the frequency slope of the most recent N statistical windows. When the slope is consistently positive (frequency continues to increase) and remains positive for M consecutive windows (M is configurable), it is determined to be a "gradual flooding" trend, triggering an early warning or flow restriction in advance without waiting for the frequency to actually exceed the absolute threshold.

[0169] Note: Slow flooding is a type of distributed denial-of-service (DDoS) attack or abnormal traffic behavior, characterized by low rate and long duration.

[0170] Characteristic manifestation: below the threshold: the number of requests per second or bandwidth usage may be far below the alarm threshold of traditional security devices, thereby bypassing the protection system based on fixed thresholds.

[0171] Resource exhaustion: Although the single traffic is small, maintaining the connection for a long time (such as HTTP Slowloris, SlowPOST) consumes server threads, memory or database connection pool, causing legitimate users to be unable to obtain services.

[0172] Highly deceptive: Traffic patterns may mimic normal business fluctuations (such as cache refilling, natural traffic growth caused by hot events), making it extremely deceptive.

[0173] 3. Circuit breaker decision-making and multi-granularity control module

[0174] When the threshold judgment module triggers a circuit breaker event, this module automatically selects the optimal circuit breaker granularity based on the fault range and severity to achieve precise fault isolation.

[0175] The specific decision-making strategy for global total circuit breaker is as follows:

[0176] 1) When the total number of global signals exceeds 8000 times / second, count the receiving frequency of each signal in the current second and sort them from high to low;

[0177] 2) Trigger the signal-level fuses sequentially, starting with the highest frequency signal;

[0178] 3) After each signal is blown, the total global count is recalculated;

[0179] 4) Repeat the above process until the total global count drops below 8000 times / second, then stop the circuit breaker.

[0180] 5) This strategy ensures that abnormal signals with the "largest traffic contribution" are restricted first, while preserving the normal reception of more normal signals to the greatest extent possible.

[0181] 4. Fuse Status Management Module

[0182] This module is responsible for maintaining the state machine of all circuit-broken signals, enabling adaptive circuit breaker duration management.

[0183] 1) Default circuit breaker duration: After a signal is circuit breaker interrupted, it will enter a 2-minute circuit breaker period, during which the signal will not be forwarded to the upper layer;

[0184] 2) Silent monitoring mechanism: During the circuit breaker period, the underlying protocol stack continuously receives the signal but does not report it, and continuously counts its reception frequency through a sliding window;

[0185] 3) Early recovery mechanism: If the receiving frequency of the interrupted signal is lower than the set threshold for multiple consecutive sliding windows during the circuit breaker period, the fault is considered to have been eliminated, the circuit breaker is terminated early, and normal forwarding is restored.

[0186] 4) Stepped penalty mechanism: For signals that trigger circuit breakers multiple times within 5 minutes, the circuit breaker duration will be doubled in a stepped manner (2min→4min→8min→……) to prevent the system from falling into a volatile state of frequent circuit breakers and recovery when the fault is not completely resolved;

[0187] 5) Reset penalty count: If the signal remains in a normal state for a certain period of time (configurable), the penalty count will be reset to zero, restoring the default 2-minute fuse duration.

[0188] The tiered penalty upper limit mechanism includes the following: While improving oscillation suppression capabilities, without an upper limit constraint, a hardware component with persistent communication defects may become chronically disabled due to the doubling of fuse duration, affecting the overall vehicle function. Therefore, this invention sets the following upper limit constraint mechanism for the tiered penalty duration:

[0189] 1) Maximum Circuit Breaker Duration (MaxCircuitBreakDuration): Sets a hard limit on the circuit breaker duration for each signal or signal group via configuration file (the recommended default value is 32 minutes). Regardless of how many times the tiered penalty is triggered, the duration of a single circuit breaker must not exceed this limit to prevent permanent signal failure.

[0190] 2) Forced unlocking trigger condition: When the cumulative fuse failure time of a certain signal exceeds the duration of one complete driving cycle of the whole vehicle (configurable, 1 hour is recommended), the system will trigger forced unlocking, reset the penalty level, and report a "long-term abnormal signal" alarm to the whole vehicle diagnostic platform, prompting maintenance personnel to intervene and troubleshoot hardware faults.

[0191] 3) Vehicle restart reset mechanism: After the vehicle is powered off and restarted (IG OFF→ON), the step penalty count and fuse status of all signals are automatically cleared to zero. The vehicle restart is used as the hard reset point after the fault is repaired, so as to avoid the impact of the historical penalty status on the normal driving cycle.

[0192] 5. Configuration Management Module:

[0193] This embodiment supports flexible configuration of all key parameters via external configuration files, adapting to different vehicle models and application scenarios without code modification. Configurable parameters include:

[0194] 1) Single signal frequency fuse threshold (default: 100 times / second)

[0195] 2) Global signal total fusing threshold (default: 8000 times / second)

[0196] 3) Sliding window fine-grained unit duration (default: 100ms)

[0197] 4) Number of sliding window combinations (default: 10)

[0198] 5) Number of consecutive window triggers exceeding the threshold, N (anti-accidental touch parameter)

[0199] 6) Default circuit breaker duration (default: 2 minutes)

[0200] 7) Early recovery of the number of consecutive windows

[0201] 8) Tiered penalty trigger conditions (threshold for multiple triggers within 5 minutes)

[0202] 9) Tiered penalty multiplier

[0203] 10) Non-fuseable whitelist of signals (supports configuration at multiple granularities such as Signal ID and Service ID)

[0204] 11) Expected receiving frequencies for each signal (for network health assessment)

[0205] The whitelist configuration fallback and fault tolerance protection mechanism includes: The whitelist mechanism uses "permanent allow" as the highest priority protection method; however, if the whitelist configuration file itself has errors (such as missing configuration items, incorrect ID format, file corruption, etc.), it may cause critical signals that should be protected to be unexpectedly broken, or illegal signals to be incorrectly allowed, leading to more serious system behavior anomalies. Therefore, this invention introduces the following whitelist fault tolerance protection mechanism in the configuration management module:

[0206] 1) Built-in Hardcoded Fallback Whitelist: A minimal fallback whitelist is built into the SOA service code as a static constant, containing core signal identifiers that must not be interrupted, such as UDS diagnostic signals and vehicle safety monitoring signals. This fallback whitelist exists independently of the external configuration file. Even if the external configuration file is completely missing or corrupted, the built-in whitelist remains effective, ensuring the bottom-line protection of security-critical channels.

[0207] 2) Whitelist Configuration with Dual Replica Hot Standby (Primary / Backup): Supports configuring two whitelist file paths, a primary and a secondary one. If the primary configuration file fails to load, it automatically switches to the backup file; if both files are invalid, the built-in fallback whitelist is activated. Replica switch events are reported via a diagnostic interface, prompting maintenance personnel to repair configuration anomalies.

[0208] The implementation of the configuration parameter validity verification mechanism includes: The configurability of all parameters grants the system great flexibility, but unreasonable configuration values ​​(such as setting the threshold to 0, setting the window number to a negative value, or an incorrect whitelist format) will lead to abnormal behavior of the circuit breaker engine, and may even produce consequences more serious than not configuring them at all. Therefore, this invention introduces a systematic parameter verification mechanism in the configuration management module:

[0209] 1) Type & Range Validation: When the system starts and loads the configuration, it performs strict type checks and numerical range constraint verification on each parameter. For example: the single signal threshold must be a positive integer and not less than 10 (to prevent excessive sensitivity leading to a large number of false circuit breakers); the number of sliding windows must be between 2 and 60; the circuit breaker duration must be greater than 0 and not exceed MaxCircuitBreakDuration. If any parameter exceeds the valid range, the system will refuse to load the configuration, report an alarm, and continue running using the last valid configuration.

[0210] 2) Cross-Parameter Consistency Check: This check verifies the logical constraints between parameters to prevent situations where individual parameters are valid but their combination is invalid. For example: the number of consecutive windows for early recovery must be less than the total number of sliding windows; the upper limit of the tiered penalty duration must be greater than the basic circuit breaker duration; and the global total threshold must be greater than the lower limit of the sum of the individual thresholds of all signals. Otherwise, the global threshold will trigger before the single signal threshold, rendering the single signal protection ineffective.

[0211] 3) Whitelist Integrity Check: Verify the format validity of each entry in the whitelist (Signal ID format, Service ID range, etc.) and attempt to cross-compare it with the currently subscribed signal set; if a whitelist entry references a signal ID that does not exist in the system, record a warning log (possibly due to incorrect configuration input), but do not prevent startup.

[0212] 4) Configuration file integrity check: The configuration file is generated with an SHA-256 checksum; the checksum is compared each time it is loaded. If they do not match, it means that the file has been accidentally modified or corrupted, and the file is refused to be loaded and switched to the backup configuration.

[0213] 5) Runtime configuration hot update two-phase commit: When running configuration hot update is supported, a full verification (including type, range, logical consistency, whitelist format, etc.) is first completed in the pre-verification sandbox. Only after all verifications pass can the changes be committed and take effect. If any verification fails, the current running configuration will be rolled back to ensure the atomicity of configuration changes.

[0214] 6. Network health status monitoring and reporting module

[0215] This module dynamically compares the preset "should be received" frequencies for each signal in the configuration file with the real-time statistical "actual received" frequencies to proactively determine whether the network communication status is within a healthy range.

[0216] 1) Health status definition: If the actual received frequency is within a reasonable deviation range of the expected frequency (with configurable upper and lower limits), it is considered healthy;

[0217] 2) Definition of sub-health state: If the actual frequency exceeds the expected upper limit but does not reach the circuit breaker threshold, it is judged as sub-health and an early warning is issued;

[0218] 3) Definition of abnormal state: When the actual frequency reaches or exceeds the circuit breaker threshold, it is judged as abnormal, triggering the circuit breaker and reporting an alarm.

[0219] 4) Health score reporting: Periodically generate a global network health score and report it to the vehicle diagnostic platform through a diagnostic interface (such as UDS DID reading), supporting remote OBD reading.

[0220] Example 4, in this example, as Figure 4 As shown, the complete circuit breaker decision-making process is as follows:

[0221] 1. The SOA service receives SOME / IP Ethernet signals in real time and calculates the signal frequency using a sliding window;

[0222] 2. Prioritize checking the whitelist; signals from the whitelist are allowed to proceed directly without further processing.

[0223] 3. Perform single-signal frequency threshold judgment on non-whitelisted signals (>100 times / second);

[0224] 4. If the signal-level threshold is triggered, the signal-level circuit breaker will be activated and silent monitoring and tiered penalty timing will be started.

[0225] 5. If the signal-level threshold is not triggered, perform a global total threshold check (>8000 times / second).

[0226] 6. If the global threshold is triggered, circuit breakers will be triggered sequentially according to the highest frequency priority strategy until the total global amount falls back to the safe range;

[0227] 7. If none of the thresholds are triggered, the signal is forwarded to the upper-layer application normally, and the network health status is updated at the same time;

[0228] 8. During the circuit breaker period, the system will continuously monitor silently and automatically release the circuit breaker when the conditions for early recovery are met, or wait for the circuit breaker duration to expire before resuming.

[0229] This embodiment is compared with existing solutions:

[0230] In the field of communication overload protection and traffic management, there are currently several related technical solutions, but none of them can directly meet the unique requirements of the SOME / IP Ethernet signal scenario on the vehicle-mounted QNX side:

[0231] (a) Internet microservice circuit breaker frameworks (such as Netflix Hystrix, Resilience4j, Sentinel)

[0232] These frameworks are widely used in cloud-native microservice architectures, implementing service-level circuit breaking through mechanisms such as thread pool isolation, semaphore isolation, and timeout control.

[0233] Its design is geared towards HTTP / RESTful API call scenarios, relying on a synchronous request-response model, which is fundamentally different from the publish / subscribe asynchronous event model of in-vehicle SOME / IP.

[0234] It does not provide fine-grained signal-level monitoring capabilities and cannot independently count or fuse the receiving frequency of a single SOME / IP signal.

[0235] The lack of a whitelist priority release mechanism makes it unsuitable for in-vehicle safety requirements where critical channels such as diagnostics and OTA cannot be interrupted.

[0236] (b) AUTOSAR Adaptive Platform Communication Management (ARA CM)

[0237] The AUTOSAR AP provides a Communication Management Module (CM) and a SOME / IP protocol stack, but it mainly focuses on service discovery and routing management, and does not have built-in signal frequency monitoring and circuit breaker protection functions.

[0238] When the SOME / IP signal transmission frequency rises abnormally, the AP platform cannot automatically limit the current or blow up the abnormal signal, requiring the upper-layer application to handle it itself, lacking platform-level unified protection capabilities.

[0239] The adaptation and support for QNX RTOS is limited, especially in terms of lightweight deployment and real-time performance assurance under the QNX microkernel architecture.

[0240] (c) Traditional firewall / gateway filtering in vehicle networks

[0241] Traditional vehicle gateways perform static packet filtering based on MAC address, VLAN ID, IP 5-tuple, etc., which is a coarse-grained whitelist / blacklist mechanism.

[0242] It cannot perceive the time dimension characteristic of signal frequency, and cannot distinguish between legitimate signals within the normal frequency range and flooded signals at abnormal frequencies.

[0243] Lacking dynamic adjustment capabilities, rule changes require rewriting the configuration, making real-time adaptive circuit breaking impossible.

[0244] Figure 5 This is a block diagram of an electronic device for an emergency avoidance method for vehicles accidentally pressing the accelerator, provided in one or more embodiments of the present invention.

[0245] Example 5, as Figure 5 As shown, the present invention provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0246] The memory stores a computer program, which, when executed by the processor, causes the processor to perform steps for an emergency avoidance method when a vehicle accidentally presses the accelerator.

[0247] The present invention also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of an emergency avoidance method for a vehicle accidentally pressing the accelerator.

[0248] The present invention also provides an in-vehicle infotainment system, comprising:

[0249] Electronic equipment used to implement emergency avoidance procedures for vehicles that have accidentally pressed the accelerator pedal;

[0250] The processor runs a program, and when the program runs, it executes the steps of an emergency avoidance method based on data output from electronic devices when a vehicle accidentally presses the accelerator.

[0251] Storage medium used to store programs that, when running, execute steps for emergency avoidance methods when a vehicle accidentally presses the accelerator pedal, based on data output from an electronic device.

[0252] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0253] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0254] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0255] Electronic devices can also obtain reset commands corresponding to storage media. These reset commands are provided by the supplier, and the reset commands for different storage media can be the same or different, which is not limited here.

[0256] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0257] For ease of description, the above apparatus is described by dividing it into various units and modules according to their functions. Of course, in implementing this invention, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0258] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0259] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0260] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that the present invention can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of the present invention.

[0261] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for dynamic fuse breaking of SOME / IP Ethernet signals based on QNX-side SOA services, characterized in that, include: Perform real-time frequency statistics on the SOME / IP Ethernet signals received by the SOA service on the QNX side; Allow key signals within the whitelist to pass, perform single-signal frequency threshold judgment on non-whitelist signals, and select to perform global signal total quantity threshold judgment based on the single-signal frequency threshold judgment result; Based on the threshold judgment result, a multi-granularity circuit breaker decision is made, which specifically includes: determining the fault range based on the level of the signal judged as abnormal, selecting the corresponding circuit breaker granularity according to the fault range, and controlling the abnormal signal through circuit breaker. During the circuit breaker management period, the circuit breaker status of the circuit breaker signal is maintained, which specifically includes: managing the adaptive circuit breaker duration through a silent monitoring mechanism, an early recovery mechanism, and a tiered penalty mechanism.

2. The dynamic fuse breaking method for SOME / IP Ethernet signals based on QNX-side SOA services according to claim 1, characterized in that, The real-time frequency statistics include: employing a layered window mechanism, performing detection separately for short-time and long-time time layers. For the short time layer, a second-level sliding time window is used, and a sliding window counter is independently maintained for each signal to detect sudden anomalies; For the longer time frame, a minute-level periodic statistical window is used for slow flood detection.

3. The dynamic fuse breaking method for SOME / IP Ethernet signals based on QNX-side SOA services according to claim 2, characterized in that, A second-level sliding time window is used, and a sliding window counter is independently maintained for each signal to perform sudden anomaly detection, including: One second is divided into multiple consecutive millisecond-level sliding evaluation windows. When the frequency statistics of N1 consecutive sliding evaluation windows all exceed the single signal frequency threshold, an anomaly is reported to trigger the circuit breaker decision process.

4. The method for dynamic fuse breaking of SOME / IP Ethernet signals based on QNX-side SOA services according to claim 2, characterized in that, Slow flood detection is performed using a minute-level periodic statistical window, including: Chronic overload determination includes: calculating the average continuous deviation of the signal receiving frequency from the configured expected frequency using a statistical window with a duration of minutes; When the average value of the continuous deviation exceeds the preset deviation threshold continuously, it is determined to be a chronic overload, triggering current limiting and / or an alarm; The progressive flooding determination includes: constructing a time series of the signal reception frequency and fitting the frequency change slope of the most recent N2 minute-level periodic statistical windows; When the slope is consistently positive and all M consecutive minute-level periodic statistical windows are positive, it is determined to be a gradual flooding trend, triggering flow restriction and / or an early warning.

5. The method for dynamic fuse breaking of SOME / IP Ethernet signals based on QNX-side SOA services according to claim 1, characterized in that, The step of selecting the corresponding fuse size based on the fault range includes: Based on the level to which the abnormal signal belongs, the fault range is determined, and the fuse granularity is automatically selected, specifically including: Signal level L1: When a single non-whitelisted signal exceeds the single signal frequency threshold, the signal is blown off. Interface-level L2: When multiple non-whitelisted signals on the same interface malfunction, the circuit breaker will trip the Event or Method interface. Service Level 3: When multiple interfaces of the same service fail, the service instance is tripped. ECU node level L4: When multiple or multiple interfaces of the same ECU are abnormal, all non-whitelisted communications of the ECU will be shut down. Network domain level L5: When multiple ECUs in the same network domain have abnormal non-whitelist signals, all non-whitelist communication in the entire network domain will be shut down.

6. The method for dynamic fuse breaking of SOME / IP Ethernet signals based on QNX-side SOA services according to claim 1, characterized in that, When the total global signal volume exceeds the total global signal volume threshold, the circuit breaker decision includes: Calculate the reception frequency of each non-whitelisted signal within the current second, and sort the signals that have triggered single signal anomalies from high to low according to their reception frequency; Starting with the most frequent abnormal signal, the signal level L1 fuse is triggered sequentially, and the total number of global signals is recalculated after each signal is fused. Repeat the above process until the total global signal volume drops below the total global signal volume threshold, then stop the circuit breaker.

7. The method for dynamic fuse breaking of SOME / IP Ethernet signals based on QNX-side SOA services according to claim 1, characterized in that, The adaptive circuit breaker duration management includes: The default value for the circuit breaker duration is preset, and the circuit breaker signal is not forwarded to upper-layer applications during the circuit breaker control period; During circuit breaker control, maintain the circuit breaker status of the circuit breaker signal, including: Silent monitoring mechanism: During the circuit breaker control period, the underlying protocol stack continuously receives the circuit breaker signal and counts its reception frequency at a preset statistical period; Early recovery mechanism: If the receiving frequency of the circuit-broken signal during the circuit breaker control period is continuously lower than the single signal frequency threshold for multiple preset statistical periods, the circuit breaker will be terminated early and normal forwarding will be restored. Tiered penalty mechanism: If multiple statistical cycles are preset during the circuit breaker control period and the receiving frequency triggers the circuit breaker, the circuit breaker duration of that signal will be doubled in a tiered manner according to the default value.

8. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program that, when executed by a processor, causes the processor to perform the steps of the SOME / IP Ethernet signal dynamic fuse breaking method based on QNX-side SOA services as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, include: The device stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the SOME / IP Ethernet signal dynamic fuse breaking method based on QNX-side SOA services as described in any one of claims 1 to 7.

10. A vehicle infotainment system, characterized in that, include: An electronic device for implementing the steps of the SOME / IP Ethernet signal dynamic fuse breaking method based on QNX-side SOA services as described in any one of claims 1 to 7; A processor that runs a program that, when the program is running, executes the steps of the SOME / IP Ethernet signal dynamic fuse breaking method based on QNX-side SOA services as described in any one of claims 1 to 7, from data output by the electronic device. A storage medium for storing a program that, when running, performs the steps of the SOME / IP Ethernet signal dynamic fuse-off method based on QNX-side SOA services as described in any one of claims 1 to 7 on data output from an electronic device.

Images