Operation state monitoring method for vehicle motor controller

Abstract

The invention relates to the field of automobile electronic control, in particular to a running state monitoring method for a vehicle motor controller, which comprises the following steps: S0, determining a key running signal needing to be continuously monitored; the communication format of the key operation signal on a vehicle-mounted CAN bus is defined; the method comprises the following steps: S1, constructing and deploying an embedded operation event recording system in a motor controller; s2, after the motor controller is powered on and runs, the embedded running event recording system constructed in the S1 is started, and recording of the running event is completed; s3, continuously monitoring and accumulating the power-off dormancy times of the motor controller through the storage aging management module; and executing an erasing operation on the special storage block. According to the method, reliable storage and on-demand return of key event data can be realized on the premise of not depending on an external debugging interface and not increasing significant hardware cost, so that effective monitoring of the working state of the motor controller is realized.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic control, and more particularly to a method for monitoring the operating status of a vehicle motor controller. Background Technology

[0002] With the rapid development of new energy vehicles and intelligent driving technologies, automotive electronic control systems are becoming increasingly complex. The Electronic Control Unit (ECU) of a vehicle is becoming more and more reliant on software, placing higher demands on the reliability and safety of electric drive systems. As a core component of the electric drive system, the motor controller directly determines the vehicle's power output, energy efficiency management, and operational safety. It integrates a large number of high-precision sensors, power semiconductor devices, and complex control algorithms, resulting in a massive amount of software code and highly coupled operational logic. Any anomaly can not only lead to power interruption and performance degradation but may even jeopardize driving safety.

[0003] However, in practical engineering applications, motor controllers are typically enclosed in sealed cast iron housings with limited physical interfaces. Furthermore, due to cost, space, or information security considerations, many mass-produced vehicles have eliminated traditional online calibration and data acquisition functions such as XCP (Universal Measurement and Calibration Protocol). This makes it difficult for engineers to obtain critical operational status data before and after the fault through conventional methods if the motor controller experiences intermittent faults (such as transient overvoltage, overcurrent, or underlying hardware interruptions) during vehicle operation. Even when reading some diagnostic information via the vehicle's CAN bus, it is often limited to the fault codes (DTCs) themselves, lacking the original signal sequences that are temporally continuous and multi-dimensionally correlated, making fault reproduction, root cause analysis, and iterative software optimization extremely difficult.

[0004] Therefore, how to achieve reliable storage and on-demand transmission of key event data without relying on external debugging interfaces or increasing significant hardware costs, thereby enabling effective monitoring of the motor controller's operating status, has become an urgent problem to be solved. Summary of the Invention

[0005] To address the aforementioned shortcomings of existing technologies, the present invention aims to provide a method for monitoring the operational status of a vehicle motor controller. This method enables reliable storage and on-demand transmission of key event data without relying on external debugging interfaces or incurring significant hardware costs, thereby achieving effective monitoring of the motor controller's operational status.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0007] A method for monitoring the operating status of a vehicle motor controller includes the following steps:

[0008] S0. Determine the key operating signals that need to be continuously monitored; the key operating signals include electrical status quantities related to motor control, fault flag bits, and INTBL or INTBH in the underlying abnormal interrupt signals; and define the communication format of the key operating signals on the vehicle CAN bus.

[0009] S1. Based on the key operating signals and defined communication format determined in S0, an embedded operating event recording system is built and deployed inside the motor controller. The system includes the following functional modules:

[0010] The signal acquisition module is configured to acquire the key operating signals determined in S0 at a preset period.

[0011] The event triggering module is configured to monitor preset fault event conditions in real time and generate an event triggering signal when any fault event among overvoltage, overcurrent, or INTBL / INTBH abnormality is detected.

[0012] The dual-mode cache management module is configured to: write the key operation signal into the circular buffer in the random access memory (RAM) when no event trigger signal is received, and perform rolling over cache; after receiving the event trigger signal, immediately freeze the current circular buffer and extract time series data containing the first preset time window before the fault occurs and the second preset time window after the fault occurs from it;

[0013] The non-volatile storage module is configured to write the time-series data extracted by the dual-mode cache management module into a pre-allocated dedicated storage block in the non-volatile memory inside the motor controller;

[0014] The communication feedback module is configured to respond to data read requests sent by external diagnostic devices via the CAN bus and send the data in the dedicated storage block via the CAN bus according to the communication format defined by S0.

[0015] The storage aging management module is configured to record the cumulative number of times the motor controller enters the power-off sleep state and determine whether the cumulative number has reached the preset clearing threshold.

[0016] S2. After the motor controller is powered on and running, the embedded operation event recording system built in S1 is started and the following operations are performed continuously: the key operation signals are periodically acquired through the signal acquisition module; the event triggering module determines in real time whether a fault event has occurred; if no fault event has occurred, the dual-mode cache management module maintains rolling over the cache; if a fault event has occurred, the dual-mode cache management module extracts the time series data, and the non-volatile storage module writes the data into the dedicated storage block to complete the recording of one operation event.

[0017] S3. The storage aging management module continuously monitors and accumulates the number of times the motor controller goes into sleep mode after power-down. When the accumulated number of sleep mode times reaches the preset clearing threshold, it is determined that the conditions for automatic data clearing are met. The storage aging management module then controls the non-volatile storage module to perform an erase operation on the dedicated storage block.

[0018] Compared with the prior art, the present invention has the following advantages:

[0019] 1. The overall architecture is highly integrated, requiring no additional hardware support. All functional modules are deployed on the existing hardware resources within the motor controller, without introducing additional sensors or independent recording units. Compared to solutions that rely on external recording devices or upgrade the main control chip, this method achieves a high level of operational status monitoring capabilities without significantly increasing hardware costs.

[0020] 2. Automatic capture of contextual data before and after a fault. Through a dual-mode cache management mechanism, critical signals are stored using a circular buffer during normal operation, saving memory resources. Once a pre-defined fault event such as overvoltage, overcurrent, or low-level interrupt anomaly (e.g., INTBL / INTBH) is detected, the cache is immediately frozen, and complete time-series data containing the time windows before and after the fault is extracted. This preserves the dynamic behavior during the fault evolution process, significantly improving the accuracy and traceability of fault diagnosis.

[0021] 3. Supports efficient data storage and management in embedded environments. Extracted key event data is written to a dedicated block of the controller's internal non-volatile memory, avoiding reliance on external storage devices or vehicle gateways, thus reducing system complexity and communication latency. Simultaneously, through a storage aging management module, data erasure is automatically determined and performed based on the number of power-down sleep cycles, effectively mitigating the lifespan degradation problem caused by frequent writes to non-volatile memory and solving the challenge of long-term stable operation of traditional log systems in resource-constrained embedded platforms.

[0022] 4. Compatible with the vehicle CAN bus standard, enabling standardized transmission of diagnostic data. All critical operating signals are encapsulated according to a predefined CAN communication format. The communication transmission module can respond to requests from external diagnostic equipment and directly upload historical event data via the vehicle CAN bus. Compared to traditional methods that require dedicated debugging interfaces or physical disassembly of the controller to obtain data, this solution requires no additional hardware support, facilitating after-sales diagnostics, remote analysis, and OTA iterative optimization.

[0023] 5. Lightweight deployment, suitable for mass-produced motor controllers. The entire operation event recording system is integrated into the internal software architecture of the motor controller, utilizing only existing RAM and non-volatile storage resources, without introducing additional sensors or communication modules. Even with the removal of limitations such as the XCP function and the enclosed cast iron casing, it can still achieve autonomous recording and backtracking of high-value operating data, demonstrating good engineering applicability and mass production feasibility.

[0024] In summary, this method can reliably store and transmit critical event data on demand without relying on external debugging interfaces or increasing significant hardware costs, thereby enabling effective monitoring of the motor controller's operating status.

[0025] Preferably, in S0, the key operating signals that need to be continuously monitored are determined based on the functional safety requirements and typical failure mode analysis of the motor controller.

[0026] This approach, by combining functional safety requirements and typical failure mode analysis, scientifically selects key operational signals to be monitored in the S0 stage, avoiding the blind collection of redundant data. Compared to general monitoring solutions that rely solely on experience or full data collection, this method ensures that the recorded signals are highly correlated with safety-critical faults, significantly enhancing the reliability of subsequent fault diagnosis and safety mechanism response.

[0027] Preferably, the key operating signals include the high-voltage DC bus voltage, three-phase stator current, motor speed and rotor position, power semiconductor device temperature, internal power supply status, fault flag bit, and INTBL or INTBH in the underlying abnormal interruption signal.

[0028] This setup achieves comprehensive coverage of the motor controller's multi-dimensional key states. The selected key operating signals encompass multiple dimensions, including electrical (high-voltage DC bus voltage, three-phase stator current), mechanical (motor speed and rotor position), thermal management (power semiconductor device temperature), power integrity (internal power supply status), logic faults (fault flags), and underlying hardware anomalies (INTBL / INTBH). Compared to existing solutions that only monitor a single type of signal (such as only current or only fault codes), this combination can more completely reflect the system's true operating status under complex conditions, significantly improving the breadth and depth of anomaly detection.

[0029] 2. Enhanced collaborative identification capabilities for early potential faults and sudden low-level anomalies. By simultaneously collecting high-level control variables (such as speed and current) and low-level interrupt signals (such as INTBL / INTBH), the system can establish correlation analysis between software logic anomalies and hardware-level interrupt events. For example, when a processor anomaly or peripheral communication failure occurs that is not captured by upper-level fault flags, INTBL / INTBH can still trigger recording, avoiding missed detections of "silent failures." This cross-level signal fusion mechanism compensates for the blind spots in the perception of low-level anomalies in traditional monitoring methods.

[0030] Preferably, the internal non-volatile memory is the program flash memory inside the main control chip of the motor controller.

[0031] This setup effectively utilizes existing hardware resources, avoiding the introduction of additional storage devices. Event data is stored directly in the program flash memory inside the main control chip, fully leveraging its existing non-volatile storage capabilities without the need for external EEPROM or a separate Flash chip. Compared to traditional solutions that rely on external memory, this approach not only saves board space and material costs but also reduces reliability risks associated with external interface communication (such as signal interference and connection failures), while simplifying hardware design and manufacturing processes.

[0032] 2. Improve data storage security and access efficiency. Program flash memory typically resides on the internal bus of the main controller chip, offering high access bandwidth and controlled erase / write mechanisms. Allocating dedicated storage blocks in this area allows for direct management by the main controller firmware, avoiding the transmission of sensitive operational data via the external bus and reducing the risk of tampering or interception. Furthermore, it enables rapid hardening of critical data after a fault is triggered, minimizing the probability of data loss due to system resets or power outages.

[0033] Preferably, the dedicated storage block is a non-volatile storage block that is partitioned in the program flash memory by a configuration tool and is dedicated to storing time-series data covering the time window before and after the time of the fault occurrence.

[0034] This setup, firstly, explicitly allocates dedicated storage blocks in the program's flash memory using configuration tools, ensuring that these blocks are used solely to store critical time-series data within the time window before and after a failure, thus avoiding co-storage with application code, parameter calibration, and other data. Compared to static allocation or data storage methods without clear boundaries, this approach not only prevents event data from being accidentally overwritten by firmware updates or normal write operations but also supports adjusting the size or location of storage blocks through standard configuration procedures during development or after-sales phases, improving system maintainability and adaptability.

[0035] 2. The independence and specific purpose of the dedicated storage blocks ensure the physical and logical isolation of fault log data within the non-volatile memory. Even after main control program malfunctions or multiple power cycles, the data in this area remains stable, facilitating accurate backtracking of fault scenarios using diagnostic tools. Compared to embedding event logs into a general log area or shared cache, this significantly enhances the reliability and forensic value of the data.

[0036] Preferably, the duration of the first preset time window before the fault occurs is longer than the duration of the second preset time window after the fault occurs.

[0037] With this setup, 1) the operating state before a fault occurs is often the root cause of the anomaly (such as slow voltage rise, current fluctuation, temperature accumulation, etc.), while data after the fault occurs is mainly used to confirm the response behavior. By setting the first preset time window to be longer than the second preset time window, the system can capture more complete fault precursor information. Compared with traditional recording strategies that have equal window lengths or focus on post-event data, this significantly improves the ability to trace potential causes.

[0038] 2. Given limited non-volatile storage space, more capacity is allocated to data prior to the failure, avoiding redundant recording of large amounts of known states (such as the controller entering protective shutdown) after a failure has occurred. This asymmetric time window design better suits the actual needs of engineering diagnostics, increasing the information value density of the stored data without increasing storage overhead.

[0039] Preferably, the first preset time window is 300 milliseconds to 800 milliseconds, and the second preset time window is 100 milliseconds to 400 milliseconds.

[0040] This setup achieves the following: 1. Quasi-matching of the dynamic response characteristics of the motor control system. Typical electrical and control processes of a motor controller (such as current loop regulation, fault detection delay, and power device thermal accumulation) typically evolve within hundreds of milliseconds. Setting the pre-fault window to 300–800 milliseconds is sufficient to cover the development process of most gradual anomalies (such as bus voltage overshoot and phase current imbalance); while the post-fault window of 100–400 milliseconds can fully record the execution results of protection actions (such as PWM shutdown and fault latching). Compared to fixed or excessively short time windows, this range better matches the physical and logical timing of the actual control system, ensuring that critical dynamic processes are not truncated.

[0041] 2. The time window range ensures sufficient contextual information is captured while avoiding the over-collection of redundant data. For example, if the pre-fault window is too long (e.g., several seconds), it may contain a large amount of irrelevant steady-state data; if it is too short (e.g., tens of milliseconds), it may miss the cause of the fault. The combination of 300–800 ms and 100–400 ms generates a moderate amount of data at typical sampling frequencies (e.g., 1–10 kHz), which meets the needs of in-depth analysis while adapting to the limited non-volatile storage resources of embedded systems.

[0042] Preferably, the communication backhaul module is configured to respond to data read requests from the Unified Diagnostic Service (UDS) protocol and backhaul the stored time-series data.

[0043] This setup, by employing the Unified Diagnostic Service (UDS) protocol as the data reading interface, enables seamless integration of event data feedback into the existing vehicle diagnostic system. Compared to traditional solutions that rely on proprietary protocols or custom communication formats, this design allows OEMs, aftermarket equipment providers, or third-party diagnostic tools to directly access fault time-series data through the standard UDS service without modifying hardware or adding dedicated drivers, significantly lowering the barrier to system integration and maintenance.

[0044] Preferably, the storage aging management module only determines that the clearing condition is met after confirming that the time-series data in the dedicated storage block has been successfully read.

[0045] This setup, by introducing "read confirmation" as the clearing trigger condition, ensures the sustainable use of storage resources while preserving high-value fault information to the greatest extent, achieving synergistic optimization of reliability, maintainability, and resource management.

[0046] Preferably, the dedicated storage block is provided with a status flag bit to indicate whether the time series data has been successfully read.

[0047] This setup, by setting a status flag in the dedicated storage block, clearly indicates whether the corresponding time-series data has been successfully read by external diagnostic equipment. This mechanism provides the storage aging management module with an accurate basis for judgment, avoiding premature data deletion due to communication interruptions, incomplete diagnostic processes, or misjudgments. Compared to schemes without status flags, it significantly improves the determinism and robustness of data management.

[0048] 2. The status flag is directly embedded in a dedicated storage block, eliminating the need for additional storage areas or complex log systems. The read status can be updated with a single write operation. This design achieves efficient status synchronization in resource-constrained embedded environments and seamlessly integrates with the UDS read process (e.g., setting the flag after data return is complete), making the entire "record-read-clear" logic simple, reliable, and easy to verify. Attached Figure Description

[0049] To make the objectives, technical solutions, and advantages of the invention clearer, the invention will now be described in further detail with reference to the accompanying drawings, wherein:

[0050] Figure 1 This is a flowchart of the method. Detailed Implementation

[0051] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0052] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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 a part of the embodiments of the present invention, not all of them. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to represent selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0053] It should be noted that similar reference numerals and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the figures, or the orientation or positional relationship commonly used when the product is in use. They are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance. In addition, the terms "horizontal," "vertical," etc., do not indicate that the component is required to be absolutely horizontal or suspended, but can be slightly tilted. For example, "horizontal" simply means that its direction is more horizontal than "vertical," and does not mean that the structure must be completely horizontal, but can be slightly tilted. In the description of this invention, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0054] Example:

[0055] like Figure 1 As shown, the present invention provides a method for monitoring the operating status of a vehicle motor controller, comprising the following steps:

[0056] S0. Identify the key operating signals that need to be continuously monitored; the key operating signals include electrical status quantities related to motor control, fault flag bits, and INTBL or INTBH in the underlying abnormal interrupt signals; and define the communication format of the key operating signals on the vehicle CAN bus. In specific implementation, a database description file (Database CAN, abbreviated as DBC) can be created to define the communication format of the key operating signals on the vehicle CAN bus.

[0057] In practical implementation, based on the functional safety requirements and typical failure mode analysis of the motor controller, key operating signals requiring continuous monitoring are identified. By combining functional safety requirements and typical failure mode analysis, key operating signals to be monitored are scientifically selected in the S0 stage, avoiding the blind collection of redundant data. Compared to general monitoring schemes that rely solely on experience or full data collection, this method ensures that the recorded signals are highly correlated with safety-critical faults, significantly enhancing the reliability of subsequent fault diagnosis and safety mechanism response.

[0058] In practical implementation, the key operating signals include the high-voltage DC bus voltage, three-phase stator current, motor speed and rotor position, power semiconductor device temperature, internal power supply status, fault flag bits, and the INTBL or INTBH interrupt signals in the underlying abnormal interrupt signals. The high-voltage DC bus voltage comes from the bus voltage sensor ADC channel; the rotor position comes from the resolver decoding module; and the INTBL / INTBH interrupts come from the MCU core's NMI or specific peripheral error interrupts. These signals reflect functional safety requirements and typical failure modes. For example: over-temperature → power device failure; power supply abnormality → MCU reset.

[0059] In this way, the selected key operating signals cover multiple dimensions, including electrical (high-voltage DC bus voltage, three-phase stator current), mechanical (motor speed and rotor position), thermal management (power semiconductor device temperature), power integrity (internal power supply status), logic faults (fault flag bits), and low-level hardware anomalies (INTBL / INTBH). Compared to existing solutions that only monitor a single type of signal (such as only current or only fault codes), this combination can more comprehensively reflect the actual operating status of the system under complex conditions, significantly improving the breadth and depth of anomaly detection. Furthermore, by simultaneously acquiring high-level control variables (such as speed and current) and low-level interrupt signals (such as INTBL / INTBH), the system can establish correlation analysis between software logic anomalies and hardware-level interrupt events. For example, when a processor anomaly or peripheral communication failure occurs that is not captured by the upper-level fault flags, INTBL / INTBH can still trigger recording, avoiding missed "silent failures." This cross-level signal fusion mechanism compensates for the blind spots of traditional monitoring methods in the perception of low-level anomalies.

[0060] S1. Based on the key operating signals and defined communication formats determined in S0, an embedded operating event recording system is built and deployed inside the motor controller. The system includes a signal acquisition module, an event triggering module, a dual-mode buffer management module, a non-volatile storage module, a communication feedback module, and a storage aging management module.

[0061] The signal acquisition module is configured to acquire the key operating signals determined in S0 at a preset period. In specific implementation, the specific value of the signal acquisition period can be set by those skilled in the art according to actual needs (such as 100μs or 1 kHz), which will not be elaborated here.

[0062] The event triggering module is configured to monitor preset fault event conditions in real time and generate an event triggering signal when any fault event among overvoltage, overcurrent, or INTBL / INTBH abnormality is detected.

[0063] The dual-mode cache management module is configured to: write the key operation signal into the circular buffer in the random access memory (RAM) when no event trigger signal is received, and perform rolling over cache; after receiving the event trigger signal, immediately freeze the current circular buffer and extract time series data containing the first preset time window before the fault occurs and the second preset time window after the fault occurs.

[0064] To facilitate better understanding, the following example demonstrates how to calculate the size of a circular buffer:

[0065] For example, to support an 800ms front window + 400ms back window at a 1kHz sampling rate, 1200 data points need to be buffered. Each signal occupies 4 bytes, and there are a total of N signals. Therefore, the RAM buffer size is N×4×1200 bytes.

[0066] Regarding the specific implementation of the "freeze" operation: Upon receiving the event trigger signal, the dual-mode cache management module immediately stops writing new data to the circular buffer and records the current write pointer position as the moment the fault occurred.

[0067] Front and back window extraction logic: Extract continuous data from the starting point of the front window (write pointer - front window length) to the ending point of the back window (write pointer + back window length).

[0068] The non-volatile storage module is configured to write the time-series data extracted by the dual-mode cache management module into a pre-allocated dedicated storage block in the non-volatile memory inside the motor controller;

[0069] The communication feedback module is configured to respond to data read requests sent by external diagnostic devices via the CAN bus and send the data in the dedicated storage block via the CAN bus according to the communication format defined in S0.

[0070] In practice, the communication backhaul module is configured to respond to data read requests from the Unified Diagnostic Service (UDS) protocol and return the stored time-series data. For better understanding, the specific service and format of "UDS protocol backhaul" are illustrated below with examples.

[0071] UDS Service ID: When an external diagnostic device sends a UDS 0x22 (ReadDataByIdentifier) ​​request, the DID (DataIdentifier) ​​is 0xF190, which corresponds to the fault event record data.

[0072] Data Packaging Method: The communication feedback module encapsulates the time series data into multiple CAN messages and sends them according to the CAN communication format defined by S0 (e.g., 8 bytes per frame, signal A occupies Byte0–1, signal B occupies Byte2, etc.).

[0073] Explanation of the relationship with DBC: The communication format is consistent with the DBC file, but the DBC is only used for parsing by the host computer; the controller internally uses a hard-coded mapping table. The DBC file is generated and burned to the diagnostic host computer before the motor controller is deployed, and is used to parse the returned raw CAN data; the motor controller internally uses a predefined signal mapping table to package the data, and does not require runtime parsing of the DBC.

[0074] By adopting the Unified Diagnostic Service (UDS) protocol as the data reading interface, event data feedback can be seamlessly integrated into the existing vehicle diagnostic system. Compared to traditional solutions that rely on proprietary protocols or custom communication formats, this design allows OEMs, aftermarket equipment providers, or third-party diagnostic tools to directly access fault time-series data through the standard UDS service without modifying hardware or adding dedicated drivers, significantly reducing the barriers to system integration and maintenance.

[0075] The storage aging management module is configured to record the cumulative number of times the motor controller enters a power-down sleep state and determine whether the cumulative number has reached a preset clearing threshold. In specific implementation, the storage aging management module only determines that the clearing condition is met after confirming that the time-series data in the dedicated storage block has been successfully read. The dedicated storage block has a status flag bit to indicate whether the time-series data has been successfully read.

[0076] To facilitate better understanding, the implementation of "read confirmation" and "status flag" is illustrated with the following examples.

[0077] Successful read determination criteria: When the communication feedback module completes the transmission of all time series data and receives a positive response from the diagnostic device (such as UDS 0x62), it is determined as 'successful read'.

[0078] Position and operation of status flags: 4 bytes are reserved in the header of the dedicated storage block as metadata area, where Bit0 is the 'read flag'; after successful reading, this bit is set to 1.

[0079] The complete logic for the erasure condition is as follows: The storage aging management module only triggers the erase operation when the following conditions are met simultaneously: (a) the cumulative number of sleep cycles is greater than or equal to the threshold (e.g., 100 times); and (b) the status flag is 1.

[0080] The following example illustrates the implementation of "accumulated power-down sleep count".

[0081] Counter storage location: The sleep count counter is stored in the MCU backup register or a dedicated Flash area and is not lost when power is off.

[0082] Counting trigger timing: The counter increments by 1 each time the power management module is detected to enter a low-power sleep mode (such as Standby Mode).

[0083] By introducing "read confirmation" as the trigger condition for data clearing, the system ensures the sustainable use of storage resources while preserving high-value fault information to the greatest extent possible, achieving synergistic optimization of reliability, maintainability, and resource management. Setting a status flag in the dedicated storage block clearly indicates whether the corresponding time-series data has been successfully read by external diagnostic devices. This mechanism provides an accurate basis for judgment for the storage aging management module, avoiding premature data clearing due to communication interruptions, incomplete diagnostic processes, or misjudgments. Compared to schemes without status flags, this significantly improves the determinism and robustness of data management. Furthermore, the status flag is directly embedded in the dedicated storage block, eliminating the need for additional storage areas or complex log systems; the read status is updated with a single write operation. This design achieves efficient status synchronization in resource-constrained embedded environments and seamlessly integrates with the UDS read process (e.g., setting the flag after data return is complete), making the entire "record-read-clear" logic simple, reliable, and easy to verify.

[0084] In specific implementation, the internal non-volatile memory is the program flash memory inside the motor controller's main control chip. The dedicated storage block is a non-volatile storage block partitioned in the program flash memory by a configuration tool, specifically used to store time-series data covering the time window before and after the fault occurrence.

[0085] To facilitate understanding, the following example illustrates the partitioning and access of "dedicated storage blocks" in PFlash.

[0086] Configuration tool example: Using AUTOSAR DaVinci Configurator or the Flash partitioning tool provided by the chip manufacturer, reserve the address space 0x0008_0000–0x0008_2000 as a dedicated storage block in the linker script.

[0087] Write mechanism: The non-volatile storage module calls the MCU Flash driver API (such as Flash_Write()) to write the time series data into a dedicated block in pages, and performs an erase operation before each write.

[0088] Durability description: The program flash memory supports at least 100,000 erase and write cycles to meet the needs of recording occasional faults throughout the vehicle's lifespan.

[0089] By storing event data directly in the program flash memory within the main control chip, its existing non-volatile storage capabilities are fully utilized, eliminating the need for external EEPROM or independent Flash chips. Compared to traditional solutions relying on external memory, this approach not only saves board space and material costs but also reduces reliability risks associated with external interface communication (such as signal interference and connection failures), while simplifying hardware design and manufacturing processes. Furthermore, the program flash memory typically resides on the internal bus of the main control chip, offering high access bandwidth and controlled erase / write mechanisms. Allocating a dedicated storage block in this area allows for direct management by the main control firmware, avoiding the transmission of sensitive operational data via the external bus and reducing the risk of tampering or interception. Additionally, it enables rapid hardening of critical data after a fault is triggered, reducing the probability of data loss due to system resets or power outages.

[0090] By explicitly allocating dedicated storage blocks in the program's flash memory using configuration tools, these blocks are used exclusively to store critical time-series data within the time window preceding and following a failure, preventing them from being co-located with application code, parameter calibration, or other data. Compared to static allocation or data storage without clear boundaries, this method not only prevents event data from being accidentally overwritten by firmware updates or normal write operations but also allows for adjustments to the size or location of storage blocks during development or after-sales phases through standard configuration procedures, improving system maintainability and adaptability. Furthermore, the independence and specific purpose of the dedicated storage blocks ensure physical and logical isolation of fault log data within non-volatile memory. Even after main control program malfunctions or multiple power-ups and shutdowns, the data in this area remains stable, facilitating accurate backtracking of the fault scenario using diagnostic tools. Compared to embedding event logs into a general log area or shared cache, this significantly enhances the data's credibility and forensic value.

[0091] In practice, the first preset time window before the fault occurs is longer than the second preset time window after the fault occurs. The operating state before the fault often reveals the root cause of the anomaly (such as slow voltage rise, current fluctuations, temperature accumulation, etc.), while data after the fault occurs is mainly used to confirm the response behavior. By setting the first preset time window longer than the second preset time window, the system can capture more complete information about the precursors of the fault. Compared with traditional recording strategies that have equal window lengths or focus on post-fault data, this significantly improves the ability to trace potential causes. In addition, given the limited non-volatile storage space, more capacity is allocated to data before the fault, avoiding redundant recording of a large number of known states after the fault has occurred (such as the controller entering a protective shutdown). This asymmetric time window design better meets the actual needs of engineering diagnostics, increasing the information value density of the stored data without increasing storage overhead.

[0092] The first preset time window is 300 to 800 milliseconds, and the second preset time window is 100 to 400 milliseconds. Typical electrical and control processes of a motor controller (such as current loop regulation, fault detection delay, and power device thermal accumulation) typically evolve within hundreds of milliseconds. Setting the pre-fault window to 300–800 milliseconds is sufficient to cover the development process of most gradual anomalies (such as bus voltage overshoot and phase current imbalance); while the post-fault window of 100–400 milliseconds can fully record the execution results of protection actions (such as PWM shutdown and fault latching). Compared to fixed or excessively short time windows, this range better matches the physical and logical timing of the actual control system, ensuring that critical dynamic processes are not truncated. Furthermore, the time window range ensures sufficient contextual information is captured while avoiding the over-collection of redundant data. For example, if the pre-fault window is too long (e.g., several seconds), it may contain a large amount of irrelevant steady-state data; if it is too short (e.g., tens of milliseconds), it may miss the fault trigger. The combination of 300–800 ms and 100–400 ms generates a moderate amount of data at typical sampling frequencies (such as 1–10 kHz), which satisfies the needs of in-depth analysis and is compatible with the limited non-volatile storage resources of embedded systems.

[0093] S2. After the motor controller is powered on and running, the embedded operation event recording system built in S1 is started and the following operations are performed continuously: the key operation signals are periodically acquired through the signal acquisition module; the event triggering module determines in real time whether a fault event has occurred; if no fault event has occurred, the dual-mode cache management module maintains rolling over the cache; if a fault event has occurred, the dual-mode cache management module extracts the time series data, and the non-volatile storage module writes the data into the dedicated storage block to complete the recording of one operation event.

[0094] S3. The storage aging management module continuously monitors and accumulates the number of times the motor controller goes into sleep mode after power-down. When the accumulated number of sleep mode times reaches the preset clearing threshold, it is determined that the conditions for automatic data clearing are met. The storage aging management module then controls the non-volatile storage module to perform an erase operation on the dedicated storage block.

[0095] Compared to existing technologies, all functional modules in this method are deployed on the existing hardware resources within the motor controller, without introducing additional sensors or independent recording units. Compared to solutions that rely on external recording devices or upgrade the main control chip, this method achieves a high level of operational status monitoring capabilities without significantly increasing hardware costs. Through a dual-mode cache management mechanism, key signals are stored using a circular buffer during normal operation, saving memory resources. Once a preset fault event such as overvoltage, overcurrent, or low-level interrupt anomaly (such as INTBL / INTBH) is detected, the cache is immediately frozen, and complete time-series data containing the time windows before and after the fault occurs is extracted. This preserves the dynamic behavior during the fault evolution process, significantly improving the accuracy and traceability of fault diagnosis. Furthermore, the extracted key event data is written to a dedicated block of the controller's internal non-volatile memory, avoiding reliance on external storage devices or vehicle gateway relays, reducing system complexity and communication latency. Meanwhile, the storage aging management module automatically determines and executes data erasure based on the number of power-down hibernation cycles, effectively alleviating the lifespan loss problem caused by frequent writes to non-volatile memory and solving the problem of traditional log systems being unable to run stably for a long time in resource-constrained embedded platforms.

[0096] In this method, all critical operating signals are encapsulated according to a predefined CAN communication format. The communication feedback module can respond to requests from external diagnostic equipment and directly upload historical event data via the vehicle's CAN bus. Compared to traditional methods that require dedicated debugging interfaces or physical disassembly of the controller to obtain data, this solution requires no additional hardware support, facilitating after-sales diagnostics, remote analysis, and OTA iterative optimization. Furthermore, the entire operating event recording system is integrated into the internal software architecture of the motor controller, utilizing only existing RAM and non-volatile storage resources without introducing additional sensors or communication modules. Even with the removal of limitations such as the XCP function and the enclosed cast iron casing, it can still achieve autonomous recording and backtracking of high-value operating data, demonstrating good engineering applicability and mass production feasibility.

[0097] This method can reliably store and transmit critical event data on demand without relying on external debugging interfaces or increasing significant hardware costs, thereby enabling effective monitoring of the motor controller's operating status.

[0098] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit the technical solutions. Those skilled in the art should understand that any modifications or equivalent substitutions to the technical solutions of the present invention without departing from the spirit and scope of the present invention should be covered within the scope of the claims of the present invention.

Claims

1. A method for monitoring the operating status of a vehicle motor controller, characterized in that, Includes the following steps: S0. Determine the key operating signals that need to be continuously monitored; the key operating signals include electrical status quantities related to motor control, fault flag bits, and INTBL or INTBH in the underlying abnormal interrupt signals; and define the communication format of the key operating signals on the vehicle CAN bus. S1. Based on the key operating signals and defined communication format determined in S0, an embedded operating event recording system is built and deployed inside the motor controller. The system includes the following functional modules: The signal acquisition module is configured to acquire the key operating signals determined in S0 at a preset period. The event triggering module is configured to monitor preset fault event conditions in real time and generate an event triggering signal when any fault event among overvoltage, overcurrent, or INTBL / INTBH abnormality is detected. The dual-mode cache management module is configured to: write the key operation signal into the circular buffer in the random access memory (RAM) when no event trigger signal is received, and perform rolling over cache; Upon receiving the event trigger signal, the current circular buffer is immediately frozen, and time-series data containing the first preset time window before the fault occurs and the second preset time window after the fault occurs is extracted from it. The non-volatile storage module is configured to write the time-series data extracted by the dual-mode cache management module into a pre-allocated dedicated storage block in the non-volatile memory inside the motor controller; The communication feedback module is configured to respond to data read requests sent by external diagnostic devices via the CAN bus and send the data in the dedicated storage block via the CAN bus according to the communication format defined by S0. The storage aging management module is configured to record the cumulative number of times the motor controller enters the power-off sleep state and determine whether the cumulative number has reached the preset clearing threshold. S2. After the motor controller is powered on and running, the embedded operation event recording system built in S1 is started, and the following operations are continuously performed: the key operation signals are periodically acquired through the signal acquisition module; the event triggering module determines in real time whether a fault event has occurred. If no fault event occurs, the dual-mode cache management module maintains rolling over cache; If a fault event occurs, the dual-mode cache management module extracts the time-series data, and the non-volatile storage module writes the data into the dedicated storage block to complete the recording of one running event. S3. The storage aging management module continuously monitors and accumulates the number of times the motor controller goes into sleep mode after power-down. When the accumulated number of sleep mode times reaches the preset clearing threshold, it is determined that the conditions for automatic data clearing are met. The storage aging management module then controls the non-volatile storage module to perform an erase operation on the dedicated storage block.

2. The method for monitoring the operating status of a vehicle motor controller according to claim 1, characterized in that: In S0, based on the functional safety requirements of the motor controller and the analysis of typical failure modes, the key operating signals that need to be continuously monitored are determined.

3. The method for monitoring the operating status of a vehicle motor controller according to claim 1, characterized in that: The key operating signals include the high-voltage DC bus voltage, three-phase stator current, motor speed and rotor position, power semiconductor device temperature, internal power supply status, fault flag bits, and INTBL or INTBH in the underlying abnormal interruption signals.

4. The method for monitoring the operating status of a vehicle motor controller according to claim 1, characterized in that: The internal non-volatile memory is the program flash memory inside the main control chip of the motor controller.

5. The method for monitoring the operating status of a vehicle motor controller according to claim 4, characterized in that: The dedicated storage block is a non-volatile storage block that is partitioned in the program flash memory by a configuration tool and is dedicated to storing time-series data covering the time window before and after the time of the fault occurrence.

6. The method for monitoring the operating status of a vehicle motor controller according to claim 1, characterized in that: The duration of the first preset time window before the fault occurs is longer than the duration of the second preset time window after the fault occurs.

7. The method for monitoring the operating status of a vehicle motor controller according to claim 6, characterized in that: The first preset time window is 300 milliseconds to 800 milliseconds, and the second preset time window is 100 milliseconds to 400 milliseconds.

8. The method for monitoring the operating status of a vehicle motor controller according to claim 1, characterized in that: The communication backhaul module is configured to respond to data read requests from the Unified Diagnostic Service (UDS) protocol and backhaul the stored time-series data.

9. The method for monitoring the operating status of a vehicle motor controller according to claim 1, characterized in that: The storage aging management module only determines that the clearing conditions are met after confirming that the time-series data in the dedicated storage block has been successfully read.

10. The method for monitoring the operating status of a vehicle motor controller according to claim 9, characterized in that: The dedicated storage block is equipped with a status flag bit to indicate whether the time series data has been successfully read.

Images