Auswahl des optimalen Gerätetreibers für PXI-Hardware

Mess- und Stimulus-Hardware, Schaltsystemeinheit,Verkabelung, eventuell eine Adapterschnittstelle, Prüflingsspannungsversorgung, externer PC oder alternativ ein Embedded-Controller, sowie die Programmierumgebung sind die wesentlichen Komponenten eines typischen Testsystems. Jede Komponente wird aufgrund vorgegebener Anforderungen wie Prüfparameter, Abmessungen, Testdurchsatz und Budget ausgewählt. In dieser Liste fehlt jedoch als wichtiges Element der Gerätetreiber zur Ansteuerung der Hardware.

Pickering Interfaces

Die IVI-Foundation hat einen intelligenteren Gerätetreiberstandard definiert, den viele Hersteller von PXI-Instrumenten und Schaltlösungen zusätzlich zum obligatorischen VISA-Layer (Virtual Instrument Software Architecture) unterstützen. Für zahlreiche Awendungen bietet der IVI-Treiber Vorteile. Wie soll man also die Entscheidung treffen?

Zusätzliche Eigenschaften und Erweiterungen

Unter den meisten Betriebssystemen, einschließlich Windows, kann der Benutzer nicht direkt mit der Hardware, sondern nur über einen dafür speziell entwickelten Treiber kommunizieren. Der Kernel-Treiber bietet einen Low-Level-Hardwarezugriff im Kernel-Space und eine Schnittstelle im User-Space. Er verfügt lediglich über eine sehr rudimentäre Low-Level-Schnittstelle. Ein weiteres Modul, das Application Programming Interface (API) baut auf dem Kernel auf und stellt eine Schnittstelle bereit, die dieses spezielle Modul besser steuern kann. Komplexere APIs bauen auf der Low-Level-Ebene auf und bieten besonders zweckmäßige Schnittstellen an, um zusätzliche Eigenschaften und Erweiterungen bereitzustellen.

Ein Anwendungsprogramm kann über eine der verfügbaren APIs auf die Hardware zugreifen. Die Auswahl hängt von verschiedenen Faktoren wie Programmierumgebung, Kompatibilitätsanforderungen oder persönlichen Vorlieben ab.

Bild 1 zeigt eine typische Auswahl möglicher Alternativen, von der Low-Level-Programmierung auf Basis der Schnittstelle des Kernel-Treibers bis zu APIs höherer Ebenen, die eine zunehmend bessere Modellierung der Funktionalität der speziellen Hardware-Module bieten.

Dargestellt sind die verschiedenen Programmierebenen von APIs.Pickering Interfaces

VISA ist ein Kernel-Treiber, der die Steuerung der Hardware und das Management der Ressourcen bereitstellt. Diese Low-Level- Schnittstelle bietet nur rudimentäre I/O-Funktionalität zur Steuerung des Hardware-Moduls. Auf dieser Ebene kann die Modulsteuerung sehr komplex sein und umfassende Kenntnisse über die Hardware erfordern. Nahezu jeder Hersteller bietet eine Low-Level-API, die das spezielle Fachwissen über das Hardware-Modul abstrahiert und dadurch die Programmieraufgabe erleichtert.

Viele Hersteller stellen auch einen IVI-Treiber bereit. Dieser bietet eine Higher-Level-API, die auf dem Low-Level-Treiber aufsetzt und typischerweise der Branchen-Standardfunktionalität für den Modultyp entspricht.

Es können mehr als die oben illustrierten Ebenen beteiligt sein. In vielen Fällen gibt es einen Satz von Non-VISA-Treibern. Steht Visa, wegen Betriebssystem- oder Lizenzeinschränkungen nicht zur Verfügung, ist dies sehr hilfreich. VISA liegt beispielsweise nur bei einer beschränkten Anzahl von Linux-Distributionen vor, sodass der Anwender gezwungen ist, auf eine alternative Kernel-Schnittstelle zuzugreifen.

Auf Austauschbarkeit ausgelegt

Der PXI-Standard fordert einen VISA-Schnittstellentreiber. Viele PXI-Module sind jedoch mit einer Vielzahl verschiedenster Treiber ausgestattet, sodass der Anwender den Treiber auswählen muss, der am besten zu seiner Applikation passt. Zunehmend stehen IVI-Treiber zur Verfügung. Ausgelegt ist dieser Treiber-Standard speziell auf Austauschbarkeit und er ist für bestimmte Softwarewerkzeuge zwingend erforderlich wie zum Beispiel bei der Switch-Executive von National Instruments. Dieses Tool bedient nur Module, die über einen IVI-Switch-Class-Treiber verfügen. In einigen Fällen haben die Anwender die Möglichkeit, beim Entwurf eines Systems auf die Verwendung von Visa zu verzichten. In diesem Fall ist es wichtig, sich beim Hersteller zu erkundigen, ob ein geeigneter Treiber zur Verfügung steht.

Ursprünglich von der VXI-Plug-and-Play-System-Alliance entwickelt, wird der Visa-Standard inzwischen von der IVI-Foundation gepflegt. Ziel des Standards ist es, eine Möglichkeit zu definieren, Instrumenten-Treiber zu entwickeln, die eine hohe Interoperabilität zwischen Modulen verschiedener Hersteller aufweisen.

Der PXI-Standard befürwortet die Verwendung des Visa-Standards. Zu seinen maßgeblichen Eigenschaften gehören:

• Der Standard erlaubt es, unterschiedliche Treiber von verschiedenen Herstellern konfliktfrei auf demselben PXI-System zu installieren.
• Um die Interoperabilität sicherzustellen, wird ein VISA-I/O-Layer für alle I/O-Funktionen eingesetzt.
• Es ist definiert, wie die Treiber geschrieben werden.
• Ein Treiber, der die VISA-Spezifikation einhält, verwendet definierte Datentypen sowie definierte Funktionsnamen.
• Er verkürzt den Einarbeitungsprozess in neue Instrumente und somit die Zeit, ein Testsystem zu entwickeln.

Der IVI-Standard (Interchangeable Virtual Instrument) wird von der IVI-Foundation gepflegt. Ziel von IVI ist es, einen hohen Grad der Austauschbarkeit und eine Instrumentensimulation bereitzustellen. IVI unterstützt alle wichtigen Plattformen einschließlich PXI, AXIe und GPIB. Da sich diese Schnittstelle auf höherer Ebene befindet, die einen Low-Level-Treiber für den Zugriff auf die Hardware verwendet, kann ihr Einsatz gegenüber anderen Treibern zu einer geringfügig niedrigeren Geschwindigkeit führen.

Die genannten Zielsetzungen der IVI-Foundation dienen dazu, die Austauschbarkeit der Hardware zu verbessern, durch:

• Vereinfachung der Aufgabe, ein Instrument durch ein ähnliches Instrument zu ersetzen.
• Die Anwendungssoftware weiter zu nutzen, falls Instrumente nicht mehr verfügbar sein sollten.
• Vereinfachung der Wiederverwendung von Programmcode von der Designvalidierung bis zur Produktion.

Die Qualität verbessert sich durch die Einführung von Richtlinien für den Test und die Verifizierung von Treibern.

Verbesserung der Interoperabilität durch:

• Bereitstellung eines strukturellen Rahmens, der es Anwendern ermöglicht, Software von verschiedenen Lieferanten einfach zu integrieren.
• Bereitstellung eines standardisierten Zugriffs auf Treiberfunktionalitäten wie Range-Checking und State-Caching.
• Simulation von Instrumenten, um Software-Entwicklung auch dann zu ermöglichen, wenn die Hardware (noch) nicht verfügbar ist.
• Umsetzung konsistenter Instrumentensteuerungen in populären Programmierumgebungen.

Wie auch VISA, bietet IVI eine Möglichkeit, die Treiberentwicklung zu standardisieren, jedoch geht IVI weit über die Möglichkeiten von VISA hinaus. Die IVI-Spezifikationen beinhalten mehrere Instrumenten-Klassen-Definitionen. Jede Klasse verfügt über eine Standard-Programmierschnittstelle, einschließlich Funktionsnamen und Datentypen. Durch den richtigen Einsatz von IVI-Klassen-Treibern kann ein Anwender ein hardwareunabhängiges System entwickeln, das heißt Instrumente lassen sich sehr leicht durch ähnliche Instrumente anderer Hersteller ersetzen, ohne dass der Code des Anwenderprogramms umgeschrieben werden müsste.

Zum Zeitpunkt der Erstellung dieses Artikels sind folgende Klassen spezifiziert:

• IVI-4.1: IviScope Class Specification (Diese Spezifikation definiert die IVI-Klasse für Oszilloskope).
• IVI-4.2: IviDmm Class Specification (Diese Spezifikation definiert die IVI-Klasse für Digitalmultimeter).
• IVI-4.3: IviFgen Class Specification (Diese Spezifikation definiert die IVI-Klasse für Funktionsgeneratoren).
• IVI-4.4: IviDCPwr Class Specification (Diese Spezifikation definiert die IVI-Klasse für DC-Spannungsversorgungen).
• IVI-4.5: IviACPwr Class Specification (Diese Spezifikation definiert die IVI-Klasse für AC-Spannungsversorgungen).
• IVI-4.6: IviSwtch Class Specification (Diese Spezifikation definiert die IVI-Klasse für Schalter).
• IVI-4.7: IviPwrMeter Class Specification (Diese Spezifikation definiert die IVI-Klasse für HF-Leistungsmesser).
• IVI-4.8: IviSpecAn Class Specification (Diese Spezifikation definiert die IVI Klasse für Spektrumanalysatoren).
• IVI-4.10: IviRFSigGen Class Specification (Diese Spezifikation definiert die IVI-Klasse für HF-Signalgeneratoren).
• IVI-4.12: IviCounter Class Specification (Diese Spezifikation definiert die IVI-Klasse für Zähler/Zeitgeber).
• IVI-4.13: IviDownconverter Class Specification (Diese Spezifikation definiert die IVI-Klasse für Abwärts-Frequenzumsetzer).
• IVI-4.14: IviUpconverter Class Specification (Diese Spezifikation definiert die IVI-Klasse für Aufwärts-Frequenzumsetzer).
• IVI-4.15: IviDigitizer Class Specification (Diese Spezifikation definiert die IVI-Klasse für Frequenz-Digitalisierer).

Bei der Klassenspezifizierung sollte nicht vergessen werden, dass die Klassendefinition keine anbieterspezifischen Eigenschaften beinhalten kann, sondern nur die Grundfunktionalität der Instrumentenklasse. Auch Leistungsunterschiede wie Genauigkeit oder Geschwindigkeit sind nicht berücksichtigt. Für die Praxis ist es wichtig, sich die Konsequenzen eines Wechsels von einem Modul auf das eines anderen Herstellers bewusst zu machen, dass sich diese unter Umständen nicht exakt identisch verhalten.

IVI-Treiber beinhalten eine integrierte Simulationsfähigkeit. Mittels dieser Simulation lassen sich Anwendungen entwickeln, ohne, dass das Instrument tatsächlich vorhanden ist. Die Entwicklung kann beginnen, bevor die Instrumente vorhanden sind oder wenn sie noch bei anderen Anwendungen genutzt werden.

IVI-Treiberarchitektur

Ein IVI-Treiber hat inhärente Fähigkeiten implementiert, die im Dokument IVI-3. Inherent Capabilities Specificaton definiert sind. Dabei kommt es nicht darauf an, ob er auch einer Klassenspezifikation entspricht. Ein IVI-Klassentreiber ist eine allgemeine, abstrakte Klasse, die die grundlegenden Eigenschaften von Instrumenten dieser Klasse definiert, wie sie zwischen den Mitgliedern der IVI-Foundation vereinbart worden sind. Eigenschaften, die ein spezieller Lieferant anbietet und die nicht notwendigerweise bei Modulen anderer Lieferanten gegeben sind, beinhaltet ein spezifischer IVI-Treiber (IVI Specific driver). Untergruppen der IVI Specific Driver bilden die spezifischen, Klassen-kompatiblen IVI-Treiber (IVI Custom Specific Driver). Ein IVI-Class-Compliant-Specific-Driver bietet sowohl die Klassen-Funktionalität, als auch eine zusätzliche Lieferanten-spezifische Funktionalität.

Der IVI-Treiber reproduziert aus der IVI-3.1-Spezifikation. Pickering Interfaces

Die meisten Spezifikationen enthalten optionale Fähigkeiten zur Klassenerweiterung wie die Scanner-Funktions-Gruppe in IviSwtch. Da sie optional sind, ist nicht sichergestellt, dass alle Lieferanten diese Fähigkeiten bieten. Ein Großteil der IVI-Treiber fällt in die Gruppe der spezifischen, Klassen-kompatiblen IVI-Treiber (IVI Class-Compliant Specific Driver). Das bedeutet, dass der Treiber Klassen-kompatibel ist, jedoch zusätzliche Funktionalitäten beinhaltet, die über die Klassen-Definition hinaus gehen. Weiterhin ist es möglich, die Treiber mit einem C-, einem COM- oder einem .NET-Interface auszustatten. Die meisten Entwicklungsumgebungen können auf einen Treiber mit C-Interface zugreifen, viele nutzen ein COM-Interface, wohingegen nur wenige Entwicklungsumgebungen das .NET-Interface unterstützen.

Der IVI-Konfigurationsspeicher (IVI Configuration-Store)

Beim IVI-Treibermodell kommt dem IVI-Configuration-Store eine zentrale Rolle zu. Das Diagramm zeigt die Beziehungen verschiedener Software-Elemente im Rahmen der Nutzung des IVI-Systems.

Anwendung des spezifischen, Klassen-kompatiblen IVI-Treibers, reproduziert aus der IVI-3.1-Spezifikation. Pickering Interfaces

Beim IVI-Konfigurationsspeicher handelt es sich um eine XML-Datei, die Definitionen und Beziehung zwischen verschiedenen Aspekten eines Moduls und seiner Software-Treiber enthält. Das IVI-Softwaresystem bietet die Möglichkeit, über einen Treiber auf den Speicher zuzugreifen. Um auf den IVI-Konfigurationsspeicher zugreifen und diesen manipulieren zu können, stehen spezielle Werkzeuge wie zum Beispiel der Measurement- und-Automation-Explorer (MAX) von National Instruments zur Verfügung.

(ah)