Accelerating automotive ECU diagnostic software testing through Hardware-In-The-Loop Systems
Vietsol - Pioneering Excellence in Mobility Engineering & Technology
Ride the wave of automotive engineering evolution
Introduction
Did you know modern cars can house an astonishing array of up to 70 electronic control units (ECUs), each managing diverse functions? Ensuring the integrity and reliability of the software within each ECU is paramount. As the proportion of software dedicated to on-board diagnostics (OBD) systems in each ECU increases, the need for robust testing methods becomes even more critical.
The diagnostic software structure is intricately divided into two parts: one for legislated diagnostics following SAE J1979 standards and on-board management, while the other part encompasses OEM-specific enhanced diagnostics defined by the ISO 14229 communication services.
Enter Hardware-in-the-Loop (HIL) systems, equipped with fully integrated software packages. These cutting-edge systems facilitate the validation of controller software through both manual and automated methods. Manual testing, akin to real-world vehicle testing, requires the expertise of a test engineer, whereas the integrated nature of the HIL system enables seamless automated tests.
The adoption of automated testing for ECU software represents a remarkable technological advancement in automotive manufacturing, ensuring enhanced reliability and efficiency in testing procedures.
HIL architecture for diagnostic software testing
The system operates through MATLAB/Simulink software and VECTOR hardware, with a real-time software model replacing the vehicle for testing control units. Created in MATLAB/Simulink, this model includes a vehicle dynamics mathematical model and descriptions of actuators, drivers, and the environment, compiled for real-time execution using MATLAB's Real-Time Workshop.
Key to this system is hardware allowing the HIL simulator to connect as a node on a Controller Area Network (CAN) bus. For control systems, a diagnostic protocol on the CAN bus provides access to controller diagnostic information. Proprietary software embeds CAN functionality into a simulation model and implements the required communication protocol.
The real-time model emulates vehicle system sensor properties and preprocesses actuator signals. Engineers focus on the control system's behavior under fault conditions, expecting deterministic behavior and adherence to the diagnostic communication protocol. A fault insertion unit facilitates fault generation during automated tests, producing wire breaks and short circuit faults.
Development of diagnostics services using CAN communication
The inception of Controller Area Networks (CAN) dates back to the 1980s, emerging in response to the growing issue of cable clutter in automobiles. CAN network communication presents a robust solution resilient to electrical interference, offering easy installation and facilitating the interconnection of nodes (controllers). While CAN enables serial communication with a maximum transfer rate of 1 Mbps, typical network speeds range between 125 and 500 Kbps. Diagnostic services for controllers are designed following the ISO 11898 high-speed CAN standard. Illustrated in the diagram is the schematic layout of high-speed CAN, illustrating the CAN high (CAN_H) and CAN low (CAN_L) signals used for message transmission and reception. CAN_H outputs a signal ranging from 2.5 to 3.5V, while CAN_L outputs between 1.5 and 2.5V. Each node (ECU) is serially connected to the bus, minimizing cable usage and enhancing efficiency.
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, acknowledgment, message framing and arbitration. The physical layer takes care of bit representation, transfer rates, signal levels, signal timing and transmission medium.
User-created software resides in the application layer, where data packets must be precisely 8 bytes long.
CAN functions as a protocol for short messages, accommodating up to 8 bytes of data per transmission, making it suitable for trigger signals and measurements. It employs a CSMA/AMP protocol, ensuring message priority for bus access, with messages never being interrupted and reaching all nodes on the CAN bus.
Each node decides whether to accept a message based on its unique identifier. When a node needs to transmit, it waits for bus availability and then sends the message identifier bit by bit, with arbitration determined by signal dominance.
CAN messages come in two sizes: standard, with an 11-bit identifier, and extended, with a 29-bit identifier. The data field of these messages holds diagnostic service data for testing automotive controller software.
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 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.
Recommended by LinkedIn
• 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
Diagnostic services and routines are exclusive to specific states/sub-states within an ECU's software, with only one state or sub-state active at any given time. The level of diagnostics performed varies based on the ECU's state/sub-state. If an appropriate request is received, or if a diagnostic message is not received within a predefined timeout period, the ECU exits the diagnostic state, returning to normal operation.
A Diagnostic Service (mode) refers to tasks or operations conducted by an ECU in a designated state/sub-state, including requests to enter or exit these states/sub-states. All diagnostic messages from test equipment include 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-dependent. 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
In the figure below, the diagnostic interface requests a parameterAccessByPID() diagnostic service, denoted by the 0xE303 hex address. This service involves 4 bytes of data representing 4 characters of a vehicle identification number. The CAN message constructed for this request consists of 8 bytes, with the first byte indicating data length, the second byte indicating the diagnostic service mode, and the third and fourth bytes indicating the parameter identifier. The ECU responds with an affirmative code, containing data from the 0xE304 location within the ECU.
Flowchart of the diagnostic software testing process using HIL
ECU diagnostic software testing process using HIL
The ECU diagnostic software testing process utilizes hardware-in-the-loop systems and previously described diagnostic test software. Illustrated in the flowchart above, the process begins with Simulink model development, where offline simulations validate against vehicle data. Upon acceptance, source code is generated and compiled for real-time computing.
If necessary, an iterative process refines the real-time simulation model. The next phase involves developing a graphical user interface, linking to the real-time model for interactive manual testing by engineers.
Subsequently, scripts defining test sequences are developed to meet module validation requirements, incorporating diagnostic services. These scripts enable automated unsupervised testing. Test results are logged and compared against specifications, with non-compliant software subject to review and rewriting.
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 can 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
Vietsol's cutting-edge Testing and Validation offers full coverage: Component, sub-system, system, vehicle level across all domains: Infotainment, body, Chassis, e-Powertrain and charging, ADAS, Network & Diagnostic, Functional Safety, Cyber Security. Backed by esteemed partners like Vector Informatik and dSpace, our technical proficiency ensures accelerated, secure and cost-effective outcomes. Collaborate with our team for unparalleled results!