AFE application software development verification and confirmation device and method

Abstract

The present invention provides an AFE application software development verification and validation device and method. This device uses an AFE simulator to simulate data packets that can be sent arbitrarily by the AFE end, collects information from the AFE end, or selects the AFE model to be simulated via a host computer. The MCU then executes corresponding safety measures on the AFE end simulated information. When executing the safety measures, the AFE simulator generates a corresponding response, which is presented to the PLC end. This provides fault response, fault duration, and BMS functional response results, thereby verifying the rationality and completeness of software development and confirming the effective implementation of safety measures.

Description

Technical Field

[0001] The present invention relates to the technical field of software debugging, and in particular to an AFE application software development verification and confirmation device and method. Background Art

[0002] With the adoption of ISO26262 development processes for complete vehicles, the mainstream solution for battery management systems (BMS) is to use high-safety-level (ASIL C and above) AFEs for battery voltage and temperature measurement to meet functional safety requirements. To meet functional safety requirements, manufacturers of high-safety-level (ASIL C and above) AFE chips have defined extensive safety measures for AFE failure modes (for example, the LTC6815 offers 50 safety measures, and the Maxim 17823 offers 53 safety measures). These measures help diagnose single-point faults and latent faults within the AFE. However, for BMS manufacturers, most AFE faults cannot be injected, making software verification difficult. However, software verification is essential for functional safety development. During BMS integration testing, most AFE faults cannot be injected, such as AFE AD measurement drift. Because the AFE AD is normal, BMS developers cannot create a drift fault. These faults can only be tested by modifying the software and disabling some normal functions. This approach requires modifying certain BMS software modules and disabling some normal software module functions to test them. The testing method is complex and requires changes to the original testing procedure, resulting in low test reliability. For AFEs currently meeting ASILC or higher, dozens of faults can impact safety targets, posing a significant testing workload. During acceptance testing, it's also difficult for OEMs to verify that all AFE safety mechanisms are fully implemented, making it difficult to assess functional safety compliance. Summary of the Invention

[0003] To address these issues, this technology innovatively proposes an AFE application software development verification and validation device and method. This device uses an AFE simulator to simulate the AFE. The simulated faults correspond exactly to the safety measures defined in the AFE chip safety manual. This makes AFE application software development verification and validation more efficient, reliable, and complete.

[0004] Specifically, the AFE application software development verification and confirmation device and method described in the present invention include: a BMS system, and an AFE simulation device connected to the BMS system, wherein the BMS system includes an MCU center, an isolated communication IC, and an AFE end connected in sequence; wherein:

[0005] The AFE simulation device is used to simulate the AFE end information, and the AFE end information at least includes any data packet for transmission, or information collected by the AFE front end;

[0006] A PLC terminal connected to the AFE simulation device is used to select a model that matches the AFE front end to be simulated;

[0007] The MCU center is used to execute corresponding safety measures according to the AFE end simulation information sent by the AFE simulation device; when executing the safety measures, the AFE simulation device generates a corresponding response result, and the response result is presented on the PLC end.

[0008] Furthermore, the method further includes: configuring the collected information of the AFE end through the PLC end, or selecting the AFE model to be simulated through the PLC end.

[0009] Furthermore, the AFE simulation device numbers the safety measures executed by the MCU center.

[0010] Furthermore, the number corresponds to the number in the chip security manual of the AFE end.

[0011] The AFE simulation device communicates with the PLC end through a USB interface, and the PLC end displays the executed safety measure number on an interface.

[0012] Furthermore, the response results include at least: normal fault-free response, response with different fault durations, and no response.

[0013] When the AFE end needs to be verified, the isolation communication IC is disconnected from the AFE end and connected to the AFE simulation device, and the other end of the isolation communication IC is connected to the AFE simulation device through an SPI interface.

[0014] As another preferred embodiment, the present invention further provides an AFE application software development verification and validation method, comprising the following steps:

[0015] Step 1: In the BMS system, disconnect the Daisy chain between the MCU center and the AFE end;

[0016] Step 2: Connecting the AFE analog device to the isolated communication IC;

[0017] Step 3: According to the AFE information, model and chip safety manual number of the AFE, through the PLC

[0018] Configure security measures for each security mechanism;

[0019] Step 4: The BMS is powered on and works normally, and communicates with the AFE simulator. The safety measure number on the PLC side is used to confirm whether the BMS has safety measures with corresponding numbers. The software development is then verified to be qualified based on the safety measure configuration in step 3.

[0020] The safety measure configuration includes at least: normal no-fault response, response to different fault durations, and no response.

[0021] Furthermore, when the response result of the AFE simulation device is within the error range of the safety measure configuration,

[0022] The PLC side shows a normal response without fault;

[0023] When the response result of the AFE simulation device exceeds the error range of the safety measure configuration, the time difference of the response result is calculated, and the PLC terminal displays different fault duration responses;

[0024] When the AFE simulation device does not respond, the PLC terminal displays a fault response.

[0025] In summary, the present invention provides an apparatus and method for verifying and confirming the development of AFE application software. This method employs an AFE simulator to simulate arbitrary data packets sent by the AFE, collect information from the AFE, or select the AFE model to be simulated via a host computer. The MCU then executes corresponding safety measures on the simulated AFE information. When executing these safety measures, the AFE simulator generates a corresponding response, which is presented to the PLC. This method provides fault response, fault duration, and BMS functional response results, thereby verifying the rationality and completeness of software development and confirming the effective implementation of safety measures. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 Schematic diagram of the AFE verification process commonly used in the prior art.

[0027] Figure 2 FIG. 4 is a schematic diagram of a method for developing, verifying, and confirming AFE application software in one embodiment. DETAILED DESCRIPTION

[0028] The following will further describe in detail an AFE application software development verification and validation device and method of the present invention in conjunction with specific embodiments and drawings. Example 1

[0029] like Figure 1The following diagram illustrates the current organizational structure for AFE application software development and verification: the MCU executes safety measures, the AFE responds, and the MCU diagnoses AFE faults based on the AFE's response information. Verifying and confirming that the MCU software can correctly diagnose and respond to AFE faults is challenging for BMS manufacturers, as most AFE faults cannot be injected, making software verification difficult.

[0030] like Figure 2 The present invention provides an AFE application software development verification and validation device, comprising: a BMS system, and an AFE simulation device connected to the BMS system. The BMS system includes an MCU center, an isolated communication IC, and an AFE end connected in sequence; wherein:

[0031] The AFE simulation device is used to simulate the AFE end information, and the AFE end information at least includes any data packet for transmission, or information collected by the AFE front end;

[0032] A PLC terminal connected to the AFE simulation device is used to select a model that matches the AFE front end to be simulated;

[0033] The MCU center is used to execute corresponding safety measures according to the AFE end simulation information sent by the AFE simulation device; when executing the safety measures, the AFE simulation device generates a corresponding response result, and the response result is presented on the PLC end.

[0034] Furthermore, the method further includes: configuring the collected information of the AFE end through the PLC end, or selecting the AFE model to be simulated through the PLC end.

[0035] Furthermore, the AFE simulation device numbers the safety measures executed by the MCU center.

[0036] Furthermore, the number corresponds to the number in the chip security manual of the AFE end.

[0037] The AFE simulation device communicates with the PLC end through a USB interface, and the PLC end displays the executed safety measure number on an interface.

[0038] Furthermore, the response results include at least: normal fault-free response, response with different fault durations, and no response.

[0039] When the AFE end needs to be verified, the isolation communication IC is disconnected from the AFE end and connected to the AFE simulation device, and the other end of the isolation communication IC is connected to the AFE simulation device through an SPI interface.

[0040] As another preferred embodiment, the present invention further provides an AFE application software development verification and validation method, comprising the following steps:

[0041] Step 1: In the BMS system, disconnect the Daisy chain between the MCU center and the AFE end;

[0042] Step 2: Connecting the AFE analog device to the isolated communication IC;

[0043] Step 3: Configure security measures for each security mechanism through the PLC according to the AFE information, model, and chip security manual number of the AFE.

[0044] Step 4: The BMS is powered on and works normally, and communicates with the AFE simulator. The safety measure number on the PLC side is used to confirm whether the BMS has safety measures with corresponding numbers. The software development is then verified to be qualified based on the safety measure configuration in step 3.

[0045] The safety measure configuration includes at least: normal no-fault response, response with different fault durations, and no response.

[0046] Furthermore, when the response result of the AFE simulation device is within the error range of the safety measure configuration, the PLC terminal displays a normal and fault-free response;

[0047] When the response result of the AFE simulation device exceeds the error range of the safety measure configuration, the time difference of the response result is calculated, and the PLC terminal displays different fault duration responses;

[0048] When the AFE simulation device does not respond, the PLC terminal displays a fault response.

[0049] The AFE simulator can define each safety measure according to the AFE chip safety manual, simulate related faults, and set the fault duration. This makes software development verification convenient and efficient, highly reliable, and intuitively measures test coverage for more complete testing. Example 2

[0050] To better illustrate the advancement of the present invention, the following takes safety measure SM9 defined in the LTC6815 safety manual as an example to illustrate the differences between the prior art and the present invention.

[0051] SM9 description: cell overlap measurement (use the ADOL command to measure the same cell voltage by ADC1 and ADC2 at the same time).

[0052] Safety measures: SM9 targets an ADC measurement error. The AFE has two ADCs. When the AFE receives the ADOL command from the MCU, ADC1 and ADC2 within the AFE simultaneously sample the same voltage. If the difference between the voltages collected by the two ADCs exceeds the allowable error accuracy, the MCU should recognize this as an ADC failure and, based on safety requirements, enter a safe state.

[0053] The existing technology verifies whether SM9 is correctly implemented as follows:

[0054] 1. Fault-free test: The AFE itself has no AD faults. When the MCU executes the ADOL command, the error between the two AD values after the AFE responds is within the allowable range. The MCU recognizes and determines that the ADC is normal.

[0055] 2. Faulty test: The AFE is a sealed chip. When the MCU executes the ADOL command, it cannot cause the two ADCs to output AD values with a large voltage difference. The only solution is to first block the paths from ADC1 and ADC2 to the AFE through software and forcefully modify the values of ADC1 and ADC2. After the modification, the MCU will recognize it as an ADC fault and the test will pass.

[0056] The shortcomings of current testing techniques are as follows: using a modified program for testing, and logically only checking after the ADOL command is issued. This results in insufficient testing, low reliability, and difficulty verifying correctness.

[0057] The process of verifying whether SM8 is correctly implemented is as follows:

[0058] 1. Fault-free test: Follow the AFE simulator application steps. In step 3, configure SM9 to respond with a fault-free response. This means that when the simulator receives the ADOL command from the MCU, the difference between the ADC1 and ADC2 values is within the error range. The MCU recognizes this and determines that the ADC is normal.

[0059] 2. Fault Test: Follow the AFE simulator application steps. In step 3, configure SM9 for a fault response. This means that when the simulator receives the ADOL command from the MCU, it responds with a value indicating that the difference between the ADC1 and ADC2 values is just outside the error range. If the MCU identifies this as an ADC fault, the test passes. You can also set the time between the two ADC values to verify the MCU's fault filter timing.

[0060] The test device of the present invention has the following advantages: greatly improved efficiency, no need to modify the BMS software code, improved test reliability, and can also detect timing problems.

[0061] In summary, the AFE application software development verification and confirmation device and method described in the present invention not only effectively improves the efficiency and reliability of BMS functional safety development verification, but also can achieve compatibility with the simulation of mainstream AFEs with a safety level above ASILC. It has strong versatility: the software developed for different projects and different BMSs has the same verification method, and there is no need to change the device of the present invention, which provides a basis for the vehicle owner to accept the BMS.

[0062] The above-described embodiments merely illustrate several implementations of the present invention, and while their descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art would be able to make numerous variations and improvements without departing from the spirit of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be determined by the appended claims.

Claims

1. An AFE application software development verification and validation device, characterized in that: include: A BMS system and an AFE simulation device connected to the BMS system, wherein the BMS system includes an MCU center, an isolated communication IC, and an AFE end connected in sequence; wherein: The AFE simulation device is used to simulate the AFE end information, and the AFE end information at least includes any data packet for transmission, or information collected by the AFE front end; A PLC terminal connected to the AFE simulation device is used to select a model that matches the AFE front end to be simulated; The MCU center is used to execute corresponding safety measures according to the AFE end simulation information sent by the AFE simulation device; When the safety measure is executed, the AFE simulation device generates a corresponding response result, and the response result is presented on the PLC end; The response results include at least: normal fault-free response, response with different fault durations, and no response; The collected information of the AFE end is configured through the PLC end, or the AFE model to be simulated is selected through the PLC end; The AFE simulation device numbers the safety measures executed by the MCU center.

2. The AFE application software development verification and validation device according to claim 1, characterized in that: Also includes: The numbers correspond to the numbers in the chip safety manual on the AFE side.

3. The AFE application software development verification and validation device according to claim 2, characterized in that: Also includes: The AFE simulation device communicates with the PLC end via a USB interface, and the PLC end displays the executed safety measure number on an interface.

4. The AFE application software development verification and validation device according to claim 3, characterized in that: Also includes: When the AFE end needs to be verified, the isolation communication IC is disconnected from the AFE end and connected to the AFE simulation device, and the other end of the isolation communication IC is connected to the AFE simulation device through an SPI interface.

5. A method for verifying and confirming the development of AFE application software, characterized in that: The AFE application software development verification and confirmation method adopts the AFE application software development verification and confirmation device according to any one of claims 1 to 4, and the AFE application software development verification and confirmation method includes the following steps: Step 1: In the BMS system, disconnect the Daisy chain between the MCU center and the AFE end; Step 2: Connecting the AFE analog device to the isolated communication IC; Step 3: Configure security measures for each security mechanism through the PLC according to the AFE information, model, and chip security manual number of the AFE. Step 4: The BMS is powered on and working normally, and communicates with the AFE simulator. The PLC uses the safety measure number to confirm whether the BMS has developed safety measures with corresponding numbers. The software development is then verified to be qualified based on the safety measure configuration in step 3. The safety measure configuration includes at least: normal no-fault response, response with different fault durations, and no response.

6. The AFE application software development verification and confirmation method according to claim 5, characterized in that: Also includes: When the response result of the AFE simulation device is within the error range of the safety measure configuration, the PLC terminal displays a normal and fault-free response; When the response result of the AFE simulation device exceeds the error range of the safety measure configuration, the time difference of the response result is calculated, and the PLC terminal displays different fault duration responses; When the AFE simulation device does not respond, the PLC terminal displays a fault response.

Images