Fallstudie: Erste Schritte in Richtung IIoT in einer KMU-Umgebung

Fallstudie: Erste Schritte in Richtung IIoT in einer KMU-Umgebung

IIoT Welt

PDF herunterladen
Original-Artikel
ManufacturingTomorrow
PDF herunterladen
Original-Artikel

IIoT und Industrie 4.0 sind allgegenwärtige Themen auf den heutigen Industriemessen und in Blogbeiträgen. Viele Produkte versprechen, Ihnen zu helfen, eine vertikale Integration von Produktionsfluss und Daten und Unternehmenssoftware wie ERP zu erreichen. Aber in der Regel gibt es auch einen Haken: Entweder Sie bekommen sehr komplexe Produkte mit einem ähnlich schockierenden Preisschild - oder Sie werden trotz des IIoT-Versprechens der vollständigen herstellerübergreifenden Interoperabilität herstellergebunden, insbesondere wenn Sie Softwarelösungen in Betracht ziehen, die von Produktionsmaschinenherstellern in Verbindung mit ihren Geräten verkauft werden.

Für kleinere Unternehmen mit begrenzten Ressourcen und kleinen oder einköpfigen IT-Abteilungen ist dies ein Dilemma. Während solche Unternehmen auf Flexibilität angewiesen sind, um mit größeren Unternehmen konkurrieren zu können, und daher Paradigmen wie Industry 4.0 übernehmen müssen, ist dies in der Regel mit enormen Investitionen und einer Mauer scheinbar unüberwindbarer technischer Komplexität verbunden.

In dieser Fallstudie zeige ich erstens, wie eine Software-Integrationsplattform mit vorgefertigten Konnektoren für die Maschinendatenkommunikation helfen kann, diese Einschränkungen zu überwinden. Und zweitens, was erste praktische Anwendungen für Echtzeit-Maschinendaten in einer kleinen Fabrik sein können, die ihre Reise in Richtung des industriellen Internets der Dinge beginnt.

Über den Kunden und seine Anforderungen

Der Kunde ist ein kleiner Industriezulieferer, der überwiegend Edelstahlblechprodukte mit kleinen Losgrößen und einem komplexen Produktportfolio anbietet.

Um mit anderen Herstellern in diesem Bereich konkurrieren zu können, benötigt das Werk technologischen Fortschritt und eine ständige Weiterentwicklung des Produktionsprozesses. Daher hat der Kunde damit begonnen, modernstes Roboter-Laserschweißen in den Produktionsprozess einzuführen.

Abgesehen vom Prozess selbst ist die Integration einer solchen Roboterschweißlösung in die Produktionsplanung, die Beschaffung der notwendigen Daten für die Kostenkalkulation, die Qualitätskontrolle usw. eine weitere Herausforderung.

Die IT-Umgebung des Kunden

Die IT-Landschaft des Kunden ist eine natürlich gewachsene und daher von Natur aus komplex. Auf ihrer Grundlage verwendet sie ein veraltetes ERP-System, das durch kundenspezifische webbasierte PHP-Anwendungen und Schnittstellen zu anderen Softwareprodukten (z.B. CAD, CAM wie Laserschachtelsoftware, ...) und Kundensystemen für den direkten Datenaustausch erweitert wird. All dies innerhalb einer gemischten Windows/Linux-Serverumgebung und einem fast ausschließlich Windows-basierten Client-Pool in einem Active Directory. Die Dateidienste basieren überwiegend auf Windows-Freigaben und (in geringerem Umfang) auf Dropbox.

Im Allgemeinen besteht die Strategie des Kunden darin, die Komplexität seiner IT-Infrastruktur zu reduzieren, indem er versucht, die Menge der verschiedenen verwendeten Technologien (LAMP-Stacks, AD, Windows, O365, Legacy-Systeme usw.) zu verringern und so die Verwaltbarkeit zu erhöhen und die Wartungskosten des gesamten Ökosystems zu senken.

Die Produktionsumgebung

Produktionsmaschinen haben meist eine inhärent lange Nutzungsdauer. Daher sind nicht alle Maschinen für Industrie-4.0-Anwendungen ausgestattet oder bieten nur sehr eingeschränkte Funktionalität in diesem Bereich. Daher konzentriert sich dieser Artikel ausschließlich auf die Anwendung Roboterschweißen und deren Integrationsbedarf.

Bei der Schweißanlage handelt es sich um eine schlüsselfertige Lösung eines namhaften Herstellers, bestehend aus einer Festkörperlaserquelle, einem Roboter mit Dreh-Schwenktisch, einem Bearbeitungskopf mit Kamerasystem, einer Schutzzelle, die für Hochleistungslaseranwendungen benötigt wird, Steuerungssystemen und Hilfssystemen (Absaugung, Staubabsaugung, Kühlung).

Die Komponenten dieses Systems kommunizieren über eine Vielzahl von industriellen Standardverbindungen (digitale IOs, Profinet, EtherCat, Standard-Ethernet). Nach den Spezifikationen des Herstellers ist nur eine Standard-Ethernet-Schnittstelle zur Netzwerkinfrastruktur des Kunden offen. Diese Schnittstelle ist mit dem gesamten SPS-System des Maschinenherstellers verbunden und bietet nur einen sehr eingeschränkten Zugriff auf das Daten- und Steuerungssystem der Maschine. Es handelt sich um eine OPC-UA-Schnittstelle mit weniger als 10 Datenpunkten, die nur gefüllt werden, wenn die Fabrik die Produktionsplanungssoftware des Maschinenherstellers verwendet, die auf der SPS der Maschine läuft. Daher erwies sich diese Schnittstelle für meinen Kunden jetzt als nicht allzu nützlich, aber die Situation könnte sich ändern.

Die ersten Schritte

Als erster Schritt war es das Ziel, Daten direkt von den Komponenten der Maschine zu erfassen.

Der Kunde entschied sich für das Kommunikationsprotokoll OPC UA, das in den heutigen SPSen und Maschinen immer häufiger zum Einsatz kommt. Während dieser Standard für den Aufbau einer Echtzeitkommunikation genutzt werden kann und damit Funktionen ersetzt, die derzeit von industriellen Feldbus-Systemen implementiert werden, sind in unserem Szenario keine Echtzeitfähigkeiten erforderlich. Zwar gibt es SDKs für die direkte Integration des OPC-UA-Stacks in die Anwendung meines Kunden, doch sind diese in der Regel sehr aufwändig und widersprechen damit dem Ziel der Komplexitätsreduzierung.

Anstelle einer individuellen Programmierung entscheidet sich der Kunde also für eine Integrationsplattform, die über einen vorgefertigten OPC-UA-Konnektor mit einer einfach zu bedienenden Schnittstelle und einer Möglichkeit zur Verbindung mit Back-Office-Systemen wie ERP, CRM, verschiedenen Dokumentenverwaltungssystemen oder Datenbanken verfügt - lokal und Cloud-basiert, und das zu einem vernünftigen Preis.

Die direkte Steuerung dieser Systeme über die Integrationsplattform ist kein Ziel, da sie möglicherweise das für die Maschinensicherheit notwendige Single-Point-of-Control-Prinzip verletzen könnte.

Häufigkeit der Datenabfrage

In dieser Fabrik durchläuft die neue Technologie gerade den Anpassungsprozess, so dass das Roboterschweißsystem nur im Einschichtbetrieb läuft und die Maschine auch während der Arbeitszeit nicht ständig in Betrieb ist. Daher können die zu diesem Zeitpunkt erfassten Daten zwar nützlich sein, sich aber auch als unzuverlässig für die zukünftige Nutzung oder für Vorhersagezwecke erweisen. Dies basiert auf den Erfahrungen des Kunden mit Daten, die von anderen Produktionsmaschinen, z. B. Laserschneidmaschinen, gewonnen wurden. Bestimmte Faktoren - ob der Maschinenbediener am Ende eines Produktionszyklus anwesend war, wann die Datenerfassung ausgelöst wurde - haben bewiesen, dass selbst scheinbar hochgenaue Daten ein falsches Bild zeichnen können und dass eine feine Granularität nicht immer notwendig ist, um die Effizienz des Produktionsprozesses zu beurteilen.

Daher wird derzeit eine eher niedrige Polling-Frequenz von 30 Sekunden zur Datenerfassung verwendet.

In diesem ersten Schritt möchte der Kunde Daten aus diesen 3 Hauptkomponenten abfragen:

die Laserquelle,

die SPS des Roboters,

das Kamerasystem.

Im Moment kann jedoch nur die Laserquelle angeschlossen werden. Andere Komponenten sind nicht integrierbar: Die SPS des Roboters verfügt nur über die OPC-Classic-Schnittstelle, und der Übergang zur Unified Architecture ist im Moment eine Herausforderung; und das Kamerasystem ist an die SPS der gesamten Maschine gebunden und scheint für externe Clients nicht zugänglich zu sein.

OPC UA für die Laserquelle

Damit bleibt die Laserquelle übrig. Glücklicherweise ist dieses System mit einer hochmodernen Steuerung ausgestattet, die eine ausgeklügelte OPC-UA-Schnittstelle mit mehreren Zugriffsebenen enthält: anonymer Zugriff mit eingeschränkten Lesemöglichkeiten, Nur-Lesen, Lesen-und-Schreiben. Wie bereits erwähnt, kam ein Read-and-Write-Zugriff aus Gründen der Maschinensicherheit nicht in Frage. Daher wurde der Nur-Lese-Zugriff gewählt.

Diese Schnittstelle bietet eine Fülle von Daten:

Gesamtzustand des Lasersystems

Betriebszeiten, verbrauchte Leistung, ...

Fehler- und Wartungsmeldungen

Mit der Integrationsplattform entwickelte der Kunde einen Windows-Dienst in C#, um die Daten periodisch abzufragen und in mehreren SQL-Datenbanktabellen für die zukünftige Verwendung zusammenzustellen. Die Tabellen können Informationen wie allgemeine Daten, Gerätenutzung, Tabellen für Wartungs-/Fehlermeldungen, die von der Laserquelle erzeugt werden, enthalten.

Eine große Frage: Wie nutzt man diese Maschinendaten

Die erste wertvolle Erkenntnis ist die Zusammenstellung von Maschinenprotokollmeldungen. Die Erfahrung meines Kunden in der Vergangenheit war, dass nicht alle Maschinen ihre Logdateien über Neustarts hinweg aufbewahren. Außerdem melden die Maschinenbediener Störungen und Fehler nicht immer genau an ihre Vorgesetzten. Dies kann dazu führen, dass bei einer schwerwiegenden Störung die Maschine länger als nötig stillsteht. Ob die Maschine an diesem Tag überhaupt gelaufen ist - ist eine wichtige Frage.

Für den einfachen Zugriff durch die technische Leitung des Unternehmens werden solche täglichen Berichte als PDF-Dateien generiert und in einer gemeinsamen Dropbox gespeichert, falls ein Support-Anruf an den Maschinenhersteller geöffnet werden muss.

Natürlich ist dies derzeit nur eine sehr begrenzte Anwendung der immensen Leistungsfähigkeit des OPC UA Connectors. Die nächsten Schritte, die der Kunde entwickelt, sind:

Verbindung mit der SPS des Roboters (über digitale IOs, falls nicht anders möglich), um eine genaue Start-/Stopp-Taktung der Produktionszyklen zu erhalten.

In Verbindung mit dem Zeiterfassungssystem des Unternehmens ermöglicht dies ein besseres Verständnis dafür, wie viel Zeit die Maschine tatsächlich in der Produktion ist und wie viel Zeit für das Teachen (Roboterprogrammierung) und/oder das Be-/Entladen/Wartung verwendet wird;

Zugang zum Kamerasystem: Da Laserschweißen ein anderes Schweißverfahren ist, müssen die Kunden meines Kunden diese Produktionsmethode zertifizieren lassen, bevor echte Produkte geliefert werden. Solche Prozesse lassen sich viel leichter erreichen, wenn eine vollständige Dokumentation des Schweißprozesses ständig und automatisch geliefert werden kann.

Darüber hinaus steht mit der geplanten Reduzierung der Komplexität und der in Anspruch genommenen Dienstleistungen ein Wechsel von Dropbox-Shared zu OneDrive unmittelbar bevor, sobald dies bei allen betroffenen Kunden eingeführt ist. Der Kunde ist auch an einer möglichen Datenanalyse für die vorausschauende Wartung interessiert.

Schlussfolgerung

Wie oben geschrieben, befindet sich dieses Projekt in der Anfangsphase und ist noch weit davon entfernt, eine voll funktionsfähige IIoT-Lösung zu sein. Die Entscheidung für eine Integrationsplattform mit vorgefertigten Konnektoren, anstatt die gesamte Integration zu programmieren, hat mir geholfen, da ich mich nicht in die Details eines weiteren Verbindungsstacks (wie OPC UA oder die Dropbox-API) einarbeiten musste. Und für meinen Kunden bot es einen zentralisierten Kommunikationsstack für zukünftige Anwendungen.

Über Richard Majer

Richard Majer, Gründer von flupo Systemtechnik e.U., spezialisiert auf industrielle IT und Automatisierungstechnik für KMU. Bevor er sein eigenes Unternehmen gründete, arbeitete Richard Majer in einem F&E-Institut für Hochleistungslaseranwendungen (er sammelte Erfahrungen in der Lasertechnik, FEM-Simulationen, Industrierobotik, SPS-Programmierung, industrielle Feldbussysteme) und hat mehr als 10 Jahre Erfahrung in der allgemeinen IT mit Schwerpunkt auf Softwareentwicklung im KMU-Umfeld (hauptsächlich Schnittstellen zwischen verschiedenen Softwareprodukten und Produktionsplanungsanwendungen). Er hat einen Master-Abschluss in Mathematik von der Universität Wien.