Wägeterminal-Software
Wägeterminal-Software: Wann ein Alt-Terminal zum Risiko wird – und wie man es ablöst
Viele Werke wiegen heute mit einer Terminal-Applikation aus den 2010ern – vom Waagenhersteller, von einem Systemhaus oder selbst gebaut. Sie funktioniert. Diese Seite hilft bei der Frage, wann „funktioniert“ nicht mehr reicht, was eine neue Applikationssoftware für Wägeterminals (auch Wiegeterminals) können muss und wie ein Wechsel gelingt, ohne dass sich der Ablauf am Arbeitsplatz ändert. Danach: wie d-dispensing dafür gebaut ist.
Teil 1 · Das Alt-Terminal bewerten
Sechs Warnsignale
- 01Die Laufzeitumgebung wird nicht mehr gepatcht – ein altes Java, ein Windows ohne Support. Die IT-Sicherheit toleriert es nur noch, weil das Terminal „im Werksnetz“ steht.
- 02Installation ist Wissen einer Person. DLLs in den JRE-Ordner kopieren, Registry-Einträge von Hand – dokumentiert ist nichts.
- 03Der Hersteller existiert nicht mehr oder pflegt das Produkt nicht. Fehler bleiben, Änderungen kosten Sondervereinbarungen.
- 04Kein Audit-Trail oder ein editierbares Log. Bei der letzten Inspektion gab es dazu eine Bemerkung.
- 05ERP-Anbindung per Datei oder Handübertrag. Zwei Bestände, die abgeglichen werden müssen.
- 06Neue Anforderungen scheitern: GHS-Anzeige, zweite Waage, Mehrfach-Chargen, weitere Sprache – jede Erweiterung ist ein Projekt oder unmöglich.
Zwei dieser Signale rechtfertigen eine Risikobewertung; vier bedeuten, dass der Wechsel nicht mehr geplant wird, sondern nur noch sein Zeitpunkt.
Die Risikobewertung, die die QA erwartet
Bewertet werden Patientensicherheit/Produktqualität (Kann das Terminal eine Falscheinwaage zulassen?), Datenintegrität (Ist der Datensatz vollständig, zuordenbar, unveränderbar?), Verfügbarkeit (Was passiert bei Hardware- oder Softwareausfall? Gibt es Ersatz?) und Wissensrisiko (Wer kann das System betreiben, wenn eine Person ausfällt?). Das Ergebnis begründet den Wechsel – oder das bewusste Weiterbetreiben mit kompensierenden Maßnahmen.
Anforderungen an eine neue Wägeterminal-Software
| Anforderung | Warum |
|---|---|
| Herstellerunabhängige Waagenanbindung (serielle Standardprotokolle) | Vorhandene Waagen weiterverwenden; kein Lock-in |
| Bedienung ohne Client-Installation (Browser) | Arbeitsplatz-PC austauschbar; kein Rollout-Aufwand |
| Trennung Bedienung / Gerätezugriff / Server | Ausfallverhalten definierbar; ein Server pro Werk statt Software auf jedem Terminal |
| Serverseitige Toleranzprüfung | Nicht umgehbar, prüfbar |
| Audit-Trail mit Manipulationserkennung | Annex 11 / ALCOA+ |
| Signierte, nachvollziehbare Updates | Änderungskontrolle; kein „Datei kopieren“ |
| Ausgehende Verbindung vom Arbeitsplatz | Keine eingehenden Firewall-Regeln im Werksnetz |
| Dokumentierte Installation | Betrieb ohne Schlüsselperson |
| Gleicher Arbeitsablauf wie heute | Bediener-Akzeptanz, geringerer Schulungs- und Validierungsaufwand |
Die Tabelle beschreibt die Terminal-Ebene. Welche Arten von Waagensoftware es insgesamt gibt und was ein Dispensing-System im Einwaageprozess verhindern muss, beschreiben eigene Seiten.
Migration ohne Prozessänderung
Der größte Wechselaufwand liegt selten in der Technik, sondern in Schulung, SOP-Änderung und Re-Qualifizierung. Beides sinkt drastisch, wenn die neue Applikation den bestehenden Ablauf nachbildet und ihr Verhalten gegen das Altsystem nachgewiesen wird – nicht gegen ein Lastenheft, das jemand aus der Erinnerung geschrieben hat. Empfohlener Weg: Ist-Ablauf aufnehmen → Pilotarbeitsplatz mit definiertem Zeitraum → Vergleich der Datensätze alt/neu → risikobasierte Qualifizierung → Cutover mit Rückfallplan. Ein formaler Parallelbetrieb ist möglich, aber aufwändig; wichtig ist vor allem, dass pro Charge klar ist, welches System das führende Protokoll liefert. Eine Schritt-für-Schritt-Liste für den Umstieg vom Papier oder Alt-System steht auf der Seite Software für Wägeanwendungen.
Teil 2 · Wie d-dispensing gebaut ist
d-dispensing als Wägeterminal-Software
d-dispensing ist genau eine solche Terminal-Applikation – seit 2015 täglich bei mehreren Herstellern im Einsatz, mehrere Millionen Produktionsaufträge abgewickelt. Jede Weiterentwicklung durchläuft hunderte automatisierte Tests, bevor sie ausgeliefert wird. Der Arbeitsablauf bleibt; die Technik bleibt modern und wartbar.
Gegen die Anforderungstabelle:
- Waagen: serielle Industriewaagen u. a. von Mettler Toledo, Sartorius und RHEWA; weitere Hersteller ergänzt die Treiberschicht problemlos, ohne das Terminal anzufassen. Etiketten als ZPL an Zebra-Netzwerkdrucker.
- Bedienung: Browser im Vollbild, Touch- und Scanner-freundlich, Hell/Dunkel pro Arbeitsplatz; keine Client-Installation nötig.
- Architektur: Ein Standort-Server pro Werk (Aufträge, Toleranzen, Audit-Trail, ERP-Buchung), ein kleiner Stationsagent pro Waagenplatz (Waage, Drucker, lokaler Speicher).
- Toleranzen: Serverseitig – 104 % Restbedarf pro Wägung, 98–102 % Positionsabschluss, Warnungen bei 50 %/95 %.
- Audit-Trail: Hash-verkettet, mit Zeitstempeln, Gründen, Checkpoints und Export.
- Updates: Ed25519-signierte Manifeste; Signatur, Größe und Prüfsumme werden vor der Installation geprüft; Aktivierung nie während einer offenen Wägung – beim nächsten Start der Station.
- Netz: Der Stationsagent verbindet sich ausschließlich ausgehend. Bei Netzausfall wird die laufende Wägung abgeschlossen, lokal gesichert und idempotent nachgebucht; neue Aufträge brauchen den Server.
- Installation: Heute manuell (JDK + Anwendung), dokumentiert im Administrationshandbuch; signierter Windows-Installer auf der Roadmap. Lizenzprüfung offline-fähig und stoppt nie eine Wägung.
Häufige Fragen
Häufige Fragen zur Wägeterminal-Software
Nächster Schritt
Wie Sie weitermachen
- Geschäftsführung / Einkauf: Zehn-Fragen-Liste in den FAQ; Demo an eigenen Aufträgen.
- IT / Produktion: Administrations- und Installationshandbuch unter Support; Terminal live testen.
- QA: QA- & Compliance-Brief anfordern; Anforderungen unter Einwaage unter GMP.