Muster für die Datensatzsperrung bei der Stapelverarbeitung

Tulip verhindert nicht von Haus aus, dass zwei Bediener gleichzeitig denselben Chargenlauf beanspruchen. Wenn mehrere Bediener auf separaten Geräten aus einer gemeinsamen Chargenwarteschlange arbeiten, kann es zu einer Race Condition kommen: Beide Geräte lesen den Chargenstatus als „Ausstehend“, beide schreiben „In Bearbeitung“ und beide navigieren in die Ausführungs-App. Die Folge ist die parallele Ausführung eines einzelnen Chargendatensatzes, was die Prozesskonformität beeinträchtigt und die Charge ungültig macht.

Eine Statusaktualisierung allein reicht nicht aus. Die Lösung ist eine Datensatzsperre – ein spezielles Feld, das den Batch vor Beginn der Ausführung an einen einzigen Verantwortlichen bindet und überprüft wird, bevor die Navigation erlaubt wird.

> Dieses Muster gilt für jedes Szenario mit gemeinsamer Warteschlange in Tulip: Batch-Starter, Kommissionierung von Arbeitsaufträgen, Aufgabenzuweisung – überall dort, wo mehrere Bediener auf separaten Geräten aus einer gemeinsamen Liste von Datensätzen auswählen.

Sperrmuster

Tulip supports Zwei Sperrmuster. Muster 1 speichert die Sperre im Batch-Datensatz selbst, mit zwei Optionen, je nachdem, ob Sie nach Station oder nach Benutzer sperren. Muster 2 nutzt die vorhandene Struktur der Stationstabelle.

Wann sollte die Datensatzsperre verwendet werden?

Wenden Sie dieses Muster an, wenn:

• Mehrere Bediener teilen sich auf separaten Geräten eine Warteschlange mit bearbeitbaren Datensätzen
• Zwei Bediener könnten gleichzeitig denselben Datensatz auswählen
• Eine parallele Ausführung würde gegen Prozessvorschriften oder die Datenintegrität verstoßen

Dieses Muster ist nicht erforderlich, wenn jeder Bediener mit einem vorab zugewiesenen Stapel arbeitet, wenn jeweils nur ein Gerät auf die Tabelle zugreift oder wenn Tulip Automations die Stapelzuweisung übernimmt, bevor die Bediener mit der Warteschlange interagieren.

Muster 1: Sperre der Batch-Tabelle

Tulip schreibt einen Eigentümerwert in eine spezielle Spalte der Stapeltabelle und liest das Feld anschließend erneut aus, um zu überprüfen, ob die Sperre erworben wurde, bevor die Navigation zugelassen wird. Zwei Feldtypen decken die beiden Hauptanwendungsfälle ab.

Option A: Sperre nach Station

Fügen Sie Ihrer Batch-Tabelle eine Spalte hinzu:

Ein natives Feld vom Typ „Station“ stellt sicher, dass nur eine gültige Tulip-Station in diese Spalte geschrieben werden kann.

Ablauf der Anforderung und Überprüfung:

1. Lies „locked_by_station“ für den ausgewählten Stapel aus.
2. Falls gefüllt – Navigation sperren. Anzeige: „Dieser Stapel ist von einer anderen Station gesperrt.“
3. Wenn leer – die aktuelle Station in „locked_by_station“ schreiben.
4. „locked_by_station“ erneut lesen.
5. Wenn der Wert mit der aktuellen Station übereinstimmt – weiter zur Ausführungs-App.
6. Wenn der Wert eine andere Station angibt – Navigation blockieren. Fehlermeldung anzeigen.
7. Nach Abschluss des Stapels – „locked_by_station“ löschen.

Das erneute Auslesen in den Schritten 4–6 ist entscheidend. Wenn zwei Stationen gleichzeitig schreiben, bleibt nur ein Schreibvorgang bestehen. Das erneute Auslesen bestimmt, welche Station den Vorrang hat.

Am besten geeignet für: Umgebungen, in denen Bediener von festen, benannten Stationen aus arbeiten.

Option B: Sperre nach Benutzer

Identisch mit Option A, verwendet jedoch ein Feld vom Typ „Benutzer“. Die Sperre ist an den angemeldeten Bediener statt an das Gerät gebunden, was benannte Prüfpfade in regulierten Umgebungen unterstützt und Workflows mit gemeinsam genutzten Geräten ermöglicht, bei denen sich mehrere Bediener dasselbe Gerät teilen.

Fügen Sie Ihrer Batch-Tabelle eine Spalte hinzu:

Ablauf der Anforderung und Überprüfung:

1. Lies „locked_by_user“ für den ausgewählten Stapel aus.
2. Falls gefüllt – Navigation sperren. Anzeige: „Dieser Stapel ist von [Benutzername] gesperrt.“
3. Wenn leer – den aktuellen Benutzer in „locked_by_user“ schreiben.
4. „locked_by_user“ erneut lesen.
5. Wenn der Wert mit dem aktuellen Benutzer übereinstimmt – zur Ausführungs-App weiterleiten.
6. Wenn der Wert einen anderen Benutzer angibt – Navigation blockieren. Fehlermeldung anzeigen.
7. Nach Abschluss der Charge – „locked_by_user“ löschen.

Am besten geeignet für: Umgebungen mit gemeinsam genutzten Geräten in der Pharmaindustrie, bei Medizinprodukten oder in regulierten Branchen, in denen die Compliance eine namentliche Benutzererfassung für jede Chargenausführung erfordert.

Muster 2: Stationszugehörigkeit

Die Stations-Tabelle von Tulip (verfügbar in der Bibliothek) enthält eine Spalte „order_id “. Durch das Schreiben einer Auftrags-ID in das Feld „order_id“ einer Station wird diese Station als Eigentümer des Auftrags festgelegt. Jede andere Station, die versucht, denselben Auftrag zu starten, findet das Feld bereits ausgefüllt vor und wird blockiert.

Es sind keine Schemaänderungen erforderlich.

Ablauf zum Anfordern und Überprüfen:

1. Abfrage der „Stations“-Tabelle nach allen Stationen, bei denen die „order_id“ mit dem ausgewählten Auftrag übereinstimmt.
2. Wird eine Übereinstimmung gefunden, blockieren Sie die Navigation. Anzeige: „Dieser Auftrag wird bereits an einer anderen Station bearbeitet.“
3. Wenn keine Übereinstimmung vorliegt – die Auftrags-ID in das Feld „order_id“ der aktuellen Station schreiben.
4. Fragen Sie die Stations-Tabelle erneut ab, um sicherzustellen, dass keine andere Station im Zeitraum zwischen den Schritten 1 und 3 denselben Auftrag geschrieben hat.
5. Wenn keine andere Station diese Auftrags-ID besitzt – fahre mit der Ausführungs-App fort.
6. Wenn eine andere Station sie nun besitzt – Navigation blockieren. Fehlermeldung anzeigen.
7. Nach Abschluss des Stapels – „order_id“ der Station löschen.

Wenn ein Gerät während des Batch-Laufs abstürzt, bleibt die „order_id“ der Station gesetzt. Stellen Sie eine „Force Release “-Funktion für den Supervisor bereit, mit der das Feld manuell gelöscht werden kann.

Am besten geeignet für: Feste, benannte Arbeitsstationen. Die Stationentabelle kann auch als Live-Übersicht über den Produktionsbereich dienen – eine Abfrage zeigt an, welche Station zu einem bestimmten Zeitpunkt welchen Auftrag ausführt.

Verhalten gegenüber dem Bediener

Wenn ein Batch gesperrt ist, sollte der Bediener eine eindeutige Meldung erhalten, keinen Systemfehler.

• Verwenden Sie im Batch-Dashboard die bedingte Formatierung von Tulip oder eine gefilterte interaktive Tabelle, um gesperrte Batches visuell zu kennzeichnen (z. B. durch eine „Gesperrt“-Anzeige oder eine ausgegraute Zeile).
• Bei Antippen wird angezeigt: „Dieser Batch wird derzeit von einem anderen Bediener ausgeführt. Bitte wählen Sie einen anderen Batch aus.“
• Fügen Sie einen Timer-Trigger hinzu (z. B. alle 30 Sekunden), um die Chargenliste automatisch zu aktualisieren, sodass aufgehobene Sperren umgehend berücksichtigt werden.

Freigabe der Sperre

Erstellen Sie einen Trigger beim Beenden der App, der das Sperrfeld löscht. Berücksichtigen Sie dabei die folgenden Beendigungsszenarien:

Randfälle

Verwandte Ressourcen

• Trigger – Best Practices – enthält Anleitungen zur Vermeidung von Race-Conditions bei Variablen
• Datenüberprüfung zur GxP-Konformität – Überprüfen Sie Workflows, die für die Chargenkonformität relevant sind
• Widget „Verlauf aufzeichnen“ – Verfolgen Sie Änderungen an gesperrten Datensätzen
• GxP-Datenerfassung – Muster für die Erfassung regulierter Daten
• eBR-Prüfungs-App-Gruppe – Arbeitsabläufe zur Überprüfung von Chargenprotokollen
• Dashboard für die Chargenproduktion – die Start-App, in der dieses Muster zur Anwendung kommt
• „Electronic Batch Record Suite “ – der übergeordnete eBR-Workflow