Software heterogeneous redundant control method and system for electromechanical brake system

CN122976512APending Publication Date: 2026-10-27WUHU BETHEL AUTOMOTIVE SAFETY SYST CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611305502.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-08-26
Publication Date
2026-10-27

AI Technical Summary

Technical Problem

[0006]本申请提供一种用于电子机械制动系统的软件异构冗余控制方法及系统,用于解决现有电子机械制动系统因软件异常或单核运算故障导致制动指令不可靠输出、缺乏有效仲裁机制且切换过程存在制动力缺失的技术问题

Benefits of technology

[0018]本申请同一多核微控制器(MCU)内的不同处理器核运行不同软件架构、使用经内存保护单元隔离的不同内存区域、且采用不同控制算法;同时主控制单元与辅控制单元之间通过多路私有CAN通信网络实现通信冗余。该“软件架构—内存空间—控制算法—通信链路”四维异构冗余架构,使得任何单一故障模式(包括软件缺陷、内存位翻转、算法逻辑错误及通信中断)难以在多个异构核中同时复现,从根本上消除了共因失效路径,完全符合ISO26262对最高功能安全等级(ASIL-D)的系统要求。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122976512A_ABST
    Figure CN122976512A_ABST
Patent Text Reader

Abstract

The application provides a software heterogeneous redundancy control method and system for an electromechanical braking system, comprising: acquiring a braking request signal; acquiring a first control signal, a second control signal, a third control signal and a fourth control signal generated based on the braking request signal; performing consistency verification on the four control signals; in response to meeting a consistency condition, outputting the control signal confirmed consistent by the consistency verification as an effective control signal to a wheel-end execution mechanism through a multi-path private CAN communication network; and in response to not meeting the consistency condition, prohibiting the output of the effective control signal. The application independently generates braking control signals through four heterogeneous processor cores and performs consistency verification, thereby achieving high-reliability braking instruction output in a normal state and precise identification of a fault source when the signals are different, effectively solving the technical problem of unreliable output of braking instructions caused by common cause failure, algorithm defects or single-point hardware failure in existing braking control redundancy schemes.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application belongs to the field of vehicle braking control technology, and relates to a software heterogeneous redundancy control method and system for electromechanical braking systems. Background Technology

[0002] An electro-mechanical braking system (EMB) is an electrically controlled braking system that replaces the original brake chamber / oil chamber, pipelines, valve body, and other related components with a drive motor and electrical wiring, based on a traditional pneumatic / hydraulic braking system, and uses electrical signals as the transmission medium.

[0003] The EMB (Electronic Braking System) eliminates the mechanical connection and hydraulic transmission link between the brake pedal and the actuator, relying entirely on electrical signal transmission and the computation of the electronic control unit (ECU) for braking commands. This architectural feature makes the reliability of the electronic control system a key bottleneck restricting the large-scale application of EMB systems. When the controller fails to output braking control commands normally due to software anomalies (such as program crashes, infinite loops, stack overflows, algorithm defects) or hardware failures (such as single-core processing unit failure, memory bit flips), the vehicle faces a significant safety risk of loss of braking force. To address these risks, existing technologies primarily propose solutions at the hardware redundancy level.

[0004] A common redundancy solution is to use a dual-ECU master / slave architecture. When the master ECU is working normally, it outputs braking commands; when the master ECU fails, the system switches to the backup ECU. However, this solution has the following drawbacks: First, the master / slave switchover typically takes milliseconds or even hundreds of milliseconds, during which there is a significant window of lost braking force, seriously endangering driving safety in emergency braking scenarios. Second, when the outputs of the master ECU and the backup ECU are inconsistent, the system lacks an effective arbitration mechanism to determine which output is correct, making it impossible to accurately locate the fault source.

[0005] In summary, the existing redundant control scheme of electromechanical braking system has the following technical defects: (1) There is a braking force loss window when switching between the main and backup ECUs, and the loss time can reach 150ms, which affects the continuity of braking; (2) There is no effective third-party arbitration mechanism when the outputs of the main and backup ECUs are inconsistent. Summary of the Invention

[0006] This application provides a software heterogeneous redundancy control method and system for electromechanical braking systems, which solves the technical problems of unreliable output of braking commands, lack of effective arbitration mechanism, and loss of braking force during the switching process caused by software abnormalities or single-core computing failures in existing electromechanical braking systems.

[0007] In a first aspect, this application provides a software heterogeneous redundancy control method for an electromechanical braking system. The method includes: acquiring a braking request signal; acquiring a first control signal, a second control signal, a third control signal, and a fourth control signal generated based on the braking request signal, wherein the first control signal is generated by a first processor core running first control software, the second control signal is generated by a second processor core running second control software, the third control signal is generated by a third processor core running third control software, and the fourth control signal is generated by a fourth processor core running fourth control software; the first processor core and the second processor core are configured in a main control unit, and the third processor core and the fourth processor core are configured in an auxiliary control unit; performing consistency verification on the first control signal, the second control signal, the third control signal, and the fourth control signal; in response to satisfying the consistency condition, outputting the control signal confirmed to be consistent through the consistency verification as a valid control signal to the wheel-end actuator through a multi-channel private CAN communication network; and in response to not satisfying the consistency condition, prohibiting the output of the valid control signal.

[0008] In one implementation of the first aspect, the first control software and the second control software run in independent memory regions with different architectures, so that the first control software and the second control software are heterogeneous in terms of operation logic and runtime resources; the third control software and the fourth control software run in independent memory regions with different architectures, so that the third control software and the fourth control software are heterogeneous in terms of operation logic and runtime resources.

[0009] In one implementation of the first aspect, the method further includes: under normal operating conditions, the main control unit performs the consistency verification and outputs the valid control signal as the current master control device; in response to a communication failure occurring in both the first processor core and the second processor core within the main control unit, the main control unit sends a control switch request to the auxiliary control unit to switch control to the auxiliary control unit; after the switch, the auxiliary control unit takes over the consistency verification based on the third control signal and the fourth control signal, and outputs the valid control signal when the consistency conditions are met.

[0010] In one implementation of the first aspect, consistency verification of the first control signal, the second control signal, the third control signal, and the fourth control signal includes: under normal operating conditions, firstly determining whether the first control signal and the second control signal meet consistency conditions; if they do, directly outputting the first control signal or the second control signal as the valid control signal; if they do not meet, then determining whether the first control signal meets consistency conditions with the third control signal and the fourth control signal, and whether the second control signal meets consistency conditions with the third control signal and the fourth control signal, and based on the determination results, outputting the valid control signal or prohibiting the output of the valid control signal; if the first control signal meets consistency conditions with the third control signal and the fourth control signal... If the first control signal is not satisfied, the second control signal is output as the valid control signal; or if the second control signal satisfies the consistency condition with the third and fourth control signals, the second control signal is output as the valid control signal; or if the first control signal does not satisfy the consistency condition with the third and fourth control signals, or the second control signal does not satisfy the consistency condition with the third and fourth control signals, the output of the valid control signal is prohibited. When both the first processor core and the second processor core in the main control unit fail, the auxiliary control unit has control authority and determines whether the consistency condition is satisfied based on the third and fourth control signals. If the consistency condition is satisfied, the third control signal or the fourth control signal is output as the valid control signal; otherwise, the output of the control signal is prohibited.

[0011] In one implementation of the first aspect, the method further includes: performing heartbeat detection on the first processor core and the second processor core, and on the third processor core and the fourth processor core, respectively, including: the first processor core and the second processor core exchanging heartbeat messages; when the first processor core does not receive the heartbeat message sent by the second processor core within a preset time, determining that the second processor core has a communication failure, or when the second processor core does not receive the heartbeat message sent by the first processor core within a preset time, determining that the first processor core has a communication failure; in response to the first processor core or the second processor core having a communication failure, performing consistency verification on the second control signal or the first control signal, the third control signal, and the fourth control signal; and the third processor core and the fourth processor core exchanging the heartbeat messages in the same manner as the first processor core and the second processor core and monitoring for communication failures.

[0012] In one implementation of the first aspect, the multi-channel private CAN communication network includes a first private CAN communication network, a second private CAN communication network, a third private CAN communication network, and a fourth private CAN communication network; wherein, the main control unit and the auxiliary control unit are redundantly connected via the fourth private CAN communication network; the main control unit sends valid control signals to the wheel-end actuator via the first private CAN communication network or the second private CAN communication network; the auxiliary control unit sends valid control signals to the wheel-end actuator via the first private CAN communication network or the third private CAN communication network.

[0013] Secondly, this application provides a software heterogeneous redundancy control system for an electromechanical braking system. The system includes: a signal receiving module configured to acquire a braking request signal; a main control unit including a first multi-core microcontroller unit, configured with a first processor core and a second processor core, wherein the first processor core is configured to run first control software to generate a first control signal based on the braking request signal, and the second processor core is configured to run second control software to generate a second control signal based on the braking request signal; and an auxiliary control unit including a second multi-core microcontroller unit, configured with a third processor core and a fourth processor core, wherein the third processor core is configured to run third control software to generate a third control signal based on the braking request signal, and the fourth processor core is configured to run fourth control software to generate a third control signal based on the braking request signal. A fourth control signal; a consistency verification module, configured to perform consistency verification on the first control signal, the second control signal, the third control signal, and the fourth control signal; a control signal output module, configured to output the control signal confirmed by consistency verification as a valid control signal to the wheel-end actuator when the first control signal, the second control signal, the third control signal, and the fourth control signal meet the consistency conditions, and to prohibit the output of valid control signals when the consistency conditions are not met; a multi-channel private CAN communication network, connecting the main control unit, the auxiliary control unit, and the wheel-end actuator, configured to realize data communication between the main control unit and the auxiliary control unit, and configured to realize the output of valid control signals from the main control unit and / or the auxiliary control unit to the wheel-end actuator.

[0014] In one implementation of the second aspect, the system further includes: a memory protection unit, configured inside the main control unit and the auxiliary control unit, configured to isolate and protect memory regions corresponding to different processor cores within the main control unit and the auxiliary control unit, prohibiting cross-region memory access; a heartbeat detection module, configured to perform heartbeat detection between the first processor core and the second processor core, and between the third processor core and the fourth processor core to monitor communication failures; and a control switching module, configured to monitor the working status of the main control unit, and trigger control switching when the main control unit fails, switching control to the auxiliary control unit.

[0015] Thirdly, this application provides an electronic device, the electronic device comprising: a memory storing a computer program; and a processor communicatively connected to the memory, which, when the computer program is invoked, executes the software heterogeneous redundancy control method for an electromechanical braking system as described above.

[0016] Fourthly, this application provides a vehicle that includes a software heterogeneous redundancy control system for an electromechanical braking system as described above.

[0017] As described above, the software heterogeneous redundancy control method and system for electromechanical braking systems described in this application have the following beneficial effects:

[0018] This application describes a multi-core microcontroller (MCU) with different processor cores running different software architectures, using different memory regions isolated by memory protection units, and employing different control algorithms. Simultaneously, the main control unit and auxiliary control unit achieve communication redundancy through a multi-channel private CAN communication network. This four-dimensional heterogeneous redundancy architecture—"software architecture—memory space—control algorithm—communication link"—makes it difficult for any single failure mode (including software defects, memory bit flips, algorithm logic errors, and communication interruptions) to be simultaneously reproduced in multiple heterogeneous cores, fundamentally eliminating common-cause failure paths and fully complying with ISO 26262's requirements for the highest functional safety level (ASIL-D).

[0019] This application adopts a fault handling strategy of "main control unit priority and dual-core takeover in the same system". When a single core malfunctions, there is no need to switch between the main and auxiliary control units at the system level. Another heterogeneous core in the same MCU directly takes over the control signal output. The switching time is only on the order of microseconds, which completely eliminates the interruption of braking force output and ensures the continuity of braking force and vehicle stability in emergency braking scenarios.

[0020] By utilizing four independent computing channels—two heterogeneous cores (the first and second processor cores) in the main control unit and two heterogeneous cores (the third and fourth processor cores) in the auxiliary control unit—a "four-way signal + majority voting" arbitration mechanism is constructed. When disagreements arise among the four signals, the system can identify the abnormal core with the largest deviation through majority consensus, achieving precise location and isolation of the fault source and providing a reliable basis for subsequent fault recovery and system degradation.

[0021] This application employs a multi-redundancy design involving heterogeneous software architecture, heterogeneous control algorithms, and isolated memory space. This effectively defends against various soft errors, including algorithm design flaws, fixed-point / floating-point arithmetic deviations, execution timing anomalies caused by compiler optimizations, stack overflows, and data corruption. Furthermore, the inherent differences in the sensitivity of multi-core heterogeneous software to electromagnetic interference ensure that at least one software system can output correct braking control instructions even in complex electromagnetic environments, significantly improving the system's anti-interference capability and overall robustness. Attached Figure Description

[0022] Figure 1 The diagram shown is a schematic diagram of the software heterogeneous redundancy control system for an electromechanical braking system as described in an embodiment of this application.

[0023] Figure 2 The diagram shows the redundant communication topology of the multi-channel private CAN communication network described in the embodiments of this application.

[0024] Figure 3 The diagram shown is a flowchart illustrating the software heterogeneous redundancy control method for an electromechanical braking system as described in an embodiment of this application.

[0025] Figures 4a-4d The diagram shown is a schematic representation of the consistency verification process described in an embodiment of this application.

[0026] Figure 5 The diagram shows the state of heartbeat detection as described in the embodiments of this application.

[0027] Figure 6 The diagram shown is a structural schematic of the electronic device described in an embodiment of this application.

[0028] Figure 7 The diagram shown is a structural schematic of the vehicle described in an embodiment of this application.

[0029] Component designation explanation

[0030] 100 Software heterogeneous redundancy control system 170 Heartbeat detection module 110 Main control unit 180 Multi-channel private CAN communication network 111 First multi-core microcontroller 181 First private CAN communication network 1111 First processor core 182 Second private CAN communication network 1112 Second processor core 183 Third private CAN communication network 120 Auxiliary control unit 184 Fourth private CAN communication network 121 Second multi-core microcontroller 190 Control switching module 1211 Third processor core 600 electronic devices 1212 Fourth processor core 601 memory 130 Memory protection unit 602 processor 140 Signal receiving module 603 monitor 150 Consistency verification module 700 vehicle 160 Control signal output module S301~S304 step Detailed Implementation

[0031] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

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

[0033] The following embodiments of this application provide a software heterogeneous redundancy control method and system for an electromechanical braking system, which solves the technical problems in the prior art of unreliable output of braking commands due to software abnormalities or single-core computing failures, lack of effective arbitration mechanisms, and loss of braking force during the switching process in electromechanical braking systems.

[0034] The technical solutions in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0035] Figure 1 The diagram shown is a schematic of a software heterogeneous redundancy control system for an electromechanical braking system according to an embodiment of this application. It adopts a dual-control unit quad-core heterogeneous architecture combined with a multi-channel private CAN communication network to execute the software heterogeneous redundancy control method for an electromechanical braking system provided in the following embodiments of this application.

[0036] The software heterogeneous redundancy control system 100 includes: a main control unit 110, an auxiliary control unit 120, a memory protection unit 130, a signal receiving module 140, a consistency verification module 150, a control signal output module 160, a heartbeat detection module 170, a multi-channel private CAN communication network 180, and a control switching module 190.

[0037] The main control unit 110 includes a first multi-core microcontroller 111, on which a first processor core 1111 and a second processor core 1112 are integrated. The auxiliary control unit 120 includes a second multi-core microcontroller 112, on which a third processor core 1211 and a fourth processor core 1212 are integrated.

[0038] The first and second control software run in independent execution domains with different architectures, and are heterogeneous in terms of computational logic and runtime resources. Similarly, the third and fourth control software run in independent execution domains with different architectures.

[0039] Memory protection units 130 are configured inside the main control unit 110 and the auxiliary control unit 120, respectively, and are implemented using hardware memory protection units 130. Memory protection units 130 isolate and protect the memory region corresponding to the first processor core 1111 and the memory region corresponding to the second processor core 1112 within the main control unit 110, and simultaneously isolate and protect the memory region corresponding to the third processor core 1211 and the memory region corresponding to the fourth processor core 1212 within the auxiliary control unit 120. Each processor core can only access the memory region within its own execution domain, prohibiting cross-region memory access.

[0040] The signal receiving module 140 acquires the braking request signal through a redundant hard-wired input interface and an onboard Ethernet interface. The braking request signal includes the target braking deceleration value, quantized as a 16-bit unsigned integer data, with a value range of 0 to 000, corresponding to a braking deceleration requirement of 0 m / s² to m / s².

[0041] Under normal operating conditions, the signal receiving module 140 acquires the braking request signal at a period of 10ms. The first processor core 1111, the second processor core 1112, the third processor core 1211, and the fourth processor core 1212 synchronously receive the braking request signal and independently execute the braking control algorithm. For example, the first control software uses a feedforward plus PID feedback force control algorithm, the second control software uses a sliding mode variable structure control algorithm, the third control software uses a model predictive control algorithm, and the fourth control software uses an adaptive fuzzy control algorithm.

[0042] Each processor core completes its calculations within 5ms of receiving the braking request signal, generating the first, second, third, and fourth control signals respectively. Each control signal is in 32-bit CAN message format, containing the target clamping force value, motor speed limit, and fault flag.

[0043] The conformance verification module 150 is deployed in the main control unit 110 and the auxiliary control unit 120 respectively, and acquires the first control signal, the second control signal, the third control signal and the fourth control signal through the multi-channel private CAN communication network 180. Under normal working conditions, the conformance verification module 150 deployed in the main control unit 110 performs the conformance verification process. When the first processor core 1111 or the second processor core 1112 in the main control unit 110 fails, the conformance verification process is still performed by the conformance verification module 150 deployed in the main control unit 110. When both the first processor core 1111 and the second processor core 1112 in the main control unit 110 experience communication failures, the control switching module 190 triggers the control switching process.

[0044] The main control unit 110 sends a control switch request message to the auxiliary control unit 120 through the fourth private CAN communication network 184. After receiving the switch request message, the auxiliary control unit 120 completes the takeover of control within milliseconds and becomes the current master device. The consistency verification module 150 deployed in the auxiliary control unit 120 then performs the consistency verification process.

[0045] The heartbeat detection module 170 is deployed in the first processor core 1111, the second processor core 1112, the third processor core 1211, and the fourth processor core 1212 respectively. It monitors the heartbeat messages exchanged between the first processor core 1111 and the second processor core 1112 through the high-speed SPI interface inside the main control unit 110, and monitors the heartbeat messages exchanged between the third processor core 1211 and the fourth processor core 1212 through the high-speed SPI interface inside the auxiliary control unit 120. Based on the preset conditions of heartbeat detection, it monitors the communication failures between the first processor core 1111 and the second processor core 1112, and between the third processor core 1211 and the fourth processor core 1212.

[0046] This embodiment achieves comprehensive heterogeneous redundancy from processor cores, software architecture, memory space to communication links through a dual electronic control unit (ECU) architecture of "main control unit 110 + auxiliary control unit 120", combined with the heterogeneous software configuration of multi-core microcontrollers inside each ECU, and the redundant design of multi-channel private CAN communication network 180, effectively avoiding common cause failures.

[0047] like Figure 2The diagram shown illustrates the redundant communication topology of the multi-channel private CAN communication network 180 described in this embodiment. The multi-channel private CAN communication network 180 includes a first private CAN communication network 181, a second private CAN communication network 182, a third private CAN communication network 183, and a fourth private CAN communication network 184. The fourth private CAN communication network 184 connects the main control unit 110 and the auxiliary control unit 120. The baud rate during the arbitration phase is 500 Kbit / s, while the baud rate during the data phase is 2 Mbit / s. It uses twisted-pair shielded cable with a maximum length of 7 meters.

[0048] The baud rates of the first private CAN communication network 181, the second private CAN communication network 182, and the third private CAN communication network 183 are all set to 500kbps, and each is connected to the corresponding communication interface of the wheel-end actuator through an independent CAN transceiver. The main control unit 110 sends valid control signals to the wheel-end actuator through the first private CAN communication network 181 or the second private CAN communication network 182. The auxiliary control unit 120 sends valid control signals to the wheel-end actuator through the first private CAN communication network 181 or the third private CAN communication network 183.

[0049] During normal operation, the main control unit 110 and the auxiliary control unit 120 transmit control signals and status data through the first private CAN communication network 181. Different control signals are distinguished by different message identifiers (CAN IDs) during transmission and are accompanied by cyclic redundancy check codes.

[0050] When a communication failure occurs in the first private CAN communication network 181 (such as a line break, CAN transceiver damage, or bus contention), the main control unit 110 and the auxiliary control unit 120 share control signals through the fourth private CAN communication network 184, and output control signals to the wheel-end actuators through the second private CAN communication network 182 and the third private CAN communication network 183, respectively. The CAN communication network switching process is completely transparent to the upper-level control algorithm, without any data loss or delay. When the faulty network is restored, the system automatically re-enables the redundant transmission mode.

[0051] In addition, the main control unit 110 also forwards its own operating status information (such as the real-time operating status and fault diagnosis information of the first processor core 1111 and the second processor core 1112112) to the auxiliary control unit 120 through the first private CAN communication network 181. The auxiliary control unit 120 also forwards its own status information to the main control unit 110. This two-way status sharing mechanism enables either control unit to grasp the health status of the other in real time, providing a basis for control switching decisions.

[0052] This embodiment effectively avoids control system failure caused by single-point communication failure through the redundant design of dual-channel private CAN communication network, further improving the overall reliability of the system.

[0053] Figure 3 The diagram shown is a flowchart illustrating a software heterogeneous redundancy control method for an electromechanical braking system provided in an embodiment of this application. Figure 3 As shown, the procedure includes steps S301 to S304.

[0054] Step S301: Obtain the braking request signal.

[0055] Step S302: Obtain the first control signal, the second control signal, the third control signal, and the fourth control signal generated based on the braking request signal.

[0056] Step S303: Perform consistency verification on the first control signal, the second control signal, the third control signal, and the fourth control signal.

[0057] In step S304, in response to meeting the consistency condition, the control signal confirmed by the consistency verification is output as a valid control signal to the wheel-end actuator through the multi-channel private CAN communication network; or in response to not meeting the consistency condition, the output of the valid control signal is prohibited.

[0058] In this embodiment, the signal receiving module 140 obtains the braking request signal through the redundant hard-wired input interface and the vehicle Ethernet interface.

[0059] The braking request signal may include at least one of the following: brake pedal travel signal, brake pedal force signal, driver braking intention signal, and braking demand signal from the autonomous driving system. The braking request signal is transmitted to the signal receiving module 140 via a sensor or an onboard network (such as a CAN bus).

[0060] In step S302, the first processor core 1111 within the main control unit 110 runs the first control software, generating a first control signal based on the braking request signal and according to the first control strategy. Simultaneously, the second processor core 1112 within the main control unit 110 runs the second control software, generating a second control signal based on the same braking request signal and according to the second control strategy. The first and second control software employ different software architectures (e.g., different operating systems, different software layering architectures, different code generation toolchains, or different programming languages), use different memory regions isolated by the memory protection unit 130, and employ different control algorithms (e.g., the first control software uses a force control algorithm with base feedforward and PID feedback, while the second control software uses a model predictive control algorithm).

[0061] The third processor core 1211 within the auxiliary control unit 120 runs third control software, generating a third control signal based on the braking request signal. The fourth processor core 1212 runs fourth control software, generating a fourth control signal based on the braking request signal. Both the third and fourth control software employ heterogeneous software architectures and control algorithms.

[0062] The main control unit 110 receives the third and fourth control signals sent by the auxiliary control unit 120 through the fourth private CAN communication network 184. Each control signal is distinguished by a different message identifier during transmission and is accompanied by a cyclic redundancy check (CRC) code to ensure the integrity and correctness of data transmission.

[0063] At this point, the main control unit 110 has acquired four independently calculated braking control signals: a first control signal (generated by the first processor core 1111), a second control signal (generated by the second processor core 1112), a third control signal (generated and forwarded by the third processor core 1211 of the auxiliary control unit 120), and a fourth control signal (generated and forwarded by the fourth processor core 1212 of the auxiliary control unit 120).

[0064] This embodiment calculates the braking control signal independently by four heterogeneous processor cores, ensuring that software defects, algorithm errors, or hardware failures of any single processor core will not affect the normal calculation of other cores, thus providing a reliable signal source for subsequent consistency verification.

[0065] In step S303, the consistency verification module 150 performs consistency verification on the first control signal, the second control signal, the third control signal, and the fourth control signal.

[0066] The consistency condition is defined as follows: the deviation between the control signals used for consistency judgment is less than a preset deviation threshold.

[0067] In the table below, CCU1 is the main control unit 110, which is the main control device. The control signals are output by the main control unit 110. In the table, A represents the first control signal, B represents the second control signal, C represents the third control signal, and D represents the control signal.

[0068] A=B CCU1 transmits control signal A through its private first-level private CAN communication network. A≠B and A=C=D CCU1 transmits control signal A through its private first-level private CAN communication network. A≠B and B=C=D CCU1 transmits control signal B through its private first private CAN communication network. A≠B and C≠D and (A=C or A=D) CCU1 transmits control signal A through its private first-level private CAN communication network. A≠B and C≠D and (B=C or B=D) CCU1 transmits control signal B through its private first private CAN communication network. Not meeting any of the above conditions Set the control signal output status to Inhibit (disable output).

[0069] Specifically, when there is no communication failure in the multi-channel private CAN communication network 180, such as Figure 4a As shown:

[0070] When the main control unit 110 is the main control device and neither the first processor core 1111 nor the second processor core 1112 is faulty, the consistency verification module 150 first determines whether the first control signal and the second control signal meet the consistency conditions.

[0071] If the first control signal and the second control signal meet the consistency condition, the main control unit 110 directly outputs the first control signal as a valid control signal through the first private CAN communication network 181.

[0072] If the first control signal and the second control signal do not meet the consistency condition, the process proceeds to the majority voting stage, where the consistency verification module 150 determines the following:

[0073] (1) Whether the first control signal, the third control signal, and the fourth control signal all meet the consistency condition, that is, whether the deviation value between the first control signal and the third control signal is less than the preset deviation threshold, and whether the deviation value between the first control signal and the fourth control signal is less than the preset deviation threshold.

[0074] (2) Whether the second control signal, the third control signal, and the fourth control signal all meet the consistency condition, that is, whether the deviation value between the second control signal and the third control signal is less than the preset deviation threshold, and whether the deviation value between the second control signal and the fourth control signal is less than the preset deviation threshold.

[0075] If the first control signal, the third control signal, and the fourth control signal in (1) all meet the consistency condition, then the main control unit 110 outputs the first control signal as a valid control signal through the first private CAN communication network 181.

[0076] If the second control signal in (2) meets the consistency condition with the third and fourth control signals, then the main control unit 110 outputs the second control signal as a valid control signal through the first private CAN communication network 181.

[0077] If neither (1) nor (2) is satisfied, then the control signal output is prohibited and the wheel-end actuator enters the safety braking mode.

[0078] like Figure 4b As shown, when the main control unit 110 is the main control device, and the first processor core 1111 is faulty while the second processor is not faulty, the consistency verification module 150 directly enters the majority voting stage to determine whether the first control signal, the third control signal, and the fourth control signal meet the consistency conditions.

[0079] like Figure 4cAs shown, in the main control unit 110, the first processor core 1111 is fault-free, while the second processor is faulty. The consistency verification module 150 directly enters the majority voting stage to determine whether the second control signal, the third control signal, and the fourth control signal meet the consistency conditions.

[0080] When both the first processor core 1111 and the second processor core 1112 in the main control unit 110 are faulty, the control switching module 190 triggers the control switching, switching the auxiliary control unit 120 to the main control device.

[0081] like Figure 4d As shown, when the auxiliary control unit 120 is the main control device and neither the third processor core 1211 nor the fourth processor core 1212 is faulty, the consistency verification module 150 directly determines whether the third control signal and the fourth control signal meet the consistency conditions.

[0082] If the third control signal and the fourth control signal meet the consistency condition, the auxiliary control unit 120 outputs the third control signal as a valid control signal through the first private CAN communication network 181.

[0083] If the third control signal and the fourth control signal do not meet the consistency condition, the control signal output is prohibited, and the wheel-end actuator enters the safety braking mode.

[0084] When the auxiliary control unit 120 is the main control device, or when the third processor core 1211 or the fourth processor core 1212 malfunctions, the control signal output is directly prohibited, the wheel-end actuator enters the safety braking mode, and an alarm is output.

[0085] When the first private CAN communication network 181 fails to communicate and the main control unit 110 is the master control device, the main control unit 110 outputs a valid control signal to the left front wheel end and the right rear wheel end of the wheel-end actuator through the second private CAN communication network 182. The main control unit 110 sends the valid control signal to the auxiliary control unit 120 through the fourth private CAN communication network 184. The auxiliary control unit 120 outputs a valid control signal to the right front wheel end and the left rear wheel end of the wheel-end actuator through the third private CAN communication network 183.

[0086] When the first private CAN communication network 181 fails to communicate and the auxiliary control unit 120 becomes the master control device, the auxiliary control unit 120 outputs a valid control signal to the right front wheel and left rear wheel of the wheel-end actuator through the third private CAN communication network 183. The auxiliary control unit 120 also sends the valid control signal to the master control unit 110 through the fourth private CAN communication network 184. The master control unit 110 then outputs a valid control signal to the left front wheel and right rear wheel of the wheel-end actuator through the second private CAN communication network 182.

[0087] It should be noted that regardless of whether the current control right belongs to the main control unit 110 or the auxiliary control unit 120, both control units continuously output valid control signals containing safety level indicators. The wheel-end actuator arbitrates the two valid control signals in real time and dynamically switches to the signal source with the higher current safety level to achieve seamless redundancy backup of control right.

[0088] In some implementations, heartbeat detection is used to determine whether any of the first processor core 1111, the second processor core 1112, the third processor core 1211, or the fourth processor core 1212 is faulty.

[0089] like Figure 5 As shown, taking the first processor core and the second processor core as an example, the heartbeat detection module 170 performs heartbeat detection at a preset time period. The first processor core 1111 and the second processor core 1112 exchange heartbeat messages through the high-speed SPI interface inside the main control unit 110. The heartbeat message is 8 bytes long and includes the sender identifier, sequence number, and life signal. For example, the preset time period is 10ms.

[0090] If the first processor core 1111 does not receive a heartbeat message from the second processor core 1112 within a preset time, it is determined that the second processor core 1112 has a communication failure. If the second processor core 1112 does not receive a heartbeat message from the first processor core 1111 within a preset time, it is determined that the first processor core 1111 has a communication failure.

[0091] The third processor core 1211 and the fourth processor core 1212 exchange heartbeat messages and monitor communication failures through the SPI interface inside the auxiliary control unit 120 in the same manner.

[0092] In some other implementations, taking the first processor core and the second processor core as an example, the counting flag is reset at the beginning of each cycle. Then, the first processor core 1111 and the second processor core 1112 send heartbeat messages to each other through the high-speed SPI interface inside the main control unit 110. If each processor core does not receive a heartbeat response from the other within a preset time threshold, the non-response is counted in the non-response count.

[0093] If the number of times the first processor core 1111 fails to receive a response exceeds a preset threshold, it is determined that the second processor core 1112 has a communication failure; if the number of times the second processor core 1112 fails to receive a response exceeds a preset threshold, it is determined that the first processor core 1111 has a communication failure.

[0094] The third processor core 1211 and the fourth processor core 1212 exchange heartbeat messages and monitor communication failures through the SPI interface inside the auxiliary control unit 120 in the same manner.

[0095] The following embodiments use a complete emergency braking process as an example to describe the complete workflow of the present invention.

[0096] When the driver slams on the brake pedal or the automatic driving system issues an emergency braking command, a braking request signal is simultaneously sent to the main control unit 110 and the auxiliary control unit 120.

[0097] The first processor core 1111 in the main control unit 110 runs the first control software, and the second processor core 1112 runs the second control software. Both independently calculate the braking torque command based on the same braking request signal, generating the first control signal and the second control signal. Similarly, the third processor core 1211 and the fourth processor core 1212 in the auxiliary control unit 120 independently calculate and generate the third and fourth control signals, respectively, and send them to the main control unit 110 via the fourth private CAN communication network 184.

[0098] After the consistency verification module 150 of the main control unit 110 acquires the four control signals, it first determines whether there is a communication fault between the first processor core 1111 and the second processor core 1112. Under normal conditions, it prioritizes determining whether the first control signal and the second control signal are consistent—if the deviation between the two is less than a preset deviation threshold (such as ±2%), then the control signal is directly output to the electromechanical brake actuator 40, resulting in the shortest braking response time and no delay in braking force output.

[0099] If the first control signal and the second control signal are inconsistent (the deviation exceeds a preset deviation threshold), then the majority voting stage begins. The consistency verification module 150 determines whether the first control signal is consistent with the third and fourth control signals, or whether the second control signal is consistent with the third and fourth control signals. If the first control signal is consistent with the third and fourth control signals, then the first control signal is used as the output; if the second control signal is consistent with the third and fourth control signals, then the second control signal is used as the output.

[0100] If all four signals are inconsistent, control signal output will be prohibited, and a system fault alarm will be triggered, prompting the driver to take manual braking measures.

[0101] Throughout the braking process, the first processor core 1111 and the second processor core 1112 in the main control unit 110, and the third processor core 1211 and the fourth processor core 1212 in the auxiliary control unit 120, continuously exchange heartbeat messages through the high-speed SPI interface inside the main control unit 110 / auxiliary control unit 120 to monitor each other's working status in real time.

[0102] If the first processor core 1111 fails, the main control unit 110 remains the main control device, and continues to output braking control commands after performing consistency verification based on the second, third and fourth control signals.

[0103] If the main control unit 110 fails (both the first processor core 1111 and the second processor core 1112 fail), the auxiliary control unit 120 will be switched to the current main control unit within 20ms through the control switching module 190. After consistency verification based on the third control signal and the fourth control signal, the braking control command will continue to be output.

[0104] The following embodiments provide an alternative technical solution based on different combinations of heterogeneous software architectures and dynamic consistency verification thresholds, focusing on describing the... Figure 1 The systems shown differ in their software implementation and verification strategies.

[0105] The first control software is implemented using fixed-point C code automatically generated by MATLAB Simulink and runs in the bare-metal environment of the first processor core 1111. The second control software is implemented using handwritten C code based on floating-point arithmetic and runs in the AUTOSAR environment of the second processor core 1112. The third control software is implemented using C code translated from Python and runs in the FreeRTOS environment of the third processor core 1211. The fourth control software is safety-critical code implemented using the Ada language and runs in the bare-metal environment of the fourth processor core 1212.

[0106] The first and second control software are heterogeneous in terms of data representation, task scheduling mechanism, and runtime library calls. The third and fourth control software are heterogeneous in terms of programming language abstraction level, memory management method, and exception handling mechanism.

[0107] The consistency verification strategy employs a dynamic threshold adjustment mechanism. The basic consistency conditions are set as follows: the absolute value of the difference between target clamping forces is no greater than 100N, and the absolute value of the difference between motor speed limits is no greater than 200rpm. Under low-speed driving conditions (below 30km / h), the consistency conditions are tightened to: the absolute value of the difference between target clamping forces is no greater than 30N, and the absolute value of the difference between motor speed limits is no greater than 50rpm.

[0108] In the multi-channel private CAN communication network 180, the baud rate of the first private CAN communication network 181 is set to 250kbps, the baud rates of the second private CAN communication network 182 and the third private CAN communication network 183 are set to 500kbps, and the baud rate of the fourth private CAN communication network 184 is set to 1Mbps.

[0109] This embodiment is suitable for application scenarios with high requirements for the diversity of software development toolchains. By combining different code generation methods and programming languages, it further reduces the risk of common software failures. The dynamic threshold mechanism provides higher control accuracy under low-speed conditions while ensuring safety.

[0110] The following embodiments provide an alternative technical solution for the physical integration architecture of the main and auxiliary control units and the optimization of heartbeat detection parameters.

[0111] The main control unit 110 and the auxiliary control unit 120 are integrated into the same multi-core microcontroller chip, which adopts the Infineon AURIX TC397TP architecture.

[0112] The first processor core 1111 and the second processor core 1112 are configured in the first lockstep core cluster of the chip, and the third processor core 1211 and the fourth processor core 1212 are configured in the second lockstep core cluster of the chip.

[0113] The two lockstep core clusters are connected via an internal bus matrix. The fourth private CAN communication network 184 is implemented through an internal virtual CAN channel, eliminating the need for external physical CAN cables.

[0114] The memory protection unit 130 employs a memory protection unit integrated into the chip and a bus memory protection unit 130 working in concert. The memory protection unit isolates the local RAM regions of the first processor core 1111 and the second processor core 1112. The bus memory protection unit 130 restricts the global RAM access permissions of the third processor core 1211 and the fourth processor core 1212, ensuring complete isolation of the memory regions of the four processor cores.

[0115] The heartbeat detection module 170 has a heartbeat message sending period of 10ms and a preset time of 30ms. The heartbeat message is transmitted through the inter-core communication register inside the chip, with a transmission delay of less than 1 microsecond. If the first processor core 1111 does not receive a heartbeat message from the second processor core 1112 within 30ms, a fault response is immediately triggered.

[0116] This embodiment reduces hardware costs and PCB layout area through a single-chip integration solution, making it suitable for space-constrained braking control modules. The shortened heartbeat detection cycle and preset time further improve fault response speed.

[0117] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, or methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or units may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of apparatuses or modules or units may be electrical, mechanical, or other forms.

[0118] The modules / units described as separate components may or may not be physically separate. The components shown as modules / units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / units can be selected to achieve the objectives of the embodiments of this application, depending on actual needs. For example, the functional modules / units in the various embodiments of this application may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit.

[0119] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0120] This embodiment provides an electronic device, which includes a memory and a processor.

[0121] Memory, used to store computer programs;

[0122] A processor is used to execute computer programs stored in memory to enable electronic devices to perform software heterogeneous redundancy control methods for electromechanical braking systems as described above.

[0123] Figure 6The diagram shown is a structural schematic of an electronic device 600 according to an embodiment of this application. Figure 6 As shown, in this embodiment, the electronic device 600 includes a memory 601 and a processor 602.

[0124] The memory 601 is used to store computer programs; preferably, the memory 601 includes various media that can store program code, such as ROM, RAM, magnetic disk, USB flash drive, memory card or optical disk.

[0125] Specifically, memory 601 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory. Electronic device 600 may further include other removable / non-removable, volatile / non-volatile computer system storage media. Memory 601 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application. It is understood that memory 601 may be volatile memory or non-volatile memory, or both. Non-volatile memory may be read-only memory (ROM) or programmable read-only memory (PROM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memories described in the embodiments of this invention are intended to include, but are not limited to, these and any other suitable categories of memories.

[0126] The processor 602 is connected to the memory 601 and is used to execute the computer program stored in the memory 601 so that the electronic device 600 executes the software heterogeneous redundancy control method for an electromechanical braking system according to any embodiment of this application.

[0127] Optionally, the processor 602 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0128] Optionally, the electronic device 600 in this embodiment may further include a display 603. The display 603 is communicatively connected to the memory 601 and the processor 602, and is used to display the relevant graphical user interface (GUI) of the software heterogeneous redundancy control method for the electromechanical braking system according to the embodiments of this application.

[0129] This application also provides a vehicle. Figure 7 The diagram shown is a schematic representation of a vehicle according to one embodiment of this application. Figure 7 As shown, vehicle 700 includes the software heterogeneous redundancy control system 100 for the electromechanical braking system as described above. The software heterogeneous redundancy control system 100 for the electromechanical braking system has already been described above and will not be repeated here.

[0130] This application also provides a computer-readable storage medium. Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing a processor, and the program can be stored in a computer-readable storage medium. The storage medium is a non-transitory medium, such as random access memory, read-only memory, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof. The above storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0131] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0132] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A software heterogeneous redundancy control method for an electromechanical braking system, characterized in that, include: Obtain the braking request signal; The system acquires a first control signal, a second control signal, a third control signal, and a fourth control signal generated based on the braking request signal. The first control signal is generated by a first processor core running first control software, the second control signal is generated by a second processor core running second control software, the third control signal is generated by a third processor core running third control software, and the fourth control signal is generated by a fourth processor core running fourth control software. The first processor core and the second processor core are configured in a main control unit, and the third processor core and the fourth processor core are configured in an auxiliary control unit. The consistency of the first control signal, the second control signal, the third control signal, and the fourth control signal is verified. In response to the fulfillment of the consistency condition, the control signal confirmed by consistency verification is output as a valid control signal to the wheel-end actuator through a multi-channel private CAN communication network; or In response to non-compliance conditions, the output of effective control signals is prohibited.

2. The method according to claim 1, characterized in that, The first control software and the second control software run in independent memory regions with different architectures, so that the first control software and the second control software are heterogeneous in terms of operation logic and runtime resources. The third control software and the fourth control software run in independent memory regions with different architectures, so that the third control software and the fourth control software are heterogeneous in terms of operation logic and runtime resources.

3. The method according to claim 1, characterized in that, The method further includes: Under normal operating conditions, the main control unit acts as the current master control device to perform the consistency verification and output the valid control signal. When both the first processor core and the second processor core in the main control unit experience a communication failure, the main control unit sends a control switch request to the auxiliary control unit to switch control to the auxiliary control unit. After the switch, the auxiliary control unit takes over the consistency verification based on the third control signal and the fourth control signal, and outputs the valid control signal when the consistency condition is met.

4. The method according to claim 3, characterized in that, The consistency verification of the first control signal, the second control signal, the third control signal, and the fourth control signal includes: When the main control unit is the master control device, it is first determined whether the first control signal and the second control signal meet the consistency condition. If the conditions are met, the first control signal or the second control signal is directly output as the valid control signal. If not satisfied, then determine whether the first control signal meets the consistency condition with the third control signal and the fourth control signal, and whether the second control signal meets the consistency condition with the third control signal and the fourth control signal, and based on the determination results, output the valid control signal or disable the output of the valid control signal; If the first control signal meets the consistency condition with the third and fourth control signals, then the first control signal is output as the valid control signal; or If the second control signal meets the consistency condition with the third and fourth control signals, then the second control signal is output as the valid control signal; or If the first control signal does not meet the consistency condition with the third and fourth control signals, or the second control signal does not meet the consistency condition with the third and fourth control signals, then the output of the valid control signal is prohibited. When both the first processor core and the second processor core in the main control unit fail, the auxiliary control unit is switched to become the main control device. Based on the third control signal and the fourth control signal, it is determined whether the consistency condition is met. If the consistency condition is met, the third control signal or the fourth control signal is output as a valid control signal; otherwise, the control signal output is prohibited.

5. The method according to claim 1, characterized in that, The method further includes: performing heartbeat detection on the first processor core and the second processor core, and on the third processor core and the fourth processor core, respectively, including: The first processor core and the second processor core exchange heartbeat messages; If the first processor core does not receive the heartbeat message sent by the second processor core within a preset time, it is determined that the second processor core has a communication failure; or if the second processor core does not receive the heartbeat message sent by the first processor core within a preset time, it is determined that the first processor core has a communication failure. In response to a communication failure in the first processor core or the second processor core, a consistency verification is performed on the second control signal or the first control signal, the third control signal, and the fourth control signal. The third processor core and the fourth processor core send heartbeat messages to each other in the same manner as the first processor core and the second processor core, and monitor communication failures.

6. The method according to claim 1, characterized in that, The multi-channel private CAN communication network includes a first private CAN communication network, a second private CAN communication network, a third private CAN communication network, and a fourth private CAN communication network; among them, The main control unit and the auxiliary control unit are redundantly connected via the fourth private CAN communication network. The main control unit sends effective control signals to the wheel-end actuator through the first private CAN communication network or the second private CAN communication network. The auxiliary control unit sends effective control signals to the wheel-end actuator through the first private CAN communication network or the third private CAN communication network.

7. A software heterogeneous redundancy control system for an electromechanical braking system, characterized in that, include: The signal receiving module is configured to acquire braking request signals; The main control unit includes a first multi-core microcontroller unit, which is configured with a first processor core and a second processor core. The first processor core is configured to run first control software to generate a first control signal based on the braking request signal, and the second processor core is configured to run second control software to generate a second control signal based on the braking request signal. The auxiliary control unit includes a second multi-core microcontroller unit, configured with a third processor core and a fourth processor core, wherein the third processor core is configured to run third control software to generate a third control signal based on the braking request signal, and the fourth processor core is configured to run fourth control software to generate a fourth control signal based on the braking request signal. The consistency verification module is configured to perform consistency verification on the first control signal, the second control signal, the third control signal, and the fourth control signal; The control signal output module is configured to output the control signal that has been verified to be consistent as a valid control signal to the wheel-end actuator when the first control signal, the second control signal, the third control signal, and the fourth control signal meet the consistency condition; and to prohibit the output of the valid control signal when the consistency condition is not met. A multi-channel private CAN communication network, connecting the main control unit, the auxiliary control unit, and the wheel-end actuator, is configured to enable data communication between the main control unit and the auxiliary control unit, and to enable the main control unit and / or the auxiliary control unit to output valid control signals to the wheel-end actuator.

8. The system according to claim 7, characterized in that, The system also includes: A memory protection unit is configured inside the main control unit and the auxiliary control unit to isolate and protect the memory regions corresponding to different processor cores inside the main control unit and the auxiliary control unit, and to prohibit cross-region memory access. The heartbeat detection module is configured to perform heartbeat detection on the first processor core and the second processor core, and the third processor core and the fourth processor core to monitor communication failures; The control switching module is configured to monitor the working status of the main control unit and trigger a control switching when the main control unit fails, switching the control of the main control device to the auxiliary control unit.

9. An electronic device, characterized in that, include: A memory that stores a computer program; The processor, which is communicatively connected to the memory, executes the software heterogeneous redundancy control method for an electromechanical braking system as described in any one of claims 1 to 6 when calling the computer program.

10. A vehicle, characterized in that, The vehicle includes a software heterogeneous redundancy control system for an electromechanical braking system as described in any one of claims 7 to 8.