Scenario-based arbitration and redundancy switching method, computer device, and storage medium

Abstract

The application discloses a scene-based arbitration and redundancy switching method, a computer device and a storage medium. The method comprises the following steps: after the system is powered on, initialization is performed, and self-checking and state synchronization of a master controller and a slave controller are performed; if the self-checking or the state synchronization fails, a limp-home mode is entered; if the self-checking and the state synchronization succeed, the master controller and the slave controller are controlled to enter a normal working mode and parallel processing, and a periodic monitoring process is executed by an arbitration module; the periodic monitoring process comprises the following steps: it is judged whether a monitoring period arrives; if the monitoring period arrives, it is checked whether a heartbeat signal of the master controller is normal; if the heartbeat signal is normal, the quality of a wheel speed signal is checked; if the quality is abnormal, a scene-based arbitration processing process is executed. When a master system microcontroller unit fails, the embodiment of the application can quickly switch to a slave system microcontroller unit to maintain basic braking functions.

Description

Technical Field

[0001] This application relates to a method for wheel speed signal acquisition, processing and redundancy control in a vehicle braking system, and in particular a dual microcontroller unit (MCU) redundancy scheme that can quickly switch to a slave microcontroller unit to maintain basic braking function when the main system microcontroller unit fails. It belongs to the field of automotive electronic control and chassis safety technology. Background Technology

[0002] Modern automotive chassis control systems, especially anti-lock braking systems (ABS) and electronic stability programs (ESP), rely heavily on accurate, real-time wheel speed signals. Wheel speed signals are not only the basis for calculating vehicle speed, but also a key input for determining wheel slip ratio, achieving precise braking pressure control, and ultimately ensuring vehicle braking stability and safety.

[0003] Traditional wheel speed signal processing is typically handled by a single electronic control unit (ECU). This unit collects signals from all wheel speed sensors, performs analysis, verification, and fault diagnosis. However, this single-point architecture presents a significant risk of single-point failure. If the main control unit completely shuts down due to hardware failure, software malfunction, or power supply issues, the entire braking system will lose accurate wheel speed information. This will directly lead to the failure of advanced braking functions such as ABS, ESP, HDC, and AVH, degrading the vehicle to rely solely on basic hydraulic braking, seriously threatening driving safety.

[0004] While some redundant designs exist in existing technologies, they primarily focus on redundancy at the braking command execution level or for specific intelligent driving parking scenarios. They do not deeply address the redundancy issues in the more fundamental signal acquisition and analysis links at the front end. Failures of wheel speed sensors and their signal processing links are common chassis malfunctions, and existing solutions lack sophisticated redundancy switching strategies that are deeply integrated with specific braking application scenarios for this aspect. Summary of the Invention

[0005] In view of this, this application provides a scenario-based arbitration and redundancy switching method, computer equipment, and storage medium. The embodiments of this application introduce hardware circuits and functional redundancy at the forefront of signal acquisition and analysis, and make intelligent decisions in combination with the upper-layer application status to ensure that when a specific fault occurs in the master system MCU, it can quickly and reliably switch to the slave system MCU and continue to provide reliable wheel speed information to ensure the basic braking function of the vehicle and improve the overall safety level of the system.

[0006] The first aspect of this application discloses a scenario-based arbitration and redundancy switching method. The method includes: after the system is powered on, initialization is performed and self-tests and state synchronization are conducted on the main controller and the slave controller; if the self-test or state synchronization fails, a limp-home mode is entered; if the self-test and state synchronization are successful, the main controller and the slave controller are controlled to enter a normal working mode and parallel processing, and a periodic monitoring process is executed by the arbitration module; the periodic monitoring process includes: determining whether the monitoring period has arrived; if the monitoring period has arrived, checking whether the heartbeat signal of the main controller is normal; if the heartbeat signal is normal, checking the quality of the wheel speed signal; if the quality is abnormal, executing a scenario-based arbitration processing process; the scenario-based arbitration processing process includes: matching a preset scenario-based switching decision rule according to the current vehicle operating state, and generating an arbitration instruction according to the matched rule; according to the arbitration instruction, maintaining the current control mode, triggering an alarm, or executing a redundancy switch from the main controller to the slave controller.

[0007] In some embodiments, checking the quality of the wheel speed signal includes: determining the number of valid wheel speed signals; and defining the wheel speed signal quality as abnormal when the number of signals is less than a preset valid number threshold.

[0008] In some embodiments, matching a preset scenario-based switching decision rule based on the current vehicle operating state includes: determining whether the vehicle is in a first scenario, where the vehicle speed is higher than a first speed threshold and the vehicle is in an emergency braking state; if yes, matching a first decision rule, where the first decision rule is: when the number of invalid wheel speed signals reaches a first value, a suggested switching request is generated; if no, determining whether the vehicle is in a second scenario, where the second scenario is a normal driving state where the vehicle speed is lower than the first speed threshold but higher than a second speed threshold; if yes, matching a second decision rule, where the second decision rule is: when the number of invalid wheel speed signals reaches a second value, a suggested switching request is generated; if no, determining whether the vehicle is in a third scenario, where the third scenario is a parking state where the vehicle speed is lower than the second speed threshold; if yes, matching a third decision rule, where the third decision rule is: not performing a control switch and triggering an alarm; wherein, the second value is greater than the first value.

[0009] In some embodiments, the first speed threshold is 75~85km / h, the first value is 1, the second speed threshold is 15~25km / h, and the second value is 2.

[0010] In some embodiments, performing a redundancy switch from the master controller to the slave controller according to the arbitration instruction includes: if there is a forced switch request, or if there is a suggested switch request and the status signal of the slave controller is valid, then performing a redundancy switch procedure to switch control from the master controller to the slave controller and entering a fault-operable mode to perform degraded braking protection.

[0011] In some embodiments, after entering the fault-operable mode, the method further includes: continuously monitoring whether the system restart conditions or the main controller fault recovery conditions are met; if not met, continuing to run the function degradation mode; if met, ending the fault-operable mode and performing initialization.

[0012] In some embodiments, the method further includes: if there is no forced switching request, or no suggested switching request, or the status signal of the slave controller is invalid, then return, wait for the next monitoring cycle, and / or maintain the current processing mode.

[0013] In some embodiments, the method further includes: if the quality is normal, returning, waiting for the next monitoring cycle, and / or maintaining the current processing mode.

[0014] A second aspect of this application discloses a computer-readable storage medium comprising a stored program, wherein the program, when running, controls the execution of the scenario-based arbitration and redundancy switching method of the above embodiments in the processor of the device.

[0015] A third aspect of this application discloses a computer device, the computer device including a processor and a memory; wherein the memory stores a computer program, the computer program being adapted to be loaded by the processor and executed by the scenario-based arbitration and redundancy switching method of the above embodiments.

[0016] Compared with the prior art, the embodiments of this application have the following beneficial effects: 1. Wheel speed depth signal redundancy: The redundancy design is extended to the fundamental link of wheel speed signal acquisition and analysis, which improves the reliability and availability of the braking system from the source.

[0017] 2. Intelligent scenario-based switching: The switching decision is not limited to MCU hardware failure, but deeply integrates wheel speed signal quality, vehicle dynamic scenarios and upper-level application requirements, avoiding unnecessary switching or switching delays, and making decision control more precise.

[0018] 3. Ensure basic braking function: By using the reliable wheel speed signal of a single axle provided by the system MCU, combined with vehicle model software measurement technology or axle speed information, a usable vehicle dynamic information view can still be constructed after the main system fails completely. This supports the braking system in performing critical anti-lock braking and basic braking functions, realizing the evolution from "fail-safe" to "fail-operable".

[0019] 4. Clear and efficient system architecture: The master and slave MCUs have clearly defined responsibilities, work in parallel, and have a fast and reliable fault detection and redundancy management switching mechanism. The modification to the existing braking system architecture is relatively small and easy to implement. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating the scenario-based arbitration and redundancy switching method provided in this application embodiment.

[0022] Figure 2 This is a diagram illustrating the overall hardware architecture of the dual-MCU redundant wheel speed processing system provided in this application embodiment.

[0023] Figure 3 The complete logic flowchart of the dual MCU redundant wheel speed processing system provided in the embodiments of this application is shown. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] like Figure 1 and Figure 3 As shown in the figure, this application embodiment provides a scenario-based arbitration and redundancy switching method, the method including: S101. After the system is powered on, it initializes and performs self-tests and status synchronization on the master controller and slave controller.

[0027] In this step, the master and slave system MCUs each complete their self-test processes and exchange initial states and self-test results through the redundancy management communication module. By default, the master MCU provides the wheel speed signals for all wheels after the system powers on.

[0028] like Figure 2 As shown, the system includes a master system MCU, a slave system MCU, redundant communication channels, and a system status monitoring and arbitration module (referred to as the arbitration module). Among them: 1. Main System MCU: Configured as the main controller of the braking system, it is responsible for collecting the raw signals from the wheel speed sensors of all four wheels during normal operation, performing high-precision wheel speed calculation and fault diagnosis, and providing complete four-wheel wheel speed information and fault diagnosis status to the upper-level chassis domain controller or vehicle controller.

[0029] 2. Slave MCU: Configured as a slave controller (i.e., redundant controller) of the braking system, operating independently of the master MCU. During normal operation, it acquires wheel speed signals from the two wheels of the drive axle (for front-wheel drive vehicles) or rear axle (exemplary solution) and performs local wheel speed analysis and fault monitoring. Its core function is to take over the wheel speed signal delivery and provide tasks when the master control system fails.

[0030] 3. Redundant Communication Channel: Connected between the master system MCU and the slave system MCU, this channel enables status synchronization, heartbeat monitoring, fault flag transmission, and necessary sharing of raw sensor data. It can be implemented using CAN FD, Ethernet, or a dedicated serial bus, and can employ hardware hot backup and time-slice polling software mechanisms to ensure the reliability of the redundant management communication link. The target switching time is less than 10ms, meaning the communication cycle needs to be less than 10ms.

[0031] 4. System Status Monitoring and Arbitration Module: This module can be embedded in the chassis domain controller or distributed as independent logic within the master and slave system MCUs. This module monitors in real time: 4-1. Operating status of the main system MCU (via crystal oscillator, heartbeat, watchdog timer, etc.); 4-2. Validity of the wheel speed signal reported by the main system MCU; 4-3. Wheel speed fault diagnosis status reported by the main system MCU; 4-4. Current vehicle operating scenario (e.g., normal driving, emergency braking, cornering, etc.); 4-5. Request status for upper-level braking function.

[0032] Based on this multidimensional information, the module performs redundant functions to switch arbitration modes.

[0033] like Figure 2 As shown, in this system, the main system power supply (SBC) powers the wheel speed sensor, and there is bidirectional interaction between the wheel speed sensor and the main system power supply (SBC). The auxiliary system power supply is powered by a low-dropout linear regulator (LDO), which provides another power source for the wheel speed sensor. The wheel speed sensor signal is transmitted to the main system MCU through multiple lines (including redundant lines), and also to the slave system MCU (redundant) through multiple redundant communication paths. The slave system MCU and the main system MCU also communicate bidirectionally through redundant communication channels to ensure the reliability of signal transmission and system redundancy.

[0034] S102. If self-check or state synchronization fails, enter limp home mode.

[0035] Limp home mode is a fault protection strategy in automotive electronic control systems. When a vehicle's powertrain system (such as the engine or transmission) detects a specific serious fault, the system automatically activates a preset set of degraded control logic.

[0036] This mode is typically triggered in the following situations: failure of critical sensor signals (such as throttle position sensor or air flow meter malfunction); failure of critical actuators (such as abnormal electronic throttle control); or severe interruption of controller area network (CAN bus) communication.

[0037] S103. If the self-test and status synchronization are successful, the main controller and the slave controller are controlled to enter the normal working mode and parallel processing, and the arbitration module executes the periodic monitoring process.

[0038] In normal operating mode, the system's master controller and slave controllers operate according to preset, independent, and complementary processes, each performing its own function. Parallel processing here specifically refers to the working method in which the master and slave controllers execute their respective processes simultaneously and independently in both physical and temporal aspects.

[0039] The periodic monitoring process includes: S104. Determine if the monitoring period has arrived.

[0040] S105. If the monitoring cycle is reached, check whether the heartbeat signal of the main controller is normal.

[0041] S106. If the heartbeat signal is normal, check the quality of the wheel speed signal.

[0042] The process of checking the quality of the wheel speed signal includes: determining the number of valid wheel speed signals; and defining the wheel speed signal quality as abnormal when the number of valid signals is less than a preset threshold.

[0043] Optionally, the effective number of paths threshold is 2.

[0044] It should be noted that the main system MCU continuously analyzes and diagnoses faults in its four wheel speed signals, including signal validity, signal amplitude, frequency rationality, and short / open circuit detection to ground. The slave system MCU performs simplified and reliable wheel speed signal analysis and fault diagnosis in parallel on the two wheel speed signals it is responsible for. The two systems periodically exchange vital signs and fault diagnosis summaries via a redundant communication module.

[0045] S107. If the quality is abnormal, then execute the scenario-based arbitration process.

[0046] In this embodiment, the system status monitoring and arbitration module will perform a switch of control when any of the following conditions are met: Forced switchover: A preset fault occurs in the main system MCU.

[0047] Recommended switch: The main system MCU has detected that the number of invalid wheel speed signal channels exceeds the preset threshold (e.g., 2 channels).

[0048] The scenario-based arbitration process includes: S108. Match the preset scenario-based switching decision rules according to the current vehicle operating status, and generate an arbitration instruction based on the matched rules.

[0049] The step of matching a preset scenario-based switching decision rule based on the current vehicle operating status includes: determining whether the vehicle is in a first scenario, where the vehicle speed is higher than a first speed threshold and the vehicle is in an emergency braking state; if yes, then matching a first decision rule, where the first decision rule is: when the number of invalid wheel speed signals reaches a first value, a suggested switching request is generated; if no, then determining whether the vehicle is in a second scenario, where the second scenario is a normal driving state where the vehicle speed is lower than the first speed threshold but higher than a second speed threshold; if yes, then matching a second decision rule, where the second decision rule is: when the number of invalid wheel speed signals reaches a second value, a suggested switching request is generated; if no, then determining whether the vehicle is in a third scenario, where the third scenario is a parking state where the vehicle speed is lower than the second speed threshold; if yes, then matching a third decision rule, where the third decision rule is: not performing a control switch and triggering an alarm; wherein, the second value is greater than the first value.

[0050] It is understandable that, such as Figure 3 As shown, the situation that triggers the alarm belongs to scenario one, while the situation that suggests switching requests belongs to scenario two.

[0051] The first speed threshold is 75~85km / h, and the first value is 1; the second speed threshold is 15~25km / h, and the second value is 2.

[0052] Optionally, the first speed threshold is 80 km / h, and the second speed threshold is 20 km / h.

[0053] It is worth noting that fault diagnosis must be closely combined with the vehicle's current motion state. For example, in a high-speed (>80km / h) emergency braking scenario, even if the main system MCU loses only one non-critical wheel speed signal, the system may issue an early warning and prepare to initiate function switching because the ABS / ESP function has extremely high requirements for data integrity. However, in a low-speed (<20km / h) coasting condition, the system can allow for a longer response time in fault diagnosis.

[0054] It should be noted that the system status monitoring module continuously evaluates whether redundancy switching conditions are triggered. The triggering conditions are not singular, but involve multiple judgments, such as the aforementioned fault, quality judgment, and scenario-based switching.

[0055] S109. According to the arbitration instruction, maintain the current control mode, trigger an alarm, or perform a redundancy switch from the master controller to the slave controller.

[0056] The step of performing a redundancy switch from the master controller to the slave controller according to the arbitration instruction includes: if there is a forced switch request, or if there is a suggested switch request and the status signal of the slave controller is valid, then the redundancy switch procedure is executed to switch control from the master controller to the slave controller and enter the fault-operable mode to perform degraded braking protection.

[0057] When the system detects abnormal operating conditions or vehicle status, it issues a forced switchover request.

[0058] For example, if the MCU heartbeat packet is lost or the watchdog timeout occurs, the system issues a forced switch request.

[0059] Once the redundancy management module determines that the switching conditions are met, the redundancy switching procedure described above should be executed immediately. Freeze the wheel speed output of the master system MCU; activate the slave system MCU as the master wheel speed signal source; the slave system MCU sends the two reliable wheel speed signals it resolves directly to the upper-level chassis domain controller or vehicle controller via network communication. For the missing wheel speed information for the other two wheels, the upper-level chassis domain controller or vehicle controller can obtain it through axle rotation speed, or estimate the wheel speed information using the model's software measurement algorithm.

[0060] After the wheel speed redundancy function switch is completed, the entire braking system enters a fault-operable mode. Based on the limited and reliable wheel speed information provided by the system MCU, and combined with software measurement algorithms or axle speed values, the braking system performs a function degradation operation to ensure that the vehicle has a safe and reliable backup braking function.

[0061] It is understood that the redundancy switching function of this invention is designed to automatically switch control to the slave controller when the main controller fails. The slave controller will take over and execute core safety functions such as basic braking and vehicle stability control, thereby ensuring that the vehicle can still maintain basic driving capability and safely reach a repair point, avoiding complete vehicle failure. This design stems from the fact that the slave controller is positioned as a safety backup; its function set is streamlined, focusing on ensuring minimum driving safety, rather than providing full-featured operational support like the main controller.

[0062] After completing the wheel speed redundancy function switch, the braking system enters a fail-operable mode. At this time, the system performs a series of degraded operation operations to ensure basic safety. These operations mainly include: First, completely disabling advanced functions that require extremely high wheel speed signal accuracy, such as Electronic Stability Control (ESC), Traction Control System (TCS), Automatic Emergency Braking (AEB), and Adaptive Cruise Control (ACC), to avoid the risk of false triggering; Second, simplifying the control logic of the retained basic Anti-lock Braking System (ABS), for example, downgrading from four-wheel independent control to co-axle joint control, using a fixed pressure modulation period and a more lenient slip ratio threshold, prioritizing vehicle stability rather than the shortest braking distance; Third, actively limiting system performance, such as reducing the pressure modulation rate and upper limit of the hydraulic unit's operating pressure, to improve control smoothness and robustness; Fourth, clearly warning the driver of abnormal system status through dashboard warning lights and text messages, prompting them to adopt a conservative driving strategy. Through these hierarchical degraded operations, the system can still provide reliable basic braking capability under conditions of limited wheel speed information, achieving the safety redundancy goal.

[0063] In some embodiments, the method further includes: if there is no forced switching request, or no suggested switching request, or the status signal of the slave controller is invalid, then return, wait for the next monitoring cycle, and / or maintain the current processing mode.

[0064] In some embodiments, the method further includes: if the quality is normal, returning, waiting for the next monitoring cycle, and / or maintaining the current processing mode.

[0065] The current processing mode refers to the working mode in which the master system MCU is fully responsible for outputting the wheel speed signal in a master-slave dual MCU architecture.

[0066] The embodiments of this application have the following beneficial effects: 1. Wheel speed depth signal redundancy: The redundancy design is extended to the fundamental link of wheel speed signal acquisition and analysis, which improves the reliability and availability of the braking system from the source.

[0067] 2. Intelligent scenario-based switching: The switching decision is not limited to MCU hardware failure, but deeply integrates wheel speed signal quality, vehicle dynamic scenarios and upper-level application requirements, avoiding unnecessary switching or switching delays, and making decision control more precise.

[0068] 3. Ensure basic braking function: By using the reliable wheel speed signal of a single axle provided by the system MCU, combined with vehicle model software measurement technology or axle speed information, a usable vehicle dynamic information view can still be constructed after the main system fails completely. This supports the braking system in performing critical anti-lock braking and basic braking functions, realizing the evolution from "fail-safe" to "fail-operable".

[0069] 4. Clear and efficient system architecture: The master and slave MCUs have clearly defined responsibilities, work in parallel, and have a fast and reliable fault detection and redundancy management switching mechanism. The modification to the existing braking system architecture is relatively small and easy to implement.

[0070] Example 2: Embodiments of this application also provide a computer device, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of the present invention during runtime.

[0071] The aforementioned memory can refer to devices inside a computer used to store data and programs, including RAM, hard disks, etc. RAM can be used to temporarily store running programs and data, while hard disks can be used to store programs and data long-term. Memory enables the computer to read and write data and execute programs. The aforementioned processor is responsible for executing instructions in computer programs and performing data processing. It can also be responsible for controlling and executing various operations, including arithmetic operations, logical operations, and data transmission.

[0072] Example 3: Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of the present invention.

[0073] The aforementioned computer storage media can refer to the media used in computer memory to store certain discontinuous physical quantities. Computer storage media mainly include semiconductors, magnetic cores, magnetic drums, magnetic tapes, laser discs, etc. Computer-readable storage media include stored programs, which can be a set of instructions that a computer can recognize and execute, running on an electronic computer to meet certain information needs.

[0074] Example 4: Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of the present invention.

[0075] The aforementioned computer program products can refer to software programs that have been written, tested, and released, and can run on computers or other devices. Computer program products can include application programs, operating systems, utility software, etc., used to achieve specific functions or solve specific problems.

[0076] Example 5: Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium for storing a computer program that, when executed by a processor, implements the methods in various embodiments of the present invention.

[0077] The aforementioned non-volatile computer-readable storage medium can refer to a medium for storing data. Non-volatile computer-readable storage media can retain data without loss when power is off and can be used to store long-term data, such as operating systems, applications, and user files. Non-volatile storage media can include hard disk drives, solid-state drives, optical disks, and flash memory storage devices, etc.

[0078] Example 6: Embodiments of this application also provide a computer program that, when executed by a processor, implements the methods described in the various embodiments of the present invention.

[0079] The aforementioned computer program can refer to a set of instructions used to tell the computer to perform specific tasks or operations. Computer programs can be written by programmers using specific programming languages ​​and can include algorithms, data structures, logic, and control flow. Computer programs can be used for a variety of purposes, including application software, operating systems, etc.

[0080] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0081] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

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

[0083] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0085] In summary, the embodiments of this application introduce hardware circuitry and functional redundancy at the forefront of signal acquisition and analysis, and make intelligent decisions in conjunction with the upper-layer application status. This ensures that when a specific fault occurs in the main system MCU, it can quickly and reliably switch to the slave system MCU and continue to provide reliable wheel speed information, thereby protecting the vehicle's basic braking function and improving the overall safety level of the system.

[0086] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A scenario-based arbitration and redundancy switching method, characterized in that, The method includes: After the system is powered on, it initializes and performs self-tests and status synchronization on the master controller and slave controller. The main controller continuously analyzes and diagnoses faults in its four wheel speed signals, while the slave controller analyzes and diagnoses faults in parallel in the two wheel speed signals it is responsible for. For the other two wheel speed information missing by the slave controller, the upper chassis domain controller or vehicle controller obtains it through the shaft rotation speed, or uses the model's software measurement algorithm to estimate the wheel speed information. If self-check or status synchronization fails, it will enter limp home mode; If the self-test and status synchronization are successful, the main controller and the slave controller are controlled to enter the normal working mode and parallel processing, and the arbitration module executes the periodic monitoring process. The periodic monitoring process includes: Determine if the monitoring period has been reached; If the monitoring cycle is reached, check whether the heartbeat signal of the main controller is normal; If the heartbeat signal is normal, check the quality of the wheel speed signal; If the quality is abnormal, a scenario-based arbitration process will be executed. The scenario-based arbitration process includes: Based on the current vehicle operating status, a preset scenario-based switching decision rule is matched, and an arbitration instruction is generated based on the matched rule; According to the arbitration instruction, the current control mode may be maintained, an alarm may be triggered, or a redundancy switch from the master controller to the slave controller may be performed; The quality check of the wheel speed signal includes: Determine the number of valid wheel speed signals; When the number of paths is less than a preset effective number of paths threshold, the quality of the wheel speed signal is defined as abnormal. The step of matching preset scenario-based switching decision rules based on the current vehicle operating status includes: Determine whether the vehicle is in the first scenario, where the vehicle speed is higher than a first speed threshold and the vehicle is in an emergency braking state. If so, then the first decision rule is matched, and the first decision rule is: when the number of invalid wheel speed signals reaches a first value, a suggested switching request is generated from the master controller to the slave controller; If not, then determine whether the vehicle is in the second scenario, which is a normal driving state where the vehicle speed is lower than the first speed threshold and higher than the second speed threshold; If so, then the second decision rule is matched, which is: when the number of invalid wheel speed signals reaches a second value, a suggested switching request is generated from the master controller to the slave controller; If not, then determine whether the vehicle is in a third scenario, which is a parking state where the vehicle speed is lower than the second speed threshold; If so, then the third decision rule is matched, which is: do not perform a switch of control and trigger an alarm; The second value is greater than the first value.

2. The scenario-based arbitration and redundancy switching method according to claim 1, characterized in that, The first speed threshold is 75~85km / h, and the first value is 1; the second speed threshold is 15~25km / h, and the second value is 2.

3. The scenario-based arbitration and redundancy switching method according to claim 1, characterized in that, The step of performing a redundancy switch from the master controller to the slave controller according to the arbitration instruction includes: If a forced switchover request exists, or if the suggested switchover request exists and the status signal of the slave controller is valid, a redundancy switchover process is executed to switch control from the master controller to the slave controller and enter a fault-operable mode to perform degraded braking protection.

4. The scenario-based arbitration and redundancy switching method according to claim 3, characterized in that, After entering the fault-operable mode, the method further includes: Continuously monitor whether the system restart conditions or the main controller fault recovery conditions are met; If the requirements are not met, the function will continue to run in the degradation mode. If the conditions are met, the fault-operable mode is terminated and initialization is performed.

5. The scenario-based arbitration and redundancy switching method according to claim 3, characterized in that, The method further includes: if there is no forced switching request, or no suggested switching request, or the status signal of the slave controller is invalid, then return, wait for the next monitoring cycle, and / or maintain the current processing mode.

6. The scenario-based arbitration and redundancy switching method according to claim 1, characterized in that, The method further includes: if the quality is normal, returning, waiting for the next monitoring cycle, and / or maintaining the current processing mode.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the scenario-based arbitration and redundancy switching method as described in any one of claims 1 to 6.

8. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the scenario-based arbitration and redundancy switching method as described in any one of claims 1 to 6.

Images