Diagnose über CAN - emotive · 1-ed Mapping mechanism inside the runtime system for environment...

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

2

Dia

gnos

esys

tem

e im

Aut

omob

il

OTX Basic concepts Open Diagnostic Framework Demonstration

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Diagnostic Process Chain – Past

3

Dia

gnos

esys

tem

e im

Aut

omob

il


Production Development Diagnostic system

supplier

System supplier Service

The conventional diagnostic process is characterized by an heterogeneous

exchange of diagnostic information.

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Diangostic Process Chain – Future: OTX/ODX

4

Dia

gnos

esys

tem

e im

Aut

omob

il


Exchange of standardized diagnostic data throughout all stages of the

vehicle life cycle – basic principle: Single Source

Production Development Diagnostic system

supplier

System supplier Service

Supplier Diagnostic Database

Manufacturer Diagnostic Database

OTX ODX

Internet

OTX ODX

OTX ODX

OTX ODX

Manufacturer Diagnostic Database

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

ECU ECU ECU

Test- und Diagnoseanwendungen

OTX – Open Diagnostic Test sequence eXchange

5

Dia

gnos

esys

tem

e im

Aut

omob

il


Modular VCI

Runtime System (MVCI, ISO 22900)

D-Server API, MCD 3 (ISO 22900-3)

D-PDU API, MCD 1 (ISO 22900-2)

OTX (ISO 13209)

Vehicle Communication Interface – VCI

OD

X, M

CD

2

(ISO

22901-1

)

API

Test and Diagnostic applications

OTX

ODX

OTX = Open Test sequence eXchange (ISO 13209)

Domain specific language on high abstraction level

Goal: Formal, graphical description of diagnostic sequences

Platform and tester independent exchange format

Includes powerful concepts to reduce complexity

Process safe alternative for Java-Jobs in ODX

Application area: Vehilce diagnostics, Test automation, HIL-Simulation etc.

Initial application: exchange format for ODX based diagnostic sequences

Only through OTX/ODX there is a complete, data-driven solution for the complete process chain

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Diagnostic Sequnces in interaction with user and vehicle

6

Dia

gnos

esys

tem

e im

Aut

omob

il


GUI

External sensors

& actors

Off-Board

Kommunikation

Test sequence

Diagnostic tester in development, production & service

Request/Response

ECUs x?

y? z?

A

B C C‘ D

E E‘ Recursive

function call

ShowScreen

OTX

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Application in the Diagnostic Process

7

Dia

gnos

esys

tem

e im

Aut

omob

il


OTX

ECU

manufacturer

Development

of diagnostic

functions

Diagnostics

in

production

HIL-Tests After-Sales

Diagnostics

Diagnostic

Docu (GVO, Euro 5,

Hotline …)

Development Production Service

Goal: Exchanging and archiving verified tested

diagnostic sequences

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Interfaces & Extenstions

8

Dia

gn

ose

syst

em

e im

Au

tom

ob

il


DiagCom

Environment Event

… Job/Flash

I18n

StringUtil Math

Measure

Quantities

Diagnostic Tester Application

Diagnoseanwendung (Tester) Diagnostic Runtime System (e.g. MVCI Server, D-Server, …)

Diagnoseanwendung (Tester)

Measurement Data Acquisition

Diagnoseanwendung (Tester) Other Device

(e.g. HIL-API, ASAM GDI)

OTX Core Processing System

OTX

HMI

Diagnoseanwendung (Tester) HMI Device (e.g. Keyboard,

Mouse, Screen …)

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Simple OTX Sequence

9

Dia

gnos

esys

tem

e im

Aut

omob

il


<otx name="ODFProject1" package="Package1" version="0.9.4" timestamp="2010-10-13T09:34:08">

<validities>

<validity name="Validity1">

<realisation xsi:type="BooleanLiteral" value="true" />

</validity>

</validities>

<procedures>

<procedure name="Workflow1">

<realisation>

<declarations>

<variable name="Variable1">

<realisation>

<dataType xsi:type="Integer" />

</realisation>

</variable>

</declarations>

<flow>

<action name="setContextDataActivity1" id="setContextDataActivity1">

<specification>Umgebungsvariable setzen ...</specification>

<realisation xsi:type="env:SetContextData">

<env:identifier xsi:type="StringLiteral" value="data1" />

<env:term xsi:type="StringLiteral" value="abc" />

</realisation>

</action>

</flow>

</realisation>

</procedure>

</procedures>

</otx>

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

OTX Timeline

10

Dia

gnos

esys

tem

e im

Aut

omob

il


19/12/2008

New Work Item

Proposal

submission to ISO

Mile stone Today

V 0.9 (Schwabing)

V 0.9.1 (Wolfsburg)

V 0.9.2 (Aachen)

V 0.9.3 (Sommerrain)

V 0.9.4

V 0.9.5 (DIS)

25/02/2011

DIS-Ballot (Draft

International

Standard)

Core only

28/06/2011

DIS-Release (Draft

International

Standard)

Core only

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Reusability (single source)

Increase of security through less process steps

Simple and quick verification

Improvement of maintainance

XML format: Maschine and human readability

Manufacturer independence

Automated tools for configuration, documentation, code generation etc.

Generic creation of diagnostic applications

…

Advantanges & Benefits

11

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

12

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Basic concepts representing the experiences in the creation of diagnostic

seuqunces.

Goal: Reducing and controlling complexity

Basic Concepts

13

Dia

gnos

esys

tem

e im

Aut

omob

il


Specification/realisation concept

Context concept

Validity concept

Signature concept

Variant management

Process management

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

OTX supports a 3 step development process:

1. Specification stage

• To specify sequences in an early stage of the developement process

• The general sequence logics is known

• Details for an executable sequence are still unknown but can be specified in prose

2. Intermediate stage

• A mix of specification and realisation

• The sequence creation implements the realisation based on the specifcation

• The sequence is executable already! Missing realisations are „simulated“ through appropriate dialogs

3. Realisation stage

• For each specification a realisation has been implemented

• The sequence is fully executable

Important: In each of the 3 stages the sequence can be validated, saved, and exchanged!

Specification/Realisation Concept I

14

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Specification/Realisation Concept II

15

Dia

gnos

esys

tem

e im

Aut

omob

il


Realisation

Specification Stage Intermediate Stage

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Mapping mechanism inside the runtime system for environment parameters :

• Vehicle data (e.g. model, sales person, identification number, motorization etc.)

• Diagnostic application data (e.g. name, version, used VCI etc.)

• User data (e.g. user name, user rights, idle time etc.)

• Environment data (e.g. location, version of operating system etc.)

Realisation via global context variables

Every context variable is bound to an identification routine at runtime in order to retrieve the value of the variable

Identification routines may either be proprietary or OTX procedures

Advantages:

• Working as if using global constants

• Reusabilty of the existing structure with optimal migration via stepwise mapping to OTX procedures

• When switching to other runtime environments only the mapping layer has to be adapted

• Context variables can easily be simulated externally

Context Concept I

16

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Internal Routines of the

diagnostic application

Diagnostic Application

Context variables used as global constants

OTX Sequence

Context Concept II

17

Dia

gnos

esys

tem

e im

Aut

omob

il


VIN Typ: String, Default: “”

MODEL Typ: String, Default: “”

STEERING Typ: String, Default: “left”

MANUFACTORING Typ: Boolean, Default: False

SERVICE Typ: Boolean, Default: True

DEBUG_MODE Typ: Boolean, Default: False

GetVIN();

GetModelNumber();

GetSteeringType();

n.a.

n.a.

n.a. Map

pin

g (

OTX

-Ru

nti

me)

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Based on the context concept

In order to customize the sequences to different environment conditions at runtime

So-called validities are definied globally. A validity is either

• a boolean context variable, or

• a composed logical expression, e.g. several context variables.

Nodes can be bound via the ValidFor attribute to a validity which will only be executed if the validity returns TRUE

An action node may contain several realisations

Thus context dependent sequence parts may be activated or deactivated

Advantages

• Clear borderline between static and dynamic decisions

• Reduction of the number of branches due to implicit control via environment data and not explicitly via branches

• Compact readable sequences that improve the understanding of the test logic

• Avoidance of redundancies due to storing of frequently used validities at a central location

• Presentation of different environment scenarios via on and off switch of validities (filtering)

Validity Concept

18

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Validity Concept

19

Dia

gnos

esys

tem

e im

Aut

omob

il


Using branches

Using validities

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Similar to validity concept, but on procedure level

A signature describes an interface to a procedure (prototype)

A signature equals a procedure without realisation

A signature contains a name, a specification and a set of input and output parameters

Procedures may be called indireclty via signatures

The caller only has to know the parameters and the specification of the procedure but not the implementation details

Signatures allow the creation of generic sequences that can adapt to different environment conditions at runtime

Advantages:

• Sequences don‘t have to be changed if a new context is added

• Increases the maintainance for long term availability of test sequences

• Makes it possible to develop distributed test sequences. The signature itself represents the formal definition of the interfaces among the individual partners

• Avoidance of redundancies via storing of frequently used signatures at a central location

Signature Concept

20

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Using signatures

Signature Concept

21

Dia

gnos

esys

tem

e im

Aut

omob

il


Using validities

The runtime system calles one of the two procedures based on the validity

ValidFor: isVintageModel ValidFor: isModernModel

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Normaler Ablauf

Comparing the Concepts

22

Dia

gnos

esys

tem

e im

Aut

omob

il


Using validities Using signatures Using branches

22 activities

13 activities

11 activities

Advantages:

Avoidance of branches

Reduces the presentation to the actual test logic (11 activities)

Better maintainance and long term availability

Avoiding redundancies

Possibility for distributed development of test sequences

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

23

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Diagnostic runtime system Standardized programming

interface for ECU

communication

MVCI-Server ISO 22900

MVCI-Server ISO 22900-3

Diagnostic database Standardized exchange

format for diagnostic data

ODX ISO 22901

ODX ISO 22901-1

Overview

24

Ope

n D

iagn

ostic

Wor

kflo

w


Diagnostic sequences Standardized exchange

format for diagnostic

sequences

OTX ISO 13209

OTX ISO 13209

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Completely new development based on the new OTX standard (ISO 13209)

Datadriven solution for the complete diagnostic process chain

For specification, realisation, documentation, test and execution of OTX sequences

Creation of graphical user interfaces (HMI/GUI)

Independent of diagnostic runtime system

Native and direct working on OTX data

Handling of very large OTX databases

On-the-fly creation of C# program code (no execution interpreter!)

Support of different concepts to complexity reduction and user group adaption

Flexibly provided as

• Stand alone application (incl. viewer)

• SDKs to integrate in own application

• Easily extensible on almost each layer

Highlights

25

Ope

n D

iagn

ostic

Wor

kflo

w


Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Main tasks:

Specification

Realisation

Documentation

Test and

Execution of OTX sequences

Target groups:

Development

Production

Service

Design characteristics:

Openness

Adaptable

Extensibility

Main Characteristics

26

Ope

n D

iagn

ostic

Wor

kflo

w


Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

ODF - Open Diagnostic Framework

OTX Runtime Environment

Database-Modul

XML-DB

OTX-API

Forms-Designer

Control-Library

Data-Binding

Principle Architecture

27

Ope

n D

iagn

ostic

Wor

kflo

w


OTX

Proprietary Diagnostic RT-Systems SDX*

Standardized Diagnostic RT-Systems

D-PDU API MVCI-Server + PDU-Simulation Legacy RT-Systems

VCI - Vehicle Communication Interface

Simulation ODX

ECU‘s

*SDX = Simple Diagnostic Data Exchange Format by emotive to support proprietary

Diagnostic Runtime Systems

OTX-Designer

Activity-Library

Project-Explorer

Test-Environment

Debugger

Unit-Tests

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

ODF runtime Database module

Runtime Environment

28

Ope

n D

iagn

ostic

Wor

kflo

w


OTX

OTX-API OTX-

Runtime

ODF-

Runtime XML-DB Compiler

DLL C# XQuery

Data processing

ca. 3 MB Storage requirement on hard-drive ca. 20 MB

OTX execution system

Data processing as OTX format Data processing in binary format

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

OTX-Designer

• Graphical specification and implementation of diagnostic sequences

• Direct, native working on OTX

• Validation of sequences at design time

• Execution, test and debugging of sequnces at design time

• Monitoring of diagnostic communication and variable changes

• Configurable designer modes

All, Compact, Minimal, etc.

OTX-API

• Fast access to very large OTX databases

OTX-Runtime

• On-the-fly C# code generation of high performance

• Independent of diagnostic runtime system

• Support of different standardized and proprietary diagnostic runtime system:

DSA Prodis.MCD (ODX 2.0.1, 2.0.2, 2.1.0, 2.2.0)

samtec samDiaX

Further systems, e.g. CBF runtime quickly integrated

• High-performance, optimized handling of resources, multi-channeling, multi-instance handling

• PDU simulation for development of sequences without communication with ECU

Screen Designer

• Easy graphical creation of modern GUIs

• Simple binding of diagnostic sequences variables to GUI controls for in and output

• Language manager to localize the application

• Simple distribution of the created application to third parties via MSI or MSM

General:

• Object search

• Forward-driven data input

• Undo/Redo, Drag&Drop

• References adjustment

• Version management

• User profiles

• IDE in German and English

Features

29

Ope

n D

iagn

ostic

Wor

kflo

w


Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Supported diagnostic standards:

• MVCI Server API (ISO 22900-3, ASAM MCD-3D Server)

• ODX (ISO 22901-1, ASAM MCD-2D)

• OTX Beta Version (ISO 13209)

• D-PDU-API (ISO 22900-2)

• CAN (ISO 11898)

• K-Line (ISO 9141)

• UDS (ISO 14229)

• ISOTP (KWP 2000 on CAN, ISO/DIS 15765-3)

• KWP 2000 (ISO 14230)

Supported hardware (Vehicle Communication Interface):

• Bosch MDI

• DSA MDI-G

• samtec HSX, HS+, HSlight

• Vector CANCardXL, CANCaseXL, CANBoardXL

• Further interfaces with standardized D-PDU-API interface

System requirements

• PC with Windows XP SP2 32-Bit or higher

• .NET Framework 3.5

Standards, Hardware & System Requirements

30

Ope

n D

iagn

ostic

Wor

kflo

w


Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

31

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Stand-Alone Application

32

Ope

n D

iagn

ostic

Wor

kflo

w


Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Visual Studio Plug-In I

33

Ope

n D

iagn

ostic

Wor

kflo

w


OTX-DESIGNER

VALIDATION

AC

TIV

ITY

LIB

RA

RIE

S

VARIABLES

PR

OJ

EC

T E

XP

LO

RE

R

PROPERTIES

TRACE WINDOW DIAGNOSTIC COMMUNICATION

TRACE WINDOW VARIABLES

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Visual Studio Plug-In II

34

Ope

n D

iagn

ostic

Wor

kflo

w


DEBUGGING

Cop

yrig

ht ©

3/8

/201

1 em

otiv

e G

mbH

- A

ll rig

hts

rese

rved

Sprechen Sie

mit uns!

Wir helfen Ihnen gern.

www.emotive.de

Thank You for Your Attention!

35

Dia

gnos

esys

tem

e im

Aut

omob

il

Visit our trade exhibition!

Further information on our website at

Diagnose über CAN - emotive · 1-ed Mapping mechanism inside the runtime system for environment...

Documents

Transcript of Diagnose über CAN - emotive · 1-ed Mapping mechanism inside the runtime system for environment...