Austauschbarkeit oder Kompatibilität?
1. Machine Vision Standards
Mit dem Aufkommen von Machine Vision Standards hat sich die Industrie in einer nie dagewesenen Weise auf eine Zusammenarbeit geeinigt. Daraus entstanden in den letzten zehn Jahren mit GenICam, GigE Vision oder USB3 Vision generische Schnittstellen für den Einsatz von Industriekameras mit einheitlichen Funktionsnamen und definiertem Feature-Umfang. Die Design-In-Phase von Kameras in Machine Vision Anwendungen sollte sich dadurch vereinfachen und verkürzen, um Entwicklungskosten einzusparen. Die Austauschbarkeit und vollständiges Plug & Play von Geräten werden dabei immer als wesentliche Merkmale hervorgehoben.
Aber sind das die ausschlaggebenden Faktoren zur Realisierung einer Anwendung? Ist der vollständig generische Lösungsansatz für jede Applikation der richtige? Das kommt darauf an.
Um eine erfolgreiche Anwendung zu erstellen, kann die Hersteller-Austauschbarkeit durchaus ein wichtiger Vorteil sein. Fest steht aber, dass die Erhaltung dieses Vorteils an Bedingungen geknüpft ist, die beim Aufbau einer Anwendung erst erarbeitet und zwingend einzuhalten sind.
Die Entwicklung von Machine Vision Komponenten unter Einhaltung der Festlegungen der „Vision-Standards“ ist hingegen so wichtig, um in mehr Anwendungen als zuvor zum Einsatz zu kommen. Für die Hersteller ist das anzustrebende Ziel damit eher eine „gesteigerte Kompatibilität“, die durch die Nutzung der Standard-Vision-Protokolle automatisch gegeben ist.
Die Standardisierung seitens der Organisationen AIA (Global Association for Vision Information) und EMVA (European Machine Vision Association) stellt einen wichtigen Schritt dar, dem Interface Wirrwarr im Machine Vision Umfeld Einhalt zu gebieten. Nichts desto trotz lassen die Standards den Herstellern genügend Raum für die Implementierung zusätzlicher, spezifischer Features außerhalb der SFNC, um eine Abgrenzung der Anbieter untereinander zu ermöglichen (Quality of Implementation). Mit der Nutzung dieser herstellerspezifischen Feature-Sets ist ein Herstellerwechsel unter Umständen nicht ohne Softwareanpassungen möglich.
Auch bei der Programmierschnittstelle bieten proprietäre Ansätze im Vergleich zu GenICam durchaus ein höheres Maß an Komfort und Benutzerfreundlichkeit durch den Einsatz von Convenience-Funktionen, die es im Vision Standard nicht gibt. Die Hersteller von Industriekameras wissen das und bieten deshalb oftmals eigene Programmierschnittstellen an, die aber auf den standardisierten Interfaces basieren.
Bleibt eine Anwendung durch die Nutzung dieser „proprietären Standards“ trotzdem herstellerübergreifend kompatibel oder sollte man dafür ausschließlich auf die Standardschnittstellen setzen?
2. Das standardisierte System im Detail
Um die Anforderungen und Ziele einer Anwendung sicher umzusetzen, sollten auch wichtige Details der generischen Systemlösung bekannt sein und im richtigen Maß eingesetzt werden.
Systemarchitektur
Auch wenn aktuelle Machine-Vision-Standard-Kameras mit GigE Vision bzw. USB3 Vision-Schnittstellen auch ohne ein herstellerspezifisches Softwarepaket „funktionieren“, bleibt die grundlegende Systemarchitektur notwendigerweise erhalten und muss auf einem System vorhanden sein.
Die Hardware-Ebene baut auf bekannte Technologien und Anschlusstechniken zur Übertragung von Kameradaten und Kommunikationsprotokollen (z.B. USB, Gigabit Ethernet). Gerätenahe Software (Treiber und Userspace-Bibliotheken) vermittelt mit einem API zwischen dem Transportkanal der Kamera und der Benutzeranwendung.
Abbildung 1: Durch die Schnittstellenstandardisierung entstehen für Applikationen mehrere Möglichkeiten Machine-Vision-Standard-Kameras zu nutzen.
Mit GenICam als Basis erfolgte an mehreren Schnittstellen der Systemarchitektur eine Standardisierung, wodurch mehrere klar definierte und dokumentierte Ansatzpunkte für die Verwendung von Machine-Vision-Standard-Kameras geschaffen wurden.
Aus N mach 1 und aus 1 mach N
Mit GenICam (Generic Interface for Cameras) als Vermittler zwischen Benutzeranwendung und Gerätesoftware wird die Vielzahl von herstellerspezifischen Programmierschnittstellen auf eine einzige allgemeingültige beschränkt. GenICam abstrahiert den Zugang zu allen Kamerafunktionen hersteller- und transportprotokollübergreifend. GenICam ist eine Beschreibungssprache. Die verfügbaren Funktionen werden zur Verwendung bereitgestellt, ohne sie selbst zu kennen. Das macht sie zu einer idealen Anwendungsbasis, wenn es um Features geht, die sich mit jedem Kameramodell ändern oder durch Firmware-Updates erweitern können.
Durch die Einführung von Protokollen wie GigE Vision und USB3 Vision auf der Transportebene musste auch ein Umdenken bei der Kamerafirmware stattfinden. Kameras mit diesen standardisierten Transportprotokollen, die von den Mitgliedern der AIA definiert werden, sprechen eine einheitliche Sprache gegenüber der Gerätesoftware. Damit bricht auch die strikte Zusammengehörigkeit zwischen Kamerafirmware, Übertragungsprotokoll und Gerätesoftware auf. Die Kamera wird unabhängig von einer einzigen Herstellersoftware.
Unabhängigkeit bringt neue Möglichkeiten
Vision-kompatible Kameras können jetzt mit einem herstellerunabhängigen „Generic Transportlayer“ (GenTL) betrieben werden. Die GenAPI (Generic Application Programming Interface) ermöglicht das Auflisten und die Konfiguration der verfügbaren Kamerafeatures durch die Analyse der standardkonformen XML-Datei der Kamera. Der Inhalt dieser Datei beschreibt alle implementierten Kamerafeatures in einer Syntax, die im GenAPI Modul der GenICam Spezifikation definiert ist: Funktionsnamen, Parameterlisten, erweiterte Informationen, Funktionsbeschreibung. Sogar Tooltips, die eine Anwendung für die Features anzeigen soll, sind in der XML-Datei beschrieben. Die Kamera liefert quasi ihr eigenes Programmierhandbuch mit aus.
Dabei ist es unerheblich, ob es sich um Standard-Features handelt, die in der GenICam SFNC (Standard Feature Naming Convention) definiert sind oder um spezielle „Custom-Features“, die es nur bei einem Hersteller gibt, aber standardkonform implementiert wurden.
Abbildung 2: Die GenAPI vermittelt gerätespezifische Registeradressen durch definierte Feature-Namen.
Technisch ist die herstellerunabhängige Zusammenarbeit von Hardware und Software vom Standard festgelegt und „erwünscht“. Die Unabhängigkeit ist aber nur seitens der Kamera zu 100 % gegeben. GenICam Producer mancher Hersteller scheinen dem Anwender nahezulegen, mit welcher Kamera sie gerne zusammenarbeiten wollen. Das macht die Austauschbarkeit für Anwender manchmal etwas undurchsichtig.
Mit der Unabhängigkeit ergeben sich sowohl für Kamerahersteller als auch Anwender automatisch viele neue Möglichkeiten. Z.B. die Entkopplung von Hardware- und Software-Releases. Ein neues Kameramodell bzw. neue Kamerafirmware kann in viel kürzerer Zeit bereitgestellt werden, da keine Anpassung, Dokumentation und Veröffentlichung einer Host-Software notwendig ist, um die Kamera zu betreiben.
Ebenso können Updates für einzelne Kameramodelle unabhängig von der Host-Software oder anderen Modellen sehr viel einfacher und schneller fertiggestellt werden. Die Mitglieder der EMVA-Organisation arbeiten bereits an einer Update-Spezifikation, wie Vision-Kameras über jede beliebige standardkonforme Software mit einem herstellerspezifischen Update-Paket aktualisiert werden können. Eine zusätzliche Update-Modulspezifikation zum GenICam Standard wird noch im Sommer 2017 erwartet.
Die Unabhängigkeit bringt ganz automatisch eine erweiterte Plattformkompatibilität mit sich. Mit den Standard-Transportprotokollen wie bspw. GigE Vision oder USB3 Vision sind die Kameras auf jeder Plattform und jedem Betriebssystem lauffähig, für die es eine standardkonforme, herstelleroffene Software inklusive Transportlayer gibt. Auch wenn Sie nicht aus dem eigenen Haus stammt.
Diese Unabhängigkeit ist damit die Basis für die „Austauschbarkeit“.
GenTL ist nicht gleich GenTL
GenTL sind aber alles andere als gleich. Allein die Tatsache, dass sie sowohl Richtung Kamera als auch Richtung Benutzeranwendung eine standardisierte Schnittstelle aufweisen (siehe weiße Elemente in Abbildung 1) und sie eigentlich nur für das Auffinden und Ansprechen von Geräten inklusive Bildaufnahme zuständig sein sollen, macht sie nicht zwangsläufig kompatibel mit allen Vision-Kameras.
Ein standardisierter GenTL ist für eine Bildverarbeitungsbibliothek wie bspw. HALCON eine sehr sinnvolle Erweiterung, wenn er offen für Vision-Kameras aller Hersteller ist. Der Vorteil ist ein vollständiges Plug & Play für alle Kameras, ohne eine herstellerspezifische 3rd-Party-Bibliothek installieren zu müssen. Aus diesem Grund haben die MVTec-Entwickler HALCON mit einem eigenen herstellerübergreifend kompatiblen GenTL ausgestattet (siehe Abbildung 3), der jede Vision-kompatible Kamera ohne eine spezielle Herstellersoftware verwenden kann.
Für Kamerahersteller bietet ein eigener GenTL trotz Standardvorgaben die Möglichkeit, dem Kunden eine Softwarekomponente bereitzustellen, die „optimal“ mit der eigenen Kamera interagiert und auch unter den Herstellersupport fällt. Keine ganz unwichtige Frage, wenn in einer Machine-Vision-Applikation ein Problem mit der Kamera auftritt. Wer ist dann zuständig, wenn Anwendung, BV-Bibliothek, GenTL und Kamera jeweils von unterschiedlichen Herstellern sind? Die Frage stellt sich nicht, wenn alle Komponenten von ein und demselben Hersteller stammen.
3. Kamera-Einheitsbrei?
Kameras, die dem Standard folgen, kommunizieren und übertragen Daten mit denselben Protokollen und stellen definierte Standardfeatures zur Verfügung. „Kennt man eine, kennt man alle?“ Weit gefehlt!
Wo zuvor unterschiedliche Treibersoftware notwendig war, um die Kamera-Host-Verständigung herzustellen ist nur noch eine „Sprache“ erforderlich. Wo jeder Hersteller sein eigenes Süppchen gekocht hat, arbeiten heute alle gemeinsam an der Schnittstelle und implementieren Kamerafunktionen nach definierten Vorgaben. Jeder Nutzer profitiert von dieser Entwicklung. Worin unterscheiden sich die Hersteller noch voneinander? Auch eine standardisierte Kamera bleibt ein komplexes Produkt aus mehreren Komponenten, die ausschlaggebend für den Erfolg sind: Gehäuse (Stabilität, Ausmaße, Material, Gewicht, Stecker, Optiken, Zubehör), Elektronik (EMV-Verhalten, Störverhalten, Wärmeentwicklung, Speicher, Leistungsfähigkeit, Haltbarkeit), Software (Sensor-Wissen, Feature-Umsetzung, Modularität, Wartbarkeit, Support/Unterstützung), um nur einige zu nennen. Das Gesamtpaket bleibt entscheidend für den Einsatz in einer Anwendung.
Die vollständige Softwareunterstützung, um Vision-Kameras schnell und einfach in Betrieb zu nehmen, ist für Vision Ein- und Umsteiger schon ein Auswahlkriterium. IDS Imaging Development Systems GmbH bietet seinen Kunden schon immer ein Rundum-Sorglos-Paket zu seinen Produkten an. Nach der Installation steht dem Anwender neben dem IDS Vision Cockpit mit graphischer Oberfläche zur komfortablen Kamera-Evaluierung auch ein herstellereigener GenTL zur Verfügung. Die vollständige Kompatibilität mit allen am Markt befindlichen standardkonformen Bildverarbeitungsbibliotheken ist damit gesichert.
Trotz der möglichen Austauschbarkeit der Vision-Komponenten ist ein derartiges All-in-One Paket aufgrund eines komplett inbegriffenen Hersteller-Support von der Kamera-Hardware bis zur Kundenanwendung ein sehr wichtiger Vorteil für ein Machine-Vision-Projekt.
4. Aller Anfang ist leicht?
Am einfachsten ist der Einstieg mit Vision-Standard-Komponenten über standardkonforme Bildverarbeitungssoftware wie bspw. HALCON, LabView, Cognex VisionPro. Viele der namhaften BV-Softwarepakete liefern mittlerweile eigene GenTL-Provider mit, wodurch tatsächliches Austauschen von Vision Kameras ohne herstellerspezifische Software demonstriert wird. Um Kameras über die herstellereigenen GenTL einzubinden, bringen einige dieser BV-Softwarepakete einen entsprechenden GenICam Connector mit.
Abbildung 3: HALCON besitzt ein direktes GigE Vision-Interface durch einen eigenen GenTL Producer. Über GenICam ist die Anbindungen mit jeder anderen Vision-Standard-Schnittstelle zusätzlich möglich.
So nutzen die BV-Software-Hersteller die Vorteile der Standardisierung voll aus. Der Anwender kann direkt ohne Programmieraufwand zur Kameraeinbindung mit der Bildverarbeitung beginnen. Mit den Standardschnittstellen kommt der Benutzer lediglich über die dynamische GUI des jeweiligen BV-Frameworks in Kontakt. Diese stellen im Grunde eine benutzerfreundliche, grafische, „proprietäre“ Schnittstelle dar, die es dem Benutzer so einfach wie möglich macht.
Aber nicht jeder 3rd-Party-Bildverarbeiter liefert entsprechende GenTL-Provider mit. Das trübt das Plug & Play Versprechen etwas.
Mehr Aufwand erwartet jeden, der den zweiten Ansatz wählt und seine Anwendung von Grund auf neu entwickelt. Dabei rückt die Programmierschnittstelle in den Mittelpunkt. Hier sind andere Faktoren für die Realisierung einer Anwendung wichtig.
Generische Programmierung mittels GenICam kann durch die sehr strengen, komplexen Prinzipien sehr mühselig sein. Um jede Eventualität korrekt zu bearbeiten muss jedes Feature und jeder Wertebereich zuerst abgefragt werden, bevor ein Kameraparameter verändert werden kann. Der ungefilterte Zugriff auf jede GenICam-Komponente ist sehr atomar und erfordert ein tiefes Verständnis dieser Prinzipien. Wer eher gerätebezogen schnell vorankommen möchte und weniger Wert auf die komplexen Möglichkeiten legt, wünscht sich eine einfache, reduzierte Zusammenfassung als API. Müssen diese Anwender den gänzlich „proprietären“ Ansatz wählen und damit auf alle Vorteile, die durch die Vision-Standards erreicht wurden verzichten?
5. Proprietäre Standards
Die Verwendung von Vision-Standard-Kameras ist aufgrund der definierten Schnittstellen nicht nur auf eine Weise nutzbar. Die Verwendung von Convenience-Funktionen, auch Hilfs- oder Komfortfunktionen genannt, ist ein Design-Konzept, dass in proprietären Programmierschnittstellen zur Unterstützung der Entwickler gerne eingesetzt wird. Sie helfen, Code zu vereinfachen und übersichtlicher zu gestalten, indem atomare Funktionsaufrufe gezielt gekapselt werden. Mit wenigen Funktionsaufrufen kann damit ein „definiertes“ Ziel sehr viel schneller und einfacher erreicht werden.
Wenn sich ein solches „proprietäres API“ Richtung Kamera standardkonform verhält, bildet es sogar eine weitere Möglichkeit des Zugriffs für eine Kundenanwendung.
Abbildung 4: Proprietäre Schnittstellen erweitern die Möglichkeiten Vision-Standard-Kameras zu nutzen.
Solange der Hersteller einer solchen proprietären Ebene keine Filterung für seine eigenen Geräte integriert, steht diesem Ansatz eine Nutzung in herstellerübergreifenden Anwendungen ebenfalls nichts im Weg. Übrigens entsprechen proprietäre GUIs von BV-Bibliotheken wie bspw. HALCON genau diesem Ansatz. HALCON nutzt Vision-Standards mit eigener Benutzeroberfläche. Vereinfachende Programmierschnittstellen sind also auch weiterhin möglich und erweitern den Kundennutzen.
6. Entscheidend ist die Anwendung
Die Verwendung der Standard-Schnittstellen ist ein Vorteil für Anwendungen, die es mit verschiedenen Kameras und unterschiedlichem Funktionsumfang zu tun haben. Auch der Mischbetrieb von Standard-Kameras mit verschiedenen Transfertechnologien wie bspw. USB3 Vision oder GigE Vision wird durch das einheitliche Ansprechen über das GenICam-Interface vereinfacht. Die Applikation muss über diese gerätespezifischen Merkmale nichts wissen bleibt somit für alle standardkonformen Geräte kompatibel.
Durch ein absolut dynamisches GUI werden Verbindung und Funktionsumfang von Vision-Kameras ohne weiteren Programmieraufwand zur Verfügung gestellt. Die eigentliche Arbeit kann für den Anwender bzw. den Bildverarbeiter mit der Einstellung der Kamera für die jeweilige Anwendung sofort beginnen.
Bringt eine Anwendung zusätzlich ihren eigenen GenTL mit, muss für die Integration einer neuen Kamera nicht einmal eine herstellerspezifische Software installiert werden. Für die Hersteller von Machine-Vision-Kameras bedeuten die Vision-Standards nicht nur eine mögliche Austauschbarkeit, sondern auch eine erweiterte Kompatibilität zu jeder entwickelten standardkonformen Anwendungen.
Des Weiteren bleibt aber der Anteil an Kundenanwendungen stabil am Markt bestehen, für welche die USPs (Universal Selling Proposition) der Vision-Standards nur zweitrangig sind. Diese Anwender setzen auf schnellen Einsatz von speziellen Kameras in Verbindung mit einfachen Interfaces, die vom Hersteller auch umfassend supportet und gegebenenfalls flexibel für ihre Anwendung angepasst werden.
Am Ende entscheidet immer der Kunde mit seiner Anwendung, welche Schnittstellen bzw. Geräte welchen Herstellers zum Einsatz kommen, um erfolgreich zu sein und „das beste Anwendererlebnis im Vision-Markt“ zu haben.