Weighing terminal software
Weighing terminal software: when a legacy terminal becomes a risk – and how to replace it
Many plants still weigh with a terminal application from the 2010s – from the scale maker, a systems integrator, or built in-house. It works. This page helps you decide when "it works" is no longer enough, what new weighing terminal software must do, and how to switch without changing the bench workflow. Then: how d-dispensing is built for exactly that.
Part 1 · Assessing the legacy terminal
Six warning signs
- 01The runtime is no longer patched – an old Java, a Windows version out of support. IT security tolerates it only because the terminal "sits in the plant network".
- 02Installation is one person's knowledge. DLLs copied into the JRE folder, registry entries made by hand – nothing documented.
- 03The vendor no longer exists or no longer maintains the product. Bugs stay, and every change needs a special arrangement.
- 04No audit trail, or an editable log. The last inspection made a remark about it.
- 05ERP integration by file or manual transfer. Two stock figures that have to be reconciled.
- 06New requirements fail: GHS display, a second scale, multi-batch orders, another language – every extension is a project or impossible.
Two of these justify a risk assessment; with four, the question is no longer whether to switch, only when.
The risk assessment QA expects
Assess patient safety and product quality (can the terminal allow a wrong dispense?), data integrity (is the record complete, attributable, unalterable?), availability (what happens on hardware or software failure? Is there a spare?) and knowledge risk (who can operate the system if one person leaves?). The result justifies the switch – or a conscious continuation with compensating measures. What GMP expects of the dispensing record is listed under GMP weighing and dispensing software.
Requirements for new weighing terminal software
| Requirement | Why |
|---|---|
| Vendor-independent scale connectivity (standard serial protocols) | Keep existing scales; no lock-in |
| Operation without client installation (browser) | Bench PC replaceable; no rollout effort |
| Separation of UI / device access / server | Failure behaviour definable; one server per plant instead of software on every terminal |
| Server-side tolerance check | Cannot be bypassed, verifiable |
| Tamper-evident audit trail | Annex 11 / ALCOA+ |
| Signed, traceable updates | Change control instead of "copy a file" |
| Outbound connection from the bench | No inbound firewall rules in the plant network |
| Documented installation | Operation without a key person |
| Same workflow as today | Operator acceptance, less training and validation effort |
How a terminal application compares with other kinds of weighing scale software is mapped on the overview page.
Migration without changing the process
The biggest switching cost is rarely technical – it is training, SOP changes and re-qualification. Both drop sharply when the new application reproduces the existing workflow and its behaviour is demonstrated against the legacy system – not against a specification someone wrote from memory. Recommended path: capture the as-is workflow → pilot bench with a defined period → compare old and new records → risk-based qualification → cutover with a rollback plan. A formal parallel run is possible but costly; what matters most is that for every batch it is clear which system provides the leading record. More on planning the move in weighing application software.
Part 2 · How d-dispensing is built
How d-dispensing is built
d-dispensing is exactly such a terminal application – in daily use at several manufacturers since 2015, with several million production orders processed. Every release goes through hundreds of automated tests before it ships. The workflow stays; the technology stays modern and maintainable.
- Scales: serial industrial scales from Mettler Toledo, Sartorius, RHEWA and more; the driver layer makes further manufacturers easy to add, without touching the terminal. Labels as ZPL to Zebra network printers.
- Operation: full-screen browser, touch- and scanner-friendly, light/dark mode per bench; nothing to install in the browser. German UI today, built for further languages.
- Architecture: one site server per plant (orders, tolerances, audit trail, ERP booking), one small station agent per bench (scale, printer, local store).
- Tolerances: server-side – 104 % of remaining per weighing, 98–102 % position closure, warnings at 50 %/95 %.
- Audit trail: hash-chained, with timestamps, reasons, checkpoints and export.
- Updates: Ed25519-signed manifests; signature, size and checksum verified before installation; never activated during an open weighing – only at the station's next start.
- Network: the station agent connects outbound only. On network loss the weighing in progress finishes, is stored locally and booked idempotently later; new orders need the server.
- Installation: manual today (JDK + application), documented in the administration guide; a signed Windows installer is on the roadmap. The licence check works offline and never stops a weighing.
FAQ
Frequently asked questions
Next step
How to proceed
- Management / purchasing: Ten-question list in the FAQ; a demo on your own orders.
- IT / production: Administration and installation guide under Support; try the live terminal.
- QA: Request the QA & compliance brief.