Autor: Robert Schachner, RST Industrie Automation<\/p>\n
Die Umsetzung von Produktionsanlagen, wie sie mit dem Referenzarchitekturmodell Industrie 4.0 (RAMI 4.0) oder der parallelen IoT Entwicklung mit ihrem Industrial Internet Reference Architecture (IIRA) beschrieben werden, ist mittlerweile in der Realit\u00e4t angekommen. Die Firmen beziehungsweise Betreiber sind bereit, ihre Produktionsanlagen zu digitalisieren.<\/strong><\/p>\n Doch wer kann den Betreiber auf diesen Weg begleiten? Zuerst denkt man nat\u00fcrlich an Firmen wie IBM mit ihrem Watson oder Siemens mit Mindsphere. Die Big Player sind vor allem im Office-Floor vonn\u00f6ten. Der wichtigste Player ist jedoch der Betreiber selbst mit seinem Servicepersonal und der IT-Abteilung. Nur sie sind in der Lage, die Anforderungen und Prozesse zu definieren. Und es braucht mittelst\u00e4ndische Spezialfirmen als dritten Player im Verbund, die in der Lage sind, diese Anforderungen und Prozesse in Zusammenarbeit mit dem Betreiber Maschine f\u00fcr Maschine, Service f\u00fcr Service auf dem Shop-Floor zu integrieren. (siehe\u00a0PDF<\/a>, Abb. 1)<\/p>\n Ziel dieser Norm (DIN SPEC 91345) ist ein gemeinsames Verst\u00e4ndnis der grundlegenden Begriffe ebenso wie ein Konsens \u00fcber Referenzmodelle und -architekturen. F\u00fcr eine erfolgreiche Umsetzung ist es unumg\u00e4nglich, sich mit den wichtigsten Kriterien der in der Norm enthaltenen Umsetzungsempfehlungen vertraut zu machen. (siehe\u00a0PDF<\/a>, Abb. 2)<\/p>\n Es ist wichtig zu sehen, dass ein modernes Produktionssystem nicht mehr aus einer Automatisierungspyramide besteht, sondern aus zwei Kommunikationsebenen, die entsprechende Konnektivit\u00e4t bzw. ein gemeinsames semantisches Modell bilden. Die dreidimensionale Darstellung aller relevanten Ebenen ist hier f\u00fcr ein Grundsatzverst\u00e4ndnis ebenso wichtig:<\/p>\n –\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Layer-Ebene mit der detaillierten Schichtung vom Asset bis zum Business Layer<\/p>\n –\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Lifecycle und Value Stream mit der Darstellung der Lebensl\u00e4ufe von Assets und Produkten<\/p>\n –\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Hierarchie-Level, der eine funktionale Einordnung von Elementen erm\u00f6glicht<\/p>\n (siehe\u00a0PDF<\/a>, Abb. 3)<\/p>\n F\u00fcr die Integration der Assets bzw. Maschinen wurde in der Norm eine sogenannte „Industrie 4.0 Komponente“ definiert. Die Grafik veranschaulicht dazu sehr eindr\u00fccklich wie das zu geschehen hat. (siehe\u00a0PDF<\/a>, Abb. 4)<\/p>\n Gegenstand meint hier Maschinensteuerungen, Antriebe, aber auch manuelle Arbeitspl\u00e4tze, die in eine einheitliche Service-Schale \u2013 die Verwaltungsschale – integriert werden.<\/p>\n Klassisch erfolgt die Steuerung von Maschinen mit SPS-Steuerungen. Sie sind Teil der Maschinen, die man aufgrund des Aufwands und des Gew\u00e4hrleistungsverlustes nicht \u00e4ndern sollte. Hier werden Prozessdaten zyklisch eingelesen, verarbeitet und wieder ausgegeben. Wichtig sind hier nur die neuesten Informationen, die ein zeitnahes Abbild der Realit\u00e4t vermitteln k\u00f6nnen. Die Datenmenge reduziert sich hier ganz einfach durch \u00dcberschreiben \u00e4lterer Daten. (siehe\u00a0PDF<\/a>, Abb. 5)<\/p>\n Aufgrund einer fehlenden Persistenz ist das Modell beim Handling von Fehler- oder Statuswerten ungeeignet. F\u00fcr die persistente Datenkommunikation eignet sich viel mehr die serialisierte Kommunikation von Daten und Kommandos (Messages) \u00fcber Broker, die dann deren Verteilung organisieren. Die Daten bleiben dann so lange im System, bis sie von einem Client abgeholt werden. Dieses Verfahren bildet bei den meisten Middleware-Technologien die alleinige Kommunikationsbasis. Das synchrone Prozessdatenmodell wird meist nicht unterst\u00fctzt, obwohl es f\u00fcr die zyklische Verarbeitung unumg\u00e4nglich ist. (siehe\u00a0PDF<\/a>, Abb. 6)<\/p>\n Jedoch ist diese Form der Kommunikation nicht etwa langsam. In der Automatisierung \u00fcbliche Steuerungsprogrammierung \u00fcber „State Machines“ sind mit Messages schneller und effizienter umsetzbar.<\/p>\n Informationen werden nun durch Adressierung an dedizierte Clients versendet. Alternativ dazu k\u00f6nnen Botschaften an sogenannte Topics (semantisch adressierte, virtuelle Kan\u00e4le) versandt werden (publish). Clients k\u00f6nnen sich nun mit Topics verbinden (subscribe) und erhalten so die Nachrichten des Publishers zugestellt. M\u00e4chtige Wildcard-Funktionen erleichtern dabei die Selektion der passenden Topics.<\/p>\n Publish\/Subscribe ist die einzige Kommunikationsform, die keine direkte Kopplung zwischen Sender und Empf\u00e4nger aufweist. Sie ist die wichtigste Neuerung in der Kommunikation, da ohne diesen Mechanismus eine Cloud nicht realisierbar ist.<\/p>\n Und es gibt Quality-of-Service Funktionen, wie zum Beispiel „Last Will“, eine vorher definierbare Message, die verteilt wird, wenn ein Client vom Netz verschwindet.<\/p>\n Ein entscheidender Faktor bei der Auswahl einer Middleware ist eine Multibroker-Architektur. Die Clients k\u00f6nnen so \u00fcber einen eigenen Broker lokal viel schneller und unabh\u00e4ngig von der Vernetzung kommunizieren. System\u00fcbergreifend werden Nachrichten dann nur noch \u00fcber die Broker verteilt. Die Kommunikation wird redundant, und die Industrie 4.0-Komponenten bleiben auch bei Ausfall des Netzwerks funktionsf\u00e4hig. (siehe\u00a0PDF<\/a>, Abb. 7)<\/p>\n Obwohl die Shop-Floor-Ebene in der Regel nicht mit dem Internet verbunden ist, sollte man trotzdem auf eine ad\u00e4quate Absicherung mit Zertifikaten zur Authentifizierung und eine Verschl\u00fcsselung der \u00fcbertragenen Daten nicht verzichten. Empfohlen ist auch eine rollenspezifische Einschr\u00e4nkung der Kommunikation.<\/p>\n Services sind Dienstprogramme, die Informationen aus einer oder mehrerer Maschinen b\u00fcndeln und weiterverarbeiten. In einer Industrie 4.0-Komponente bilden Services die Verwaltungsschale und kommunizieren \u00fcber den Resource Manager mit \u00fcbergeordneten Services. Sie konzentrieren und koordinieren die Informationen Maschinen \u00fcbergreifend.<\/p>\n Ein wichtiges Beispiel f\u00fcr Services in einer Produktionsanlage ist das Fehlermanagement. Ein Service in der Verwaltungsschale erkennt aus den ihm vorliegenden Informationen den Fehlerzustand und „publisht“ diesen an ein fest definiertes Topic. Wird nun aus den vorliegenden Informationen erkannt, dass in K\u00fcrze ein Fehler entstehen wird, so nennt man dies auch „Predictive Maintenance“. \u00dcbergeordnete Services abonnieren diese Meldungen und speichern sie in eine Datenbank oder informieren den Service-Techniker. (siehe\u00a0PDF<\/a>, Abb. 8)<\/p>\n Zur Umsetzung werden alle Informationen aus den Qualit\u00e4tsmanagement-Prozessen, von Servicetechnikern, Mitarbeitern an der Produktionsstra\u00dfe und der IT-Abteilung in Form von User Stories und Use Cases zusammengef\u00fchrt. Daraus werden dann Spezifikationen abgeleitet, die dann in der Folge in \u00fcberschaubaren Schritten umgesetzt werden.<\/p>\n Zur Implementierung werden bei den bestehenden Steuerungen die Daten auf unterschiedlichsten Wegen versucht auszulesen. Dazu sollte die Middleware bereits Schnittstellen f\u00fcr Feldbusse bereitstellen. Da auf der bestehenden Maschinensteuerung keine Ver\u00e4nderungen erfolgen d\u00fcrfen oder k\u00f6nnen, werden die Daten nun in einem digitalen Zwilling, also in ein synchrones Prozessdatenmodell, gespiegelt. Auf dieser Ebene kann dann die Weiterverarbeitung der Daten und deren Verdichtung \u00fcber die Services der Verwaltungsschale erfolgen. (siehe\u00a0PDF<\/a>, Abb. 9)<\/p>\n Werden Maschinen neu entwickelt, kann das gleiche Modell verwendet werden. Anstelle der SPS-Steuerung wird ein Feldbus adaptiert, der die I\/O-Signale erfasst und dem Prozessdatenmodell \u00fcbergibt. Jetzt kann die Steuerungssoftware die Abl\u00e4ufe koordinieren w\u00e4hrend die \u00fcbergeordneten Services der Verwaltungsschale die Daten aufbereiten.<\/p>\n Neben unterschiedlichen Werkzeugen f\u00fcr die Steuerungs- und Service-Entwicklung muss die Middleware aber auch Werkzeuge f\u00fcr Test und Simulation bereitstellen. Denn die vor-Ort-Programmierung, die bis zur Abwesenheit von Fehlern die Produktion lahmlegt, ist nicht mehr m\u00f6glich. Continous Integration mit automatischen Rollout sollte man hier anstreben.<\/p>\n Auf diese Weise werden nun alle Maschinen in der Fertigung in eine einheitliche Service-Landschaft \u00fcberf\u00fchrt, in der alle Assets einheitlich verarbeitet und koordiniert werden k\u00f6nnen. In vielen F\u00e4llen muss zus\u00e4tzlich zu der Message-basierten Kommunikation zwischen den Maschinen und deren synchronen Steuerungen auch ein synchrones Netzwerk etabliert werden. Dar\u00fcber werden, wenn n\u00f6tig, synchronisierte Echtzeit-Daten \u00fcbertragen. (siehe\u00a0PDF<\/a>, Abb. 10)<\/p>\n Erst jetzt wird auch die Kopplung mit dem \u00fcbergeordneten Office-Floor sinnvoll und m\u00f6glich.<\/p>\n Ein Protokoll-Konverter \u00fcbernimmt dabei die \u00dcbersetzung der Daten zwischen Office- und Shop-Floor. Somit entsteht eine Konnektivit\u00e4t zu beliebigen Endpunkten und damit ein gemeinsames semantisches Modell.<\/p>\n Die erfolgreiche Umsetzung einer digitalisierten Fertigung ist nur m\u00f6glich, wenn Betreiber, Mittelstand und Big Player zusammenarbeiten. Neben den Umsetzungsstrategien sind vor allem auch Migrationsstrategien zu entwickeln. Einseitige oder planlose Umsetzungen, wie sie leider derzeit vorkommen, gef\u00e4hrden solche Projekte bzw. den Betreiber ganz erheblich.<\/p>\n [1] https:\/\/www.zvei.org\/themen\/industrie-40\/das-referenzarchitekturmodell-rami-40-und-die-industrie-40-komponente\/<\/p>\n Dipl.-Ing. (FH) Robert Schachner ist Gesch\u00e4ftsf\u00fchrer der RST Industrie Automation GmbH und technischer Vorstand von Embedded4You e.V. Seit 30 Jahren besch\u00e4ftigt er sich mit Middleware basierten embedded Systemen. Bis heute konnte er mit seinem Team die Effizienz in mehr als 250 verschiedenen Projekten in der Produktion, Maschinensteuerung und Test nachweisen. Zum Thema Middleware engagiert er sich an der VDI\/VDE2657 Richtlinie, h\u00e4lt Informatik Vorlesungen und Schulungen bzw. Consulting bei Kunden.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema IoT\/Industrie 4.0\/ System- und Hardwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema IoT\/Industrie 4.0\/ System- und Hardwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nReferenzarchitekturmodell Industrie 4.0 (RAMI4.0)<\/h2>\n
Kommunikationsmethoden im Shop-Floor<\/h2>\n
Services in der Verwaltungsschale<\/h2>\n
Umsetzung<\/h2>\n
Literatur- und Quellenverzeichnis<\/h2>\n
Autor<\/h2>\n
\nIoT \/ Industrie 4.0 – unsere Trainings & Coachings<\/h2>\n
\nIoT \/ Industrie 4.0\u00a0– Fachwissen<\/h2>\n