Kontrollierte Definition von Alarm- und Ereigniscodes für 3D-Druckanlagen

Einleitung: Derselbe Alarm, drei Schichten, drei Maßnahmen

Bei einer Metall-Pulverbett-Schmelzanlage erschien während der Nachtschicht wiederholt die Meldung „Sauerstoffgehalt zu hoch“: Schicht A druckte erfahrungsbasiert weiter, Schicht B stoppte die Anlage und spülte die Kammer erneut, Schicht C setzte die Meldung schlicht zurück. Alle drei Aufzeichnungen beschreiben dasselbe Phänomen, doch keine beantwortet die Fragen: „Welchem Ereigniscode entspricht diese Meldung, welcher Auslöseschwellenwert gilt, ist ein Weiterdrucken zulässig und muss nach dem Rücksetzen erneut geprüft werden?“ Bei der Umsetzung von Lifecycle-Projekten von der Konstruktionszeichnung bis zur physischen Auslieferung hat lantu3D festgestellt, dass Fertigungsbereiche meist weder Sensoren noch Prüfchecklisten vermissen. Es fehlt vielmehr eine kontrollierte Codetabelle, welche die Rohereignisse des Anlagencontrollers in eindeutig beurteilbare Maßnahmen übersetzt. Dieser Beitrag behandelt nicht die Frage „Wie wird die Anlage repariert?“, sondern die vorgelagerte Ebene: wie Alarm- und Ereigniscodes nummeriert, klassifiziert, mit Interlock-Aktionen verknüpft, bei Maskierung und Rücksetzung kontrolliert und mit Firmwareversionen eingefroren werden, damit dasselbe Ereignis in jeder Schicht gleich behandelt wird.

1. Zunächst die Grenzen klären: Alarmcodes, Fehlerphänomene und Qualitätsereignisse gehören nicht in dieselbe Tabelle

Zunächst müssen drei häufig vermischte Objekte getrennt werden. Ein Alarmcode ist eine vom Anlagensteuerungssystem bit- oder wortweise ausgegebene strukturierte Kennung; seine Bedeutung wird durch die Codetabelle definiert und muss eindeutig, stabil und maschinenlesbar sein. Ein Fehlerphänomen ist eine vom Bediener beobachtete Beschreibung, etwa „Streifen im Pulverbett“, und gehört zur natürlichen Sprache; mehrere Phänomene können auf denselben Code verweisen. Ein Qualitätsereignis ist eine nachträgliche Beurteilung der Bauteilauswirkung, beispielsweise „dieser Build wird zur Prüfung gesperrt“, und gehört zur Freigabeebene. Bereits behandelte Themen wie dreistufige Messpunkte und Wellenformaufzeichnungen für die Netzqualität, die Zuordnung von Fehlermodi, Überwachungskennzahlen und Grenzwerten in der vorausschauenden Instandhaltung oder die drei Zustände normal/anomal/erneut zu prüfen bei Anlageninspektionen nutzen jeweils eine bestimmte Art von Ereignis für eine andere Entscheidung. Sie definieren jedoch nicht, „woher ein Code stammt, wie Codebereiche gegliedert werden oder wie bei Codeänderungen mit Altaufzeichnungen verfahren wird“. Die entscheidende Abgrenzungsfrage auf dieser Ebene lautet: Beschreibt der Beitrag, wie nach Eingang eines Signals ein Ergebnis berechnet wird, oder wie dieses Signal bei seiner Entstehung heißt, welcher Stufe es angehört und welche Aktion es auslösen darf? Nur Inhalte, die sich auf „einen Code, eine Klassifizierungstabelle, eine Interlock-Regel und einen Versionssperrvermerk“ zurückführen lassen, gehören zur Engineering-Ebene der Codetabelle.

2. Codebereiche: Jedem Ereignis eine niemals wiederverwendete Identität geben

Empfohlen wird eine fünfteilige Codierung fester Länge: E-<Anlagenfamilie 2 Stellen>-<Subsystem 2 Stellen>-<Laufnummer 3 Stellen>-<Stufe 1 Stelle>. Beispielsweise bezeichnet LP-GS-0217-3 Ereignis Nummer 217 im Subsystem Pulverbeschichtung/Gas mit Schweregrad 3. Anlagenfamilien werden nach Prozessplattform gegliedert (LP Laser-Pulverbett, BJ Binder Jetting, PJ Photopolymerisation, DE Directed Energy Deposition); Subsysteme nach Funktionsbereich (GS Gasversorgung und Sauerstoffgehalt, RC Pulverbeschichtung und Rakel, LS Laser und Strahlengang, TH Substratvorheizung, MT Bewegung und Servo, PW Stromversorgung und Medienversorgung, CT Steuerung und Kommunikation). Für jeden Code müssen in der Codetabelle mindestens acht Felder festgeschrieben sein: eindeutiger Code, deutsche und englische Standardbeschreibung, Ausdruck der Auslösebedingung, Standardstufe, Standard-Interlock-Aktion, zulässige Betriebszustände, erstmals gültige Firmwareversion und verantwortliche Bearbeitungsrolle. Eine einmal vergebene Laufnummer darf niemals wiederverwendet werden; stillgelegte Ereignisse werden lediglich als deprecated markiert und mit historischem Mapping erhalten. Es ist verboten, alte Nummern neuen Bedeutungen zuzuweisen, da Qualitätsaufzeichnungen von vor drei Jahren bei einer Rückverfolgung sonst als völlig andere Ereignisse interpretiert würden.

3. Klassifizierung und Interlocks: Eine vierstufige Aktionsmatrix von „Hinweis“ bis „Sicherheitsabschaltung“

Empfohlen werden vier Schweregrade, wobei jeder Stufe eine eindeutige Standardaktion zugeordnet wird, um Ermessensentscheidungen vor Ort zu vermeiden: S1 Hinweis (nur Eintrag im Ereignisprotokoll, keine Unterbrechung des Bauprozesses, etwa Erinnerung an einen bevorstehenden Filterwechsel bei zunehmender Filterdruckdifferenz); S2 Vorwarnung (Bauprozess wird fortgesetzt, jedoch mit reduzierter Geschwindigkeit oder Markierung, beispielsweise bei einem Sauerstoffgehalt in der Kammer von 800–1000 ppm, wobei die Spülzeit zwischen den Schichten automatisch verlängert und die betreffende Schicht markiert wird); S3 Prozesshaltung (Pulverbeschichtung wird angehalten, aktuelle Schichtnummer und Inertgasatmosphäre werden gehalten, etwa bei Sauerstoffgehalt >1000 ppm für ≥2 s oder bei einer Abweichung der gemessenen Laserleistung vom Sollwert um ±8 % über mehr als 3 Schichten); vor dem Weiterdrucken muss der Verschmelzungszustand der drei Schichten vor und nach der betroffenen Schichtnummer überprüft werden; S4 Sicherheitsabschaltung (Laseremission wird abgeschaltet, Gaszirkulation bleibt erhalten, der betreffende Build wird unmittelbar gesperrt, etwa bei Ausfall des Schutzgases, Auslösen der Kammertürverriegelung oder Betätigung des Not-Aus-Kreises). Für S4 sind automatisches Rücksetzen und Maskierung ausnahmslos verboten. Die Aktionsmatrix ist mit sechs Spalten zu formulieren: „Stufe → Unterbrechung ja/nein → Atmosphäre beibehalten ja/nein → Build sperren ja/nein → Erstteilprüfung erforderlich ja/nein → zu benachrichtigende Rolle“. Sie wird nach gemeinsamer Freigabe durch Prozess-, Anlagen- und Qualitätsverantwortliche veröffentlicht.

4. Entprellung, Auslösebedingungen und Evidenz-Snapshots: Ein Ereignis nachvollziehbar berechenbar machen

Eine Auslösebedingung darf nicht lediglich „Sauerstoffgehalt hoch“ lauten, sondern muss als nachvollziehbar berechenbarer Ausdruck formuliert sein: Vergleichsgröße / Vergleichsoperator / Grenzwert / Dauer / Hystereseband / Freigabebetriebszustand. Für den Sauerstoffgehalt gelten beispielsweise ein Grenzwert von 1000 ppm, eine Dauer von 2 s, ein Hystereseband von 5 % (Aufhebung erst bei Rückgang unter 950 ppm) sowie eine Freigabe nur während Bau- und Vorheizbetrieb; im Standby- und Wartungsbetrieb findet keine Bewertung statt. Für die Abweichung der Laserleistung gelten ±8 %, drei aufeinanderfolgende Schichten und Entprellung bei einem Abtastintervall von 100 ms; eine Bestätigung erfolgt erst nach drei aufeinanderfolgenden erfüllten Zyklen, während kurzzeitige Spitzen von <50 ms als transiente Ereignisse protokolliert und nicht hochgestuft werden. Für jedes bestätigte Ereignis wird ein Evidenz-Snapshot erzeugt. Empfohlen werden zehn feste Felder: Ereigniscode, Zeitstempel (mit Anlagenuhr synchronisiert, Drift ≤1 s), aktuelle Schichtnummer, tatsächliche Laserleistung, Position der Beschichtungsachse, Sauerstoffgehalt und Taupunkt, Hash des Parametersatzes, Version der Codetabelle, Firmwareversion und Bedienerkennung. Zusätzlich sind die Wellenformen kritischer Größen für 200 ms vor und 1 s nach dem Ereignis aufzubewahren. Ohne diesen Snapshot lässt sich die Auswirkungsgrenze eines Ereignisses nachträglich nicht bestimmen; auch Freigabeentscheidungen bei S3/S4 entbehren dann einer Grundlage.

5. Maskierung, Rücksetzung und temporärer Bypass: Ausnahmen in einen autorisierten Rahmen einschließen

In der Praxis gibt es berechtigte Anforderungen zur Maskierung, etwa während der Kalibrierung eines Sauerstoffanalysators; diese müssen jedoch technisch kontrolliert werden: Maskierung ist nur für S1–S3 zulässig, für S4 dauerhaft verboten. Der Antrag muss Codenummer, Begründung, alternative Überwachungsmaßnahmen und Gültigkeitsdauer enthalten. Die Gültigkeitsdauer sollte ≤8 Stunden oder ≤1 Build betragen, je nachdem, was zuerst eintritt; nach Ablauf wird die Maskierung automatisch unwirksam. Die Durchführung erfordert eine Doppelautorisierung durch Anlagen- und Qualitätsverantwortliche. Während der Maskierung werden alle Ereignisse weiterhin regulär aufgezeichnet; es werden lediglich suppressed=true und die Nummer des Autorisierungsantrags ergänzt. Ereignisse dürfen niemals stillschweigend verworfen werden. Auch eine Rücksetzung ist kein einfacher Tastendruck: Vor dem Rücksetzen von S3/S4 müssen ein Fehlerursachencode gemäß Fehlerlexikon sowie die bearbeitende Person eingetragen werden. Nach dem Rücksetzen ist eine Erstteilvalidierung mit einem Standardprüfkörper durchzuführen; außerdem sind die drei Schichten vor und nach der Ereignisschicht auf Bindefehler und Porosität zu prüfen. Erst wenn alle vier Aufzeichnungen vollständig sind, darf die Build-Sperre aufgehoben werden. Es wird empfohlen, „Maskierungsrate ≤1 % der Builds“, „Anteil nicht klassifizierter Ereignisse ≤2 %“, „mehr als 5 Wiederholungen derselben Ursache innerhalb einer Stunde erzeugen automatisch einen Ursachen-Arbeitsauftrag“ und „Vollständigkeitsrate Ereignis–Snapshot ≥99 %“ in das monatliche Dashboard aufzunehmen.

6. Versionssperre und Änderungen: Wohin gehen alte Codes nach einem Firmware-Upgrade?

Eine Codetabelle ist ein kontrolliertes Dokument und keine beliebig veränderbare Excel-Datei. Bei jeder Veröffentlichung werden Versionsnummer, SHA-256-Hash, Gültigkeitsdatum, Liste der anwendbaren Anlagenseriennummern und minimale Firmwareversion erstellt und gemeinsam mit der Version des Parametersatzes und der Build-Nummer als Dreifachschlüssel in die Liefernachweiskette geschrieben. Das Hinzufügen oder Ändern eines Codes muss über einen Änderungsantrag erfolgen: Auswirkungsanalyse (welche historischen Aufzeichnungen, Arbeitskarten und Interlock-Logiken betroffen sind) → Prüfung durch drei Parteien → Zuordnung alter und neuer Codes → Umschaltung zum Stichtag → Außerkraftsetzung alter Arbeitskarten. Vor und nach einem Firmware-Upgrade ist zwingend ein Abgleich der Codetabellenkonsistenz durchzuführen: Für jeden Eintrag wird geprüft, ob die vom Controller tatsächlich ausgegebene Codenummer, Stufe und Beschreibung mit der aktuellen kontrollierten Version übereinstimmen. Bei Abweichungen wird die Betriebsfreigabe der Anlage gesperrt. Historische Codetabellen und Ereignisprotokolle sollten mindestens über die Produktlebensdauer zuzüglich drei Jahren aufbewahrt und schreibgeschützt archiviert werden.

7. Checkliste für die Umsetzung und häufige Fehler

Die Einführung kann innerhalb von 30 Tagen erfolgen: In Woche 1 wird die vollständige Ereignisliste des Controllers exportiert, nach dem fünfteiligen Schema neu codiert und ein Codebereichsregister angelegt. In Woche 2 werden die vierstufige Aktionsmatrix und die Ausdrücke für Auslösebedingungen fertiggestellt sowie Entprellung und Hysteresebänder ergänzt. In Woche 3 wird die automatische Verknüpfung der zehn Snapshot-Felder mit Parametersatz-Hash und Schichtnummer eingerichtet. In Woche 4 folgt eine 30-minütige Rückverfolgungsübung: Zufällig wird ein S3-Ereignis von vor drei Monaten ausgewählt; die damalige Version der Codetabelle, Auslösebedingung, der Snapshot und die Freigabeentscheidung müssen rekonstruiert werden. Das Ziel für die Erfolgsquote der Rekonstruktion liegt bei ≥95 %. Vier häufige Fehler sind: Alarmcodes als natürlichsprachliche Beschreibungen formulieren und sie dadurch nicht maschinenlesbar machen; nur Grenzwerte, aber weder Dauer noch Freigabebetriebszustand definieren, sodass im Wartungsbetrieb Fehlalarme auftreten; Ereignisse bei Maskierung gar nicht aufzeichnen und dadurch die Evidenzkette unterbrechen; nach einem Firmware-Upgrade die alte Codetabelle weiterverwenden, sodass alte und neue Bedeutungen vermischt werden.

Fazit

Die kontrollierte Definition von Anlagenalarm- und Ereigniscodes ist die grundlegende Engineering-Ebene, welche „was die Maschine meldet“ in „was die Fertigung tun muss“ übersetzt. Sie ersetzt weder Energieverbrauchsabrechnung, Netzqualitätsmanagement, vorausschauende Instandhaltung noch Prüfloseverwaltung, sondern stellt diesen Methoden ein stabiles, nachvollziehbar berechenbares und rückverfolgbares Eingabewörterbuch bereit. Für Plattformen, die die gesamte Kette von Konstruktion, Prozess und Fertigung bis zur physischen Auslieferung abdecken, gilt: Nur wenn jeder Code eindeutig, jede Stufenaktion eindeutig, jede Ausnahme dokumentiert und jede Version einfrierbar ist, wird ein Hinweis in der Nachtschicht zu einer technischen Tatsache, die in jeder Schicht zum selben Ergebnis führt.