Vollständigen Artikel als PDF herunterladen - All

MESSTECHNIK
ASAM-Schnittstellen
Ein Überblick
ASAM (Association for Standardisation of Automation and
Measurement Systems) definiert Schnittstellen für Anwendungen im Versuch, in der Auswertung und Simulation und
hilft damit allen, die Anwendungssoftware erstellen, Treibersoftware für Meßgeräte implementieren, Anwendungen und Peripheriegeräte integrieren oder komplexe Systeme anwenden und betreiben.
Durch die übergreifende Zusammenarbeit
von Anwendern, Systemherstellern und
Systemintegratoren wurde eine Reihe von
Standards definiert, die Schnittstellen für verschiedenen Anwendungsgebiete festlegen
(Bild 1). Im Einzelnen liegen vor und sind in
Produkten implementiert:
e
e
ODS (Open Data Service),
MCD (Measurement, Calibration
and Diagnosis),
e GDI (Generic Device Interface),
e ACI (Automatic Calibration Interface).
Die folgenden Asam-Standards sind in Vorbereitung und definieren zusätzliche, gemeinsame Kommunikationsmethoden zwischen
Anwendungen und deren Softwarekomponenten:
e
CEA (Components for Evaluation
and Analysis),
CCC (Component
Communication and
Co-ordination),
e ULI (Upper Level
Interfaces).
e
Bild 1: ASAM definiert Schnittstellen mit denen komplexe
Systeme in überschaubare Module gegliedert werden
Mit Kooperationspartnern entstehen zur Zeit
Prüfmethoden, mit de-ren Hilfe die Konformität von Implementierungen mit den Standards kontrolliert werden wird. Die Verwendung des Begriffs ASAM-Konformität von
Anwendungen setzt dann eine erfolgreiche
Zertifizierung voraus.
Im Dezember 1998 wurde die Nachfolgeorganisation für die in Arbeitsgruppen organisierte Initiative gegründet. Dem Asam e.V.
sind bereits bei der Gründungsveranstaltung
33 Firmen beigetreten. Der Verein als Rechtskörper übernimmt die Vertretung der Stan-
dards und steuert deren Weiterentwicklung.
Nachfolgend ein detaillierter Blick in die einzelnen Standards.
ODS (Open Data Service)
Zahlreiche Versuchs- und Simulationssysteme
in der Industrie haben ihre proprietären Formate zum Speichern ihrer Ergebnisse. Diese
Formate unterscheiden sich in der Beschreibung des Prüflings und der Prüfung sowie in
der Weise, in der die Prüfergebnisse in einer
Datenbank oder in Dateien gespeichert werden. Zur Überwindung der sich daraus ergebenden Probleme arbeitet Asam-ODS an:
e
Bild 2: Überblick über die Asam-MCD-Schnittstellen
90
http://www.elektronik-industrie.de
Einer Definition einer Schnittstelle (Application Programmer‘s Interface API) zur Bereitstellung eines standardisierten Zugriffs auf
gespeicherte Daten von Prüfsystemen für
Asam-kompatible Systeme und Werkzeuge.
e Einer Definition eines gemeinsamen grundlegenden Datenmodells für die unzweideutige und vollständige Speicherung aller
Daten in der Versuchs- und Simulationsumgebung. Diese grundlegende Struktur baut
auf einer Reihe von Regeln und Beziehungen auf, ist an individuelle Anforderungen
der verschiedenen Projekte und Systeme
anpaßbar und deckt die Erfordernisse vieler
Implementierungen ab.
e Methoden zur Erzeugung von selbsterklärenden Datenstrukturen innerhalb einer
Datenbank, wobei das Konzept zur Beschreibung der verschiedenen Strukturen
mit Metainformationen es ermöglicht,
elektronik industrie 9 – 1999
MESSTECHNIK
Werkzeuge herzustellen, die bei verschiedenen Asam-ODS-Datenspeichern eingesetzt werden können.
e Einer Definition eines standardisierten,
leicht benutzbaren Austauschformats (Asam
Transport Format ATF) für die Übertragung
von Asam-ODS-Daten, einschließlich der entsprechenden Metainformationen.
Asam-ODS beruht gegenwärtig auf ausgereiften Spezifikationen der Asam-ODS-Schnittstellen, Verfahren und Datenmodellen (Express-G), die vom Asam-Web-Server heruntergeladen werden können. Mehrere lmplementierungen (Asam-ODS-Server, API-Implementierung, Browser und verschiedene
Werkzeuge), die auf diesen Spezifikationen
Model indentifiziert drei Schnittstellen und die
drei Funktionsgruppen Messen, Kalibrieren
und Diagnose:
Wiederverwendung bereits vorhandener
Daten in einer Asam-Umgebung ermöglichen
(z.B. für Kalibrierwerkzeuge).
e Asam-MCD/1
standardisiert ECU-Kommunikationsprotokolle mit dem Applikationssystem. Für Kalibriersysteme (Abgleich und
Optimierung) wurde ein CAN-Kalibrierungsprotokoll (CCP) spezifiziert.
e Asam-MCD/2 spezifiziert den Zugriff auf
Steuergerätebeschreibungsdaten und deren
Repräsentation.
e Asam-MCD/3 dient als Anwendungsschnittstelle zwischen Applikationssystem und
Automatisierungssystem und kommt unter
Anwendung der Asam-GDI-Methoden zum
Einsatz.
GDI (Generic Device Interface)
Der Asam-GDI arbeitet an einer standardisierten Anbindung von Geräten an Rechnersysteme und einer einheitlichen Ankopplung
von Anwendungen. Er betreibt keine Normung des physikalischen Übertragungsmediums und der Protokollschicht, sondern trifft
Festlegungen zur Präsentation von Geräten
und deren Anbindung über eine Anwendungsschnittstelle. Im Rahmen seiner Arbeiten hat der Asam-GDI zwei Schnittstellen zur
Spezifikation definiert:
e
Anwendungsneutrale Schnittstelle (Upper
Level Interface). Über diese Schnittstelle ist
es möglich, unterschiedliche Anwendungen auf einem Meß- und Automatisierungssystem auszutauschen, bzw. ohne
gerätespezifische Kenntnisse auf Geräteinformationen zuzugreifen.
e Geräteneutrale Schnittstelle (Lower-API).
Diese Schnittstelle ermöglicht den Austausch oder die Integration von Geräten in
einem Gesamtsystem.
Bild 3: Auf Basis der von Asam-CCC geschaffenen Definitionen werden sukzessive die
Asam-Standards und -Implementierungen auf eine gemeinsame Basis gehoben
beruhen, sind bei verschiedenen Lieferanten
erhältlich und bei Projekten der Automobilindustrie im Einsatz. Die Integration der CorbaTechnologie gemäß den Ergebnissen von
Asam-CCC ist im Gange und wird 1999 zu
einer neuen Version der Schnittstellenspezifikation führen.
Schwerpunkte der weiteren Arbeit wird die
Entwicklung und Festigung der in Asam-ODS
definierten Standards sein. Hierzu gehören
auch die Beobachtung und Prüfung neuer
Technologien und Quasi-Standards, wie zum
Beispiel XML (extensible Markup Language)
für den Datenaustausch und LDAP (Lightwatch Directory Access Protocol) für die
Benutzererkennung und -Autorisierung in
weiteren Rechnerumfeldern.
MCD (Measurement, Calibration
and Diagnosis)
Asam-MCD definiert Schnittstellen zwischen
Subsystemen für Meßdatenerfassung, Kalibration und Diagnose mit Steuergeräten und einer
übergeordneten Anwendung (Bild 2). Das
elektronik industrie 9 – 1999
Der Schutz vor unbefugter Benutzung der
Steuergerätedaten wird durch Asam-MCD/2
sichergestellt. Die objektorienteierte Da-tenbeschreibung bei Asam-MCD/2 wird durch Verwendung von SGML/XML gewährleistet.
Asam-MCD/3 liefert eine funktionale Systemschnittstelle, die einem Rechner- oder Automatisierungsystem einen einheitlichen Zugriff auf
das Applikationssystem ermöglicht. Konformität mit den Asam-Spezifikationen ermöglicht die parallele Nutzung bestehender und
neuer Applikationssysteme. Für die Meß- und
Kalibrierumgebung (z.B. Motorkalibrierung)
wird eine serielle Verbindung als Schnittstelle
zwischen Kalibriersystem und Automatisierungssystem des Prüfstands spezifiziert.
Auf der Grundlage der bestehenden AsamMCD-Spezifikationen wurden in den vergangenen Jahren eine große Anzahl von Systemen
installiert. Die Spezifikationen sollen mit den
Besonderheiten neuer Fertigungs- oder Service-Konzepte Schritt halten, ohne die bisherigen Festlegungen zu verändern. So wird z.B.
ein Konzept für die Flash-Programmierung aufgenommen. Migrationswege werden auch die
GDI orientiert sich an der Standardisierung
der Kommunikation innerhalb der ISO und
verwendet einige Definitionen aus der Manufacturing Message Specification (MMS ISO
9506). Gewählter Ansatz: Anwendungsprogramm und Gerät müssen hinsichtlich ihrer
Aufgabe und Funktion nichts voneinander
wissen. Das Gerät wird durch einen vom
Gerätehersteller mitgelieferten Gerätetreiber
eingebunden. Dieser ist plattform- und betriebssystemunabhängig zu schreiben. Dazu
sind sämtliche Systemaufrufe durch standardisierte (an Posix angelehnte) GDI-Funktionen
zu realisieren, welche durch einen Plattformadapter umgesetzt werden. Die Verbindung
zwischen Anwendung und Gerätetreiber ist
Aufgabe eines zum Automatisierungssystem
gehörenden Koordinators, der durch eine
anwendungsneutrale und eine geräteneutrale Schnittstelle eingerahmt wird.
Um die Fähigkeiten der verschiedenen Gerätetreiber des Systems dem Anwendungsprogramm in einer einheitlichen Art und Weise
zur Verfügung zu stellen, wird eine zentrale
Verwaltungseinheit, der Koordinator, vorgesehen. Zur allgemeinen Beschreibung der
Gerätefähigkeiten dient das Gerätefunktionsmodell: Um dem Koordinator die Fähigkeiten
des Gerätes mitzuteilen, liefert der Gerätehersteller mit dem Gerätetreiber eine Beschreibung der Gerätefähigkeiten (DCD: Device
Capability Description). In dieser werden AsamGDI-Geräte sowohl in ihrer Funktion als auch
hinsichtlich ihrer gesamten Parameter-(Objekt-)Strukturen in einer neutralen Form ein- ©
http://www.elektronik-industrie.de
91
MESSTECHNIK
deutig beschrieben. Der
Asam-GDI spezifiziert
dazu die Syntax (ASCIIText) und Funktionen für
den einheitlichen Zugriff. Neben den Gerätefunktionen beinhaltet
die DCD treiberspezifische Parameter und einen Bereich für allgemeine Texte (Ausgaben,
Fehlermeldungen...).
Zu jedem Asam-GDIGerät gehört neben der
DCD der Gerätetreiber.
Um auch hier die Neutralität zu wahren und
eine Unabhängigkeit
von den verwendeten
Bild 4: Beim ULI (Upper Level Interfaces) wurden Funktionen wie
Rechnern und Betriebsz.B. Messungen, Ausgabe von Sequenzen und Einstellwerten in
systemen zu erhalten,
logische Dienste gruppiert
ist der Gerätetreiber in
ANSI-C/C++ auszuführen.
AuSy- oder ACS-Lieferant muß eine maßgeFür jede Rechnerumgebung ist ein Plattforschneiderte DLL für sein eigenes System zur
madapter zu erstellen, der die BetriebssyKommunikation mit Dienstanbieter bzw.
stemfunktionen des jeweiligen Systems nutzt
Dienst-Gateway schreiben.
und gegebenenfalls erweitert. Das FunktionsMit zunehmender Hardware-Leistung ist die
interface des Plattformadapters zu den GeräDurchführung von HIL-Echtzeitprüfungen (Hardtetreibern ist vom Asam-GDI bereits spezifiware in the Loop) unter repräsentativen, defiziert. Ist ein Plattformadapter einmal erstellt,
nierten Umgebungsbedingungen im Labor
steht er allen weiteren Gerätetreibern für diemöglich. Dies bezieht sich hauptsächlich auf
ses Betriebssystem ebenso zur Verfügung.
die Corba-Umgebung und die Sicherheit,
Derzeit wird an Asam-GDI Companion StanEchtzeitkommunikation zu erreichen und aufdards zur einheitlichen Einbindung von Gerärechtzuerhalten. Ein weiteres Arbeitsgebiet
teklassen gearbeitet, mit dem Ziel, die Ausim Zusammenhang mit ACS-Systemen ist die
tauschbarkeit von Geräten zu erleichtern. ParIntegration einer Modellierungsumgebung,
allel entstehen Werkzeuge zur Unterstützung
so daß Strategien und Antriebsstrang-Konfider Entwicklung von Gerätetreibern und
gurationen unter visuellen Bedingungen gePlattformadaptern.
prüft werden können. Das Konzept Dienstanbieter bzw. Dienst-Gateway ist modular.
ACI (Automatic Calibration Interface)
Die Schnittstelle Asam-ACI stellt eine Lösung
zum Anschluß von ACS-Systemen (Automatic
Calibration System) an Prüfstandsautomatisierungssysteme bereit. Dieser Mechanismus soll
objektorientiert sein und auf der Corba-Technologie basieren. Dienst-Gateway und Dienstanbieter fungieren jeweils zu verschiedenen
Zeiten als Client bzw. Server, je nach der
gerade ablaufenden Funktion. Sie machen
dem Anwender die Kommunikation vollständig deutlich und dienen als die Gateways zum
jeweiligen System, indem sie die verschiedenen Dienstaufrufe weiterleiten. Das ACS steuert den Prüfablauf, das Automatisierungssystem (AuSy) übernimmt die Steuerung der
lokalen Prüfstandfunktionen. Für die Entwicklung des Schnittstellenprotokolls wurden folgende Dienste definiert: Player Services,
Recorder Services, Watcher Services, Calibrator Services, Device Services. Die gesamte
Kommunikation zwischen ACS und AuSy ist in
diesen Diensten abgebildet. Der jeweilige
92
CEA (Components for
Evaluation and Analysis)
Mit den Arbeiten zu Asam-CEA wurde im
Oktober 1998 begonnen, um eine Architektur sowie Basisfunktionen für Auswertungen
aus Funktionskomponenten zu definieren.
Dabei sollen sowohl Komponenten eines Herstellers als auch Komponenten beliebiger Hersteller zu einer Applikation mit einheitlichem
Erscheinungsbild zusammengefügt werden
können.
Eine komponentenbasierte Auswertung besteht aus einem Container plus Komponenten.
Der Container bietet den Rahmen mit Grundfunktionen, wie z.B. Hilfe. Die Integration der
Komponenten erfolgt über eine offene, auf
verschiedenen Systemplattformen realisierbare
Infobus-Corba-Architektur unter Berücksichtigung der Asam-CCC-Standards. Es werden
existierende und neue Schnittstellen in gleicher
Weise in die Gesamtarchitektur eingebettet.
Hierbei erscheinen die bisherigen Asam-
http://www.elektronik-industrie.de
Schnittstellen als Datenquellen, während die
neuen Schnittstellen im wesentlichen die Verarbeitungsfunktion bereitstellen.
Die Asam-Mapper stellen die bestehenden
Asam-Objektdefinitionen am Infobus bereit,
die COM-/WEB-Mapper Entsprechendes für
Objekte außerhalb des Asam-Umfeldes. Durch
diese Sichtweise ergibt sich eine Öffnung zu
bestehenden DV-Segmenten ohne den Zwang
die Asam-Schnittstellen in voller Breite zu
unterstützen. Dies bedeutet, eine Migration
von aussen hin zu Asam ist möglich.
Bis Ende 1999 sollen die für das Releasejahr 1
notwendigen Spezifikationen sowie ein erster
lauffähiger Prototyp zur Verfügung stehen.
CCC (Component Communication
and Co-ordination)
Asam-CCC wurde 1996 als Arbeitsgruppe
gegründet und definiert auf der Grundlage
moderner Systemarchitekturen und Standards (z.B. Corba, OLE) die grundlegenden
Kommunikationsmechanismen und -verfahren, die für verteilte Software-Komponenten
in einer komplexen und heterogenen Prüfumgebung erforderlich sind. Eines der Hauptziele bestand in der Anpassung und Wiederverwendung existierender Standards (z.B.
Asam-ODS, Nutzung von Corba Services). Das
Bild 3 zeigt das Architekturmodell von AsamCCC anhand eines Konfigurationsbeispiels
einer Applikation mit mehreren SoftwareKomponenten inclusive der anderen AsamStandards. Man beachte das Paradigma: Der
Server-Teil (S) von Software-Komponenten
oder Programmen bietet Dienste, die von Client-Teilen (C) anderer Komponenten benutzt
werden. In der Abbildung sind mehrere Software-Komponenten dargestellt, die über den
CCC-Kernel verbunden sind. Der Kernel stellt
Methoden für die von CCC definierten Grundregeln zur Verfügung. Jede Software-Komponente kann andere Schnittstellen zu Subkomponenten haben. Z.B. unterstützt der
ODS-Dienst über den CCC-Kernel die ODSStandard-Schnittstelle. Die andere Schnittstelle stellt die Verbindung zu einer Datenbank her, in der die Daten gespeichert sind.
Die Buchstaben C und S in den Schnittstellen
der Komponenten zum Asam-CCC-Kernel
bedeuten, daß alle Komponenten in diesem
Modell in ihrem Lebenszyklus sowohl Client
als auch Server sein können.
Die funktionale Spezifikation wurde von
Asam-CCC auf Basis von Corba erstellt. Die
Abbildung auf COM/OLE wird über eine
Corba/OLE-Bridge ermöglicht.
Andere Standardisierungsgruppen (z.B. ODS,
ACI, ULI) haben bereits mit der Definition
ihrer Standards anhand der CCC-Regeln
begonnen. Eine erste Implementierung der
ODS-Schnittstelle ist bereits verfügbar. Es gibt
mehrere Themen (z.B. Debugging), die in
Asam-CCC bisher nicht definiert wurden.
elektronik industrie 9 – 1999
ULI (Upper Level Interfaces)
Das Ziel der ULIs besteht in der Definition von
vereinheitlichten Zugriffsverfahren auf eine
Vielfalt von bereits bestehenden Diensten
innerhalb von Automatisierungs- und Subsystemen (Bild 4). Für die Navigation, den
Zugriff und die Steuerung der definierten
Dienste wurde eine objektorientierte Vorgehensweise gewählt. Um eine klare und konsistente Definition zu gewährleisten, beruht die
Spezifikation auf einem UML-Modell (Unified
Modelling Language), das Klassen, Zusammenhänge, Beziehungen und auch Szenarien
durch Interaktionsdiagramme darstellt. Die in
diesem Modell spezifizierten Dienste können
auf Basis vorhandener monolithischer Automatisierungssysteme aufgebaut werden und
stellen so deren Fähigkeiten in einer vereinheitlichten dienstzentrierten und objektorientierten Weise dar. Die ULIs können als Erweiterung der bestehenden Asam-ACS-Norm
betrachtet werden. Die Schnittstelle selbst
wird in der IDL-Sprache nach den von AsamCCC bereitgestellten Richtlinien beschrieben.
Die IDL-Definitionsdateien werden direkt aus
dem UML-Modell heraus generiert. Weitere
Verbesserungen des Gerätedienstes (GDI) und
des Kalibrier-Dienstes (MCD) sind im Gange
und werden bald abgeschlossen sein.
(jj)
743
Bearbeitet nach Unterlagen der ASAM e.V., 80788
München, http://www.asam.de
ASAM in der Praxis
Die ASAM-Standards haben den nächsten Meilenstein auf dem Weg zu standardisierten Automatisierungs- und
Meßsystemen erreicht: In der Fachhochschule Nürnberg wird die Big Demonstrator genannte Veranstaltung vom
22.-24.9.1999 die Praxistauglichkeit
der ASAM-Standards zu beweisen. Alle
Interessenten sind herzlich eingeladen,
sich in Nürnberg an zwei Motorprüfständen von der Interoperabilität der
Komponenten unterschiedlicher Hersteller zu überzeugen. Die begleitende
Ausstellung zeigt die große Bandbreite
verfügbarer ASAM-konformer Produkte. In zwei Seminaren kann man
sich tiefer in die Materie einarbeiten.
Die Veranstaltungen sind kostenlos,
eine vorherige Anmeldung ist erforderlich.
http://www.asam.de/frame_news.htm
Tel. 0 89 - 35 65 39 -71
Fax 0 89 - 35 65 39 - 72
elektronik industrie 9 – 1999
93