Automation of DTC validation for automotive ECUs using a standardized testing template

One of the most fundamental aspects on the behaviour of a general electronic control modules (ECUs), is the management of the diagnostic trouble code (DTCs). The DTC is a standardised numerical code used in order to identify and store malfunctions or faults detected by the ECU. Each code represents a specific type of fault, facilitating identification, diagnosis and troubleshooting in automotive embedded systems. For this reason, it is crucial to verify whether the ECU manages these identifications codes as expected. In particular, to validate the DTCs of a specific ECU, it is necessary to check when the ECU sets a given DTC after fault injection, and when it deactivates it once the fault is removed. Additionally, it is important to check the status of the specific DTC under analysis. As explained in the norm ISO 14229, each DTC is associated with a status byte that provides further information about the current state of the fault. This information contained inside the status byte could be very useful to understand the actual status of the fault and when it occurs. For this reason, the validator must ensure that this status byte evolves correctly in response to specific test maneuvers or when the fault is set or removed. These validation procedures are typically time-consuming, requiring the manual implementation of long test sequences and extended simulation runs. To address this inefficiency, my team and I developed an automatic testing template to automate the validation of the DTCs of a specific ECU. The most important aspect my team had to address is that each ECU has specific characteristics related to the DTCs and distinct behaviours. Moreover, each ECU’s DTCs involve particular faults that cannot be known in advance by our template. For all these reasons, we had to develop a solution that could be easily implemented by the user and capable of testing a wide range of DTCs and ECUs, each with very different behaviours and evolutions. We decided to organize the project into two parts. The first part, prepared by us, includes all the necessary steps to fully test the ECU’s DTC. This section does not require any compilation or modification by the user, as it already contains all the checks and procedures needed for the DTC testing. The second part, instead, must be completed by the user, since it involves specific operations such as powering on the ECU, performing the key cycle, defining the ECU test conditions, and most importantly, inserting and removing the fault. To simplify the operator’s work and minimize the effort in terms of coding lines and time, we structured this second part in advance by providing constants, variables, and templates. Using this pre-defined structure, the operator only needs to fill in precise information or add a few lines of code for more complex operations. Using this subdivision of the project into two parts, my team and I solved the problem of adapting this tool to as many projects as possible, even when the ECUs show different behaviours. The aspects that vary from one project to another—particularly those related to the ECU’s behaviour and the DTCs—are handled directly by the user, who has knowledge of the specific project and of how the ECU operates. In this way, the user can easily and quickly adapt our template to the ECU under test. At this point, once the preliminary project was completed and provided stable results, the template was implemented and tested on multiple components that had alread