Method for sending diagnosis information of motor controller of new energy automobile through CAN (Controller Area Network)

Abstract

The invention belongs to the technical field of new energy automobile motor controller diagnosis, and particularly relates to a method for sending diagnosis information of a new energy automobile motor controller through a CAN (Controller Area Network), which comprises the following steps of: S0, counting faults of an electric drive system detected in a current power-on period and summarizing the faults into a fault queue; s1, initializing a circular queue; s2, traversing the fault queue to obtain fault information of each fault in the fault queue, and screening out to-be-sent fault information to be stored in a circular queue according to a fault state in the fault information in combination with a preset judgment condition; s3, the to-be-sent fault information is enqueued to a circular queue according to a preset enqueueing process; and S4, dequeuing the to-be-sent fault information in the circular queue according to a preset dequeuing process, and sending the to-be-sent fault information through the CAN module. According to the method, when the new energy automobile electric drive system breaks down, the corresponding fault information can be read at the first time, the problem can be solved and processed in time, and rapid identification, timely early warning and effective maintenance of the automobile fault are achieved.

Description

Technical Field

[0001] The present invention belongs to the technical field of new energy vehicle motor controller diagnosis, and in particular relates to a method for sending new energy vehicle motor controller diagnostic information via CAN. Background Art

[0002] With the rapid development of new energy vehicle technology, the vehicle remote diagnosis system has become an important tool to ensure the safe and reliable operation of the vehicle. Through remote communication technology, the system can monitor and diagnose various performance indicators of the vehicle in real time, and promptly discover and warn of potential faults, thereby greatly shortening the time for fault confirmation and maintenance, and effectively improving the utilization efficiency of maintenance resources.

[0003] Remote diagnostic technology has been widely used in the field of new energy vehicles due to its high efficiency and convenience. It can comprehensively analyze the vehicle system in a short period of time, accurately determine the fault, and provide maintenance personnel with timely and accurate diagnostic information, thereby ensuring that the vehicle can quickly resume normal operation.

[0004] However, in the prior art, the method of reading controller fault information through a diagnostic instrument has become increasingly limited when facing the complex system of a new energy vehicle motor controller. The motor controller of a new energy vehicle integrates a large number of advanced electronic components and control algorithms, and the complexity and diversity of its fault information far exceeds that of traditional vehicles. When reading this information, the diagnostic instrument in the prior art has problems such as slow information reading speed, low diagnostic accuracy and low information transmission efficiency. These problems directly lead to the inability of the prior art to efficiently and accurately send diagnostic information of the motor controller of new energy vehicles. Since the fault information cannot be transmitted to maintenance personnel or related systems in a timely and accurate manner, it is impossible to quickly identify vehicle faults, timely warn and effectively maintain them. This not only prolongs the time for fault repair and increases the risk of vehicle operation, but also reduces the reliability and user satisfaction of new energy vehicles.

[0005] Therefore, how to design an efficient and accurate method for sending diagnostic information of new energy vehicle motor controllers so that when a new energy vehicle electric drive system fails, the corresponding fault information can be read in the first time and the problem can be solved in time to achieve rapid identification, timely warning and effective maintenance of vehicle faults has become an urgent problem to be solved. Summary of the invention

[0006] In view of the deficiencies of the above-mentioned prior art, the present invention provides a method for sending diagnostic information of a new energy vehicle motor controller through CAN, so that when a fault occurs in the electric drive system of the new energy vehicle, the corresponding fault information can be read in the first time and the problem can be solved in time, so as to realize rapid identification of vehicle faults, timely warning and effective maintenance.

[0007] In order to solve the above technical problems, the present invention adopts the following technical solutions:

[0008] A method for sending diagnostic information of a motor controller of a new energy vehicle via CAN comprises the following steps:

[0009] S0. Counting the faults of the electric drive system detected in the current power-on cycle, and summarizing the fault information of each fault into a fault queue; wherein the fault information includes a fault ID and a corresponding fault code and fault status;

[0010] S1, initialize the circular queue and reset the head pointer and tail pointer to the start position of the queue;

[0011] S2, traverse the fault queue, obtain the fault information of each fault therein, and filter out the to-be-sent fault information to be stored in the circular queue according to the fault status in the fault information and the preset judgment conditions;

[0012] S3, according to the preset queueing process, the fault information to be sent is queued into the circular queue;

[0013] S4. According to the preset dequeuing process, the fault information to be sent in the dequeuing circular queue is dequeued and sent through the CAN module.

[0014] Compared with the prior art, the present invention has the following beneficial effects:

[0015] 1. In this method, by counting the electric drive system faults detected in the current power-on cycle and summarizing the fault information into the fault queue, centralized management of fault information is achieved. This helps to uniformly analyze and handle the faults later. At the same time, the circular queue is initialized, and the head pointer and tail pointer are used to perform queue operations to ensure the effective use of queue resources. The characteristics of the circular queue enable old data to be overwritten from the head of the queue when the queue is full, thereby avoiding the problem of queue overflow.

[0016] 2. In this method, the fault queue is traversed and the fault information to be sent is screened out according to the fault status and the preset judgment conditions. This step ensures that only important or urgent fault information is sent to the CAN bus, avoiding information redundancy and waste of communication resources. In addition, through the preset queue entry and exit process, the orderly storage and sending of the fault information to be sent in the circular queue is realized. This ensures that the fault information can be processed and transmitted in a certain order, which helps the receiving end to understand and respond to the fault information.

[0017] In summary, this method can read the corresponding fault information in the first time when a fault occurs in the electric drive system of a new energy vehicle, and solve the problem in time, so as to achieve rapid identification of vehicle faults, timely warning and effective maintenance.

[0018] Preferably, S2 includes:

[0019] S21, traverse the fault queue and obtain the fault information of each fault therein;

[0020] S22: For a fault, detect whether status bit0 and bit3 in the fault status have changed to determine whether the fault status has been updated or changed; if so, go to S23; if not, detect the next fault;

[0021] S23, check whether the clear flag in its fault state has been set to confirm whether the fault has been processed or cleared; if the fault clear flag has been set, remove the fault information of the fault; if the fault clear flag has not been set, go to S24;

[0022] S24: The fault information of the fault is used as the fault information to be stored in the circular queue and to be sent.

[0023] With this setting, 1. By detecting whether status bit0 and bit3 in the fault status have changed, the system can accurately identify which fault status has been updated or changed. This helps the system obtain the latest fault information in a timely manner and provides a basis for subsequent processing and decision-making. If the fault status has not changed, the system will not repeatedly send the same fault information, thereby avoiding the waste of communication resources and the processing burden on the receiving end. This helps to improve the overall efficiency and response speed of the system.

[0024] 2. It can manage processed fault information more effectively. By checking whether the fault clear flag is set, the system can identify which faults have been processed or cleared. For faults that have been processed, the system will remove their fault information to ensure that the circular queue only contains valid faults that currently need attention. This helps the system to more accurately assess the current fault situation and make reasonable decisions.

[0025] 3. It can ensure the accuracy of the fault information to be sent. After the above screening process, the system will eventually store the qualified fault information as the fault information to be sent in the circular queue. This information contains the latest fault status and excludes the faults that have been processed, so it has high accuracy and reliability.

[0026] Preferably, in S3, each piece of fault information to be sent is queued into a circular queue in sequence according to the order of occurrence time of the detected faults.

[0027] With this setting, 1. By queueing in the order of the time when the fault occurred, the system can ensure that the earliest fault information is processed and sent first. This helps the receiving end to obtain the most important fault information in time and respond quickly. In addition, the sequential queueing method ensures the orderliness of the fault information in the circular queue. This avoids processing confusion and omissions caused by information confusion and ensures the integrity and accuracy of the fault information.

[0028] 2. Sequential queuing also means that the system can use the resources of the circular queue more efficiently. Since the fault information is arranged in chronological order, the system can quickly locate specific fault information when needed without additional searching or sorting operations. In addition, this orderliness also helps to optimize the efficiency and reliability of CAN communication.

[0029] 3. It also supports fault tracking and analysis. The fault information in the sequence queue facilitates subsequent fault tracking and analysis. By viewing the fault information in the circular queue, technicians can clearly understand the order and time point of the fault occurrence, so as to more accurately determine the cause and impact of the fault.

[0030] Preferably, in S3, the preset queue entry process includes:

[0031] S31, determine whether the queue tail pointer position points to the last position of the circular queue; if so, go to S32; if not, go to S33;

[0032] S32, move the tail pointer back to the starting position of the queue, and then go to S33;

[0033] S33, storing the fault information to be sent currently to the queue position pointed to by the tail pointer;

[0034] S34. After successfully storing the fault information to be sent, update the position of the tail pointer to point to the next free position in the queue to prepare for the subsequent queue entry operation.

[0035] Such a setting can, 1. Avoid queue overflow. By judging whether the position of the queue tail pointer points to the last position of the circular queue (S31), the system can take timely measures when the queue is about to be full to prevent the queue from overflowing due to the inability to store new fault information. This is an important advantage of the circular queue over the linear queue. It allows the queue to overwrite old data from the beginning when it is full, thereby achieving efficient use of resources. The continuity of the queue can also be maintained. When the tail pointer points to the last position of the queue (S32), the system moves it back to the starting position of the queue and continues to store new fault information (S33). This operation ensures the continuity of the queue, so that the fault information forms a ring structure in the queue, which is convenient for subsequent reading and processing.

[0036] 2. It can ensure the orderliness of fault information. After each successful storage of the fault information to be sent (S33), the system will update the position of the tail pointer (S34) to point to the next free position in the queue. This operation ensures that the fault information is arranged in chronological order in the queue, which facilitates subsequent reading and fault analysis.

[0037] Through the above-mentioned queueing process, the system can efficiently manage the circular queue and ensure that fault information can be stored and transmitted in a timely and accurate manner. This helps to improve the overall efficiency and response speed of the system, allowing the electric drive system of new energy vehicles to respond quickly when a fault occurs, reducing the impact of the fault on vehicle operation.

[0038] Preferably, before S31, the process further includes S30, checking whether the circular queue is full; if the queue is full, terminating the current queueing process; if not full, proceeding to S31.

[0039] With this setting, the system can determine in advance whether the queue is full by checking the occupancy of the circular queue before enqueuing. Once the queue reaches its capacity limit, the system will not be able to perform new enqueuing operations, thus effectively avoiding the loss or overwriting of fault information caused by queue overflow. By performing a queue full check before enqueuing, the system can simplify the error handling logic. Once the queue is full, the system can directly end the current enqueuing process without complex error handling or data recovery operations.

[0040] Preferably, in S4, the preset dequeue process includes:

[0041] S41, check whether the head pointer points to the last position of the circular queue, if not, go to S42; if so, move the head pointer to the starting position of the circular queue, and then go to S42;

[0042] S42, obtaining the corresponding fault code and fault status according to the fault ID pointed to by the head pointer, and passing them to the CAN module for transmission;

[0043] S43, update the head pointer to point to the next position of the queue;

[0044] S44, determine whether the head pointer and the tail pointer meet, if not, return to S42 to continue dequeuing; if they meet, end dequeuing.

[0045] Such a setting can, 1. maintain the continuity of the queue. By checking whether the head pointer points to the last position of the circular queue (S41), and moving it to the starting position of the circular queue if necessary (if so), the system can ensure the continuity of the queue. This operation enables the fault information to form a closed-loop structure in the queue, which is convenient for subsequent reading and sending. At the same time, the accurate transmission of the fault information can be ensured. In step S42, the system obtains the corresponding fault code and fault status according to the fault ID pointed to by the head pointer, and passes it to the CAN module for sending. This operation ensures the accuracy and completeness of the fault information, so that the receiving end can accurately understand and respond to the fault information.

[0046] 2. It can optimize resource utilization and communication efficiency. By continuously updating the position of the head pointer (S43), the system can ensure that the fault information in the queue is sent out in an orderly manner. At the same time, by judging whether the head pointer and the tail pointer meet (S44), the system can end the dequeue process in time when the queue is empty, thereby avoiding unnecessary communication and waste of resources.

[0047] 3. It also supports real-time fault monitoring and processing. Since fault information is stored in the queue in chronological order, the system can send it in the order in which the fault occurs. This helps the receiving end to monitor and process fault information in real time, take corresponding measures in time, and reduce the impact of faults on the electric drive system of new energy vehicles.

[0048] Preferably, before S41, it also includes S40, judging whether the circular queue is empty, and if so, ending the dequeue operation; if not, going to S41.

[0049] With this setup, by checking whether the circular queue is empty before dequeuing, the system can avoid invalid read and send operations when the queue is empty. This helps reduce system resource consumption and unnecessary processing time, improving overall efficiency. Dequeuing when the queue is empty may cause system errors or abnormal behavior, such as reading invalid data or triggering exception handling logic. By preventing this from happening, the system can maintain its stability and reliability, ensuring that fault information can be delivered and processed correctly and in an orderly manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to make the purpose, technical solution and advantages of the invention more clear, the present invention will be further described in detail below with reference to the accompanying drawings, in which:

[0051] Figure 1 A flowchart of the method is shown in FIG.

[0052] Figure 2 Flow chart of method S2 in the embodiment;

[0053] Figure 3This is a flow chart of the method S3 in the embodiment;

[0054] Figure 4 Flow chart of method S4 in the embodiment. DETAILED DESCRIPTION

[0055] The following is a further detailed description through specific implementation methods:

[0056] Embodiment 1

[0057] like Figure 1 As shown, this embodiment discloses a method for sending diagnostic information of a motor controller of a new energy vehicle via CAN, comprising the following steps:

[0058] S0. Count the faults of the electric drive system detected in the current power-on cycle, and summarize the fault information of each fault into a fault queue; wherein the fault information includes a fault ID and a corresponding fault code (DTC) and a fault status (DTCStatus).

[0059] S1. Initialize the circular queue and reset the head pointer and tail pointer to the start position of the queue.

[0060] S2. Traverse the fault queue to obtain fault information of each fault therein, and filter out the to-be-sent fault information to be stored in the circular queue according to the fault status in the fault information and the preset judgment conditions.

[0061] When implementing it, Figure 2 As shown, S2 includes:

[0062] S21, traverse the fault queue and obtain the fault information of each fault therein;

[0063] S22: For a fault, detect whether status bit0 and bit3 in the fault status have changed to determine whether the fault status has been updated or changed; if so, go to S23; if not, detect the next fault;

[0064] S23, check whether the clear flag in its fault state has been set to confirm whether the fault has been processed or cleared; if the fault clear flag has been set (indicating that the fault is no longer a valid fault that needs to be paid attention to at present), remove the fault information of the fault; if the fault clear flag is not set (indicating that the fault is still valid), go to S24;

[0065] S24: The fault information of the fault is used as the fault information to be stored in the circular queue and to be sent.

[0066] In this way, by detecting whether status bit0 and bit3 in the fault status have changed, the system can accurately identify which fault status has been updated or changed. This helps the system to obtain the latest fault information in a timely manner and provide a basis for subsequent processing and decision-making. If the fault status has not changed, the system will not repeatedly send the same fault information, thereby avoiding the waste of communication resources and the processing burden of the receiving end. This helps to improve the overall efficiency and response speed of the system. In addition, the processed fault information can be managed more effectively. By checking whether the fault clearing flag is set, the system can identify which faults have been processed or cleared. For faults that have been processed, the system will remove their fault information to ensure that the circular queue only contains valid faults that currently need to be paid attention to. This helps the system to more accurately evaluate the current fault situation and make reasonable decisions. In addition, the accuracy of the fault information to be sent can also be ensured. After the above screening process, the system finally uses the qualified fault information as the fault information to be sent to be stored in the circular queue. This information contains both the latest fault status and excludes the faults that have been processed, so it has high accuracy and reliability.

[0067] S3. According to the preset queueing process, the fault information to be sent is queued into the circular queue.

[0068] In specific implementation, each fault information to be sent is queued into the circular queue in the order of the detected fault occurrence time. In this way, by queuing in the order of the fault occurrence time, the system can ensure that the earliest fault information is processed and sent first. This helps the receiving end to obtain the most important fault information in time, so as to respond quickly. In addition, the sequential queuing method ensures the orderliness of the fault information in the circular queue. This avoids processing confusion and omissions caused by information confusion, and ensures the integrity and accuracy of the fault information. Sequential queuing also means that the system can use the resources of the circular queue more efficiently. Since the fault information is arranged in chronological order, the system can quickly locate specific fault information when needed without additional search or sorting operations. In addition, this orderliness also helps to optimize the efficiency and reliability of CAN communication. It also supports fault tracking and analysis. The fault information queued in sequence facilitates subsequent fault tracking and analysis. By viewing the fault information in the circular queue, technicians can clearly understand the order and time point of the fault occurrence, so as to more accurately determine the cause and impact of the fault.

[0069] When implementing it, Figure 3 As shown, S3 includes:

[0070] S30, check whether the circular queue is full; if the queue is full, then (no new queue entry operation can be performed) end the current queue entry process; if not full, go to S31;

[0071] S31, determine whether the queue tail pointer position points to the last position of the circular queue; if so, go to S32; if not, go to S33;

[0072] S32, move the tail pointer back to the starting position of the queue, and then go to S33;

[0073] S33, storing the fault information to be sent currently to the queue position pointed to by the tail pointer;

[0074] S34. After successfully storing the fault information to be sent, update the position of the tail pointer to point to the next free position in the queue to prepare for the subsequent queue entry operation.

[0075] In this way, by checking the occupancy of the circular queue before enqueuing, the system can determine in advance whether the queue is full. Once the queue reaches its capacity limit, the system will not be able to perform new enqueuing operations, thus effectively avoiding the loss or overwriting of fault information caused by queue overflow. By performing a queue full check before enqueuing, the system can simplify the error handling logic. Once the queue is full, the system can directly end the current enqueuing process without complex error handling or data recovery operations.

[0076] Queue overflow can also be avoided. By judging whether the position of the queue tail pointer points to the last position of the circular queue (S31), the system can take timely measures when the queue is about to be full to prevent the queue from overflowing due to the inability to store new fault information. This is an important advantage of the circular queue over the linear queue. It allows the queue to overwrite old data from the beginning when it is full, thereby achieving effective utilization of resources. The continuity of the queue can also be maintained. When the tail pointer points to the last position of the queue (S32), the system moves it back to the starting position of the queue and continues to store new fault information (S33). This operation ensures the continuity of the queue, so that the fault information forms a ring structure in the queue, which is convenient for subsequent reading and processing. The orderliness of the fault information can also be ensured. After each successful storage of the fault information to be sent (S33), the system will update the position of the tail pointer (S34) to point to the next free position in the queue. This operation ensures that the fault information is arranged in chronological order in the queue, which facilitates subsequent reading and fault analysis. Through the above-mentioned enqueue process, the system can efficiently manage the circular queue and ensure that the fault information can be stored and transmitted in a timely and accurate manner. This helps improve the overall efficiency and response speed of the system, allowing the electric drive system of new energy vehicles to respond quickly when a failure occurs, reducing the impact of the failure on vehicle operation.

[0077] S4. According to the preset dequeuing process, the fault information to be sent in the dequeuing circular queue is dequeued and sent through the CAN module.

[0078] When implementing it, Figure 4 As shown, S4 includes:

[0079] S40, determine whether the circular queue is empty, if it is empty, end the dequeue operation; if it is not empty, go to S41;

[0080] S41, check whether the head pointer points to the last position of the circular queue, if not, go to S42; if so, move the head pointer to the starting position of the circular queue, and then go to S42;

[0081] S42, obtaining the corresponding fault code and fault status according to the fault ID pointed to by the head pointer, and passing them to the CAN module for transmission;

[0082] S43, update the head pointer to point to the next position of the queue;

[0083] S44, determine whether the head pointer and the tail pointer meet, if not, return to S42 to continue dequeuing; if they meet, end dequeuing.

[0084] In this way, by checking whether the circular queue is empty before dequeuing, the system can avoid invalid read and send operations when the queue is empty. This helps reduce system resource consumption and unnecessary processing time, improving overall efficiency. Dequeuing when the queue is empty may cause system errors or abnormal behavior, such as reading invalid data or triggering exception handling logic. By preventing this from happening, the system can maintain its stability and reliability, ensuring that fault information can be delivered and processed correctly and in an orderly manner.

[0085] By checking whether the head pointer points to the last position of the circular queue (S41), and moving it to the starting position of the circular queue if necessary (if it does), the system can ensure the continuity of the queue. This operation forms a closed-loop structure for the fault information in the queue, which is convenient for subsequent reading and sending. At the same time, the accurate transmission of the fault information can be ensured. In step S42, the system obtains the corresponding fault code and fault status according to the fault ID pointed to by the head pointer, and passes it to the CAN module for transmission. This operation ensures the accuracy and completeness of the fault information, so that the receiving end can accurately understand and respond to the fault information. It can also optimize resource utilization and communication efficiency. By continuously updating the position of the head pointer (S43), the system can ensure that the fault information in the queue is sent out in an orderly manner. At the same time, by judging whether the head pointer and the tail pointer meet (S44), the system can end the dequeue process in time when the queue is empty, thereby avoiding unnecessary communication and resource waste. In addition, real-time fault monitoring and processing are also supported. Since the fault information is stored in the queue in chronological order, the system can send it in the order in which the fault occurs. This helps the receiving end to monitor and process fault information in real time, take corresponding measures in time, and reduce the impact of faults on the electric drive system of new energy vehicles.

[0086] In this method, by counting the electric drive system faults detected in the current power-on cycle and summarizing the fault information into the fault queue, centralized management of fault information is achieved. This helps to uniformly analyze and process the faults in the future. At the same time, the circular queue is initialized, and the head pointer and tail pointer are used to perform queue operations to ensure the effective use of queue resources. The characteristics of the circular queue enable old data to be overwritten from the head of the queue when the queue is full, thereby avoiding the problem of queue overflow. In addition, in this method, the fault queue is traversed, and the fault information to be sent is filtered out according to the fault state combined with the preset judgment conditions. This step ensures that only important or urgent fault information will be sent to the CAN bus, avoiding information redundancy and waste of communication resources. In addition, through the preset queue entry and exit process, the orderly storage and transmission of the fault information to be sent in the circular queue is achieved. This ensures that the fault information can be processed and transmitted in a certain order, which helps the receiving end to understand and respond to the fault information.

[0087] This method can read the corresponding fault information immediately when a fault occurs in the electric drive system of a new energy vehicle, and solve the problem in time, so as to achieve rapid identification of vehicle faults, timely warning and effective maintenance.

[0088] Embodiment 2

[0089] For better understanding, an application example is used to illustrate.

[0090] The vehicle remote diagnosis system should define a unified diagnostic information sending rule: the controller detects a fault in the current power-on cycle. The controller detects a fault in the current power-on cycle, and bit 0 in DTC Status changes from 0 to 1, and bit 3 is 1; the controller detects that the fault disappears in the current power-on cycle, and bit 0 in DTC Status changes from 1 to 0, and bit 3 is 1. The fault status (DTC Status) is defined as shown in Table 1; the fault does not need to be sent if it is cleared by the driving cycle or the diagnostic instrument.

[0091] Table 1 defines DTC status

[0092]

[0093] When the above conditions are met, when a fault occurs or disappears, the controller only sends the corresponding fault message once and does not send it repeatedly.

[0094] When no new fault code (DTC) is generated and the status of the existing fault code (DTC Status) has not changed, the 8 bytes of the data field in the controller fault message are filled with 0x0. When only one fault code (DTC) and its fault status (DTC Status) need to be uploaded, only the 4 bytes related to DTC1 are used in the fault message, and the 4 bytes related to DTC2 are filled with 0x0. If the number of fault codes that the controller needs to send is greater than 2, the remaining fault codes (DTC) and fault status (DTC Status) are sent in subsequent cycles according to the following rules:

[0095] 1) Send the corresponding fault code (DTC) and fault status (DTCStatus) in the order in which the faults occur;

[0096] 2) If multiple faults occur at the same time, the controller will define the upload order by itself;

[0097] 3) If a new fault is generated during the process of queuing uploading faults, the new fault can only be uploaded after the previous faults are uploaded.

[0098] The controller allocates a dedicated fault message on CAN (the message ID is determined by the protocol). The message is a standard frame with a period of 500ms. For the detailed content and format of the message, see the example of active uploading of fault information. The example of active uploading of fault information is shown in Table 2:

[0099] Table 2 Diagnostic message format

[0100]

[0101] Among them, DTCHighByte, DTCMiddleByte, and DTCLowByte represent the fault diagnostic code in service; StatusOfDTC represents the fault status.

[0102] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention rather than to limit the technical solution. Those skilled in the art should understand that those modifications or equivalent substitutions of the technical solution of the present invention that do not depart from the purpose and scope of the technical solution should be included in the scope of the claims of the present invention.

Claims

1. A method for sending diagnostic information of a motor controller of a new energy vehicle via CAN, characterized in that: The following steps are involved: S0. Counting the faults of the electric drive system detected in the current power-on cycle, and summarizing the fault information of each fault into a fault queue; wherein the fault information includes a fault ID and a corresponding fault code and fault status; S1, initialize the circular queue and reset the head pointer and tail pointer to the start position of the queue; S2, traverse the fault queue, obtain the fault information of each fault therein, and filter out the to-be-sent fault information to be stored in the circular queue according to the fault status in the fault information and the preset judgment conditions; S3, according to the preset queueing process, the fault information to be sent is queued into the circular queue; S4. According to the preset dequeuing process, the fault information to be sent in the dequeuing circular queue is dequeued and sent through the CAN module.

2. The method for sending diagnostic information of a motor controller of a new energy vehicle via CAN according to claim 1, characterized in that: S2 includes: S21, traverse the fault queue and obtain the fault information of each fault therein; S22: For a fault, detect whether status bit0 and bit3 in the fault status have changed to determine whether the fault status has been updated or changed; if so, go to S23; if not, detect the next fault; S23, checking whether the clear flag in the fault state has been set to confirm whether the fault has been processed or cleared; if the fault clear flag has been set, removing the fault information of the fault; If the fault clearing flag is not set, go to S24; S24: The fault information of the fault is used as the fault information to be stored in the circular queue and to be sent.

3. The method for sending diagnostic information of a motor controller of a new energy vehicle via CAN according to claim 1, characterized in that: In S3, the default queue entry process includes: S31, determine whether the queue tail pointer position points to the last position of the circular queue; if so, go to S32; if not, go to S33; S32, move the tail pointer back to the starting position of the queue, and then go to S33; S33, storing the fault information to be sent currently to the queue position pointed to by the tail pointer; S34. After successfully storing the fault information to be sent, update the position of the tail pointer to point to the next free position in the queue to prepare for the subsequent queue entry operation.

4. The method for sending diagnostic information of a motor controller of a new energy vehicle via CAN as claimed in claim 3, characterized in that: Before S31, it also includes S30, checking whether the circular queue is full; if the queue is full, the current queue entry process is terminated; If not full, go to S31.

5. The method for sending diagnostic information of a motor controller of a new energy vehicle via CAN as claimed in claim 4, characterized in that: In S3, each piece of fault information to be sent is queued into a circular queue in sequence according to the order of the detected fault occurrence time.

6. The method for sending diagnostic information of a motor controller of a new energy vehicle via CAN according to claim 1, characterized in that: In S4, the default dequeue process includes: S41, check whether the head pointer points to the last position of the circular queue, if not, go to S42; if so, move the head pointer to the starting position of the circular queue, and then go to S42; S42, obtaining the corresponding fault code and fault status according to the fault ID pointed to by the head pointer, and passing them to the CAN module for transmission; S43, update the head pointer to point to the next position of the queue; S44, determine whether the head pointer and the tail pointer meet, if not, return to S42 to continue dequeuing; if they meet, end dequeuing.

7. The method for sending diagnostic information of a motor controller of a new energy vehicle via CAN as claimed in claim 6, characterized in that: Before S41, it also includes S40, judging whether the circular queue is empty, if it is empty, ending the dequeue operation; if it is not empty, going to S41.

Images