Das Referenzarchitekturmodell Rami ist in eine dreidimensionale Architektur gegliedert, welche als Rahmenwerk fungiert und für unterschiedlichste Produktionsanforderungen die Zukunft bilden soll. Dieses Modell soll auch die klassische ein- bis zweidimensionale Automationspyramide ersetzen. Während bei der bekannten Automationspyramide auf jeder Ebene konkrete Produkte, Protokolle oder Aufgabenstellungen problemlos eingefügt werden können, ist das Rami-Modell an vielen Stellen mehr als abstrakt. Hier muss noch intensiv an neuen Definitionen, Standards sowie Produkten gearbeitet werden. Schaut man sich die verschiedenen Schichten des Modells genauer an, entsteht schnell der Eindruck, dass sich die Automationshersteller von den unteren Schichten nach oben arbeiten, während sich die IT entgegengesetzt von oben nach unten bewegt. Von daher ist es nicht verwunderlich, dass die drei Schichten ‚Functional‘, ‚Information‘ und ‚Communication‘ bislang in Punkto Standards sowie Tools am wenigsten Substanz zu bieten haben. Doch denkt man an die Automationspyramide zurück, wird schnell klar, dass zwischen der Automationswelt und IT schon immer die größten Herausforderungen lagen. Das heißt zwei Welten treffen aufeinander – und dieses Problem gilt es zu lösen.
Automationspyramide nicht zeitgemäß
Was bedeutet Industrie 4.0 konkret? Kurz zusammengefasst: Anwender möchten möglichst viele ihrer Prozesse digitalisieren. Und dies auf verschiedenen Ebenen: Betrieb, Beschaffung, Dokumentation, Logistik, Audit Trail, Vertrieb sowie in vielen weiteren Bereichen. Damit dies alles umgesetzt werden kann, müssen im Vorfeld sämtliche Prozessanwendungen erfasst sowie analysiert werden.
Das Fallbeispiel
Digitalisierung ist am einfachsten, wenn ein Unternehmen, ausschließlich ein Produkt herstellt. In diesem Fallbeispiel kann die Automation für genau eine Aufgabe programmiert werden. Dies entspricht einer klassischen Aufgabenstellung jeder SPS-Programmierung. Für die weitere Digitalisierung werden beispielsweise Schnittstellen zur Produktionsplanung, Logistik oder Qualitätssicherung benötigt. Durch die möglichen Kombinationen ergibt sich eine beliebige Komplexität. Ferner hat diese Art von Architektur grundsätzliche Design-Fehler: Durch die teilweise Nachbildung der Automationsprozesse in der Leitebene entsteht an dieser Stelle eine Redundanz. Auf das alte Produktionsverfahren übertragen, wäre dies vergleichbar, wie wenn anstatt Facharbeitern ungelernte Hilfskräfte eingestellt werden würden. Jeder einzelne Arbeitsschritt müsste detailliert vorgegeben und kontrolliert werden. Und die Personen, welche diese Schritte kontrollieren müssen, kommen aus der Planung und Buchhaltung. Es entstünde so zu sagen sehr viel teurer Leerlauf. Bezogen auf die Software-Architektur sowie praktische Umsetzung hat dies hier zwei Auswirkungen: Die Quasi-Nachbildung der Produktionsebene in der Leitebene findet auf einem recht abstrakten Niveau statt. Das Debugging ist enorm schwierig, weil weitestgehend im Blindflug programmiert wird. Dies führt zu hohen Entwicklungskosten. Noch kritischer wird es allerdings im weiteren Lebenszyklus dieser Lösung, da das System so komplex ist und Änderungen über die Jahre immer schwieriger werden. Diese Redundanz kann nur dann beseitigt werden, wenn die Produktionsprozesse ausschliesslich auf der Automationsebene programmiert werden. Die Leitebene legt fest, welche Aufträge bearbeitet und welche Produkte gefertigt werden sollen. Sie erteilt auch die Anforderungen an die Produktionsmittel, Produktionszeiten, Stücklisten, Testprotokolle und vieles mehr. Dies bedeutet auch, dass die Leitebene festlegt, was produziert werden soll – wie es aber produziert werden soll, bestimmt die Maschine. Deshalb wird auf der Produktionsebene ein möglichst objektorientierter Ansatz verfolgt, im Sinne einer Orientierung an der Maschine als mechatronische Einheit. Das heißt die jeweiligen Produktions- und Steuerungseinheiten holen sich die Aufträge von der Leitebene, kommunizieren mit den für die Produktfertigung notwendigen Subsystemen, allozieren diese und liefern ihnen den Link auf die Vorgaben aus der Leitebene. Der Materialbedarf bzw. -verbrauch wird an ein Logistiksystem gemeldet und der Produktionsstatus zurück an die Leitebene. Jedes Objekt beschäftigt sich ausschließlich mit seiner eigenen Aufgabe. Das bedeutet, dass zu jeder Steuerung nicht nur die I/O-Ebene für die klassische Automation programmiert wird, sondern eben auch die Kommunikationsebene für die Einbindung in das I4.0 Netzwerk der Firma. Für jedes anschließend darauf gefertigte Produkt wird möglichst ‚klassisch‘ in IEC61131 auf der I/O-Ebene der Automationssysteme programmiert. Also genau so, wie es bei einer Serienanfertigung eines einzelnen Produktes gemacht wird. Das garantiert eine effiziente Entwicklung, eine unkomplizierte Wartung und einen hohen Freiheitsgrad für zukünftige Erweiterungen. Eine Modularisierung von Produkten ist in den meisten Unternehmen längst Standard. Es ist nun zusätzlich ein Mechanismus gefordert, der das passende SPS Programm für zu fertigende Produkt aktiviert. Die Steuerungseinheit führt Test, Messreihen oder Protokolle selbst aus. Auch Formulare oder Typenschilder werden automatisch erstellt. Sollte eine Arbeitsstation nicht vollautomatisch sein, so ist die Steuerungseinheit in der Lage, Arbeitsanweisungen für einen Arbeiter beispielsweise auf einem lokalen Display anzuzeigen.
Die pragmatische Umsetzung
Die Basis für den Aufbau der Steuerungseinheit bildet der SpiderControl Scada Server. Diese Software ist nahezu für alle Betriebssysteme (Windows Standard, embedded Compact, Linux, embedded Linux, Raspian oder Android) verfügbar und wurde bereits auf aktuelle Geräten vieler namhafter SPS Hersteller portiert, die offene Steuerungen anbieten, wie z.B. Wago PFC, Phoenix PLCNext, Siemens IoT2040, industrielle RapsberryPi oder auch Industrie Router wie z.B. die MRX Serie von Insys. Ist der Scada Server auf die SPS integriert, kann dieser direkt mit der lokalen SPS Applikation oder mit abgesetzten Automationskomponenten kommunizieren. In diesen Scada Server ist die SpiderPLC eingebunden, welche eine einfache Programmierung von Funktionsplan über den Browser ermöglicht. Das Besondere daran: Die Funktionsbausteine führen nicht nur einfache Logik aus, sondern können zusätzlich Funktionen aus externen Scripten der wichtigsten aktuellen Hochsprachen, wie u.a. JavaScript (NodeJS, NodeRED), PHP, Python oder .Net aufrufen. Hierzu wird zusätzlich eine Runtime für die Ausführung der benötigten Script-Sprachen auf der SPS installiert. Diese wird im Hintergrund gestartet und wartet darauf, dass sie eine Anfrage für die Ausführung einer Funktion aus SpiderPLC empfängt. Damit wird es möglich, den SPS Code direkt mit den Daten und Funktionen aus der Leitebene zu verknüpfen. Zur Anbindung an die IT Ebene können die Informatiker den Code zur Kommunikation mit deren Applikationen in der Hochsprache ihrer Wahl zur Verfügung stellen. Dieser Code wird über einen Funktionsbaustein gekapselt und in die Automation eingebunden. Die vorher beschriebene Architektur kann beispielsweise wie folgt umgesetzt werden: Um einen Auftrag an eine Produktionseinheit zu übergeben, kann das MES die notwendigen Informationen dazu z.B. in eine Datenbank schreiben, über ein Rest API im Intranet ablegen, oder es gibt ein Software API zum Zugriff auf die entsprechende MES Software. Der Software Ingenieur, der sich im MES auskennt, hat nun mehrere Möglichkeiten. Er kann ein PHP Script erstellen, welches die entsprechenden Felder aus der Datenbank liest. Oder er liefert ein JavaScript, welches sein Rest API auslesen kann. Oder er hat eine .Net Funktion, welche ein API direkt in seine MES Applikation implementiert. Jetzt kann der SPS Programmierer die vom MES Spezialisten gelieferte Script-Funktion aus einem Funktionsbaustein in der SpiderPLC aufrufen. Damit das Script die passenden Daten aus dem MES finden kann, werden alle notwendigen Parameter aus der SPS auf den Funktionsbaustein übertragen. Dazu muss die SPS angeben, für welches Produktionsmittel sie einen Auftrag abfragen will (‚wer bin ich‘). Das Script wiederum schreibt die Daten dann in den Namespace des Scada Servers. Somit kann man auch größere Datenstrukturen mit einem Aufruf übergeben und auch wieder zurückbekommen. Die SPS weiss nun, was sie als nächstes produzieren soll. Über einen weiteren Funktionsbaustein kann SpiderPLC mit der Produkt-ID ein PHP Script aufrufen, welches aus einer SQL-Datenbank Produktinformationen zu diesem Objekt ausliest. Das Script erteilt Auskunft über Stücklisten, involvierte Subsysteme, Referenzen auf Dokumente, Testprotokolle, etc. und wird von einem Informatiker zur Verfügung gestellt, der mit der Wartung der Produkt-Datenbank vertraut ist. Dieser Informatiker weiss, welche Parameter er von der SPS bekommen muss, damit er den gewünschten Datensatz findet. Den abgefragten Datensatz kann er als Antwort in ein XML Format packen, welches indessen vom Scada Server verstanden und in seinen internen Namespace abgebildet wird. Danach alloziert die SPS die in den Produktionsprozessen involvierte Subsysteme, z.B. ein System welches für die Produktion das notwendige Material aus einem Lager entnimmt sowie für den Weitertransport konfektioniert. Die direkte Kommunikation kann durchaus über ein Feldbus Protokoll erfolgen. Förderlich wäre evtl., wenn die SPS eine Referenz auf die benötigten Datenbank Datensätze an das Subsystem weitergibt. Das Subsystem, das die benötigten Teile auf einen Transportträger konfektioniert, erstellt bei Bedarf einen Datensatz, wie die Teile angeordnet sind. Der Roboter, der dann die Teile vom Transportträger in die CNC Maschine fördert, kann dadurch mit sehr unterschiedlichen Konstellationen umgehen, weil die SpiderPLC ihm mitteilt, welches Teil an welcher Position liegt. Nun werden auf der SPS die für die Fertigung des gewünschten Teiles erforderlichen Programme (in IEC61131) aufgerufen. Diese geben über einen Datenpunkt ein Signal, wann die Sequenz abgeschlossen ist. Somit können die Teile ausgefördert und der Status des Auftrags im MES mutiert werden. Testprotokolle werden zeitgleich an einer anderen Station in Empfang genommen und durchgeführt. Die Messungen werden in Registern der SPS abgelegt und über die SpiderPLC wird ein PHP Script aufgerufen, welches diese Variablen als Parameter übergibt sowie beispielsweise mit der FPDF PHP Library ein PDF Dokument erzeugt. Da die Daten parallel dazu in einer Datenbank abgelegt werden, ist die Produktion jederzeit zurück verfolgbar. Zudem wird stets eine aktuelle Statistik über die Qualität der Produktion geführt, welche Rückschlüsse über den Anlagenzustand und andere produktionsrelevante Parameter erlaubt. Da für diese Aufgaben z.B. oftmals Python verwendet wird, ergibt sich der Übergang zum Machine Learning nahezu von selbst. Python Funktionen können analog über Funktionsbausteine direkt aus SpiderPLC aufgerufen werden.
