Rahman Jamal: "Indem der Anwender benutzerspezifische Funktionen quasi per Software in das Gerät hineindesignt, kann er dem Gerät immer wieder ein neues Gesicht verleihen."

© National Instruments

Herr Jamal, Sie prophezeien das Ende traditioneller Messgeräte! Wie sieht Ihr neuer Ansatz aus?

Stellen Sie sich vor, Sie als Nutzer bestimmen, was das Gerät zu tun hat – und nicht der Hersteller. Sie können sich also auf die eigentliche Fragestellung 'Was will ich und wie setze ich es um?' konzentrieren. Die klassische Herangehensweise sieht doch so aus, dass ein Messgerät mit fest vorgegebener Funktionalität eventuell noch über ein Stückchen Software vom PC aus angesprochen und gesteuert wird. Wir gehen jetzt erheblich weiter: Der Endanwender kann jetzt nicht nur die Software um das Messgerät herum entwickeln, sondern auch die Software innerhalb des Messgerätes selbst entwerfen. Wir nennen dies 'softwaredesignte Messtechnik'.

Sie haben auf Basis dieser Philosophie jetzt einen neuen Transceiver vorgestellt. Welche Vorteile hat dieses Gerät gegenüber herkömmlichen?

Wir haben damit eine neue Kategorie von Instrument entworfen, welche die HF-Funktionalitäten eines Vektorsignal-Generators, eines Vektorsignal-Analysators und eines offenen Firmware- und Software-Modells vereint: Wir nennen es einen Vektorsignal-Transceiver – kurz VST. Anders als herkömmliche HF-Messlösungen gestattet der auf PXI basierende VST dem Anwender, sein eigenes benutzerspezifisches HF-Messinstrument zu konzipieren – vor allem durch 'Hineindesignen' der auf seine Belange zugeschnittenen Echtzeit-Signalverarbeitungs- und -Steuer-/Regelalgorithmen in das Messsystem. Möglich wird dies durch den in den VST integrierten FPGA, der anwenderspezifisch über Labview konfiguriert beziehungsweise programmiert werden kann.

Welche konkreten Vorteile ergeben sich hierbei?

Damit heben wir die üblichen Einschränkungen auf, denen sich der Anwender in der klassischen Messtechnik gegenüber sieht. Insbesondere ist er nun nicht mehr auf Funktionalitäten beschränkt, die ihm vom Hersteller aufgezwungen werden. Er legt selbst die Eigenschaften des Messgeräts fest. Solch ein Messgerät lässt sich einerseits im herkömmlichen Sinne nutzen, andererseits kann der Anwender Schicht für Schicht in die Software eintauchen, bis hin zur Firmware, ja sogar bis zu den Pins des Messgeräts. Damit lassen sich beliebige benutzerspezifische Modifikationen und Erweiterungen umsetzen, um beispielsweise neue Funktionen zu definieren oder auch die Leistungsfähigkeit des Geräts nach oben zu schrauben.

Ist Ihr Ansatz auch auf Geräte der Automatisierungstechnik übertragbar? Mit welchen Konsequenzen beziehungsweise Vorteilen?

Wir tun dies bereits: Nehmen Sie die CompactRIO-Plattform, die schon länger auf dem Markt ist. Hierbei handelt es sich um ein rekonfigurierbares Embedded-Steuer-, -Regel- und –Datenerfassungssystem, dessen Herzstück einen rekonfigurierbaren FPGA enthält. Dieser FPGA lässt sich über Labview beliebig konfigurieren beziehungsweise programmieren, so dass er je nach Anwendungsfall ein anderes Gesicht verliehen bekommt.

David Humphrey: "Ein reizvolles Konzept für die Automation"

David Humphrey, Director of Research bei der ARC Advisory Group: "Ein großer Hemmschuh sind die heutigen Engineering-Tools – der Anwender würde viel zu schnell die Übersicht verlieren!"

© ARC Advisory Group

Herr Humphrey, Applikation und Gerätefunktion in Software entwickeln und sie dann in das FPGA eines Automatisierungsgerätes gießen: Wäre das eine praktikable Vorgehensweise für die Automatisierungstechnik?

Das Konzept von National Instruments könnte auch in der Automatisierungstechnik eine Zukunft haben, da es zwei andere, gängige Konzepte unterstützt: die Modularität und die Dezentralisierung. Modulare Architekturen ermöglichen Maschinenbauern das 'mass customization', also die individualisierte Konfiguration ihrer Maschinen. Durch eine flexible Architektur kann der Kunde nur die Funktionen kaufen, die er wirklich braucht, oder seine eigene Konfiguration nach dem Baukastenprinzip zusammen stellen, ohne viel zusätzlichen Projektierungsaufwand seitens des Maschinenbauers.

Die Modularität wird begünstigt durch den Trend, immer mehr Funktionen in Software zu realisieren. Die Hardware wird bis auf die CPU, Sensoren und Aktoren reduziert. Der nächste logische Schritt wäre, die Software mittels FPGAs direkt in den Endgeräten einzubetten. Durch diese Verlagerung der Intelligenz könnten Maschinenbauer ihre Kosten reduzieren, die Flexibilität erhöhen und ihr geistiges Eigentum besser schützen.

Welche Vorteile würden Sie in einer solchen Vorgehensweise sehen?

Es gibt Vor- und Nachteile. Der Lösungsansatz von National Instruments ist für die Automatisierungsbranche ein attraktives Ziel, nur der Weg dahin ist nicht ohne Barrieren. Solche 'Blackbox'-Lösungen sind schwierig zu warten, da jede Lösung ein Unikat ist. Außerdem sind manche Maschinenbauer und Endkunden gegen eine Dezentralisierung ihrer Architekturen, da sie schnell den Überblick verlieren. Eine Lösung hierfür sind Engineering-Tools, die dezentralisierte Einheiten visuell wieder zusammenfügen, damit sie wie ein Programm aussehen, aber so weit sind wir noch nicht.

Die Vorteile sehe ich in reduzierten Kosten durch weniger Hardware und die daraus resultierende erhöhte Flexibilität. Außerdem können FPGAs nicht so schnell 'reverse engineered' werden – das heißt, Maschinenbauer senken das Risiko, dass ihr Know-how geklaut wird – ein wichtiger Faktor heutzutage, nicht nur in Asien!

Prof. Dr. Detlef Zühlke: "Die Feldgeräte werden zu smarten Webknoten"

Prof. Dr. Detlef Zühlke, wissenschaftlicher Direktor am DFKI: "Zukünftig werden wir die Feldgeräte über das Netzwerk an ihre spezielle Aufgabe anpassen können – was allerdings noch fehlt, sind Standards auf allen Ebenen der Kommunikation."

© DFKI

Herr Prof. Zühlke, ist denn der Ansatz von National Instruments auch auf die Automatisierungstechnik übertragbar?

Klassische Automatisierungskomponenten arbeiten schon lange nach diesem Prinzip, zum Beispiel ist eine SPS eine Standard Hardware, die durch kundenspezifische Software zum funktionsspezifischen Leben erweckt wird. Auch die modernen Sensoren und Aktoren sind in der Regel vom Anwender auf die jeweilige Funktionalität programmierbar.

Was spricht gegen beziehungsweise für einen solchen Ansatz?

Zunächst einmal spricht nichts dagegen, solange der Kunde davon profitiert. Interessant wird die Vorgehensweise, wenn wir uns in Richtung Hardware-Unabhängigkeit bewegen. Das heißt, der Kunde kann Sensoren und Aktoren beliebiger Hersteller so programmieren, dass sie schnittstellenkompatibel werden. Eine solche Vorgehensweise dürfte allerdings nicht gerade im Interesse der Hersteller liegen.

Sehen Sie schon Tendenzen in der Automation in diese Richtung?

In der Automation ist eine starke Tendenz hin zu einer herstellerneutralen Vernetzung aller Komponenten zu verzeichnen. Heutige Feldbus-Systeme werden mehr und mehr durch immer leistungsfähigere Lösungen auf Standard-Ethernet-Basis ersetzt werden. Und oberhalb der physikalischen Transportschichten werden wir standardisierte Middleware-Lösungen wie OPC-UA verstärkt einsetzen. Die Feldgeräte werden sich damit zu smarten Webknoten entwickeln, die über OPC-UA ihre Kommunikation abwickeln. Und da sie 'smart' sind, wird man sie auch über das Netzwerk konfigurieren, das heißt an ihre spezielle Aufgabe anpassen können.

Wir folgen damit dem aktuellen Paradigma 'Industrie 4.0', welches voraussagt, dass zukünftige Produktionssysteme dem Leitbild des Internet of Things folgen werden. Alle Elemente werden zu Cyber-Physical-Systems – zu smarten Automatisierungskomponenten – die sich ad-hoc in IP-basierten Netzwerken vernetzen werden. Aber Voraussetzung für diese neue Zukunftswelt sind entsprechende Standards auf allen Ebenen, damit solche smarten 'Objekte' untereinander auch Ebenen-übergreifend kommunizieren können. Wenn ich mir die Situation etwa bei den Funkkommunikationsstandards anschaue, werden wir uns mächtig anstrengen müssen, um solche Standards auf dem Weltmarkt durchzusetzen.

Hans-Jürgen Hilscher: "Bewusst gegen eine FPGA-Lösung entschieden"

Hans-Jürgen Hilscher, Firmenchef bei Hilscher: "Applikationsspezifische Bausteine sind in der Automation ein Muss, reine FPGA-Szenarien sind aber sicher nicht die Lösung."

© Hilscher GmbH

Herr Hilscher, Automatisierungstechnik auf Chip-Ebene ist ja mehr oder weniger Spezialität ihres Hauses. Was halten Sie von dem Ansatz, Gerätefunktion und Anwendung auf Software-Basis zu erarbeiten und sie dann in ein FPGA zu gießen?

Schauen sie sich Spitzentechnologien in der Automatisierung an und sie werden feststellen, dass sie um applikationsspezifische Bausteine gar nicht umhin kommen. Das können FPGA-Lösungen, spezielle ASICs oder über Mikrocode in weiten Bereichen konfigurierbare Controller sein. Aufgrund der geringen Stückzahlen, der hohen NRE-Kosten und der notwendigen Flexibilität über die Lebenszeit eines Produktes Funktionen upzudaten und zu ergänzen, kann dies nur auf Basis von Software erfolgen. Dabei hat sich Hilscher bewusst gegen eine FPGA-Lösung entschieden.

In der industriellen Kommunikationstechnik können sie für einige Slaves IPs kaufen, die sich einfach in FPGAs 'gießen' lassen. Dabei ist jedes IP, sprich jede FPGA-Implementation, anders, was die Applikationsschnittstelle betrifft. Sie können keine analogen Komponenten wie etwa Physical Layer implementieren, und Speicherblöcke von über 600 Kbyte – wie wir sie in unseren netX 51/52 haben – bedingen extrem teure FPGAs. Versuchen sie doch mal, ein IP für einen Profinet Controller oder ein Profinet Device zu kaufen, das die Version 2.3 unterstützt. Wenn überhaupt werden sie noch einige Jahre warten müssen.

Mit unseren netX Controllern haben wir uns eine Infrastruktur geschaffen, die wir über eine eigens entwickelte Sprache konfigurieren. Die einheitliche Architektur sichert eine hohe Qualität und erzielt große Synergie-Effekte bei der Implementierung von über 20 Protokollmaschinen. Seit sechs Jahren folgen wir damit den Entwicklungen in der industriellen Kommunikationstechnik. Erst in der neuen Generation haben wir Rechenleistung und Ressourcen erweitert, konnten aber große Teile unser Konfigurationssoftware wieder verwenden. Von daher ein eindeutiges 'Ja' dazu, Gerätefunktionen auf Software-Basis zu erarbeiten. Allerdings halte ich dies auf Basis von FPGAs für die gesamte Breite der industriellen Kommunikationstechnik durchzuführen – und nur darüber kann ich sprechen – für den falschen Ansatz.