New energy electric vehicle fault detection method and detection system

Abstract

The invention discloses a new energy electric vehicle fault checking method and system, and relates to the field of new energy electric vehicle fault diagnosis, the new energy electric vehicle fault checking system comprises a data acquisition system and a parameter adjustment system, the data acquisition system comprises a connecting line, the connecting line is connected with an acquisition machine, and the acquisition machine is internally provided with a Bluetooth communication module and a hardware encryption chip and is provided with an anti-interference filter circuit; the parameter adjusting system comprises an adjusting APP, the adjusting APP is installed on a mobile phone, the adjusting APP and the acquisition machine are connected through Bluetooth, and the adjusting APP is further connected with a cloud diagnosis server through a network. Compared with the prior art, the method has the advantages that the data transmission security is guaranteed, the APP provides a parameter modification range and a recommended value reference, the method can adapt to data of different manufacturers for reading and permission application, the timeliness and accuracy of fault inspection are effectively improved, the method has big data analysis and remote firmware upgrading capabilities, and the fault inspection effect is continuously optimized.

Description

Technical Field

[0001] The present application relates to the field of fault diagnosis of new energy electric vehicles, and in particular to a fault inspection method and detection system for new energy electric vehicles. Background Art

[0002] The booming new energy electric vehicle industry has become a key driver of the global electric vehicle industry's transformation. As the number of electric vehicles on the road has grown, fault diagnosis technology has evolved over generations. Early fault diagnosis relied heavily on manual experience, with inspectors relying on simple tools to interact with the vehicle's computer, troubleshooting suspected faults one by one. This was inefficient and prone to misdiagnosis. Later, portable fault diagnosis instruments emerged. These connected to the vehicle's OBD port, read vehicle fault codes according to a pre-set program, and initially located the fault. While these improved diagnostic efficiency, their limited functionality and data processing capabilities made them inadequate for complex faults. In the era of intelligent electric vehicles, some fault diagnosis solutions have begun to incorporate wireless communication technology, leveraging mobile applications. However, these solutions lack a systematic architecture, and suffer from significant shortcomings in data acquisition accuracy, transmission stability and security, and diagnostic intelligence. These tools struggle to adapt to the increasingly complex technical architecture and diverse fault modes of new energy electric vehicles. The industry urgently needs a more advanced, comprehensive, and reliable fault diagnosis technology system.

[0003] Existing fault detection methods for new energy electric vehicles suffer from the following major issues: First, data collection is insufficient in depth and breadth. Most methods can only capture limited fault codes and basic operating parameters, such as vehicle speed and battery level. Deep parameters of core components like motor controllers and battery management systems, including motor speed, torque output, battery SOC, BMS status, and DC / AC conversion efficiency, are not fully collected, limiting the root cause of faults. Second, data transmission lacks security. Wireless communications generally lack hardware encryption chips, making data vulnerable to interception and tampering, posing a security risk. Wired connections, on the other hand, suffer from complex wiring, signal interference, and other issues that affect data transmission quality. Summary of the Invention

[0004] The present application provides a new energy electric vehicle fault inspection method and detection system, which are used to solve the problems of incomplete data collection and low transmission security commonly existing in existing new energy electric vehicle fault diagnosis technologies.

[0005] The present application provides a new energy electric vehicle fault detection system, including a data acquisition system and a parameter adjustment system. The data acquisition system includes a connecting line connected to a data acquisition machine. The data acquisition machine is internally provided with a Bluetooth communication module and a hardware encryption chip. The Bluetooth communication module supports the BLE 5.0 protocol, has a maximum transmission distance of 30 meters, and is equipped with an anti-interference filter circuit.

[0006] The parameter adjustment system includes an adjustment APP, which is installed on a mobile phone. The adjustment APP and the collector are connected by Bluetooth. The adjustment APP is also connected to the cloud diagnostic server through the network.

[0007] As an improvement, the detection steps are as follows:

[0008] S1. Connect the data collector: Plug the connecting cable into the OBD port of the tram, and the data collector will establish communication with the ECU.

[0009] S2. Parameter collection: The data acquisition machine obtains editable parameters such as motor speed, torque output, battery SOC, BMS status, DC / AC conversion efficiency, etc. in real time;

[0010] S3. Data reception preparation: After the smart terminal starts the APP, it pairs with the collector through the Bluetooth protocol and verifies the device digital certificate;

[0011] S4, data transmission: The data collector transmits the encrypted parameter data packet to the APP via Bluetooth, and simultaneously uploads it to the cloud server;

[0012] S5. Parameter display and modification: The APP displays the collected data, and users adjust parameters according to their permission level;

[0013] S6, command execution: The modified command is sent to the data acquisition machine after hardware encryption. The data acquisition machine writes the security-verified command into the ECU through the CAN bus;

[0014] S7. Effect verification: The collector continuously monitors the modified parameters, and the APP generates a diagnostic report and pushes it to the user and maintenance organization.

[0015] As an improvement, step S1 is connected using the CAN bus protocol.

[0016] As an improvement, the parameters collected in step S2 are motor controller parameters, battery management system parameters and thermal management system parameters, including but not limited to maximum output current, PWM frequency, temperature protection threshold, balancing strategy, overvoltage / undervoltage threshold, charging rate limit, coolant pump speed, PTC heating power, and radiator fan control logic.

[0017] As an improvement, step S5 requires selecting the machine manufacturer before displaying the parameters. After selecting the manufacturer, it is convenient to adjust the APP to directly adapt to the manufacturer's data for reading and permission application.

[0018] As an improvement, when modifying step S5, the APP provides a reference for parameter modification range and recommended values ​​to prevent vehicle failures from being aggravated due to improper parameter settings. After the modification, a simulation test can be performed to verify the modification effect.

[0019] As an improvement, in step S6, the acquisition machine will perform a triple security check before executing the instruction, including a hash check of the instruction data packet, a secondary verification of the user operation authority, and a CRC check of the ECU response signal.

[0020] As an improvement, it also includes: S8, real-time monitoring step: the APP continuously receives the vehicle operation status data sent by the collector, and automatically triggers an alarm and records the fault code when abnormal parameters are detected.

[0021] As an improvement, the acquisition machine has a built-in self-test module that performs hardware diagnosis every time it is started to detect CAN communication stability, Bluetooth module signal strength and storage space occupancy.

[0022] As an improvement, the cloud diagnostic server includes a big data analysis module and a remote firmware upgrade module.

[0023] Compared with the prior art, the advantages of the present invention are: the new energy electric vehicle fault inspection system and method of the present invention have many significant advantages. In terms of security, Bluetooth communication is equipped with a hardware encryption chip to ensure data transmission security. In terms of intelligence, the APP provides parameter modification range and recommended value references, and can simulate tests to assist users in accurately adjusting parameters. It has good compatibility. By selecting machine manufacturers, it can adapt to different manufacturers' data for reading and permission application. Its real-time monitoring function can automatically trigger alarms and record fault codes, effectively improving the timeliness and accuracy of fault inspections. The system integrates a self-test module and a cloud-based diagnostic server, and has big data analysis and remote firmware upgrade capabilities, continuously optimizing fault inspection results, and fully meeting the needs of new energy electric vehicle fault detection and processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The accompanying drawings are used to provide a further understanding of the technical solution of the present invention and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the technical solution of the present invention and do not constitute a limitation on the technical solution of the present invention.

[0025] Figure 1 Flowcharts provided for embodiments of the present application;

[0026] Figure 2 A system architecture diagram provided for an embodiment of the present application;

[0027] Figure 3 A timing diagram is provided for an embodiment of the present application. DETAILED DESCRIPTION

[0028] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0029] It should be noted that all directional indications in the embodiments of the present invention (such as up, down, left, right, front, back, etc.) are only used to explain the relative position relationship, movement status, etc. between the various components under a certain specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indication will also change accordingly.

[0030] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of the technical features being referred to. Thus, a feature specified as "first" or "second" may explicitly or implicitly include one or more of such features. Throughout this application, unless otherwise specified, "plurality" means two or more.

[0031] In the description of this application, it should be noted that, unless otherwise expressly specified or limited, the terms "connected" and "connect" should be understood in a broad sense. For example, they can refer to fixed connections, detachable connections, or integral connections. Those skilled in the art will understand the specific meanings of the above terms in this application based on the specific circumstances. Furthermore, when describing pipelines, the terms "connected" and "connected" used in this application have the meaning of conducting electricity. The specific meanings need to be understood in the context.

[0032] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0033] like Figure 1-Figure 3 A new energy electric vehicle fault inspection system includes a data acquisition system and a parameter adjustment system. The data acquisition system includes a connecting line connected to a data acquisition machine. The data acquisition machine is internally provided with a Bluetooth communication module and a hardware encryption chip. The Bluetooth communication module supports the BLE5.0 protocol, has a maximum transmission distance of 30 meters, and is equipped with an anti-interference filter circuit.

[0034] The parameter adjustment system includes an adjustment APP, which is installed on a mobile phone. The adjustment APP and the collector are connected by Bluetooth. The adjustment APP is also connected to the cloud diagnostic server through the network.

[0035] As an improvement, the detection steps are as follows:

[0036] S1. Connect the data collector: Plug the connecting cable into the OBD port of the tram, and the data collector will establish communication with the ECU.

[0037] By adopting the CAN bus protocol, the system overcomes the signal interference issues faced by traditional communication methods (such as serial ports or Wi-Fi) in complex electromagnetic environments. It also supports multi-node communication, meeting the needs of multi-system collaborative diagnosis in new energy electric vehicles. Furthermore, the standardized nature of the CAN bus (such as ISO11898) lowers the barrier to device compatibility, enabling the data acquisition machine to adapt to ECUs from different manufacturers, improving system versatility and deployment efficiency.

[0038] S2. Parameter collection: The data acquisition machine obtains editable parameters such as motor speed, torque output, battery SOC, BMS status, DC / AC conversion efficiency, etc. in real time;

[0039] Multi-source parameter collection overcomes the limitations of traditional single-source fault code reading, enabling the system to identify potential faults (such as battery aging and motor overheating) rather than relying solely on triggered fault codes. For example, collecting BMS balancing strategies and charge rate limit parameters can provide early warning of battery pack imbalance issues, avoiding safety risks caused by localized overcharging or over-discharging. Furthermore, real-time monitoring of thermal management parameters (such as PTC heating power) helps optimize energy consumption and extend battery life.

[0040] S3. Data reception preparation: After the smart terminal starts the APP, it pairs with the collector through the Bluetooth protocol and verifies the device digital certificate;

[0041] Bluetooth 5.0's anti-interference filtering circuitry and 30-meter transmission distance design overcome the signal attenuation issues often associated with traditional Bluetooth in complex scenarios, improving connection stability. A digital certificate verification mechanism prevents unauthorized access, preventing malicious parameter tampering or data theft. For example, in maintenance facilities, maintenance personnel must authenticate their operations through an app, ensuring controllable access permissions and reducing the risk of misoperation.

[0042] S4, data transmission: The data collector transmits the encrypted parameter data packet to the APP via Bluetooth, and simultaneously uploads it to the cloud server;

[0043] Hardware-level encryption (such as AES-256) offers greater resistance to attacks than software-based encryption, preventing sensitive parameters (such as battery health status) from being intercepted during transmission. Cloud synchronization supports cross-regional collaboration. For example, users in remote areas can access expert diagnostic models through the cloud, improving troubleshooting efficiency. Furthermore, historical data stored in the cloud can be used for big data analysis to identify common failure modes and assist manufacturers in optimizing product designs.

[0044] S5. Parameter display and modification: The APP displays the collected data, and users adjust parameters according to their permission level;

[0045] A hierarchical permission system effectively prevents non-professional users from arbitrarily adjusting key parameters (such as the maximum motor output current), preventing vehicle performance degradation or safety hazards caused by incorrect parameters. Recommended values ​​are generated by combining references with AI algorithms (such as LSTM-based predictive models), reducing reliance on human experience and improving the scientific nature of modification suggestions. The simulation test function verifies the effects of modifications before actually writing them to the ECU, reducing trial and error costs. For example, when adjusting the overvoltage threshold of the BMS, the system can simulate the changes in battery life under different thresholds to assist users in making decisions.

[0046] S6, command execution: The modified command is sent to the data acquisition machine after hardware encryption. The data acquisition machine writes the security-verified command into the ECU through the CAN bus;

[0047] Triple security checks (hash checksums ensure data integrity, permission verification prevents unauthorized access, and CRC checksums ensure command transmission accuracy) create a multi-layered defense system, significantly reducing the risk of unauthorized command injection. A priority arbitration mechanism for CAN bus writes ensures that high-priority commands (such as emergency fault repairs) are executed first, improving system response speed. For example, if the battery overheats, the system can quickly issue cooling commands to avoid the risk of thermal runaway.

[0048] S7. Effect verification: The collector continuously monitors the modified parameters, and the APP generates a diagnostic report and pushes it to the user and maintenance organization.

[0049] Continuous monitoring dynamically tracks system performance after parameter adjustments, enabling timely detection of secondary faults (e.g., abnormal motor temperature after modifying thermal management parameters). Structured diagnostic reports (such as fault type, severity level, and recommended actions) facilitate rapid understanding of the issue and provide data support for subsequent maintenance. For example, the report can include SOC fluctuation curves before and after parameter modifications, providing a visual representation of changes in battery performance.

[0050] As an improvement, step S1 is connected using the CAN bus protocol.

[0051] As an improvement, the parameters collected in step S2 are motor controller parameters, battery management system parameters and thermal management system parameters, including but not limited to maximum output current, PWM frequency, temperature protection threshold, balancing strategy, overvoltage / undervoltage threshold, charging rate limit, coolant pump speed, PTC heating power, and radiator fan control logic.

[0052] As an improvement, step S5 requires selecting the machine manufacturer before displaying the parameters. After selecting the manufacturer, it is convenient to adjust the APP to directly adapt to the manufacturer's data for reading and permission application.

[0053] As an improvement, when modifying step S5, the APP provides a reference for parameter modification range and recommended values ​​to prevent vehicle failures from being aggravated due to improper parameter settings. After the modification, a simulation test can be performed to verify the modification effect.

[0054] As an improvement, in step S6, the acquisition machine will perform a triple security check before executing the instruction, including a hash check of the instruction data packet, a secondary verification of the user operation authority, and a CRC check of the ECU response signal.

[0055] As an improvement, it also includes: S8, real-time monitoring step: the APP continuously receives the vehicle operation status data sent by the collector, and automatically triggers an alarm and records the fault code when abnormal parameters are detected.

[0056] The real-time monitoring function provides proactive fault warnings, preventing users from ignoring early warning signs (such as slight fluctuations in battery voltage) and potentially exacerbating the problem. Automatic recording and classification of fault codes (according to ISO14229 standards) facilitates subsequent tracing and analysis, reducing manual troubleshooting time. For example, when driving at high speeds, the system can immediately indicate abnormal motor temperature and recommend slowing down, improving driving safety.

[0057] As an improvement, the acquisition machine has a built-in self-test module that performs hardware diagnosis every time it is started to detect CAN communication stability, Bluetooth module signal strength and storage space occupancy.

[0058] A self-check function ensures the data collector is in optimal condition before each use, preventing diagnostic failures due to hardware failures (such as a CAN bus disconnect). For example, if Bluetooth signal strength is detected below a threshold, the system can prompt the user to move away from interference sources, improving connection reliability. Storage space utilization monitoring prevents data overflow and ensures long-term operational stability.

[0059] As an improvement, the cloud diagnostic server includes a big data analysis module and a remote firmware upgrade module.

[0060] The big data analysis module aggregates massive amounts of vehicle data to identify common failure modes (such as battery aging patterns in specific vehicle models), providing manufacturers with a basis for product iteration. Remote firmware upgrades eliminate the need for physical access to the data collector, allowing for vulnerability fixes or performance optimizations (such as updating encryption algorithms to address new attacks), reducing maintenance costs. For example, the cloud can push optimized thermal management strategies for low-temperature winter conditions to improve vehicle adaptability.

[0061] Example 1: Experimental preparation and implementation process

[0062] This experiment aims to verify the innovativeness and performance advantages of a new energy electric vehicle fault detection system. The test subjects include a traditional Bluetooth 4.2 system, a non-encrypted Bluetooth system, a system without hardware encryption, and the proposed system (including cloud-based synchronization verification). The experimental environment simulates real-world scenarios, using multiple brands of electric bicycles (such as Yadi, Niu, and Ninebot) as the test platform to ensure coverage of different ECU protocols and parameter requirements.

[0063] The test steps are as follows:

[0064] Device connection and initialization: Plug the data collector into the electric bicycle's OBD port and establish communication with the ECU via the CAN bus protocol. All systems must complete a hardware self-test (testing CAN communication stability, Bluetooth signal strength, and storage space usage) to ensure consistency in the initial state.

[0065] Parameter collection: The data collector obtains data such as motor speed (0-3000RPM), battery SOC (0-100%), BMS status (overvoltage / undervoltage threshold, balancing strategy), thermal management system parameters (coolant pump speed, PTC heating power) in real time.

[0066] Data transmission and security verification: After the smart terminal launches the app, it pairs with the data collector via the BLE5.0 protocol and verifies the digital certificate. The data packet is hardware-encrypted and transmitted to the app, which is then synchronized to the cloud server.

[0067] Parameter adjustment and command execution: After the user selects the manufacturer adaptation mode, the app provides parameter modification ranges and recommended values ​​for reference (e.g., the PWM frequency adjustment range is 5-20kHz). The modification command undergoes triple security verification (hash check, secondary permission verification, and CRC check) before being sent to the ECU.

[0068] Effect Verification and Real-Time Monitoring: The data collector continuously monitors the modified parameters, and the app generates a diagnostic report and sends it to the user and maintenance agency. During the experiment, if the system triggers an abnormal parameter alarm (such as temperature exceeding the limit), the fault code and response time are recorded.

[0069] Optimized design:

[0070] As shown in Table 1, the anti-interference filter circuit: by integrating the LNA low-noise amplifier and dynamic frequency hopping algorithm in the Bluetooth module of the data collector, the transmission distance and stability are significantly improved.

[0071] Cloud-based big data analysis: Utilize server-side machine learning models to perform cluster analysis on historical fault data, optimize parameter adjustment recommendations, and reduce manual intervention.

[0072] Remote firmware upgrade: The cloud module supports OTA upgrades to ensure system compatibility with new ECU protocols (such as ISO 14229-2023).

[0073] Data analysis and innovative verification

[0074] It can be seen intuitively from the experimental data that the system of the present invention is superior to the traditional solution in all key performance indicators:

[0075] Transmission distance and stability:

[0076] The maximum transmission distance of the traditional Bluetooth 4.2 system is only 15 meters and is easily interfered by metal obstacles; the system of the present invention is based on the BLE5.0 protocol, with a transmission distance of 30 meters, and the anti-interference filter circuit reduces the signal strength attenuation rate to 0.1dB / m (the comparison group is 0.5dB / m).

[0077] The packet integrity (99.8%-99.9%) is much higher than that of traditional systems (88.6%-92.3%), indicating that encrypted transmission and dynamic frequency hopping effectively reduce channel conflicts.

[0078] Safety verification efficiency:

[0079] The system's triple security check (120-130 milliseconds) is over 60% shorter than traditional solutions (350-420 milliseconds). The redundancy design of hash check combined with CRC check reduces the risk of instruction misoperation to 0.1% (compared to 3.9%-6.5% in the control group).

[0080] The hardware encryption chip (AES-256 algorithm) ensures that data packets cannot be tampered with. The non-encrypted system has a false alarm rate of up to 6.5% due to the lack of a verification mechanism.

[0081] Cloud collaboration and scalability:

[0082] The storage space occupancy rate (62%) of experimental group 3 (cloud-based synchronous verification) is significantly lower than that of the traditional system (85%-90%), thanks to the cloud-based distributed storage architecture.

[0083] The big data analysis module trains the model through historical data, which increases the matching degree of the parameter adjustment recommendation value to 95% (the traditional solution relies on a fixed threshold and the matching degree is only 70%).

[0084] Real-time monitoring and fault response:

[0085] When the system of the present invention detects an abnormal coolant pump speed (>1200RPM), the average response time for triggering an alarm is 0.8 seconds (compared to 3.2 seconds for traditional systems), and the fault code recording completeness rate is 100%.

[0086] Creativity and novelty are reflected in:

[0087] Protocol compatibility: Through the manufacturer adaptation mode and CAN bus protocol, the system supports multiple brands of electric bicycles, solving the problem of traditional solutions requiring customized hardware.

[0088] Balance of safety and efficiency: The triple safety verification mechanism ensures safety without significantly increasing operation delay (60% faster than traditional solutions), meeting industrial-grade real-time control requirements.

[0089] Cloud empowerment: Remote firmware upgrades and big data analysis capabilities enable the system to have continuous evolution capabilities and adapt to the rapid iteration characteristics of new energy vehicle technology.

[0090] In summary, the system of the present invention has achieved a comprehensive improvement in fault detection efficiency, safety and scalability through hardware innovation (BLE5.0+anti-interference filtering), algorithm optimization (triple verification) and cloud collaboration, providing a technical benchmark for the field of new energy electric vehicle diagnosis.

[0091] Table 1 Performance comparison experimental data of new energy electric vehicle fault detection system

[0092]

[0093]

[0094] Example 2:

[0095] Workflow and principle of new energy electric vehicle fault detection system

[0096] This embodiment is based on the technical solution in the claims and describes in detail the overall workflow of the device and the functional implementation of each component to ensure that examiners can manufacture devices with corresponding functions based on this embodiment.

[0097] 1. Equipment structure and component numbering

[0098] Data acquisition system:

[0099] Cable 1: Uses ISO15765-4 standard OBD interface cable, compatible with CAN bus protocol (ISO11898-2).

[0100] Collector 2: Embedded hardware device, including the following submodules:

[0101] Bluetooth communication module 21: supports BLE5.0 protocol (NordicnRF52840 chip), has a maximum transmission distance of 30 meters, and is equipped with an anti-interference filtering circuit (LC low-pass filter).

[0102] Hardware encryption chip 22: integrated AES-256 encryption algorithm (Infineon OPTIGA TM TrustX), used for data packet encryption and decryption.

[0103] CAN bus controller 23: supports ISO11898-2 protocol (TITMS570LS04) and is used to communicate with the ECU.

[0104] Storage unit 24: eMMC 8GB memory card, used for caching collected data.

[0105] Parameter adjustment system:

[0106] Adjust APP3: Developed based on Android / iOS platform and installed on smart terminals (such as mobile phones).

[0107] Cloud diagnostic server 4: deployed on an AWS EC2 instance, including:

[0108] Big data analysis module 41: Based on the Hadoop framework, used for fault mode mining.

[0109] Remote firmware upgrade module 42: supports OTA upgrade (MQTT protocol).

[0110] 2. Workflow and Principle

[0111] Step S1: Connect to the data collector

[0112] The connecting line 1 is inserted into the vehicle's OBD interface, and the collector 2 establishes communication with the ECU via the CAN bus controller 23 .

[0113] The CAN bus controller 23 sends an ISO14229 standard request frame (0x100x03), and the ECU responds to establish a diagnostic session.

[0114] Step S2: Parameter collection

[0115] Collector 2 obtains the following parameters in real time:

[0116] Motor controller parameters:

[0117] Motor speed (via Hall sensor, sampling frequency 1kHz).

[0118] Torque output (via torque sensor, resolution 0.1Nm).

[0119] Battery management system parameters:

[0120] Battery SOC (via BMSCAN frame ID0x18F1E5F1, accuracy ±1%).

[0121] BMS status (parse the fault code of CAN frame ID0x18F1E5F2).

[0122] Thermal management system parameters:

[0123] Coolant pump speed (analyzed by PWM signal, range 0-3000RPM).

[0124] PTC heating power (through voltage sampling circuit, accuracy ±5W).

[0125] Step S3: Data reception preparation

[0126] The smart terminal starts the adjustment APP3 and pairs with the collector 2 through the Bluetooth communication module 21 (BLE5.0 protocol).

[0127] Verify the device digital certificate:

[0128] The collector 2 generates an AES-256 key pair through the hardware encryption chip 22, and APP3 uses the preset public key to verify the device identity.

[0129] Step S4: Data transmission

[0130] The data collector 2 encrypts the parameter data packet (using the AES-256 algorithm) and transmits it to the APP 3 via the Bluetooth communication module 21 .

[0131] Synchronously upload to cloud diagnostic server 4:

[0132] The data package is uploaded to the AWS S3 bucket via HTTPS protocol, and the URL is distributed by MQTT message.

[0133] Step S5: Parameter display and modification

[0134] APP3 displays parameters according to user authority level (normal user / maintenance personnel / expert):

[0135] Ordinary users: can only view real-time data (such as SOC and temperature).

[0136] Maintenance personnel: Can adjust BMS balancing strategy (range ±5%).

[0137] Expert: You can modify the DC / AC conversion efficiency (range 90% to 98%).

[0138] When modifying parameters, APP3 provides recommended value references (based on LSTM model prediction) and simulation test functions:

[0139] The simulation test verifies the modification effect through a virtual ECU model (Simulink simulation).

[0140] Step S6: Instruction execution

[0141] The modification instruction is encrypted by the hardware encryption chip 22 (SHA-256 hash check) and then sent to the collector 2.

[0142] Collector 2 performs triple security checks:

[0143] Hash check: Verify the integrity of the command data packet.

[0144] Secondary verification of permissions: Compare the digital certificate sent by APP3 with the whitelist stored in the hardware encryption chip 22.

[0145] CRC check: Verify the ECU response signal (CAN frame ID0x18F1E5F3).

[0146] After the verification is passed, the collector 2 writes the instruction into the ECU through the CAN bus controller 23.

[0147] Step S7: Effect verification

[0148] Collector 2 continuously monitors the modified parameters (such as SOC change rate) and uploads them to APP3 every 10 seconds.

[0149] APP3 generates a diagnostic report (PDF format) and pushes it to users and maintenance organizations (via AWS SNS service).

[0150] Step S8: Real-time monitoring

[0151] APP3 continuously receives the vehicle operation status data sent by the collector 2 (sampling period is 1 second).

[0152] Abnormal parameters trigger alerts:

[0153] When the insulation resistance is less than 1MΩ, APP3 will pop up a red alarm and record a fault code (ISO14229 standard DTCP0A85).

[0154] The fault codes are stored in the MySQL database (table name: fault_codes) of the cloud diagnostic server 4 .

[0155] Step S9: Self-test module

[0156] When the collector 2 starts, it performs a hardware self-test:

[0157] CAN communication stability: Send a test frame (ID0x18F1E5F4) and require the ECU to respond (timeout threshold 50ms).

[0158] Bluetooth signal strength: Measure RSSI value (threshold -70dBm).

[0159] Storage space usage: Detects the remaining eMMC space (threshold 10%).

[0160] Step S10: Cloud Function

[0161] Big Data Analysis Module 41:

[0162] Aggregate historical fault data and use Apache Spark to train a fault prediction model (random forest algorithm).

[0163] Remote firmware upgrade module 42:

[0164] The firmware package (SHA-256 signature) is pushed via the MQTT protocol, and the collector 2 verifies and updates it (upgrade time < 30 seconds).

[0165] Table 2 Key component models and technical parameters

[0166]

[0167] 4. Logical Verification and Implementation Feasibility

[0168] Logical coherence:

[0169] Each step depends on the output of the previous step (e.g., parameter collection in S2 provides the data basis for the modification in S5).

[0170] Security check (S6) ensures that permission verification and data integrity check are completed before the instruction is executed.

[0171] Implementation feasibility:

[0172] The hardware modules of the collector 2 are all commercial off-the-shelf components (such as Nordic nRF52840 and TITMS570LS04) and can be purchased directly.

[0173] APP3 is developed based on Android / iOS SDK, and the code implementation is consistent with the description (for example, the LSTM model calls TensorFlowLite).

[0174] The architecture of Cloud Server 4 complies with AWS standards and does not require special customization.

[0175] The above is only a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or replacements within the technical scope disclosed in the present application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A new energy electric vehicle fault detection system, including a data acquisition system and a parameter adjustment system, characterized by: The data acquisition system includes a connecting line connected to a data acquisition machine, and the data acquisition machine is internally provided with a Bluetooth communication module and a hardware encryption chip; The parameter adjustment system includes an adjustment APP, which is installed on a mobile phone. The adjustment APP and the collector are connected by Bluetooth. The adjustment APP is also connected to the cloud diagnostic server through the network.

2. A new energy electric vehicle fault inspection method according to claim 1, characterized in that: The detection steps are: S1. Connect the data collector: Plug the connecting cable into the OBD port of the tram, and the data collector will establish communication with the ECU. S2. Parameter collection: The data acquisition machine obtains editable parameters such as motor speed, torque output, battery SOC, BMS status, DC / AC conversion efficiency, etc. in real time; S3. Data reception preparation: After the smart terminal starts the APP, it pairs with the collector through the Bluetooth protocol and verifies the device digital certificate; S4, data transmission: The data collector transmits the encrypted parameter data packet to the APP via Bluetooth, and simultaneously uploads it to the cloud server; S5. Parameter display and modification: The APP displays the collected data, and users adjust parameters according to their permission level; S6, command execution: The modified command is sent to the data acquisition machine after hardware encryption. The data acquisition machine writes the security-verified command into the ECU through the CAN bus; S7. Effect verification: The collector continuously monitors the modified parameters, and the APP generates a diagnostic report and pushes it to the user and maintenance organization.

3. The new energy electric vehicle fault detection method according to claim 2, characterized in that: Step S1 is connected using the CAN bus protocol.

4. The new energy electric vehicle fault detection method according to claim 2, characterized in that: The parameters collected in step S2 are motor controller parameters, battery management system parameters and thermal management system parameters.

5. The new energy electric vehicle fault detection method according to claim 2, characterized in that: In step S5, the machine manufacturer needs to be selected before displaying the parameters.

6. The new energy electric vehicle fault detection method according to claim 2, characterized in that: When modifying step S5, the APP provides parameter modification ranges and recommended values ​​for reference to prevent vehicle failures from being aggravated due to improper parameter settings. After the modification, a simulation test can be performed to verify the modification effect.

7. The new energy electric vehicle fault detection method according to claim 2, characterized in that: In step S6, the data collector performs a triple security check before executing the instruction, including a hash check of the instruction data packet, a secondary verification of the user's operation authority, and a CRC check of the ECU response signal.

8. The new energy electric vehicle fault inspection method according to claim 2, characterized in that: Also includes: S8. Real-time monitoring step: The APP continuously receives the vehicle operation status data sent by the collector, and automatically triggers an alarm and records the fault code when abnormal parameters are detected.

9. The new energy electric vehicle fault detection method according to claim 1, characterized in that: The acquisition machine has a built-in self-test module that performs hardware diagnosis every time it is started to detect CAN communication stability, Bluetooth module signal strength and storage space occupancy.

10. The new energy electric vehicle fault detection method according to claim 1, characterized in that: The cloud diagnostic server includes a big data analysis module and a remote firmware upgrade module.

Images