Administrations- und Installationshandbuch
Administrations- und Installationshandbuch
Für wen dieses Handbuch ist: Für IT-Administratoren und technische Verantwortliche, die d-dispensing an einem Standort einrichten, betreiben und aktualisieren. Voraussetzungen: Grundkenntnisse in Windows- oder Linux-Serveradministration, Netzwerk und serieller Geräteanbindung.
1
Systemarchitektur
d-dispensing besteht aus zwei Diensten und einer Browser-Oberfläche.
| Komponente | Anzahl | Aufgabe | Verbindungen |
|---|---|---|---|
| Standort-Server | 1 pro Werk | Fertigungsaufträge und Stücklisten aus dem ERP; Toleranzprüfung; Buchungstransaktion in ERP und Lagerverwaltung; Audit-Trail; Lizenzprüfung; Auslieferung der Bedienoberfläche | ERP (myfactory oder weclapp), Lagerverwaltung (xstorage, mit myfactory), Stationsagenten (eingehend), Browser (eingehend) |
| Stationsagent | 1 pro Waagenarbeitsplatz | Serielle Anbindung der Waage; Etikettendruck (ZPL); lokaler dauerhafter Speicher (Outbox) für Wägungen; Update-Verifikation | Waage (seriell), Drucker (Netzwerk), Standort-Server (ausschließlich ausgehend) |
| Bedienoberfläche | 1 pro Arbeitsplatz | Terminal im Vollbild-Browser; keine Installation | Standort-Server |
Datenfluss einer Wägung: Waage → Stationsagent (lokal dauerhaft speichern) → Etikett drucken → Standort-Server (Buchung in ERP + WMS in einer Transaktion, Audit-Trail-Eintrag). Bei fehlender Serververbindung verbleibt der Datensatz in der Outbox und wird idempotent nachübertragen.
2
Systemvoraussetzungen
Standort-Server
- Betriebssystem: Windows Server oder Linux [Engineering: unterstützte Versionen]
- Java-Laufzeit: JDK [Engineering: Version]
- Datenbank: [Engineering: eingebettet oder extern? Produkt/Version]
- Netzwerkzugriff auf das ERP (myfactory und xstorage bzw. weclapp) [Engineering: Protokolle/Ports]
- Eingehender Port für Stationsagenten und Browser [Engineering: Port, TLS-Terminierung]
- Ressourcen: [Engineering: CPU/RAM/Disk-Empfehlung]
Stationsagent (Arbeitsplatz)
- Windows oder Linux [Engineering: Versionen], Java-Laufzeit [Engineering: Version]
- Serielle Schnittstelle (RS-232 oder USB-Seriell-Adapter) zur Waage
- Netzwerkzugriff auf den Etikettendrucker (ZPL, [Engineering: Port 9100?]) und ausgehend auf den Standort-Server
- Lokaler Speicher für die Outbox [Engineering: Pfad, Größenempfehlung]
- Browser im Vollbild/Kiosk-Modus [Engineering: getestete Browser]
Unterstützte Geräte
Waagen: serielle Industriewaagen u. a. von Mettler Toledo, Sartorius und RHEWA. Weitere Hersteller werden problemlos als Treiber in der Treiberschicht ergänzt; das Terminal bleibt unverändert. Drucker: Zebra-Netzwerkdrucker mit ZPL. Scanner: Barcode-Scanner im Tastatur-Modus [Engineering: Suffix/Konfiguration].
3
Installation
3.1 Standort-Server
- 01JDK installieren und
JAVA_HOMEsetzen. - 02Anwendungsartefakt in das Zielverzeichnis entpacken [Engineering: Pfad].
- 03Konfiguration anlegen [Engineering: Datei, Schlüssel]: Datenbank, ERP-Zugang (myfactory oder weclapp), WMS-Zugang (xstorage, bei myfactory), Port, TLS, Standortkennung.
- 04Toleranzparameter prüfen. Standard: Einzelwägung max. 104 % des Restbedarfs; Positionsabschluss 98–102 % des Ziels; Warnstufen 50 % und 95 %. Änderungen nur nach Freigabe durch QA und mit Eintrag in der Änderungskontrolle.
- 05Dienst einrichten (Windows-Dienst / systemd) [Engineering: Unit/Service-Definition].
- 06Starten und Erreichbarkeit der Bedienoberfläche im Browser prüfen.
- 07ERP- und WMS-Verbindung mit einem Testauftrag prüfen [Engineering: Testmodus].
3.2 Stationsagent
- 01JDK installieren.
- 02Agent-Artefakt entpacken [Engineering: Pfad].
- 03Konfiguration [Engineering: Datei]: Adresse des Standort-Servers, Stationskennung, serieller Port und Waagenmodell, Druckeradresse, Outbox-Pfad.
- 04Waage anschließen, Protokollparameter (Baudrate etc.) an der Waage und in der Konfiguration abgleichen.
- 05Dienst einrichten und starten.
- 06Prüfen: Live-Gewicht im Terminal sichtbar; Testetikett druckbar [Engineering: Testfunktion]; Station erscheint am Server als „Online“.
3.3 Arbeitsplatz-Browser
Browser im Kiosk-/Vollbildmodus mit der Terminal-URL des Standort-Servers starten [Engineering: URL-Schema, Stationszuordnung]. Autostart einrichten. Hell-/Dunkelmodus wird pro Arbeitsplatz im Browser gespeichert.
4
Integration
4.1 ERP: myfactory
Der Standort-Server verwendet einen dedizierten Adapter, der die Buchungstransaktion Ende-zu-Ende verantwortet: Lesen von Fertigungsaufträgen und Stücklisten, Schreiben der Lagerbewegung je Wägung. [Engineering: benötigte Rechte, Endpunkte, Stammdatenanforderungen – insbesondere GHS-Daten und Gebinde-/Quant-Kennungen im Materialstamm]
4.2 Lagerverwaltung: xstorage
Bestandsbuchung in derselben Transaktion wie die ERP-Buchung [Engineering: Details].
4.3 ERP: weclapp
Eigener Adapter für weclapp, mit derselben Buchungstransaktion je Wägung. weclapp kennt keine Gebinde-Barcodes: Statt eines Quants scannt der Bediener Artikelnummer und Lagerplatz, und der Server prüft das Paar gegen den Bestand in weclapp. [Engineering: benötigte Rechte, API-Zugang, Stammdatenanforderungen]
4.4 Weitere Systeme
Die Integrationsschicht (ErpPort) ist bewusst schmal und implementierungsunabhängig. Weitere ERP-/WMS-Adapter sind möglich, aber heute nicht vorhanden. Anfragen an D-Automation.
5
Betrieb
5.1 Überwachung
Status der Stationen am Standort-Server [Engineering: Ansicht/Endpunkt]; Outbox-Füllstand je Station: Datensätze, die noch nicht an den Server übertragen wurden [Engineering: Sichtbarkeit]; Protokolle (Logs) [Engineering: Pfade, Rotation] – Hinweis: Logs sind nicht der Audit-Trail.
5.2 Verhalten bei Ausfall
| Ausfall | Verhalten | Maßnahme |
|---|---|---|
| Netz/Server während laufender Wägung | Wägung wird abgeschlossen, lokal gespeichert, etikettiert; Buchung idempotent nachgeholt | Verbindung wiederherstellen; Outbox leert sich automatisch |
| Netz/Server, kein Auftrag offen | Neue Aufträge und Anmeldungen nicht möglich (bewusst) | Verbindung wiederherstellen |
| Waage nicht erreichbar | Kein Live-Gewicht; Wägung nicht möglich | Kabel/Port/Protokoll prüfen |
| Drucker nicht erreichbar | Datensatz ist gespeichert; Etikett fehlt | Drucker prüfen; Nachdruck [Engineering: Funktion] |
| ERP/WMS nicht erreichbar | Server hält Buchung zurück [Engineering: Verhalten] | ERP-Verfügbarkeit herstellen |
5.3 Datensicherung
Datenbank des Standort-Servers inklusive Audit-Trail regelmäßig sichern [Engineering: Verfahren]. Outbox-Verzeichnisse der Stationen enthalten nur temporär nicht übertragene Datensätze; sie dürfen nicht manuell gelöscht werden.
5.4 Audit-Trail
Jede Wägung, Ablehnung, Lizenzprüfung und jedes Update ist ein Eintrag in einem hash-verketteten Audit-Trail mit vertrauenswürdigem Zeitstempel. Export für die QA: [Engineering: Funktion/Format]. Checkpoints zur Verifikation: [Engineering: Verfahren]. Der Audit-Trail wird nicht rotiert und darf nicht bearbeitet werden.
6
Software-Updates
Releases werden als Ed25519-signierte Manifeste verteilt. Ablauf an der Station:
- 01Manifest laden; Signatur prüfen, bevor irgendetwas geparst wird.
- 02Artefakt laden; Größe und Prüfsumme verifizieren – abgeschnittene oder manipulierte Antworten werden verworfen.
- 03Artefakt bereitstellen; Aktivierung nur zu einem sicheren Zeitpunkt: keine offene Wägung, keine Datensätze in der Outbox.
7
Lizenzierung
Grundregel: Ein Lizenzproblem stoppt nie eine Wägung – nicht die laufende, nicht ihr Etikett, nicht ihre Buchung, nicht einen nach Ausfall nachübertragenen Datensatz.
- Der Standort prüft eine signierte, offline prüfbare Berechtigung gegen die eigene Uhr; keine Internetverbindung nötig.
- 3 Wochen vor Ablauf: Warnung. Nach Ablauf: 2 Wochen Karenz. Danach: keine neuen Fertigungsaufträge – laufende Wägungen bleiben unberührt.
- Alle Lizenzprüfungen stehen im Audit-Trail.
8
Sicherheit
- Stationsagenten: nur ausgehende Verbindungen; keine eingehenden Ports am Arbeitsplatz.
- Standort-Server: einzige Komponente mit ERP-/WMS-Zugang; Zugangsdaten [Engineering: Ablage/Verschlüsselung].
- Toleranzprüfung serverseitig; der Browser ist reine Anzeige- und Eingabeschicht.
- Updates kryptografisch verifiziert (Signatur → Größe → Prüfsumme).
- Audit-Trail hash-verkettet; Manipulation erkennbar.
- Benutzerverwaltung und Rollen [Engineering: Umfang].
9
Umstieg von einem bestehenden Terminal
d-dispensing läuft seit 2015 täglich bei mehreren Herstellern und hat inzwischen mehrere Millionen Produktionsaufträge abgewickelt; jede Weiterentwicklung durchläuft hunderte automatisierte Tests, bevor sie ausgeliefert wird. Empfohlenes Vorgehen für die Ablösung Ihres bisherigen Terminals: Pilotarbeitsplatz mit definiertem Zeitraum, Vergleich der Datensätze, risikobasierte Qualifizierung (siehe QA- & Compliance-Brief), Cutover mit Rückfallplan. Pro Charge muss eindeutig sein, welches System das führende Protokoll liefert.
10
Demo-Umgebung
Unter /demo/ läuft die echte Terminal-Komponente gegen eine simulierte Waage, einen simulierten Drucker und ein Beispiel-Auftragsbuch – ohne Backend, als Teil des statischen Builds. Das Szenario (Aufträge, Materialien, Gebinde) wird in einer Seed-Datei gepflegt [Engineering: Pfad]; eine kundenspezifische Demo ist eine Inhaltsänderung.
Version: Entwurf 0.1, September 2026. Änderungen an diesem Dokument unterliegen der Änderungskontrolle des Betreibers, sobald es Teil der Systemdokumentation ist.