Design of engine calibration diagnosis system based on ASAP standard

introduction

The engine electronic control unit (ECU) is the core of the vehicle engine control system. It can provide the best air-fuel ratio and ignition time according to the engine's operating conditions, thereby achieving the best state for the engine's power, economy and exhaust emissions [1]. Therefore, it is very important to develop a reliable, convenient and flexible calibration tool. It can shorten the ECU development cycle, reduce the matching experiment workload, reduce development costs, and help calibrators obtain the best calibration parameters in a short time. From the existing data, the calibration system designed in China generally has calibration, monitoring and diagnosis functions. However, its diagnostic function only displays the fault information provided by the ECU on the host computer. There is no introduction to the rapid fault location and repair between the host computer and the ECU. In addition to the online calibration, real-time monitoring and the ability to read the fault information in the ECU, the calibration diagnosis system designed in this paper uses software watchdog technology on the calibration host computer to achieve rapid fault location between the host computer and the ECU, and has the functions of automatically saving, loading, and reading back comparison data. The reliability and flexibility of the calibration system are enhanced.

1 ASAP Standard Architecture

ASAP (Arbeitskreis zur Standardisierung von Applikationssystemen) refers to the Application System Standardization Organization, which proposed this international standard to ensure compatibility and interchangeability of tools and methods used during the development of automotive electronic products [2]. In order to achieve measurement, calibration and diagnosis of application systems, the ASAP working group divided the standard into three sub-standards: ASAP1, ASAP2 and ASAP3 based on the MCD (Measurement, Calibration and Diagnostics) model.

The ASAP1 standard provides an interface between the application system and the control device; the ASAP2 standard provides a standardized description of various internal parameters of the ECU, external interface information, communication methods, etc. The ASAP description file generated according to this standard is a data exchange platform for various control devices; the ASAP3 standard provides a unified interface between the automatic system (or user) and the MCD system. The user only needs to call the interface function provided by the MCD system to complete measurement, calibration, and diagnosis functions.

2 Overall design of calibration system

A PC is used as the host computer, which is connected to the engine ECU through a USB-CAN communication card to realize the calibration, monitoring, diagnosis and other operations of the engine ECU. The communication and data exchange platform between the host computer and the ECU are respectively realized by the CCP protocol in the ASAP standard and the ASAP description file (.A2L file) generated by the ASAP2 standard. The host computer calibration software adopts a layered and modular design, including a data layer, a presentation layer and a communication layer (as shown in Figure 1). The data layer includes an initialization subsystem and a data management subsystem. The initialization subsystem mainly completes operations such as the initialization of the CAN communication module and data. The data management subsystem mainly completes operations such as data storage, loading, playback and management of the A2L database; the presentation layer includes a calibration monitoring subsystem and a diagnostic subsystem, which mainly completes operations such as calibration, monitoring and diagnosis of the engine ECU; the communication layer mainly completes communication operations between the host computer and the ECU.

Figure 1 Overall framework of the calibration diagnosis system

The A2L database generated by the ASAP editor is the data exchange platform for the entire calibration system. Therefore, when the system starts running, the A2L file is first imported, and then the interface library function provided by the CAN communication module is called to complete the CAN communication module initialization and other operations. After the connection is established, multiple ECUs can be calibrated and monitored. Fault diagnosis (ECU fault information upload display and calibration system fault diagnosis) runs through the entire calibration and monitoring process (as shown in Figure 2).

2.1 Design of Initialization Subsystem

This subsystem includes the initialization of the USB-CAN module, the initialization of the calibration parameters, and the initialization configuration of the DAQ parameters. The host computer performs the following initialization operations in sequence by calling the relevant interface library functions of the CAN communication module: opening the CAN communication module, selecting the CAN port connected to the ECU, configuring the relevant parameters of each CAN port (acceptance code, mask code, timer, filter, mode, etc.), starting the CAN communication device, etc. There are two ways to initialize the calibration parameters: one is to read the calibration data from the RAM area of ​​the ECU to the calibration window of the host computer, and the other is to load the calibration data file from the host computer into the program to initialize the calibration data (as shown in Figure 3). Before uploading the monitoring parameters, the DAQ configuration is performed on the data to be monitored, and the monitoring data of different upload cycles are configured in different DAQ tables. This requires the host computer to send DAQ configuration commands and START_STOP commands to require the DAQ processor in the ECU to configure and open different DAQ tables to upload and display monitoring data. During the operation of the calibration system, by opening or closing a DAQ table, the data upload data of the opened DAQ table can be monitored in real time.

2.2 Design of Data Management Subsystem

This subsystem mainly includes the management of the A2L database, data storage, printing, playback and comparison functions. The A2L database is the data exchange platform of the entire calibration system. It records the various parameters inside the controller, external interface information, communication methods and other detailed information. Therefore, its management is particularly important. In the communication protocol, the method of combining the address with the data segment length is used to realize data download and modification. The host computer program is responsible for querying the A2L database to obtain information such as the address and data segment length of the control parameters [3]. The use of the A2L database reduces the burden of the ECU on defining and storing a large number of calibration variables and shortens the computing time occupied by the microprocessor. When the parameter information in the ECU changes, only the modified part of the original A2L file needs to be refreshed using the ASAP database editor. The calibration system only needs to perform operations such as calibration and monitoring on the ECU under the new A2L file. Therefore, when the relevant information of the ECU changes, no changes will be made to the code of the calibration software. At the same time, it also avoids the hidden dangers caused by partial changes in the internal code of the calibration software [4], increasing the flexibility of the calibration system.

In order to facilitate offline analysis and comparison of the monitored data, the system has the functions of saving the monitored data and performing offline analysis, waveform playback and printing.

2.3 Design of the diagnostic subsystem

In this subsystem, in addition to reading the fault information in the ECU, the calibration host computer uses software watchdog technology to quickly locate the fault of the calibration system, greatly reducing the fault finding time. When a fault occurs, the calibrated data is saved in time to avoid repeated calibration work due to the loss of calibration data, thereby improving the reliability of the calibration system (as shown in Figures 4 and 5).

2.3.1 Rapid fault location and automatic data storage

In the receiving interrupt function of the host computer, set a global variable ConnectFlag and assign its value to 0. As long as there is monitoring data uploaded periodically (the data upload cycle of the three DAQ tables in this article is 10ms, 20ms, and 50ms), ConnectFlag is always 0. When it exceeds 50ms, the variable will continue to increase by 1 in the timer function. When it is greater than the specified value (no data is uploaded within the specified time), a fault prompt will appear in the host computer. According to the interface function provided by USB-CAN, determine whether the fault is between the ECU and the USB-CAN module, or between the USB-CAN and the ECU. In case of a fault, call the save function on the host computer to save the calibrated data, make a backup of the calibration data, avoid recalibration due to the loss of calibration data, and reduce the calibration workload.

2.3.2 Fault repair and automatic data loading

Quickly locate the fault according to the fault prompt. After troubleshooting, click the reset button in the repair menu on the main interface according to the fault prompt. When the reset is successful, the calibrated data will be automatically loaded from the saved file of the host computer to the calibration window and sent down. Then continue the calibration operation without recalibration. In the repair menu, if the ECU is powered off, when the ECU is powered on and repaired, the host computer needs to resend the configuration DAQ command and start the DAQ table and other related commands, because once the power is off or reset, the related commands between the ECU and the host computer need to be resent to complete the communication between the two; in the case of a line fault between the ECU and the USB-CAN, you only need to connect the line to continue the communication between the host computer and the ECU; in the case of a fault between the USB-CAN and the host computer, you need to turn off the CAN-USB device on the host computer first, then turn it on and initialize the device, and then continue the calibration work.

2.4 Design of calibration monitoring subsystem

The online calibration of ECU control parameters is completed in the calibration window of the host computer. By modifying the parameter values ​​in the calibration window online, the relevant parameter values ​​in the RAM area of ​​the ECU can be optimized. After calibration, the calibration values ​​in the RAM area are burned into the FLASH. At the same time, the calibration parameter values ​​in the ECU can be read in the calibration subwindow and compared with the current calibration window values ​​to ensure the correctness of the calibration values ​​sent down. The calibration flow chart is shown in Figure 4. In addition, the subsystem can monitor the data collected by the ECU in real time and display the data in a diversified manner, which can intuitively display the monitored data and its changing rules. The host computer can send a command once to request the slave device to automatically upload DAQ monitoring data periodically (see Figure 5 for details).

2.5 Design of the Communication Subsystem

The communication subsystem mainly provides a communication interface between the host computer and the ECU. The communication protocol used is the CCP protocol [5], which is an independent communication standard from the ASAP1a substandard. The protocol has the advantages of reliable communication, strong real-time performance, and good versatility. In the design, the ccpCommand() function is used to call different CCP commands to complete the command issuance, and the fGetData() function is called to receive the return command from the ECU and read the monitoring data uploaded in the ECU. The ECU periodically uploads the monitoring data according to the DAQ configuration command and the start DAQ command of the host computer.

3 Design of the underlying software of the calibration system

In order to increase the versatility of the underlying communication module, a modular design concept is adopted to separate the CAN Driver and the CCP Driver. The Command Processor is the main component of the CCP Driver; the DAQ Processor is used to collect and periodically upload the current values ​​of the monitoring parameters of different DAQ tables as required. The two processors constitute the CCP Driver of the controller, which parses and implements the content of the calibration protocol. In order to ensure the reliability of CAN communication, the CAN Driver adopts a ring buffer mechanism and communicates interrupt subroutines and system tasks through operating system messages. By changing the CAN Driver, different ECU hardware platforms can be transplanted, and new ECUs can be calibrated, which increases the compatibility and versatility of the underlying communication module.

4 Conclusion

The calibration diagnosis system designed in this paper integrates calibration, monitoring, diagnosis and other functions. On the basis of ensuring the flexibility of the system and the real-time communication, the software watchdog technology is used on the host computer to realize the rapid diagnosis and repair of calibration system faults, automatic data saving and loading functions, thereby preventing the loss of calibration data, avoiding repeated calibration work, and ensuring the reliability of the entire calibration system. Experiments show that the system has high real-time, flexibility and reliability.