OTX Basic concepts Open Diagnostic Framework Demonstration

(1)

(2)

Co py righ t © 5 /1 3/2 01 1 em ot ive Gm bH - Al l r igh ts rese rv ed

2

Di ag no sesyst em e im A ut om obi l

(3)

py righ t © 5 /1 3/2 01 1 em ot ive Gm bH - Al l r igh ts rese rv ed

Diagnostic Process Chain – Past

3

ag no sesyst em e im A ut om obi l

OTX

Basic concepts Open Diagnostic Framework Demonstration

Production

Development

Diagnostic system

supplier

System supplier

Service

The conventional diagnostic process is characterized by an heterogeneous

exchange of diagnostic information.

(4)

Diangostic Process Chain – Future: OTX/ODX

4

OTX

Basic concepts Open Diagnostic Framework Demonstration

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

Manufacturer

Diagnostic

(5)

ECU

Test and Diagnostic applications

OTX – Open Diagnostic Test sequence eXchange

5

OTX

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,

MCD

2

(ISO

22901

-1)

API

Test and Diagnostic applications

OTX

ODX



OTX =

O

pen

T

est sequence e

X

change (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

(6)

Diagnostic Sequnces in interaction with

user and vehicle

6

OTX

Basic concepts Open Diagnostic Framework Demonstration

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‘

_{function call}Recursive

ShowScreen

(7)

Application in the Diagnostic Process

7

OTX

ECU

manufacturer

Development

of diagnostic

functions

Diagnostics

in

production

HIL-Tests

Diagnostics

After-Sales

Diagnostic

Docu

(GVO, Euro 5,

Hotline …)

Development

Production

Service

Goal: Exchanging and archiving verified tested

(8)

Interfaces & Extenstions

8

Dia gnos es ys tem e im A ut om ob il

OTX

Basic concepts Open Diagnostic Framework Demonstration

DiagCom

DateTime

EventHandling

…

Job/Flash

I18n

StringUtil

Math

Measure

Quantities

HMI

Logging

Diagnostic Tester Application

OTX Core Processing System

OTX

Diagnostic Runtime System

(e.g. MVCI Server, D-Server, …)

Data Acquisition

Measurement

Other Device

(e.g. HIL-API, ASAM

GDI)

HMI Device

(e.g. Keyboard,

Mouse, Screen …)

(9)

Simple OTX Sequence

9

OTX

<

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

>

(10)

OTX Timeline

10

OTX

09 Dec. 2008

Begin of

development of

the ODF

Mile stone

Today

09 Feb. 2010

Release ODF

Version 2.0

13 May 2011

Distributable Beta

version of ODF

Version 3.0

(planned)

25 Feb. 2011

DIS-Ballot (Draft

International

Standard)

Core only

28 June 2011

DIS-Release (Draft

International

Standard)

Core only

28 June 2011

Release ODF

Version 3.0

(planned)

19 Dec. 2008

New Work Item

Proposal

(11)



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

OTX

Goal: Exchanging and archiving verified tested

(12)

12

(13)

Basic concepts representing the experiences in the creation of diagnostic

seuqunces.

Goal: Reducing and controlling complexity

Basic Concepts

13

OTX

Basic concepts

Open Diagnostic Framework Demonstration

Specification/realisation concept

Context concept

Validity concept

Signature concept

Variant management

Process management

(14)

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

(15)

Specification/Realisation Concept II

15

OTX

Basic concepts

Realisation

(16)



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

(17)

Internal Routines of the

diagnostic application

Diagnostic Application

Context variables used as global constants

OTX Sequence

Context Concept II

17

OTX

Basic concepts

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.

Mapp

ing

(O

TX

-Run

time

)

(18)



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

(19)

Validity Concept

19

OTX

Basic concepts

Using branches

(20)



Similar to validity concept, but on procedure level



A signature describes an interface to a procedure (prototype)



A signature equals a procedure without realization



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

parameters



Procedures may be called indirectly 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 maintenance 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

(21)

Using signatures

Signature Concept

21

OTX

Basic concepts

Using validities

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

(22)

Normaler Ablauf

Comparing the Concepts

22

OTX

Basic concepts

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

(23)

23

(24)

Overview

24

O pe n Di ag no st ic W or kf lo w

OTX Basic concepts

Open Diagnostic Framework

Demonstration

Diagnostic runtime system

Standardized programming

interface for ECU

communication

MVCI-Server

ISO 22900

Diagnostic database

Standardized exchange

format for diagnostic data

ODX

ISO 22901

Diagnostic sequences

Standardized exchange

format for diagnostic

sequences

OTX

(25)

Highlights

25

OTX Basic concepts

Demonstration

Data-driven solution

for the complete

diagnostic process chain

Specification, realisation, validation,

documentation & test

of OTX sequences

Independant of

diagnostic runtime system

Completely

new

development

Simple

custom extensibility

at almost each layer

Concepts for

complexity

reduction

User group

adaption

Connection

and generation

GUI/HMI

Flexible usage:

Stand-alone or SDK

On-the-fly code generation

(C# …, no execution interpreter!)

Native and direct working

on OTX

data (no im-/export!)

Fast processing of

very

large OTX

(26)

Main tasks:



Specification



Realisation



Documentation



Test and



Execution of OTX sequences

Target groups:



Development



Production



Service

Design characteristics:



Openness



Adaptable



Extensibility

Main Characteristics

26

(27)

ODF - Open Diagnostic Framework

OTX Runtime Environment

Database-Modul

XML-DB

OTX-API

Forms-Designer

Control-Library

Data-Binding

Principle Architecture

27

pe n Di ag no st ic W or kf lo w

OTX Basic concepts

Demonstration

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

(28)

ODF runtime

Database module

Runtime Environment

28

OTX Basic concepts

Demonstration

OTX

OTX-API

Runtime

ODF-

Runtime

OTX-XML-DB

XQuery

C#

Compiler

DLL

Data processing

ca. 3 MB

Storage requirement on hard-drive ca. 20 MB

OTX execution system

(29)



OTX-Designer

•

Graphical specification and implementation of

•

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

(30)



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

(31)

31

(32)

Stand-Alone Application

32

(33)

Visual Studio Plug-In I

33

pe n Di ag no st ic W or kf lo w

OTX Basic concepts Open Diagnostic Framework

Demonstration

OTX-DESIGNER

VALIDATION

A

C

T

IVI

T

Y

L

IB

R

A

R

IES

VARIABLES

PR

OJEC

T

EXPL

OR

ER

PROPERTIES

TRACE WINDOW DIAGNOSTIC COMMUNICATION

(34)

Visual Studio Plug-In II

34

OTX Basic concepts Open Diagnostic Framework

Demonstration

(35)

Contact us!

We can help out.

www.emotive.de

Thank You for Your Attention!

35

Further comprehensive information on OTX

and vehicle diagnostics can be found on our

website at