DS DOCK:SCHEDULER
Technology, integration, operations

DockScheduler runs without an ERP system.

Wherever an external system connects, there is a field for its identifier; the application never assigns it and never uses it in calculations. There is no off-the-shelf connector for any specific ERP.

Runtime
.NET 10, ASP.NET Core
User interface
Blazor with DevExpress
Database
SQL Server or PostgreSQL
Operations
Windows with IIS or Linux
Architecture

Three components sharing one database.

All business logic resides in the core. The UI and interface are thin layers on top. Therefore, the same rules apply whether a booking is made via the portal, the internal screen, or the interface.

Core Class library
Data model and business logic.
Web Web application
All screens and the interface.
Service Background service
Watcher for no-shows and reminders. Runs as a separate process so that restarting the UI does not interrupt watcher runs.
Interface

Two interfaces, two counterparts.

An ERP system asks for time slots and bookings. A yard device reports what it sees and asks what to do. These are two conversations with different counterparts, and they use separate keys.

For your ERP system
{{ w.verb }} {{ w.pfad }}
{{ w.zweck }}
For your yard devices
{{ w.verb }} {{ w.pfad }}
{{ w.zweck }}

A rejection is not an error. It arrives as a successful response with a reason, not as an error code. An exhausted quota is not an invalid request.

Order import is repeatable. The document number from the external system is the key; the same document updates the existing record instead of creating a duplicate.

Yard devices

The truck pulls up. The camera reads the license plate. Then the camera does not make the decision.

A license plate reader reports what it read and receives a decision in return: admit, wait, or reject, each with a reason in plain text. The decision is made just like at the gate: the license plate is used to find the booking.

License plate reader, barrier, display board, scale, and terminal can be connected via a dedicated interface. It has not yet been tested against real hardware; the first integration will happen at a pilot site as a dedicated project, together with the hardware vendor.

Admit
There is a booking for the license plate, and the vehicle is no more than one hour early. The appointment is checked in; the barrier at this entrance receives its command.
Wait
Too early, or without a booking. The vehicle is recorded and visible in the control center, but a human makes the decision.
Reject
No license plate recognized, or the vehicle is already in the yard. A duplicate reading does not trigger a second opening.
No entry without a booking
The vehicle is still recorded; otherwise it would be missing from all reports. But a barrier that lets unregistered vehicles in is no barrier at all.
Commands are polled, not pushed
Your equipment polls whether anything is pending for it, requiring only outbound connections to DockScheduler.
Open commands expire
It expires after two minutes. A barrier that wakes up after a network outage and opens is more dangerous than one that does nothing.
Each device has its own key
Firmly tied to a location, optionally also to a dock. A reader at the North entrance cannot check in for another plant, not even after swapping cables.
Languages

Eleven languages outside, four inside.

Portal, login, registration, the driver page, and text messages to the driver are available in German, English, French, Swedish, Polish, Romanian, Lithuanian, Czech, Hungarian, Bulgarian, and Slovak. The selection reflects long-distance transport into Germany; French and Swedish were added with the first target markets. The internal screens are available in German, English, French, and Swedish.

In the portal, the user decides
A language selector in the header whose selection persists. Without a selection, the browser setting applies.
For the driver, the booking decides
The carrier sets the language when booking; if a driver is assigned, their preference applies. The phone might be set to something else; the booking record is what counts.
Rejections are also translated
Not just labels. A reason nobody can read does not prevent a single phone call.
Numbers and dates follow the language
Everyone sees dates and numbers in their familiar format. Only the CSV export retains German settings so Excel parses numbers correctly.

Security

Two separate login procedures
Windows login or a dedicated password internally; dedicated access for carriers externally. External access grants no access to internal screens.
Hashed passwords
Carrier credentials are never stored in plain text.
The driver page requires no account
The link carries an access token for each booking.
Documents with checksums
The content is stored in the file system, the checksum in the database. This allows determining whether a file was modified after the fact.
Every process is traceable
Bookings and status changes write a dedicated row with timestamp and author. There is no silent overwriting.

What is missing today

These points belong in the discussion, not swept under the rug.

  • No customer in production. Therefore, there are no figures on waiting times or savings.
  • No roles and permissions. The internal screens require a login: always with a password, optionally with Windows authentication. Anyone logged in sees everything. If Windows login is not enforced, anyone on the network who knows the address sees everything. Roles and permissions will be added before any live operation, meaning before your pilot.
  • HTTPS and installation security. Roles and permissions will be added together. The website, demo, and free trials run over HTTPS; the in-house test environment does not. A certificate must be provided for a customer installation.
  • Devices not tested with real hardware. The interface for license plate readers, barriers, displays, scales, and terminals is ready. Its business logic is automatically tested, and the flow from reading to receipt has been walked through manually. The first integration takes place during a pilot as a dedicated project, together with the hardware vendor. Traffic lights, induction loops, dock locks, and badge readers have no interface.
  • Notifications via SMS only. Emailing carriers and drivers will follow the first pilot.
  • No automatic rescheduling. If a dock fails, the application does not reschedule anything on its own.
  • No waitlist, no recurring bookings. Neither is modeled.
  • No site map. There are lists and occupancy bars. DockScheduler does not manage trailers, parking spaces, or shunting movements.
  • No staff or equipment planning. Shifts, forklifts, and qualifications are not factored into time slot calculations.
  • No ready-made ERP connector, no EDI, no file interface. Rescheduling is missing from the UI and via the interface; the interface also lacks write access for yard control.
  • No hosted service. Tenants only exist for free trials, each with its own database and locked after 30 days. An installation at a customer serves one customer.
Operations

A maintenance window of a few minutes is enough.

Web application in IIS, one Windows service, one database. On Linux, the web application and service run as systemd units behind nginx. The configuration resides next to the application and is not overwritten during deployment. Updates: replace files, restart application and service.

Quality assurance
266 Automated tests
As of 25 September 2026

They test the business logic against SQL Server, the free trials against PostgreSQL, deliberately not against an in-memory substitute: the lock that prevents duplicate bookings does not exist there at all. The interface flows have been walked through manually.

Schedule a demo

Half an hour, with your docks.

We walk through the process on our test system with your docks, operating hours, and restrictions, plus status, roadmap, and the pilot offer.

Or: 30-day free trial

Email
dock-scheduler@brendel-software.de
Write email
Phone
+49 5281 61094-69
Address
Brendel Software GmbH & Co. KG
Am Sonnenhof 12, 32676 Lügde, Germany