Hardware in-the-loop system for testing automotive ECU diagnostic software

Introduction

Today, automobiles can contain up to 70 electronic control units (ECUs) for many diverse applications such as power-train control, chassis control and comfort systems. The validity, robustness and reliability of the software in each ECU have to be guaranteed and a software testing process is an important step in ensuring software satisfies the specification. As the proportion of software dedicated to on-board diagnostic (OBD) systems in each ECU increases, a method for testing automotive controller diagnostic software is essential and will ensure each ECU will function properly in its operational environment.

The diagnostic software structure is divided in two parts. One part contains software for legislated diagnostics defined by the SAE J1979 communication services and the on-board management structure.The second part contains OEM Specific enhanced diagnostics, which are defined by the ISO 14229 communication services.

The HIL systems are designed to include a number of fully integrated software Packages that allow controller software to be validated using manual or automated methods. Manual testing of control system software using HIL is similar in nature to testing performed using vehicles. In this case, the test engineer has to be present throughout the test and is required to vary test conditions according to a pre-defined test schedule. The integrated nature of the HIL system also allows automated tests to be carried out. Automated testing of ECU software is a technology that has been implemented by automotive manufacturers over that last few years.

The general benefits of such an approach to testing are :

? Enhanced ECU developer knowledge database.

? Reduced time to detect and diagnose failures.

? Improve existing and future control units.

? Repeatable testing.

? Safer testing.

? Increased test coverage.

HIL architecture for diagnostic software testing

Hardware components :

? Personal Computer (PC).

? Real time processing hardware enabling the real-time implementation of simulation models. Provides simulated vehicle electrical I/O for ECUs under test. Allows manual or scripted user intervention via Control Panel Graphical User Interface (GUI).

? Fault Insertion Unit. Hardware enabling short and open circuit fault modes to be applied to electrical control systems either manually or under programmed test automation conditions.

? External Hardware (load)

? Electronic Control Unit (ECU)

Software components :

? MATLAB (Simulink, Stateflow, Real-TimeWorkshop). A computing environment that combines numeric computation, data visualisation and a high-level programming language. Simulink is a powerful modelling tool that enables a user to model systems using block diagrams to simulate and analyse dynamic systems. Stateflow is used as an interactive design tool for modelling and simulating complex reactive systems. Stateflow provides a graphical method of constructing finite state machines in a manner that utilises many rules associated with the construction of flow charts. Real-time workshop automatically generates C code from Simulink block diagrams and Stateflow systems.

? ControlDesk (dSPACE software). ControlDesk is used as a GUI for interactive control and monitoring of Simulink and real-time simulations. It provides powerful scripting language Python incorporating object-orientated features.

? AutomationDesk (dSPACE software). Test Automation Software applications that provide engineers with a means of automating documented tests.

The functionality of the system is based on the integrated platform of MATLAB/Simulink simulation software and a real time computing system using dSPACE hardware. In a HIL system, a software model executing in real time replaces the vehicle for which the control unit under test is designed. The software model, which is implemented in MATLAB/Simulink, can include a mathematical model of the vehicle dynamics together with descriptions of the actuators, the driver and the environment. In order to run in real-time, the complete model is compiled using the auto-C-code generation function of Matlab’s Real-TimeWorkshop. A key element of the real time computing platform is hardware that enables the HIL simulator to be connected as a node on a controller area network (CAN) bus. For the control systems considered, a diagnostic protocol is defined that allows controller diagnostic information to be accessed via a CAN bus connection. Use of propriety software enables CAN functionality to be embedded into a simulation model and allows the communication protocol required for the data exchange with the control module under test to be implemented. The real time model emulates vehicle system sensor properties in the vehicle CAN bus and pre-processes any actuator signals. Of interest to engineers, is the behaviour of a control system under fault conditions. In particular, the control system should exhibit deterministic behaviour for a set of specified fault conditions and report each failure in accordance the diagnostic communication protocol. To enable failure modes to be set during each automated test, a fault insertion unit is used to generate wire breaks(Open Circuit) and short circuit faults.?

Development of diagnostics services using CAN communication

Controller area networks (CAN) originate from the 1980’s, when a need arose to do something about the excessive use of cables in cars. CAN network communication offers a system, which is durable against electrical disturbances, easy to install and provides the flexibility of connecting of nodes (controllers) with each other. CAN offers serial communication where the maximum transfer rate is 1Mbits/s however, a speed for networks of between 125 and 500Kbit/s is more usual. The diagnostic services for controllers have been developed based on the ISO 11898 high-speed CAN. The above figure depicts a schematic layout of high speed CAN showing the CAN high (CAN_H) and CAN low (CAN_L) signals that are used for receiving and transmitting messages. CAN_H has a signal output of 2.5-3.5V where CAN_L has an output of 1.5-2.5V. Every node (ECU) is connected to the bus in series, which offers the advantage of low cable use.

The communication protocol

CAN implementation in relation to the ISO/OSI 7 layer model. In particular, CAN operates at the data link and physical layer of the ISO/OSI 7 layer model. The data link layer is implemented within two layers, the object and transfer layer. In the former layer every CAN frame has a priority number indicating the Importance of the message. This layer also deals with message filtering, in order to decrease the number of unwanted messages. The transfer layer takes care of error detection, fault confinement, acknowledgement, message framing and arbitration. The physical layer takes care of bit representation, transfer rates, signal levels, signal timing and transmission medium.

User designed software resides in the application layer. The designer must develop the data packets to be 8 bytes in length. CAN is a protocol for short messages. As previously mentioned each transmission of a message can carry up to 8 bytes of data. This makes it suitable for transmission of trigger signals and measurement values. It is a CSDA/AMP (Carrier Sense Multiple Access / Arbitration by Message Priority) type of protocol. Thus the protocol is message oriented and each message has a specific priority according to which it gains access to the bus in case of simultaneous transmission. An ongoing message is never interrupted. Every message entering the CAN bus reaches all the other nodes (ECUs). Each node makes a judgement whether to accept a message or not. Every node has a unique identifier, which makes it possible to address messages. When a node is required to transmit a message, it waits until the bus is free. The message identifier is transmitted bit by bit. A zero is dominant over a one and a node loses the arbitration when it has written a one but reads a zero on the bus. As soon as a node has lost the arbitration it stops transmitting but continues reading the bus signals. When the bus becomes free the CAN controller automatically makes a new attempt to transmit its message. There are two different sizes of CAN messages available for use, one with an 11-bit identifier called standard and another with 29-bit identifier called extended. The below figure illustrates a message with an 11-bit identifier. The data that defines each diagnostic service for testing automotive controller diagnostic software is placed within the data field.

ECU diagnostic software structure

The ECU diagnostic software structure is described by three components State, Sub-state and diagnostic modes (mode requests) as shown in below image.

An ECU diagnostic software state can be thought of as a state or condition that the ECU can operate in and from which it may perform certain diagnostic related tasks or operations. An ECU sub-state is similar to an ECU software state however its primary purpose is to allow the ECU to carry out a specific action. While in any of the specified diagnostic states, an ECU shall support serial communications to be able to perform the following functions.

? Access to Diagnostic Trouble Code (DTC) – Read/Clear

? Access to parameter identifier information – Read only

? Data access via direct memory reference (DMR)

? Entry into the Default, Extended and Programming state

? Exercise on-board diagnostic routines

Certain diagnostic services and routines may only be performed by an ECU when the ECU software has entered the correctly specified state/sub-state. The ECU may only be in one state or sub-state at a time. Various levels of diagnostics may be performed depending on the state/sub-state of the ECU. An ECU will exit a diagnostic software state if it receives an appropriate request to enter another state or sub-state or it does not receive a diagnostic message within a pre-defined timeout period. In this case, an ECU will return to its normal operational state. A Diagnostic Service (mode) can be defined as an operation or task that an ECU will perform while operating in a given state or sub-state. A diagnostic service can also be defined as a request for an ECU to enter or exit a software state or sub-state. All diagnostic messages sent by diagnostic test equipment contain a mode number in the first data byte of the request message.

Diagnostic trouble code (DTC) and parameter Identifier (PID)

Each ECU receives data in the form of signals from various switches and sensors. The data is processed and used to generate vehicle system control signals. Each ECU is connected to a vehicle communication network on which it shares data with other ECUs. Each vehicle system fault condition is defined, for diagnostic purposes, by a unique diagnostic trouble code (DTC). Diagnostic data for each vehicle control module is held on a diagnostic database. DTCs are logged by an ECU upon the detection of on-board or I/O faults.

Two types of DTCs are supported those defined as legislated and those related to OEM enhanced diagnostic software. Parameter identifiers (PIDs) are characterised by a two-byte value, each defining a particular ECU variable. The ability to read or write data to each ECU variable on an ECU is PID dependant. As with DTCs, there are legislated PIDs and those defined as OEM enhanced PIDs. Using a specified service mode, a data value can be written to the ECU at an internal memory location specified by its unique parameter identifier. In addition data record values can be requested from the ECU using a specified parameter identifier.

PID data structure

An example of how the generic diagnostic services are implemented is depicted in Figure below. In this particular example the diagnostic interface will request a diagnostic service parameterAccessByPID(). The parameter identifier is 2 bytes in length and is denoted by the 0xE303 hex address. This PID defines 4 characters of a vehicle identification number and using 4 bytes of data. When the request for diagnostic data is made, the functions described in the previous section are used in order that the diagnostic interface can construct the appropriate CAN message. As shown in Figure below the CAN message consists of 8 bytes of data.The first byte defines the data length, the second the diagnostic service mode, the third and fourth the parameter identifier hex address and the remaining bytes are padded with zeros to complete the 8 byte CAN message. When the ECU receives a request for diagnostic information, it will return a response code, which is either an affirmative code (indicating the request can be executed) or a negative code (indicating the request cannot be executed). When a negative response is returned, a code that indicates the reason for the rejection of the request is included. In the case illustrated in Figure below the ECU response is affirmative. The second byte of the message indicates the affirmative response, whereas bytes 4-8 contain the data from the 0xE304 location within the ECU.The data are returned to the diagnostic interface and a data validation process takes place.

Flowchart of the diagnostic software testing process using HIL

ECU diagnostic software testing process using HIL

The ECU diagnostic software testing process using hardware-in-the-loop systems and the diagnostic test software described previously. The flowchart in Figure above illustrates the full process for diagnostic software testing. The process begins with the development of a model in Simulink. In control engineering terms the Simulink model is constituted by the plant dynamics and other dynamic components. At this stage the model is simulated offline and validated against existing vehicle data until results are acceptable. Once the offline simulation results are acceptable, source code is generated for the model that can be compiled ready for use in a real time computing environment. If necessary, an iterative process can be used to refine the real-time simulation model. The next phase of the process involves the development of a graphical user interface to assist the test engineer with the diagnostic software testing process. A graphical user interface links to the real time model and provides the test engineer with a means of manipulating model variables to implement tests using an interactive manual approach. The next phase in the process of building a software test system is the development of scripts that define a test sequence and that can be used with software that enables unsupervised tests to be executed automatically. Such test scripts are designed to meet the software validation requirements of a specific control module. During this process the diagnostic services discussed above are embedded into the automated scripts. Finally the test scripts are run and results are logged for validation against the module specification. If the module specifications are met, the diagnostic software onboard the ECU is considered acceptable, otherwise the diagnostic software is reviewed and re-written if necessary.

Results

The proposed method allows diagnostic software to be tested systematically by applying implausible signals or defective electrical connections to a control module. The defined series of diagnostic tests are able to run automatically. Once a test sequence has been defined, repeat testing is straightforward and tests that can take several weeks of engineering time can be performed in a matter of hours. Indicative results obtained from the automatic diagnostic software validation process.

Reference

www.instmc.org.uk

Hardware in-the-loop system for testing automotive ECU diagnostic software A Paper published by Alexandros Mouzakitis, David Copp, Richard Parker Jaguar Land Rover, Coventry, UK

Keith Burnham Control Theory and Applications Centre, Coventry University, UK

I would like to thank the above authors of the paper for publishing a great paper which was useful in my career to understand about ECU Diagnostic test in HIL testing in detail.

I have no credit in this article, Just thought of sharing their work in short.

Link : https://journals.sagepub.com/doi/pdf/10.1177/002029400904200803