diagnose über can€¦ · variantenmanagement prozessmanagement . 2-ed otx unterstützt einen 3...

Cop

yrig

ht ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

2

Dia

gnos

esys

tem

e im

Aut

omob

il

Was ist OTX? „Der generische Tester“ Demonstration Praktische Anwendung

Cop

yrig

ht ©

2/2

0/20

12 e

mot

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 ist gekennzeichnet durch einen

heterogenen Austausch von diagnoserelevanten Informationen

Cop

yrig

ht ©

2/2

0/20

12 e

mot

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 ©

2/2

0/20

12 e

mot

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 ©

2/2

0/20

12 e

mot

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 ©

2/2

0/20

12 e

mot

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 ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

DiagCom

DateTime EventHandling

… Job/Flash

I18n

StringUtil Math

Measure

Quantities

HMI

Logging

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 ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

Basiskonzepte, repräsentieren die Erfahrungen bei Erstellung von

Diagnoseabläufen.

Ziel: Reduzierung und Beherrschung der Komplexität

Basiskonzepte

9

Dia

gnos

esys

tem

e im

Aut

omob

il


Specification/Realisation-Konzept

Kontext-Konzept

Validity-Konzept

Signatur-Konzept

Variantenmanagement

Prozessmanagement

Cop

yrig

ht ©

2/2

0/20

12 e

mot

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 I

10

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

Specification/Realisation-Konzept II

11

Dia

gnos

esys

tem

e im

Aut

omob

il


Realisation

Specification Stage Intermediate Stage

Cop

yrig

ht ©

2/2

0/20

12 e

mot

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

12

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

2/2

0/20

12 e

mot

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

13

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 ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

Basieren auf dem 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

14

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

Validity-Konzept

15

Dia

gnos

esys

tem

e im

Aut

omob

il


Mit Verzweigung

Mit Validities

Cop

yrig

ht ©

2/2

0/20

12 e

mot

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

16

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

Mit Signaturen

Signatur-Konzept

17

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 ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

Normaler Ablauf

Konzepte im Vergleich

18

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 ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

Einfache OTX-Sequenz

19

Dia

gnos

esys

tem

e im

Aut

omob

il


Umgebungsvariable setzen ...

Cop

yrig

ht ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

OTX Timeline

20

Dia

gnos

esys

tem

e im

Aut

omob

il


Meilenstein Heute

19.12.2008

Einreichung des

New Work Item

Proposals in die

ISO

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)

11.11.2011

Release of

ISO 13209-1 &

ISO 13209-2

Core only

02/2012

Release of

ISO 13209-3

Libraries

V 1.0 (ISO 13209)

Cop

yrig

ht ©

2/2

0/20

12 e

mot

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

21

Dia

gnos

esys

tem

e im

Aut

omob

il


Ziel: Austausch und Archivierung von

verifizierten, praxiserprobten Diagnosesequenzen

Cop

yrig

ht ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

22

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

Generierter Diagnosetester

Generisch (lat. genus: „Art, Gattung, Geschlecht“) = allgemeingültig

Ein „generischer Tester“ ist ein universeller Diagnosetester

Ziel ist die schnelle und prozesssichere Erzeugung von datengetriebenen Testern ohne Schreiben von Programmcode

Ansatz: Generative Programmierung (Automatische Erzeugung von Programmcode)

„Generischer Tester“

23

Dia

gnos

esys

tem

e im

Aut

omob

il


ODX

Diagnosedaten

OTX

Ablauflogik

Config Konfiguration

externer I/O‘s

.NET JAVA

Binary

Windows Linux

Androit Embedded

…

…

Codegenerator

Config

Cop

yrig

ht ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

Deutliche Steigerung der Produktivität

Erhöhung der Prozesssicherheit und Stabilität

Plattformunabhängigkeit – „Write Once Run Anywhere“

Vermeidung Syntax- und Laufzeitfehlern

Flexibel für verschiedene Anwendungsszenarien skalierbar

Vereinfachtes Änderungsmanagement

Aber:

Komplexe Datenstrukturen

Softwarewerkzeuge müssen die Komplexität der Daten

benutzerfreundlich repräsentieren

Vorteile & Nutzen

24

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

OTX-Runtime

Generische Einbindung externer Geräte

25

Dia

gnos

esys

tem

e im

Aut

omob

il


Scr

een

Sig

natu

re

HMI-Device

GenericScreen .NET

WPF Java Swing

…

Layout

Devic

eSig

natu

re

Measurement-Device

National Instruments Agilent

Hewlett-Packard Texas Instruments

…

Configuration

ExecuteDeviceService

OpenScreen

OTX-Activitiy

OTX-Activitiy

Mapping

Mapping

Cop

yrig

ht ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

Beispiel: HMI-Bibliothek

26

Dia

gnos

esys

tem

e im

Aut

omob

il


DiagCom

DateTime EventHandling

… Job/Flash

I18n

StringUtil Math

Measure

Quantities

HMI

Logging

Diagnostic Tester Application

OTX Core Processing System

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 ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

Die HMI Bibliothek erweitert den OTX-Core um Funktionen für die Interaktion mit dem Anwender über verschiedene Ein- und Ausgabegeräte, z.B.: Monitor, Tastatur, Punkt-Matrix-Display, LEDs etc.

Es wird nur die Schnittstelle der Ein-und Ausgabe beschrieben

Es werden keine Layout-Informationen abgebildet

Da nicht jedes Zielsystem über ein Display verfügt, gibt es für die Ein und Ausgabe zwei Wege:

• BasicScreens

Für elementare Anwendungen: Anzeigen einer Warnung, Anfrage einer einfachen Eingabe, z.B. Ja/Nein

Sind immer modal, d.h. der Ablauf wird solange angehalten, bis der Screen bestätigt wird.

Müssen durch jedes Ablaufsystem unterstützt werden

• CustomScreens

Definieren eine Schnittstelle zu einer außerhalb von OTX erzeugten Oberfläche

Entkopplung der Bildschirmdarstellung von der Testsequenz. Funktion und Layout werden nicht in OTX beschrieben.

Können auch nichtmodal sein, d.h. Ablauf läuft weiter, wenn der Screen dargestellt wird.

HMI – Mensch-Maschine Schnittstelle

27

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

28

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

Open Diagnostic Framework

29

Ope

n D

iagn

ostic

Wor

kflo

w


Cop

yrig

ht ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

30

Dia

gnos

esys

tem

e im

Aut

omob

il


Cop

yrig

ht ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

Highlights

31

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

Konzepte zur Komplexitäts-reduzierung

Benutzergruppen-Adaption

Anbindung und Generierung

GUI/HMI

Flexible Bereitstellung:

Stand-Alone oder SDK

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 ©

2/2

0/20

12 e

mot

ive

Gm

bH -

All

right

s re

serv

ed

ODF - Open Diagnostic Framework

OTX Runtime Environment

Forms-Designer*

Control-Library

Data-Binding

Prinzipieller Aufbau

32

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

*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 ©

2/2

0/20

12 e

mot

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!

33

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€¦ · variantenmanagement prozessmanagement . 2-ed otx unterstützt einen 3...

Documents