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

IIoT und Industrie 4.0 sind allgegenwärtige Themen auf den heutigen Industriemessen und in Blogbeiträgen. Viele Produkte versprechen, Ihnen bei der vertikalen Integration von Produktionsabläufen und Daten sowie Unternehmenssoftware wie ERP zu helfen. Aber in der Regel gibt es auch einen Haken: Entweder erhalten Sie sehr komplexe Produkte mit einem ähnlich schockierenden Preis – oder trotz des Versprechens des IIoT, eine vollständige herstellerübergreifende Interoperabilität zu gewährleisten, werden Sie an einen bestimmten Anbieter gebunden, insbesondere wenn Sie Softwarelösungen in Betracht ziehen, die von Anbietern von Produktionsmaschinen 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 organisch gewachsen und daher von Natur aus komplex. Sie basiert auf einem älteren ERP-System, das durch benutzerdefinierte PHP-Webanwendungen und Schnittstellen zu anderen Softwareprodukten (z. B. CAD, CAM wie Lasernesting-Software usw.) und Kundensystemen für den direkten Datenaustausch erweitert wurde. All dies innerhalb einer gemischten Windows/Linux-Serverumgebung und einem fast ausschließlich Windows-basierten Client-Pool in einem Active Directory. 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 Standardschnittstellen (digitale E/A, Profinet, EtherCat, Standard-Ethernet). Gemäß den Spezifikationen des Herstellers ist nur eine Standard-Ethernet-Schnittstelle zur Netzwerkinfrastruktur des Kunden hin offen. Diese Schnittstelle ist mit dem gesamten SPS-System des Maschinenherstellers verbunden und bietet nur sehr eingeschränkten Zugriff auf die Daten und das Steuerungssystem der Maschine. Sie bietet eine OPC-UA-Schnittstelle mit weniger als 10 Datenpunkten, die nur dann ausgefüllt werden, wenn das Werk die Produktionsplanungssoftware des Maschinenherstellers verwendet, die auf der SPS der Maschine läuft. Daher erwies sich diese Schnittstelle für meinen Kunden derzeit als nicht besonders nützlich, allerdings könnte sich die Situation ändern.

Die ersten Schritte

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

Der Kunde entschied sich für das Kommunikationsprotokoll OPC UA, das in heutigen SPSen und Maschinen immer häufiger zum Einsatz kommt. Dieser Standard kann zwar zur Einrichtung einer Echtzeitkommunikation verwendet werden und somit Funktionen ersetzen, die derzeit von industriellen Feldbussystemen implementiert werden, in unserem Szenario sind Echtzeitfähigkeiten jedoch nicht erforderlich. Zwar sind SDKs für die direkte Integration des OPC UA-Stacks in die Anwendung meines Kunden verfügbar, diese sind jedoch in der Regel komplex und widersprechen somit dem Ziel der Komplexitätsreduzierung.

Anstelle einer individuellen Programmierung entscheidet sich der Kunde für eine Integrationsplattform, die über einen vorgefertigten OPC-UA-Konnektor mit einer benutzerfreundlichen Oberfläche verfügt und die Möglichkeit bietet, eine Verbindung zu Backoffice-Systemen wie ERP, CRM, verschiedenen Dokumentenmanagementsystemen oder Datenbanken – lokal und cloudbasiert – herzustellen, und das zu einem angemessenen 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 befindet sich die neue Technologie noch in der Einführungsphase, sodass das Roboterschweißsystem nur in einer Schicht betrieben wird und die Maschine selbst während der Arbeitszeiten nicht ständig in Betrieb ist. Daher können die derzeit erfassten Daten zwar nützlich sein, sich aber für zukünftige Anwendungen oder Vorhersagen als unzuverlässig erweisen. Diese Einschätzung basiert auf den Erfahrungen des Kunden mit Daten, die von anderen Produktionsmaschinen, z. B. Laserschneidmaschinen, erfasst wurden. Bestimmte Faktoren – beispielsweise, ob der Maschinenbediener bei Beendigung eines Produktionszyklus anwesend war, als die Datenerfassung ausgelöst wurde – haben gezeigt, dass selbst scheinbar hochpräzise Daten ein falsches Bild vermitteln 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.

Derzeit kann jedoch nur die Laserquelle angeschlossen werden. Andere Komponenten können nicht integriert werden: Die SPS des Roboters verfügt nur über die OPC Classic-Schnittstelle, und der Übergang zur Unified Architecture ist derzeit noch mit Schwierigkeiten verbunden. 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, Stromverbrauch, …

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 Erfahrungen meines Kunden in der Vergangenheit haben gezeigt, dass nicht alle Maschinen ihre Protokolldateien nach einem Neustart beibehalten. Außerdem melden Maschinenbediener Störungen und Fehler nicht immer genau an ihre Vorgesetzten. Dies kann zu unnötig langen Maschinenstillstandszeiten führen, wenn eine schwerwiegende Störung auftritt. Ob die Maschine an diesem Tag überhaupt in Betrieb war, ist eine wichtige Frage.

Um dem technischen Management des Unternehmens einen einfachen Zugriff zu ermöglichen, werden solche Tagesberichte als PDF-Dateien erstellt und in einer gemeinsamen Dropbox gespeichert, falls ein Supportanruf beim Maschinenhersteller erforderlich wird.

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:

Anschluss an die SPS des Roboters (über digitale E/A, falls nicht anders möglich), um genaue Start-/Stopp-Zeiten der Produktionszyklen zu erhalten.

In Verbindung mit dem Zeiterfassungssystem des Unternehmens lässt sich so besser nachvollziehen, wie viel Zeit die Maschine tatsächlich in der Produktion ist und wie viel Zeit für das Einrichten (Roboterprogrammierung) und/oder Be- und Entladen/Wartung aufgewendet wird.;

Zugriff auf das Kamerasystem: Da es sich beim Laserschweißen um ein anderes Schweißverfahren handelt, müssen die Kunden meines Auftraggebers diese Produktionsmethode zertifizieren, bevor echte Produkte geliefert werden können. Solche Prozesse lassen sich viel einfacher realisieren, wenn eine vollständige Dokumentation des Schweißprozesses kontinuierlich und automatisch bereitgestellt 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 in einem Forschungs- und Entwicklungsinstitut für Hochleistungslaseranwendungen (wo er Erfahrungen in den Bereichen Lasertechnologie, FEM-Simulationen, Industrierobotik, SPS-Programmierung und industrielle Feldbussysteme sammelte) und verfügt über mehr als 10 Jahre Erfahrung in der allgemeinen IT mit Schwerpunkt auf Softwareentwicklung in KMU-Umgebungen (hauptsächlich Schnittstellen zwischen verschiedenen Softwareprodukten und Produktionsplanungsanwendungen). Er hat einen Master-Abschluss in Mathematik von der Universität Wien.