Kommunikation zwischen Fertigung und Traceability-System
Die Schnittstelle als kritischer Punkt der internen Traceability
Wie sollen die Fertigungsgeräte miteinander bzw. mit dem Traceability-System kommunizieren? Die oft proprietäre Schnittstelle zwischen beiden Seiten ist häufig der Schwachpunkt des Gesamtsystems. Abhilfe soll der vom Arbeitskreis »Technologie« im ZVEI Arbeitskreis »Traceability« erarbeitete Vorschlag zur Standardisierung einer Kommunikationsschnittstelle schaffen.
»Darüber, dass Standardisierungen die für alle Beteiligten große Vorteile bringen würden, waren wir uns sofort einig«, so Dr. Johann Gaus, Vorsitzender der Arbeitsgruppe »Technologie« im ZVEI-Arbeitskreis Traceability und Geschäftsführer von Gaus Softwaretechnik. »Sieht man aber genauer hin, hat die Schnittstelle viele Anspekte, die es zu berücksichtigen gilt: Kabel und Stecker der Datenleitung, technische Details der Datenübertragung, der Aufbau der übertragenen Daten und schließlich der wirkliche Nutzinhalt.«
Diskussionen über die ersten beiden Punke wären ein Streit um des »Kaisers Bart« gewesen, meint Gaus, denn hier hänge zu viel von der Konstruktion der Geräte ab. So konzentrierte sich der Arbeitskreis auf die anderen beiden Punkte und damit auf die Schnittstelle. Das Ergebnis sind fertig ausgearbeitete XML-Strukturen, die zum Download unter www.zvei.de/traceability verfügbar sein werden.
Jobangebote+ passend zum Thema
Die praktische Umsetzung der Schnittstelle erfolgte durch zwei analog aufgebaute Kommunikationskanäle: control und unitData. Während die Kommunikation über control der Prozesskontrolle dient, um die zugehörigen Daten während der Bearbeitung des Produktes auszutauschen, ist unitData für die Übertragung des Ergebnisprotokolls zuständig. »Ein passives Traceability-System wird mit unitData auskommen, während ein aktives System »control« benötigt «, so Gaus. Ein passives System kann bei der Produktion nur zusehen und im Ernstfall beispielsweise alle Geräteseriennummern anzeigen, in die eine defekte Bauteilecharge eingebaut wurde. Ein aktives System ist dagegen in der Lage, die Produktion auch zu steuern und anzuhalten, wenn z.B. ein ungestesteter Schaltkreis verpackt werden soll. »unitData alleine würde im Ernstfall lediglich die nicht korrekte Verpackung protokollieren und damit eine Schadensbegrenzung im Nachhinein ermöglichen«, gibt Gaus zu bedenken. Trotz der unterschiedlichen Rollen sind beide Schnittstellen in weiten Feldern analog aufgebaut. Sie gliedern sich
- in stets vorhandene Kopfdaten:
- name: Je nach Tiefe der erforderlichen Traceability eine Seriennummer, aber auch ein Auftrag oder Auftragslos
- equipment: Name bzw. eindeutige Bezeichnung der Maschine, des mauellen Arbeitsplatzes oder der Fertigungsinsel
- starttime, Endtime: Zeitpunkte des Beginns und Endes der Bearbeitung
- state: Zustand der Bearbeitung ok oder nok
- und in optionale Anhänge
- productionResources: Werkzeuge und Fertigungshilfsmittel
- processingParameters: Parameter und Sollwerte
- properties: Zusätzliche Eigenschaften
- assembly, disassembly: Materialverbrauch Ein- und Ausbauinformationen
- measuring: Allgemeine Messdaten
- test, diagnosis, repair: Test, Diagnose und Reparaturdaten
- subUnitData: Handeln von Werkstückträgern
- additionalId: Zusätzliche Seriennummern
- actions: Durchzuführende Aktionen
- setups: Soll- und Istrüstungen, zu verbauende Materialien
Der genaue Aufbau ist als Sammlung von XSD-Dateien definiert, kann also zur direkten Verifikation der übertragenen Daten verwendet werden, sofern dies in XML erfolgt. Die Verwendung von XML ist indes laut Gaus nicht obligatorisch. Geräte mit Microcontrollern, die sich diesen »Luxus« nicht leisten können, könnten beispielsweise ein effizienteres Format verwenden.
- Die Schnittstelle als kritischer Punkt der internen Traceability
- Die Schnittstelle als kritischer Punkt der internen Traceability
Lesen Sie mehr zum Thema
