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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Automotive Diagnostic Software. Benutzerhandbuch. Version 2.0. Copyright 2009 WGSoft.de. All rights reserved

Automotive Diagnostic Software. Benutzerhandbuch. Version 2.0. Copyright 2009 WGSoft.de. All rights reserved Automotive Diagnostic Software ScanMaster ELM Benutzerhandbuch Version 2.0 2009 Copyright 2009 WGSoft.de. All rights reserved Inhalt 1. Grundmerkmale... 3 2. Minimale Hard- und Software Voraussetzungen...

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

Bedienungsanleitung für DS350E mit Motion LE1700 Tablet. Dangerfield February 2009 V1.0 Delphi PSS

Bedienungsanleitung für DS350E mit Motion LE1700 Tablet. Dangerfield February 2009 V1.0 Delphi PSS Bedienungsanleitung für DS350E mit Motion LE1700 Tablet 1 INHALT Hauptkomponenten...3 Bluetooth Konfiguration... 8 Hauptmenü... 20 Diagnoseprogramm...41 EOBD-Funktionen...77 Fehlercodes löschen (EOBD)...83

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

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

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

A central repository for gridded data in the MeteoSwiss Data Warehouse

A central repository for gridded data in the MeteoSwiss Data Warehouse A central repository for gridded data in the MeteoSwiss Data Warehouse, Zürich M2: Data Rescue management, quality and homogenization September 16th, 2010 Data Coordination, MeteoSwiss 1 Agenda Short introduction

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

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

CAN-Anwendungen für die Automobilindustrie

CAN-Anwendungen für die Automobilindustrie CAN-Anwendungen für die Automobilindustrie Dipl. Ing. Roland Magolei NI Engineering Germany GmbH roland.magolei@ni.com National Instruments R&D weltweit NI R&D Denmark NI R&D Germany NI R&D Romania NI

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

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

eurex rundschreiben 094/10

eurex rundschreiben 094/10 eurex rundschreiben 094/10 Datum: Frankfurt, 21. Mai 2010 Empfänger: Alle Handelsteilnehmer der Eurex Deutschland und Eurex Zürich sowie Vendoren Autorisiert von: Jürg Spillmann Weitere Informationen zur

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

RDKS in der Zunkunft. Poing, März 2013. Johannes Kraus (Body& Security)/ Stefan Dötsch (Independent Aftermarket)

RDKS in der Zunkunft. Poing, März 2013. Johannes Kraus (Body& Security)/ Stefan Dötsch (Independent Aftermarket) RDKS in der Zunkunft Poing, März 2013 Johannes Kraus (Body& Security)/ Stefan Dötsch (Independent Aftermarket) Continental Corporation 5 starke Divisionen Chassis & Safety Powertrain Reifen ContiTech Electronic

Mehr

ISO 15504 Reference Model

ISO 15504 Reference Model Prozess Dimension von SPICE/ISO 15504 Process flow Remarks Role Documents, data, tools input, output Start Define purpose and scope Define process overview Define process details Define roles no Define

Mehr

Model-based Development of Hybrid-specific ECU Software for a Hybrid Vehicle with Compressed- Natural-Gas Engine

Model-based Development of Hybrid-specific ECU Software for a Hybrid Vehicle with Compressed- Natural-Gas Engine Model-based Development of Hybrid-specific ECU Software for a Hybrid Vehicle with Compressed- Natural-Gas Engine 5. Braunschweiger Symposium 20./21. Februar 2008 Dipl.-Ing. T. Mauk Dr. phil. nat. D. Kraft

Mehr

KURZANLEITUNG. Firmware-Upgrade: Wie geht das eigentlich?

KURZANLEITUNG. Firmware-Upgrade: Wie geht das eigentlich? KURZANLEITUNG Firmware-Upgrade: Wie geht das eigentlich? Die Firmware ist eine Software, die auf der IP-Kamera installiert ist und alle Funktionen des Gerätes steuert. Nach dem Firmware-Update stehen Ihnen

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

Sichere Identitäten in Smart Grids

Sichere Identitäten in Smart Grids Informationstag "IT-Sicherheit im Smart Grid" Berlin, 23.05.2012 Sichere Identitäten in Smart Grids Dr. Thomas Störtkuhl, Agenda 1 2 Beispiele für Kommunikationen Digitale Zertifikate: Basis für Authentifizierung

Mehr

Liste der Normen und Standardschriften am Ende der jeweiligen Kapitel

Liste der Normen und Standardschriften am Ende der jeweiligen Kapitel Literaturverzeichnis 347 Literaturverzeichnis [1] Robert Bosch GmbH (Hrsg.): Kraftfahrtechnisches Handbuch. Vieweg Verlag, 25. Auflage, 2003 [2] R. K. Jurgen (Hrsg.): Automotive Electronics Handbook. McGraw

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

Bild in der Größe 215x148 mm einfügen

Bild in der Größe 215x148 mm einfügen Mercedes-Benz Service Bild in der Größe 215x148 mm einfügen Systembeschreibung On-Board-Diagnose II (OBD II / EOBD) e r l ry h s AG Mercedes-Benz Service Systembeschreibung On-Board-Diagnose II (OBD II

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

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

Customer-specific software for autonomous driving and driver assistance (ADAS)

Customer-specific software for autonomous driving and driver assistance (ADAS) This press release is approved for publication. Press Release Chemnitz, February 6 th, 2014 Customer-specific software for autonomous driving and driver assistance (ADAS) With the new product line Baselabs

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

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

Netzwerke und Sicherheit auf mobilen Geräten

Netzwerke und Sicherheit auf mobilen Geräten Netzwerke und Sicherheit auf mobilen Geräten Univ.-Prof. Priv.-Doz. DI Dr. René Mayrhofer Antrittsvorlesung Johannes Kepler Universität Linz Repräsentationsräume 1. Stock (Uni-Center) 19.1.2015, 16:00

Mehr

CaliAV Geführte Applikation für INCA Effizienz in Applikation & Validierung

CaliAV Geführte Applikation für INCA Effizienz in Applikation & Validierung CaliAV Geführte Applikation für INCA Effizienz in Applikation & Validierung 1 Zunehmende Komplexität in der Motorapplikation Engine Management Transmission Management ~12 labels Vehicle Motion Management

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

Parameter-Updatesoftware PF-12 Plus

Parameter-Updatesoftware PF-12 Plus Parameter-Updatesoftware PF-12 Plus Mai / May 2015 Inhalt 1. Durchführung des Parameter-Updates... 2 2. Kontakt... 6 Content 1. Performance of the parameter-update... 4 2. Contact... 6 1. Durchführung

Mehr

Portalverbundprotokoll Version 2. S-Profil. Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG

Portalverbundprotokoll Version 2. S-Profil. Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG 1 Portalverbundprotokoll Version 2 S-Profil Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG Kurzbeschreibung Das S-Profil von PVP2 verwendet SAML WebSSO für die Authentifizierung von Benutzern mit Webbrowser.

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

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

CeBIT 17.03.2015. CARMAO GmbH 2014 1

CeBIT 17.03.2015. CARMAO GmbH 2014 1 CeBIT 17.03.2015 CARMAO GmbH 2014 1 HERZLICH WILLKOMMEN Applikationssicherheit beginnt lange bevor auch nur eine Zeile Code geschrieben wurde Ulrich Heun Geschäftsführender Gesellschafter der CARMAO GmbH

Mehr

This document is a preview generated by EVS

This document is a preview generated by EVS EESTI STANDARD EVS-EN 13290-6:2002 Space project management - General requirements - Part 6: Information/Documentation management Space project management - General requirements - Part 6: Information/Documentation

Mehr

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem 1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem Management, Access Management a. Event Management b. Service Desk c. Facilities Management d. Change Management e. Request Fulfilment

Mehr

TMF projects on IT infrastructure for clinical research

TMF projects on IT infrastructure for clinical research Welcome! TMF projects on IT infrastructure for clinical research R. Speer Telematikplattform für Medizinische Forschungsnetze (TMF) e.v. Berlin Telematikplattform für Medizinische Forschungsnetze (TMF)

Mehr

Technical Note 0102 Gateway

Technical Note 0102 Gateway Technical Note 0102 Gateway MBus Zähler von Kamstrup auslesen - 1 - Inhaltsverzeichnis 1 Allgemeines... 3 1.1 Information... 3 1.2 Hinweis... 3 2 Gateway konfigurieren... 4 2.1 Kommunikationseinstellungen...

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

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

SemTalk Services. SemTalk UserMeeting 29.10.2010

SemTalk Services. SemTalk UserMeeting 29.10.2010 SemTalk Services SemTalk UserMeeting 29.10.2010 Problemstellung Immer mehr Anwender nutzen SemTalk in Verbindung mit SharePoint Mehr Visio Dokumente Viele Dokumente mit jeweils wenigen Seiten, aber starker

Mehr

ESG Elektroniksystem- und Logistik-GmbH

ESG Elektroniksystem- und Logistik-GmbH ESG Elektroniksystem- und Logistik-GmbH Seit über fünfzig Jahren entwickelt, integriert und betreibt die ESG komplexe, oftmals sicherheitsrelevante Elektronik- und IT-Systeme für Unternehmen, Behörden

Mehr

I T I L. ITIL ein systematisches und professionelles Vorgehen für. das Management von IT Dienstleistungen. Andreas Henniger.

I T I L. ITIL ein systematisches und professionelles Vorgehen für. das Management von IT Dienstleistungen. Andreas Henniger. I T I L ITIL ein systematisches und professionelles Vorgehen für das Management von IT Dienstleistungen. 1 ITIL Was ist ITIL? ITIL wurde von der Central Computing and Telecommunications Agency (CCTA) entwickelt,

Mehr

Product Lifecycle Manager

Product Lifecycle Manager Product Lifecycle Manager ATLAS9000 GmbH Landauer Str. - 1 D-68766 Hockenheim +49(0)6205 / 202730 Product Lifecycle Management ATLAS PLM is powerful, economical and based on standard technologies. Directory

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

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08 Security Patterns Benny Clauss Sicherheit in der Softwareentwicklung WS 07/08 Gliederung Pattern Was ist das? Warum Security Pattern? Security Pattern Aufbau Security Pattern Alternative Beispiel Patternsysteme

Mehr

Offene Standards und Open Source Software für pan europäische egovernment Dienstleistungen

Offene Standards und Open Source Software für pan europäische egovernment Dienstleistungen CEBIT 2005 Hannover, 15. März 2005 Offene Standards und Open Source Software für pan europäische egovernment Dienstleistungen Dr. Barbara Held IDABC, Enterprise and Industry Directorate General, European

Mehr

Themen für Abschlussarbeiten/Praktika im Bereich FlexRay

Themen für Abschlussarbeiten/Praktika im Bereich FlexRay Kopfarbeit mit Spaßfaktor Kopfarbeit mit Spaßfaktor Von A3 bis Z4 wir sind marktführend in der Entwicklung von Softwarewerkzeugen und komponenten für die Vernetzung von Steuergeräten in Fahrzeugen. Über

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

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management Anforderungsmanagement im Projekt BIS-BY von B. KREUZER Schlüsselwörter: Änderungswünsche, Anforderungsmanagement, DOORS Kurzfassung Softwaresysteme unterliegen während ihrer Entwicklung und während ihres

Mehr

Ausarbeitung zum Vortrag Java Web Start von Adrian Fülöp Fach: Komponentenbasierte Softwareentwicklung WS 06/07 Fachhochschule Osnabrück

Ausarbeitung zum Vortrag Java Web Start von Adrian Fülöp Fach: Komponentenbasierte Softwareentwicklung WS 06/07 Fachhochschule Osnabrück Ausarbeitung zum Vortrag Java Web Start von Adrian Fülöp Fach: Komponentenbasierte Softwareentwicklung WS 06/07 Fachhochschule Osnabrück Adrian Fülöp (297545) - 1 - Inhaltsverzeichnis: 1. Einführung 2.

Mehr

Connected Machines. Wie und warum Maschinen vernetzt werden

Connected Machines. Wie und warum Maschinen vernetzt werden Connected Machines Wie und warum Maschinen vernetzt werden ServTec Austria 4.0 20. März 2014, Graz Michael Sinnl Friedrich Nachtmann GIGATRONIK Austria GmbH Internet der (Dinge) Maschinen Evolution Informations-

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Automatisierungsarchitekturen für das Smart Grid Am Beispiel der OPC UA und der IEC 61970. Dr.-Ing. Mathias Uslar, Sebastian Rohjans

Automatisierungsarchitekturen für das Smart Grid Am Beispiel der OPC UA und der IEC 61970. Dr.-Ing. Mathias Uslar, Sebastian Rohjans Automatisierungsarchitekturen für das Smart Grid Am Beispiel der OPC UA und der IEC 61970 Dr.-Ing. Mathias Uslar, Sebastian Rohjans 2 OPC Foundation Vision: OPC-Technologien sollen überall dort zur Interoperabilitäts-Basis

Mehr

Einsatz einer Dokumentenverwaltungslösung zur Optimierung der unternehmensübergreifenden Kommunikation

Einsatz einer Dokumentenverwaltungslösung zur Optimierung der unternehmensübergreifenden Kommunikation Einsatz einer Dokumentenverwaltungslösung zur Optimierung der unternehmensübergreifenden Kommunikation Eine Betrachtung im Kontext der Ausgliederung von Chrysler Daniel Rheinbay Abstract Betriebliche Informationssysteme

Mehr

Instruktionen Mozilla Thunderbird Seite 1

Instruktionen Mozilla Thunderbird Seite 1 Instruktionen Mozilla Thunderbird Seite 1 Instruktionen Mozilla Thunderbird Dieses Handbuch wird für Benutzer geschrieben, die bereits ein E-Mail-Konto zusammenbauen lassen im Mozilla Thunderbird und wird

Mehr

Gegenüberstellung und Anwendung verschiedener Testverfahren zur Sicherstellung der Interoperabilität von Netzelementen in Next Generation Networks

Gegenüberstellung und Anwendung verschiedener Testverfahren zur Sicherstellung der Interoperabilität von Netzelementen in Next Generation Networks ITG-Fachtagung Mobilkommunikation 2009 Gegenüberstellung und Anwendung verschiedener Testverfahren zur Sicherstellung der Interoperabilität von Netzelementen in Next Generation Networks Matthias Bormann

Mehr

Agenda.! Die Cloud-Strategie der Europäischen Kommission.! Themen und Arbeitsgruppen! Die Rolle von EuroCloud! Gestaltungsmöglichkeiten

Agenda.! Die Cloud-Strategie der Europäischen Kommission.! Themen und Arbeitsgruppen! Die Rolle von EuroCloud! Gestaltungsmöglichkeiten Agenda! Die Cloud-Strategie der Europäischen Kommission! Themen und Arbeitsgruppen! Die Rolle von EuroCloud! Gestaltungsmöglichkeiten Europa The EU Cloud computing strategy includes three key actions regarding:

Mehr

Sprint 1 -> 2 Bridge (20150108)

Sprint 1 -> 2 Bridge (20150108) Sprint 1 WK49-WK50 Prerequisites: MDM4 API documentation MDM4 business object model Eclipse tooling definitions (maven as build) Common Goals: Define MDM API as a valid component and its position MDM API

Mehr

Hochverfügbares Ethernet MRP - Media Redundancy Protocol

Hochverfügbares Ethernet MRP - Media Redundancy Protocol Hochverfügbares Ethernet MRP - Media Redundancy Protocol Hirschmann Automation and Control GmbH Dipl.- Ing. Dirk Mohl 1 25.01.07 - ITG Automation Übersicht Netzwerke und Redundanztypen Rapid Spanning Tree

Mehr

Ingest von Fachverfahren. Werkzeuge des Landesarchivs Baden-Württemberg

Ingest von Fachverfahren. Werkzeuge des Landesarchivs Baden-Württemberg Ingest von Fachverfahren. Werkzeuge des Landesarchivs Baden-Württemberg 13. Tagung des AK Archivierung von Unterlagen aus digitalen Systemen 27.4.2009, St. Gallen Dr. Christian Keitel und Rolf Lang Übersicht

Mehr

Fred Stay 2013-06-04/05. Management der Funktionalen Sicherheit KROHNE Academy Automatisierungstechnik in der Prozessindustrie

Fred Stay 2013-06-04/05. Management der Funktionalen Sicherheit KROHNE Academy Automatisierungstechnik in der Prozessindustrie Fred Stay 2013-06-04/05 Management der Funktionalen Sicherheit KROHNE Academy Automatisierungstechnik in der Prozessindustrie 1. Warum brauchen wir ein FSM 2. Vermeidung/Beherrschung von Fehlern 3. Praxisbeispiel:

Mehr

Verzeichnis. 1.Sicherheitshinweise und Warnungen... 2

Verzeichnis. 1.Sicherheitshinweise und Warnungen... 2 Verzeichnis 1.Sicherheitshinweise und Warnungen... 2 2. Allgemeine InformationenFehler! Textmarke nicht definiert. 2.1 On-Board Diagnose (OBD) II... 3 2.2 Diagnose Fehlercode (DTCs)... 3 2.3 Lage des Datenübertragungssteckers

Mehr

Schnittstelle SAP. - Schnittstelle SAP

Schnittstelle SAP. - Schnittstelle SAP Schnittstelle SAP - Schnittstelle SAP K3V 3.0 Energiewirtschaft als technische Ergänzung zu SAP als führendes ERP-System K3V 3.0 kann problemlos mit einem ERP-System wie z.b. SAP zusammenarbeiten, auch

Mehr

1KONFIGURATION VON ACCESS LISTEN UND FILTERN

1KONFIGURATION VON ACCESS LISTEN UND FILTERN 1KONFIGURATION VON ACCESS LISTEN UND FILTERN Copyright 23. Juni 2005 Funkwerk Enterprise Communications GmbH Bintec Workshop Version 0.9 Ziel und Zweck Haftung Marken Copyright Richtlinien und Normen Wie

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

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

Cleanroom Fog Generators Volcano VP 12 + VP 18

Cleanroom Fog Generators Volcano VP 12 + VP 18 Cleanroom Fog Generators Volcano VP 12 + VP 18 Description & Functional Principle (Piezo Technology) Cleanrooms are dynamic systems. People and goods are constantly in motion. Further installations, production

Mehr

selbst verständlich certainly

selbst verständlich certainly selbst verständlich certainly Messe Gastronomie, Hannover selbst verständlich Selbstverständlich ist in der Gastronomie ein geflügeltes Wort. Das Kassensystem Matrix POS ist intuitiv in der Bedienung und

Mehr

Anleitung zum Verbinden des ecoroute HD 1xxx/2xxx/3xxx

Anleitung zum Verbinden des ecoroute HD 1xxx/2xxx/3xxx Anleitung zum Verbinden des ecoroute HD 1xxx/2xxx/3xxx ecoroute HD ist die intelligente Weiterentwicklung der erfolgreichen Garmin ecoroute Technologie. Es macht aus einem Garmin nüvi ein Fahrzeug-Diagnose

Mehr

Extract of the Annotations used for Econ 5080 at the University of Utah, with study questions, akmk.pdf.

Extract of the Annotations used for Econ 5080 at the University of Utah, with study questions, akmk.pdf. 1 The zip archives available at http://www.econ.utah.edu/ ~ ehrbar/l2co.zip or http: //marx.econ.utah.edu/das-kapital/ec5080.zip compiled August 26, 2010 have the following content. (they differ in their

Mehr

Lehrstuhl für Allgemeine BWL Strategisches und Internationales Management Prof. Dr. Mike Geppert Carl-Zeiß-Str. 3 07743 Jena

Lehrstuhl für Allgemeine BWL Strategisches und Internationales Management Prof. Dr. Mike Geppert Carl-Zeiß-Str. 3 07743 Jena Lehrstuhl für Allgemeine BWL Strategisches und Internationales Management Prof. Dr. Mike Geppert Carl-Zeiß-Str. 3 07743 Jena http://www.im.uni-jena.de Contents I. Learning Objectives II. III. IV. Recap

Mehr

Lebendige Sicherheit: Entwicklung von Secure Software im dynamischen Umfeld

Lebendige Sicherheit: Entwicklung von Secure Software im dynamischen Umfeld Lebendige Sicherheit: Entwicklung von Secure Software im dynamischen Umfeld Prof. Dr. Ruth Breu Quality Engineering Laura Bassi LaB Institut für Informatik Universität Innsbruck Quality Engineering Projekte

Mehr

p^db=`oj===pìééçêíáåñçêã~íáçå=

p^db=`oj===pìééçêíáåñçêã~íáçå= p^db=`oj===pìééçêíáåñçêã~íáçå= Error: "Could not connect to the SQL Server Instance" or "Failed to open a connection to the database." When you attempt to launch ACT! by Sage or ACT by Sage Premium for

Mehr

Requirements Engineering Übung 8 Systemmodellierung im RE

Requirements Engineering Übung 8 Systemmodellierung im RE Requirements Engineering Übung 8 modellierung im RE Dr. Birgit Penzenstadler, Dr. Daniel Méndez, Jonas Eckhardt 11. Dezember 2012 Übung 8 Aufgabe 1: Modelle als Sichten auf ein Aufgabe 2: Von Anwendungsfällen

Mehr

Agile Methoden bei der Entwicklung medizinischer Software

Agile Methoden bei der Entwicklung medizinischer Software Agile Methoden bei der Entwicklung medizinischer Software Bernhard Fischer Fischer Consulting GmbH Fischer Consulting GmbH Technologie-Forum 2008 Folie 1 Wie soll Software entwickelt werden? Fischer Consulting

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