In der Automation löst sich der klassische Ansatz von hierarchisch aufbauender Feld-, Prozess- und Leitebene weiter auf. Konzepte wie Edge und Cloud Computing werden um Fog Computing ergänzt. Das sind zwar ebenso drei Ebenen, allerdings mit einer anderen Gewichtung von Intelligenz und Kommunikation.
Je nach Anforderung kann ein IIoT-/Edge-Gerät über mehr »Intelligenz« verfügen als ein nachgeschalteter Server in der Cloud. Das muss nicht immer mit brachialer Rechenleistung erzielt werden, sondern lässt sich ebenso mit einer smarten Spezialisierung erreichen. Seit Jahren beflügelt die Halbleiterindustrie mit ihren applikationsspezifischen Bausteinen diese Entwicklung (Bild 1).
Neben der smarten Rechenleistung spielt ebenfalls die Kommunikationsfähigkeit eine immer stärkere Rolle. Dabei ist Ethernet der klare Motor der Entwicklung: Mit einem Kommunikationsprotokoll vom Sensor bis hinauf zum Managementsystem oder sogar zum Verkaufsrechner. Das Industrie-4.0-Stichwort lautet: Serienproduktion mit Losgröße Eins.
Neben den Umbrüchen in den Abstraktionsebenen zeichnen sich ebenso in der realen Welt Veränderungen ab: Die Intelligenz rückt immer näher an den Ort des Geschehens, ist also im IIoT-Gerät am Edge verbaut. Hiermit spielen Baugröße und Wärmeentwicklung eine immer wichtigere Rolle. Eine Möglichkeit sind skalierbare Bausteinfamilien, die genau das im Chip integrieren, was Entwickler wirklich in der Anwendung benötigen – alles, was unnötig Platz und Energie braucht, wird gestrichen. Je nach Applikation kann das durchaus knifflig sein.
Es gibt aber auch klare Eckpunkte wie: »Ist ein Display anzuschließen?« Falls nein, entfallen die Grafikeinheit und die entsprechenden Schnittstellen – man spricht in dem Zusammenhang auch von »Headless«-Applikationen. Hier lagert man die Visualisierung von Zuständen und Abläufen ganz gezielt aus. In der Theorie soll die bildliche Darstellung in der Cloud erfolgen, in der Praxis will der Anwender jedoch ein Display vor Ort haben – nicht zwingend an jedem einzelnen Gerät, aber in ihrer Nähe, um eingreifen zu können, falls etwas nicht den Erwartungen entspricht (Bild 2).
Erfahrene Anwender »spüren« oftmals, dass etwas in ihrer Produktion anfängt aus dem Ruder zu laufen und wollen dann gegensteuern. Diese Aufgabe könnte ebenso der »Visualisierungsrechner« im Fog übernehmen. Er braucht dafür allerdings die entsprechende Bandbreite, um die Daten der IIoT-Geräte zu sammeln und die Rechenleistung, um sie mit Methoden der Predictive Maintenance auszuwerten.
Außerdem kann der Rechner übergeordnete Steuerungs- beziehungsweise Koordinationsaufgaben übernehmen, also die üblichen Aufgaben der klassischen Leitebene. Er ist wie ein Dirigent eines Orchesters – er muss nicht jedes Notenblatt der einzelnen Musiker kennen, sondern sie zu einer Einheit verbinden und koordinieren.
Manchmal muss ein Rechner für Fog Computing auch trennen können, besonders wenn die Datensicherheit gefährdet ist: Die Netze der Operational Technology (OT) und der Information Technology (IT) sollen klar auseinandergehalten werden und die Deterministik der OT-Netze darf nicht durch zusätzliche Payload wie Verschlüsseln belastet werden. Ein Rechner im Fog, der als Gateway und Firewall dient – also lediglich die nötigen Daten durchlässt und sie entsprechend ver- und entschlüsselt – ist oftmals die favorisierte Option. Hiermit sind viele echtzeitfähige Ethernet-Schnittstellen nötig, um die Einzelstränge des OT auszuwerten, sowie zusätzlich mindestens ein »normaler« Ethernet-Port, der die Ergebnisse in Richtung Cloud schickt (Bild 3). Dank Letzterem bleibt den Echtzeit-Ethernet-Kanälen der kryptografische Overhead erspart, der in seinem Timing nicht deterministisch ist.
Die augenscheinlichste Aufgabe für einen Fog-Rechner bleibt jedoch die Visualisierung. Sie stellt gehobene Ansprüche an die Hardware, da oftmals hohe Auflösungen und 3D-Grafik gefordert sind, um die laufenden Prozesse anschaulich darzustellen. Hinzu kommen die passenden Schnittstellen für die jeweiligen Displays beziehungsweise Monitore.
Über die applikationsspezifischen Funktionen hinaus, spielen bei der Wahl der richtigen Rechnerplattform weitere Faktoren eine bedeutende Rolle. Ein Fog-Rechner, der Daten sammelt, selektiert, koordiniert und visualisiert, ist im Dauereinsatz und die Leistungsaufnahme ein nicht zu unterschätzender Kostenfaktor. Hierbei zählt jedes Watt doppelt, zum einen am Verbrauchszähler, zum anderen beim Kühlaufwand. Letzterer setzt sich aus den Material- und Montagekosten für die Entwärmung, den Kühlkosten für den mit Abwärme belasteten Raum sowie den Wartungskosten für den Tausch von Filtermatten und Lüftern zusammen.
Der Paradigmenwechsel in der Automation hin zu Edge/Fog/Cloud-Konzepten bedeutet eine Neuausrichtung von Aufgaben und Kompetenzen und damit sich verändernde Leistungsanforderungen an die eingesetzte Elektronik. Am besten nähert man sich den Herausforderungen mit einer sehr weit skalierenden Prozessorfamilie. So kann man die unterschiedlichen Applikationen mit der passenden Performance und den nötigen Schnittstellen versorgen. Ein nicht zu unterschätzender Erfolgsfaktor ist dabei die passende Softwareentwicklungsumgebung. Sie ermöglicht es den Entwicklern, ohne einarbeitungsintensiven Werkzeugwechsel, schnell und effizient Lösungen zu erarbeiten – also eine Tool-Chain über die gesamte Plattform hinweg und für mehrere Produktfamilien.
Selbst wenn der Fog-Rechner von den Echtzeitapplikationen der einzelnen Edge-Geräte entkoppelt ist, kann eine Echtzeitreaktionsfähigkeit im Rahmen der Gesamtanlage durchaus gefordert sein. Auch hier punktet eine durchgängige Softwareentwicklungskette vom Edge-Gerät bis hin zum Fog-Rechner. Ebenso ist der Einsatzort bei einem Fog-Rechner in Betracht zu ziehen. So herrscht in vielen Werkshallen ein deutlich raueres Klima, als es die übliche IT verträgt. Muss man sie gegen die besonders harsche Umwelt kapseln, wird die Baugröße schnell ein Thema.
Die wichtigsten Anforderungen für einen Fog-Rechner im Überblick:
TQ-Embedded stellt sich den vielfältigen Anforderungen mit dem Embedded-Modul »TQMa65xx« sowie dem Mainboard »MBa65xx«. Sie basieren auf dem »Sitara AM65x«-Baustein von Texas Instruments. Er kombiniert zwei oder vier Arm-Cortex-A53-Kerne mit einem dualen Arm-Cortex-R5F-MCU-Subsystem. Es enthält Funktionen für die funktionale Sicherheit sowie drei Gigabit-Subsysteme für die industrielle Kommunikation in einem System-on-Chip (SoC). TQ ergänzt die CPU zu einem lauffähigen System, unter anderem mit Speichern, Security-Elementen und einem Power-Management. Für die Visualisierungsaufgaben verfügt der AM65 über eine 3D Graphics Processing Unit (GPU) für eine Auflösung bis zu 1920 x 1200 Pixel – das TQMa65xx stellt sie per 24-bit-RGB für LVDS oder für ein Display bereit. Zusätzlich stehen MIPI-CSI2- und 16-bit-Video-in-Anschlüsse sowie zwei Kameraeingänge für Videokommunikation oder Überwachungsaufgaben bereit (Bild 4).
Wer es besonders deterministisch will, kann an jeden Port lediglich einen Sender/Empfänger anschließen und ist so befreit von Netzwerkkollisionen. Zusätzlich gibt es einen normalen Gigabit-Ethernet-Port für die Kommunikation mit der Cloud/IT. Im Falle des MBa65xx sind die Ethernet-Buchsen auch räumlich klar getrennt: Auf der einen Seite die echtzeitfähigen Ports, auf der anderen Seite die Buchse für das »normale« Ethernet für die Cloud – wer hier in der Not den Stecker ziehen will, findet ihn sofort.
Kryptografische Beschleunigung und sicheres Booten sind auf dem AM65x zusätzlich zu den vom Device Management und Security Controller (DMSC) verwalteten granularen Firewalls verfügbar. Der Arm-Cortex-M3-basierte DMSC fungiert als Master für die Systemsicherheit und schützt Security Assets während der Laufzeit. Ergänzt wird das auf dem TQMa65xx um ein Secure-Element als Zusatzchip.
Mit seiner Größe von 77 mm x 55 mm benötigt das TQMa65xx lediglich wenig Platz und eignet sich somit ebenfalls für schwierige Einbauverhältnisse. Typischerweise liegt die Leistungsaufnahme bei 6 W, der Standardtemperaturbereich reicht von -25 bis +85 °C, optional von -40 bis +85 °C.
Dank der Cortex-R5F-Kerne können TQMa65xx und MBa65xx ebenfalls Echtzeitaufgaben übernehmen und somit den üblichen starren Aufgabenbereich eines Rechners der Leitebene erweitern hin zu flexiblen Fog-Applikationen. Gerade die Anpassungsfähigkeit ist der Schlüssel, um das Konzept der »Software Defined Factory« zu realisieren: Die einzelnen Geräte lassen sich für die jeweilige Fertigungsaufgabe entsprechend konfigurieren – aus der Cloud heraus oder mit einem geeigneten Fog-Rechner.
Betrachtet man die Skalierbarkeit der AM65x-Serie von Texas Instruments, muss man ebenfalls die Schwesterserien »AM64x« und »AM24x« einschließen. Sie sind beide für Headless-Applikationen ausgelegt, haben also keine energieintensive GPU und Display-/Monitor-Schnittstellen. Aufgrund ihrer Arm-R5F-Kerne eignen sie sich sehr gut für Echtzeitapplikationen. Sie teilen sich nicht nur viele Hardware-Komponenten mit der AM65-Serie, auch die Softwareentwicklungsumgebung ist dieselbe. Hiermit können Entwickler ohne Tool-Bruch über die unterschiedlichen Bausteinfamilien hinweg arbeiten. Die Tabelle zeigt die Skalierbarkeit im praktischen Einsatz als TQ-Modul.
Jedoch eignen sich die Module nicht nur für den modernen Automatisierungsansatz mit Edge/Fog/Cloud, sie können ebenfalls die Aufgaben des klassischen Feld-, Prozess- und Leitebene-Konzepts erledigen. Hiermit schlagen sie eine Brücke zwischen altem und neuem Ansatz und ermöglichen so eine nahezu fließende Umstellung. Denn eine bestehende und produzierende Fabrikationsanlage umzustellen, erfordert deutlich mehr, als ein neues Konzept mit einer neuen Fabrik auf die grüne Wiese zu stellen – hier soll eine Umstellung mit möglichst wenig eingreifenden Schritten erfolgen.
Anwender der Modultechnik von TQ sind also für bestehende Anlagen und künftige Projekte gut gerüstet. Mit einer Langzeitverfügbarkeit von mehr als 15 Jahren besteht zudem Liefersicherheit – auch bei ungewollten Projektverzögerungen und sehr langen Einsatzzeiten. Mit einer ausgeklügelten Obsolescence-Management-Strategie schützt TQ seine Produkte, wie das TQMa65xx und MBa65xx, vor unerwarteten Änderungen und Abkündigungen – was in der aktuellen Marktsituation ein unverzichtbarer Bestandteil der Produktlebenszyklus-Maßnahmen ist. Darüber hinaus unterstützt TQ Entwickler mit diversen Obsolescence-Management-Dienstleistungen. Als erfahrenes E²MS-Unternehmen und Systemanbieter kann die TQ-Group zudem zahlreiche Dienstleistungen zu den Modulen anbieten und so in vielen Phasen der Produktentwicklung und Fertigung unterstützen. Zudem ist das firmeneigene Product Compliance Center für das Durchführen von Prüfungen zur elektromagnetischen Verträglichkeit, Produktsicherheit und für Umweltprüfungen zugelassen.