How to Evaluate an ECU for Suitability to My System: Diagnostic Needs

The difficulty with diagnostics is in the definition.

• Do the diagnostics report simple wire harness shorts and opens checks?
• Do the diagnostics report ECU pin function checks and possible intermediate stuck at voltage checks?
• Do the diagnostics perform initial checks at power-on, or real-time and run-time checks of the internal ECU health and function?
• Are the diagnostics the complex rationality and long-term diagnostics of system (not just ECU) function related to regulatory compliance?
• Finally, are any of the diagnostics of functions associated with safety?

The answer is usually “yes to all the above”.

Basic Pin Diagnostics:

For most embedded control systems, the minimum price for entry is basic short circuit and open circuit diagnostics for all outputs. Inputs are more nuanced as the valid states for a typical switch input are “open circuit” and “short to battery” or “short to ground”. Fully diagnosable switch input circuits require switches which transition not between open and closed, but rather between two distinct closed states (distinct resistances to battery or ground) and are diagnosed with an analog voltage measurement. Measuring the analog voltage at the pin and comparing that to the expected voltage given the currently assumed system state is typically at the core of basic robust pin diagnostics. For more constrained systems or lower diagnostic intensity a simple digital monitor can often provide enough information, and in instances where frequency-based signals are expected, the ability to measure in the time domain may prove useful. The entire OpenECU product line has at least the basic pin diagnostics as a starting point.

Output Driver Diagnostics:

Output drivers have an idle state and an actively driven state (or potentially two actively driven states for H-Bridge outputs). The basic pin diagnostics needs to be cognizant of the possible valid pin states and the current commanded state. Do the diagnostics require detection of faults regardless of the commanded state? Do the diagnostics require detection of intermediate faults (not a short to battery/ground but an over current condition which could be caused by a short internal to an inductive load)? These diagnostics start with the pin state monitor (typically analog voltage for low speed circuits and possibly a digital input into a timer channel for frequency or PWM signals) and then diagnostic application code needs to be written to make sense of the pin state data. This diagnostic application code is usually tightly coupled to the control application, as the interpretation of the pin state data is highly dependent upon the expected state, which for outputs is determined by the control application. The output driver diagnostics provided by the OpenECU product line combined with the basic pin diagnostics enable the higher-level diagnostics to be constructed in the application.

Rationality Diagnostics:

Rationality diagnostics are not faults that drive signals out of their expected ranges, but more typically a set of input values that together do not match with a rationally expected physical system, e.g. the air/fuel ratio sensor reads lean mixture even at full fuel pulse duration and partial throttle. These diagnostic applications typically require substantial knowledge of the physics of the system under control, and usually need a large engineering effort to calibrate the thresholds between normal operation and faulted state. Quite often these applications require that data be stored from repeated operating cycles of the system.

Functional Safety Associated Diagnostics:

Functional safety associated diagnostics are more a mindset than a separate category of diagnostic type, involving diagnostics of faults/failures that do not directly cause an issue with a required function (input or output), but rather with a safety measure. If your system has functional safety associated controls, then an analysis is required where the ECU design is reviewed in light of the system safety goals, and the diagnostics must be reviewed to confirm that any fault that could violate the safety goals can be detected.

It is important to understand that even full-featured ECUs like the OpenECU M560, which have extensive diagnostic capabilities, will likely require application development to implement higher-level system diagnostic functions. Development of these system-level diagnostic functions for ECUs requires knowledge of the measurements and modes available on the ECU, in addition to the behaviors and details of the system under control. Dana’s extensive OpenECU documentation provides the necessary detail for systems engineers to develop these diagnostics.