OBD & NOx anti-tampering system architecture experiences ...€¦ · anti-tampering system...

Be

ingenious

OBD & NOx anti-tampering system architecture experiences & lessons learned

BRACE Automotive Marcel Romijn

Competences coordinator

OBD & Emission specialist

CTI 3rd International Conference Heavy-Duty Diesel Diagnostics – 9th October 2014

Be

ingenious Introduction

o Often overlooked are consequences of OBD and NOx anti-tampering legislations to system

architectures.

o Also how unclear boundaries of the OBD system can generate problems.

o Even more valid for heavy-duty on- and off-highway.

o This presentation aims to discuss these potential problems and the lessons to learned.

Agenda:

o Vehicle Diagnostics overview

o Legislation requirements impacting system architecture

o Diagnostic Master & Slave

o Use of “off-the-shelf” smart sensors & actuators from suppliers

o Architecture consequences on legislation compliance, required service information &

emissions warranty

o Concluding

2 CTI 3rd International Conference Heavy-Duty Diesel Diagnostics – 9th October 2014

Be

ingenious Vehicle Diagnostics overview

Engine

• OBD (emissions)

• NOx inducements

• (EGAS) Functional Safety

• Safety (e.g. fire risk)

• Service

Transmission

• OBD (emissions)

• Functional Safety

• Service

Brakes & Vehicle dynamics


• Service

Driver assistence systems


• Service

Comfort systems


• Service

Supplier to Vehicle OEM OEM is the responsible coordinator


Be


Engine (by Engine OEM) • OBD (emissions)

• NOx inducements



• Service

Transmission (by supplier) • Functional Safety

• Service

Brakes & Vehicle dynamics (by supplier) • Functional Safety

• Service

Driver assistence systems • Functional Safety

• Service

Comfort systems • Functional Safety

• Service

Engine OEM & suppliers to Vehicle OEM to Bodybuilder Responsible coordinator?

“Work” application (by Bodybuilder) • Functional Safety

• Service


Be


Engine (by Engine OEM) • OBD (emissions)?

• NOx inducements



• Service

Transmission (by supplier) • Functional Safety

• Service

Brakes & Vehicle dynamics (by

supplier) • Functional Safety

• Service

Driver assistence systems • Functional Safety

• Service

Comfort systems (by supplier) • Functional Safety

• Service

Engine OEM & suppliers to Machine OEM Responsible coordinator?

“Work” application • Functional Safety

• Service


Be

ingenious

6

Legislation requirements impacting system architecture

o Engine

o Driver interface (warnings)

o Transmission

o Aftertreatment

Concept of OBD & Emissions domain

o Concept to clarify the legal requirements

o Legislation requirements can define the domain

o Engine & Aftertreatment are always in

o An engine-dyno certification means transmission is not part of the domain

o Hybrids are a difficult exemption

o Special domains, responsibilites & certification procedures for Hybrids

o OBD & NOx warning system may be part of domain

CTI 3rd International Conference Heavy-Duty Diesel Diagnostics – 9th October 2014

Be

ingenious Legislation requirements impacting system architecture

Concept of OBD & Emissions domain

o US legislation is very strict, while EU & others only so-so

o Any input to an OBD diagnostic = OBD & Emissions domain

E.g. switch off Misfire diagnostic with low fuel tank level or when Traction Control (via CAN)

requests torque limitation

o Any input to Emissions controls = OBD & Emissions domain

E.g. adapt EGR rate on Ambient temperature or the vehicle air pressure system as actuating

medium for Urea injector

o Any system/component possibly impacting emissions or OBD =

OBD & Emissions domain

E.g. Arctic Start Ether Support System, Wait-to-Start or Glow-plug light Systems,

Start-Stop, Cooling Systems, Driver modes (ECO, Sport), Cruise Controls

Domain

Signals to domain

Commands from domain

X

X

Arctic Ether start


Be

ingenious Legislation requirements impacting system architecture

When inside the OBD & Emissions domain

o Full-blown OBD monitoring on sensor signals

E.g. Electrical, Ranges, Plausibility, CAN-bus

o Full-blown OBD monitoring on actuators & commands

E.g. Electrical, Commands Response (whole actuator system), CAN-bus

o Possibility of being a DECECU (Diagnostic or Emission Critical ECU)

E.g. ECU OBD monitoring (Processor, Memory, Supply Voltage), Support CAL-ID (SW and Cal.

part number) & CVN (SW and Cal. verification calculation)

Domain

Signals to domain

Commands from domain

X

X


Be

ingenious

Many control units possibly in OBD & Emissions domain

o Should they all communicate individually to OBD Scantool?

o Should they all keep their own storage of faultcodes and related information?

Diagnostic Masters & Slaves

Ambient

air T

Engine ECU

Aftertreatment

ECU

Cooling fan

EGR valve

VGT

actuator

Glow plug

control

Swirl valves

Urea pump

ABS Vehicle

speed

NOx sensor

NH3 sensor

PM sensor

Driver

interface

OBD

Scantool


Be

ingenious Diagnostic Masters & Slaves

o Typically one or two Diagnostic Masters are assigned

o Responsible for all fault code storages

-No synchronization needed for drive cycle definitions start/end & other cycles

-Prevent “stack-up” of fault codes by the same problem source

-Easy to allocate system overall diagnostics that monitor over several ECU’s functions

o Supports all scan tool communication

o Smart gateway

E.g. Collects, stores, and updates CAL-ID/CVN’s, Smart gateway for Mode6 OBD, groups similar diagnostics under one monitor,

aligns and combines all info for Readiness and Monitor status, and aligns EI-AECD counters with NTE area reporting

o Responsible for commands to driver interface

o Requires lots of interface agreements; some of which do not fit in with current standards

o Requires OBD expertise & preferably develop this only once!

Experience: ~80 CAN messages

total for SAE J1939 scantool


Be

ingenious Diagnostic Masters & Slaves

Look at the source of the information

No point in sending “engine speed” data to a NOx sensor, rules out the

possibility of diagnostics that require “engine speed” based enabling to be

founded in NOx sensor.

System

Plausibility

Range

Electrical

System interpretation of

sensor value

Environment in which the sensor

measures

Electrical circuit of the component

Short/Open circuits; usually all the Volt, Amps, Ohms things

Placement of diagnostics based on diagnostic levels and information need

“Does the whole system act as it should?”

“Does the value make any sense?”

Exceeding normal measurement range; in unit of the sensor

Every diagnostic needs information

The “monitored value” and enabling conditions


Be

ingenious

Use of “off-the-shelf” smart

sensors/actuators from suppliers

Typical Heavy-Duty Diesels = large amount off-the-shelf parts

o Economy-of-scales cost reduction reasons

o Makes diagnostic responsibility a multi-company task

o Many (sub)suppliers have little knowledge about i.e. OBD & NOx anti-tampering

o Purchasing contracts often not technically deep enough

o Lack of important details or even requesting only “OBD compliance” as a generic term

o Makes all the ingredients for a disastrous development project!


Be

ingenious



False PASS scenario with off-the-shelf part based on real-life experience

o Smart valve (i.e. EGR) based on stepper-motor & butterfly valve; internally diagnosed for stuck

butterfly valve by means of internal control error

o CAN communication consisted of 1 bit per internal fault.

If bit = FALSE; Then PASS status to fault code storage & scan tool info

If bit = TRUE; Then FAIL status set to fault code storage & scan tool info

o Now ask yourselves; what is a scenario of a stuck valve?

Say the valve can not move to more than 50% opening due to blockage

Valve works fine below 50% opening


Be

ingenious



CAN bit =

FALSE PASS

Set point< 50%

Engine

Start / Running

Let’s imagine how does the diagnostic react?

CAN bit =

TRUE FAIL

Yes No

FALSE PASS!

o First at start setpoint = 0; so PASS is set

o Later during engine running setpoint = >50%; so FAIL is set

o Fault is now self-healed at every engine start or when setpoint is <50%


Be

ingenious



False PASS issues with off-the-shelf parts; a real life experience cont’d:

o Two solutions investigated:

1) Blame the new-to-OBD (sub)supplier: Modify the internal diagnostic by adding enabling conditions

2) Let the OBD engineers fix it: Don’t forward directly the (sub)suppliers internal status to fault handling

o With 1, the supplier needed to wait for diagnosing unless the setpoint was at higher level

What to do with the 1 bit fault reporting in CAN? When not TRUE is that a PASS or just a “Don’t know yet”?

o With 2, make the OBD master handle the waiting for diagnosing until a relevant setpoint

In the meantime ignore whatever the smart valve was sending in fault reporting

o This experience has come again and again in many situations and systems

Even outside OBD such as Safety related diagnostics


Be

ingenious



DECECU (Diagnostic or Emission Critical ECU) in USA:

o Check up-to-date legislation boundary between “component” and “ECU”

o Typical example: more then 2 Components (e.g. Sensors) DECECU

o Example: Smart valve

Components: Stepper motor (actuator), position sensor, and PCB electrical circuits temperature sensor (overheat protection)

o Usually only first two used; thus not a DECECU

o However, PCB temperature sensor can also be used by OBD master in assisting e.g. Engine Coolant

Temperature plausibility check

o Now all three are used and therefore DECECU

o Special Note:

The same component can be a DECECU in one application and not be a DECECU in another application

Makes for interesting discussions between OEMs, suppliers and sub-suppliers!


Be

ingenious

Architecture consequences on legislation compliance,

required service information, and emissions warranty

What are the consequences if we end up with a compliancy disaster?

o False PASS or no-detections give rise to problems with legislator in USA

Many of these are found in required tests on series-production vehicles either performed by OEM or performed by legislator

o False FAIL or non-existent failures give rise to problems with customers

Legislator is unhappy too because it generates a “bad image” regarding required OBD & NOx anti-tampering systems

o Possible consequences

1. (Forced) recall & warranty costs

2. Exposure in news; (i.e. http://www.epa.gov/otaq/cert/eng-recall/recall.htm or http://www.nhtsa.gov/Vehicle+Safety/Recalls+&+Defects)

3. Possibly fines


http://www.epa.gov/otaq/cert/eng-recall/recall.htm



http://www.nhtsa.gov/Vehicle+Safety/Recalls+&+Defects

Be

ingenious



Emissions related warranty; an USA thing:

o For items in the Emissions & OBD domain an extended warranty is required

Can last up to 10 years and depending on vehicle type varies from 180.000km to 750.000km

o All warranty repairs must be reported to legislator; regardless of repairer

o When a certain % of vehicles has gotten the same warranty repair forced recall

o A DECECU has a longer warranty term than a component

o Thus domain creation can be driven by potential warranty costs and recalls

Many OEMs have a list of no-go signals as the associated sensor would be too expensive in warranty claims

Same component in a different application can make the difference of a 3 years B10 vs. a 10 year B1 reliability demand

o Components that cannot comply may become maintenance items (e.g. NOx sensors)

Set a maintenance term on when to replace most of the components before they are broken


Be

ingenious



Information exchange

o A lot of information must be disclosed about the workings of Emissions system and OBD

During type-approval application and during the vehicle lifetime on a publicly available Service Information website

o Includes also info from the off-the-shelf components internal workings

Again; great fun in discussions between OEMs, suppliers and sub-suppliers

o Some examples of the public available information:

Detroit Diesel: https://ddcsn-ddc.freightliner.com/cps/rde/xchg/ddcsn/hs/5712.htm

Ford (incl. Heavy-duty): https://www.motorcraftservice.com/vdirs/retail/default.asp?pageid=diag_theory_retail&gutsid=diagsheet&menuIndex1=10

General Motors: https://service.gm.com/gmspo/mode6/index.html


https://ddcsn-ddc.freightliner.com/cps/rde/xchg/ddcsn/hs/5712.htm



https://www.motorcraftservice.com/vdirs/retail/default.asp?pageid=diag_theory_retail&gutsid=diagsheet&menuIndex1=10

https://service.gm.com/gmspo/mode6/index.html

Be

ingenious Concluding

OBD, NOx anti-tampering & other diagnostics are always challenging

o Usage in Heavy-duty domain adds more challenges

o Understanding responsibilities throughout the vehicle/machine is key

o Create boundaries with clear and limited I/O interfaces

o Just sourcing components already requires focus on many items unknown to many outsiders

o Things that seem not important or were never important before can have the biggest financial impact

o Knowledgeable (sub)suppliers can be of great help

o (Sub)suppliers that are unaware can however create a nightmare scenario

o (Sub)suppliers need to be prepared to see very different demands of their products depending on

application


Be

ingenious Questions?

www.brace-automotive.com

[email protected]

http://www.brace-automotive.com/



mailto:[email protected]




OBD & NOx anti-tampering system architecture experiences ...€¦ · anti-tampering system...

Documents

Transcript of OBD & NOx anti-tampering system architecture experiences ...€¦ · anti-tampering system...