Fabriken sind verstärkt herausgefordert, wendig und geschickt zu sein. Anstatt dieselbe Sache hundertmal, tausend- oder gar millionenfach herzustellen, heißt das neue Paradigma Flexibilität, um Geräte und Ausrüstungen rasch umgestalten zu können und dadurch unterschiedliche Builds zu unterstützen. Dies kann streng vertrauliche Informationen betreffen, weswegen OEMs beschließen könnten, einige oder die gesamte entsprechende Fertigungssoftware letztendlich selbst zu schreiben. Das Unternehmen, dessen Roboter ein bestimmtes Produkt baut, muss OEM-Software integrieren und sicherstellen können, dass diese nicht die zugrundeliegende Steuersoftware des Roboters beeinträchtigt.

Bild 1: Der Trend zum Mehrkernprozessor-System ist in der Branche solide etabliert, erfüllen aber nicht mehr die notwendigen Vorhersagbarkeitskriterien für Steuerungsprogramme.

Bild 1: Der Trend zum Mehrkernprozessor-System ist in der Branche solide etabliert, erfüllt aber nicht mehr die notwendigen Vorhersagbarkeitskriterien für Steuerungsprogramme. Lynx

Augenblicklich ist die Robotik an einem sehr spannenden Punkt angelangt, denn es besteht die echte Chance, gewisse Abläufe in der Fabrik zu revolutionieren und neue „as a service“-Einnahmequellen in Form einer Dienstleistung zu generieren. Die traditionelle industrielle Robotertechnik mit Branchenführern wie Mitsubishi, ABB Robotics, Omron und Fanuc muss sich dem neuen Paradigma anpassen, da sie sowohl vor neuen Möglichkeiten als auch neuem Wettbewerb gegenübersteht. Die adressierten diversen zusätzlichen Use Cases erfordern erhöhte Mobilität, neue Sensortypen und Preisklassen. Ein neues Maß an Geschicklichkeit ist zu beobachten, mit der Roboter mit empfindlichen oder unförmigen Objekten umgehen. Es wird ein Tag kommen, an dem Roboter schließlich alle fünf Sinne bedienen können.

Der Beitrag wird zeigen, dass zum neu entstehenden Roboterparadigma konsolidierte multifunktionale Designs gehören, die sich einen heterogenen Multicore-Chip teilen und natürlich vernetzt sind. Ferner geht es um die Auswirkungen dessen, speziell auf das Software-Design dieser Roboter.

Cobots für den Post-Corona-Arbeitsplatz

Das Auftauchen von Cobots (kollaborative Roboter), die mit Menschen im selben Raum interagieren oder in nächster Nähe sicher arbeiten sollen, ist eine bedeutende Entwicklung. Cobots stehen in deutlichem Kontrast zu herkömmlichen Industrierobotern, die autonom arbeiten bei gewährleisteter Sicherheit durch Trennung von menschlichem Kontakt. Es handelt sich derzeit um einen sehr kleinen Teil des gesamten Robotikmarkts, jedoch um einen Bereich, von dem eine Anzahl anerkannter Analysten glauben, dass er in den nächsten fünf Jahren schnell wachsen wird, und zwar für Anwendungen in der Fertigung, dem Gesundheitswesen und im Einzelhandel.

Die Corona-Pandemie beschleunigt diesen Trend, da sie die Akzeptanz gegenüber verstärkter digitaler Transformation und Automation erhöht. In Umgebungen, in denen das Einhalten von zwei Metern Abstand zwischen den Menschen schwierig oder unglaublich ineffizient ist, wird Cobot-Technologie zuerst zum Einsatz kommen. Große Kaufhäuser wie Walmart nutzen Roboter bereits zur Fußbodenreinigung ihrer Filialen. Zunehmen wird der Einsatz übergroßer Roombas zum Putzen in Schulen, Firmen und Krankenhäusern. Angesichts der vorhergesagten kurzfristigen Verlangsamung im Rennen um selbstfahrende Fahrzeuge dürften viele Technologieschmieden in diesem Bereich hin zu diesen neuen Use Cases abschwenken, was spannende Spitzentechnologie in die Robotik einbringt.

Da Cobots in der Nähe von Menschen agieren, müssen sie ihre Aufgaben zu jeder Zeit deterministisch ausführen. Die Sicherheit eines neben einem Cobot arbeitenden Menschen ist von allergrößter Bedeutung. Es müssen Sicherheitszertifizierungen und Prozesse definiert und strikt eingehalten werden, wenn dieser Markt sich erfolgreich formieren soll. In diesem Bereich liegt reichlich Fokus auf künstliche Intelligenz (KI), um die Anwendererfahrung mit diesem Maschinentyp zu verbessern. Der Wunsch, die Lebensdauer dieser Plattformen über einen langen Zeitraum zu erhalten, bedeutet, dass ein sicheres Verfahren für Software-Updates notwendig ist, die diesen Plattformen neue Fähigkeiten ermöglicht.

Bei einigen der größeren Plattformen sind auch Schritte in Richtung mehr Modularität zu sehen, um im Laufe der Zeit auch Hardware-Upgrades zu ermöglichen. Die Hersteller der Cobot-Hardware möchten sich nicht an einen bestimmten Hardware-Anbieter gebunden fühlen, vor allem nicht auf einem so dynamischen Gebiet wie der KI, auf dem es in den kommenden Jahren zu vielen Akquisitionen, Unternehmensauflösungen und Veränderungen im Leistungsführerschaft-Ranking kommen wird.

Konsolidierung

Bild 2: Aus Softwareperspektive muss ein vernetztes System dafür ausgelegt sein, nach dem Booten nicht umkonfigurierbar zu sein. Ein System mit Separation Kernel kann diese Anforderungen erfüllen.

Bild 2: Aus Softwareperspektive muss ein vernetztes System dafür ausgelegt sein, nach dem Booten nicht umkonfigurierbar zu sein. Ein System mit Separation Kernel kann diese Anforderungen erfüllen. Lynx

Ein zentraler Aspekt der Cobot-Entwicklung ist also die Konsolidierung der Schnittstelle zwischen Informationstechnologie (IT) und operativer Technologie (OT). Wie lassen sich die Konfigurationsanweisungen zu den Roboteraufgaben (IT) mit dem, was in Echtzeit in der Fabrik passiert (OT), verbinden – vor allem den schnellen und unberechenbaren Handlungen von Menschen? In Fabrikumgebungen ist ein vergleichsweise langsames Veränderungstempo verständlich, da dort der Fokus auf Zuverlässigkeit gerichtet ist, auf möglichst lange aktive Betriebszeiten, wenig Unfälle, wenig Ausschuss, etc. Bei OT-Technologie handelt es sich daher um separate Netzwerke, die auf der Ebene der Hauptkonsole mit den IT-Netzwerken verbunden sind. Die Absicht ist, diese Fusion der IT- und der OT-Welt in die Fabrikhalle zu verschieben, so dass die Maschinen fundiertere Entscheidungen schneller treffen können.

Doch dieser Herausforderung gilt es innerhalb eines kommerziell attraktiven Kosten-, Leistungs- und Größenrahmens zu begegnen. Das bedeutet, mehrere Systeme auf einem einzigen konsolidierten Board zusammenzuschrumpfen (und in immer mehr Fällen in einem einzigen heterogenen Multicore-Chip). Diese Systeme müssen funktionsreiche Betriebssysteme wie Linux und Windows ausführen, gleichzeitig aber das Echtzeitverhalten der „muss-immer-auf-diese-Art-reagieren“-Elemente auf der Plattform garantieren. Dies wird beschrieben als System mit gemischter Kritikalität. Anwendungen sind zu unterteilen, um sicherzustellen, dass bestimmte Applikationen nicht zum Ausfall anderer Systemelemente führen.

Echtzeitbetriebssysteme mit Einkern- und Mehrkernprozessoren

Echtzeitbetriebssysteme auf der Basis eines Einkernprozessors (SCP) sind in der Branche wohlbekannt. Es wurde ein Echtzeit-Systementwicklungsprozess eingeführt, der auf der Annahme einer konstanten Worst-Case Execution Time (WCET) beruht. Diese besagt, dass das gemessene schlimmstmögliche Laufzeitverhalten einer Software-Aufgabe, wenn allein auf einem einzelnen Kern durchgeführt, gleichbleibt, wenn diese Aufgabe zusammen mit anderen Aufgaben läuft. Diese Grundannahme bildet die Grundlage für die Schedulability Analysis (Analyse des Systemverhaltens), die feststellt, dass eine Ablaufterminierung gefunden werden kann, die alle Aufgaben innerhalb ihrer jeweiligen Fristen beendet.

In der Branche ist der Trend zu Mehrkernprozessor (MCP)-Systemen bereits solide etabliert (Bild 1). Viele dieser Multicore-Systeme wurden mit Blick auf die Anforderungen von IT-Anwendungen an Geschwindigkeit und Effizienz entwickelt und erfüllen nicht immer die Vorhersehbarkeitskriterien für Steuerungssysteme in der Avionik, Automobilindustrie, Industrieautomation, etc. Während die Annahme einer konstanten WCET für Single-Core-Chips korrekt ist, trifft sie wegen Core-übergreifender Interferenzen beim Zugriff auf geteilte Ressourcen nicht bei derzeitigen Multicore-Chips zu. Interferenzen zwischen Cores können Spitzenauslastungen (Spikes) im Worst-Case-Laufzeitverhalten um mehr als das Sechsfache gegenüber einem Einzelkern verursachen.

Hierauf konzentriert sich Lynx und stellt einen sicheren Hypervisor bereit, der Anwendungen sicher partitionieren und isolieren kann, gleichzeitig aber eine Reaktion im Mikrosekundenbereich auf zeitkritische Ereignisse garantiert.

Vernetzte Systeme

Hinzu kommt, dass Cobots notwendigerweise vernetzt sein müssen. Nicht nur, um Sensordaten zu teilen und Anweisungen zu erhalten, auch für regelmäßige Sicherheits- und andere Updates. Ein Sicherheitsangriff beeinträchtigt ja nicht nur das System selbst, sondern potenziell jedes Gerät, auf das über die betreffende Netzwerkverbindung zugegriffen werden kann. Sicherheit muss von Anfang an miteindesignt sein anstatt in Nachhinein, und viele Angriffe haben gezeigt, dass ein komplexes System immer nur so stark ist wie sein schwächstes Glied. Vor allem industrielle Systeme haben eine lange Lebenszeit und sind manchmal über zehn Jahre oder länger im Einsatz. Der Systemarchitekt muss beim Designen bedenken, dass über einen solchen Zeitraum kein System zu 100 Prozent sicher zu halten ist. Es können zum Beispiel inzwischen neue Bedrohungen auftauchen, Änderungen am System selbst anfallen, oder aber an den verbundenen Systemen, was sich dann sicherheitsgefährdend auswirkt. Stattdessen bedarf es der Früherkennung einer Systembeeinträchtigung, verbunden mit einem Weg, es zu seinem letzten bekannten guten Zustand wiederherzustellen. Und, da es sich um keine statische Umgebung handelt, muss das System neue Software datensicher herunterladen können, um die Hindernisse gegen Angriffe hochzuhalten oder tatsächlich zu erhöhen. Aus Softwareperspektive muss das System dafür ausgelegt sein zu gewährleisten, dass es sich nach dem Booten nicht umkonfigurieren lässt und dass keine Anwendung aus Zufall (oder böser Absicht) in der Lage ist, einen Ausfall des Roboters zu verursachen.

Ein Lynx-System mit einem Separation Kernel kann diese Anforderungen erfüllen. Die Laufzeitarchitektur ist in Bild 2 dargestellt. In den meisten Implementierungen laufen zwei Plattform-Kernel:

  • Der Separation Kernel, der die physikalische Hardware steuert.
  • Der OS-Kernel, der die Gastanwendungen hostet.

Dieses Konzept führt eine zusätzliche Abstraktionsschicht ein. Zum Vergleich: In typischen OS-Designs ist die Hardwaresteuerung mit dem OS-Kernel integriert. Hier ist der Separation Kernel die einzige Software mit Zugriff auf die physikalische Hardware; die Anwendungskernel haben keinen Zugang zur echten Hardware und können lediglich „abgebildete Ressourcen“ (mapped resources) verwalten.

Bei diesem softwaregestützten Hardware-Partitionierungs-Modell, wie es Lynx bezeichnet, sind alle Partitionsgrenzen von Anwendungsräumen ausschließlich hardwaregestützt, nach einem von einem Architekten bewusst gestalteten und formal beschriebenen Modell. Verletzt in diesem Modell eine Applikation eine Partitionsgrenze, bekommt zunächst die Hardware die Verletzung mit und fragt dann beim Separation Kernel Hypervisor Software-Unterstützung an, um den Ausnahmefall zu managen.

Edge Computing

Den erörterten Entwicklungen liegt ein Trend hin zur Implementierung von Edge-Computing-Konzepten in Cobots zugrunde. Edge Computing bezieht sich auf die Verlagerung der Intelligenz, der Informationsverarbeitung, zurück dorthin, wo Daten entstehen. Einfach definiert ist die Edge das erste Gerät auf dem Weg der Daten von ihrem Enstehungsort zurück ins Zentrum des Netzwerks, in dem dann multiple Datenströme verarbeitet und Erkenntnisse aus diesen Daten abgeleitet werden.

Ein Cobot verkörpert genau das. Aus Latenz-, Netzwerkverfügbarkeits- und Datenschutzgründen nutzen Cobots üblicherweise lokal am Arbeitsplatz oder auf dem Firmengelände verfügbare Computing-Ressourcen, keine Rechenressourcen aus der Cloud. Dies erfolgreich in einem Kontext umzusetzen, in dem die Maschinen Seite an Seite mit und rund um Menschen herum arbeiten und potenziell Aufgaben mit hohen Sicherheitsrisiken verrichten, impliziert ein Cobot-Design, das funktions- und datensicher (safe & secure) ist. Der Beitrag zeigte diverse Kriterien auf, die hierbei zu berücksichtigen sind. Die kommerzielle Bereitstellung von Cobot-Designs an Corona-sensiblen Arbeitsstätten erfordert konsolidierte, vernetzte Plattformen, die auf Edge-Computing-Konzepten aufbauen.