Programme, Kommunikationsprototypen und Maschinenintegration – wie Geräte verschiedener Hersteller in Schlesien verbunden werden

Warum Produktionsunternehmen zunehmend Maschinenintegration und individuelle Software suchen

Ein typischer Betrieb in Schlesien hat einen über Jahre gewachsenen Maschinenpark: eine Presse aus den neunziger Jahren, eine neue Verpackungslinie, einen mit einem geförderten Projekt gekauften Roboter, eine Waage mit Etikettendrucker und mehrere Steuerungen verschiedener Marken. Jedes dieser Geräte arbeitet für sich und ist oft die einzige Informationsquelle über den eigenen Betrieb. Produktionsdaten erreichen den Schichtleiter auf Papier, in Excel oder gar nicht.

Wenn die Auftragszahl steigt, Kunden Chargenrückverfolgung erwarten und die Buchhaltung die realen Produktkosten kennen will, reicht manuelles Abtippen nicht mehr aus. Dann wird ein Programm gebraucht, das Maschinen untereinander und mit IT-Systemen verbindet. Fertige Pakete passen selten zu Geräten verschiedener Jahrzehnte und Hersteller, deshalb entsteht Software, die auf den konkreten Maschinenpark zugeschnitten ist.

Unser Kern ist Hardware: Reparaturen von Steuerungen, Antrieben, HMI-Panels, Netzteilen und Kommunikationskarten. Deshalb sind die Programme, die wir schreiben, auf reale Hallenbedingungen ausgelegt: Störungen, lange Kabel, alte serielle Schnittstellen und fehlende Dokumentation. Wir kennen diese Geräte bis auf die Leiterplatte, was die Diagnose beschleunigt, wenn die Kommunikation einfach nicht startet.

Mit welchen Problemen Unternehmen kämpfen – die häufigsten Hürden der Integration

Gespräche mit Instandhaltungsabteilungen und Produktionsleitern sowie Branchenveröffentlichungen zeigen, dass die Hürden seit Jahren dieselben sind. Die folgende Tabelle fasst die häufigsten zusammen, zusammen mit unserem Lösungsweg.

Was wir schreiben und bauen – Umfang der Programme und Kommunikationsprototypen

Hinter dem Begriff „Maschinenintegration“ verbergen sich mehrere Arbeitsebenen. In der Praxis verbinden wir sie zu einem Projekt, aber es lohnt sich, sie zu unterscheiden, weil jede andere Kompetenzen und Werkzeuge erfordert.

• SPS-Programme: Logik des Datenaustauschs, Puffer, Quittierungen, Fehlerbehandlung und Wiederherstellung der Kommunikation nach Spannungsausfall,
• Protokolltreiber für Geräte mit serieller Schnittstelle: Waagen, Etikettendrucker, Codeleser, Messgeräte, ältere Steuerungen,
• Middleware auf einem Industrie-PC oder Edge-Gateway, die Daten aus Maschinen liest und weiterleitet,
• Anbindung an SQL-Datenbanken, ERP-, MES- und WMS-Systeme: Aufträge, Zähler, Status, Qualitätsergebnisse,
• Signalaustausch zwischen Maschinen: Bereitschaftsquittierungen, Übergabe von Produkten zwischen Stationen, Zusammenspiel von Roboter, Förderer und Bildverarbeitung,
• Dashboards und Berichte: einfache Panels für den Schichtleiter, Alarme per E-Mail oder SMS, Export nach CSV und XML,
• Teststände und Maschinensimulatoren, mit denen ein Programm geprüft werden kann, ohne die Produktion anzuhalten.

Für größere Projekte mit vollständiger Prozessvisualisierung binden wir unsere Lösungen an übergeordnete Systeme an, die in einem eigenen Artikel zur Maschinenintegration mit SCADA beschrieben sind. Dieser Text konzentriert sich auf die frühere Ebene: wie die Kommunikation selbst entsteht und wie man sie sicher prüft.

Warum man mit einem Prototyp (Proof of Concept) beginnen sollte

Ein Kommunikationsprototyp ist ein kleiner, schnell gebauter Aufbau, der beweist, dass sich Daten einer bestimmten Maschine lesen, verarbeiten und weitergeben lassen. Er ist keine Showversion, sondern die erste Phase des eigentlichen Projekts, die dessen größte Risiken beseitigt.

Ein Prototyp beantwortet Fragen, die sich auf dem Papier nicht klären lassen: Sendet die Maschine Daten tatsächlich so, wie es die Dokumentation sagt, wie oft aktualisiert sie Werte, ist die Verbindung gegenüber Störungen von Frequenzumrichtern robust, erfüllen die Latenzen die Prozessanforderungen und bleibt die Maschinensicherheit unberührt.

1. Gespräch und erste Analyse: Liste der Maschinen, Steuerungsmarken, Datenumfang, Geschäftsziel und Stellen, an denen heute Informationen verloren gehen.
2. Schnittstellenerkundung: Prüfung von Anschlüssen, Protokollen, Adressen und Dokumentation oder, falls diese fehlt, Analyse des Leitungsverkehrs.
3. Aufbau eines Teststands: Nachbildung der Kommunikation auf dem Tisch, mit Maschinensimulation oder einem ausgebauten Gerät.
4. Software-Prototyp: Lesen, Schreiben, Fehlerbehandlung, Ereignisprotokoll und erste Ergebnisse in einer einfachen Ansicht.
5. Versuch an der Maschine in einem vereinbarten Servicefenster, ohne Eingriff in Sicherheitskreise.
6. Auswertung mit dem Kunden und Entscheidung: weiterentwickeln, Ansatz ändern oder in dieser Phase beenden.

So wissen wir, was der Rollout wirklich kostet und wie lange er dauert, bevor der Kunde ein größeres Budget bindet. Das Angebot für das Gesamtprojekt beruht dann auf geprüften Fakten statt auf Annahmen.

Werkzeuge und Technologien – was wir einsetzen

Wir schreiben keine einzelne Technologie vor. Wir wählen Werkzeuge passend zu dem, was beim Kunden bereits läuft, damit die Instandhaltung die Lösung nach dem Projekt selbstständig verstehen und betreiben kann.

Alte Schnittstellen und geschlossene Protokolle – wie wir Maschinen ohne Dokumentation angehen

Die größte Auftragsgruppe sind Maschinen, die über eine serielle Verbindung oder ein eigenes, undokumentiertes Protokoll kommunizieren und deren Hersteller nicht mehr existiert oder das Gerät nicht mehr unterstützt. Eine solche Maschine ist für die Integration nicht verloren.

• wir zeichnen den Verkehr auf der Leitung während des normalen Maschinenbetriebs auf (passives Mitlesen, ohne Einfluss auf den Prozess),
• wir vergleichen Frames mit Bedienhandlungen und Anzeigeänderungen, um Bedeutung von Feldern, Prüfsummen und Markern abzuleiten,
• wir stellen die Kommunikation am Teststand mit eigenem Programm nach und prüfen die Antworten des Geräts,
• erst nach Bestätigung der Korrektheit schließen wir die Lösung dauerhaft an und dokumentieren die Frames,
• ist die Schnittstelle selbst beschädigt, reparieren wir die Kommunikationskarte oder den Transceiver auf Bauteilebene.

Von der Maschine zu ERP und MES – wie Daten durch den Betrieb fließen

Die Kommunikation mit der Maschine allein bringt keinen Nutzen, solange die Daten nicht dort ankommen, wo sie gebraucht werden. Die häufigsten Szenarien sind die automatische Rückmeldung von Stückzahlen an den Fertigungsauftrag, die Übernahme von Prozessparametern aus dem System in die Maschine und die Erfassung von Stillstandszeiten mit Ursache.

• ein Auftrag aus dem ERP geht an die Maschine: Artikelnummer, Menge, Rezeptur oder Bearbeitungsprogramm,
• die Maschine meldet an das ERP zurück: Gut- und Schlechtstücke, Laufzeit, Stillstandszeit, Chargennummer,
• Qualitätsereignisse von Lesern und Kameras werden mit der Auftragsnummer verknüpft und in der Datenbank gespeichert,
• Alarme und Parameterüberschreitungen werden per E-Mail oder SMS an die richtige Person gesendet,
• Energie- und Materialverbrauch wird auftragsbezogen erfasst, sodass sich die realen Produktkosten berechnen lassen.

Wir binden uns über die offiziellen Schnittstellen an die bestehenden Systeme des Kunden an: Datenbanken, APIs, Austauschdateien oder dedizierte Module. Wir gehen nicht von einem Austausch des ERP oder MES aus: Wir arbeiten mit dem, was das Unternehmen bereits hat und täglich nutzt.

Beispielszenarien der Integration für Betriebe in der Region

Die folgenden Szenarien sind typische Aufgaben für Unternehmen unserer Region. Sie zeigen Größenordnung und Charakter der Arbeiten und beschreiben keinen konkreten Kunden.

SPS-Programmierung für die Kommunikation – worauf wir achten

Ein Datenaustauschprogramm in der Steuerung ist eine andere Aufgabe als die Steuerung der Maschine selbst. Es muss robust sein gegenüber Verbindungsverlust, wiederholten Frames, verspäteten Antworten und dem Neustart des Geräts auf der Gegenseite. Im Folgenden die Grundregeln, die wir in jedem Projekt anwenden.

• Kommunikation ist von der Prozesslogik getrennt: Ein Leitungsausfall darf die Maschine nicht stoppen oder ihren sicheren Zustand ändern,
• jeder Austausch hat eine Quittierung und ein Zeitlimit; fehlende Antwort ist ein behandeltes Ereignis und kein undefinierter Zustand,
• externe Daten werden validiert (Bereiche, Typen, Prüfsummen), bevor sie den Maschinenbetrieb beeinflussen,
• Variablen haben lesbare Namen und Beschreibungen, die Signalliste wird als eigene Datei dokumentiert,
• das Programm hat Diagnose: Fehlerzähler, letzte gültige Lesung, Zeitstempel und eine leicht einsehbare Kommunikationsanzeige,
• vor jeder Änderung erstellen wir eine Projektsicherung und übergeben anschließend eine vollständige Version mit Änderungsbeschreibung.

Cybersicherheit und Eigentum am Code – was man von einem Auftragnehmer erwarten sollte

Die Anbindung von Maschinen an das Betriebsnetz erhöht das Risiko, wenn sie ohne Plan erfolgt. Deshalb enthält jedes Projekt grundlegende Schutzprinzipien für Industrienetze im Sinne der IEC 62443.

• Netzwerksegmentierung: Maschinen in einem eigenen Subnetz, Zugriff nur über ein kontrolliertes Gateway,
• kein direktes Exponieren von Steuerungen im Internet; Fernzugriff nur über einen authentifizierten, verschlüsselten Kanal,
• individuelle Konten und minimale Rechte, Änderung der Standardpasswörter der Geräte,
• Sicherungen der SPS-Projekte, Gateway-Konfigurationen und Middleware-Programme,
• Dokumentation von IP-Adressen, Ports und Datenflüssen, damit die IT-Abteilung sie prüfen und freigeben kann.

Nach Projektende erhält der Kunde alle Unterlagen: Quellcode der Programme, Steuerungsprojekte, Gerätekonfiguration, Signaldokumentation und Kommunikationsschemata. Die Rechte am Code werden vor Arbeitsbeginn im Vertrag vereinbart, damit das Unternehmen nicht von einem einzigen Auftragnehmer abhängig wird.

So läuft die Zusammenarbeit Schritt für Schritt ab

1. Kontakt per Telefon oder E-Mail: Sie beschreiben Maschinen, Problem und Ziel. Es genügen Steuerungsmarken und einige Fotos von Typenschildern und Schränken.
2. Erste Analyse und Angebot für den Prototyp: kostenlos, individuell, mit klarem Umfang und Erfolgskriterien.
3. Prototyp am Teststand und Versuch an der Maschine zum vereinbarten Termin.
4. Auswertung der Ergebnisse und Plan für einen schrittweisen Rollout mit vereinbarten Servicefenstern.
5. Umsetzung, Inbetriebnahme und Abnahme gemeinsam mit der Instandhaltung des Kunden.
6. Schulung, Dokumentation und weitere Betreuung: Bei Hardwareausfall reparieren wir Steuerungen, Panels und Netzteile in unserer Werkstatt in Knurów.

Wir arbeiten an Werktagen, Montag bis Freitag von 8:00 bis 16:00 Uhr (MEZ). Anfragen außerhalb dieser Zeiten bearbeiten wir am nächsten Werktag.

Branchen und Betriebe, für die wir Integrationen umsetzen

Schlesien und die Umgebung im Umkreis von 50 km um Gleiwitz (Gliwice) und Rybnik – wo wir tätig sind

Die Werkstatt von ACORE befindet sich in Knurów, im Herzen des oberschlesischen Ballungsraums. Wir fahren zu Kunden im Umkreis von etwa 50 km um Gleiwitz und Rybnik, also in das Gebiet, in dem die meisten großen Produktionsbetriebe der Region liegen. Aufträge aus dem Rest des Landes bearbeiten wir aus der Ferne und durch Hardwareversand in unsere Werkstatt.

Die Region gehört zu den am besten auf die digitale Transformation der Industrie vorbereiteten in Polen. Die Schlesische Technische Universität betreibt in Gleiwitz ein Zentrum für Industrie 4.0 mit Infrastruktur zum Testen von IIoT-Lösungen, und lokale Unternehmen, unterstützt unter anderem durch eine Sonderwirtschaftszone, führen schrittweise Robotisierung und Datenintegration von Maschinen ein. Der Bedarf, den vorhandenen Maschinenpark praktisch mit modernen Systemen zu verbinden, wächst daher sowohl in großen Betrieben als auch in kleinen Produktionsfirmen.

Nicht nur Software – Reparatur der Hardware, auf der die Integration läuft

Eine Integration funktioniert nur so lange, wie die Geräte, auf die sie sich stützt, intakt sind. Deshalb verbinden wir an einem Ort das Schreiben von Programmen mit der Reparatur von Elektronik: SPS-Steuerungen, HMI-Panels, Frequenzumrichter, Servoantriebe, Hutschienen-Netzteile, E/A-Module und Kommunikationskarten.

• wenn die Kommunikation ausfällt, prüfen wir, ob Software, Verkabelung oder ein beschädigter Schnittstellenbaustein die Ursache ist,
• beschädigte Kommunikationskarten und Anschlüsse reparieren wir auf Bauteilebene, ohne das ganze Gerät auszutauschen,
• für Hardware, die nicht mehr zu kaufen ist, stellen wir die Funktion wieder her oder bauen ein Gateway, das das ausgefallene Modul ersetzt,
• nach der Reparatur testen wir das Gerät am Teststand unter betriebsnahen Bedingungen.

Sie können die Hardware nach Knurów bringen oder per Kurier aus ganz Polen und Europa senden.

Häufige Fragen zu Maschinenintegration und individueller Software