Verteilte Systeme sind üblicherweise, wie in Bild 2 dargestellt, als ein Netzwerk intelligenter Subsysteme angelegt, die zusammen ein verteiltes, ineinandergreifendes System ergeben. Erhöht sich die Systemleistung, kann dieser hardwarezentrierte Ansatz jedoch zu Problemen führen, da die Subsysteme häufig sowohl über zeitkritische als auch nicht zeitkritische Protokolle miteinander kommunizieren. Dadurch ergeben sich zwangsläufig Engpässe bei Latenz, Determinismus und Durchsatz. So kann es z.B. bei Anwendungen, die ein nahtloses Zusammenspiel von Bildverarbeitung und Motion Control erfordern – wie z.B. bei der bildgestützten Robotersteuerung (Visual Servoing) – mit einer verteilten Architektur zu erheblichen Leistungsproblemen kommen, die sich jedoch erst aufgrund der gestiegenen Verarbeitungskapazität offenbaren. Hinzu kommt, dass jedes Subsystem über einen eigenen Controller gesteuert wird, wodurch es zu einer geringeren Verarbeitungseffizienz kommt, da keines der einzelnen Subsysteme die tatsächliche Verarbeitungsleistung des Gesamtsystems benötigt. Entwickler sind daher mit diesem verteilten, hardwarezentrierten Ansatz gezwungen, für jedes Subsystem andere Designwerkzeuge zu verwenden, was insbesondere kleinere Entwicklerteams oder Einzelingenieure vor Herausforderungen stellt.
Softwarezentrierter Ansatz
Glücklicherweise gibt es jedoch eine bessere Möglichkeit, diese Art von System zu entwerfen. Der Schlüssel hierzu ist ein softwarezentrierter Ansatz, bei dem für alle Systembereiche ein und dasselbe Entwicklungswerkzeug eingesetzt und der modulare Aufbau des mechanischen Systems in Software abgebildet wird. Durch die Konsolidierung der verschiedenen Automatisierungsaufgaben wie optische Inspektion, Bewegungssteuerung, I/O und HMIs in nur einem leistungsstarken Embedded-System lässt sich nicht nur die Struktur des jeweiligen Steuer- und Regelsystems vereinfachen. Auch die klassischen Kommunikationsprobleme zwischen den Subsystemen werden umgangen, da alle Systeme auf einem zentralen Controller und im gleichen Softwarestack ausgeführt werden. Als zentraler Controller kann hier z.B. ein Embedded-Visionsystem eingesetzt werden. Die zentralisierte Verarbeitungsarchitektur bietet verschiedene Vorteile, was am Beispiel einer bildverarbeitungsgestützten Bewegungssteuerung, wie z.B. einem flexiblen Zuführsystem, deutlich wird. Bei dieser Art von Anwendung geht es um Teile, die in unterschiedlichen Positionen und Ausrichtungen vorliegen. Das Bildverarbeitungssystem macht zunächst ein Foto des jeweiligen Teils, um die genaue Position und Ausrichtung zu ermitteln, und überträgt die Daten anschließend an das Bewegungssteuerungssystem. Dieses setzt daraufhin den Aktor in Bewegung, der anhand der übermittelten Koordinaten das jeweilige Teil aufnimmt. Die übermittelten Informationen dienen aber auch dazu, die Ausrichtung eines Teils zu korrigieren, bevor es an der vorgesehenen Stelle wieder abgelegt wird, d.h. dass keine Spezialvorrichtungen oder -halterungen mehr eingesetzt werden müssen, um Teile richtig zu positionieren und auszurichten. Dies spart auf der einen Seite Kosten und ermöglicht andererseits auch einfachere Anpassungen an neue Teile, da nur die Software geändert werden muss.
Zentralisierte Verarbeitungsarchitektur
Ein Vorteil der hardwarezentrierten Architektur ist die Skalierbarkeit, die durch die Ethernet-Anbindung der Subsysteme ermöglicht wird. Aber auch hier müssen einige Aspekte beachtet werden, da die Ethernet-Kommunikation nicht deterministisch ist und nur eine eingeschränkte Bandbreite zur Verfügung steht. Für die meisten bildverarbeitungsgestützten Bewegungssteuerungen, bei denen die Bildverarbeitung nur zu Beginn der Aufgabe zum Einsatz kommt, stellt dies keine größeren Herausforderungen dar. Allerdings kann es in bestimmten Anwendungsfällen aufgrund der Latenzschwankungen zu Problemen kommen. Auch hier bietet der Übergang zu einer zentralisierten Verarbeitungsarchitektur mehrere Vorteile. Erstens ist die Entwicklung weniger komplex, da sowohl das Bildverarbeitungs- als auch das Bewegungssteuerungssystem mit derselben Software erstellt werden kann. Zweitens werden potenzielle Leistungsengpässe im Ethernet-Netzwerk umgangen, da Daten nur noch zwischen den Schleifen einer einzelnen Anwendung übertragen werden, anstatt über eine Bit-Übertragungsschicht. Da alle Subsysteme Teil des gleichen Prozesses sind, wird somit das gesamte System deterministisch ausgeführt. Dies ist insbesondere für solche Anwendungen nützlich, bei denen die Bildverarbeitung direkt in die Regelschleife integriert ist, wie z.B. beim Visual Servoing. In diesem Fall nimmt das Bildverarbeitungssystem während des gesamten Bewegungsablaufs kontinuierlich Bilder des Aktors und des jeweiligen Teils auf, bis die Bewegung vollständig ausgeführt ist. Die Bilder dienen der Überprüfung, ob die Bewegung erfolgreich ausgeführt wurde. Anhand der Ergebnisse können Entwickler dann die Genauigkeit und Präzision der Automatisierung optimieren, ohne dafür leistungsstärkere Hardware einsetzen zu müssen.
Heterogene Verarbeitungsarchitektur
Um die für die industrielle Bildverarbeitung nötige Rechenleistung und Steuerung/Regelung bereitzustellen, sowie gleichzeitig eine nahtlose Anbindung an andere Systeme, u.a. Bewegungssteuerung, HMIs und I/O zu ermöglichen, muss die Hardwarearchitektur für jedes der einzelnen Subsysteme die entsprechende Leistung, Kommunikation und Steuerung bieten können. Eine gute Lösung ist hier eine heterogene Verarbeitungsarchitektur, bestehend aus Prozessor, FPGA und I/O. Auf Industrieseite wird schon länger verstärkt in diese Art der Architektur investiert, was sich z.B. an den Zynq All-Programmable SoCs (System on a Chip) von Xilinx mit ARM-Prozessor und Xilinx-7-FPGA sowie zahlreichen derzeit erhältlichen Bildverarbeitungssystemen zeigt. Insbesondere für die Bildverarbeitung ist der Einsatz von FPGAs praktisch, da sie von Haus aus eine parallele Ausführung bieten, d.h. dass Algorithmen auf tausende Pfade aufgeteilt werden und dabei völlig unabhängig voneinander bleiben. Nicht nur für die Bildverarbeitung hat diese Architektur zahlreiche Vorteile, sondern auch für die Bewegungssteuerung und I/Os, da die Prozessoren und FPGAs anspruchsvolle Verarbeitungs-, Rechen- und Logikfunktionen ermöglichen. Darüber hinaus lässt sich nahezu jeder Sensor über beliebige Bussysteme anbinden. Auch was Timing, Synchronisierung und nicht zuletzt die Produktivität angeht, hebt sich diese Architektur von anderen Ansätzen ab. Denn da keine größeren, spezialisierten Designteams mehr nötig sind, beschleunigt sich auch die Entwicklung. Diese Architektur bietet zwar klare Vorteile in Bezug auf Leistung und Skalierbarkeit, jedoch waren bisher für die Implementierung und insbesondere die Programmierung und Nutzung des FPGAs spezielle Fachkenntnisse vonnöten. Mithilfe integrierter Software, wie z.B. LabView, lassen sich diese Risiken jedoch relativ gering halten und gleichzeitig die Produktivität steigern, da komplexe Low-Level-Vorgänge abstrahiert werden und jegliche eingesetzte Technologie in eine einheitliche Entwicklungsumgebung integriert ist.
