Vollständigen Artikel als PDF herunterladen - All
Transcrição
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