0

A typical Electronic Control Unit(ECU) performs Open Circuit(OC), Short to Ground(STG), and Short to Battery(STB) Diagnostics on selected internal and external pins in the ECU.

For example, consider a external output pin. There is a wire connected from this pin to somewhere else. If this wire is cut, software will detect OC fault. Or if the output impedance reaches OC threshold, software will detect OC fault.

For some Automotive Advanced Drive Assist System(ADAS) ECU, one Original Equipment Manufacturer(OEM) requires supplier to implement software and hardware to detect OC, STG, and STB faults on all external Digital Outputs and PWM Outputs. They also require supplier to detect these faults on all internal Serial Peripheral Interface(SPI) busses. What might be the reason for selecting these pins for fault detection? Why not some other pins? Maybe fault detection is required on these pins to meet some safety standard?

Consider a Level 2 Autonomous Camera ECU and Radar ECU that support features such as Lane Departure Warning(LDW), Adaptive Cruise Control(ACC), Automatic Emergency Braking(AEB), etc.

What internal and external pins in Camera and Radar ECU should be detected for OC, STG, and STB faults and why?

jani
  • 19
  • 3
  • 2
    This looks like homework. You need to show some effort if you want some assistance. – Kartman Jan 14 '22 at 04:16
  • what pins are available? – jsotola Jan 14 '22 at 05:13
  • This isn't homework. I'm not in school. In my past work experience, customer gave me requirements to implement software to detect stated faults. I did the implementation but I didn't know why fault detection was required for some pin but not others. – jani Jan 14 '22 at 08:51
  • In my current project, the ECU's are Radar and Camera. Since radar's external interface is antennas, there are not external pins for detecting faults? Since camera's external interface is wave signal, there are no external pins for detecting faults? I'll try to find out radar and camera internal interface pins. But generally speaking, consider a non-standard camera interface that has video pins, a pin for synchronizing camera with some device like FPGA, and some control pins. Is it necessary to detect faults on these camera interface pins? If yes, why? – jani Jan 14 '22 at 09:01
  • How do you detect if a given sensor is operational? How do you know your camera is working? How can you test it? Just because it is giving you a video signal doesn’t necessary mean the camera is fully operational. One would expect if you are working in this industry that you do FMEA to work through these questions. – Kartman Jan 14 '22 at 10:23
  • dFMEA was done for this system. I wasn't involved. I could review it. I'll try to find out how radar and camera interface with devices (e.g. ASIC) or what radar and camera pins are connected to devices internal to ECU. Since external to radar is antennas and external to camera is waves, there should be no pins externally? I understood these faults should be addressed during FMEA but generally speaking what internal radar and camera pins need fault detection? – jani Jan 14 '22 at 14:04
  • @jani Any and all pins whose failure in these modes could affect the safety of the users must be covered by testing. Some pins can legitimately be covered by tests on other pins : failure of a clock pin can be detected through absence of data for example (provided you can distinguish between absent data and 0 (or 1) data, e.g. by reading a signature) but you must prove coverage. This will all be in the FMEA : if you find holes in the FMEA, shout about it. –  Jan 14 '22 at 15:14

1 Answers1

1

The camera and radar are ASIL-B level devices. In a Level 2 ADAS, if they fail, they fail passively such that the driver is warned to take over.

Being ECU inputs (and not logic 1/0 type) detecting stuck-at for radar and camera on the ECU interface side doesn’t make sense. Loss of signal is enough.

Do these sensors need internal diags to detect stuck-at? I wouldn’t think so, since they’re ASIL-B, unlike for example a PWM that runs a throttle servo which most certainly is ASIL-D. That said, power-on self test and link integrity are a means to detect some failures which would serve a similar purpose to stuck-at within the sensor. There could also be low-level stuck-at checks on control links in the sensor (e.g., I2C.) This is a huge simplification, see more here: https://www.ti.com/lit/ug/spruig2/spruig2.pdf

Another thing to consider. Cameras and radar can become disabled for reasons that have nothing to do with their electrical signals: they can get dirty. Yet the response is the same as if the component failed: the automated function relying on the sensor is disabled and the driver takes over. This is a far more important (as in, more likely) consideration.

hacktastical
  • 49,832
  • 2
  • 47
  • 138
  • Camera ECU Pinout Camera has no external input pins Within camera is Low Voltage Differential Signaling(LVDS) interface. It's from imager to SOC. The pins are as follows: LVDS+ LVDS- Radar ECU Pinout Radar has no external input pins – jani Jan 15 '22 at 02:31
  • Both cameras and radar units have control interfaces internally. A camera will have a MIPI-to-coax bridge for example, that includes I2C sideband besides the CSI-2 link. A radar (and for that matter, LiDAR) unit will have that, and a DSP, with a control link to the analog front end. All are potential stuck-ats or opens. – hacktastical Jan 15 '22 at 18:06
  • I encourage you to review that TI paper I linked. It’s directly applicable to your question. – hacktastical Jan 15 '22 at 18:09