Diagnose über CAN - emotive€¦ · Variantenmanagement Prozessmanagement . 1-ed OTX unterstützt...

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

2

Dia

gnos

esys

tem

e im

Aut

omob

il

OTX Basiskonzepte Open Diagnostic Framework Demonstration

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Diagnoseprozesskette – Vergangenheit

3

Dia

gnos

esys

tem

e im

Aut

omob

il


Produktion Entwicklung Diagnose-

systemlieferant

Systemlieferant Service

Die herkömmliche Diagnoseprozesskette war gekennzeichnet durch einen

heterogenen Austausch diagnoserelevanter Informationen

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Diagnoseprozesskette – Zukunft: OTX/ODX

4

Dia

gnos

esys

tem

e im

Aut

omob

il


Austausch von standardisierten Diagnosedaten über alle Phasen des

Fahrzeuglebenszyklus – Grundprinzip: Single Source

Produktion Entwicklung Diagnose-

systemlieferant

Systemlieferant Service

Lieferanten Diagnose

Datenbank

Hersteller Diagnose

Datenbank

OTX ODX

Internet

OTX ODX

OTX ODX

OTX ODX

Hersteller Diagnose

Datenbank

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

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- und Diagnoseanwendungen

OTX

ODX

OTX = Open Test sequence eXchange (ISO 13209)

Domänen spezifische Sprache auf hoher Abstraktionsebene

Ziel: Formale, graphische Beschreibung von Diagnosesequenzen

Plattform und Tester unabhängiges Austauschformat

Enthält leistungsfähige Konzepte zur Komplexitätsreduzierung

Prozesssichere Alternative für die Java-Jobs in ODX

Anwendungsbereiche: Fahrzeugdiagnose, Testautomatisierung, HIL-Simulation etc.

Initiale Anwendung: Austauschformat für ODX basierte Diagnosesequenzen

Erst mit OTX/ODX liegt eine vollständige, datengetriebene Lösung für die gesamte Diagnoseprozesskette vor

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Diagnosesequenz in Zusammenspiel mit Nutzer- und Fahrzeuginteraktion

6

Dia

gnos

esys

tem

e im

Aut

omob

il


GUI

Externe Sensoren

& Aktoren

Off-Board

Kommunikation

Prüfsequenz

Diagnosetester in Entwicklung, Produktion & Service

Request/Response

Steuergeräte x?

y? z?

A

B C C‘ D

E E‘ Rekursiver

Funktions-

aufruf ShowScreen

OTX

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Anwendung in der Diagnoseprozesskette

7

Dia

gnos

esys

tem

e im

Aut

omob

il


OTX

Steuergeräte

Hersteller

Entwicklung

Diagnose-

funktionen

Diagnose

in der

Produktion

HIL-Tests After-Sales

Diagnose

Diagnose

Doku (GVO, Euro 5,

Hotline …)

Entwicklung Produktion Service

Ziel: Austausch und Archivierung von

verifizierten, praxiserprobten Diagnosesequenzen

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

DiagCom

DateTime EventHandling

… Job/Flash

I18n

StringUtil Math

Measure

Quantities

HMI

Logging

Schnittstellen & Erweiterungen

8

Dia

gn

ose

syst

em

e im

Au

tom

ob

il


Diagnostic Tester Application

OTX Core Processing System

OTX

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

Measurement Data Acquisition

Other Device (e.g. HIL-API, ASAM

GDI)

HMI Device (e.g. Keyboard,

Mouse, Screen …)

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

OTX Timeline

9

Dia

gnos

esys

tem

e im

Aut

omob

il


19.12.2008

Einreichung des

New Work Item

Proposals in die

ISO

Milestone Heute (10/2011)

V 0.9 (Schwabing)

V 0.9.4

V 0.9.3 (Sommerrain)

V 0.9.2 (Aachen)

V 0.9.1 (Wolfsburg)

ISO/DIS 13209 (V 0.9.5)

25.02.2011

DIS-Ballot (Draft

International

Standard)

Core only

28.06.2011

DIS-Release (Draft

International

Standard)

Core only

Wichtig: Erst ab ISO/DIS Release

(V 0.9.5) kann Datensicherheit

gewährleistet werden!

13.04.2011

DIS-Ballot (Draft

International

Standard)

Libraries only

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Wiederverwendbarkeit (Single-Source)

Erhöhung der Sicherheit, durch weniger Prozessschritte

Einfache und schnelle Verifizierbarkeit

Verbesserung der Wartbarkeit

Maschinen- und Menschenlesbarkeit (XML Format)

Herstellerunabhängigkeit

Erweiterbarkeit um anwendungsspezifische Bibliotheken

Verfügbarkeit von Tools zur Konfiguration, Dokumentenerstellung,

Kode-Erzeugung etc.

Generische Erstellung von Diagnoseapplikationen

Vorteile & Nutzen

10

Dia

gnos

esys

tem

e im

Aut

omob

il


Ziel: Austausch und Archivierung von

verifizierten, praxiserprobten Diagnosesequenzen

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

11

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Basiskonzepte, repräsentieren die Erfahrungen bei Erstellung und

Anwendung von Prüfsequenzen.

Ziel: Reduzierung und Beherrschung der Komplexität

Basiskonzepte

12

Dia

gnos

esys

tem

e im

Aut

omob

il


Specification/Realisation-Konzept

Kontext-Konzept

Validity-Konzept

Signatur-Konzept

Variantenmanagement

Prozessmanagement

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

OTX unterstützt einen 3 stufigen Entwicklungsprozess:

1. Spezifikationsphase

• Zur Spezifikation von Sequenzen in einer frühen Phase des Entwicklungsprozesses

• Die allgemeine Ablauflogik ist bekannt

• Details für eine ablauffähige Sequenz sind noch unbekannt, können aber in Prosa beschrieben werden

2. Zwischenphase

• Eine Mischung aus Spezifikations- und Realisierungsphase

• Der Ablaufersteller implementiert aus der Spezifikation die einzelnen Realisierungen

• Der Ablauf ist bereits ausführbar! Fehlende Realisierungen werden durch geeignete Dialoge „simuliert“.

3. Realisierungsphase

• Für jede Spezifikation wurde auch eine Realisierung implementiert

• Die Sequenz ist voll ablauffähig

Wichtig: In jeder der 3 Phasen ist der Ablauf validierbar, speicher- und austauschbar!

Specification/Realisation-Konzept

13

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Specification/Realisation-Konzept II

14

Dia

gnos

esys

tem

e im

Aut

omob

il


Realisation

Specification Stage Intermediate Stage

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Mapping-Mechanismus auf Ebene des Ablaufsystems für Umgebungsparameter :

• Fahrzeugdaten (z.B.: Modell, Verkäufer, Identifikationsnummer, Motorisierung etc.)

• Daten der Diagnoseapplikation (z.B.: Name, Version, Verwendetes VCI etc.)

• Benutzerdaten (z.B.: Benutzername, Benutzerrechte, Idle-Time etc.)

• Umgebungsdaten (z.B.: Standort, Version des Betriebssystems etc.)

Realisierung über globale Kontextvariablen

Jede Kontextvariable wird zur Laufzeit an eine Identifikationsroutine gebunden, welche den Wert der Variablen ermittelt

Die Identifikationsroutinen können anwendungsspezifisch (proprietär) oder OTX-Prozeduren sein

Vorteile:

• Arbeiten wie mit globalen Konstanten

• Weiterverwendung der vorhandene Struktur mit optionaler Migration durch schrittweises Mapping an OTX-Prozeduren

• Beim Austausch mit anderen Laufzeitumgebungen muss nur der Mapping-Layer angepasst werden

• Kontextvariablen können einfach extern simuliert werden

Kontext-Konzept I

15

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Internal Routines of the

diagnostic application

Diagnostic Application

Context variables used as global constants

OTX Sequence

Kontext-Konzept II

16

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 ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Basiert auf Kontext-Konzept

Zur Anpassung der Abläufe an verschiedene Umgebungsbedingungen zur Laufzeit

Es werden global so genannte Validities definiert. Eine Validity ist entweder

• eine boolesche Kontextvariable oder

• ein zusammengesetzter logischer Ausdruck, z.B.: aus mehreren Kontextvariablen.

Knoten können über die ValidFor-Eigenschaft an eine Validity gebunden werden und werden nur ausgeführt, wenn die Validity TRUE ergibt

Ein Action-Knoten kann mehrere Realisierungen enthalten

Es können so kontextabhängig Teile einer Sequenz aktiviert oder deaktiviert werden

Vorteile

• Klare Abgrenzung zwischen statischen und dynamischen Entscheidungen

• Verringerung der Anzahl der Verzweigungen, da implizite Steuerung über Umgebungsdaten und nicht explizit über Verzweigungen

• Kompakterer, lesbarerer Ablauf, der die eigentliche Testlogik besser sichtbar macht

• Vermeidung von Redundanzen durch Speicherung häufig verwendeter Validities an einem zentralen Ort

• Darstellung verschiedener Umgebungsszenarien durch ein und Ausschalten von Validities (Filterung)

Validity-Konzept

17

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Validity-Konzept

18

Dia

gnos

esys

tem

e im

Aut

omob

il


Mit Verzweigung

Mit Validities

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Ähnlich dem Validity-Konzept nur auf Prozedur-Ebene

Eine Signatur beschreibt ein Interface für eine Prozedur (Prototyp)

Eine Signatur ist wie eine Prozedur ohne Realisierung

Eine Signatur besteht aus Namen, Spezifikation und einem Satz von Ein- und Ausgabeparametern

Prozeduren können über Signaturen indirekt aufgerufen werden

Der Aufrufer muss nur die Parameter und die Spezifikation aber keine Implementierungsdetails der Prozedur kennen

Signaturen erlauben das Erzeugen von generischen Sequenzen, die sich den jeweiligen Umgebungsbedingungen zur Laufzeit anpassen können.

Vorteile:

• Sequenzen müssen nicht geändert müssen, wenn ein neuer Kontext hinzugefügt wird

• Erhöht die Wartbarkeit bei der Langzeitverfügbarkeit von Testsequenzen

• Ermöglicht die verteilte Entwicklung von Testsequenzen. Die Signatur dient dabei als formale Definition der Schnittstellen zwischen den einzelnen Partnern.

• Vermeidung von Redundanzen durch Speicherung häufig verwendeter Signaturen an einem zentralen Ort

Signatur-Konzept

19

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Mit Signaturen

Signatur-Konzept

20

Dia

gnos

esys

tem

e im

Aut

omob

il


Mit Validities

Das Laufzeitsystem ruft entsprechend der Validity eine der beiden Prozeduren auf

ValidFor: isVintageModel ValidFor: isModernModel

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Normaler Ablauf

Konzepte im Vergleich

21

Dia

gnos

esys

tem

e im

Aut

omob

il


Mit Validities Mit Signaturen Mit Verzweigungen

22 Aktivitäten

13 Aktivitäten

11 Aktivitäten

Vorteile:

Vermeidung von Verzweigungen

Reduzierung der Darstellung auf die eigentliche Testlogik (11 Aktivitäten)

Bessere Wartbarkeit und Langzeitverfügbarkeit

Vermeidung von Redundanzen

Möglichkeit der verteilten Entwicklung von Testsequenzen

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

22

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed Diagnoselaufzeitsystem

Bereitstellung einer standar-

disierten Programmier-

schnittstelle zur Kommunika-

tion mit dem Steuergerät

MVCI-Server ISO 22900

Diagnoselaufzeitsystem Bereitstellung einer standar-

disierten Programmier-

schnittstelle zur Kommunika-

tion mit dem Steuergerät

MVCI-Server ISO 22900-3

Diagnosedatenbank Bereitstellung eines standar-

disierten Austauschformats

für Diagnosedaten

ODX ISO 22901

Diagnosedatenbank Bereitstellung eines standar-


für Diagnosedaten

ODX ISO 22901-1

Übersicht

23

Ope

n D

iagn

ostic

Wor

kflo

w


Diagnoseabläufe Bereitstellung eines standar-


für Diagnoseabläufe

OTX ISO 13209

Diagnoseabläufe Bereitstellung eines standar-


für Diagnoseabläufe

OTX ISO 13209

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Highlights

24

Ope

n D

iagn

ostic

Wor

kflo

w


Datengetriebene Lösung für die gesamte Diagnoseprozesskette

Spezifikation, Realisierung, Validierung, Dokumentation & Test von OTX-Sequenzen

Unabhängig vom Diagnoselaufzeitsystem

Komplette Neuentwicklung

Einfach auf nahezu jeder Ebene benutzerspezifisch erweiterbar

Benutzergruppen-Adaption

Flexible Bereitstellung: Stand-Alone

oder SDK

Anbindung und Generierung

GUI/HMI

On-the-fly OTX-Checker (Validierung)

On-the-fly Code-Erzeugung (C# …, kein Ablaufinterpreter!) Natives und direktes Arbeiten auf

OTX-Daten (kein Im-/Export!)

Performante Verarbeitung auch sehr großer OTX-

Datenbanken

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

ODF - Open Diagnostic Framework

OTX Runtime Environment

Forms-Designer*

Control-Library

Data-Binding

Prinzipieller Aufbau

25

Ope

n D

iagn

ostic

Wor

kflo

w


Database-Modul

XML-DB

OTX-API OTX

Proprietary Diagnostic RT-Systems SDX*

D-PDU API Legacy RT-Systems Simulation

Standardized Diagnostic RT-Systems

MVCI-Server + PDU-Simulation ODX

VCI - Vehicle Communication Interface

ECU‘s

OTX-Designer

Activity-Library

Project-Explorer

Test-Environment*

Debugger

Unit-Tests

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Laufzeitumgebung

26

Ope

n D

iagn

ostic

Wor

kflo

w


OTX-

Runtime

ODF-Runtime

ODF-

Runtime Compiler

C#

Datenbankmodul

OTX-API XML-DB XQuery

Datenverarbeitung

ca. 3 MB Platzbedarf auf der Festplatte ca. 20 MB

OTX-Ablaufumgebung

OTX

Datenbereitstellung im OTX-Format

DLL

Datenbereitstellung im Binär-Format

Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Unterstützte Diagnosestandards:

• 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)

Unterstützte Hardware (Vehicle Communication Interface):

• Bosch MDI

• DSA MDI-G

• samtec HSX, HS+, HSlight

• Vector CANCardXL, CANCaseXL, CANBoardXL

• Weitere Interfaces mit standardisierter D-PDU-API Schnittstelle

Systemvoraussetzungen

• PC mit Windows XP SP-2 oder höher (32 und 64 Bit)

• .NET Framework 4.0

Standards, Hardware & Systemvoraussetzungen

27

Ope

n D

iagn

ostic

Wor

kflo

w


Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

28

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Stand-Alone Anwendung

29

Ope

n D

iagn

ostic

Wor

kflo

w


Cop

yrig

ht ©

10/

28/2

011

emot

ive

Gm

bH -

All

right

s re

serv

ed

Sprechen Sie

mit uns!

Wir helfen Ihnen gern.

www.emotive.de

Danke für Ihre Aufmerksamkeit!

30

Dia

gnos

esys

tem

e im

Aut

omob

il

Besuchen Sie uns in der Fachausstellung!

Weitere Informationen finden Sie auf unserer

Website unter

Diagnose über CAN - emotive€¦ · Variantenmanagement Prozessmanagement . 1-ed OTX unterstützt...

Documents

Transcript of Diagnose über CAN - emotive€¦ · Variantenmanagement Prozessmanagement . 1-ed OTX unterstützt...