Vehicle-mounted ethernet bandwidth optimization method and device, vehicle and medium

Abstract

The application mainly relates to the technical field of automobile engineering. The application discloses a vehicle-mounted Ethernet bandwidth optimization method, device, vehicle and medium, and the method comprises the following steps: identifying the service domain type to which a received data stream belongs; generating a plurality of priority queues arranged in a preset priority order; distributing the data stream to a target queue according to the service domain type; and detecting the transmission delay of each queue. If the target queue delay is greater than a threshold value, the bandwidth upper limit of all queues with a lower priority than the queue is reduced to a first bandwidth value corresponding to the priority; if the delay is not greater than the threshold value, the bandwidth upper limit of the queues is increased to a second bandwidth value corresponding to the priority, and the second bandwidth value of the same queue is greater than the first bandwidth value. Through the above lightweight delay feedback adjustment mechanism, the application realizes dynamic differentiated bandwidth allocation for multi-domain services on a low-complexity gateway chip with low complexity, effectively alleviates the bandwidth bottleneck and guarantees the real-time performance of each service.

Description

Technical Field

[0001] This invention relates to the field of automotive engineering technology, specifically to a method, apparatus, vehicle, and medium for optimizing in-vehicle Ethernet bandwidth. Background Technology

[0002] As automotive electronic and electrical architecture evolves towards centralized computing and regional control, in-vehicle networks need to simultaneously support multiple types of services, including advanced driver assistance systems (ADAS), smart cockpits, interconnected communications, and classic control. These services have significantly different requirements for bandwidth, latency, and jitter. For example, ADAS requires extremely low latency, cockpit services require high throughput, while control services rely on strictly deterministic latency. Automotive Ethernet, with its high bandwidth and scalability, has become the preferred choice for backbone networks; however, the limited bandwidth resources make congestion and latency issues highly likely when multiple domain services compete for the same link. TSN technologies such as IEEE 802.1Qbv (Time-Aware Shaper) and 802.1Qav (Credit Shaper) have also been introduced into the automotive network field. 802.1Qbv provides deterministic transmission for time-sensitive flows through a gating scheduling mechanism, while 802.1Qav limits bandwidth usage for non-critical flows through a credit mechanism.

[0003] Vehicle gateway chips, limited by power consumption and cost, have significantly lower computing power and cache compared to industrial switching chips. 802.1Qbv requires global time synchronization and periodic gating list parsing, while 802.1Qav requires maintaining multiple credit value counters and calculating transmission timing in real time. These operations consume numerous processing cycles on low-performance chips. More importantly, the amount of perception data for assisted driving fluctuates with weather and road conditions, the cockpit video bitrate changes in real time with the displayed content, and the interconnection communication load frequently changes with external network conditions. Faced with these dynamic demands, existing TSN mechanisms can only rely on offline pre-configuration of fixed gating lists or static credit value parameters, failing to perform differentiated bandwidth reallocation based on the instantaneous needs of various domain services during operation. Forcibly introducing dynamic adjustment algorithms would drastically increase the complexity of scheduling decisions, further burdening the chip. Summary of the Invention

[0004] This invention provides a method, apparatus, vehicle, and medium for optimizing in-vehicle Ethernet bandwidth. It enables dynamic, differentiated, deterministic bandwidth allocation for multi-domain services with low complexity on an in-vehicle low-computing-power gateway chip, thereby effectively alleviating bandwidth bottlenecks and ensuring the real-time requirements of various services.

[0005] This invention provides a method for optimizing in-vehicle Ethernet bandwidth, the method comprising: The received data streams are identified to determine the service domain type to which each data stream belongs; Multiple priority queues are generated, and each priority queue is arranged in a preset priority order; Based on the business domain type of each data flow, each data flow is assigned to a target priority queue; Detect the transmission delay value for each of the priority queues; If the transmission delay value of the target priority queue is greater than the preset threshold, the bandwidth limit of each priority queue after the target priority queue will be reduced to the first bandwidth limit value corresponding to the priority. There is a corresponding relationship between the bandwidth limit value of the priority queue and the priority of the priority queue. If the transmission delay value of the target priority queue is less than the preset threshold, then the bandwidth limit value of each priority queue whose priority order is after the target priority queue is increased to the second bandwidth limit value corresponding to the priority, wherein, for the same priority queue, the second bandwidth limit value is greater than the first bandwidth limit value.

[0006] Optionally, each priority queue is provided with a corresponding bandwidth reservation ratio value, wherein the bandwidth reservation ratio value is used to set the minimum bandwidth value of the priority queue, and there is a corresponding relationship between the bandwidth reservation ratio value of the priority queue and the priority of the priority queue. The in-vehicle Ethernet bandwidth optimization method also includes: The data flow status of each priority queue is detected. When the target priority queue is inactive, the reserved bandwidth resources of the target priority queue are allocated to at least one active priority queue based on the bandwidth reservation ratio value corresponding to the target priority queue.

[0007] Optionally, the in-vehicle Ethernet bandwidth optimization method further includes: Generate the scheduling weight corresponding to each of the priority queues; A weighted round-robin scheduling method is adopted, and data frames are sequentially retrieved from each priority queue and sent according to the scheduling weight; During the scheduling process, when the instantaneous bandwidth utilization rate of the target priority queue reaches the current bandwidth limit value corresponding to the target priority queue, data frames are stopped being retrieved from the target priority queue until the instantaneous bandwidth utilization rate is lower than the current bandwidth limit value.

[0008] Optionally, the bandwidth upper limit can be adjusted in the following ways: Generate a token bucket corresponding to each of the priority queues, and each of the token buckets has a commitment information rate; Tokens are injected into the token bucket at the promised information rate, wherein when the bandwidth limit of the priority queue is adjusted, the promised information rate of the token bucket corresponding to the priority queue is updated. When there is a data frame to be sent in the target priority queue, it is determined whether the number of available tokens in the token bucket corresponding to the target priority queue is greater than or equal to the length of the data frame to be sent. If so, the number of tokens corresponding to the length is consumed and the data frame to be sent is sent. If not, the sending of the data frame to be sent is stopped.

[0009] Optionally, the method for adjusting the upper limit of bandwidth also includes: Generate a data frame matching rule for each priority queue, the data frame matching rule being used to identify data frames belonging to the target service subclass within the same priority queue; Determine the rate limiting threshold of the data frame matching rule, wherein when the bandwidth upper limit of the priority queue is adjusted, the rate limiting threshold in the data frame matching rule corresponding to the priority queue is updated; When a target data frame in the priority queue belongs to the target service subclass defined by the data frame matching rule, if the target data frame exceeds the rate limit threshold, the target data frame is discarded.

[0010] Optionally, the in-vehicle Ethernet bandwidth optimization method further includes: Detect network status indicators across multiple dimensions, and perform a weighted and comprehensive calculation on these indicators to generate a comprehensive status score. When the overall status score is lower than a preset threshold and the duration reaches a preset hysteresis duration, an activation command is sent to the hardware acceleration module to achieve hardware acceleration processing. When the overall status score exceeds the threshold, it is determined that the current data stream load exceeds the hardware acceleration processing capability, and a shutdown command is sent to the hardware acceleration module to switch the data stream from hardware acceleration processing to software processing.

[0011] Optionally, the in-vehicle Ethernet bandwidth optimization method further includes: When the operating status of the software layer traffic control component is detected to meet the preset fault triggering conditions, the software layer traffic control is determined to be in failure, and the bandwidth upper limit of at least one priority queue whose priority order is after the target priority queue is set as the safe bandwidth upper limit, wherein the safe bandwidth upper limit is lower than the first bandwidth upper limit of the priority queue in the normal state.

[0012] The present invention also provides an in-vehicle Ethernet bandwidth optimization device, the device comprising: The identification module is used to identify the received data streams in order to determine the business domain type to which each data stream belongs; A sorting module is used to generate multiple priority queues, each of which is arranged in a preset priority order; The allocation module is used to allocate each data stream to a target priority queue based on the service domain type of each data stream; A detection module is used to detect the transmission delay value of each of the priority queues; The adjustment module is configured to, if the transmission delay value of the target priority queue is greater than a preset threshold, reduce the upper limit of the bandwidth of each priority queue whose priority order follows the target priority queue to a first upper limit of bandwidth corresponding to the priority, wherein there is a corresponding relationship between the upper limit of bandwidth of the priority queue and the priority of the priority queue; if the transmission delay value of the target priority queue is less than the preset threshold, increase the upper limit of bandwidth of each priority queue whose priority order follows the target priority queue to a second upper limit of bandwidth corresponding to the priority, wherein for the same priority queue, the second upper limit of bandwidth is greater than the first upper limit of bandwidth.

[0013] The present invention also provides a vehicle, the vehicle including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the in-vehicle Ethernet bandwidth optimization method as described in any of the preceding claims.

[0014] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the in-vehicle Ethernet bandwidth optimization method as described in any of the preceding claims.

[0015] The present invention has at least the following beneficial effects: This solution does not rely on global time synchronization or periodic parsing of gating lists, nor does it involve real-time maintenance of multiple credit value counters. It triggers bandwidth adjustments solely by monitoring the transmission latency value of each priority queue. This trigger-based strategy, based on local latency thresholds, simplifies scheduling decisions to a single-dimensional comparison and linear adjustment, resulting in extremely low computational overhead and making it perfectly compatible with the processing capabilities of low-performance gateway chips. The mapping from service domain types to priority queues ensures that sensitive services such as advanced driver assistance systems (ADAS) enter high-priority queues and receive absolute priority forwarding. Simultaneously, bandwidth adjustments only affect all low-priority queues following the target priority queue, rather than causing a global disturbance. This protects the deterministic latency of high-priority services while avoiding mutual interference between different domain services. Through real-time monitoring of latency thresholds and a dual-threshold adjustment mechanism, when high-priority traffic surges, the system quickly tightens low-priority bandwidth to ensure critical services; when the network is idle, the system proactively releases bandwidth to low-priority services, avoiding static waste of bandwidth resources and continuously optimizing overall bandwidth utilization under dynamic changes in multi-domain service loads. In summary, this solution balances deterministic latency guarantees and dynamic bandwidth reuse with minimal computational cost, thereby effectively alleviating bandwidth bottlenecks and meeting the real-time requirements of multi-domain services on low-computing-power chips. Attached Figure Description

[0016] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.

[0017] Figure 1 This is a flowchart illustrating the steps of a method for optimizing Ethernet bandwidth in vehicles. Figure 2 This is a flowchart illustrating the steps involved in implementing a weighted round-robin scheduling strategy in a method for optimizing Ethernet bandwidth in vehicles. Figure 3 This is a flowchart illustrating the steps involved in implementing a hardware and software solution by the central gateway device in a vehicle-mounted Ethernet bandwidth optimization method. Figure 4 This is a flowchart illustrating the steps involved in implementing a traffic control scheme for the infotainment domain software layer within a method for optimizing vehicle Ethernet bandwidth. Figure 5 This is a flowchart illustrating the steps of a dynamic hardware acceleration control method in an in-vehicle Ethernet bandwidth optimization approach. Figure 6 This is a schematic diagram of a vehicle-mounted Ethernet bandwidth optimization device. Figure 7 This is a schematic diagram of the architecture of an in-vehicle Ethernet bandwidth optimization system. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0019] In this technical field, with the rapid development of automotive intelligence and connectivity, the demand for data transmission bandwidth in in-vehicle electronic systems has increased dramatically. Modern automobiles generally adopt a domain controller architecture, including the Autonomous Driving Domain (HAD), the Infotainment Domain (ICC), and the Cockpit Domain (CSC), with data exchange between these domains via a central gateway (CGW). Due to its high bandwidth and low latency characteristics, automotive Ethernet has become the mainstream technology for in-vehicle network communication.

[0020] In automotive Ethernet architectures, the IEEE 802.1p protocol defines a priority-based flow control mechanism, supporting eight priorities (0-7), which can be used to differentiate the Quality of Service (QoS) requirements of different service flows. However, in practical applications, how to reasonably configure priority and bandwidth allocation strategies remains a technical challenge that urgently needs to be solved.

[0021] In addition, TSN technologies such as IEEE 802.1Qbv (Time-Aware Shaper) and 802.1Qav (Credit Shaper) have also been introduced into the field of automotive networks. 802.1Qbv provides deterministic transmission for time-sensitive flows through a gating scheduling mechanism, while 802.1Qav restricts bandwidth usage for non-critical flows through a credit mechanism. However, these technologies have the following shortcomings in practical automotive applications: (1) High configuration complexity, requiring precise time synchronization and gating list design, which places excessively stringent real-time requirements on the automotive system; (2) High requirements for hardware chips, as most automotive CGW chips do not yet fully support all TSN functions; (3) Lack of differentiated bandwidth allocation strategies for automotive multi-domain architectures (HAD / ICC / CSC), making it impossible to dynamically adjust resource allocation according to service priorities. Therefore, under the existing automotive Ethernet chip conditions, how to achieve refined bandwidth management and service isolation based on the general 802.1p priority mechanism remains a technical challenge that urgently needs to be solved.

[0022] Researchers studying this application have found that the current mainstream automotive Ethernet architecture adopts a star topology, with the central gateway acting as the core switching node responsible for data forwarding between domain controllers. Typical data flows include advanced driver assistance system (ADAS) video streams sent from the ADAS domain controller to the smart cockpit domain controller via the central gateway. This stream has low latency and high reliability requirements. The smart cockpit interconnect communication service streams are sent from the smart cockpit domain controller to the interconnect communication domain controller via the central gateway. This includes video playback and online upgrade services, and features high bandwidth and tolerable latency. Existing technical solutions typically configure basic virtual LAN partitioning and simple quality of service (QoS) policies on the central gateway, but lack fine-grained bandwidth management for different service flows. Specifically, this manifests as: unreasonable bandwidth allocation; when advanced driver assistance systems (ADAS) and smart cockpit interconnection communications simultaneously generate high-traffic data, the central gateway, as the sole forwarding node, lacks an effective bandwidth allocation mechanism, leading to outbound data congestion; inadequate QoS policies; existing solutions do not fully consider the differentiated needs of different service flows, and high-priority video streams may experience packet loss due to bandwidth contention, resulting in a green screen; lack of cross-domain traffic control; smart cockpit interconnection communication services exert continuous pressure on the central gateway and affect the transmission quality of critical services; and strong hardware dependence, with some central gateway chips not supporting hardware rate limiting functions, thus preventing the implementation of fine-grained traffic control strategies. These problems manifest in actual products as: a mass-produced vehicle model A experiencing slow online upgrades, and a mass-produced vehicle model B displaying a green screen when showing autonomous driving footage.

[0023] To address the problems of existing technologies, this application provides a method, apparatus, vehicle, and medium for optimizing in-vehicle Ethernet bandwidth. This method enables dynamic, differentiated, deterministic bandwidth allocation for multi-domain services with low complexity on a low-computing-power in-vehicle gateway chip, effectively alleviating bandwidth bottlenecks and ensuring the real-time requirements of various services. The following are various embodiments of this technical solution.

[0024] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating the steps of a method for optimizing Ethernet bandwidth in vehicles.

[0025] This embodiment provides a method for optimizing in-vehicle Ethernet bandwidth, including: S101. Identify the received data streams to determine the business domain type to which each data stream belongs.

[0026] S102. Generate multiple priority queues, each priority queue arranged according to a preset priority order.

[0027] S103. Based on the business domain type of each data flow, assign each data flow to the target priority queue.

[0028] S104. Detect the transmission delay value of each priority queue.

[0029] S105. If the transmission delay value of the target priority queue is greater than the preset threshold, the bandwidth limit of each priority queue after the target priority queue is reduced to the first bandwidth limit value corresponding to the priority. There is a corresponding relationship between the bandwidth limit value of the priority queue and the priority of the priority queue.

[0030] S106. If the transmission delay value of the target priority queue is less than the preset threshold, the bandwidth limit of each priority queue after the target priority queue is increased to the second bandwidth limit value corresponding to the priority. For the same priority queue, the second bandwidth limit value is greater than the first bandwidth limit value.

[0031] Understandably, this solution does not rely on global time synchronization or periodic parsing of gating lists, nor does it involve real-time maintenance of multiple credit value counters. It triggers bandwidth adjustments solely by monitoring the transmission latency value of each priority queue—a single feedback quantity. This trigger-based strategy, based on local latency thresholds, simplifies scheduling decisions to a single-dimensional comparison and linear adjustment, resulting in extremely low computational overhead and making it perfectly suited to the processing capabilities of low-performance gateway chips. The mapping from service domain types to priority queues ensures that sensitive services such as advanced driver assistance systems (ADAS) enter high-priority queues and receive absolute priority forwarding. Simultaneously, bandwidth adjustments only affect all low-priority queues following the target priority queue, rather than causing a global disturbance. This protects the deterministic latency of high-priority services while avoiding mutual interference between different domain services. Through real-time monitoring of latency thresholds and a dual-threshold adjustment mechanism, when high-priority traffic surges, the system quickly tightens low-priority bandwidth to ensure critical services; when the network is idle, the system proactively releases bandwidth to low-priority services, avoiding static waste of bandwidth resources and continuously optimizing overall bandwidth utilization under dynamic changes in multi-domain service loads. In summary, this solution balances deterministic latency guarantees and dynamic bandwidth reuse with minimal computational cost, thereby effectively alleviating bandwidth bottlenecks and meeting the real-time requirements of multi-domain services on low-computing-power chips.

[0032] In some embodiments, each priority queue has a corresponding bandwidth reservation ratio value, wherein the bandwidth reservation ratio value is used to set the minimum bandwidth value of the priority queue, and there is a corresponding relationship between the bandwidth reservation ratio value of the priority queue and the priority of the priority queue.

[0033] The above-mentioned methods for optimizing vehicle Ethernet bandwidth also include: The data flow status of each priority queue is detected. When the target priority queue is inactive, the reserved bandwidth resources of the target priority queue are allocated to at least one active priority queue based on the bandwidth reservation ratio corresponding to the target priority queue.

[0034] Specifically, step 1: Service domain identification and queue mapping. The received data frames are identified by their service domain type, and based on the identification results, the data frames are allocated to multiple priority queues arranged in priority order.

[0035] Step 2: Configure Differentiated Bandwidth Reservation Ratio. A bandwidth reservation ratio is preset for each priority queue. This ratio represents the minimum bandwidth guarantee that the queue can obtain when the link is congested. The reservation ratio is set based on the peak bandwidth requirements and deterministic requirements of the corresponding service domain: the reservation ratio for high-priority services (such as HAD video streams) is greater than its peak bandwidth percentage to provide burst absorption margin; the reservation ratio for medium-priority services (such as ICC video streams) is slightly higher than its peak bandwidth percentage, with a strict upper limit to prevent over-occupancy; the reservation ratio for low-priority non-real-time services (such as OTA upgrade streams) is set to a lower value, only guaranteeing its minimum transmission requirements.

[0036] The sum of the reservation ratios for each priority queue can be greater than 100%. The specific values ​​are determined based on the vehicle network topology and actual business traffic characteristics. For example, HAD video stream reservation ≥ 60%, ICC video stream reservation ≤ 25%, and OTA upgrade stream reservation ≤ 15%.

[0037] Step 3: Setting the bandwidth cap based on the reservation ratio. Using the reservation ratio of each queue in Step 2 as a benchmark, determine the bandwidth cap for each priority queue under different states. Specifically: When the system is not congested, the second bandwidth limit of each priority queue can be set to be equal to the bandwidth value corresponding to its reserved ratio, or it can be allowed to exceed the reserved ratio within a certain range to utilize idle bandwidth. When system congestion occurs (i.e., the reference queue delay exceeds the threshold), the first bandwidth limit of each low-priority queue is set to be strictly equal to the bandwidth value corresponding to its reserved proportion.

[0038] Step 4: Dynamic adjustment of bandwidth cap driven by reference queue latency. The highest priority queue is designated as the reference queue, and its transmission latency is continuously monitored. When the transmission latency of the reference queue exceeds a preset threshold, link congestion is determined, and the bandwidth cap of each priority queue lower than the reference queue is reduced to its corresponding first bandwidth cap (i.e., contracted to the bandwidth value corresponding to the reserved proportion). When the transmission latency of the reference queue falls back below the threshold, congestion is determined to be resolved, and the bandwidth cap of these queues is increased to its corresponding second bandwidth cap (i.e., exceeding the reserved proportion to utilize idle bandwidth).

[0039] Step 5: Borrowing Idle Reserved Bandwidth. Detect the data flow activity status of each priority queue. When any priority queue is inactive (no data to be sent), the bandwidth resources reserved for it in Step 2 can be temporarily allocated to other active priority queues. Once the inactive queue becomes active again, its reserved bandwidth is immediately reclaimed. The borrowing behavior in Step 5 is constrained by Step 4: when the reference queue's latency exceeds the threshold, even if idle reserved bandwidth exists, the bandwidth limit of the low-priority queue is still locked at its first bandwidth limit value, and it cannot borrow more bandwidth.

[0040] Understandably, this embodiment ensures basic transmission guarantees for critical services even during network congestion by setting a minimum bandwidth reservation ratio for each priority queue, thus enhancing the reliability of deterministic services. Simultaneously, dynamically detecting queue activity and reclaiming idle reserved bandwidth allows for real-time allocation of idle resources to active queues, preventing bandwidth waste and further improving overall link utilization. This reclamation logic involves only status monitoring and ratio calculation, maintaining low computational complexity and adapting to the operational requirements of low-performance gateway chips.

[0041] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating the steps involved in implementing a weighted round-robin scheduling strategy in a method for optimizing Ethernet bandwidth in vehicles.

[0042] In some embodiments, the above-described vehicle Ethernet bandwidth optimization method further includes: S201. Generate the scheduling weight corresponding to each priority queue.

[0043] S202. A weighted round-robin scheduling method is adopted, and data frames are taken out from each priority queue in turn according to the scheduling weight and sent.

[0044] S203. During the scheduling process, when the instantaneous bandwidth utilization rate of the target priority queue reaches the current bandwidth limit value corresponding to the target priority queue, stop retrieving data frames from the target priority queue until the instantaneous bandwidth utilization rate is lower than the current bandwidth limit value.

[0045] Specifically, a scheduling weight is assigned to each priority queue. The scheduling weight is determined based on the reserved ratio or the upper limit of the effective bandwidth of each queue, so as to ensure that each queue obtains a scheduling opportunity that matches its set bandwidth.

[0046] During outbound scheduling, a weighted round-robin (WRR) algorithm is used to sequentially retrieve data frames from each queue according to their weight ratios for transmission.

[0047] During WRR scheduling, the instantaneous bandwidth utilization of each queue is monitored in real time. When the instantaneous bandwidth utilization of any queue reaches its current effective bandwidth limit, scheduling of data frames from that queue is suspended, even if the queue still has remaining weight. The scheduling opportunity will automatically yield to other queues that have not reached their limits. When the instantaneous bandwidth utilization of that queue falls back below its limit, its normal WRR scheduling is resumed.

[0048] Through this mechanism, when the bandwidth usage of ICC video streams or OTA upgrade streams reaches their preset limit, the transmission rate will be automatically limited, thereby effectively preventing them from preempting the bandwidth resources of HAD video streams, even if they are active and their weights allow them to send more data.

[0049] Understandably, this embodiment, by assigning scheduling weights to each priority queue, can proportionally and fairly allocate transmission opportunities under bandwidth limit constraints, avoiding long-term starvation of low-priority queues and improving scheduling fairness among multi-domain services. Simultaneously, real-time monitoring of queue instantaneous bandwidth utilization and pausing scheduling when the limit is reached allows for precise execution of the bandwidth limit value obtained from previous dynamic adjustments, preventing sudden traffic surges from impacting other queues and enhancing the execution accuracy of deterministic bandwidth allocation. This rate-limiting operation only involves bandwidth counting comparison and scheduling start / stop control, requiring no complex calculations and maintaining compatibility with low-computing-power chips.

[0050] In some embodiments, in addition to WRR, DWRR (Deficit Weighted Round Robin) or WFQ (Weighted Fair Queuing) can be used to implement bandwidth limiting for ICC and OTA streams.

[0051] Please refer to Figure 3 , Figure 3 This is a flowchart illustrating the steps involved in implementing a hardware and software solution by the central gateway device in a vehicle-mounted Ethernet bandwidth optimization method.

[0052] This embodiment uses the optimization of bandwidth management of the central gateway in a mass-produced vehicle as an example to illustrate the implementation process and verification effect of the present invention. The central gateway of this vehicle uses a commercial chip supporting 802.1p hardware acceleration, and the vehicle backbone network is a 1Gbps Ethernet link, mainly carrying three types of services: advanced driver assistance system (ADAS) video stream, smart cockpit interconnection communication video stream, and online upgrade data stream. The ADAS video stream is sent from the ADAS domain controller to the central gateway, and then forwarded by the central gateway to the smart cockpit domain controller for displaying the autonomous driving screen. This service requires an end-to-end latency of less than 10 milliseconds and does not allow packet loss. The smart cockpit interconnection communication video stream is sent from the smart cockpit domain controller to the central gateway and then forwarded to the interconnection communication domain controller for rear-seat entertainment video playback. It can tolerate latency in the hundreds of milliseconds but requires stable throughput. The online upgrade data stream is initiated by the interconnection communication domain controller and distributed to each domain controller via the central gateway; this is a background, non-real-time service.

[0053] In this embodiment, the central gateway is pre-configured with strict 802.1p priority mapping and bandwidth policies, as shown in Table 1 below: Table 1 - Bandwidth Policy Configuration Table

[0054] Specifically, the advanced driver assistance system (ADAS) video stream is mapped to the highest priority queue and configured with a strict priority scheduling policy. When the queue overflows, only low-priority data packets are dropped, ensuring that the stream is not impacted by any low-priority traffic. The smart cockpit interconnection video stream is mapped to the medium priority queue and its bandwidth is capped at 25% of the total bandwidth. The online upgrade data stream is mapped to the lowest priority queue and its bandwidth is capped at 15% of the total bandwidth. The above proportions are based on the following: the peak bandwidth of the ADAS video stream under a 1Gbps link is approximately 400 to 500 megabits per second, and reserving more than 60% of the bandwidth ensures that it still has sufficient resources to cope with sudden bitrate fluctuations during congestion; the peak bandwidth of the smart cockpit interconnection video stream is approximately 150 to 200 megabits per second, and the 25% cap is sufficient to ensure smooth playback while preventing excessive congestion; and as an online upgrade is a background service, the 15% cap ensures that upgrades can continue without interfering with critical driving functions. Meanwhile, the central gateway adopts a weighted round-robin scheduling strategy. When the instantaneous bandwidth usage of the intelligent cockpit interconnection communication video stream or online upgrade stream reaches its respective limit, it automatically limits its transmission rate to avoid instantaneous surges that may preempt the forwarding resources of the advanced driver assistance system video stream.

[0055] To verify the effectiveness of this solution, the system performance before and after optimization was tested on the same vehicle and under the same road conditions. Before optimization, only basic virtual local area network (VLAN) partitioning was configured, and no differentiated quality of service (QoS) strategies were implemented. After optimization, the configuration described in this embodiment was used. The test conditions were as follows: the vehicle was traveling on a highway, the advanced driver assistance system continuously generated approximately 400 megabits per second of perceived image data stream, while the rear-seat entertainment system played high-definition video, generating approximately 200 megabits per second of smart cockpit interconnection communication data stream, and the entire vehicle online upgrade package was downloaded simultaneously in the background.

[0056] Test results show that before optimization, the packet loss rate of the advanced driver assistance system (ADAS) video stream was approximately 0.8%, the average number of green screens during autonomous driving was 3.2 per hour, the number of stutters in the rear-seat entertainment video playback was 5.6 per hour, the average online upgrade rate was only 12 megabits per second, and the central gateway's outbound bandwidth utilization reached 98% during peak periods with continuous congestion. After optimization, the packet loss rate of the ADAS video stream dropped to 0%, the number of green screens dropped to zero per hour, the number of stutters in the rear-seat entertainment video playback dropped to 0.3 per hour with a subjectively smooth playback experience, the average online upgrade rate improved and stabilized at 18 megabits per second, and the central gateway's outbound bandwidth utilization stabilized within a reasonable range of 75% to 85%, with no congestion. The above comparative data fully demonstrates that the solution in this embodiment achieves differentiated deterministic bandwidth allocation for multi-domain services with extremely low scheduling overhead on an in-vehicle low-computing-power gateway chip, effectively alleviating bandwidth bottlenecks and ensuring the real-time requirements of various services.

[0057] In some embodiments, the bandwidth upper limit is adjusted in the following ways: Generate a token bucket corresponding to each priority queue, and each token bucket has a commitment information rate; inject tokens into the token bucket at the commitment information rate, wherein when the bandwidth limit of the priority queue is adjusted, the commitment information rate of the token bucket corresponding to the priority queue is updated; when there is a data frame to be sent in the target priority queue, determine whether the number of available tokens in the token bucket corresponding to the target priority queue is greater than or equal to the length of the data frame to be sent. If so, consume the number of tokens corresponding to the length and send the data frame to be sent. If not, stop sending the data frame to be sent.

[0058] Specifically, first, a corresponding token bucket filter instance is created for each priority queue. Each token bucket is configured with two core parameters: Committed Information Rate (CIR) and Burst Size (CBS). CIR corresponds to the current effective bandwidth limit for the queue, and CBS corresponds to the allowable instantaneous burst traffic size for the queue.

[0059] Secondly, each token bucket generates tokens at a constant rate of CIR, with a maximum accumulation limit of CBS. When a token bucket is full, newly generated tokens are discarded.

[0060] When a priority queue has a data frame to send, the number of available tokens in the corresponding token bucket is checked. If the number of tokens is greater than or equal to the data frame length, the corresponding number of tokens are consumed, the data frame is granted permission to send, and enters the egress scheduling; if the number of tokens is insufficient, the data frame is postponed or discarded until enough tokens accumulate in the token bucket.

[0061] When the latency of the reference queue exceeds the threshold, the effective bandwidth limit of the low-priority queue is reduced, and the new limit value is updated in real time to the CIR parameter of the token bucket of that queue; when the latency falls back below the threshold, the effective bandwidth limit is increased, and the CIR is updated in real time to the new limit value.

[0062] Through the above steps, the TC tool achieves precise coordination with the dynamic bandwidth limit adjustment described in claim 1 at the software level: when the transmission rate of the ICC video stream or OTA upgrade stream reaches its currently effective bandwidth limit, the token bucket automatically restricts its passage, thereby preventing it from preempting the bandwidth resources of the HAD video stream.

[0063] Understandably, this embodiment, by configuring a token bucket for each priority queue and injecting tokens at the commitment information rate, can directly map the dynamically adjusted bandwidth limit to the token injection rate, achieving precise execution of bandwidth allocation results. When the bandwidth limit changes, only the commitment information rate parameter of the corresponding token bucket needs to be updated, without refactoring the scheduling logic, reducing the overhead of dynamic reconfiguration. Simultaneously, the token bucket mechanism, through frame-by-frame comparison of the number of available tokens with the frame length, can smoothly control burst traffic, avoiding instantaneous overload, further ensuring the smoothness and determinism of bandwidth allocation. Moreover, this operation only involves counting and comparison, resulting in extremely low computational burden, which is suitable for the hardware conditions of low-computing-power gateway chips.

[0064] In some embodiments, in addition to tc, eBPF / XDP technology can be used to achieve higher performance software-layer traffic control.

[0065] In some embodiments, adjusting the bandwidth limit also includes: Generate data frame matching rules for each priority queue. These rules are used to identify data frames belonging to the target service subclass within the same priority queue. Determine the rate limiting threshold for the data frame matching rules. When the bandwidth limit of a priority queue is adjusted, the rate limiting threshold in the data frame matching rules for that priority queue is updated. If a target data frame in a priority queue belongs to the target service subclass defined by the data frame matching rules, and the target data frame exceeds the rate limiting threshold, the target data frame is discarded.

[0066] Specifically, firstly, based on the service domain type, fine-grained matching rules are defined for the data streams within each priority queue. Rule dimensions include, but are not limited to: VLAN identifier, source / destination IP address, transport layer protocol type (TCP / UDP), and source / destination port number. For example, ICC video streams can be further subdivided into "RTSP video stream within VLAN 20, using UDP protocol, destination port 554" and "HTTP stream within VLAN 20, using TCP protocol, destination port 80".

[0067] Secondly, use ipset to create a hash-structured set of IP addresses or ports, grouping multiple IP addresses or ports belonging to the same bandwidth constraint policy into the same set to improve the efficiency of iptables rule matching. For example, create a port set named "ICC_VIDEO_PORTS" that includes commonly used video streaming ports such as 554 and 8554.

[0068] Then, using iptables' hashlimit or limit extension module, tiered rate limits are configured for traffic with different matching granularities. hashlimit supports rate limiting based on a combined hash bucket of "source IP + destination IP + destination port," while limit supports rate limiting based on a single rule using a token bucket. The rate limit value of each rule corresponds to the currently effective bandwidth limit value of the priority queue in claim 1—it can be set to be equal to that limit value, or set to a proportional distribution of that limit value among the segmented traffic.

[0069] When the reference queue latency exceeds the threshold, the effective bandwidth limit for low-priority queues is reduced. This new limit value is updated in real time to the rate parameter of the corresponding iptables rate limiting rule (achieved by dynamically modifying iptables rules or by using tc-iptables combined flags). When the latency falls back below the threshold, it is updated to a more lenient limit value.

[0070] Through the above steps, iptables / ipset implements precise rate limiting of segmented traffic within a specific service domain at the software level: when the transmission rate of a certain type of video stream (such as RTSP stream) in the ICC video stream reaches its assigned rate limiting threshold, iptables directly discards the over-limited packet or re-marks it as a low priority, thereby preventing non-critical services from preempting the bandwidth resources of the HAD video stream at a finer granular level.

[0071] Understandably, this embodiment, by further identifying target service subclasses and setting independent rate-limiting thresholds within the priority queue, enables fine-grained control over traffic of specific subclasses within the same priority queue. This prevents sudden surges in traffic from a single subclass from crowding out bandwidth resources for other subclasses within the queue. When the overall bandwidth limit is dynamically adjusted, the subclass rate-limiting thresholds are updated synchronously, ensuring the consistency of the hierarchical bandwidth allocation strategy. This mechanism employs rule matching and counting comparison, eliminating the need for complex scheduling calculations and enhancing the fine-grained control of bandwidth allocation with minimal overhead, further guaranteeing fairness among multiple service subclasses.

[0072] Please refer to Figure 4 , Figure 4 This is a flowchart illustrating the steps involved in implementing a traffic control scheme for the infotainment domain software layer within a method for optimizing in-vehicle Ethernet bandwidth.

[0073] This embodiment uses a typical scenario where the central gateway of a mass-produced vehicle does not support hardware speed limiting, illustrating the specific implementation process and verification effect of the present invention's solution in achieving bandwidth optimization through software-layer collaborative management. The central gateway chip of this vehicle does not have a built-in hardware speed limiting engine, but it runs a Linux operating system and possesses basic software traffic management capabilities. The vehicle's Ethernet backbone link is 1Gbps, also carrying three types of services: advanced driver assistance system (ADAS) video streams, smart cockpit interconnection communication video streams, and online upgrade data streams. The ADAS video stream is transmitted through User Datagram Protocol (UDP) port 5004, and the online upgrade data stream is transmitted through Transmission Control Protocol (TCP) port 8080.

[0074] This embodiment deploys a software-layer bandwidth management scheme based on Linux kernel-native traffic control tools in the intelligent cockpit domain controller. The specific implementation includes a two-level control architecture: the first level uses a hierarchical token bucket algorithm to allocate overall bandwidth at the virtual interface level of the virtual LAN; the second level combines packet filtering tools and traffic control tools to achieve fine-grained rate limiting based on protocols and ports.

[0075] In the first-level control, a hierarchical token bucket queue rule is established on the Ethernet interface root node using a flow control tool, dividing the 1Gbps total bandwidth into three subcategories. Specifically, the root node's total bandwidth is set to 1000 Mbps. The three subcategories are allocated as follows: a guaranteed rate of 600 Mbps (maximum not exceeding 600 Mbps) for the VPN interface hosting the Advanced Driver Assistance System (ADAS) video stream; a guaranteed rate of 250 Mbps (maximum not exceeding 250 Mbps) for the VPN interface hosting the Smart Cockpit Interconnection Communication video stream; and a guaranteed rate of 150 Mbps (maximum not exceeding 150 Mbps) for the VPN interface hosting the online upgrade data stream. Uncategorized streams default to the last category. This configuration ensures that the ADAS video stream receives at least 600 Mbps of dedicated bandwidth under all circumstances, consistent with the allocation ratio in the aforementioned embodiment.

[0076] In the second level of control, packet filtering tools mark traffic on specific ports along the packet forwarding path with Differential Service Code Points (DSCs), and flow control tools then apply additional rate-limiting constraints to the marked traffic. Specifically, the Advanced Driver Assistance System (ADAS) video stream on UDP port 5004 is marked as an accelerated forwarding category, corresponding to the highest priority in 802.1p; the online upgrade stream on Transmission Control Protocol (TCP) port 8080 is marked as a guaranteed forwarding category, corresponding to a lower priority in 802.1p. The marked packets are automatically assigned to the corresponding subclass in the hierarchical token bucket queue rules based on their DSC values, thus achieving further service differentiation based on port and protocol within the same VLAN. Through these two layers of configuration, the bandwidth allocation of the flow control tool and the marking of the packet filtering tool work together to form a multi-level, refined flow control system encompassing VLAN, protocol, and port.

[0077] When network load is light, traffic for each subclass does not reach its limit, and queuing rules allow idle bandwidth to be shared among subclasses. When there is a surge in advanced driver assistance system (ADAS) video streams or when smart cockpit interconnection communication video streams and online upgrade streams peak simultaneously, queuing rules strictly limit the latter two types of traffic to their limits, ensuring priority forwarding of ADAS video streams. The entire software-layer management requires no hardware rate limiting capabilities and relies entirely on native Linux kernel tools.

[0078] To verify the effectiveness of the software solution in this embodiment, tests were conducted in a real vehicle environment, comparing the pre-optimization state without traffic control and the post-optimization state after adopting this solution. The test conditions were the same as the previous embodiment: the vehicle was traveling on a highway, the Advanced Driver Assistance System (ADAS) continuously generated approximately 400 megabits per second of data, while high-definition video was played in the rear seats and an online upgrade package was downloaded in the background. Before optimization, without any traffic control, the intelligent cockpit interconnection video stream and the online upgrade stream competed for bandwidth, resulting in a packet loss rate of 1.2% for the ADAS video stream during peak hours, causing noticeable screen tearing and latency in the autonomous driving footage. After adopting the software solution in this embodiment, the packet loss rate of the ADAS video stream decreased to below 0.05%, and the screen display was stable and without abnormalities. The average utilization rate of the central gateway's central processor decreased from approximately 55% before optimization to 28%. This is attributed to the dynamic hardware acceleration control mechanism additionally integrated into this solution based on the aforementioned embodiments. This mechanism dynamically enables or disables hardware acceleration processing based on a comprehensive network status score, significantly reducing the proportion of time hardware acceleration is disabled from 100% in the always-off solution to 35%, effectively avoiding the continuous excessive consumption of central processor resources by software traffic control. Tests show that, even when the central gateway does not support hardware rate limiting, this solution achieves multi-domain service differentiated bandwidth guarantee capabilities comparable to the previous embodiment through pure software means with acceptable central processing unit overhead, providing a flexible and low-cost bandwidth optimization path for hardware-constrained vehicle models.

[0079] Please refer to Figure 5 , Figure 5 This is a flowchart illustrating the steps of a dynamic hardware acceleration control method in an in-vehicle Ethernet bandwidth optimization approach.

[0080] In some embodiments, the above-described vehicle Ethernet bandwidth optimization method further includes: S301. Detect network status indicators in multiple dimensions, and perform weighted comprehensive calculation on the network status indicators in multiple dimensions to generate a comprehensive status score.

[0081] S302. When the overall status score is lower than the preset threshold and the duration reaches the preset hysteresis duration, a start command is sent to the hardware acceleration module to realize hardware acceleration processing.

[0082] S303. When the overall status score exceeds the threshold, it is determined that the current data stream load exceeds the hardware acceleration processing capability, and a shutdown command is sent to the hardware acceleration module to switch the data stream from hardware acceleration processing to software processing.

[0083] In one specific embodiment, this embodiment describes a dynamic hardware acceleration control method based on a multi-dimensional comprehensive judgment mechanism. The central gateway monitors three network status indicators in real time: advanced driver assistance system (ADAS) queue depth, egress bandwidth utilization, and ADAS stream packet loss rate. The judgment logic is as follows: the central gateway sends a notification message to the intelligent cockpit domain controller to disable hardware acceleration only when the ADAS queue depth exceeds 70% of the total queue length, or the egress bandwidth utilization exceeds 90% for five consecutive milliseconds, or packet loss occurs in the ADAS stream; otherwise, hardware acceleration remains enabled.

[0084] In actual driving tests, when the vehicle was in congested urban traffic, the bitrate of the advanced driver assistance system (ADAS) video stream spiked instantaneously due to the increased amount of perceived data. The outgoing bandwidth utilization briefly exceeded 90% but did not last for more than five milliseconds. During this time, hardware acceleration remained enabled, avoiding unnecessary switching operations. When the vehicle entered a highway and simultaneously underwent an online upgrade, the outgoing bandwidth utilization consistently exceeded 90% for more than five milliseconds. The central gateway immediately notified the intelligent cockpit domain controller to disable hardware acceleration and switch traffic processing to the software layer for fine-grained bandwidth management. Tests showed that this multi-dimensional judgment mechanism kept the hardware acceleration shutdown time below 35%, reducing the average CPU utilization from 55% to 28% compared to the constantly disabled solution. It also eliminated frequent switching caused by fluctuations in a single metric, significantly improving system stability.

[0085] Understandably, this embodiment uses a weighted comprehensive score based on multi-dimensional network status indicators to fully assess the current network load and congestion level, avoiding misjudgments based on a single indicator. Introducing hysteresis prevents frequent fluctuations in network status at threshold boundaries, which could cause the acceleration module to repeatedly switch on and off, enhancing switching stability. When the comprehensive score is below the threshold, hardware acceleration is activated to promptly offload high-load traffic to hardware processing, alleviating CPU burden; when the score is too high and the load exceeds acceleration capacity, software processing is switched back in a timely manner to avoid hardware overload and packet loss. This switching decision only requires periodic calculation of the comprehensive score and time comparison, with manageable complexity. This improves the gateway chip's processing resilience in multi-domain service burst scenarios and ensures the continuous and effective execution of bandwidth allocation strategies.

[0086] In some embodiments, the above-described vehicle Ethernet bandwidth optimization method further includes: When the operating status of the software layer traffic control component is detected to meet the preset fault triggering conditions, the software layer traffic control is determined to be in failure, and the bandwidth limit value of at least one priority queue whose priority order is after the target priority queue is set as the safe bandwidth limit value, wherein the safe bandwidth limit value is lower than the first bandwidth limit value of the priority queue in the normal state.

[0087] In one specific embodiment, the test environment consists of the central gateway and the smart cockpit domain controller of the same vehicle model. The bandwidth ratio in the normal mode is pre-configured as 60% for advanced driver assistance video stream, 25% for smart cockpit interconnection communication video stream, and 15% for online upgrade stream.

[0088] After the test began, the traffic control tool process was simulated to exit abnormally. The watchdog timer timed out after the process exited, triggering a restart script. The script executed the following actions in sequence: terminating any remaining process instances, reloading the hierarchical token bucket queue rules, re-injecting the packet filtering tool's marking rules, and sending a recovery completion signal to the central gateway. Within the 100-millisecond window of the process restart, the central gateway had already received the process exit event and entered conservative mode, forcibly limiting the bandwidth caps of the smart cockpit interconnect communication video stream and the online upgrade stream to 20% and 10% of the total bandwidth, respectively. Simultaneously, it disabled hardware acceleration on the smart cockpit domain controller to ensure maximum CPU resources were used for process restart. After the recovery completion signal arrived, the central gateway waited for a 500-millisecond stabilization period to confirm that the traffic control tool was operating normally and the queue depth remained below the threshold. It then exited conservative mode, restored the bandwidth caps to 25% and 15%, and re-enabled hardware acceleration. The entire fault recovery process took approximately 600 milliseconds. During this period, the actual transmission rate of the advanced driver assistance system (ADAS) video stream remained unchanged at a guaranteed value of 600 megabits per second, and there was no packet loss in the test data. This demonstrates that the conservative bandwidth tightening strategy provided sufficient time margin for process recovery and ensured deterministic service quality for critical services during software-layer anomalies.

[0089] Understandably, in this embodiment, when the software-layer traffic control component is detected to meet preset fault triggering conditions, the system automatically forces the bandwidth limit of the low-priority queue to a safe upper limit value lower than the normal first bandwidth value. This mechanism, in abnormal scenarios where software control fails, proactively compresses non-critical service bandwidth to reserve sufficient link resources for high-priority critical services, preventing bandwidth contention and congestion propagation caused by control deficiencies, thus improving the system's deterministic assurance capability under partial failure states. This degradation action is merely a switching operation of preset values, without involving complex diagnostics or recalculation, and can be executed quickly with extremely low computational overhead, further enhancing the robustness and security of the vehicular network under extreme conditions.

[0090] In some embodiments, a watchdog timer is started to monitor the software layer traffic control component. When a component crash is detected, the component is automatically restarted and the traffic control rules are restored within a preset time.

[0091] Please refer to Figure 6 , Figure 6 This is a schematic diagram of the structure of an in-vehicle Ethernet bandwidth optimization device.

[0092] This embodiment also provides an in-vehicle Ethernet bandwidth optimization device, including: The identification module 401 is used to identify the received data streams in order to determine the business domain type to which each data stream belongs.

[0093] The sorting module 402 is used to generate multiple priority queues, each priority queue being arranged according to a preset priority order.

[0094] The allocation module 403 is used to allocate each data stream to a target priority queue based on the business domain type of each data stream.

[0095] The detection module 404 is used to detect the transmission delay value of each priority queue.

[0096] The adjustment module 405 is used to, if the transmission delay value of the target priority queue is greater than a preset threshold, reduce the upper limit of the bandwidth of each priority queue after the target priority queue to the first upper limit of the bandwidth corresponding to the priority, wherein there is a corresponding relationship between the upper limit of the bandwidth of the priority queue and the priority of the priority queue; if the transmission delay value of the target priority queue is less than the preset threshold, increase the upper limit of the bandwidth of each priority queue after the target priority queue to the second upper limit of the bandwidth corresponding to the priority, wherein for the same priority queue, the second upper limit of the bandwidth is greater than the first upper limit of the bandwidth.

[0097] Please refer to Figure 7 , Figure 7 This is a schematic diagram of the architecture of an in-vehicle Ethernet bandwidth optimization system.

[0098] In this embodiment, an in-vehicle Ethernet bandwidth optimization system includes the following components: The Central Gateway (CGW), as the core switching node, is responsible for configuring priority and bandwidth policies based on the 802.1p protocol, and for differentiated management and forwarding of different types of data streams.

[0099] The HAD domain controller is responsible for generating HAD video streams (autonomous driving video data) and transmitting them to the cockpit domain controller through the central gateway.

[0100] The ICC domain controller is responsible for generating ICC video streams (entertainment video data) and OTA upgrade streams, which are transmitted to the cockpit domain controller through the central gateway. When the CGW does not support hardware rate limiting, traffic control is implemented through the software layer.

[0101] The Cockpit Domain Controller (CSC) is responsible for receiving and displaying HAD and ICC video streams, as well as performing OTA upgrades.

[0102] In some embodiments, a dual CGW architecture can be adopted, in which HAD streams and ICC streams are transmitted through different CGWs to fundamentally avoid bandwidth contention, or TSN 802.1Qbv time-aware gating scheduling can be used to replace the Strict Priority strategy to provide deterministic time slot guarantees for HAD video streams.

[0103] The specific implementation methods and technical effects of the embodiments of the present invention can be referred to the specific implementation methods and technical effects of the vehicle Ethernet bandwidth optimization method in any of the above embodiments.

[0104] The beneficial effects of the above embodiments include ensuring zero stuttering and no green screens in the advanced driver assistance system (ADAS) video stream; ensuring the real-time performance and reliability of the autonomous driving screen display by configuring the highest priority and reserving no less than 60% of the link bandwidth; ensuring smooth operation of the intelligent cockpit interconnection communication service, with its video stream using medium-to-high priority and a bandwidth limit of no more than 25%, and the online upgrade stream using low priority and a bandwidth limit of no more than 15%, thus ensuring the quality of their respective services while avoiding contention for ADAS resources; and improving the overall system efficiency by using a scheduling strategy that combines strict priority and weighted round-robin, ensuring the quality of high-priority services while achieving reasonable utilization of bandwidth resources and avoiding... It avoids waste; reduces hardware dependence, and through the traffic management scheme of the intelligent cockpit domain controller software layer, it can still effectively manage bandwidth when the central gateway chip does not support hardware rate limiting, thus improving the versatility of the solution; reduces central processor wear, and through the dynamic hard acceleration control mechanism, it only turns off hard acceleration when the data flow exceeds the threshold, which significantly reduces the central processor utilization rate to a controllable range compared to the always-off solution; it has adaptive bandwidth allocation capability, and when the advanced driver assistance video stream is inactive, the central gateway automatically releases its reserved bandwidth for other services to temporarily borrow, and when the video stream is reactivated, it recovers the bandwidth and restores priority protection within ten milliseconds, thus realizing efficient reuse of bandwidth resources.

[0105] This invention also provides a vehicle control device, including a memory, a processor, and a program stored in the memory and executable on the processor. When the program is executed by the processor, it implements the vehicle Ethernet bandwidth optimization method of the above embodiments.

[0106] Taking the example of a processor and memory in a vehicle controller being connected via a bus, the memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, the memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include memory remotely located relative to the control processor, and these remote memories can be connected to the control device via a network. The non-transitory software programs and instructions required to implement the control methods of the above embodiments are stored in the memory, and when executed by the processor, the control methods of the above embodiments are performed.

[0107] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0108] This invention also provides a vehicle, including the vehicle control device described in the above embodiments.

[0109] The vehicle can be a private car, such as a sedan, SUV, MPV, or pickup truck. It can also be a commercial vehicle, such as a van, bus, small truck, or large semi-trailer. The vehicle must have an electric motor capable of outputting power or acting as a generator to store mechanical energy. When the vehicle is a new energy vehicle, it can be a hybrid or a pure electric vehicle.

[0110] Since the vehicle applies all the technical solutions of the above-mentioned control device or vehicle controller, it has at least all the beneficial effects brought about by the technical solutions of the above embodiments, which will not be repeated here.

[0111] Furthermore, one embodiment of the present invention provides a computer-readable storage medium storing computer-executable instructions for performing the above-described vehicle Ethernet bandwidth optimization method.

[0112] It is worth noting that, since the computer-readable storage medium of the present invention is capable of executing the vehicle Ethernet bandwidth optimization method of any of the above embodiments, the specific implementation and technical effects of the computer-readable storage medium of the present invention can be referred to the specific implementation and technical effects of the vehicle Ethernet bandwidth optimization method of any of the above embodiments.

[0113] Furthermore, one embodiment of the present invention provides a computer program product, including a computer program or computer instructions, which are stored in a computer-readable storage medium. A processor of a computer device reads the computer program or computer instructions from the computer-readable storage medium and executes the computer program or computer instructions, causing the computer device to perform the above-described in-vehicle Ethernet bandwidth optimization method.

[0114] It is worth noting that, since the computer program product of this embodiment can execute the vehicle Ethernet bandwidth optimization method of any of the above embodiments, the specific implementation method and technical effects of the computer program product of this embodiment can be referred to the specific implementation method and technical effects of the vehicle Ethernet bandwidth optimization method of any of the above embodiments.

[0115] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically include computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0116] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

Claims

1. A method for optimizing the bandwidth of an in-vehicle Ethernet network, characterized in that, The method includes: The received data streams are identified to determine the service domain type to which each data stream belongs; Multiple priority queues are generated, and each priority queue is arranged in a preset priority order; Based on the business domain type of each data flow, each data flow is assigned to a target priority queue; Detect the transmission delay value for each of the priority queues; If the transmission delay value of the target priority queue is greater than the preset threshold, the bandwidth limit of each priority queue after the target priority queue will be reduced to the first bandwidth limit value corresponding to the priority. There is a corresponding relationship between the bandwidth limit value of the priority queue and the priority of the priority queue. If the transmission delay value of the target priority queue is less than the preset threshold, then the bandwidth limit value of each priority queue whose priority order is after the target priority queue is increased to the second bandwidth limit value corresponding to the priority, wherein, for the same priority queue, the second bandwidth limit value is greater than the first bandwidth limit value.

2. The method according to claim 1, characterized in that, Each priority queue has a corresponding bandwidth reservation ratio value, wherein the bandwidth reservation ratio value is used to set the minimum bandwidth value of the priority queue, and there is a corresponding relationship between the bandwidth reservation ratio value of the priority queue and the priority of the priority queue. The method further includes: The data flow status of each priority queue is detected. When the target priority queue is inactive, the reserved bandwidth resources of the target priority queue are allocated to at least one active priority queue based on the bandwidth reservation ratio value corresponding to the target priority queue.

3. The method according to claim 2, characterized in that, The method further includes: Generate the scheduling weight corresponding to each of the priority queues; A weighted round-robin scheduling method is adopted, and data frames are sequentially retrieved from each priority queue and sent according to the scheduling weight; During the scheduling process, when the instantaneous bandwidth utilization rate of the target priority queue reaches the current bandwidth limit value corresponding to the target priority queue, data frames are stopped being retrieved from the target priority queue until the instantaneous bandwidth utilization rate is lower than the current bandwidth limit value.

4. The method according to claim 1, characterized in that, The methods for adjusting the bandwidth upper limit include: Generate a token bucket corresponding to each of the priority queues, and each of the token buckets has a commitment information rate; Tokens are injected into the token bucket at the promised information rate, wherein when the bandwidth limit of the priority queue is adjusted, the promised information rate of the token bucket corresponding to the priority queue is updated. When there is a data frame to be sent in the target priority queue, it is determined whether the number of available tokens in the token bucket corresponding to the target priority queue is greater than or equal to the length of the data frame to be sent. If so, the number of tokens corresponding to the length is consumed and the data frame to be sent is sent. If not, the sending of the data frame to be sent is stopped.

5. The method according to claim 4, characterized in that, The methods for adjusting the bandwidth upper limit also include: Generate a data frame matching rule for each priority queue, the data frame matching rule being used to identify data frames belonging to the target service subclass within the same priority queue; Determine the rate limiting threshold of the data frame matching rule, wherein when the bandwidth upper limit of the priority queue is adjusted, the rate limiting threshold in the data frame matching rule corresponding to the priority queue is updated; When a target data frame in the priority queue belongs to the target service subclass defined by the data frame matching rule, if the target data frame exceeds the rate limit threshold, the target data frame is discarded.

6. The method according to claim 5, characterized in that, The method further includes: Detect network status indicators across multiple dimensions, and perform a weighted and comprehensive calculation on these indicators to generate a comprehensive status score. When the overall status score is lower than a preset threshold and the duration reaches a preset hysteresis duration, an activation command is sent to the hardware acceleration module to achieve hardware acceleration processing. When the overall status score exceeds the threshold, it is determined that the current data stream load exceeds the hardware acceleration processing capability, and a shutdown command is sent to the hardware acceleration module to switch the data stream from hardware acceleration processing to software processing.

7. The method according to claim 5, characterized in that, The method further includes: When the operating status of the software layer traffic control component is detected to meet the preset fault triggering conditions, the software layer traffic control is determined to be in failure, and the bandwidth upper limit of at least one priority queue whose priority order is after the target priority queue is set as the safe bandwidth upper limit, wherein the safe bandwidth upper limit is lower than the first bandwidth upper limit of the priority queue in the normal state.

8. A vehicle-mounted Ethernet bandwidth optimization device, characterized in that, The device includes: The identification module is used to identify the received data streams in order to determine the business domain type to which each data stream belongs; A sorting module is used to generate multiple priority queues, each of which is arranged in a preset priority order; The allocation module is used to allocate each data stream to a target priority queue based on the service domain type of each data stream; A detection module is used to detect the transmission delay value of each of the priority queues; The adjustment module is configured to, if the transmission delay value of the target priority queue is greater than a preset threshold, reduce the upper limit of the bandwidth of each priority queue whose priority order follows the target priority queue to a first upper limit of bandwidth corresponding to the priority, wherein there is a corresponding relationship between the upper limit of bandwidth of the priority queue and the priority of the priority queue; if the transmission delay value of the target priority queue is less than the preset threshold, increase the upper limit of bandwidth of each priority queue whose priority order follows the target priority queue to a second upper limit of bandwidth corresponding to the priority, wherein for the same priority queue, the second upper limit of bandwidth is greater than the first upper limit of bandwidth.

9. A vehicle, characterized in that, The vehicle includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the vehicle Ethernet bandwidth optimization method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the vehicle Ethernet bandwidth optimization method according to any one of claims 1 to 7.

Images