Method, medium, and product for brake deceleration demand for a brake-by-wire system

Abstract

The application provides a method, medium and product for brake deceleration demand of a line control brake system, and belongs to the technical field of intelligent brake control of automobiles. The method comprises the following steps: analyzing customer brake pedal feeling demand to generate customer brake performance demand data, determining upper and lower limit curves based on the customer brake performance demand data to generate brake deceleration upper and lower limit curve data, and storing data to construct a brake boundary database; collecting brake initial state data when brake triggering, verifying vehicle speed to generate verified initial vehicle speed data, and recording time to generate brake starting time stamp data; the dynamic proportional coefficient i tends to 0 at low speed, and the brake is soft, so that the jerk is reduced; the dynamic proportional coefficient i tends to 1 at high speed, and the brake is sensitive, so that the human factor engineering is met, the driver's intuition and expectation are adapted, and the driving experience consistency is improved.

Description

Technical Field

[0001] This invention proposes a method, medium, and product for meeting the braking deceleration requirements of a brake-by-wire system, belonging to the field of automotive intelligent braking control technology. Background Technology

[0002] With the increasing demands for coordinated energy recovery in new energy vehicles and for precise braking response in intelligent driving, traditional vacuum-assisted braking systems that rely on engine vacuum sources can no longer meet the overall vehicle control requirements. Braking-by-wire systems, due to their advantages such as the absence of mechanical connections and the ability to define braking characteristics in software, have become the core direction for the next generation of braking systems.

[0003] Existing brake-by-wire systems often use a pedal travel-fixed deceleration curve or lookup table method to map the driver's braking intention. However, this approach has significant drawbacks: First, the braking characteristics are rigid, and the fixed mapping relationship cannot adapt to the differences in the driver's perception of braking intensity at different vehicle speeds. When parking at low speeds, excessive braking gain can easily cause jerking, while at high speeds, insufficient braking gain can lead to inadequate emergency braking performance. Second, dynamic adaptability is lacking. The mapping logic is not adjusted in conjunction with the vehicle's operating status (such as initial speed), resulting in inconsistent deceleration output at different vehicle speeds for the same pedal travel, which contradicts the driver's expected operation. Third, development redundancy is high. Hardware parameters such as the reaction disc structure and push rod length need to be adjusted to adapt to the pedal feel requirements of different customers, resulting in many component variations, long development cycles, and high costs.

[0004] While some solutions attempt to optimize braking curves through software calibration, they remain limited to static curve correction and fail to achieve dynamic intent parsing based on real-time operating conditions. Therefore, there is an urgent need for a deceleration demand identification method that can correlate with the vehicle's initial operating state and break away from a single, fixed mapping paradigm, addressing the compatibility and development cost issues of existing technologies. Summary of the Invention

[0005] This invention provides a method for meeting the braking deceleration requirements of a brake-by-wire system, thereby addressing the problems mentioned in the background section above:

[0006] The present invention proposes a method for meeting the braking deceleration requirements of a brake-by-wire system, the method comprising:

[0007] S1: Analyze the customer's brake pedal feel requirements to generate customer brake performance requirement data, determine the upper and lower limit curves based on the customer brake performance requirement data to generate brake deceleration upper and lower limit curve data, and store the data to build a brake boundary database.

[0008] S2: When braking is triggered, collect the initial braking state data, verify the vehicle speed to generate the verified initial vehicle speed data, and record the time to generate the braking start timestamp data.

[0009] S3: Calculate the initial value of the dynamic proportional coefficient based on the initial vehicle speed v0 after verification at the moment of brake triggering; after nonlinear correction in combination with the driving mode, generate the dynamic proportional coefficient i for this braking cycle;

[0010] S4: Extract the upper and lower limit decelerations corresponding to the stroke to generate stroke-deceleration corresponding data, weighted fuse to generate initial target deceleration data, and after correction, generate final target deceleration request data;

[0011] S5: During the locking cycle, generate cycle locking parameter data, monitor the system reset signal after pedal release, and store data to generate braking history data.

[0012] S6: Generate vehicle-specific boundary parameters by calibrating parameters, and establish an index to generate vehicle-specific adaptation control data.

[0013] The present invention proposes a non-transitory computer-readable storage medium storing a computer program, characterized in that the program is executed by a processor to implement a method for braking deceleration requirements of a brake-by-wire system as described above.

[0014] The present invention provides a computer program product comprising a computer program / instruction that, when executed by a processor, implements a method for braking deceleration requirements of a brake-by-wire system as described above.

[0015] The beneficial effects of this invention are as follows: At low speeds, the dynamic proportional coefficient i approaches 0, biasing towards dec_min(s) to achieve smooth braking and reduce jerking; at high speeds, i approaches 1, biasing towards dec_max(s) to achieve sensitive response, conforming to human factors engineering, adapting to the driver's intuitive expectations, and improving the consistency of the driving experience; even with light pedal application at high speeds, sufficient deceleration can be obtained through the high-weighted dec_max(s), shortening the emergency braking distance, reducing the risk of high-speed braking, and enhancing braking safety; by replacing hardware adjustments with software calibration, the number of component variations is reduced by more than 50%, the development cycle is shortened by 30%~40%, and the overall vehicle manufacturing cost is reduced; the final target deceleration request data can be directly used as the longitudinal control input for autonomous driving (ACC, AEB), and the motor braking ratio can be embedded in dec_min(s) to maximize energy recovery without affecting pedal feel, and is compatible with intelligent driving and energy recovery; through vehicle-specific boundary parameter calibration, the same system can be adapted to different vehicle models such as sedans, SUVs, and commercial vehicles, enhancing the large-scale application value of the brake-by-wire system. Attached Figure Description

[0016] Figure 1 This is a diagram of the method described in this invention;

[0017] Figure 2This is a schematic diagram of the upper and lower limit curves described in this invention. Detailed Implementation

[0018] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0019] One embodiment of the present invention, such as Figure 1 As shown, a method for meeting the braking deceleration requirements of a brake-by-wire system, the method comprising:

[0020] S1: Perform parametric analysis on the brake pedal feel performance requirements of vehicle customers, clarify the maximum and minimum acceptable values ​​of braking intensity under different brake push rod strokes, and generate customer braking performance requirement data; based on the customer braking performance requirement data, use experimental calibration (such as bench testing to collect multiple sets of stroke-deceleration samples) or function fitting (such as polynomial fitting) to determine the upper and lower limit curves of braking deceleration as a function of brake push rod stroke (unit: mm), and generate upper and lower limit curve data of braking deceleration (where the upper limit curve corresponds to the maximum deceleration dec_max(s), and the lower limit curve corresponds to the minimum deceleration dec_min(s), where s is the brake push rod stroke), such as... Figure 2 As shown, the upper and lower limit curve data of braking deceleration are imported into the electronic control unit (ECU) of the brake-by-wire system, and a data index and calling interface are established to build a braking boundary database, providing basic parameter support for subsequent deceleration mapping.

[0021] S2: When the driver presses the brake pedal to trigger the braking action, the ECU calls the parameter requirements of the braking boundary database to collect the vehicle's operating status at the moment of braking in real time, and obtains the initial braking state data including the initial vehicle speed v0 (unit: km / h) and the pedal trigger signal; the initial vehicle speed v0 in the initial braking state data is validated (such as excluding out-of-range vehicle speed values ​​and fluctuating vehicle speed values ​​caused by sensor malfunctions), and the validated initial vehicle speed data is generated; at the same time, the system time at the moment of braking trigger is recorded to generate braking start timestamp data, which is used to bind the parameter calculation logic of this braking cycle;

[0022] S3: Calculate the initial value of the dynamic proportional coefficient based on the initial vehicle speed v0 after verification at the moment of braking trigger (the sole criterion); after nonlinear correction in combination with the driving mode, generate the dynamic proportional coefficient i for this braking cycle; this coefficient is only bound to the initial vehicle speed during braking and remains fixed throughout the entire braking cycle (regardless of the duration of braking or whether the pedal is released), and does not change with time; through associated storage and locking mechanisms, ensure that the coefficient only serves this braking, providing stable parameters for deceleration weighted fusion;

[0023] S4: Based on the current push rod stroke s collected in real time by the brake push rod stroke sensor, call the upper and lower limit curve data of braking deceleration in the braking boundary database, extract the maximum deceleration dec_max(s) and minimum deceleration dec_min(s) corresponding to the stroke s, and generate stroke-deceleration corresponding data; based on the dynamic proportional coefficient i in the weight coefficient-timestamp association data, perform weighted fusion calculation on the stroke-deceleration corresponding data (calculation formula: deceleration(s,v0)=i×dec_max(s)+(1-i)×dec_min(s)) to generate initial target deceleration data; perform smoothness detection on the initial target deceleration data (such as judging whether the rate of change of deceleration at adjacent times exceeds the preset threshold), if there is a jump, perform filtering correction, and generate final target deceleration request data as the control command of the braking actuator;

[0024] S5: Based on the braking start timestamp data, set the time range of this braking cycle (from pedal depressing to full release), lock the dynamic proportional coefficient i and initial vehicle speed v0 corresponding to the final target deceleration request data, and generate cycle locking parameter data to prevent deceleration jumps caused by vehicle speed decreases during braking, ensuring braking stability; monitor the brake pedal status in real time through the pedal position sensor, and when the pedal is fully released signal is detected, clear and reset the cycle locking parameter data and weight coefficient-timestamp correlation data, and generate a system reset signal; at the same time, store the travel-deceleration data and initial vehicle speed data of this braking cycle in the ECU's historical database to generate braking history data, providing sample support for subsequent parameter optimization;

[0025] S6: Based on historical braking data, analyze the different braking pedal feel requirements of different vehicle models (such as sedans and SUVs), recalibrate the parameters Vmin, Vmax, dec_max(s), and dec_min(s) in the braking boundary database, and generate vehicle-specific boundary parameters; import the vehicle-specific boundary parameters into the braking boundary database and establish a vehicle parameter index table to realize the function of switching vehicle parameters with one click, and generate vehicle-specific adaptation control data; through vehicle-specific adaptation control data, the same line-controlled braking system can be adapted to different brands and different levels of vehicles without changing the hardware structure, thus improving the system's platform application capabilities.

[0026] The working principle and effects of the above technical solution are as follows:

[0027] By transforming customers' qualitative requirements for brake pedal feel (such as smooth at low speeds and sensitive at high speeds) into upper and lower limit parameters of deceleration under different strokes, and combining bench testing and function fitting to generate accurate dec_max(s) and dec_min(s) curves and establish a braking boundary database, the feasibility of transforming customer requirements into technical parameters is improved, the braking control deviation caused by ambiguous requirements is reduced, and basic parameters that fit actual needs are provided for subsequent deceleration calculations.

[0028] By accurately collecting the initial vehicle speed v0 at the moment of braking triggering (averaging 3 samples within 10ms), verifying its validity (excluding outliers and relying on multi-sensor integrated algorithm compensation), and binding a millisecond-level timestamp to define the period, the reliability of the initial braking state data is ensured, the interference of single sensor failure or instantaneous fluctuations on the parameter benchmark is reduced, and a stable starting point is provided for the calculation of dynamic proportional coefficient.

[0029] By binding the dynamic proportional coefficient i only to the initial braking speed v0 (linear interpolation + nonlinear correction of driving mode) and keeping it fixed throughout the entire braking cycle (unaffected by duration or pedal release), the continuity of deceleration output is enhanced, and the sudden changes in braking force caused by the decrease in vehicle speed or changes in operation during braking are reduced, making the pedal feel felt by the driver more consistent and in line with expectations.

[0030] By collecting the stroke s in real time and calling the database parameters, dec_max(s) and dec_min(s) are weighted and fused with a fixed coefficient i, and then the final control command is generated after smoothness detection (correcting pressure or deceleration jumps). This improves the real-time matching degree between deceleration and pedal operation, reduces the body jerking caused by high-frequency fluctuations or sudden changes, and makes the braking process smoother.

[0031] By locking key parameters during the braking cycle, resetting them after the cycle, and storing historical data, the stability of single-cycle braking is ensured, and real samples are accumulated for subsequent parameter optimization. This reduces the risk of data confusion between new and old cycles and enhances the system's iterative capabilities.

[0032] By analyzing historical data to calibrate parameters specific to different vehicle models and establishing an index table, one-click switching can be achieved. This allows for adaptation to multiple vehicle models, such as sedans and SUVs, without the need to modify hardware. This reduces the development cost of cross-vehicle adaptation, enhances the system's platform application capabilities, and reduces redundant investment in developing separate hardware for each vehicle model.

[0033] In one embodiment of the present invention, S1 includes:

[0034] S11: Collect qualitative requirements (such as no jerking at low speeds, sensitive braking at high speeds, and fast emergency braking response) and quantitative indicators (such as maximum and minimum permissible deceleration under a specific travel distance) for brake pedal feel from vehicle customers (such as car manufacturers, vehicle project teams). Use a demand-parameter mapping table (e.g., mapping no jerking at low speeds to dec≤0.3m / s² when s≤5mm) to decompose the requirements into multiple dimensions and generate customer braking performance requirement data containing travel range, deceleration upper and lower limits, and operating condition labels. Perform consistency verification on the requirement data (e.g., exclude contradictory requirements where maximum deceleration < minimum deceleration under the same travel distance).

[0035] S12: Based on customer braking performance requirements, the test calibration method combines bench testing and real vehicle road testing to simulate different pedal travels on a real vehicle and collect corresponding deceleration values.

[0036] S13: Clean the deceleration samples corresponding to different push rod pedal strokes collected in S12 from the test bench and actual vehicle (e.g., remove outliers caused by sensor fluctuations) to ensure the validity of the samples; integrate the cleaned test bench samples and actual vehicle samples into a unified stroke-deceleration sample set, and use cubic polynomial fitting (e.g., dec=a×s³+b×s²+c×s+d, where a, b, c, and d are fitting coefficients) to generate the upper limit curve of braking deceleration (dec_max(s), corresponding to the maximum acceptable braking intensity for customers) and the lower limit curve (dec_min(s), corresponding to the minimum acceptable braking intensity for customers).

[0037] S14: Verify the error of the fitted upper and lower limit curves: Calculate the mean square error between the curve fitting value and the measured values ​​of the bench + real vehicle samples collected in S12, ensuring that the error is ≤5%, and generate brake deceleration upper and lower limit curve data with qualified accuracy (including fitting coefficient, travel interval, and error range); import the curve data into the electronic control unit (ECU) storage module of the brake-by-wire system in binary format.

[0038] S15: Establish a data indexing mechanism at the ECU software layer (e.g., use stroke s as the index key to quickly call the corresponding dec_max(s) and dec_min(s)), and use a standardized calling interface (to support ECU real-time reading and periodic verification of curve data); perform redundant backups of the database (e.g., dual-zone storage of curve data to prevent single-zone data corruption), and generate a brake boundary database containing a data storage area, an index table, a calling interface, and a backup area.

[0039] The working principle and effects of the above technical solution are as follows:

[0040] By simulating the push rod pedal stroke with a step length of 0~30mm on the test bench and the actual vehicle, and simultaneously collecting the corresponding deceleration values, a basic sample covering the conventional braking stroke is provided for subsequent curve fitting, which improves the integrity of the initial sampling data and reduces the curve fitting discontinuity problem caused by excessive stroke sampling interval or missed sampling.

[0041] By first cleaning the deceleration samples collected from the test bench and the actual vehicle, removing outliers caused by instantaneous fluctuations in the sensors, and then supplementing and fusing the travel-deceleration samples of the actual vehicle under low-speed / medium-speed / high-speed conditions, the effectiveness and adaptability of the sample data under all conditions are enhanced, and the situation where the fitted curve deviates from the actual driving requirements caused by single-scenario samples is reduced.

[0042] By calculating the mean square error between the fitted curve and the bench + actual vehicle measured values ​​twice to ensure that the error is ≤5%, and by importing the high-precision deceleration upper and lower limit curve data into the ECU storage module in binary format, the accuracy deviation of the curve fitting is reduced, and the problem of "soft" or "hard" pedal feel caused by inaccurate curves during subsequent braking mapping is reduced.

[0043] By establishing a fast call mechanism with stroke s as the index key at the ECU software layer, developing a standardized interface that supports real-time reading and periodic verification, and performing dual-zone redundant backup of curve data, the parameter call efficiency and data security of the braking boundary database are improved, reducing the risk of braking response lag caused by data call delay or parameter loss caused by single-zone data corruption.

[0044] In one embodiment of the present invention, S2 includes:

[0045] S21: When the driver presses the brake pedal, the pedal position sensor outputs a brake trigger signal. After receiving the trigger signal, the ECU calls the parameter call interface of the brake boundary database to trigger the vehicle operating status acquisition process.

[0046] S22: The instantaneous vehicle speed (i.e., initial vehicle speed v0, unit: km / h) at the moment of braking initiation is collected by the vehicle speed sensor, and the initial travel of the pedal is collected by the pedal displacement sensor. The data are integrated into the initial braking state data, which includes the initial vehicle speed v0, the initial pedal travel, and the braking trigger signal. In addition, the acquisition process is set with a mechanism of three consecutive samplings within 10ms to avoid single sampling errors and ensure data timeliness.

[0047] S23: Read the initial vehicle speed v0 (unit: km / h) at the braking start moment calculated by the multi-sensor integrated algorithm from the vehicle network. This vehicle speed is a unified standard data for the whole vehicle, and other systems use it as a benchmark. There is no need to check the vehicle speed deviation or fluctuation (even if individual sensors fail, the effective vehicle speed can be estimated through algorithm compensation). Only check whether the vehicle speed data is obtained: if v0 is successfully read, it is directly used as the initial vehicle speed data after verification without additional correction. If no vehicle speed is obtained (i.e. no vehicle speed signal), it is marked as "no vehicle speed condition", and the verified data without vehicle speed label is generated (in subsequent steps, braking is applied according to the logic of i=1, and the upper limit curve dec_max(s) is called first to ensure greater braking strength and improve safety), avoiding the risk of insufficient braking strength due to no vehicle speed.

[0048] S24: The ECU reads the system real-time clock (accuracy up to 1ms), records the specific time when the braking trigger signal is received (e.g., YYYY-MM-DDHH:MM:SS:XXX), and generates braking start timestamp data; the timestamp data is bound to the verified initial vehicle speed data (e.g., through data frame format association, with the timestamp as the frame header and the vehicle speed as the frame data), clearly identifying the start of this braking cycle, providing a time reference for the subsequent periodic locking of the dynamic proportional coefficient, and ensuring that the parameter calculation logic strictly corresponds to the braking cycle.

[0049] The working principle and effects of the above technical solution are as follows:

[0050] After receiving the braking trigger signal by the ECU, the braking boundary database interface is immediately invoked and the vehicle operating status acquisition process is triggered to improve the timeliness of the initial braking status data acquisition, reduce the chance of missing key information at the moment of braking initiation, and ensure that the subsequent dynamic proportional coefficient calculation can be based on an accurate initial reference.

[0051] By using a mechanism that samples the initial vehicle speed and the initial pedal travel three times consecutively within 10ms, the error caused by the instantaneous fluctuation of the sensor in a single sampling is reduced, the accuracy of the initial braking state data is improved, and the integrated "vehicle speed-travel-trigger signal" data can truly reflect the actual vehicle situation at the moment the pedal is pressed.

[0052] By reading the unified standard vehicle speed calculated by the multi-sensor integrated algorithm in the vehicle network (the algorithm can compensate for individual sensor failures), there is no need to additionally check the vehicle speed deviation or fluctuation. It only determines whether the vehicle speed has been obtained, which improves the efficiency of vehicle speed call and reduces the response delay caused by redundant verification. When there is no vehicle speed, the upper limit curve is called by i=1 to avoid the risk of insufficient braking strength and enhance driving safety.

[0053] By binding the braking start timestamp with 1ms precision to the initial vehicle speed after verification, the starting identifier of this braking cycle is clearly defined, providing a clear time reference for the subsequent cycle locking of the dynamic proportional coefficient, reducing the problem of mismatch between parameter calculation logic and braking cycle, and enhancing the coherence and stability of the entire braking control process.

[0054] In one embodiment of the present invention, S24 includes:

[0055] After receiving the braking trigger signal, the ECU immediately calls the high-precision reading interface (accuracy up to 1ms) of the system real-time clock module to read the specific moment when the signal is received; the moment is standardized and encoded according to the YYYY-MM-DDHH:MM:SS:XXX (year-month-day hour:minute:second:millisecond) format to avoid time format confusion; the encoded moment data is used as the initial timestamp to generate initial timestamp data containing the original moment and the standardized encoding;

[0056] The initial timestamp data is validated by comparing it with the internal reference clock of the ECU (such as the GPS synchronization clock). If the time deviation is greater than 5ms, it is determined that the clock synchronization is abnormal, and the clock calibration is triggered to reread the time.

[0057] Invalid data whose time exceeds the system time range (such as incorrect year or time jump) is excluded; after verification, the standardized coded time is determined as the braking start timestamp, and valid braking start timestamp data is generated.

[0058] Based on the effective braking start timestamp data and the verified initial vehicle speed data, a binding format of frame header-frame data-check bit is defined. The effective braking start timestamp is used as the frame header (occupying 16 bytes), and the verified initial vehicle speed v0 (including unit identifier) ​​is used as the frame data (occupying 4 bytes). An additional 2-byte CRC check bit is added (used to verify data integrity). The two types of data are integrated and packaged according to this format to generate a timestamp-vehicle speed bound data frame, and the physical association between time and vehicle speed is established.

[0059] Add a braking cycle start flag bit to the end of the timestamp-vehicle speed binding data frame (e.g., set a 1-byte flag bit to 0x01 to represent the start of this braking cycle); store the binding data frame with the added flag bit in the cycle parameter cache area of ​​the ECU and record the storage address; generate braking cycle start reference data containing binding data frame-storage address-start flag.

[0060] The working principle and effects of the above technical solution are as follows:

[0061] By calling the system's real-time clock interface with 1ms precision, and using the standardized encoding of "YYYY-MM-DDHH:MM:SS:XXX", the acquisition accuracy and format consistency of the braking start timestamp are improved, avoiding subsequent data association errors caused by chaotic time formats, and ensuring that the start time of each braking cycle can be accurately recorded.

[0062] By comparing the initial timestamp with the ECU's internal GPS reference clock, calibration is triggered if the deviation exceeds 5ms. Invalid data such as incorrect year and time jump are also eliminated, reducing the error caused by time synchronization anomalies, enhancing the reliability of the braking start timestamp, and avoiding the impact of inaccurate time on subsequent parameter cycle locking.

[0063] The binding format of frame header-frame data-check bit is adopted, and a 2-byte CRC check is added to the timestamp and the vehicle speed after verification. This improves the integrity of the binding of the two types of data, reduces mismatch and loss problems during data storage or transmission, and ensures that time and vehicle speed can correspond accurately.

[0064] Add a braking cycle start flag to the end of the bound data frame, then store it in the ECU cycle parameter cache and record the address to generate clear braking cycle start reference data. This clearly defines the start point of each braking cycle, reduces the risk of non-correspondence between the cycle and the subsequent dynamic proportional coefficient locking, and enhances the coherence of the entire braking control process.

[0065] In one embodiment of the present invention, S3 includes:

[0066] S31: Read the preset vehicle speed threshold parameters from the braking boundary database: low speed threshold Vmin (typical value 10km / h, corresponding to parking and congested driving conditions), high speed threshold Vmax (typical value 80km / h, corresponding to expressway and highway conditions); calculate the initial value of the proportional coefficient using a linear interpolation formula based solely on the initial vehicle speed v0 after verification at the moment of braking trigger: if v0≤Vmin, then the initial value of i=0 (completely dependent on the lower limit curve); if v0≥Vmax, then the initial value of i=1 (completely dependent on the upper limit curve); if Vmin<v0<Vmax, then the initial value of i=(v0-Vmin) / (Vmax-Vmin); after the calculation is completed, generate the initial value of the linear proportional coefficient i, clarifying that this initial value "is determined only by the initial vehicle speed and is not adjusted with subsequent braking duration or vehicle speed changes", establishing the relationship between the initial vehicle speed and the weight. Unique correlation; S32: The ECU reads the current driving mode signal (Comfort / Sport / Standard mode) and performs nonlinear correction on the initial value of i according to the judgment logic: If it is the Standard mode, the initial value of i is directly used as the dynamic proportional coefficient i; if it is the Comfort mode, the S-shaped function (i=1 / (1+e^(-k(v0-Vmin))), k=0.05) is used to correct the initial value of i, enhancing the smoothness of the weight in the low-speed segment; if it is the Sport mode, the exponential function (i=(v0-Vmin)² / (Vmax-Vmin)²) is used to correct the initial value of i, improving the sensitivity of the weight in the high-speed segment; after correction, i∈[0,1] is ensured, and the fixed dynamic proportional coefficient i for this braking cycle is generated. It is clear that this coefficient is locked as the current value and will not change regardless of how long the braking lasts or whether the pedal is released or depressed, taking into account both personalized needs and parameter stability;

[0067] S33: Jointly associate and store the dynamic proportional coefficient i with "initial braking speed v0 + braking start timestamp": Use a key-value storage structure, with "initial vehicle speed v0_braking start timestamp" as the joint key (ensuring a unique correspondence with this braking), and a fixed dynamic proportional coefficient i as the value, and write it to the temporary storage area of ​​the ECU; clearly define the storage rule "only valid within this braking cycle, and the coefficient value cannot be modified after storage", to avoid data confusion between different braking cycles, and at the same time strengthen the storage logic that "the coefficient is bound to the initial vehicle speed and is independent of time";

[0068] S34: Set a data forced lock flag: prohibit any modification to the dynamic proportional coefficient i during braking (regardless of duration or speed change); generate a coefficient lock log, clearly recording "coefficient calculation basis (initial braking speed v0), correction method (corresponding driving mode), and lock status (fixed within this braking cycle)"; finally generate weight coefficient-initial speed-timestamp associated data to ensure that the dynamic proportional coefficient i "is determined only by the initial braking speed and does not change with time or braking duration", providing stable and tamper-proof fixed weight parameters for subsequent deceleration weighted fusion.

[0069] The working principle and effects of the above technical solution are as follows:

[0070] By calculating the initial value of the proportional coefficient based solely on the initial vehicle speed v0 at the moment of brake triggering, it is clarified that this value "does not adjust with changes in braking duration or vehicle speed," thereby improving the matching accuracy between the coefficient and the initial braking condition, reducing coefficient fluctuations caused by vehicle speed reduction during braking, and ensuring that the weighting benchmark remains stable and consistent from beginning to end.

[0071] By fixing the dynamic proportional coefficient i to a fixed value for the current braking cycle (regardless of duration or whether the pedal is released or depressed), the stability of the coefficient is enhanced, reducing the sudden changes in deceleration caused by pedal operation changes or braking duration differences during driving, and making the braking force felt by the driver more consistent.

[0072] By using "initial vehicle speed v0_braking start timestamp" as the joint key to store the coefficient, and explicitly stating that "it cannot be modified after storage", the distinguishability and anti-confusion ability of data of different braking cycles are improved, the risk of mis-association of coefficients of previous and subsequent braking cycles is reduced, and the coefficient of each cycle can accurately correspond to its initial vehicle speed.

[0073] By setting a data lock flag and prohibiting any modifications during the braking process, coupled with logs recording the basis for coefficient calculation and the lock status, the reliability and traceability of the coefficients are enhanced, reducing the possibility of accidental tampering or parameter drift, and providing consistently stable fixed weight support for subsequent deceleration weighted fusion.

[0074] In one embodiment of the present invention, S33 includes:

[0075] Based on the generated dynamic proportional coefficient i, braking start timestamp data, and the verified initial vehicle speed v0 at the moment of braking trigger, the specific rules for the key-value storage structure are determined, namely: using "verified initial vehicle speed v0_braking start timestamp" as the joint key (v0 retains one decimal place, formatted as "50.0_YYYY-MM-DDHH:MM:SS:XXX", precisely associating the initial vehicle speed with time to ensure the uniqueness of the joint key for each braking cycle); using the dynamic proportional coefficient i as the value, defined as a format of 6 decimal places (e.g., 0.500000, to ensure calculation accuracy); and simultaneously setting dual verification rules for the key-value correspondence (first, the binding of the joint key and coefficient i must pass CRC verification to prevent data mismatch; second, verifying whether v0 in the joint key is the basis for the calculation of coefficient i to avoid incorrect association of i with non-corresponding v0), generating storage structure rule data containing joint key format, value format, and dual verification rules;

[0076] According to the storage structure rules, the "verified initial vehicle speed v0_braking start time stamp" joint key and the dynamic scaling factor i are packaged together: first, the joint key (v0 and timestamp) is binary encoded, then the dynamic scaling factor i is converted into a binary decimal that meets the format requirements, and the CRC check code is calculated through the double verification rules (covering the complete data of the joint key and i) and appended to the end of the data.

[0077] The encoded key-coefficient i-check code are integrated into a fixed-length data frame (e.g., 32 bytes, to match the read / write granularity of the ECU temporary storage area), generating a key-value association data unit. The byte allocation of each field in the data frame is specified (e.g., the key occupies 18 bytes, the coefficient i occupies 6 bytes, and the check code occupies 8 bytes) to ensure that the data format is fully adapted to the ECU storage module.

[0078] The ECU calls the status detection interface of the temporary storage area to perform an availability test on the target storage area (preset as the temporary partition of the braking cycle): it checks whether the partition has insufficient storage space (at least 10 data frames of redundant space need to be reserved), data conflicts (whether there are already key-value pairs with the same "v0_timestamp" composite key); if there are no abnormalities, the storage area is determined to be available, and a storage area verification result of "storage area available - target address - composite key uniqueness verification passed" is generated; if there are abnormalities (such as insufficient space or composite key conflicts), the redundant partition switching of the temporary storage area is triggered to ensure that the associated data can be written normally and is not confused with other cycle data;

[0079] Based on the target address in the storage area verification results, the key-value association data unit is written to the braking cycle temporary partition of the ECU temporary storage area. At the same time, a valid cycle identifier is appended to the end of the data unit to clarify that the data unit is only valid within the current braking cycle (from brake triggering to pedal full release), and the coefficient i cannot be modified within the cycle. After writing, the ECU reads the stored data for back-read verification (compares the written key and coefficient i with the back-read data to see if they are consistent, and also verifies the calculation correlation between v0 and i in the key). If the verification is successful, the storage completion data "Data writing successful - valid cycle marking completed - key association valid" is generated to ensure that the dynamic proportional coefficient i is strongly bound to "initial vehicle speed v0 + braking start timestamp" and only serves the current braking cycle.

[0080] The working principle and effects of the above technical solution are as follows:

[0081] By using "verified initial vehicle speed v0_braking start time stamp" as the joint key (retaining one decimal place for v0 + millisecond-level timestamp), the key-value pair of each braking cycle is ensured to be unique, which improves the distinguishability of data from different braking cycles, reduces the risk of duplicate association due to a single timestamp, and allows the dynamic proportional coefficient i to be accurately bound to the corresponding initial vehicle speed scenario.

[0082] By using a dual verification rule (CRC check to prevent data mismatch + check whether v0 is the basis for i calculation), the accuracy of key-value association is enhanced, the problem of parameter binding failure caused by misassociation of i that does not correspond to v0 or data transmission errors is reduced, and the stored i is indeed calculated from the initial vehicle speed of this braking.

[0083] By fixing the data frame to 32 bytes and specifying the byte allocation of each field (18 bytes for the union key, 6 bytes for the i value, and 8 bytes for the checksum), the compatibility of the data format with the ECU temporary storage area is improved, reducing write failures caused by format incompatibility and allowing data to be smoothly stored in the storage module.

[0084] By performing joint key conflict detection on the storage area, reserving 10 frames of redundant space, and switching the redundant partition in case of anomalies, the reliability of the storage process is enhanced, avoiding data failure to be written due to insufficient space or key value conflicts, and ensuring that i in each braking cycle can be successfully stored.

[0085] After writing, a readback verification is performed (comparing the union key, the value of i, and the correlation between v0 and i), an effective period identifier is added, and modification of i within the period is prohibited. This improves the validity and stability of the stored data, reduces the risk of cross-period data interference or accidental tampering, and ensures that i is always strongly bound to the initial vehicle speed of this braking, providing reliable weight support for subsequent deceleration calculations.

[0086] In one embodiment of the present invention, step S4 includes:

[0087] S41: During braking, the ECU collects the current brake lever travel s in real time through the pedal displacement sensor (sampling frequency 100Hz to ensure real-time performance); based on the current travel s, it calls the index table of the braking boundary database to quickly query the corresponding maximum deceleration dec_max(s) and minimum deceleration dec_min(s) under this travel.

[0088] S42: If the current stroke s exceeds the stroke range of the fitted curve (e.g., s > 30 mm), then the maximum strength level is maintained without increasing; the current stroke s - dec_max(s) - dec_min(s) are integrated into stroke-deceleration corresponding data to provide real-time deceleration boundary parameters for weighted fusion;

[0089] S43: Read the dynamic proportional coefficient i of the current braking cycle from the weight coefficient-timestamp association data, and call the preset weighted fusion formula: deceleration(s,v0)=i×dec_max(s)+(1-i)×dec_min(s); Substitute dec_max(s), dec_min(s) and the dynamic proportional coefficient i from the stroke-deceleration corresponding data into the formula to calculate the instantaneous deceleration value under the current stroke;

[0090] S44: A sliding window averaging method (window size of 5 sampling points) is used to initially smooth the continuously calculated deceleration values, reduce high-frequency fluctuations, generate initial target deceleration data, and initially match the driver's braking intention;

[0091] S45: Perform smoothness detection on the pressure control parameters corresponding to the initial target deceleration data, calculate the pressure change rate (ΔP / Δt) between two adjacent sampling times, and adapt this change rate to the operating speed of the pedal stroke (the speed of pressing or releasing); set a pressure change rate threshold (e.g., 5 bar / 10 ms, exceeding this threshold is judged as a pressure jump that may cause a sudden deceleration change); if a jump is detected, use a gradient limiting algorithm (dynamically adjust the pressure change slope according to the pedal operating speed) to correct the jump point, ensuring a smooth transition of pressure increase and decrease; compare the corrected pressure control parameters with the maximum pressure output capability of the brake actuator (e.g., the maximum hydraulic pressure driven by the motor) to ensure that it does not exceed the hardware limitations of the actuator; generate final pressure control command data that meets the dual requirements of pressure smoothness and execution capability, as the control signal sent by the ECU to the brake actuator (e.g., hydraulic unit, motor), and achieve the target deceleration by regulating the internal pressure state of the system.

[0092] The working principle and effects of the above technical solution are as follows:

[0093] By acquiring the current push rod travel at a high frequency of 100Hz and quickly querying the corresponding dec_max(s) and dec_min(s) in the braking boundary database index table, the real-time performance of travel data acquisition and the efficiency of deceleration parameter retrieval are improved, the braking response lag caused by data acquisition delay is reduced, and the parameters can accurately keep up with the driver's pedal operation rhythm.

[0094] By using extrapolation to supplement deceleration for cases exceeding the travel range (e.g., s > 30 mm) while maintaining maximum intensity without increasing, the safety risks caused by excessive braking are avoided. At the same time, the travel-deceleration corresponding data are fully integrated to provide boundary parameters covering the entire travel range for weighted fusion, reducing braking control gaps caused by missing travel data.

[0095] By reading the fixed dynamic proportional coefficient i of this braking cycle and substituting it into the formula to calculate the instantaneous deceleration, it is ensured that the deceleration is only bound to the initial vehicle speed and does not change with the braking process, thereby improving the stability of the deceleration output and reducing the sudden changes in braking intensity caused by coefficient fluctuations, which is in line with the driver's stable expectations for pedal feel.

[0096] The deceleration value is initially smoothed by averaging through a sliding window (5 sampling points), which reduces the interference of high-frequency fluctuations on the initial target deceleration, makes the data more consistent with the driver's braking intention, and reduces the basic data error of subsequent pressure control.

[0097] By focusing on the smoothness detection of pressure control parameters (calculating ΔP / Δt), associating the pedal operation speed with the rate of change, correcting pressure jumps with gradient limiting algorithms, and comparing the maximum pressure output capacity of the actuator, the deceleration shock caused by sudden pressure changes is avoided, and the failure caused by exceeding hardware limits is prevented. The target deceleration is achieved through precise pressure control, making the braking process smoother and safer.

[0098] In one embodiment of the present invention, step S5 includes:

[0099] S51: Based on the braking start timestamp data, the ECU sets the time range of this braking cycle, from the moment the braking trigger signal is received to the moment the pedal is fully released signal is received; within this cycle, the core parameters corresponding to the final target deceleration request data, namely the dynamic proportional coefficient i and the initial vehicle speed v0 after verification, are locked: the ECU is prohibited from recalculating or modifying these two parameters, and the initial parameters remain unchanged even if the vehicle speed decreases during braking (e.g., from 80km / h to 40km / h);

[0100] S52: Integrates the locked parameters with the braking cycle time range to generate cycle lock parameter data, preventing deceleration from jumping due to changes in vehicle speed and ensuring the smoothness of the braking process; The ECU monitors the brake pedal status in real time through the pedal position sensor, sets the pedal travel ≤0.5mm as the condition for complete release, and determines the end of the braking cycle when the condition is met for 50ms consecutively.

[0101] S53: The ECU immediately triggers the system reset process: clears the periodic lock parameter data and weight coefficient-timestamp association data in the temporary storage area; resets the braking start timestamp record and initial vehicle speed acquisition mark; sends a reset command to the braking actuator to restore it to its initial state; after the reset is completed, a system reset signal is generated, indicating that the ECU is ready to respond to the next braking request;

[0102] S54: Before the system reset, the ECU integrates the key data of this braking cycle, namely the braking start timestamp, the initial vehicle speed v0 after verification, the dynamic proportional coefficient i, the stroke-deceleration corresponding data sequence, and the final target deceleration request data sequence, into a braking cycle data frame; writes this data frame into the ECU's historical database (storage capacity supports 1000 braking cycle data, using a first-in-first-out mechanism to overwrite old data); classifies and labels the historical data (e.g., according to low-speed conditions, high-speed conditions, and emergency braking conditions), and generates braking historical data containing condition labels, cycle data, and calculation logs.

[0103] The working principle and effects of the above technical solution are as follows:

[0104] By locking the dynamic proportional coefficient i and the initial vehicle speed v0 during the braking cycle, the parameters are not changed even if the vehicle speed decreases during the process. This avoids sudden changes in deceleration due to changes in vehicle speed, improves the smoothness of the braking process, reduces the feeling of jerking, and allows the driver to feel a uniform force throughout the braking process when pressing the pedal, without sudden changes in strength.

[0105] By setting the pedal travel to ≤0.5mm and lasting for 50ms as the cycle end condition, the start and end boundaries of the braking cycle are clearly defined, the accuracy of cycle judgment is enhanced, misjudgment caused by slight pedal vibration is reduced, and it is ensured that the current cycle ends only when the pedal is actually released, without being premature or delayed.

[0106] By immediately clearing temporary data, resetting sensor markers, and resetting actuators after the cycle ends, the ECU can quickly return to its initial state, improving the response speed to the next braking request, reducing the interference of old data residue on the new braking cycle, and avoiding control abnormalities caused by confusion between two braking parameters.

[0107] By storing key data from 1,000 cycles and categorizing it by operating conditions, the system provides real-world driving scenario samples to support subsequent parameter optimization. This enhances the system's iterative capabilities, reduces the limitations of relying on bench testing for optimization, and allows braking parameters to be continuously adjusted based on actual usage, becoming increasingly aligned with users' driving habits.

[0108] In one embodiment of the present invention, step S6 includes:

[0109] S61: Extract braking history data for different vehicle types (e.g., sedans, SUVs, MPVs) from the ECU historical database. Use operating condition clustering analysis (e.g., K-means clustering, grouped by vehicle type) to identify differences in requirements. For example, SUVs, due to their larger body mass, need to increase dec_max(s) at high speeds (e.g., from 0.05s to 0.06s), while MPVs, due to comfort requirements, need to decrease dec_min(s) at low speeds (e.g., from 0.02s to 0.015s). Based on these differences, recalibrate the core parameters of the braking boundary database: adjust Vmin (e.g., set to 15km / h for SUVs) and Vmax (e.g., set to 75km / h for MPVs), and refit the dec_max(s) and dec_min(s) curves. Verify the calibrated parameters using real vehicles (e.g., test braking distance for SUVs at high speeds and test jerking sensation for MPVs at low speeds). After successful verification, generate vehicle-specific boundary parameters.

[0110] S62: Import vehicle-specific boundary parameters (including Vmin, Vmax, dec_max(s) fitting coefficients, and dec_min(s) fitting coefficients) into the braking boundary database, and set up independent vehicle storage partitions (such as sedan partitions and SUV partitions); establish a vehicle parameter index table with vehicle-parameter mapping in the database index layer. The index table contains vehicle code, storage partition address, and parameter version number information (such as vehicle code SUV-01 corresponding to partition address 0x002000); through the index table update interface, support the rapid addition of indexes when adding new vehicle models, generate vehicle parameter index data containing partition mapping, version management, and update interfaces, and perform ordered storage and retrieval of multi-vehicle parameters;

[0111] S63: The ECU receives the vehicle model switching command sent by the vehicle controller (such as transmitting the vehicle model code via the CAN bus), calls the vehicle model parameter index table, and locates the corresponding vehicle model storage partition according to the vehicle model code; it reads the vehicle model-specific boundary parameters of the partition through the parameter call interface and overwrites the currently effective parameters in the braking boundary database (no need to restart the ECU, online switching is supported).

[0112] S64: After the switch is completed, the ECU sends a signal to the vehicle controller to indicate that the parameter switch was successful and records the switch log (including vehicle model code, switch time, and parameter version). This process generates vehicle model adaptation control data consisting of vehicle model code, parameter switch logic, and feedback signal. This allows the same line-controlled braking system to quickly adapt to different brands and vehicle classes without changing the hardware (such as the reaction plate or push rod), significantly improving the system's platform application capabilities.

[0113] The working principle and effects of the above technical solution are as follows:

[0114] By using working condition clustering analysis to uncover the different braking requirements of different vehicle models, and then combining real vehicle verification to recalibrate braking parameters (such as dec_max for SUVs at higher speeds and dec_min for MPVs at lower speeds), the accuracy of adapting vehicle-specific boundary parameters is improved, and the problem of uncomfortable braking feel in some models caused by the "one-size-fits-all" approach to general parameters is reduced, so that the pedal feel of sedans, SUVs, and MPVs can all fit their own vehicle characteristics and usage scenarios.

[0115] By setting up independent vehicle model storage partitions and establishing a vehicle model parameter index table, the orderliness and retrieval efficiency of multi-vehicle model parameter storage are improved. For example, the corresponding parameter partition can be quickly located by vehicle model code, reducing the situation of mixed parameter storage and failure to find or retrieve parameters when calling them, making multi-vehicle model parameter management clearer.

[0116] By supporting online parameter switching without restarting the ECU, the flexibility and response speed of vehicle model adaptation are improved. For example, when switching vehicle models, only the vehicle model code needs to be transmitted to complete the parameter update, reducing the waiting time that traditional hardware modifications require restarting the system. The adaptation process does not interrupt system operation.

[0117] It can be adapted to different car models without modifying the reaction disc, push rod, or other hardware, which greatly reduces the development and vehicle adaptation costs of the braking system, enhances the platform application capability of the system, reduces the redundant work of developing hardware separately for each car model, and the same brake-by-wire system can quickly cover different brands and levels of car models without repeated investment in hardware development.

[0118] In one embodiment of the present invention, a non-transitory computer-readable storage medium is provided having a computer program stored thereon, which is executed by a processor to implement the method described above for braking deceleration requirements of a brake-by-wire system.

[0119] In one embodiment of the present invention, a computer program product includes a computer program / instructions that, when executed by a processor, implement a method for braking deceleration requirements of a brake-by-wire system as described above.

[0120] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for meeting the braking deceleration requirements of a brake-by-wire system, characterized in that, The method includes: S1: Analyze the customer's brake pedal feel requirements to generate customer brake performance requirement data, determine the upper and lower limit curves based on the customer brake performance requirement data to generate brake deceleration upper and lower limit curve data, and store the data to build a brake boundary database. S2: When braking is triggered, collect the initial braking state data, verify the vehicle speed to generate the verified initial vehicle speed data, and record the time to generate the braking start timestamp data. S3: Calculate the initial value of the dynamic proportional coefficient based on the initial vehicle speed v0 after verification at the moment of brake triggering; after nonlinear correction in combination with the driving mode, generate the dynamic proportional coefficient i for this braking cycle; S4: Extract the upper and lower limit decelerations corresponding to the stroke to generate stroke-deceleration corresponding data, weighted fuse to generate initial target deceleration data, and after correction, generate final target deceleration request data; S5: During the locking cycle, generate cycle locking parameter data, monitor the system reset signal after pedal release, and store data to generate braking history data. S6: Calibrate parameters to generate vehicle-specific boundary parameters, and establish an index to generate vehicle-specific adaptation control data; The S3 includes: S31: Read the preset vehicle speed threshold parameters from the braking boundary database; calculate the initial value of the proportional coefficient using a linear interpolation formula based only on the initial vehicle speed v0 after verification at the moment of braking trigger; after the calculation is completed, generate the initial value of the linear proportional coefficient i and establish a unique correlation between the initial vehicle speed and the weight. S32: The ECU reads the current driving mode signal, performs nonlinear correction on the initial value of i according to the judgment logic, and generates a fixed dynamic proportional coefficient i for the current braking cycle; the judgment logic is as follows: if it is the standard mode, the initial value of the linear proportional coefficient i is directly used as the dynamic proportional coefficient i; if it is the comfort mode, the initial value of i is corrected using an S-shaped function; if it is the sport mode, the initial value of i is corrected using an exponential function. S33: Jointly associate and store the dynamic proportional coefficient i with the initial braking speed v0 + the braking start timestamp; S34: Set the data forced lock flag; finally generate the weight coefficient-initial vehicle speed-timestamp associated data.

2. The method for meeting the braking deceleration requirements of a brake-by-wire system according to claim 1, characterized in that, S1 includes: S11: Collect qualitative and quantitative indicators of vehicle customers' requirements for brake pedal feel, use a requirement-parameter mapping table to decompose the requirements into multiple dimensions, generate customer braking performance requirement data, and perform consistency verification on the requirement data; S12: Based on customer braking performance requirements, the test calibration method combines bench testing and real vehicle road testing to simulate different pedal travels on a real vehicle and collect corresponding deceleration values. S13: Clean the deceleration samples corresponding to different push rod pedal strokes; integrate the cleaned bench samples and real vehicle samples into a unified stroke-deceleration sample set, and use cubic polynomial fitting to generate the upper limit curve and lower limit curve of braking deceleration respectively. S14: Verify the error of the fitted curve and generate braking deceleration upper and lower limit curve data with acceptable accuracy; import the braking deceleration upper and lower limit curve data into the electronic control unit storage module of the brake-by-wire system in binary format; S15: Establish a data indexing mechanism at the ECU software layer and generate a braking boundary database through standardized call interfaces; perform redundant backups of the database.

3. The method for meeting the braking deceleration requirements of a brake-by-wire system according to claim 1, characterized in that, The S2 includes: S21: When the driver presses the brake pedal, the pedal position sensor outputs a brake trigger signal. After receiving the trigger signal, the ECU calls the parameter call interface of the brake boundary database to trigger the vehicle operating status acquisition process. S22: The instantaneous vehicle speed at the start of braking is collected by the vehicle speed sensor, and the initial travel of the pedal when it is triggered is collected by the pedal displacement sensor, and the data are integrated into the initial braking state data. S23: Read the initial vehicle speed v0 at the braking start moment calculated by the multi-sensor integrated algorithm from the vehicle network; only judge whether the vehicle speed data is obtained: if v0 is successfully read, it is directly used as the verified initial vehicle speed data without additional correction; if the vehicle speed is not obtained, it is marked as a no-vehicle-speed condition, and verified data with no vehicle speed label is generated. S24: The ECU reads the system real-time clock, records the specific time when the brake trigger signal is received, and generates brake start timestamp data; the timestamp data is then bound to the verified initial vehicle speed data.

4. The method for meeting the braking deceleration requirements of a brake-by-wire system according to claim 1, characterized in that, The S4 includes: S41: During braking, the ECU collects the current brake lever travel s in real time through the pedal displacement sensor; based on the current travel s, it calls the index table of the braking boundary database to quickly query the corresponding maximum deceleration dec_max(s) and minimum deceleration dec_min(s) under this travel. S42: If the current stroke s exceeds the stroke range of the fitted curve, then maintain the maximum intensity level without increasing it; integrate the current stroke s-dec_max(s)-dec_min(s) into stroke-deceleration corresponding data; S43: Read the dynamic proportional coefficient i of the current braking cycle from the weight coefficient-timestamp association data, and call the preset weighted fusion formula; substitute dec_max(s), dec_min(s) and dynamic proportional coefficient i from the stroke-deceleration corresponding data into the formula to calculate the instantaneous deceleration value under the current stroke; S44: The continuously calculated deceleration values ​​are initially smoothed by using a sliding window average to generate initial target deceleration data, which is initially matched to the driver's braking intention; S45: Perform smoothness detection on the pressure control parameters corresponding to the initial target deceleration data, calculate the pressure change rate between two adjacent sampling times; set a pressure change rate threshold; if a jump is detected, use a gradient limiting algorithm to correct the jump point; compare the corrected pressure control parameters with the maximum pressure output capability of the braking actuator; generate final pressure control command data that meets both pressure smoothness and execution capability requirements, and use it as a control signal sent by the ECU to the braking actuator.

5. The method for meeting the braking deceleration requirements of a brake-by-wire system according to claim 1, characterized in that, The S5 includes: S51: Based on the braking start timestamp data, the ECU sets the time range of this braking cycle, from the moment the braking trigger signal is received to the moment the pedal is fully released signal is received; within this cycle, the core parameters corresponding to the data requested for the final target deceleration are processed. S52: The locked parameters are integrated with the braking cycle time range to generate cycle lock parameter data. The ECU monitors the brake pedal status in real time through the pedal position sensor and sets the pedal travel ≤0.5mm as the condition for complete release. When the condition is met for 50ms consecutively, the braking cycle is determined to end. S53: The ECU immediately triggers the system reset process; resets the braking start timestamp record and initial vehicle speed acquisition marker; sends a reset command to the braking actuator to restore it to its initial state; after the reset is completed, a system reset signal is generated, indicating that the ECU is ready to respond to the next braking request; S54: Before the system is reset, the ECU integrates the key data of the current braking cycle into a braking cycle data frame; writes the data frame into the ECU's historical database; classifies and marks the historical data to generate braking history data.

6. The method for meeting the braking deceleration requirements of a brake-by-wire system according to claim 1, characterized in that, The S6 includes: S61: Extract braking history data of different vehicle models from the ECU historical database, and use operating condition clustering analysis to explore the differences in requirements; based on the differences in requirements, recalibrate the core parameters of the braking boundary database; verify the calibrated parameters on real vehicles, and generate vehicle-specific boundary parameters after the verification is passed. S62: Import vehicle-specific boundary parameters into the braking boundary database and set up an independent vehicle storage partition; establish a vehicle parameter index table with vehicle-parameter mapping in the database index layer; generate vehicle parameter index data through the index table update interface, and perform ordered storage and retrieval of multi-vehicle parameters; S63: The ECU receives the vehicle model switching command sent by the vehicle controller, calls the vehicle model parameter index table, locates the corresponding vehicle model storage partition according to the vehicle model code, and reads the vehicle model-specific boundary parameters of the partition through the parameter call interface, overwriting the currently effective parameters in the braking boundary database; S64: After the switch is completed, the ECU sends a signal to the vehicle controller to indicate that the parameter switch was successful and records the switch log; it also generates vehicle model adaptation control data.

7. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the method for braking deceleration requirements of a brake-by-wire system as described in any one of claims 1-6.

8. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the method for braking deceleration requirements of a brake-by-wire system as described in any one of claims 1-6.

Images