Method for identifying non-starting or continuous resetting of communication MCU

Abstract

The application discloses a kind of identification methods of communication MCU non-start or continuous reset, belong to ECU technical field, to solve the problem that it is not convenient to set multiple MCUs in traditional ECU, when one MCU-A is not started or continuously reset, another MCU-B is used to replace the function, and the intervention of other ECU, i.e.ECU-B, enables MCU-B to effectively identify the situation that MCU-A is not started or continuously reset, and then replaces the function thereof;The application directly communicates two MCUs inside ECU and communicates the third party on network with two MCUs, and the two MCUs in ECU can effectively identify that the other party is not started or continuously reset, and then replace the function of another group of MCUs identified as not started or continuously reset with a group of MCUs that can work normally, without affecting the normal work of ECU.

Description

Technical Field

[0001] This invention relates to the field of ECU technology, specifically to a method for identifying when a communication-type MCU is not started or is continuously reset. Background Technology

[0002] The ECU (Electronic Control Unit), also known as the "vehicle computer" or "on-board computer," is similar to a regular computer. It consists of a microcontroller (MCU), memory (ROM, RAM), input / output interfaces (I / O), analog-to-digital converters (A / D), and large-scale integrated circuits for shaping and driving. The operation of the ECU is essential for the microcontroller (MCU) to function properly. However, if the MCU in the ECU fails to start or continuously resets, it will affect the operation of the ECU.

[0003] Traditional ECUs do not readily support multiple MCUs. When one MCU-A fails to start or remains reset, another MCU-B can take over its function. This requires the intervention of another ECU, ECU-B, to enable MCU-B to effectively identify the failure or reset of MCU-A and then take over its function.

[0004] To address the aforementioned issues, a method for identifying when a communication-type MCU fails to start or remains in a reset state is proposed. Summary of the Invention

[0005] The purpose of this invention is to provide a method for identifying when a communication-type MCU is not started or is continuously reset. This method solves the problem in the background art where it is inconvenient to set up multiple MCUs in a traditional ECU. When one MCU-A is not started or is continuously reset, another MCU-B can take over its function. Furthermore, the method involves the intervention of another ECU, namely ECU-B, so that MCU-B can effectively identify the situation where MCU-A is not started or is continuously reset, and then take over its function.

[0006] 2. To achieve the above objectives, the present invention provides the following technical solution: A method for identifying a communication-type MCU that is not started or is continuously reset, comprising an ECU, wherein the ECU includes at least ECU-A and ECU-B, ECU-A includes at least MCU-A as a master and MCU-B as a backup slave, communication between MCU-A and MCU-B is configured with I / O, and UART or SPI, wherein the I / O includes MCU-A_IO and MCU-B_IO, and MCU-A, MCU-B and ECU-B are in the same CAN network.

[0007] Its features are:

[0008] The method for identifying whether the MCU is not started or is continuously resetting includes the following steps:

[0009] S100: MCU-B uses the input terminal of MCU-A_IO corresponding to MCU-A_IO on MCU-B to detect whether the output of MCU-A_IO is normal (R1);

[0010] S200: After MCU-A sends a command through the UART or SPI communication port, MCU-B checks the command sent by MCU-A to determine whether it is normal (R2).

[0011] S300: MCU-B receives CAN messages from MCU-A and ECU-B via the CAN network and determines whether the received messages are normal (R3).

[0012] S400: MCU-B determines whether MCU-A is not started or continuously reset based on the obtained R1, R2 and R3.

[0013] Furthermore, MCU-B determines whether MCU-A is not started or continuously reset based on the obtained R1, R2, and R3, including:

[0014] If R1, R2, and R3 are all abnormal according to the judgment of MCU-B, then MCU-A is determined to be not started or continuously reset, and MCU-B will actively take over the functions of MCU-A and prompt that MCU-A is malfunctioning.

[0015] Furthermore, the CAN network includes a CAN bus and CAN1, which communicates with MCU-A, and CAN2, which communicates with MCU-B. Both CAN1 and CAN2 are connected to the CAN bus, and ECU-B is also connected to the CAN bus.

[0016] Furthermore, MCU-A_IO is a general-purpose output port of MCU-A, and the output level state of this port is toggled according to a defined period. MCU-B detects whether the output of MCU-A_IO is normal through the input terminal of MCU-A_IO corresponding to MCU-A_IO on MCU-B. R1 includes:

[0017] The MCU-B detects the output of MCU-A_IO through the input terminal of MCU-A_IO on the MCU-B. If the output level does not flip or the time interval between two adjacent level changes exceeds T1, then R1 is abnormal.

[0018] Furthermore, after MCU-A sends a command through the UART or SPI communication port, MCU-B checks the command sent by MCU-A to determine whether it is normal. R2 includes:

[0019] After MCU-A sends a command through the UART or SPI communication port, MCU-B detects the command sent by MCU-A. If the communication command is not received or the time interval between two adjacent commands exceeds T1, then R2 is abnormal.

[0020] Furthermore, the MCU-B receives CAN messages from MCU-A and ECU-B via the CAN network and determines whether the received messages are normal. R3 includes:

[0021] R3 is abnormal when MCU-B detects that the CAN message of ECU-B is received normally, the CAN message of a specific frame ID of MCU-A is lost, or the time interval between two adjacent messages exceeds T1.

[0022] Furthermore, the CAN messages received by MCU-B from MCU-A and ECU-B have specific frame IDs.

[0023] Furthermore, MCU-B_IO is the general-purpose output port of MCU-B. The output of this port is toggled between high and low levels according to a defined period. This port corresponds to the input port of MCU-A. The defined period is the preset time, which can be changed by the control circuit or manually.

[0024] Furthermore, the control power supply for MCU-A and MCU-B is 5V.

[0025] Furthermore, MCU-A or MCU-B is the designated name of one of any two MCU groups, and the preset frequency of MCU-A and MCU-B is 1KHz.

[0026] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0027] 1. This invention provides a method for identifying when a communication-type MCU is not started or is continuously reset. This application enables direct communication between two MCUs within an ECU and communication between the two MCUs and a third party on the network. The two MCUs in the ECU can effectively identify when the other is not started or is continuously reset. Then, the function of the other set of MCUs that is identified as not started or continuously reset is replaced by the set of MCUs that are working normally, without affecting the normal operation of the ECU. This solves the problem that in traditional ECUs, it is inconvenient to set up multiple MCUs. When one MCU-A is not started or is continuously reset, another MCU-B is used to take over the function. Moreover, the intervention of a third-party network enables MCU-B to effectively identify the situation of MCU-A not starting or continuously reset, and then take over its function. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the communication connection of the present invention. Detailed Implementation

[0029] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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 are within the scope of protection of the present invention.

[0030] To address the inconvenience of using multiple MCUs in traditional ECUs, and to facilitate the function takeover of MCU-B when MCU-A is not powered on or continuously reset, the technical challenge lies in enabling MCU-B to effectively identify the MCU-A's failure or reset status through the intervention of another ECU, ECU-B. In this configuration, MCU-A acts as the master ECU, and MCU-B as the backup slave ECU. Figure 1 As shown, the following preferred technical solutions are provided:

[0031] A method for identifying a communication-type MCU that is not powered on or is continuously reset includes an ECU, wherein the ECU includes at least ECU-A and ECU-B, ECU-A contains at least MCU-A as a master MCU and MCU-B as a backup slave MCU, communication between MCU-A and MCU-B is configured with I / O and UART or SPI, the I / O including MCU-A_IO and MCU-B_IO, and MCU-A, MCU-B and ECU-B are in the same CAN network.

[0032] Its features are:

[0033] The method for identifying whether the MCU is not started or is continuously resetting includes the following steps:

[0034] S100: MCU-B uses the input terminal of MCU-A_IO corresponding to MCU-A_IO on MCU-B to detect whether the output of MCU-A_IO is normal (R1);

[0035] S200: After MCU-A sends a command through the UART or SPI communication port, MCU-B checks the command sent by MCU-A to determine whether it is normal (R2).

[0036] S300: MCU-B receives CAN messages from MCU-A and ECU-B via the CAN network and determines whether the received messages are normal (R3).

[0037] S400: MCU-B determines whether MCU-A is not started or continuously reset based on the obtained R1, R2 and R3.

[0038] MCU-B determines whether MCU-A is not started or continuously reset based on the obtained R1, R2, and R3, including:

[0039] If R1, R2, and R3 are all abnormal according to the judgment of MCU-B, then MCU-A is determined to be not started or continuously reset, and MCU-B will actively take over the functions of MCU-A and prompt that MCU-A is malfunctioning.

[0040] The CAN network includes the CAN bus and CAN1, which communicates with MCU-A, and CAN2, which communicates with MCU-B. Both CAN1 and CAN2 are connected to the CAN bus, and ECU-B is also connected to the CAN bus.

[0041] MCU-A_IO is the general-purpose output port of MCU-A. The output level of this port is toggled according to a defined period. MCU-B detects whether the output of MCU-A_IO is normal through the corresponding input terminal of MCU-A_IO on MCU-B. R1 includes:

[0042] The MCU-B detects the output of MCU-A_IO through the input terminal of MCU-A_IO on the MCU-B. If the output level does not flip or the time interval between two adjacent level changes exceeds T1, then R1 is abnormal.

[0043] After MCU-A sends a command through the UART or SPI communication port, MCU-B checks the command sent by MCU-A to determine whether it is normal. R2 includes:

[0044] After MCU-A sends a command through the UART or SPI communication port, MCU-B detects the command sent by MCU-A. If the communication command is not received or the time interval between two adjacent commands exceeds T1, then R2 is abnormal.

[0045] The MCU-B receives CAN messages from MCU-A and ECU-B via the CAN network and determines whether the received messages are normal. R3 includes:

[0046] R3 is abnormal when MCU-B detects that the CAN message of ECU-B is received normally, the CAN message of a specific frame ID of MCU-A is lost, or the time interval between two adjacent messages exceeds T1.

[0047] MCU-B receives CAN messages from MCU-A and ECU-B with a specific frame ID. MCU-B_IO is the general-purpose output port of MCU-B. This port toggles between high and low levels according to a defined period. This port corresponds to the input port of MCU-A. The defined period is the preset time. This period can be changed by the control circuit or manually. The control power supply for MCU-A and MCU-B is 5V. MCU-A or MCU-B is the designated name of any two MCUs. The preset frequency of MCU-A and MCU-B is 1KHz.

[0048] like Figure 1 In this embodiment of the application, how is it determined whether MCU-A or MCU-B is operating normally?

[0049] Step 1: MCU-A_IO is the general output port of MCU-A. The output level of this port is toggled according to a defined period. At the same time, the MCU-A_IO output is checked through the MCU-B input port corresponding to this port to see if it is normal. This is one of the conditions for judging whether MCU-A is operating normally.

[0050] Step 2: MCU-B_IO is the general-purpose output port of MCU-B. The output of this port is toggled between high and low levels according to a defined period. At the same time, the MCU-B_IO output is checked through the MCU-A input port corresponding to this port to see if it is normal. This is one of the conditions for determining whether MCU-B is operating normally.

[0051] Step 3: Use the UART or SPI communication port to interact in master-slave mode. MCU-A is the master and MCU-B is the slave. After MCU-A sends a command, MCU-B responds. After MCU-A sends a command, it checks whether MCU-B's response is normal, which is one of the conditions for judging whether MCU-B is operating normally. At the same time, MCU-B checks whether MCU-A's command is normal, which is one of the conditions for judging whether MCU-A is operating normally.

[0052] Step 4: CAN communication interface. MCU-A, MCU-B, and ECU-B are in the same CAN network. ECU-B is the third party used for communication. During normal operation, MCU-B can receive CAN messages with specific frame IDs from MCU-A and ECU-B. MCU-B uses the normality of the received CAN messages from MCU-A and ECU-B as one of the conditions for determining whether MCU-A is operating normally.

[0053] In this embodiment of the application, the strategy and method for identifying MCU-A malfunction is as follows:

[0054] Condition 1: When MCU-B detects that the output level of MCU-A_IO has not been toggled or the time interval between two adjacent level changes exceeds T1, it is considered that condition 1 of MCU-A not starting or continuously resetting is met;

[0055] Condition 2: When MCU-B detects that the UART or SPI communication command of MCU-A has not been received or the time interval between two adjacent commands exceeds T1, it is considered that condition 2 of MCU-A not starting or continuously resetting is met;

[0056] Condition 3: When MCU-B detects that the CAN message of a specific frame ID of ECU-B is received normally, the CAN message of a specific frame ID of MCU-A is lost, or the time interval between two adjacent messages exceeds T1, it is considered that condition 3 of MCU-A is not started or is continuously reset is met.

[0057] When MCU-B detects that conditions 1, 2, and 3 for MCU-A not starting or continuously resetting are all met, MCU-B confirms that MCU-A is in a state of not starting or continuously resetting. MCU-B will then take over the functions of MCU-A and implement the functions of ECU-A, indicating that MCU-A is malfunctioning (T1 is a setting value for easy monitoring).

[0058] In this embodiment of the application, the strategy and method for identifying MCU-B malfunction is as follows:

[0059] Condition 4: When MCU-A detects that the output level of MCU-B_IO has not been toggled or the time interval between two adjacent level changes exceeds T2, it is considered that condition 4 of MCU-B not starting or continuously resetting is met;

[0060] Condition 5: When MCU-A detects that the UART or SPI communication command response of MCU-B has not been received or the time interval between two adjacent command responses exceeds T2, it is considered that condition 5 of MCU-B not starting or continuously resetting is met;

[0061] When MCU-A detects that conditions 4 and 5 for MCU-B not starting or continuously resetting are met, MCU-A confirms that MCU-B is in a state of not starting or continuously resetting, and MCU-A will prompt that MCU-B is malfunctioning (T2 is a setting value for easy monitoring).

[0062] according to Figure 1In summary: This application enables direct communication between MCU-A and MCU-B within the ECU, as well as communication between MCU-A and MCU-B and a third party on the network. In this application, the third party refers to ECU-B. MCU-A and MCU-B in ECU-A can effectively identify each other as not started or continuously reset. Subsequently, a set of MCUs that are working properly can be used to replace the other set of MCUs that are identified as not started or continuously reset, without affecting the normal operation of ECU-A.

[0063] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0064] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for identifying a communication-type MCU that is not started or is continuously reset, comprising an ECU, wherein the ECU includes at least ECU-A and ECU-B, ECU-A containing at least MCU-A as a master and MCU-B as a backup slave, communication between MCU-A and MCU-B is configured with I / O, and UART or SPI, wherein the I / O includes MCU-A_IO and MCU-B_IO, and MCU-A, MCU-B, and ECU-B are in the same CAN network. Its features are: The method for identifying whether the MCU is not started or is continuously resetting includes the following steps: S100: MCU-B uses the input terminal of MCU-A_IO corresponding to MCU-A_IO on MCU-B to detect whether the output of MCU-A_IO is normal (R1); S200: After MCU-A sends a command through the UART or SPI communication port, MCU-B checks the command sent by MCU-A to determine whether it is normal (R2). S300: MCU-B receives CAN messages from MCU-A and ECU-B via the CAN network and determines whether the received messages are normal (R3). S400: MCU-B determines whether MCU-A is not started or continuously reset based on the obtained R1, R2 and R3; The MCU-B determines whether MCU-A is not started or continuously reset based on the obtained R1, R2, and R3, including: If R1, R2, and R3 are all abnormal according to the judgment of MCU-B, then MCU-A is determined to be not started or continuously reset, and MCU-B will actively take over the functions of MCU-A and prompt that MCU-A's function is abnormal; MCU-A_IO is the general-purpose output port of MCU-A. The output level of this port is toggled according to a defined period. MCU-B detects whether the output of MCU-A_IO is normal through the corresponding input terminal of MCU-A_IO on MCU-B. R1 includes: The MCU-B detects the output of MCU-A_IO through the input terminal of MCU-A_IO on the MCU-B. If the output level does not flip or the time interval between two adjacent level changes exceeds T1, then R1 is abnormal. After MCU-A sends a command through the UART or SPI communication port, MCU-B checks the command sent by MCU-A to determine whether it is normal. R2 includes: After MCU-A sends a command through the UART or SPI communication port, MCU-B detects the command sent by MCU-A. If the communication command is not received or the time interval between two adjacent commands exceeds T1, then R2 is abnormal. The MCU-B receives CAN messages from MCU-A and ECU-B via the CAN network and determines whether the received messages are normal. R3 includes: R3 is abnormal when MCU-B detects that the CAN message of ECU-B is received normally, the CAN message of a specific frame ID of MCU-A is lost, or the time interval between two adjacent messages exceeds T1.

2. The method for identifying a communication-type MCU that is not started or is continuously reset according to claim 1, characterized in that: The CAN network includes the CAN bus and CAN1, which communicates with MCU-A, and CAN2, which communicates with MCU-B. Both CAN1 and CAN2 are connected to the CAN bus, and ECU-B is also connected to the CAN bus.

3. The method for identifying a communication-type MCU that is not started or is continuously reset according to claim 1, characterized in that: The CAN messages received by MCU-B from MCU-A and ECU-B have specific frame IDs.

4. The method for identifying a communication-type MCU that is not started or is continuously reset according to claim 1, characterized in that: MCU-B_IO is the general-purpose output port of MCU-B. The output of this port is toggled between high and low levels according to a defined period. This port corresponds to the input port of MCU-A. The defined period is the preset time, which can be changed by the control circuit or manually.

5. The method for identifying a communication-type MCU that is not started or is continuously reset according to claim 1, characterized in that: The control power supply for MCU-A and MCU-B is 5V.

6. The method for identifying a communication-type MCU that is not started or is continuously reset according to claim 1, characterized in that: MCU-A or MCU-B is the designated name of one of any two MCU groups. The preset frequency of MCU-A and MCU-B is 1KHz.

Images