vector diagnostics seminar

8/19/2019 Vector Diagnostics Seminar

1/94

157652

( 14229)

(1939, , , .) ,


2/94

1

©20 13 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.

V 0. 01 2 01 3- 11 -2 5

June, 2014

The Evolution of Automotive Diagnostic Technology

©2013 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.

Slide: 2

Agenda


3/94

2


Slide: 5

Basic Concepts – A Visit to the Doctor

Something is wrong with the car – but what?

Ask questions and run tests

ECUs know their own health

ECUs can communicate this information

Isolate the problem

Make the fix

Repair (replace) failing part(s)

Is the problem gone?

Go back and repeat questions and tests

Clean bill of health?


Slide: 6

But How Does it Know??

Onboard Diagnostics

Self tests are executed in parallel to actual system operation

Faults are detected and logged internally

Internal test routines are available for single-shot execution

Functionality created to interface with off-board diagnostic tools


4/94


5/94

4


Slide: 9

Today: It’s not brain surgery, but it’s close.


Slide: 10

Goals and Benefits

Goals

Verify function and performance of electrical & mechanical systems

Ensure components are fault free while meeting functional duties

Accurately identify specific failure modes

Benefits

Vehicle delivered from assembly plant to dealer in working order

Vehicle serviced correctly and on time during first visit to dealer

Accurately identify smallest necessary fix

Proper operation of emissions control systems

Reduced operational and warranty costs

A/DFail

Good


6/94

5


Slide: 11

Who Cares?


Slide: 12

ECU development (test implementation and functionality)

Vehicle integration (verify interaction with other ECUs)

Calibration (monitor/calibrate performance, hot/cold trips)

Testing (proving grounds, component and vehicle durability testing)

EMC testing (electro-magnetic compatibility with rest of vehicle & FCC)

Applications and Users – Engineering


7/94

6


Slide: 13

EOL testing (verify vehicle was built correctly and in working order)

Flash programming (program ECU at supplier or on assembly line)

Configuration and calibration (configure ECU on assembly line)

Repair bay (identify failures and verify repairs)

Audit bay (verify quality and compliance)

Applications and Users – Manufacturing


Slide: 14

In-service emissions testing

Troubleshoot customer complaints

Identify failures and warrantee issues

Verify repairs

Flash re-programming updates

Applications and Users – Service


8/94

7


Slide: 15

Evolution, or Revolution?


Slide: 16

Implementation Concept – How Does It Work?

!

?Client-server relationship Tester is client

ECU is server

ECU only speaks whenspoken to

Diagnostic messaging onlyhappens when tester ispresent

Not part of normal modeECU-to-ECU messaging

ECU communicates with off-board test device

1.Tester asks a question

2.ECU responds


9/94

8


Slide: 17

Evolutionary History – Point-to-Point Links

Proprietary point-to-point links (start in early 1980’s)

Implied address “tin cans on a string” model

Simple UART-based line drivers

Simple send-a-byte/get-a-byte protocols

Everything was proprietary

Still hanging on in production


Slide: 18

Evolutionary History – Point-to-Point Links (continued)

Standardized point-to-point links (start in early 1990’s)

Logically addressed “telephone party-line” model

Still UART-based line drivers

More powerful send-a-message/get-a-message protocols

Standardized regulations and tools began to appear

ISO-9141 (K-line) becomes global standard

Still in wide use


10/94

9


Slide: 19

Evolutionary History – Multiplexed Data Links

Proprietary multiplexed networks (start in late 1980’s) Logically addressed “Ethernet” model with collision arbitration

Network carries non-diagnostic messages between ECUs

Back to proprietary protocols and interface hardware

Industry diverged

Lack of standardization precluded use with legislated diagnostics

Still hanging on in production


Slide: 20

Evolutionary History – Multiplexed Data Links (continued)

Standardized multiplexed networks (start in mid 1990’s)

Industry standard network hardware

Industry standard protocols

Industry standard tools

Rapidly replacing all previous vehicle network types

Industry and regulatory convergence is here


11/94

1


V 0. 01 2 01 3- 11 -2 5

June, 2014

Legislative Considerations


Slide: 2

OBD – What are Legislated Diagnostics?

OBD – On-Board Diagnostics or “Legislated Diagnostics”

Emissions-related diagnostics required by the government

Standardized networks, protocols and test tools

Meet the requirements or pay a fine

All OEMs selling vehicles in the US must comply

Enhanced Diagnostics – Non-legislated Diagnostics

Every OEM defines their own enhanced diagnostics strategy

Proprietary protocol, data dictionary and application

Driven by quality and warranty, not the government

Covers entire vehicle – not just emissions


12/94

2


Slide: 3

Legislative Groups – Who’s Driving?

CARB (California Air Resources Board)

Earliest driver of emissions legislation for air quality improvement

EPA (US Environmental Protection Agency

Typically adopts CARB standards

EU (European Commission)

Fairly loose in early years, recently more stringent

Other Countries

See following tables


Slide: 4

Taken from Dave Ferris’ (GM Emission Compliance & Certification) presentation at the SAE 2013 On-Board Diagnostics Symposium


13/94

3


Slide: 5

Taken from Dave Ferris’ (GM Emission Compliance & Certification) presentation at the SAE 2013 On-Board Diagnostics Symposium


Slide: 6

Standards Organizations – Who’s Driving?

SAE (Society of Automotive Engineers)

Primarily a US activity

Most sensitive to EPA and CARB requirements

Most sensitive to US industry participants

More focus on global topics, as legislation goes global

ISO

ISO specific global driver

Sensitive to US, but also UN, EU and future legislation

Sensitive to all industry participants worldwide


14/94

4


Slide: 7

Legislative Considerations – Diagnostic Communications

US – California Air Resources Board (CARB)

CARB California Code of Regulations (CCR) 1968.2 (Vehicles < 14000 lbs.) CARB CCR 1971, Engine Manufacturer Diagnostics (EMD), (Vehicles > 14000 lbs.)

CARB CCR 1971.1, OBD System Requirements for 2010 and later Model-Year Heavy-Duty Engines (HD-OBD)

US – Environmental Protection Agency (EPA)

EPA, Title 40, CFR 86.8005-4, CFR 86.005-17, CFR 86.1806-05

Typically follows CARB legislation

EU – European Commission (EC)

EURO 3, 4, 5, 6, etc.= pass cars & light duty vehicles. EURO III, IV, V, VI, etc. = HD vehicles

UN/ECE Regulation Nbr. 83/2008 (light duty regs)

UN/ECE Regulation Nbr. 49/2008 (heavy duty regs)

Diagnostic Communications Requirements Summary:

CCR 1968.2 (LD) SAE J1979

CCR 1971.1 (HD) SAE J1979 or SAE J1939

UN/ECE Reg 83/2008 (LD) ISO 15031-4 (SAE J1979)

UN/ECE Reg 49/2008 (HD) ISO 27145-3 or SAE J1939-73


Slide: 8

Legal Requirements

EOBD (European On Board Diagnostics)

Necessity of Diagnostics in Motor Vehicles

96 97 98 99 00 01 02 03 04 05 06 07 08 09 10 11 12 13

Source: www.obd-2.de

Model Year

Cars, gasoline starting 2000

Cars, diesel

Trucks

MIL

Cars & Class 1-7 Trucks(OBDII – ISO9141, J1850, CAN)

Cars & Class 1-7 Trucks (CAN only required)

Trucks (Class 8)

US OBD (US On Board Diagnostics)


15/94

5


Slide: 9

Legal Requirements

OBD-II connector (SAE J1962)

P IN F un ctio n

1 Discretionary

2 Bus positive line of SAE J1850

3 Discretionary

4 Chassis ground

5 Signal ground

6 CAN_H line of ISO 15765-4

7 K line of ISO 9141-2 and ISO 14230-4

8 Discretionary

9 Discretionary

10 Bus negative line of SAE J1850

11 Discretionary

12Discretionary

13 Discretionary

14 CAN_L line of ISO 15765-4

15 L line of ISO 9141-2 and ISO 14230-4

16 Permanent positive voltage

OBD-II connector


16/94

1


V 0. 01 2 01 3- 11 -2 5

June, 2014

Diagnostic Standards – So Many to Choose From


Slide: 2

Dazed & Confused


17/94

2


Slide: 3

Diagnostic Standards

Open Standards

ISO 15765 – Diagnostics on CAN

ISO 15031 – Diagnostics for Emissions RelatedSystems (Incorporates; J1930, J1962, J1978, J1979,J2012, J2186)

UDS (ISO 14229) – Unified Diagnostic Services

KWP2000 (ISO 14230) – Key Word Protocol 2000

SAE J2534 – Pass-Thru Flash Programming

ODX (ISO 22901) – Open Diagnostic Data Exchange

WWH-OBD (ISO 27145) – World-wide HarmonizedOBD

MVCI (ISO 22900) – Multi Vehicle CommunicationsInterface

OEM Standards

GM GMW3110

Ford GGDS and MDX

Chrysler KWP2000, UDS, DDT, DPRS

Plus Toyota, FIAT, VW, Daimler, Porsche, BMW…

Coming Soon…


Slide: 4

Typical Diagnostic Standards: Car/Truck – SAE/ISO

SAE ISO Manf Specific

Pass Car & LDVeh

(KWP & UDS)

J1930

J1962

J1978

J1979

J2012

J2186

J2284

J2411

J2534

ISO 11898 (5 parts)

ISO 15765(4 parts)

ISO 14230 (4 parts)

ISO 14229 (1 part)

ISO 15031 (7 parts)

ISO 22900 (3 parts)

ISO 22901 (2 parts)

ISO 27145 (4 parts)

Several

MD & HD Veh(J1939)

J1939 (12 parts)J2403

ISO 27145 (4 parts) Several

Current Standards:

In some cases multiple standards will be mixed on the same vehicle


18/94

3


Slide: 5

Diagnostic Standards: Past – Present - Future

Pass Car & LD Veh MD & HD Veh

Past ISO9141J1850

J1708J1587

Present

J1930

J1962

J1978

J1979

J2012

J2186

J2284

J2411

J2534

ISO11898

ISO15765

ISO14230

ISO14229

ISO15031ISO22901

J1939

J2403

Future ISO27145 (WWH OBD) ??J1939 ??

ISO27145 (WWH OBD) ??


Slide: 6

Apples to Apples

OSILayer

MD & HD Standards &OBD Legislated

Pass Car & LDStandards

Pass Car & LD OBDLegislated

N/ADiagnostic

ConnectorSAE J1939-13 ISO 15031-3

(SAE J1962)

ISO 15031-3(SAE J1962)

7 ApplicationSAE J1939-71/73

SAE J1939-81

ISO 15765-3

ISO 14229-1ISO 15031-5

(SAE J1979)

6 Presentation User Defined(GMW3110, GGDS, KWP2000, etc.)

ISO 15031-5(SAE J1979)

5 Session ISO 15765-3

4Transport

ProtocolISO 15765-2 ISO 15765-2

3Network

LayerSAE J1939-31 ISO 15765-2 ISO 15765-4

2 Data Link SAE J1939-21(ISO 11898-1)

ISO 11898-1 ISO 15765-4(ISO 11898-1)

1 Physical Layer SAE J1939-11/15User Defined

(J2284, J2411, ISO11898-2/3, etc.)

ISO 15765-4(ISO 11898-2)


19/94

4


Slide: 7

H A R M O N I Z E D

Passenger Car Diagnostic Standard Reference Hierarchy

ISO 15765

ISO 15031ISO 14229

(UDS)

ISO 14230(KWP2000)

J1930SAE Recommended Practice

J1962 J1978 J1979 J2012 J2186

2 3 4 5 6 7

2 3 4

evolvedfrom

CAN-Specific

Non-CAN / Generic


Slide: 8

General

Diagnostics - International Standards (Introduction Dates)

1996 ISO 9141 CARB Requirements for Interchange ofDigital Information

1999 ISO 14230 Keyword Protocol 2000

1999 ISO/DIS 15765 Diagnostics on CAN – based on KWP2000

2001 ISO 15031 Communication for emissions-relateddiagnostics

2005 ISO 15765 Diagnostics on CAN – based on UDS

2006 ISO/DIS 14229-1 Unified Diagnostic Services (UDS)


20/94

5


Slide: 9

TLAs of UDS & ISO 15765

DID = Data ID

DLC = Diagnostic Link ConnectorDLC = Data Length Code

DTC = Diagnostic Trouble Code

ECM = Engine Control Module

ECU = Electronic Control Module

FTB = Failure Type Byte

KWP = Key Word Protocol (ISO 14230)

LID = Local ID

MIL = Malfunction Indicator Lamp

NRC = Negative Response Code

OBD = On Board Diagnostics

PCI = Protocol Control Information

PID = Parameter ID (similar to DID or LID)SID = Service ID

UDS = Unified Diagnostic Services


Slide: 10

Quote to ponder…

“The good thing about standards is that thereare so many to choose from” Keith Kreft

J1962

J2186


21/94

1


V 0. 01 2 01 3- 11 -2 5

June, 2014

ECU Addressing – Who Am I Talking Too?


Slide: 2

Physical Interface

Many Possibilities

Sensor/Aktor

Sensor Sensor Actor

LIN

Powertrain

ABS GearEngine

CAN

IC

Client

(Tester)

Diagnostic

Connector

CAN

K-Line

X-by-Wire

Flexray

ECU 1 ECU 2

Multimedia

Telephone

TV-Tuner

Navi

MOSTCD-

Player

Gateway

Comfort

ACRoof Door BCSeat

CAN


22/94

2


Slide: 3

Directing the Diagnostic Traffic

How does the tester get a diagnosticmessage to a single ECU, anywhere on thenetwork, or to a group of ECUs on thenetwork?


Slide: 4

CAN Message Structure

11 bit or 29 bit


23/94

3


Slide: 5

Directing the Diagnostic Traffic

CAN IDs

Can use either 11-bit or 29-bit

Most automotive applications use 11-bit

Each ECU has two primary CAN IDs for diagnostics

one for physical (point-to-point) requests from tester

one for responses back to the tester

Each ECU will also support one/more functional CAN IDs forbroadcast messages from the tester

The tester has to know the CAN IDs for every ECU


Slide: 6

Standard CAN Format: 11-Bit Identifier

Typically usage for diagnostics: ECU Identification

Target ECU ID or Functional Request ID for diagnostic requests (source addressnot required since KWP & UDS only allow one diagnostic tester on the bus atone time)

Source ECU ID for diagnostic responses

Most OEMs have their own ID assignment standards

Identifier "identifies" the message and includes message priority

Identifier 0 is highest priority message


24/94

4


Slide: 7

Addressing Types

Physical addressing (1:1)

Receiver known

One controller addressable

Functional addressing (1:n)

Broadcast

Receiver unknown

Multiple ECUs addressable

Possibilities – Typically Based on CAN ID Range

CU 1

CU 2

CU 3

Tester

CU 3

Tester


Slide: 8

Addressing Schemes

Normal addressing

Addressing information complete in CAN-ID

Two CAN IDs per ECU: Sending/Receiving2n(+1)

Minimal protocol overhead

Extended addressing

Addressing information “in first data byte”

Only one CAN-ID for all requests,one additional CAN-ID per node for

response (n+1)

Multiple bus systems

Elevated protocol overhead (1/8)

AB

C

AB

C

b

c


25/94

5


Slide: 9

Addressing Schemes

Normal fixed addressing (29 Bit CAN ID Only)

Addressing information complete in CAN-ID

Predefined structure of CAN ID


J1939 uses this scheme

Mixed addressing

Addressing information in CAN-ID and in “in first data byte” for the subnet


AB

C

11 or 29 bit CANId

7 Byte

(PCI +Data)

address

extension

PrioId

MaskTgt

AddrSrc

Addr

7 Byte(PCI +Data)

00address

extension

AB

C


Slide: 10

Addressing scheme

Overview

29-bit

CANID

11-bit

CANID

Mixed AddressingExtendedAddressing

Normal FixedAddressing

NormalAddressing

8Byte

(PCI+Data)

11bit

7Byte

(PCI+Data)

T

A

11bit

7Byte

(PCI+Data)

A

E

11bit

8Byte

(PCI+Data)

29bit

7Byte

(PCI+Data)

T

A

29bit

AE

SA

TA

PGN00

PrioSA

TA

PGN00

Prio

8Byte

(PCI+Data)7Byte

(PCI+Data)

TA = Target Address

SA = Source Address

AE = Address Extension

SA = Source Address


26/94

6


Slide: 11

Automotive Diagnostic Communication Model

Off-board

tester ECU 1

The tester runs the whole show Must request data it wants Must know ID of ECU to get data from ECUs provide data requested Does not listen to normal bus traffic

ECU 1-Perform this task

I did it, here’s the results

The ECU only speaks when spoken to Listens for requests from tester Provides diagnostic data only on request Never sends a diagnostic request After assembly may never be used again

ECU 2

For the diagnostic standards ISO14230 (KWP) ISO14229 (UDS)


Slide: 12

Addressing Scheme

ECU 2

Off-board

tester

ECU 1

ECU 3

200

208

201

202

209

20A

Each ECU has at least twodiagnostic CAN IDs (simplified) one/more for requests from tester one for responses to tester

The tester mustknow the CAN IDs

for every ECU on every vehicle from every OEM

it is working with.

BC 400

BC 400

BC 400


27/94

1


V 0. 01 2 01 3- 11 -2 5

June, 2014

Unlocking the Secrets of the ISO 15765-2 Transport Protocol


Slide: 2

A Quick Review of the CAN Data Field


28/94


29/94

3


Slide: 5

Possible Types of Data Transport

UUDT

Unacknowledged Unsegmented Data Transfer

Example: A CAN message (max. 8 bytes)

AUDT

Acknowledged Unsegmented Data Transfer

Example: Application protocols (“ping pong”)

USDT

Unacknowledged Segmented Data Transfer

Example: ISO 15765-2

ASDT

Acknowledged Segmented Data Transfer Example: MCNet, Volkswagen TP 2.0

sender receiver

Data

Data

Ack.

Data

Data

Data

Data

Ack.


Slide: 6

ISO15765-2 – How Does the Transport Protocol Work?

First byte(s) of data area are used to indicate TP frame type

Official name is Network Protocol Control Information

Common name is PCI

Remaining data bytes carry application (diagnostic) data

Data Area

PCI application data

SOF ID DLC ACKCRC

USDT CAN Frame Structure


30/94

4


Slide: 7

ISO15765-2 – PCI Determines Frame Type

PCI is first byte(s) of data area

PCI bits 7-4 (upper nibble) indicate frame type

0 = single frame

1 = first frame

2 = consecutive frame 3 = flow control frame

4–F are invalid and not used

X

Data Area

PCI application data

SOF ID DLC ACKCRC

USDT CAN Frame Structure


Slide: 8

ISO 15765-2

The following message types are available for data transport:

First Frame (FF)

> First part of a segmented message

Consecutive Frame (CF)

> Second part through nth part of a segmented message

Single Frame (SF)

> For transport of unsegmented messages

Flow Control (FC)

> Acknowledgment from the receiver

Message Types


31/94


32/94


33/94


34/94


35/94


36/94

10


Slide: 19

ISO 15765-2

Timing in the Transport Protocol

sender receiver

N_As

N_Bs

N_Cs

N_As

N_Br

N_Ar

N_Cr


37/94


38/94

2


Slide: 3

ISO 14229 – Diagnostic Services

What is a diagnostic “service”? A kind of a task for an ECU to execute on command

Each service is defined by a request/response message pair

Test device sends service request message to ECU

ECU sends service response message to test device

This is the client/server communication model we discussed

Let’s look at this model in a network example…


Slide: 4

KWP/UDS Diagnostic Communication Model

Off-board

tester ECU 1

The tester runs the whole show Must request data it wants Request data from single ECU ID.. Or send functional request (broadcast) ECUs provide data requested

ECU1-Perform this task (service ID)

ECU1 I did it, here’s the results

The ECU only speaks when spoken to Listens for service requests from tester Provides diagnostic data only on request Never sends a diagnostic request Not used for normal control operations

ECU 2

Two similar diagnostic standards ISO14229 (UDS) ISO14230 (KWP)


39/94

3


Slide: 5

ISO14229 – Diagnostic Service Example

Service 22 – ReadDataByIdentifier

The most basic and intuitive service

Tester is asking ECU for some piece of data

Let’s ask for the engine speed…

Tester sends request message (hex bytes) – 22 F4 0C

22 = ReadDataByIdentifier service request identifier (SID)

F40C = Engine Speed data identifier (DID)

ECU sends response message – 62 F4 0C 0F A0

62 = ReadDataByIdentifier service response identifier (SID)

F40C = Engine Speed data identifier (DID) 0FA0 = engine speed data value (0x0FA0 = 1000 RPM)


Slide: 6

ISO14229 – Service Identifiers (SIDs)

Every service has a one-byte numeric identifier associated with it

This one-byte number is known as the service identifier or “SID”

The SID and the name of the service can be used interchangeably

The SID is the first byte of the request message

The first byte of the positive response message = SID + 0x40

From our previous engine speed example:

The ReadDataByIdentifier service has an SID of 0x22

You can refer to the service as either:

ReadDataByIdentifier

- or -

Service 22

The first byte of the request message is 0x22 (the SID)

The first byte of the pos response msg is 0x62 (the SID + 0x40)


40/94

4


Slide: 7

UDS Standard vs. OEM Implementation

OEM Application of UDS

Communication Services

Standardized Data

OEM specific data &implementationrequirements

UDS Standard

Communication Services

Standardized Data


Slide: 8

There are 4 different types of UDS requests

Requests with Service ID only (e.g. SID 84)

Requests with Service ID and Subfunction

Requests with Service ID and Data ID

Requests with Service ID, Subfunction and Data ID

UDS Request Formats

SID

SID

SID

SID SF I D

I D

SF Opt. Data

Opt. Data

Opt. Data

Opt. Data


41/94

5


Slide: 9

ISO14229 – Service Subfunctions

What is a service “subfunction”? Services indicate the kind of task, but not always the exact task

Subfunctions are specific tasks a service can perform

The subfunction is always the first byte after the SID

Not all services have subfunctions (service 22 does not)

But some do (service 11 does)


Slide: 10

ISO14229 – Services with Subfunctions

Which services have subfunctions?

10 – DiagnosticSessionControl

11 – EcuReset

19 – ReadDTCInformation

27 – SecurityAccess

31 - RoutineControl

3E – TesterPresent

85 – ControlDTCSetting

And which ones don’t?

14 – ClearDiagnosticInformation

22 – ReadDataByIdentifier

23 – ReadMemoryByAddress

24 – ReadScalingDataByIdentifier

2A – ReadDataByPeriodicIdentifier

2C – DynamicallyDefineDataIdentifier

2F – InputOutputControlByIdentifier

There is no rhyme or reason to it.

It is pretty much arbitrary and you

just have to know which is which.


42/94

6


Slide: 11

Protocol Service Values


Slide: 12

The Positive Response

TPCI 22 F1 8C 00 00 00 00

TPCI 62 F1 8C 01 E2 40 00

Request(Client)

Response(Server)

+ 0x40 DID for someparameter

Parameter data

recessive

dominant


43/94

7


Slide: 13

The Negative Response

Requestby testtool

NegativeResponseby ECU

SID-NR Parameter 1 Parameter 2

0x7F SID-RQ Neg. Res. Code

SID-RQ Parameter 1 Parameter 2 Parameter 3

xx Optional Optional Optional

What if the request is invalid, or the ECU cannot

perform the request?


Slide: 14

ISO14229 – Negative Responses Codes (NRC)

10 generalReject

11 serviceNotSupported

12 subFunctionNotSupported

13 incorrectMessageLengthOrInvalidFormat

14 responseTooLong

21 busyRepeatRequest

22 conditionsNotCorrect

24 requestSequenceError

25 noResponseFromSubnetComponent

26 failurePreventsExecutionOfRequestedAction

31 requestOutOfRange

33 securityAccessDenied

35 invalidKey

36 exceedNumberOfAttempts

37 requiredTimeDelayNotExpired

70 uploadDownloadNotAccepted 71 transferDataSuspended

72 generalProgrammingFailure

73 wrongBlockSequenceCounter

78 requestCorrectlyReceived-ResponsePending

7E subFunctionNotSupportedInActiveSession

7F serviceNotSupportedInActiveSession

81 rpmTooHigh

82 rpmTooLow

83 engineIsRunning

84 engineIsNotRunning

85 engineRunTimeTooLow

86 temperatureTooHigh

87 temperatureTooLow

88 vehicleSpeedTooHigh

89 vehicleSpeedTooLow

8A throttle/PedalTooHigh

8B throttle/PedalTooLow

8C transmissionRangeNotInNeutral

8D transmissionRangeNotInGear

8F brakeSwitch(es)NotClosed 90 shifterLeverNotInPark

91 torqueConverterClutchLocked

92 voltageTooHigh

93 voltageTooLow

For every reason an ECU can have for rejecting a request, there is an NRC


44/94


45/94


46/94


47/94

11


Slide: 21

Excerpt from ISO 14229-1

02 11 03 xx xx xx xx xx

02 51 03 xx xx xx xx xx

Example - ECU Reset

Request

Pos.Response

Neg.Response

Request - ECUReset

xx – don’t care

TPCI - SingleFrame

ECUReset Type - SoftReset

Pos.Response (SID + 0x40)

TPCI - SingleFrame

ECUReset Type - SoftReset

03 7F 11 22 xx xx xx xx

Neg.Response

TPCI - SingleFrame

NRC Type – Conditions not correctECUReset


Slide: 22


ClearDiagnosticInformation – 0x14

Request

Response

Databyte

Parameter Name Cvt HexValue

Mnemonic

#1 ClearDiagnosticInformation Request Service Id M 14 CDTCI

#2#3#4

groupOfDTC[] = [groupOfDTCHighBytegroupOfDTCMiddleBytegroupOfDTCLowByte ]

MMM

00-FF00-FF00-FF

GODTC_ HBMBLB

Databyte


Mnemonic

#1 ClearDiagnosticInformation Positive ResponseService Id

M 54 CDTCIPR


48/94

12


Slide: 23


Example - ClearDiagnosticInformation

04 14 00 00 00 xx xx xx

01 54 xx xx xx xx xx xx

Request

Pos.Response

Neg.Response

Request - ClearDiagnosticInformation

xx – don’t care

TPCI - SingleFrame

Group of DTC


TPCI - SingleFrame

03 7F 14 22 xx xx xx xx

Neg.Response

TPCI - SingleFrame

NRC Type – Conditions not correctClearDiagnosticInformation


Slide: 24


ReadDataByIdentifier – 0x22

Request

Response

DataByte


Mnemonic

#1 ReadDataByIdenti fier Request Service Id M 22 RDBI

#2#3

dataIdentifier[] #1 = [byte#1 (MSB)byte#2 ]

MM

00-FF00-FF

DID_ B1B2

: : : : :

#n-1#n

dataIdentifier[] #m = [byte#1 (MSB)byte#2 ]

UU

00-FF00-FF

DID_ B1B2

DataByte


Mnemonic

#1 ReadDataByIdentifier Response Service Id M 62 RDBIPR

#2#3

dataIdentifier[] #1 = [byte#1 (MSB)byte#2 ]

MM

00-FF00-FF

DID_ B1B2

#4:

#(k-1)+4

dataRecord[]#1 = [data#1

:data#k ]

M:U

00-FF:

00-FF

DREC_ DATA_1

:DATA_m

: : : : :


49/94

13


Slide: 25


03 22 F1 86 xx xx xx xx

04 62 F1 86 02 xx xx xx

Example 1- ReadDataByIdentifier

Request

Pos.Response

Neg.Response

Request - ReadDataByIdentifier

xx – don’t care

TPCI - SingleFrame

Data Identifier - ActiveDiagnosticSession


TPCI - SingleFrame

Data Identifier - ActiveDiagnosticSession

DiagnosticSessionType - ProgrammingSession

03 7F 22 22 xx xx xx xx

Neg.Response

TPCI - SingleFrame

NRC Type – Conditions not correct

ReadDataByIdentifier


Slide: 26


05 22 01 0A 01 10 xx xx

07 62 01 0A 55 01 10 66

Example 2- ReadDataByIdentifier

Request

Pos.Response

Request - ReadDataByIdentifier

xx – don’t care

TPCI - SingleFrame

2x Data Identifier


TPCI - SingleFrame

Data Identifier 1 + data

Data Identifier 2 + data


50/94


51/94

15


Slide: 29

Session & Security Management

Some diagnostic features should not be easily accessible.Examples:

I/O Control

Flash Programming

Writing ECU Configuration Information

How are these protected?

By using special “sessions” or “security”


Slide: 30

Session Management

ECUs can support several sessions

Typical ECU sessions are: Default Session, Extended Session andProgramming Session

Some diagnostic services can only be executed in a specialsession

Sessions can support different timing parameters

As a result of a diagnostic service a state transition can beeffected

Normally an ECU starts in default session after power on


52/94

16


Slide: 31

Session Management

Example

Parameter

Default Session: 0x10 01

Programming Session: 0x10 02

Extended Session: 0x10 03

To change a session into an ECUthe protocol service 0x10DiagnosticSessionControl is used

Power On


Slide: 32

Security Access

Some diagnostic data or services can be restricted due to safetyreasons. To get access to these ECUs a Seed&Key process is used.

Tester ECU

Compare KeyIf (Key = Key)

unlock ECU

Calc Key


53/94

17


Slide: 33

ISO14229 – Service 19 ReadDTCInformation

The most valuable and frequently used service Tester asks the ECU for its state of health and any observed failures

Failures are specified with a three-byte identifier called a “DTC”

DTC = Diagnostic Trouble Code

Allows tester to read fault-related data stored in ECU memory

This is the very foundation of all vehicle diagnostics

ECUs monitor their own state of health with diagnostic monitors

These monitors generate a lot of data

This data is stored indefinitely in the ECU’s non-volatile memory

Testers can recall this data at a later time during testing and service

When ECU diagnoses itself with a failure, it stores a DTC


Slide: 34

ISO14229 – Service 19 ReadDTCInformation

Available sub functions of service 19: 01 – reportNumberOfDTCByStatusMask

02 – reportDTCByStatusMask

03 – reportDTCSnapshotIdentification

04 – reportDTCSnapshotRecordByDTCNumber

05 – reportDTCSnapshotRecordByRecordNumber

06 – reportDTCExtendedDataRecordByDTCNumber

07 – reportNumberOfDTCBySeverityMaskRecord

08 – reportDTCBySeverityMaskRecord

09 - reportSeverityInformationOfDTC

0A – reportSupportedDTC

0B – reportFirstTestFailedDTC

0C – reportFirstConfirmedDTC

0D – reportMostRecentTestFailedDTC

0E - reportMostRecentConfirmedDTC

0F – reportMirrorMemoryDTCByStatusMask

10 – reportMirrorMemoryDTCExtendedDataRecordByDTCNumber

11 – reportNumberOfMirrorMemoryDTCByStatusMask

12 – reportNumberOfEmissionsOBDDTCByStatusMask

13 – reportEmissionsOBDDTCByStatusMask 14 – reportDTCFailedDetectionCounter

15 – reportDTCWithPermanentStatus

16 – reportDTCExtDataRecordByRecordNumber

17 – reportUserDefMemoryDTCByStatusMask

18 – reportUserDefMemoryDTCSnapshotRecordByDTCNumber

19 - reportUserDefMemoryDTCExtDataRecordByDTCNumber


54/94

18


Slide: 35

ISO14229 – Service 19 Example

Let’s suppose we want to know what DTCs are problems right now…

Tester sends request message – 19 02 08

19 = ReadDTCInformation service request identifier (SID)

02 = reportDTCByStatusMask mode (19 has many different modes)

08 = confirmedDTC status mask (just DTCs whose status = failed)

ECU sends response message – 59 02 08 06 20 13 8A

59 = ReadDTCInformation service response identifier (SID)

02 = reportDTCByStatusMask mode

08 = confirmedDTC status mask

062013 = DTC Generator Control Circuit – circuit open

8A = status mask for DTC 062013


Slide: 36

ISO14229 – Diagnostic Trouble Codes (DTCs)

ECUs communicate their failures via three-byte numeric identifiers

This number is known as a diagnostic trouble code or “DTC”

Root DTC

The first two bytes (16 bits) of the DTC

Identifies the ECU component that has failed

The upper two bits of the root identify the major system

> 00 = P-code for Powertrain

> 01 = C-code for Chassis

> 10 = B-code for Body

> 11 = U-code for Network (I don’t get it either)

FTB – Failure Type Byte The last byte (8 bits) of the DTC

Identifies the failure mode detected by the ECU


55/94


56/94

20


Slide: 39

Wiring faults are the most common type of failure

Wiring is difficult to install properly

Little or no protection from pulling, bending, cutting, interference

Common wiring failures and their Failure Type Bytes (FTBs)

11 – circuit short to ground

line exposed to ground - voltage pulled low

12 – circuit short to battery

line exposed to power - voltage pulled high

13 – open circuit

line broken - resistance is infinite

Open circuit accounts for most failures and deserves attention

ISO14229 – FTBs and Wiring Faults


Slide: 40

DTCs have status information associated with them

There are eight independent states possible

Each state is represented as a bit in a status byte

Bit 7 – warningIndicatorRequest

Bit 6 – testNotCompletedThisMonitoringCycle

Bit 5 – testFailedSinceLastClear

Bit 4 – testNotCompletedSinceLastClear

Bit 3 – confirmedDTC

Bit 2 – pendingDTC

Bit 1 – testFailedThisMonitoringCycle

Bit 0 – testFailed

ISO14229 – DTC Status Byte


57/94

21


Slide: 41

ISO14229 – DTC Status Byte Example

Let’s go back to our service 19 example...

Tester sends request message – 19 02 08

19 = ReadDTCInformation service request identifier (SID)

02 = reportDTCByStatusMask mode

We want to read just the DTCs with a specific status

Could be any number of DTCs coming back in response

08 = confirmedDTC status mask

In this case, we want just those that are confirmed failures

08 = 0000 1000; bit 3 – confirmedDTC = 1, all others = 0


Slide: 42

ISO14229 – DTC Status Byte Example (continued)

Let’s go back to our service 19 example...

ECU sends response message – 59 02 08 06 20 13 8A

59 = ReadDTCInformation service response identifier (SID)

02 = reportDTCByStatusMask mode (echoed from request)

08 = confirmedDTC status mask (echoed from request)

062013 = DTC Generator Control Circuit – circuit open

8A = status mask for DTC 062013

8A = 1000 1010

> Bit 7 – warningIndicatorRequested = 1

> Bit 3 – confirmedDTC = 1

> Bit 1 – testFailedThisMonitoringCycle = 1

> So, not only is the DTC confirmed,

but it continues to fail and is illuminating the engine lamp


58/94

22


Slide: 43

For reprogramming the following services are relevant

Control DTC Setting (to enable/disable DTCsetting)

Communication Control: enable/disablenormal bus communication for ECUs

Request Download

Transfer Data (transfers data)

Request Transfer Exit

Reprogramming

36

37

85

28

34


Slide: 44

The service Read Data By Periodic Identifierstarts periodic sending of data by the ECU.

The following subfunctions are supported

Periodic Reading

2A SF ID

SF Description

01 Send At Slow Rate

02 Send At Medium Rate

03 Send At Fast Rate

04 Stop


59/94

23


Slide: 45

Suppress Positive Response Message Indicator Bit

MSB Description

0 Positive Response - not suppressed

1 Positive Response - suppressed

SID SF

Tester

M S B

7 6 5 4 3 2 1 0

Only applies to subfunctions, not services, DIDs or any other ID Setting SPRMIB to 1 is the same as adding 0x80 to the subfunction

Only suppresses positive response, not negative response


Slide: 46

ISO14229 – SPRMIB Example

First, without using the SPRMIB

Tester sends request message – 85 01

85 = ControlDTCSetting service request identifier (SID)

01 = on, the subfunction

ECU sends response message – C5 01

C5 = ControlDTCSetting service response identifier (SID)

01 = on, the subfunction

Now, let’s set the SPRMIB to 1

Tester sends request message – 85 81

85 = ControlDTCSetting service request identifier (SID)

81 = on, the subfunction with the SPRMIB (upper bit) set to 1

ECU turns DTC setting on, but does not send a positive response


60/94

24


Slide: 47

ISO14229 – Service 2F InputOutputControlByIdentifier

Some DIDs represent I/O values

I/O devices and values are also DIDs

I/O DIDs can be controlled by testers

Control modes

02 = freezeCurrentState

Hold the DID at its current value

For inputs this means ignore incoming changes

For outputs this means locking the value

03 = shortTermAdjustment

Temporarily control the DID value

For inputs this means substituting for the incoming value

For outputs this means overriding the control algorithm

00 = returnControlToEcu


Slide: 48

ISO14229 – Service 2F Example

Let’s suppose we want to control the cabin fan

Tester sends request message – 2F 9B 1D 03 64

2F = InputOutputCotnrolByIdentifier service request identifier (SID)

9B1D = Cabin Fan Speed data identifier (DID)

03 = shortTermAdjustment (temporary override/control)

64 = Cabin Fan Speed data value (0x64 = 100rpm)

ECU sends response message – 6F 9B 1D 03 64

6F = WriteDataByIdentifier service response identifier (SID)

9B1D = Cabin Fan Speed data identifier (DID)

03 = shortTermAdjustment (temporary override/control)

64 = Cabin Fan Speed data value (0x64 = 100rpm)


61/94

25


Slide: 49

ISO14229 – Service 3E TesterPresent

Doesn’tdo

anything, but helps manage diagnostic applications Some diagnostic services have persistent behavior, like:

Diagnostic session changes via Service 10

Security access changes via Service 27

Controlling DTC setting via Service 85

Output device control via Service 2F

Routines run via Service 31

These services must be actively supervised by the tester

They drive behavior outside the normal operations of the ECU

If the tester should lose contact with the ECU, the service must stop

TesterPresent allows the tester to stay in touch with the ECU,

but doesn’t cause the ECU to do anything extra


Slide: 50

ISO14229 – Service 3E Example

Tester sends request to stop setting DTCs – 85 02

Temporary state that only makes sense during test procedure

But what if the tester is accidentally disconnected?

The ECU can not stay in this mode forever

How does the ECU know how long to continue?

There is a timeout on all such persistent services

If ECU stops getting requests, it must assume the tester disconnected

Left unsupervised by the tester, the ECU must stop all persistent services

Tester sends a TesterPresent request – 3E 00

There is nothing more for the ECU to do but continue not setting DTCs

The tester send yet another TesterPresent message – 3E 00

The ECU continues not setting DTCs

This can go on for as long as the tester wants it to continue


62/94

26


Slide: 51

ISO14229 – Service 3E TesterPresent

Some important timing parameters:

P2 = Maximum time to start response after message sent

P2 Ext = Additional time allowed for response to start, after a NRC 0x78is received

S3 = Maximum time allowed in non-default session without some type ofmessage activity from the tester (0x3E Tester Present, or othermessage)

NRC 0x78 = Negative Response Code transmitted if need more time torespond


Slide: 52

default

Session

programming

Session

extendedDiagnostic

Session

10 02

start

ISO14229 – Service 10 DiagnosticSessionControlISO14229 – DiagnosticSessionControl Revisited

Session Transitions with S3 timeout

543210


63/94

1


V 0. 01 2 01 3- 11 -2 5

June, 2014

Running UDS on Different Bus Types


Slide: 2

UDS is Designed to Work on Multiple Bus Types

From ISO 14229-1:


64/94

2


Slide: 3

ISO 14229 Restructured

Part 1: Specification and requirements

Part 2: Session layer services

Part 3: Unified diagnostic services on CAN implementation(UDSonCAN)

Part 4: Unified diagnostic services on FlexRay implementation(UDSonFR)

Part 5: Unified diagnostic services on Internet Protocolimplementation (UDSonIP)

Part 6: Unified diagnostic services on K-Line implementation(UDSonK-Line)

Part 7: Unified diagnostic services on Local Interconnet Network

(UDSonLIN)


Slide: 4

Coexistence of UDS & J1939


65/94

3


Slide: 5

UDS/KWP Message Compared to J1939 Message

Tester ECU

Cyclic Diagnostic Messages (e.g. DM1)J1939

[[Prio + Request PGN + Dest Addr + Src Addr] [Requested PGN]]

- or -

ECUTester

UDS/KWP

[[Target ID] [Requested Service + Requested Data]]

[[Source ID] [Requested Service ID + Requested Data]]

(Services can be data requests, fault coderequests, output control, special test requests,security access, reprogramming requests, etc.)

[[Prio + Requested PGN + Dest Addr + Src Addr] [PGN Data]]

Single Frame Message


Slide: 6

J1939 and ISO15765 Coexistence on the same CAN bus

There 2 are ways defined to allow for ISO 15765 communication to occur ona J1939 bus

One way is using J1939 PGNs. The structure of the CAN ID is exactly thesame as any other J1939 message

There are 4 reserved J1939 PGNs for this purpose:

0x00CD00 Mixed Addressing Functional

0x00CE00 Mixed Addressing Physical

0x00DA00 Normal fixed addressing Physical

0x00DB00 Normal fixed addressing Functional

Note that these PGNs are Destination Specific and both data page bits arezero!

In current projects within Deere this method is used, with PGN 0x00DA00


66/94

4


Slide: 7

J1939 and ISO15765 Coexistence

The second way formats the CAN ID in a way that will not interfere with anyother CAN IDs on the J1939 Network

The two Data Page bits (EDP and DP) are set to 1. Differentiates thesemessages from any other on the network to avoid conflicts.

Everything else in the CAN ID is particular to ISO-15765 definition

Note that the Source Address and Destination Address fields shown here areNOT the same as the J1939 Source and Destination Addresses!

There are other means defined in ISO17565 to use both 11 bit and 29 bitCAN IDs which are not compatible with J1939. These might be used inautomobile networks for example.


Slide: 8

J1939 DM’s Compared to UDS Services

J1939 Diagnostic Message: Similar UDS Service:

DM1 – Active DTCs $19 $02 – Report DTCs by Status

DM2 – Previously Active DTCs $19 $02 – Report DTCs by Status

DM3 – Clear/Reset DTCs $14 – Clear DTCs

DM4 – Freeze Frame Data $19 $05 – Report Freeze Frame

DM5 – Diagnostic Readiness $19 $01 – Report # DTCs by Status

DM6 – Pending DTCs $19 $02 – Report DTCs by Status

DM7 – Command Non-Cont Test $31 $01 – Start Routine

DM8 –Results for Non-Cont Test $31 $03 –Routine Results

DM9 – O2 Sensor Test Results $31 $03 – Routine Results

DM10 – Non-Cont Tests Supported - No Equivalent -

DM11 – Clear/Reset Active DTCs $14 – Clear DTCs

DM12 – Emissions Related Active DTCs $19 $02 – Report DTCs by Status

DM13 – Start/Stop Broadcast Messages $28 – Communication Control

DM14 – Memory Access Request $23 – Read Memory by Address

DM15 – Memory Access Response $63 – Pos Response to $23

DM16 – Binary Data Transfer $36 – Transfer Data


67/94

1


V 0. 01 2 01 3- 11 -2 5

June, 2014

ODX – What It Is, and What It Isn‘t


Slide: 4

History Lesson

# Diagnostic Trouble Codes:

1984 Chevrolet Cavalier 15

1987 Cadillac Allante’ 84

1990 Buick Riviera 82

2006 Volkswagen Jetta ~2,000

2008 Chrysler T&C ~1200

The average vehicle today has 20+ ECUs


68/94

2


Slide: 5

Data Complexity

Example: Yesterday

1 OEM 10 Model Lines

50 Fault Codes per Model Line

= 500 Fault Code Entries

If supporting 10 OEMs:

5,000 Fault Codes to Manage

(data from 10 different sources)

Not to mention:

PIDs, DIDs, SIDs, CPIDs, Sessions, NRCs, PRCs, FTBs, Seeds,Keys, Freeze Frame Data, Monitor Data, ECU Config Data …

Example: Today

1 OEM

10 Model Lines

1,200 Fault Codes per Model Line

= 12,000 Fault Code Entries 120,000 Fault Codes to Manage

(data from 10 different sources)


Slide: 6

Definition

What is ODX?

Open Diagnostic data eXchange


69/94

3


Slide: 7

What ODX is Not!!

ODX is Not ... a protocol

ODX is Not ... the same as ODS

ODX is Not … the same as OTX

ODX is Not ... for ECU flash data only

ODX is Not ... being mandated (at this time)


Slide: 8

What is ODX?

Data format for exchange of diagnostic data

Development within ASAM & is now an ISO standard

Jointly developed with ISO (International StandardsOrganization) – ISO22901-1

ASAM = Association for Standardisation of Automation andMeasuring Systems


70/94

4


Slide: 9

Motivation

Data reuse in Development, Production, Service

Use diagnostic data for specification, test, software generation

Vehicle diagnostics

Machine readable

Ł Harmonize tools, methods and know-how

Objectives of ODX

ServiceManufacturingDevelopment

01001001Identical datain differentdepartments

Identical datain different tools

Authoring

V al i d a t i on

PDF/RTF

T e s t e r

AND


Slide: 10

Scope of ODX

Joint ASAM/ISO working group

Components of the standard

Components of the standard

UML Model XML Schema Checker RulesTextualDescription


71/94

5


Slide: 11

Use Cases

Releases

Diagnostic Layer Container

Vehicle Info Spec

Comparam Spec

Multiple ECU Jobs

Flash Data

Maintenance release of ODX 2.0.0

Function Dictionary

Ecu Configuration

Rework of Functional Addressing

Improved UDS support

ISO 22901-1

2004

2005

2006

2008

ODX 2.0.0

ODX 2.0.1

ODX 2.1.0

ODX 2.2.0

I n c om p a t i b i l i t i e s


Slide: 12

Use Cases

Tester-Application

ASAM MCD-2DODX

ISO 22901-1

D PDU API

ISO 22900-2

Hardware Interface

ISO 22900-1

ASAM MCD-3D API

ISO 22900-3

MCD-2D and MCD-3D

Source: ASAM e.V.


72/94

6


Slide: 13

Practical Application

Required Information

Which ECUs? Access?

Communication parameters?

Which services are available?

How are functions distributed across ECUs?

How to change ECU configuration options?

What data to flash to ECU?

What jobs require simultaneouscommunication with multiple ECUs?

Server

DiagnosticData

Client(Off-Board Tester)

ODX

VEHICLE-INFO-SPEC

COMPARAM-SPEC

DIAG-LAYER-CONTAINER

FUNCTION-DICTIONARY

ECU-CONFIG

FLASH

MULTIPLE-ECU-JOB-SPEC


Slide: 14

ODX Catagories

Jobs ODX-M

Function orienteddiagnostics ODX-FD

ECU configuration ODX-E

Flash data ODX-F

Vehicle access ODX-V

Communicationparameter libraries ODX-C/-CS

Diagnosticservices and jobs ODX-D

Off-boardTester

Defined by the Data Model

.PDX files:

Contains one or several odx files

Zip file, but with extension .pdx


73/94

7


Slide: 15

ODX Files

One ODX file contains exactly one ODX category

odx-c (COMPARAM-SPEC)

odx-d (DIAG-LAYER-CONTAINER)

odx-f (FLASH)

odx-m (MULTIPLE-ECU-JOB)

odx-v (VEHICLE-INFO-SPEC)

odx-e (ECU-CONFIG)

odx-fd (FUNCTION-DICTIONARY)

odx (usable for any category)


Slide: 16

Hint: PDX files (Packed ODX)

ODX files

In any case one ODX file contains exactly one ODX-CATEGORY

File extensions for each category are suggested

PDX files

Contains one or several odx files.

Intention: PDX represents ECU or vehicle

Zip file, but with extension .pdx

May contain additional files: Picture, text, java code …

Must contain a file index.xml which contains the content of thepackage.


74/94

8


Slide: 17

ODX in Practice

ODX supports many use cases ofdiagnostic data.

High complexity

Tools support different sub-sets

Common approach:

Definition of ODX sub-setrelevant for the process-savedata exchange

= Authoring guideline

Checker Tool

Authoring guidelines

ODX standard

Sub-set supported bytool A

Sub-set relevantfor data

exchangebetween thetools A and B

Sub-set supported bytool B


Slide: 18

ODX in Vector Tools


75/94

1


V 1.0 2013-10-04

June, 2014

An ECU Diagnostic Development Process – from A to Z


Slide: 2/26

Agenda

> Requirements Engineering

ECU Software

Diagnostic Testers

Diagnostic Development Process

An Exemplary Tool Chain

Summary


76/94

2


Slide: 3/26

Requirements unclear or misleading Room for (mis-) interpretation

Ł Additional need to readjust, results in increased efforts and delay

Requirements incomplete

One single requirement not comprehensive

In it’s entirety, i.e. requirements missing

Ł Additional need to readjust, results in increased efforts and delay

Requirements too concrete or solution-oriented in thebeginning

Ł Solution space is restricted without a need (e. g. prevents reuse)

Requirements Engineering

Risks


Slide: 4/26

Data formats for requirements need flexibility

One format covering many different domains

Everything needs to gets in (often no specification quality)

Little restrictions, little formalization

Use Domain specific specification formats for requirementsdocumentation? No!

Too formal

Too precise

Focused on one domain, inappropriate for others

Differentiate requirements and domain specific specifications!


Formalization


77/94

3


Slide: 5/26

Agenda


> ECU Software

Diagnostic Testers



Summary


Slide: 6/26

AUTOSAR = AUTomotive Open System ARchitecture

Hardware abstraction

Well-defined interfaces

Standardized behavior of basic software

Standardized data exchange formats

Harmonized methodology for automotive software development

Supports model based function development

Scalable over all classes of vehicles and ECU

Considers safety requirements according to ISO 26262

ECU Software

AUTOSAR


78/94

4


Slide: 7/26

ECU Software

AUTOSAR

Function Library

Seat Adjustment A

Seat Adjustment B

Lighting

Seat Heating

Air Conditioning

Vehicle A

ECU Extractof SystemDescription

Vehicle B

HardwareTopology

DistributedSystem

SoftwareConfiguration

Reuse of functions in different vehicles


Slide: 8/26

ECU Software

AUTOSAR

ECU

SWC1 SWC2

RTE

AUTOSAR BSW

Microcontroller

ComplexDeviceDrivers

MicrocontrollerAbstraction Layer

ECU Abstraction Layer

Service Layer

80 BSW modules in 3 layers


79/94

5


Slide: 9/26

ECU Software

AUTOSAR

Diagnostics is part of Basic Software (BSW)

Diagnostic Communication Manager (DCM)

Handles diagnostic protocol (UDS and/or OBDII)

Assembles any request information

Configured with ECU Configuration Description

Diagnostic Event Manager (DEM)

Handles fault memory (UDS and/or OBDII)

Manages retention of faults and snapshot data

Provides API to fault memory, e.g. for DCM

Function Inhibition Manager (FIM)

Deactivates selected functions in case of active faults

Manages substitute functions

Prevents inherited faults

System / Memory /Communication Services

FIM

Communication HardwareAbstraction

Communication Drivers

DEM DCM

Bus TP

PDURouter

BusIF

BusDriver


Slide: 10/26

Agenda


ECU Software

> Diagnostic Testers



Summary


80/94

6


Slide: 11/26

Working for multiple vehicles lines (and their ECUs)

Usually generic and data driven

Based on standardized APIs (SAE PassThru, ISO D-PDU-API,ISO MVCI)

Diagnostic data contains all information relevant for vehicleand ECU diagnostics

Diagnostic communication: Protocol, settings, ...

Diagnostic services: Semantics, structure, content, ...

Diagnostic data: Meaning, interpretation, units, ...

Diagnostic trouble codes: Meaning, related snapshot data, ...

Security mechanisms

All in different languages and localization

Diagnostic Testers


Slide: 12/26

Huge amount of data requires efficient mechanisms fordata minimization, e.g. by avoiding redundancies

Runtime format for tester parameterization

Often binary (performance and encryption)

Often vehicle manufacturer-specific, often tool-vendor-specific

Contents often generated from ODX (ISO 22901-1)

Original data format, used in engineering

Mostly XML based

Often vehicle manufacturer-specific, often tool-vendor-specific,

e.g. FORD MDX or Vector CDD Often exported to ODX (ISO 22901-1) for data exchange

Diagnostic Testers


81/94

7


Slide: 13/26

Agenda


ECU Software

Diagnostic Testers

> Diagnostic Development Process


Summary


Slide: 14/26


Iterations

Requirements

Specifications

TesterData

ECUConfiguration

Tester ECUDiagnostic

Communication


82/94


83/94

9


Slide: 17/26

You get each and every requirements into your system,requirements are domain spanning including diagnostics.

It shall be possible to reuse data from earlier process steps.

The tool chain shall support the iterative process, i.e. datais changing, causes changes in related data.

Requirements shall be traceable.

If a requirement item is already formal, it shall be possibleto generate the corresponding specification item.


Requirements for a Tool Chain


Slide: 18/26

Agenda


ECU Software

Diagnostic Testers


> An Exemplary Tool Chain

Summary


84/94

10


Slide: 19/26


Requirements

IBM DOORS

Specification

CANdelaStudioExportImport

Export

ECU Software

DaVinci

ConfiguratorPro

Validation

CANoe.DiVaa

Diag Tester

CANoeCANapeIndigo

Any Tester

ODX

CDD


Slide: 20/26


Diagnostic Requirements

Requirements

IBM DOORS

Specification

CANdelaStudio

ECU Software

DaVinciConfigurator

Pro

Validation

CANoe.DiVaa

Diag Tester

CANoeCANapeIndigo

Any Tester

ODX

CDD

Engineer and manage requirementsfor all domains in one system,including diagnostics


85/94


86/94

12


Slide: 23/26


Diagnostic Validation

Requirements

IBM DOORS

Specification

CANdelaStudio

ECU Software

DaVinci

ConfiguratorPro

Validation

CANoe.DiVaa

Diag Tester

CANoeCANapeIndigo

Any Tester

ODX

CDD

Generate test cases based ondiagnostic data

Execute test cases in CANoe

Analyze test results in Report View:

Filter, group and comment failed tests.


Slide: 24/26


Use Diagnostic Tester

Requirements

IBM DOORS

Specification

CANdelaStudioExportImport

Export

ECU Software

DaVinciConfigurator

Pro

Validation

CANoe.DiVaa

Diag Tester

CANoeCANapeIndigo

Any Tester

ODX

CDD

CANoe: Test, simulate, analyze network+ integrated diagnostic tester

CANape: Measure and calibrate a system+ integrated diagnostic tester

Indigo: Easy-to-use diagnostic tester


87/94


88/94

1


V 0. 01 2 01 3- 11 -2 5

June, 2014

The Future of Diagnostic Technology


Slide: 2

UDS Implementation Trends

All European car makers already switched to UDS standard

The first car with broad UDS implementation is on the streetsince 2004.

The American market is diversified:

Most OEMs have moved, or are moving, to UDS

The Asian market is less certain

Some OEMs change, some seem to just wait and see...


89/94

2


Slide: 3

Where is Diagnostics Heading?

More Complexity?

More Standards?

More legislation?

More Cooperation Between OEMs?

Worldwide Harmonization?

What about the end customer?

Is there a point of diminishingreturns?

Are automobiles becoming like VCRs?

Can technicians keep up?


Slide: 4

Hot Topics in Diagnostics Today

Access to vehicle data by aftermarket plug-in tools

I/M Stations

Insurance dongles

Personal data loggers / telematics systems

Multiple “testers” on the bus simultaneously

CAN ID support for more than 8 legislated ECUs

Differences in legislative requirements between:

Pass car & trucks

US, EU & Rest of World

DOIP (ISO 13400)

CAN FD impact on diagnostic specs Security of vehicle data & functionality

“Right to Repair” laws

Prognostics


90/94

3


Slide: 6

CAN FD


Slide: 7

What is CAN-FD?

CAN-FD (proposed to be ISO 11898-7) is a serial communicationsprotocol similar to and compatible with ISO 11898-1

Designed as a higher bandwidth network compatible with CAN

Supports dual bit rates within a message

Arbitration-Phase – same bit rate as standard CAN

Data-Phase – sub-multiple of controller clock rate

Supports larger data lengths than “standard” CAN

Offers increased data transmission efficiency

Transmit/receive up to 64 bytes/message


91/94

4


Slide: 8

What is CAN-FD?

Differences from CAN are limited to CAN-FD controller hardware

Usable with existing CAN transceivers up to 2-3 Mbit/sec

Legacy SW usable

Data field up to 8 bytes in length

System cost similar to standard CAN

Progressively introduce CAN-FD nodes into standard networks

First commercial silicon to be available at end of 2012

Dual rate clock, DLC ≤ 8


Slide: 9

Why CAN-FD?

CAN networks reached p

vector diagnostics seminar

Documents