Dieser Artikel ist im Entstehen und noch nicht Bestandteil der freien Enzyklopädie Wikipedia.

Solltest du über eine Suchmaschine darauf gestoßen sein, bedenke, dass der Text noch unvollständig sein und Fehler oder ungeprüfte Aussagen enthalten kann. Wenn du Fragen zu dem Thema hast, nimm am besten Kontakt mit dem Autor auf.


Historie des ASAM e.V.

Bearbeiten

Der ASAM e.V. (Association for Standardisation of Automation- and Measuring Systems) ist aus einer Initiative von 33 deutschen Fahrzeugherstellern und Zulieferern entstanden. Da im Bereich der Fahrzeugelektronik viele inkompatible und proprietäre Systeme im gesamten Herstellungsprozess von Fahrzeugen und im Fahrzeug selbst eingesetzt wurden und somit hohe Kosten und auch Abhängigkeiten entstanden waren, bot sich nur die Standardisierung als Lösung an. Vor der ASAM-Initiative existierten keine firmenübergreifenden Standards. Daher war es notwendig, für Fahrzeugkomponenten und -systeme Standards zu entwickeln, die einheitliche Schnittstellen spezifizieren und modular aufgebaut sind. Eine weitere zentrale Aufgabenstellung des ASAM e.V. ist es, diese Standards zu internationalen Normen zu entwickeln. ASAM e.V. spezifiziert weder die eingesetzten Werkzeuge noch die zugrunde liegenden Prozesse, da diese nicht vorgeschrieben werden sollen. Vorhandene Prozessprobleme können also durch ASAM Normen nicht gelöst werden, aber eine Neugestaltung vorhandener Prozesse kann durch die Anwendung von ASAM Normen effizient unterstützt werden. Die Arbeitsgruppe ASAM MCD (Measurement, Calibration and Diagnosis) ist für die Diagnose von Fahrzeugsystemen von großer Bedeutung und hat als Zielsetzung:

Die Bereitstellung von kompatiblen und austauschbaren
  • Daten,
  • Werkzeugen und
  • Methoden

für jede Phase der Steuergeräte-Entwicklung.

Dadurch werden Datenmanagement, Testsystem-Automatisierung, Messdaten-Auswertung, Simulation und die Entwicklung von Steuergeräten umfassend unterstützt. Dieser Arbeitskreis wird zukünftig als ASAM AE (Automotive Electronics) geführt.

Der ASAM MCD hat eine MCD-Systemarchitektur definiert, die im folgenden Abschnitt näher betrachtet wird.

Das ASAM MCD-System

Bearbeiten

Das unten abgebildete System wird als MCD-System bezeichnet. Die drei Funktionsgruppen Measurement (Messen - M), Calibration (Kalibrieren - C) und Diagnosis (Diagnose - D) des Standards folgen derselben Architektur eines MCD-Systems. Ziel ist es, die drei Funktionsgruppen als eigenständige Teilsysteme verwenden zu können. Die Funktionsgruppen können allerdings auch über standardisierte Schnittstellen kombiniert werden. Ein reales technisches System kann je nach Anwendung eine oder mehrere dieser Funktionsgruppen implementieren. Beispielsweise können bei Kalibriersystemen die Funktionsgruppen M,C und D, bei Testsystemen die Funktionsgruppen M und D und bei Servicetestern in der Werkstatt nur die Funktionsgruppe D zum Einsatz kommen. Ein MCD-System besteht aus den drei Komponenten

  • Laufzeitsystem,
  • Datenbeschreibung und
  • Interface-Hardware

Die Anwendung setzt auf dem MCD-System auf.

Datei:Diagnosekommunikation 2005 04 17 stm 36.jpg
ASAM_MCD_Systemarchitektur3

Das MCD-System zeichnet sich durch das zentrale Laufzeitsystem (Communication Server - COS) aus, das drei ASAM MCD-Schnittstellen bereitstellt und bedient. Die Schnittstellen und ihre ASAM Bezeichnung sind:

Schnittstelle für Standard
Programmierung von Anwendungen ASAM MCD-3
Beschreibung von Daten ASAM MCD-2
Kommunikationsprotokolle und gerätespezifische Schnittstellen für Steuergeräte ASAM MCD-1

Außerhalb des MCD-Systems - auf der anderen Seite dieser Schnittstellen - befinden sich die Applikation zum Messen, zum Kalibrieren und/oder zur Diagnose von Fahrzeugsystemen, die Steuergeräte und ein Editor für die Befüllung des Systems mit Daten. Die drei Schnittstellen des ASAM MCD-Standards werden noch feiner nach den drei Funktionsgruppen M, C und D untergliedert.

Die Standards der Funktionsgruppen Messen und Kalibrieren

Bearbeiten

Häufig werden die Funktionsgruppen Messen und Kalibrieren zusammengefasst, da sich die Aufgabenstellungen gleichen und somit die benötigten Daten und anderen Hilfsmittel gleichartig gestaltet werden können. Die für diese beiden Funktionsgruppen relevanten ASAM Standards werden nun kurz zusammengefasst:

CCP (CAN Calibration Protocol) beschreibt ein Kommunikationsprotokoll für den Datenaustausch mit Steuergeräten sowie den Blocktransfer von Speicherbereichen. ASAM MCD-1MC (Interface Specification) beschreibt einen Schnittstellentreiber zum Anbinden von ECU-Interfaces über Kommunikationsprotokolle oder gerätespezifische Schnittstellen (z. B. ROM-Emulatoren) s. a. Kapitel Bussysteme). ASAM MCD-2MC (Standardized Description Data) beschreibt Aufbau und Inhalt von Steuergerätebeschreibungsdateien für die Funktionsgruppen messwert- und kalibrierdatenbezogen. Zusätzlich werden die interface-spezifischen Daten beschrieben. ASAM MCD-3MC (Automation/Optimisation and ECU Calibration System Interface, "Serial" Version) beschreibt den Zugriff von Anwendungen auf die Funktionsgruppen Measurement und Calibration von MCD-Systemen. (weitere Details http://www.asam.net)

Die Funktionsgruppe Diagnose des ASAM

Bearbeiten

Unterstützt ein ASAM MCD-System nur die Funktionsgruppe Diagnose des ASAM MCD-Standards, wird das System auch D-System genannt. Zur Beschreibung der Schnittstellen eines D-Systems werden folgende Teil-Standards bereitgestellt:

Schnittstelle für Standard
Entwicklung von Diagnoseanwendungen ASAM MCD-3D
Beschreibung von Diagnosedaten ASAM MCD-2D
Anwendung von Diagnosebussystemen und -protokolle für Steuergeräte entfällt

Für die Diagnose existieren keine ASAM Standards an der Schnittstelle zu den Bussystemen, da bereits existierende Standards (wie ISO 14230 und ISO 15765) diese Schnittstelle in ausreichender Weise für unterschiedliche Bussysteme spezifizieren.

In ASAM MCD-2D werden die Datenaustauschprozesse und die Definition der Diagnosedaten beschrieben. Die Schnittstelle zu den Diagnoseanwendungen wird in ASAM MCD-3D definiert.

Die Software-Prozessoren des D-Systems

Bearbeiten

Innerhalb des Laufzeitsystems (COS) wird die Diagnose von vier Komponenten abgearbeitet, die Prozessoren genannt werden. Diese Prozessoren sind Software-Komponenten und besitzen jeweils eine spezielle Aufgabe bei der Durchführung von Diagnoseaufgaben und Diagnosekommunikation.

  • Der Kommunikations-Prozessor
sorgt für die Umsetzung zwischen Rohdaten (Hexadezimale Protocol Data Units) und den Bussystemen bzw. der Busphysik. Er ist somit verantwortlich für das Senden von Diagnoseanfragen zum Steuergerät und das Empfangen der Diagnoseantworten vom Steuergerät.
  • Der Diagnosedaten-Prozessor
ist verantwortlich, die Konvertierung zwischen Rohdaten (PDUs) und symbolischer Darstellung der Diagnoseanfragen und -Antworten vorzunehmen. Die Rohdaten bekommt der Prozessor von dem Kommunikationsprozessor oder liefert er an Denselben. Er stellt somit Parameter und Ergebnisse in physikalischer Darstellung bereit und greift dazu auf die ASAM MCD-2D (ODX) Datenbeschreibung zu. In die andere Richtung liefert der Diagnosedaten-Prozessor symbolische Daten an die Applikation oder die Jobs.
  • Der Job-Prozessor
bietet die Möglichkeit komplexe Diagnoseabläufe, die in Java beschrieben sind, zu interpretieren und auszuführen. Dazu wird vom Job-Prozessor auf die ASAM MCD-3D Schnittstelle zugegriffen. Die Java-Jobs sind in der ODX-Datenbasis hinterlegt. Der Job-Prozessor kann auch auf die anderen Prozessoren zugreifen.
  • Der Flashdaten-Prozessor
ist eine Erweiterung des Job-Prozessors, der spezielle Abläufe - für in Java spezifizierte Flash-Sessions nach ODX - ausgeführt. Er dient damit zum Transport von Programmen und Daten in den Speicher der Steuergeräte. Diese Flash-Daten sind Bestandteil der ODX-Datenbeschreibung.
Datei:Diagnosekommunikation 2005 04 17 stm 37.jpg

Besonders zu beachten ist, dass ASAM eine Laufzeitdatenbank vorgesehen hat. Diese Datenbank ist in dem internen Laufzeitdatenformat des jeweiligen D-Systems verfügbar. Sie bietet über die ASAM MCD-2D Daten hinaus Möglichkeiten zur Performancesteigerung, da dieses Format laufzeitoptimiert sein darf und somit keiner strengen XML-Syntax und -Semantik unterliegt, Diese Datenbank muss also zur Laufzeit nicht im XML-Quelltextformat verhältnismäßig langsam „geparst“ werden.