Gesetzliche On-Board-Diagnose und ODX

Größe: px
Ab Seite anzeigen:

Download "Gesetzliche On-Board-Diagnose und ODX"

Transkript

1 Gesetzliche On-Board-Diagnose und ODX Klaus Beiter, Christoph Rätz, Oliver Garnatz Abstract Legislated On-Board-Diagnostics is based on the requirement to monitor emission related systems during the complete life cycle of a vehicle. There have been many standardization activities since the CARB released OBD-I in The latest standard under creation is WWH-OBD. This paper gives an overview of the available OBD standards with their inter-relationships and their connection to other important diagnostic standards. ODX (Open Diagnostic Data Exchange) is a well accepted and widely used standard for the description of ECU and vehicle diagnostics. One part of the ODX standard (ISO ) is dedicated to the description of OBD data. This article will briefly introduce ODX and present the underlying design principles of the OBD ODX description. Differing requirements of the data description, based on different use cases (parameterization of diagnostic testers, diagnostic software generation, diagnostic software validation) will be analyzed and discussed. WWH-OBD has now been implemented in its first vehicle platforms. Questions arising from the WWH-OBD introduction, together with implementation approaches, will complete the article. Kurzfassung Die gesetzliche On-Board-Diagnose basiert auf der Anforderung, Abgasvorschriften nicht nur zum Zeitpunkt der Zulassung, sondern über den gesamten Lebenszyklus eines Fahrzeugs hinweg zu überwachen. Seit Verabschiedung der OBD-I Norm im Jahr 1988 durch die CARB gab es weltweit mehrere Standardisierungsaktivitäten, die in dem gerade entstehenden WWH-OBD Standard münden. Der Beitrag gibt einen Überblick über die vorhandenen OBD-Standards und ihre Beziehungen zueinander und zu anderen Diagnosestandards. ODX (Open Diagnostic Data Exchange) ist ein heute weit verbreiteter Standard zur Beschreibung der Steuergeräte- bzw. Fahrzeugdiagnose. Ein Teil des ODX- Standards (ISO ) ist der Beschreibung von OBD-Daten gewidmet. Der Beitrag wird eine kurze Übersicht über ODX geben und die zugrunde liegenden Designprinzipien der OBD ODX-Beschreibung vorstellen. Die unterschiedlichen Anforderungen an die Datenbeschreibung in Abhängigkeit von der geplanten Verwendung (Testerparametrierung, Steuergerätesoftware-Generierung, Steuergerätesoftware- Validierung) der Daten sollen anhand des OBD-Anwendungsfalls aufgezeigt und diskutiert werden. WWH-OBD wird in ersten Fahrzeugprojekten umgesetzt. Die hierbei auftretenden Fragestellungen und Lösungsansätze runden den Beitrag ab.

2 1. Gesetzliche On-Board-Diagnose 1.1 OBD-I Ausgangspunkt für die Entwicklung der OBD war die Forderung der CARB (Californian Air Resources Board), dass alle ab 1988 zugelassenen Fahrzeuge über eine selbständige Überwachung der abgasrelevanten Systeme verfügen sollten. Dies erfordert das Detektieren der Verschlechterung des Abgasverhaltens mit einer entsprechenden Meldung an den Fahrer. OBD-I fasst erstmals die in diesem Zusammenhang erforderlichen Anforderungen an die On-Board-Diagnose zusammen. OBD-I ist relativ einfach aufgebaut und beschränkt sich auf die Überwachung der Lambdasonde, der Abgasrückführung, Kraftstoffzufuhr und die Motorsteuerung. Fehler konnten als Blinkcodes am Kombiinstrument abgelesen werden. Der Fahrzeugzugang wurde im Rahmen von OBD-I nicht standardisiert, so dass hersteller- und baureihen-spezifische Lösungen entstanden. 1.2 OBD-II 1994 macht die CARB die OBD-II Norm zur Vorschrift für Fahrzeuge, die ab 1996 in Kalifornien zugelassen werden sollen. Für diese Fahrzeuge fordert die Norm, die Ausstattung mit einem OBD-System, welches die abgasrelevanten Komponenten ständig überwacht und dass Fehler, die zu erhöhten Schadstoffemissionen führen, in einem vorgegebenen Format abgespeichert werden müssen. Schwere Fehler müssen dem Fahrer mittels der MIL (Malfunction Indicator Lamp) angezeigt werden. Ebenso sind Regeln definiert, die das Ausschalten der MIL und das Löschen der Fehlerspeichereinträge beschreiben, wenn der Fehler während eines definierten Zeitraumes nicht mehr auftritt. Mit dem sogenannten Scan-Tool kann der Zustand des Fahrzeuges bzgl. seines Emissionsverhaltens ausgelesen werden, um z. B. die benötigten Informationen zur Fehlerbehebung zu ermitteln. Dies sind Steuergerätewerte (PIDs), die Fehlercodes (DTCs) und die sogenannten Umgebungsdaten zum Zeitpunkt des Fehlerauftretens (Freeze-Frames). Eine wichtige Frage beim Auslesen des Fehlerspeichers betrifft die Testabdeckung. OBD-II definiert in diesem Zusammenhang den Begriff der Readiness. Sie drückt aus, ob ein bestimmter Fehler auftreten konnte, d.h. ob die Situation (bzw. der Test), die den Fehler erkennt, seit dem letzten Löschen des Fehlerspeichers schon durchlaufen wurde. Die Readiness kann vom Scantool als Bitmaske ausgelesen werden und falls erforderlich können fehlende Tests mit dem Scantool gestartet werden. OBD-II definiert in jeweils eigenständigen Dokumenten den OBD-Stecker (SAE J1962), das OBD-Scan-Tool (SAE J1978), die Diagnosedienste (SAE J1979), die Fehlercodes (SAE J2012) und die Data Link Security (SAE J2186). Folgende Bussysteme sind für die OBD-Kommunikation möglich: ISO K-Line ISO CARB ISO CAN SAE J1850 PWM und VPWM

3 1.2 EOBD Die EOBD-Norm ist das europäische Pendant zu OBD-II. Die Norm wird erstmals für PKW mit Ottomotor ab Modelljahr 2001 vorgeschrieben. Die Anwendung der Regelung wurde später auf PKWs mit Dieselmotoren ab Modelljahr 2004 ausgeweitet. Die EOBD-Norm bezieht sich - wie auch die amerikanische OBD-II-Norm - auf mehrere ISO-Dokumente, in denen die Anforderungen an die technische Umsetzung festgeschrieben sind. Darüber hinaus definiert EOBD wie auch OBD-II die Abgas- Grenzwerte, die von den Fahrzeugen eingehalten werden müssen. Die ISO- Dokumente sind in Tabelle 1 mit den jeweils entsprechenden Dokumenten der SAE aufgelistet. Da ISO und SAE auf dem Gebiet der On-Board-Diagnose zusammenarbeiten, sind die Dokumente inhaltlich weitestgehend identisch. ISO-Dokument SAE-Dokument Allgemeine Informationen ISO Keine Entsprechung Begriffe, Definitionen, Abkürzungen ISO SAE J1930 Diagnosestecker ISO SAE J1962 Externes Testgerät ISO SAE J1978 Diagnosedienste (Modes) ISO SAE J1979 Fehlercodes ISO SAE J2012 Data Link Security ISO SAE J2186 Tabelle 1: OBD-Dokumente der ISO mit den jeweiligen Entsprechungen der SAE. Das zentrale Dokument ist die Beschreibung der OBD-Modes in ISO Das Dokument definiert die Services, die ein Scan-Tool ausführen kann und die von OBD-relevanten Steuergeräten zu unterstützen sind. Vorgesehen sind 10 Modes (Diagnosedienste). Neben dem Zugriff auf den Fehlerspeicher (Mode 02, 03, 04, 07, 0A) sind das Auslesen von Steuergerätewerten (Mode 01, 09) das Auslesen der Testergebnisse der ständigen Überwachungsfunktionen (Mode 05 oder Mode 06) und Stellgliedtests (Mode 08) vorgesehen. Ein typischer OBD-Test-Ablauf kann folgendermaßen aussehen: Mit Mode 09 werden Fahrzeugidentifikationsdaten ausgelesen Danach kann mit Mode 01 der Zustand der MIL, die Anzahl abgelegter Fehler und der Readiness-Code abgefragt werden. Mit dem Mode 03 und 07 können dann die als aktiv bzw. vorläufig eingestuften Fehler ausgelesen werden. Zusatzinformationen (Freeze Frames) für die Fehlerbehebung können mit Mode 02 ausgelesen werden. Falls zur Fehlerbehebung OBD-Routinen ausgeführt werden müssen, können diese durch das Testgerät mittels Mode 08 gestartet werden. Nach der Fehlerbehebung kann der Fehlerspeicher mit Mode 04 gelöscht werden. Die Subfunktionen zu den Modes 01, 02, 05, 06, 08 sind im Anhang des Dokumentes ISO in Ihrer Struktur definiert. Nicht jedes Steuergerät muss alle hier aufgeführten PIDs, TIDs, MIDs unterstützen. Wenn das Steuergerät die Subfunktionen unterstützt, müssen sie aber den Definitionen in ISO entsprechen. Dasselbe gilt auch für die Fehlercodes (DTCs) aus dem Dokument ISO , das sowohl deren Aufbau als auch die konkreten DTCs definiert. Alle Fehlercodes wer-

4 den als 2-Byte-Werte übertragen und als fünfstellige alphanumerische Werte am Tester angezeigt. In dem fünfstelligen Fehlercode ist folgende Information codiert: 1. Stelle: Gibt an, welchem Bereich der DTC zugeordnet ist: Powertrain (P), Fahrwerk (C), Karosserie (B) oder Bussystem (U) 2. Stelle: Gibt an, wer den DTC festgelegt hat: ISO-15031/SAE 2012, oder der Fahrzeughersteller. 3. Stelle: Gibt für die durch die ISO/SAE definierten Codes an, welchem Subsystem der DTC zugeordnet ist: Einspritzsystem (1,2), Zündung (3), Abgasrückführung (4), Geschwindigkeits- und Leerlaufregelung (5), Steuergeräteinterne Fehler (6), Getriebe (7,8). Die 4. und 5. Stelle werden zur weiteren Klassifizierung der Fehler verwendet. 1.3 WWH-OBD Im Rahmen der Vereinten Nationen wird gegenwärtig an einem Standard zur weltweiten Vereinheitlichung der Diagnose zur Überwachung des Emissionsausstoßes gearbeitet. Die Anforderungen sind in der Global Technical Regulation 5 (GTR 5) zusammengefasst. Die Norm ist zunächst auf den Nutzfahrzeug-Bereich beschränkt, soll aber später auf andere Fahrzeugbereiche ausgedehnt werden. Diese sogenannte World-Wide-Harmonized On-Board-Diagnostics (WWH-OBD) soll mittel- und langfristig die regionalen Standards ersetzen und ablösen. Zunächst werden die Anforderungen an die Abgaskontrolle und die Diagnosekommunikation festgelegt. Die Festlegung der Grenz-/Schwellenwerte obliegt vorerst noch den regionalen Behörden. Später sollen auch diese Grenzwerte harmonisiert werden. Die Ausarbeitung der technischen Rahmenbedingungen des Standards erfolgt im Rahmen der ISO (TC22 SC3) in dem Standard ISO 27145, der die bestehenden regionalen OBD- Standards (z.b. ISO 15031) ablösen soll. Um einen möglichst reibungslosen Übergang zu ermöglichen, wird als Kommunikationsbasis zunächst die Diagnose über CAN vorgesehen. Langfristig sieht ISO aber die Diagnose über IP (Ethernet oder sogar drahtlos) vor. Heute sind für die On-Board-Diagnose bei Nutzfahrzeugen die beiden Optionen ISO und J verbreitet. Beides sind CAN-basierte Protokolle. Mit der Einführung der GTR5 wird die CAN-basierte Diagnose gemäß ISO über ISO15765 und J möglich sein oder aber die TCP/IP basierte Variante gemäß ISO über ISO ISO definiert die Vehicle On-Board-Diagnostic (VOBD) bestehend aus dem VOBD System (fahrzeugseitige Implementierung), dem Datenzugriff und den OBD- Daten. Die fahrzeugseitige Implementierung kann in einem Steuergerät oder über mehrere Steuergeräte verteilt erfolgen. ISO besteht aus sechs Teilen, die in der folgenden Tabelle 1 im Überblick dargestellt sind. Die Dokumente haben momentan den Status eines Draft International Standard (DIS). Beschreibung / Inhalt Dokument Allgemeine Information und Definition der Use Cases ISO Definition der Diagnosedaten ISO Definition der Diagnosedienste ISO Kommunikation zwischen Fahrzeug und externem ISO Testgerät

5 Tests bzgl. der Einhaltung der Norm ISO Externes Testgerät ISO Tabelle 2: Dokumente des Standards ISO WWH-OBD nutzt im Gegensatz zu OBD-II keine speziell für die On-Board-Diagnose definierten Services, sondern bedient sich der in ISO festgelegten Unified Diagnostic Services (UDS), die mittlerweile bei vielen Fahrzeugherstellern auch für die Hersteller-spezifische Diagnose verwendet werden. Die für die WWH-OBDkonforme Diagnose geforderten UDS-Services sind: Service 0x14 ClearDiagnosticInformation zum Löschen des Fehlerspeichers. (Vgl. ISO Mode 04) Service 0x19 ReadDTCInformation zum Auslesen des Fehlerspeichers und der Umgebungsdaten (Snapshot-Record und Extended-Data-Record). (Vgl. ISO Mode 03, 07, 02). Service 0x22 ReadDataByIdentifier zum Auslesen der Steuergerätedaten und Testergebnisse (Vgl. ISO15031 Mode 01, 06 und 09) Service 0x31 RoutineControl zum Ausführen von Routinen (Vgl. Mode 08). Die Bereiche der zu unterstützenden Subfunktionen ergeben sich aus den Datendefinitionen aus ISO Dieses Dokument schlägt die Brücke zwischen WWH- OBD einerseits und OBD-II/EOBD andererseits, denn es verweist für die Definition der Steuergerätedaten und DTCs auf die entsprechenden SAE Dokumente SAE J1979-DA und SAE J2012-DA. 2 ODX 2.1 Grundlagen ODX wurde im Rahmen einer ASAM/ISO Arbeitsgruppe seit 2003 standardisiert. Die Notwendigkeit für die ODX-Entwicklung ergab sich aus der mangelnden Akzeptanz der damals bestehenden Standards zur Beschreibung von Diagnosedaten. Der Austausch von Diagnosedaten über Prozessgrenzen hinweg war deshalb teilweise mit erheblichem Aufwand verbunden. Ein wichtiges Ziel der ODX-Standardisierung ist die Unterstützung des Single- Source-Prinzips. Abbildung 1 veranschaulicht zwei Aspekte: Einerseits sollen die Daten in unterschiedlichen verarbeitenden Werkzeugen eingesetzt werden können, andererseits werden die Daten ohne Anpassung auch in unterschiedlichen Unternehmensbereichen weiterverarbeitet. Bei der Entwicklung von ODX wurden zahlreiche Anwendungsfälle aus den unterschiedlichen Unternehmensbereichen berücksichtigt, so dass ODX-basierte Prozesse nach dem Single-Source-Prinzip ermöglicht werden. Der Standard besteht aus folgenden Komponenten: Kernstück des Standards ist ein UML-Modell, das die Datenstruktur definiert. Abgeleitet aus dem UML-Modell ist das XML-Schema, welches die XML- Struktur der Diagnosedaten definiert. XML-Instanzen können mit

6 Abbildung 1: Das Single-Source-Prinzip: Oben Identische Daten in unterschiedlichen verarbeitenden Werkzeugen. Unten: Identische Daten in verschiedenen Unternehmensbereichen. entsprechenden Werkzeugen automatisch gegen die Schema-Definition validiert werden. Die semantische Bedeutung der Datenstrukturen ist in einer textuellen Beschreibung festgelegt, die unter anderem die Parametrierung der ODXbasierten Testsysteme festlegt. Da sich nicht alle erforderlichen semantischen Einschränkungen im UML- Modell bzw. im XML-Schema abbilden lassen, werden zusätzliche semantische Einschränkungen in den sogenannten Checker-Regeln definiert. Standardkonforme ODX-Daten müssen sowohl valide im Sinne des XML-Schemas, als auch konform zu den Checker-Regeln sein. Letzteres wird in der Praxis durch den Einsatz von ODX-Checkern erreicht. Der Fokus der Standardisierungsaktivitäten lag auf der Parametrierung der Diagnosetester. Das Datenmodell in der Version ist aus sieben Teilmodellen aufgebaut, die sich an dieser Ausrichtung orientieren (Abbildung 2). Die unteren drei Teilmodelle bilden mit der Definition der Diagnosedienste, den Kommunikationsparametern und der Beschreibung der Fahrzeugzugänge das Herzstück des Standards. Sie bilden gleichzeitig den minimalen Umfang, der für die Kommunikation eines Testgerätes mit einem oder mehreren Steuergeräten inklusive der Dateninterpretation erforderlich ist. Die oberen vier Teilmodelle sind der Beschreibung der Flash-Daten, den Steuergerätekonfigurationsdaten, der funktionsorientierten Diagnose und den sogenannten Multiple ECU Jobs vorbehalten. Ihre Verbreitung und Bedeutung ist niedriger im Vergleich zu den erst genannten Teilmodellen. ODX wurde 2008 als ISO-Standard verabschiedet. Die erste Version des Standards wurde 2004 vom ASAM als ODX herausgegeben. Zwischen dieser und der ISO-Ausgabe lagen zwei weitere Releases, in die Korrekturen und auch die Erfahrungen aus Projekten in Form von Verbesserungsvorschlägen und Erweiterungen eingeflossen sind.

7 Abbildung 2: Aufbau des ODX-Modelles Die ODX-Version wurde 2005 herausgegeben und ist heute die am weitesten verbreitete, die auch von den verfügbaren Softwarewerkzeugen am besten unterstützt ist. Um der zunehmenden Bedeutung der On-Board-Diagnose gerecht zu werden, wurde im Rahmen der ISO-Aktivitäten die ODX-Spezifikation um einen zweiten Teil ergänzt, der Richtlinien für die Erstellung der OBD-relevanten Diagnoseinhalte festlegt. Der Standard hat die Abstimmung zum Draft International Standard (DIS) bereits bestanden. Das Release als ISO-Standard steht noch aus. 2.2 ISO : OBD-II in ODX Ziele Ziel der Standardisierung von OBD-II in ODX (ISO ) ist es, die für die Entwicklung eines generischen MVCI-basierten Scan-Tools benötigten Festlegungen zu treffen. Dies sind insbesondere: Festlegung der Layer-Hierarchie (DIAG-LAYER) Definition der benötigten Kommunikationsparameter (COMPARAM-SPEC) Definition der VEHICLE-INFO-SPEC Definition der Service-Struktur (DIAG-SERVICEs) Festlegung ausgezeichneter SHORT-NAMEs und LONG-NAMEs Definition von SEMANTIC-Werten für Services und die zugehörigen Daten (DIAG-SERVICEs und TABLEs) Definition der ODX IDs Exemplarische Festlegung der PIDs und DTCs

8 Die Einhaltung des Standards sowohl bei der Erstellung der ODX-Daten als auch bei der Implementierung des Scan-Tools ermöglicht die Austauschbarkeit. ISO stellt also quasi den Vertrag zwischen der Scan-Tool-Implementierung und den OBD-ODX-Daten dar. Der Teilstandard bezieht sich auf ODX Er besteht aus einem Text-Dokument mit ODX-Beispielen, stellt aber keine vollständige OBD-Beschreibung in ODX dar. Aus dem Standard können Checker-Regeln abgeleitet werden, diese sind aber nicht im Standard definiert. ISO ist somit bzgl. Umfang und Inhalt mit den ODX-Autorenrichtlinien vergleichbar, die sich bei vielen Firmen etabliert haben Struktur des Modells Die OBD-Kommunikation basiert auf der funktionalen Adressierung. Alle abgasrelevanten Steuergeräte werden deshalb im ODX-Modell in einer FUNCTIONAL- GROUP mit dem SHORT-NAME FG_OBD_II zusammengefasst. Da die OBD- Spezifikation nicht nur die Kommunikation über CAN, sondern auch über K-Line, und SAE J-1850 vorsieht, gibt es für jeden der genannten Physical-Layer einen ODX- PROTOCOL-Layer, der die entsprechenden Kommunikationsparameter referenziert, die auch jeweils in einer Datei zusammengefasst sind. Zwischen PROTOCOL und COMPARAM-SPEC besteht hier einen 1:1-Beziehung. Die FUNCTIONAL-GROUP FG_OBD_II erbt von allen Protokollen. Der Start der Kommunikation zwischen Tester und Steuergerät erfolgt am MVCI- System durch das Öffnen eines LOGICAL-LINK. Der LOGICAL-LINK ist in der VEHICLE-INFO-SPEC VI_OBD_II definiert und enthält als wesentlichen Bestand- Abbildung 3: Schematische Darstellung der OBD-Modellierung gemäß in ODX. CPS=COMPARAM-SPEC; ES=ECU-SHARED-DATA; PR=PROTOCOL; FG=FUNCTIONAL-GROUP; LL=LOGICAL-LINK.

9 teil im Fall von OBD einen Verweis auf die FUNCTIONAL-GROUP FG_OBD_II und auf einen der oben definierten PROTOCOL Layer. Insgesamt sind also für die vier Physical-Layer vier LOGICAL-LINKS erforderlich. Ihre SHORT-NAMEs und LONG- NAMEs sind im Standard festgelegt. Auf Basis dieser Festlegung kann das Testsystem die Kommunikation auf dem gewünschten Physical-Layer starten. Redundanzvermeidung Die OBD-II-Modes werden in ODX als DIAG-SERVICEs beschrieben. Der ODX- Standard sieht unterschiedliche Mechanismen zur Vermeidung von Redundanzen in den Daten vor: Die sogenannte Value-Inheritance ist an die Vererbung in der Objektorientierung angelehnt. DIAG-SERVICEs (aber auch andere Elemente) können in höheren Schichten definiert werden und sind bei Erstellung einer Vererbungsbeziehung auf diese Schicht auch in den sogenannten erbenden Schichten sichtbar (d.h. ausführbar). Im Gegensatz zur Value-Inheritance, die eine generelle Übernahme der Elemente aus der erbenden Schicht zur Folge hat, steht mit dem Import- Mechanismus ein weiteres Mittel bereit, mit dem selektiv einzelne Elemente aus einer bestehenden Datenbeschreibung ausgewählt werden können. Im Fall von OBD werden die Konzepte eingesetzt, um die wiederholte identische Definition der Modes (Dienste) in den vier PROTOCOL-Layern zu vermeiden. Hierzu wird die Definition der DIAG-SERVICEs in ECU-SHARED-DATA Layer ausgelagert, von denen die vier PROTOCOL-Layer erben. Die geerbten Dienste aus den ECU- SHARED-DATA sind somit nach Öffnen des entsprechenden LOGICAL-LINKs für jeden der vier PROTOCOL-Layer sichtbar d.h. ausführbar. Da Mode 05 für OBD auf CAN nicht vorgesehen ist, ist eine zusätzliche Aufteilung der Modes und 06-0A einerseits und Mode 05 andererseits in jeweils eine ECU-SHARED-DATA erforderlich. Der PROTOCOL-Layer für OBD on CAN erbt direkt von dem erstgenannten, die übrigen PROTOCOL-Layer erben von dem letztgenannten ECU-SHARED-DATA- Layer. Abbildung 3 zeigt schematisch den Aufbau des ODX-Modells mit den Zuordnungen zu den ODX-Kategorien und den Beziehungen der wichtigsten Elemente untereinander. Die linke Hälfte der Abbildung führt die Modellierung für den Fall der Diagnose auf CAN im Detail aus, die rechte Seite deutet die Modellierung für die drei anderen Physical-Layer schematisch an. Die Modellierung hat zur Folge, dass die Service- Definitionen komplett in den ECU-SHARED-DATAs erfolgt. Die PROTOCOL- und FUNCTIONAL-GROUP-Dateien hingegen enthalten im Wesentlichen die Verweise auf die entsprechenden Kommunikationsparameter und die Informationen über die vererbenden Layer nicht aber Diagnoseinhalte. Die Unterstützung für DoIP könnte in dem Modell durch Hinzufügen des entsprechenden Tripels aus COMPARAM-SEPC, PROTOCOL und LOGICAL-LINK integriert werden. Diagnosedienste Für die Beschreibung der DIAG-SERVICEs (Modes) kommen in ODX zwei prinzipiell unterschiedliche Varianten in Frage: a) Erstellung eines DIAG-SERVICEs für jede gültige Kombination aus SID (Mode) und Subfunction. b) Einmalige generische Beschreibung des DIAG-SERVICEs mit einer TABLE, welche die Definition der spezifischen Daten für die Subfunctions enthält. Abbildung 4 zeigt die beiden Möglichkeiten schematisch anhand des UDS-Services 0x22 für die zwei Identifier 0x0001 und 0x002. Die Varianten unterscheiden sich

10 Abbildung 4: Alternativen zur Beschreibung von DIAG-SERVICEs in ODX. Links: Möglichkeit a) ohne Verwendung des Elementes TABLE. Rechts: Variante b) unter Verwendung des Elementes TABLE. zwar in der ODX-Datei deutlich, aus Sicht der Applikation müssen sie zu identischem Verhalten führen. In kommt für alle Services die Alternative b) zum Einsatz, denn sie hat folgende Vorteile: Die Service-Beschreibung kann vollständig von der Beschreibung der transportierten Daten getrennt werden. Wenn mehrere Services auf den gleichen Daten operieren, so können Erweiterungen (bspw. des DTC-Umfanges oder des PID-Umfanges) an zentraler Stelle gepflegt werden. Die Beschreibung nach Alternative b) ist deutlich kompakter, da der XML- Overhead für die n-fache Definition von DIAG-SERVICEs, REQUESTs, RES- PONSEs etc. entfällt. Mit zunehmender Anzahl von Subfunctions wird der Effekt größer. Vor dem Hintergrund der hohen Anzahl an PIDs, MIDs und TIDs im OBD-II Standard resultiert die Modellierung der Modes gemäß Variante b) in Dateigrößen, die etwa halb so groß sind verglichen mit der Modellierung nach Variante a) Eine Besonderheit in der Definition des OBD-Modes 0x01 ist die strukturelle Abhängigkeit einiger PIDs von der Unterstützung der PIDs 0x13 bzw. 0x1D. Ein Beispiel hierfür sind die PIDs 0x14-0x24. Die Unterscheidung trägt unterschiedlichen Powertrain-Layouts (Zuordnung der Sauerstoffsensoren zu den Bänken) Rechnung. Für den OBD-Test bedeutet das, dass nach dem Ausführen des Modes 0x01 mit dem PID 0x00 je nach erhaltener Steuergeräteantwort die weiteren Steuergeräte- Antworten auf konkrete PID-Anfragen unterschiedlich decodiert werden müssen. Zur Beschreibung dieses Merkmals des Modes 0x01 können die in ODX eingeführten SUB-COMPONENTs verwendet werden. SUB-COMPONENTs sind neben den Steuergeräte-Varianten (ECU-VARIANTs) ein zusätzlicher Mechanismus, um eine Varianz der Steuergeräte-Beschreibung innerhalb eines ODX-Layers auszudrücken. Für die SUB-COMPONENTs gibt es ebenfalls einen Identifikationsmechanismus, der

11 an den Variantenidentifikationsmechanismus angelehnt ist. Eine Applikation kann somit die zur Identifikation von SUB-COMPONENTS erforderlichen Services mit den geforderten Kriterien (Parameterwerte) auslesen. Je nach Antwort können dann die im Folgenden ausführbaren Services/Daten durch die Applikation entsprechend gefiltert werden. 3 Erfahrungen und Konsequenzen Die OBD ODX-Beschreibung (ISO ) verwendet konsequent die durch die ODX-Spezifikation (ISO ) verfügbaren Mechanismen zur Redundanzvermeidung und zum modularen Aufbau der Daten. Hierdurch wird ein hoher Grad an Änderungsfreundlichkeit erreicht. Die im Rahmen des Standards vorgegebenen Regeln sind auf die optimale Parametrierung eines Diagnose-Testers oder Scan-Tools zugeschnitten. Neben der Testerparametrierung sind aber auch die Code-Generierung der Diagnosesteuergerätesoftware und deren Validierung weitere wichtige Verwendungsszenarien, deren Unterstützung im Folgenden betrachtet wird. Die Anforderungen an die Datenqualität sind für die Code-Generieung und die Software-Validierung höher als für die Testerparametrierung, da die Daten in beiden Fällen Spezifikationsqualität aufweisen müssen. Die Datenqualität ist entscheidend für den Abdeckungsgrad der automatisch erzeugten Software und die Aussagekraft der Tests im Rahmen der automatisierten Validierung. Vor diesem Hintergrund können ODX-Daten die gemäß für die generische Testerparametrierung erstellt wurden, aus den folgenden Gründen nur eingeschränkt zur Code-Generierung oder Softwarevalidierung herangezogen werden: Die generische Testerbedatung eines Scantools muss alle in ISO15031 vordefinierten Datendefinitionen (PID, MID, TID, DTC) komplett enthalten, weil das Scantool mit allen erlaubten Datenkonstellationen sinnvoll umgehen muss. Die Steuergerätespezifikation hingegen darf nur die von dem spezifizierten Steuergerät tatsächlich unterstützten Daten beschreiben. ISO beschreibt die OBD-Daten in einer FUNCTIONAL-GROUP. Ein einzelnes Steuergerät wird in ODX durch ein BASE-VARIANT beschrieben. Eine BASE-VARIANT für eine OBD-Bedatung muss folglich von der FUNCTIONAL-GROUP erben. Die vom Steuergerät nicht unterstützten Services und Daten müssten deaktiviert werden. Die Verwendung dynamischer TABLEs in den Steuergeräteantworten ist aus Sicht der Testerparametrierung ideal, für die Steuergerätespezifikation aber nicht ausreichend, weil nicht ausgedrückt werden kann, dass in den Steuergeräteantworten nur die im Request angefragten Daten übertragen werden dürfen. ODX sieht hierfür zwar einen Mechanismus vor (MATCHING-REQUEST), er kann aber in der konkreten Situation nicht verwendet werden, da bis zu 6 PIDs in einer Antwort übertragen werden können. Die Modellierung des Powertrain-Layouts mit SUB-COMPONENTs - wie oben beschrieben - wird der Testerparametrierung gerecht, weil zur Laufzeit entschieden werden kann, welche Teile des Modells gültig sind. Die Information, für welche SUB-COMPONENT Code erzeugt werden soll, also welches Powertrain-Layout vorliegt, muss entweder dem Code-Generator außerhalb von ODX mitgeteilt werden, oder die ODX-Daten müssen entsprechend aufbereitet werden.

12 Die Verwendung der OBD-II Daten in ISO impliziert auch die Übernahme einiger OBD-II-Konzepte wie etwa die Ermittlung der verfügbaren/unterstützten PIDs durch Anfrage der Supported PIDs 0x00, 0x20 etc., deren Steuergeräteantwort die unterstützten PIDs in dem entsprechenden PID-Bereich (0x01-0x1F, 0x21-0x3F, etc.) enthält. Die grundlegenden Design-Entscheidungen der OBD-ODX-Modellierung können auch für die Modellierung des WWH-OBD-Standards ISO übernommen werden. Änderungen betreffen im Wesentlichen die ECU-SHARED-DATA mit den Service-Definitionen, denn die OBD-II Modes müssen durch die entsprechenden UDS- Services ersetzt werden. Die für OBD-II zulässigen K-Line-Protokollle und SAE J1850 entfallen. An deren Stelle tritt die Diagnose über IP. Die rechte Seite der Abbildung 3 müsste also durch PROTOCOL, LOGICAL-LINK und COMPARAM- SPEC für DoIP ersetzt werden. Da ISO die Definition der Daten aus SAE J1979 und SAE J2012 in ECU-SHARED-DATA-Layern definiert, könnten diese weitestgehend übernommen werden, allerdings müssen einzelne Datenbeschreibungen der jeweils aktuellen Version der SAE J2012-DA und SAE J1979-DA angepasst werden. Die Einführung von WWH-OBD für den Nutzfahrzeugbereich ist für Fahrzeuge ab Modelljahr 2013 gefordert. Deshalb beschäftigen sich die Entwicklungsabteilungen der Fahrzeughersteller seit geraumer Zeit mit diesem Thema, das sie vor neue Herausforderungen stellt. Es ist davon auszugehen, dass WWH-OBD nach ISO in der Praxis zunächst auf die CAN-Kommunikation beschränkt bleiben wird. So kann zunächst die WWH-OBD-Diagnose eingeführt werden, in einem späteren Schritt kann dann ggf. auch der neue Physical-Layer unterstützt werden. Risiken bei der Einführung neuer Standards und Technologien lassen sich durch die isolierte Betrachtungsweise besser einschätzen und minimieren. Abhängig von den potentiellen Absatzmärkten ist eine nicht zu unterschätzende Vielfältigkeit an unterschiedlichen Fehlerspeicherimplementierungen notwendig, die je nach regionalen Anforderungen zum Einsatz kommen müssen. So wird auf dem US- Markt die Diagnose über J1939 bzw. OBD-II noch einige Zeit gesetzt sein. Für Fahrzeuge die auch auf dem europäischen Markt verkauft werden sollen, muss ebenfalls der Zugang und die Diagnose gemäß ISO bzw. ISO vorgesehen werden. Neben diesen Varianten ist die Enhanced-Diagnose für die Serviceorganisation eine weitere Ausprägung. Es wird also nicht selten vorkommen, dass man alle vier Implementierungen auf einem Steuergerät vorfindet. Hier stellt sich auch die Frage, wie die Fehlercodes der Herstellerdiagnose in die standardisierten Codes abgebildet werden. In ODX sind die unterschiedlichen Ausprägungen durch entsprechende DTC-DOPs beschreibbar, die je nach Diagnoseprotokoll für die Kommunikation herangezogen werden können. Die Umsetzung von OBD-II und WWH-OBD zeigt, wie verschiedene Standards kombiniert werden können. Die Integration dieser Technologien hat gerade erst begonnen. Die Zukunft wird zeigen, wie sich die Themen WWH-OBD, OBD über ODX und DoIP weiter entwickeln werden.

13 Abkürzungen ASAM CAN CARB DA DoIP DTC EOBD GTR IP ISO KWP MIL MVCI OBD ODX SAE TCP UDS VOBD WWH-OBD Association for Standardisation of Automation and Measuring Systems Controller Area Network Californian Air Resources Board Digital Annex Diagnostics over IP Diagnostic Trouble Code European On-Board-Diagnosis Global Technical Regulation Internet Protocol International Organization for Standardization Key Word Protocol Malfunction Indication Lamp Modular Vehicle Communication Interface On-Board-Diagnosis Open Diagnostic Data Exchange Society of Automotive Engineers Transmission Control Protocol Unified Diagnostic Services Vehicle On-Board-Diagnosis World-Wide-Harmonized OBD Literatur [1] Title 13, California Code Regulations, Section , Malfunction and Diagnostic System Requirements for 2004 and Subsequent Model-Year Passenger Cars, Light-Duty Trucks, and Medium-Duty Vehicles and Engines (OBD II) [2] Richtlinie 98/69/EG des Europäischen Parlamentes und des Rates vom 13. Oktober 1998 über Maßnahmen gegen die Verunreinigung der Luft durch Emissionen von Kraftfahrzeugen und zu Änderung der Richtlinie 70/220/EWG des Rates [3] ISO 15031: Road vehicles - Communication between vehicle and external test equipment for emissions-related diagnostics [4] Global Technical Regulation No. 5: Technical Requirements for On-Board- Diagnostic Systems (OBD) for Road Vehicles [5] ISO : Road vehicles - Implementation of WWH-OBD communication requirements [6] ISO 13400: Road vehicles - Diagnostic communication over Internet Protocol (DoIP) [7] ISO : Road vehicles - Open diagnostic data exchange (ODX) Part 1: Data model specification [8] ISO : Road vehicles - Open diagnostic data exchange (ODX) Part 2: Emissions-related diagnostic data [9] Automatic Validation of Diagnostic Services by use of a Diagnostic Integration and Validation Assistant, ATZ elektronik 6/2008

Trends in der Fahrzeugdiagnose

Trends in der Fahrzeugdiagnose Trends in der Fahrzeugdiagnose Vector J1939 User Day, 5. März 2008 V1.0 2008-03-06 Agenda > Trends in der Fahrzeugdiagnose UDS ODX AUTOSAR WWH-OBD Zusammenfassung Slide: 2 Trends in der Fahrzeugdiagnose

Mehr

Referenten. Vorstellung Agenda Literaturverzeichnis Normen & Standards Symbole & Abkürzungen. Diagnosesysteme im Automobil

Referenten. Vorstellung Agenda Literaturverzeichnis Normen & Standards Symbole & Abkürzungen. Diagnosesysteme im Automobil Referenten 2 Dr.-Ing. Jörg Supke Nach Studium der Mechatronik, Promotion im Bereich Fahrzeugtechnik an der TH Darmstadt Produktmanager bei Tool-Hersteller im Bereich Fahrzeugdiagnose Seit Juli 2008 Gründer

Mehr

ECU Measurement, Calibration und Diagnostics

ECU Measurement, Calibration und Diagnostics ECU Measurement, Calibration und Diagnostics Dipl.-Phys. Christian Schleiermacher National Instruments Dipl.-Ing. Joachim Tauscher SMART Electronic Development GmbH Agenda ECU Measurement and Calibration

Mehr

6 Kommunikationssysteme

6 Kommunikationssysteme 6 Kommunikationssysteme 6.1 Übersicht Die in diesem Abschnitt beschriebenen Kommunikationssysteme basieren auf PC-Hardware mit Windows 1 als Betriebssystem. PC-basierte Kommunikationssysteme werden in

Mehr

Diagnose- und Testfunktionen in CANoe.J1939

Diagnose- und Testfunktionen in CANoe.J1939 Diagnose- und Testfunktionen in CANoe.J1939 V0.05 2008-03-06 Agenda > CANoe Test Feature Set Diagnose mit CANoe Slide: 2 Notwendigkeit von Tests? Ausgangssituation Heute Komplexität der Software in Steuergeräten

Mehr

Automotive Electronics

Automotive Electronics Automotive Electronics Fachartikel Vortrag auf der HdT-Konferenz vom 13./14.05.2009 in Dresden Einführung in die standardisierte Diagnosekommunikation mit UDS Autor: Peter Subke Softing AG Abstract A large

Mehr

Automotive Diagnostic Software ScanMaster PPC. Benutzerhandbuch. Version 1.0. Copyright 2008 WGSoft.de. All rights reserved

Automotive Diagnostic Software ScanMaster PPC. Benutzerhandbuch. Version 1.0. Copyright 2008 WGSoft.de. All rights reserved Automotive Diagnostic Software ScanMaster PPC Benutzerhandbuch Version 1.0 2008 Copyright 2008 WGSoft.de. All rights reserved Inhalt 1. Grundmerkmale... 3 2. Minimale Hard- und Software Voraussetzungen...

Mehr

Gebrauchsanleitung

Gebrauchsanleitung 08/11-W2010-Wei Gebrauchsanleitung 739 660 EOBD/OBD2 Simulator 1 Anschluss Batterie + 2 Einsteller Lambdasondenspannung 3 Einsteller Luftmasse 4 Umschalter Lambdaspannung konstant/periodisch wechseln zw.

Mehr

On-Board Diagnostics Europäische Eigendiagnose

On-Board Diagnostics Europäische Eigendiagnose On-Board Diagnostics Europäische Eigendiagnose On Board Diagnose Systeme Definition EOBD ist die Abkürzung für Europäische On-Board Diagnose, d.h. ein Diagnosesystem, das im Fahrzeug eingebaut (on board)

Mehr

Diagnosesysteme im Automobilsektor

Diagnosesysteme im Automobilsektor Diagnosesysteme im Automobilsektor Idee Autodiagnosesystem für pers. Gebrauch Diagnose aller Komponenten Erfasst alle verbreiteten Automarken Reparatur kleinerer Elektronikprobleme Eigenschaften der Software

Mehr

Porsche Cayenne S Hybrid

Porsche Cayenne S Hybrid Praktikumsbeleg / Studiengang Fahrzeugtechnik Porsche Cayenne S Hybrid Untersuchung der Hochvolt-Technik eines Cayenne S Hybrid unter besonderer Berücksichtigung einer zukünftigen Nutzung der implementierten

Mehr

Fahrzeugdiagnose. Martin Kaesberger. Universität Kaiserslautern m kaesberg11@cs.uni-kl.de

Fahrzeugdiagnose. Martin Kaesberger. Universität Kaiserslautern m kaesberg11@cs.uni-kl.de Fahrzeugdiagnose Martin Kaesberger Universität Kaiserslautern m kaesberg11@cs.uni-kl.de Einleitung Durch Zunahme des Straßenverkehrs in den 90er Jahren kam es zu einem Anstieg der Luftverschmutzung. Um

Mehr

OTX ODX. MVCI-Server. Hauptkomponenten - Grundlagen. Diagnoseabläufe. Diagnosedatenbank. Diagnoselaufzeitsystem. für Diagnoseabläufe

OTX ODX. MVCI-Server. Hauptkomponenten - Grundlagen. Diagnoseabläufe. Diagnosedatenbank. Diagnoselaufzeitsystem. für Diagnoseabläufe Hauptkomponenten - Grundlagen 3 Diagnosedatenbank Bereitstellung eines standardisierten Austauschformats für Diagnosedaten ODX ISO 22901 Diagnoseabläufe Bereitstellung eines standardisierten Austauschformats

Mehr

modiag Fahrzeugdiagnose

modiag Fahrzeugdiagnose Allgemein modiag professional richtet sich insbesondere an den Umrüster für Fahrzeuge mit LPG- oder CNG-Anlagen. Seine besonderen Features machen das Abstimmen der Gasanlage mit dem Benzinsteuergerät zu

Mehr

CAN-Schnittstelle für FMS. Einführung

CAN-Schnittstelle für FMS. Einführung Einführung CAN-Schnittstelle für FMS Dieses Dokument enthält Informationen zum FMS-Standard. Der FMS-Standard ist eine von mehreren Lkw-Herstellern entwickelte, offene Schnittstelle. FMS-Standard description

Mehr

Produktinformation CANdito

Produktinformation CANdito Produktinformation CANdito Inhaltsverzeichnis 1 Übersicht... 3 1.1 Einführung... 3 1.2 Die Vorteile im Überblick... 3 1.3 Schnittstellen... 4 1.4 Systemvoraussetzungen... 4 1.5 Weiterführende Informationen...

Mehr

Kompakter OBD- 2-Analyser

Kompakter OBD- 2-Analyser Kompakter OBD- 2-Analyser Bedienungsanleitung Als erstes das mitgelieferte OBD2-Interfacekabel in die OBD2-Buchse des Fahrzeuges einstecken. Diese sollte sich im Umkreis von einem Meter des Fahrersitzes

Mehr

Abbildung 1: Tool-Qualification-Kits für Testwell CTC++ Test Coverage Analyser

Abbildung 1: Tool-Qualification-Kits für Testwell CTC++ Test Coverage Analyser Qualification-Kit für Testwell CTC++ In der sicherheitskritischen Softwareentwicklung müssen die im Projekt eingesetzten Werkzeuge zunächst klassifiziert werden (Tool Classification). Diese Klassifizierung

Mehr

Messdatenerfassung: Messdaten und CAN-Botschaften synchron erfassen Nur einen USB-Anschluss entfernt!

Messdatenerfassung: Messdaten und CAN-Botschaften synchron erfassen Nur einen USB-Anschluss entfernt! Messdatenerfassung: Messdaten und CAN-Botschaften synchron erfassen Nur einen USB-Anschluss entfernt! Balazs Toth balazs.toth@ni.com Agenda Übersicht NI-XNET Plattform NI-XNET unter CompactDAQ NI-XNET

Mehr

How to Survive an Audit with Real-Time Traceability and Gap Analysis. Martin Kochloefl, Software Solutions Consultant Seapine Software

How to Survive an Audit with Real-Time Traceability and Gap Analysis. Martin Kochloefl, Software Solutions Consultant Seapine Software How to Survive an Audit with Real-Time Traceability and Gap Analysis Martin Kochloefl, Software Solutions Consultant Seapine Software Agenda Was ist Traceability? Wo wird Traceability verwendet? Warum

Mehr

Version 1.2.0. smart.finder SDI. What's New?

Version 1.2.0. smart.finder SDI. What's New? Version 1.2.0 smart.finder SDI What's New? 1 Neue Funktionen in Version 1.2.0 3 2 Neue Funktionen in Version 1.1 3 Neue Funktionen in Version 1.2.0 Neue Funktionen Unterstützung von Java 8 Die aktuelle

Mehr

Produktinformation CANdelaStudio

Produktinformation CANdelaStudio Inhaltsverzeichnis 1 Einführung... 3 1.1 Die Vorteile im Überblick... 3 2 Funktionen... 4 3 ODX-Funktionen... 6 4 Import aus ODX 2.0.1, 2.2.0... 6 5 Qualitätserhöhung durch Single-Source-Prinzip... 6 6

Mehr

Inhalt. Einleitung Datenmodell DIAG-LAYER-CONTAINER COMPARAM-SPEC VEHICLE-INFO-SPEC FLASH ECU-CONFIG MULTIPLE-ECU-JOB-SPEC FUNCTION-DICTIONARY

Inhalt. Einleitung Datenmodell DIAG-LAYER-CONTAINER COMPARAM-SPEC VEHICLE-INFO-SPEC FLASH ECU-CONFIG MULTIPLE-ECU-JOB-SPEC FUNCTION-DICTIONARY Inhalt 2 MVCI-Server (ASAM 3D-Server, ODX-Kernel) Test- und Diagnoseanwendungen Die Kühlwassertemperatur = 64 oc Wie wird die PDU in die Temperatur n umgerechnet? Wie groß ist die Kühlwassertemperatur?

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Group and Session Management for Collaborative Applications

Group and Session Management for Collaborative Applications Diss. ETH No. 12075 Group and Session Management for Collaborative Applications A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZÜRICH for the degree of Doctor of Technical Seiences

Mehr

Einleitung Diagnoselaufzeitsystem D-PDU-API

Einleitung Diagnoselaufzeitsystem D-PDU-API 2 Open System Interconnection (OSI) Schichtenmodell (ISO 1978) 3 Eigentliche Anwendung (On-Board z.b. Motorsteuerung oder Off-Board z.b. Diagnosetester) Schicht Bezeichnung 7 6 * 5 * 4 3 * 2 1 Application

Mehr

ISO 27000 mit oder ohne BSI-Grundschutz? Oliver Müller

ISO 27000 mit oder ohne BSI-Grundschutz? Oliver Müller ISO 27000 mit oder ohne BSI-Grundschutz? Oliver Müller Agenda ISO 27001+BSI IT Grundschutz ISO 27001 nativ Eignung Fazit http://www.bsi.bund.de Grundsätzlicher Analyseansatz Prozess benötigt Anwendungen

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Übersetzung des Singapore Framework für Dublin-Core-Anwendungsprofile

Übersetzung des Singapore Framework für Dublin-Core-Anwendungsprofile Übersetzung des Singapore Framework für Dublin-Core-Anwendungsprofile Identifier: http://www.kimforum.org/material/pdf/uebersetzung_singapore_20090213.pdf Title: Übersetzung des Singapore Framework für

Mehr

TeleTrusT-Informationstag "IT-Sicherheit im Smart Grid"

TeleTrusT-Informationstag IT-Sicherheit im Smart Grid TeleTrusT-Informationstag "IT-Sicherheit im Smart Grid" Berlin, 31.05.2011 Sebastian Kaluza BMW Group sebastian.kaluza@bmw.de emobility Sicheres Laden Standardisierung der Lade-Protokolle in ISO/IEC 15118

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Proseminar: Website-Management-Systeme

Proseminar: Website-Management-Systeme Proseminar: Website-Management-Systeme Thema: Web: Apache/Roxen von Oliver Roeschke email: o_roesch@informatik.uni-kl.de Gliederung: 1.) kurze Einleitung 2.) Begriffsklärung 3.) Was ist ein Web? 4.) das

Mehr

Test & Diagnose. Thomas Romanek. thomas.romanek@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab

Test & Diagnose. Thomas Romanek. thomas.romanek@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab Test & Diagnose Thomas Romanek thomas.romanek@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einführung Tests zur Qualitätssicherung V-Modell Spezielle Verfahren in Automotive Das Diagnosesystem

Mehr

Dokumenten-Modelle im CMS CoreMedia

Dokumenten-Modelle im CMS CoreMedia Dokumenten-Modelle im CMS CoreMedia Einleitung Das Content Management System CoreMedia ist ein innovatives Produkt der Hamburger Firma CoreMedia, das hauptsächlich im Unternehmensbereich und für komplexe

Mehr

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- entwicklung von Fahrzeugen Martin Jaensch, Dr. Bernd Hedenetz, Markus Conrath Daimler AG Prof. Dr. Klaus D. Müller-Glaser

Mehr

ZK2000SF ACCESS CONTROL ZUTRITTSKONTROLLE

ZK2000SF ACCESS CONTROL ZUTRITTSKONTROLLE ZUTRITTSKONTROLLE ACCESS CONTROL SMPX.xx SMPX.xG ZK2000SF Kommunikation über ISDN oder TCP/IP Intelligenter ler Individuelle Rechteverwaltung Verwaltung von 150.000 Personen Communication via ISDN or TCP/IP

Mehr

UPU / CEN / ETSI. E-Zustellung in Europa & weltweit

UPU / CEN / ETSI. E-Zustellung in Europa & weltweit UPU / CEN / ETSI E-Zustellung in Europa & weltweit Wien, den 14. Jänner 2015 Consulting Technology Operations Copyright: Document Exchange Network GmbH EUROPÄISCHE KOMMISSION Brüssel, den 30.7.2014 COM(2014)

Mehr

AFDX Explorer - AFDX Monitor - AFDX Switch

AFDX Explorer - AFDX Monitor - AFDX Switch AFDX Suite AFDX Explorer - AFDX Monitor - AFDX Switch Was ist AFDX? Die AFDX Suite im Überblick AFDX steht für Avionics Full Duplex Switched Ethernet, ein Übertragungsstandard, der auf Ethernet basiert

Mehr

BT OBD 327. Bluetooth OBD Interface. Technische Dokumentation

BT OBD 327. Bluetooth OBD Interface. Technische Dokumentation Bluetooth OBD Interface by Technische Dokumentation Dieses Dokument wurde sorgfältig überprüft. Die APOS GmbH Embedded Systems behält sich das Recht vor, Änderungen an allen hier beschriebenen Produkten

Mehr

ecall sms & fax-portal

ecall sms & fax-portal ecall sms & fax-portal Beschreibung des s Dateiname Beschreibung_-_eCall 2015.08.04 Version 1.1 Datum 04.08.2015 Dolphin Systems AG Informieren & Alarmieren Samstagernstrasse 45 CH-8832 Wollerau Tel. +41

Mehr

System Integration. and its compliance testing necessities. Automotive BUS Systems + Ethernet, Stuttgart, 10 Dec 2013.

System Integration. and its compliance testing necessities. Automotive BUS Systems + Ethernet, Stuttgart, 10 Dec 2013. System Integration and its compliance testing necessities Automotive BUS Systems + Ethernet, Stuttgart, 10 Dec 2013 Georg Janker CTO experts in automotive data communication Agenda 1. Motivation 2. Positionierung

Mehr

ISO/IEC 27001. Neue Version, neue Konzepte. Quo Vadis ISMS?

ISO/IEC 27001. Neue Version, neue Konzepte. Quo Vadis ISMS? ISO/IEC 27001 Neue Version, neue Konzepte Quo Vadis ISMS? 2/18 Ursachen und Beweggründe Regulärer Zyklus für Überarbeitung von ISO/IEC 27001:2005 Zusätzlich neues Projekt MSS (Managment System Standards)

Mehr

Produktphilosophie erstellen

Produktphilosophie erstellen User Experience Produktphilosophie erstellen Bereich Anforderungen Aktivität Ziele Erleichterte Kommunikation zwischen Stakeholdern Designentscheidungen erleichtern/rechtfertigen schnell durchführbar einfach

Mehr

Kernstandards für das Smart Grid aus dem Technical Committee IEC TC 57. Dr.-Ing. Mathias Uslar, OFFIS

Kernstandards für das Smart Grid aus dem Technical Committee IEC TC 57. Dr.-Ing. Mathias Uslar, OFFIS Kernstandards für das Smart Grid aus dem Technical Committee IEC TC 57 Dr.-Ing. Mathias Uslar, OFFIS Vision: Smart Grid Quelle:EU SG ETP National Institute for Standards and Technology (USA): The term

Mehr

Inhalt. Einleitung Transportprotokolle CAN ISOTP FlexRay AUTOSAR 3.0l Diagnoseprotokolle OBD on CAN UDS KWP 2000 on CAN. Diagnosesysteme im Automobil

Inhalt. Einleitung Transportprotokolle CAN ISOTP FlexRay AUTOSAR 3.0l Diagnoseprotokolle OBD on CAN UDS KWP 2000 on CAN. Diagnosesysteme im Automobil Inhalt 2 Kommunikation im Fahrzeug * 3 Motor Steuergerät Getriebe Steuergerät ABS Steuergerät Kombiinstrument Navigation MMI High-Speed-Bus (Antriebs-CAN) Low-Speed-Bus (Komfort-CAN) Gateway Infotainment-Bus

Mehr

Validierung von Software-Werkzeugen. Matthias Hölzer-Klüpfel

Validierung von Software-Werkzeugen. Matthias Hölzer-Klüpfel Validierung von Software-Werkzeugen Matthias Hölzer-Klüpfel Was ist Validierung ISO 9000:2000 Bestätigung durch Bereitstellung eines objektiven Nachweises, dass die Anforderungen für einen spezifischen

Mehr

Modellbasierter Entwurf sicherheitskritischer Anwendungen. Von Moritz Borgmann Für VL Eingebettete Systeme Sommer Semester 2009

Modellbasierter Entwurf sicherheitskritischer Anwendungen. Von Moritz Borgmann Für VL Eingebettete Systeme Sommer Semester 2009 Modellbasierter Entwurf sicherheitskritischer Anwendungen Von Moritz Borgmann Für VL Eingebettete Systeme Sommer Semester 2009 Einführung Einführung Modellbasierter Entwurf und der IEC 61508 Ausblick Zusammenfassung,

Mehr

modiag express ist eine OBD-Scan-Software, die in Verbindung mit OBD-DIAG-Interfaces in der Lage ist, Live-Daten aus dem Motorsteuergerät abzurufen

modiag express ist eine OBD-Scan-Software, die in Verbindung mit OBD-DIAG-Interfaces in der Lage ist, Live-Daten aus dem Motorsteuergerät abzurufen modiag express ist eine OBD-Scan-Software, die in Verbindung mit OBD-DIAG-Interfaces in der Lage ist, Live-Daten aus dem Motorsteuergerät abzurufen und zu visualisieren, den Fehlerspeicher auszulesen und

Mehr

OBD2 Software modiag - Funktionen. Abhängig von der gewählten Programmversion können Sie mit modiag:

OBD2 Software modiag - Funktionen. Abhängig von der gewählten Programmversion können Sie mit modiag: OBD2 Software modiag - Funktionen Abhängig von der gewählten Programmversion können Sie mit modiag: Laden Sie hier ein Beispiel zur Gasanlageneinstellung mit modiag professional herunter (benötigt Adobe

Mehr

ElsterOnline-Portal Benutzeranleitung CSV-Format der Import-Datei ZM. im BZSt-Verfahren Zusammenfassende Meldung

ElsterOnline-Portal Benutzeranleitung CSV-Format der Import-Datei ZM. im BZSt-Verfahren Zusammenfassende Meldung ElsterOnline-Portal Benutzeranleitung CSV-Format der Import-Datei im BZSt-Verfahren Zusammenfassende Meldung Stand: 03.11.2015 Seite 1 von 6 Inhaltsverzeichnis 1 Einleitung... 3 2 Versionierung der Importfunktion...

Mehr

UC4 Rapid Automation Handbuch für den Hyper-V Agent

UC4 Rapid Automation Handbuch für den Hyper-V Agent UC4 Rapid Automation Handbuch für den Hyper-V Agent UC4 Software, Inc. UC4: Rapid Automation Handbuch für den Hyper-V Agent Von Jack Ireton Dokumentennummer: RAHV-062011-de *** Copyright UC4 und das UC4-Logo

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

ISO/IEC 27001/2. Neue Versionen, weltweite Verbreitung, neueste Entwicklungen in der 27k-Reihe

ISO/IEC 27001/2. Neue Versionen, weltweite Verbreitung, neueste Entwicklungen in der 27k-Reihe ISO/IEC 27001/2 Neue Versionen, weltweite Verbreitung, neueste Entwicklungen in der 27k-Reihe 1 ISO Survey of Certifications 2009: The increasing importance organizations give to information security was

Mehr

Die Rolle des QM-Systems - Forderung und Praxis

Die Rolle des QM-Systems - Forderung und Praxis Die Rolle des QM-Systems - Forderung und Praxis Inhalt Warum ist ein QM-System für Hersteller von Medizinprodukten so wichtig? Was kann die Basis eines solchen Systems sein? Zusammenfassung FAQs Inhalt

Mehr

Übersicht. Normung von Software in der Medizin. Vorstellung der DKE. Vorstellung der Normungsgremien. Normen im Bereich Software.

Übersicht. Normung von Software in der Medizin. Vorstellung der DKE. Vorstellung der Normungsgremien. Normen im Bereich Software. Normung von Software in der Medizin Übersicht Vorstellung der DKE Vorstellung der Normungsgremien Normen im Bereich Software Zukunftstrends 20.09.2013/1 Vorstellung der DKE Gemeinnütziger Verband ohne

Mehr

2.7! Überwachung und Diagnose

2.7! Überwachung und Diagnose Überwachung! Systemzustand überwachen! unerwünschte oder unerlaubte Systemzustände erkennen! Gegenmaßnahmen einleiten! Fehlererkennung möglich vor einer Störung oder einem Ausfall 1 Aufbau von Fahrer mwelt

Mehr

ColdFusion 8 PDF-Integration

ColdFusion 8 PDF-Integration ColdFusion 8 PDF-Integration Sven Ramuschkat SRamuschkat@herrlich-ramuschkat.de München & Zürich, März 2009 PDF Funktionalitäten 1. Auslesen und Befüllen von PDF-Formularen 2. Umwandlung von HTML-Seiten

Mehr

File Sharing zwischen Mac OS X und Windows XP Clients

File Sharing zwischen Mac OS X und Windows XP Clients apple 1 Einführung File Sharing zwischen Mac OS X und Windows XP Clients Möchten Sie Dateien zwischen einem Macintosh Computer und Windows Clients austauschen? Dank der integralen Unterstützung für das

Mehr

Aktualisierung der ISO/IEC 27001 (ISMS): Entstehung, Änderungsbedarf und Handlungsempfehlungen für Unternehmen

Aktualisierung der ISO/IEC 27001 (ISMS): Entstehung, Änderungsbedarf und Handlungsempfehlungen für Unternehmen Aktualisierung der ISO/IEC 27001 (ISMS): Entstehung, Änderungsbedarf und Handlungsempfehlungen für Unternehmen Bearbeitet von Stefan Beck 1. Auflage 2015. Taschenbuch. 148 S. Paperback ISBN 978 3 95934

Mehr

Die neue ISO 9001:2015 Neue Struktur

Die neue ISO 9001:2015 Neue Struktur Integrierte Managementsysteme Die neue ISO 9001:2015 Neue Struktur Inhalt Neue Struktur... 1 Die neue ISO 9001:2015... 1 Aktuelle Status der ISO 9001... 3 Änderungen zu erwarten... 3 Ziele der neuen ISO

Mehr

Einrichtung eines Webdienstes. Bereitstellung der Bauleitpläne. über einen WebMapService mit GetFeatureInfo

Einrichtung eines Webdienstes. Bereitstellung der Bauleitpläne. über einen WebMapService mit GetFeatureInfo Einrichtung eines Webdienstes über einen WebMapService mit GetFeatureInfo 1. Allgemeines 1.1. Webdienste Als Webdienste (engl. Web-Services) werden internetgestützte elektronische Dienstleistungen bezeichnet.

Mehr

Empfehlung für die technische Kommunikation von Produktänderungen im GDSN

Empfehlung für die technische Kommunikation von Produktänderungen im GDSN 1 Germany Empfehlung für die technische Kommunikation von Produktänderungen im GDSN Version 1.0 Stand Mai 2014 I I I Global Standards. Make Business Efficient. Zielsetzung des Dokuments Ziel der vorliegenden

Mehr

2. Architektur von Kommunikationssystemen

2. Architektur von Kommunikationssystemen 2. Architektur von Kommunikationssystemen 2.1 2.2 TCP/IP-basierte Protokollarchitektur Digitale Kommunikationssysteme Prof. Dr. Habermann / Dr. Hischke 12-01 / 1 Das OSI-Referenzmodell wird ausführlich

Mehr

Rollen- und Rechtekonzept

Rollen- und Rechtekonzept Inhaltsverzeichnis Rollen- und Rechtekonzept 1. Ziele...1 2. Konzeption zur Realisierung durch Access Control List und im Management-Interface...2 2.1. Ansatz...2 2.2. Safety oder Security...2 2.3. User-

Mehr

EEX Kundeninformation 2007-09-05

EEX Kundeninformation 2007-09-05 EEX Eurex Release 10.0: Dokumentation Windows Server 2003 auf Workstations; Windows Server 2003 Service Pack 2: Information bezüglich Support Sehr geehrte Handelsteilnehmer, Im Rahmen von Eurex Release

Mehr

ISO 20022 Harmonisierung des Zahlungsverkehrs Schweiz Infoanlass für Business-Software-Anbieter 17. September 2015

ISO 20022 Harmonisierung des Zahlungsverkehrs Schweiz Infoanlass für Business-Software-Anbieter 17. September 2015 ISO 20022 Harmonisierung des Zahlungsverkehrs Schweiz Infoanlass für Business-Software-Anbieter 17. September 2015 2 Agenda Grundsätzliche Überlegungen zur Standardisierung Ziele der Migration ZV CH Roadmap

Mehr

Varianten Handling in AUTOSAR

Varianten Handling in AUTOSAR Vielfalt beherrschen und Kosten kontrollieren V0.01 2015-09-22 Was sind eigentlich Varianten Beispiele für verschiedene (verwandte) Abwandlung eines Steuergerätes Airbag Steuergerät für und OEM B Anwendung:

Mehr

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering,

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Manfred Broy Lehrstuhl für Software & Systems Engineering Technische Universität München Institut für Informatik ISO 26262 Functional

Mehr

Requirements-Management Ein praktisches Beispiel

Requirements-Management Ein praktisches Beispiel 2003 Eurocopter Deutschland GmbH 2003 Requirements-Management Ein praktisches Beispiel a.s.drexler@t-online.de Softwareprozesse in Luft- und Raumfahrtprojekten Workshop der DGLR am 15.10.2003 Der Vortrag

Mehr

AP-Note FlexRay Cluster-Entwurf mit dem FIBEX-Editor

AP-Note FlexRay Cluster-Entwurf mit dem FIBEX-Editor Münchener Str. 4a D-82131 Gauting Tel. +49-89-8931043/45 E-Mail: contact@crst.de Web: www.crst.de AP-Note FlexRay Cluster-Entwurf mit dem FIBEX-Editor Einführung Bisher wurden seitens der Automobilhersteller

Mehr

Protokoll vom BtG Meeting am 17.04.2007 und 08.05.2007

Protokoll vom BtG Meeting am 17.04.2007 und 08.05.2007 Protokoll vom BtG Meeting am 17.04.2007 und 08.05.2007 Author: IISM Created: May 10, 2007 Contents 1 Erstes Treffen: 17.04.2007 2 1.1 Teilnehmer........................................ 2 1.2 Anforderungen

Mehr

ANNEX A - PROTOCOL IMPLEMENTATION CONFORMANCE STATEMENT (NORMATIVE)

ANNEX A - PROTOCOL IMPLEMENTATION CONFORMANCE STATEMENT (NORMATIVE) ANNEX A - PROTOCOL IMPLEMENTATION CONFORMANCE STATEMENT (NORMATIVE) BACNET STANDARDIZED DEVICE PROFILE (ANNEX K): LIST ALL BACNET INTEROPERABILITY BUILDING BLOCKS SUPPORTED (ANNEX K): SEGMENTATION CAPABILITY:

Mehr

Ein Erfahrungsbericht beim Einsatz von generierenden Ansätzen im Vergleich zu generischen Lösungen

Ein Erfahrungsbericht beim Einsatz von generierenden Ansätzen im Vergleich zu generischen Lösungen Ein Erfahrungsbericht beim Einsatz von generierenden Ansätzen im Vergleich zu generischen Lösungen Tom Krauß Agenda Begriffsdefinition Verfahren Praktische Beispiele Vergleich und Bewertung Begriffsklärung

Mehr

Einführung in die Programmierung mit Java. Hörsaalübung

Einführung in die Programmierung mit Java. Hörsaalübung Einführung in die Programmierung mit Java Hörsaalübung Folie 1 Grundlagen der Objektorientierung Seit Anfang der Neunzigerjahre Standardmethode der Softwareentwicklung. Die OOP Objektorientierte Programmierung

Mehr

Machbar? Machbar! 07.10.2010

Machbar? Machbar! 07.10.2010 TANNER AG 2010 TANNER AG Kemptener Straße 99 D-88131 Lindau (B) Telefon +49 8382 272-0 Fax +49 8382 272-900 www.tanner.de info@tanner.de Agile Softwareentwicklung im regulativen Umfeld. Machbar? Machbar!

Mehr

Vorgaben und Erläuterungen zu den XML-Schemata im Bahnstromnetz

Vorgaben und Erläuterungen zu den XML-Schemata im Bahnstromnetz Anwendungshandbuch Vorgaben und Erläuterungen zu den XML-Schemata im Bahnstromnetz Version: 1.0 Herausgabedatum: 31.07.2015 Ausgabedatum: 01.11.2015 Autor: DB Energie http://www.dbenergie.de Seite: 1 1.

Mehr

Maschinen und Apparate im PROLIST-Engineering-Workflow. (Machines and apparatuses in the PROLIST engineering workflow)

Maschinen und Apparate im PROLIST-Engineering-Workflow. (Machines and apparatuses in the PROLIST engineering workflow) Automation 2012 Kurzfassung Maschinen und Apparate im PROLIST-Engineering-Workflow (Machines and apparatuses in the PROLIST engineering workflow) Dr.-Ing. Peter Zgorzelski, Bayer Technology Services GmbH,

Mehr

Erhebung interoperabler medizinischer Daten basierend auf ISO/CEN 13606 Archetypen

Erhebung interoperabler medizinischer Daten basierend auf ISO/CEN 13606 Archetypen Hans Demski GMDS2010 - Mannheim Erhebung interoperabler medizinischer Daten basierend auf ISO/CEN 13606 Archetypen Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt Arbeitsgruppe

Mehr

Anmerkungen zur Langlebigkeit von Testartefakten

Anmerkungen zur Langlebigkeit von Testartefakten Anmerkungen zur Langlebigkeit von Testartefakten Prof. Dr. Jens Grabowski Institut für Informatik Georg-August-Universität Göttingen grabowski@cs.uni-goettingen.de 1 Wie lange leben Testartefakte? Sinngemäßes

Mehr

ricardoassistent Gültig ab 20. August 2013

ricardoassistent Gültig ab 20. August 2013 Gültig ab 20. August 2013 1 Vision und Philosophie des neuen ricardoassistenten 3 2 Übersicht über die wichtigsten Funktionen des neuen ricardoassistenten 3 2.1 Einige neue Funktionen, die ab dem 20. August

Mehr

Industrielle Bussysteme : Modbus/TCP

Industrielle Bussysteme : Modbus/TCP Industrielle Bussysteme : Modbus/TCP Dr. Leonhard Stiegler Automation www.dhbw-stuttgart.de Inhalt Modbus/TCP Grundsätze und Versionen Protokollbeschreibung Datenmodell und Datencodierung Adressierung

Mehr

Anlage zur Akkreditierungsurkunde D-PL-19015-01-00 nach DIN EN ISO/IEC 17025:2005

Anlage zur Akkreditierungsurkunde D-PL-19015-01-00 nach DIN EN ISO/IEC 17025:2005 Deutsche Akkreditierungsstelle GmbH Anlage zur Akkreditierungsurkunde D-PL-19015-01-00 nach DIN EN ISO/IEC 17025:2005 Gültigkeitsdauer: 15.12.2014 bis 14.12.2019 Ausstellungsdatum: 15.12.2014 Urkundeninhaber:

Mehr

Normerfüllung in der Praxis am Beispiel "Tool Qualification" Dr. Anne Kramer, sepp.med gmbh

Normerfüllung in der Praxis am Beispiel Tool Qualification Dr. Anne Kramer, sepp.med gmbh Normerfüllung in der Praxis am Beispiel "Tool Qualification" Dr. Anne Kramer, sepp.med gmbh Über uns Mittelständischer IT-Service Provider 30 Jahre Industrieerfahrung Unsere Referenzen Medizintechnik Pharma

Mehr

Software, Services & Success

Software, Services & Success Unser Team sucht für den Standort Stuttgart einen Diplomand Softwareentwicklung (m/w) Thema: Regelbasierte Messdatenauswertung Im Verlauf der Entwicklung und der Integration von neuen Automotive-Steuergeräten

Mehr

Das Common Information Model (CIM) Dr.-Ing. Mathias Uslar

Das Common Information Model (CIM) Dr.-Ing. Mathias Uslar Das Common Information Model (CIM) Dr.-Ing. Mathias Uslar Vision: Smart Grid 2 Wirtschaftlicher Impact: OFFIS und das IT Quartier 101 National Institute for Standards and Technology (USA): The term Smart

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

Mehr

Die neuen Cloud-Zertifizierungen nach ISO 27018 und ISO 20000-9. DI Herfried Geyer Fachhochschule St. Pölten, CIS-Auditor

Die neuen Cloud-Zertifizierungen nach ISO 27018 und ISO 20000-9. DI Herfried Geyer Fachhochschule St. Pölten, CIS-Auditor Die neuen Cloud-Zertifizierungen nach ISO 27018 und ISO 20000-9 DI Herfried Geyer Fachhochschule St. Pölten, CIS-Auditor ISO/IEC 27013 Information technology - Security techniques - Guidance on the integrated

Mehr

OSEK/VDX NM (Network Management)

OSEK/VDX NM (Network Management) OSEK/VDX NM (Network Management) Alexander Berger alexander.berger@uni-dortmund.de PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Motivation Aufgaben des NM Architektur Konzept und Verhalten Indirektes

Mehr

Electronics. Automotive MTZ. Sonderdruck der Vector Informatik GmbH Auf solider Basis. Effiziente Entwicklung von Diagnosefunktionen im Automobil

Electronics. Automotive MTZ. Sonderdruck der Vector Informatik GmbH Auf solider Basis. Effiziente Entwicklung von Diagnosefunktionen im Automobil Automotive Electronics September 2005 58922 Sonderdruck der Vector Informatik GmbH Auf solider Basis Effiziente Entwicklung von Diagnosefunktionen im Automobil ATZ MTZ AUTOMOTIVE ENGINEERING PARTNERS ENTWICKLUNGSWERKZEUGE

Mehr

Seminar: IT-Sicherheit in eingebetteten, automotiven Systemen

Seminar: IT-Sicherheit in eingebetteten, automotiven Systemen Seminar: IT-Sicherheit in eingebetteten, automotiven Systemen Christoph Krauß, Frederic Stumpf {christoph.krauss frederic.stumpf}@sit.fraunhofer.de Fraunhofer-Institute for Secure Information Technology

Mehr

EG-Zertifikat. wurde das Teilsystem (genauer beschrieben im Anhang) the following subsystem (as detailed in the attached annex)

EG-Zertifikat. wurde das Teilsystem (genauer beschrieben im Anhang) the following subsystem (as detailed in the attached annex) _. _ NOTIFIED BODY INTEROPERABILITY EG-Zertifikat EC Certificate EG-Baumusterprufbescheinigung EC Type Examination Certificate Zertifikat-Nummer/ certificate Number: 0893/1/SB/12/RST/DE EN/2201 GemaR,

Mehr

Requirements Dokumentation Seminar- Requirements Engineering. Manoj Samtani Oliver Frank

Requirements Dokumentation Seminar- Requirements Engineering. Manoj Samtani Oliver Frank Requirements Dokumentation Seminar- Requirements Engineering Manoj Samtani Oliver Frank 24.07.2007 TU Berlin SS 2007 Inhaltsübersicht Ziel des Dokumentierens Dokumentation vs. Spezifikation Qualitätskriterien

Mehr

Multicast Security Group Key Management Architecture (MSEC GKMArch)

Multicast Security Group Key Management Architecture (MSEC GKMArch) Multicast Security Group Key Management Architecture (MSEC GKMArch) draft-ietf-msec-gkmarch-07.txt Internet Security Tobias Engelbrecht Einführung Bei diversen Internetanwendungen, wie zum Beispiel Telefonkonferenzen

Mehr

Konzept / Architektur Diagramme

Konzept / Architektur Diagramme Architektur-Modell Konzept / Architektur Diagramme Im Übergang Analyse Design wird das System konzipiert und seine Architektur entworfen: Subsystem-Modell (execution view) UML 1.x Package Diagram «subsystem»

Mehr

Release-Info. FILAKS.PLUS Release 4.5.0. Anhang DAF ecommerce

Release-Info. FILAKS.PLUS Release 4.5.0. Anhang DAF ecommerce Release-Info FILAKS.PLUS Release 4.5.0 Anhang DAF ecommerce Inhaltsübersicht 1 Allgemein 3 2 DAF ecommerce 4 2.1 Artikelabfrage 6 2.2 Warenkorb an FILAKS.PLUS übertragen 7 2.3 Neuer Auftrag in FILAKS.PLUS

Mehr

Referent: Mathias Notheis Kontakt: Mathias.Notheis@dqs.de

Referent: Mathias Notheis Kontakt: Mathias.Notheis@dqs.de ISO/IEC 62304 Medizingeräte-Software Referent: Mathias Notheis Kontakt: Mathias.Notheis@dqs.de DQS Medizin nprodukte GmbH Übersicht Basics Wann ist ein MP Software? Markteinführung vor der 62304 alles

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Cloud Computing Potenziale für die öffentliche Verwaltung führungskräfte forum im HHI, Berlin

Cloud Computing Potenziale für die öffentliche Verwaltung führungskräfte forum im HHI, Berlin Cloud Computing Potenziale für die öffentliche Verwaltung führungskräfte forum im HHI, Berlin Dr. Klaus-Peter Eckert, Dr. Peter Deussen Fraunhofer FOKUS - Berlin 18.10.2011 Agenda Technische Voraussetzungen

Mehr

Benutzerleitfaden für DS350E. Dangerfield Oct. 2007V1 Delphi PSS

Benutzerleitfaden für DS350E. Dangerfield Oct. 2007V1 Delphi PSS Benutzerleitfaden für DS350E 1 INHALT Hauptkomponenten.....3 Hauptmenü... 13 Diagnoseprogramm....34 Geräteschlüssel 43 Firmware aktualisieren...46 OBD-Kommunikation... 48 Fehlercodes auslesen und löschen

Mehr

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa Dr. Stefan Pietschmann, PF Service-Oriented Enterprise Applications, T-Systems MMS Dresden, 22.10.2013 About US PF42 Service-oriented enterprise

Mehr