De kick-off verwerkt, de aanpak aangescherpt en elke mijlpaal op datum. Zo bewijzen we in twaalf pilotweken dat dynamisch plannen via pull werkt.
TDS-data is gepseudonimiseerd en alleen bruikbaar voor drukte- en turnaround-statistiek. Voor de ETA per truck werken we de route uit via GPS van het toestel, met de check-in in de Port Alert-app als koppelmoment. Voorwaarde: chauffeurs checken vroeg in en delen GPS; adoptie en instructie van de pilotgroep zijn daarmee onderdeel van het ontwerp. AVG-kader stemmen we af met het Port Alert-team.
Refresh-bots claimen vrijgekomen tijdsloten binnen seconden. Lezen doen we via de Tracking API, maar vasthouden vraagt meer: óf de dynamische planner zit in de berichtenstroom (gate of vlag via MCA), óf de terminal borgt de vrijgevallen plek zelf met een kleine regel of reservering. Welke vorm, is dé keuze van fase 1; wij hebben de varianten werkend naast elkaar gezet.
De process flow is het totaalbeeld, de PoV wordt een bewust gekozen subset. We verkennen opties, vergelijken ze op impact en doorlooptijd, en leggen de keuze vast in een PRD dat alle partijen accorderen. RWG en APMT-II verschillen wezenlijk in planniveau; dat weegt mee.
Het formele akkoord van de Werkgroep Dynamisch Plannen is er en de overeenkomst is getekend. De presentatie aan de werkgroep verschuift naar het moment dat de gekozen aanpak en architectuur staan, zodat we daar met een gedragen voorstel komen.
De vier ontwerpprincipes uit die aanbieding blijven onverkort staan: vroeg integreren, iteratief verfijnen op werkelijke data, fail-safe met de handmatige planning als terugval, en de meetstructuur vanaf dag één van de pilot.
| Onderdeel | In de aanbieding | Na de kick-off |
|---|---|---|
| Truck-locaties | Truck-locaties via TDS, gecombineerd met HERE Routing buiten het havengebied | GPS van het toestel via de Port Alert-app, met de check-in als koppelmoment; TDS alleen voor drukte- en terminalstatistiek |
| Slot-vrijgave | Tijdelijke cancellation via MCA Road binnen het respons-window | Cancel en hertoewijzing als één beweging of geflagd bericht, zodat refresh-bots het slot niet kapen; wij luisteren mee op de Tracking API |
| Triggers | Twee pull-triggers: gemiste ETA en extra terminalcapaciteit | Vier varianten uit dezelfde familie; afhandeling per variant leggen we vast in het PRD |
| Fase 1 | Drie weken ontwerp en architectuur op basis van bekende koppelvlakken | Vier weken verkenning met RWG, APMT-II, Portbase en Port Alert, uitmondend in een door het consortium geaccordeerd PRD |
| Scope | Vooraf beschreven oplossing conform de procesflow | Bewust gekozen subset vanuit het eindbeeld, vergeleken op impact en doorlooptijd per systeem |
| Werkgroep | Formeel akkoord als eerste mijlpaal in fase 0 | Commitment al binnen; presentatie mét gekozen oplossingsrichting na fase 1, medio augustus |
Om de richting-keuze niet op papier maar op bewijs te maken, hebben we het skelet van het pull-concept gebouwd: een dynamische planner die we gebruiken om de cases te valideren en te testen tegen een digitale nabootsing van MCA, terminal-TOS en Port Alert (op basis van de publieke Portbase-specificaties), zonder dat er al testkoppelingen nodig zijn.
Alle vier de vrijval-triggers, slot vasthouden, kandidaat-matching met spelregels en planner-verzoeken met reactietermijn. Eén cockpit met vijf rollen: regie, planner, terminal, chauffeur en de planner-motor zelf.
Elke koppeling draagt een herkomstlabel. De te-bouwen-lijst is per partij uitgewerkt tot concrete contractvoorstellen: valideren kan direct, zonder te wachten op testomgevingen of legal-doorlooptijd.
Dubbele waarheid, DP-uitval, de bot-race en handmatige botsingen zijn als herhaalbare testscenario's bewezen; elke run is exact reproduceerbaar en elk cijfer herleidbaar uit de event-logs.
Een vrijgevallen plek is binnen seconden weg. Elke richting beantwoordt dezelfde vraag: hoe blijft die plek héél even beschikbaar voor de juiste kandidaat? Een plek valt op vier manieren vrij (vervoerder cancelt, terminal weigert, truck redt het niet, terminal verhoogt capaciteit); vanaf dat moment is de afhandeling telkens gelijk.
| Richting | Kern in één zin | Ons oordeel |
|---|---|---|
| 1 · Volledige overname | Alle voormeldingen gaan eerst langs de dynamische planner; wij wijzen het tijdslot toe, de terminal accepteert | Zwaarste variant: veel MCA-bouwwerk en de DP moet de planregels van de terminal kennen; meer dan de pull nodig heeft |
| 2 · Rollend venster | Zelfde, maar alleen voor de komende X uur | Zelfde bezwaren, kleiner; mogelijk groeipad, geen startpunt |
| 3 · Vrijval-gate | Bij vrijval parkeert MCA korte tijd binnenkomende voormeldingen | Borgt niet volledig: berichten die al onderweg waren, verplaatsingen van bestaande visits en de eigen herplanning van de terminal glippen erdoor, en iedereen wacht intussen |
| 3+ · Onze toevoeging: terminal-borging |
De terminal beschermt de nét vrijgevallen plek zelf: een quarantaine-regel (X minuten alleen mét DP-vlag) of een kleine reservering | Onze aanbeveling om te verkennen: klein bouwwerk, eenmalig voor beide terminals (zelfde TOS); uit de vragenlijst: "nog niet overwogen, goede optie" |
| 4/5 · Quotum en blokgroep-splitsing | De dynamische planner krijgt een eigen deel van de capaciteit | Afgevallen: vrijval buiten het eigen deel is onbereikbaar, en APMT-II kent geen blokgroepen |
Alle varianten zijn per terminal instelbaar en in onze proefopstelling naast elkaar te demonstreren; het richting-besluit landt gezamenlijk in het PRD van 7 augustus.
| Vraag | Bron | Wanneer |
|---|---|---|
| MCA-effort per richting en haalbaarheid van de generieke lus (routering als configuratie) | Portbase · Delaja, 8 u/wk vanaf 20 juli | vóór 31 jul |
| Accepteren de terminals een quarantaine-vlag of hold-endpoint, en de detailregels (duur, eenheid-boekhouding, capaciteitsverhogingen) | RWG · APMT-II (terminalgesprekken) | vóór 31 jul |
| Zien wij de volledige voormeldingenstroom van de pilot-terminal, ook van niet-deelnemers (datascope) | Portbase · Port Alert | vóór 31 jul |
| Vrijval-cijfers (cancels, rejects, herboekingssnelheid): bestaan niet, wij meten zelf zodra leestoegang er is | Bonsai via de Tracking API | fase 1 |
| Secure Chain en carrier-binding: valt de placeholder-variant definitief af | Portbase | fase 1 |
| Check-in-telemetrie en realistische reactietijd van planners (bepaalt waarschuwingstijd en reactievenster) | Port Alert · plannergesprekken via Koen Masteling | fase 1 |
Alle vragen zijn belegd (vragenlijst en gespreksagenda); het richting-besluit landt gezamenlijk in het PRD van 7 augustus.
Wij stellen voor de finale oplevering twee weken te verschuiven naar vrijdag 11 december. Zo houdt de pilot de volle 12 weken én krijgt de bouw de zes weken uit de aanbieding, ondanks de latere start en de vakantieperiode. Dit wijkt af van de overeenkomst (vóór 30 november) en vraagt vandaag formeel akkoord.
| Datum | Mijlpaal | Meetbaar resultaat |
|---|---|---|
| di 14 jul | Herijkte planning geaccordeerd in de check-in | Alle partijen akkoord op data en aanpak |
| vr 24 jul | Eerste gespreksronde RWG, APMT-II, Portbase en Port Alert afgerond | Huidige situatie en beperkingen per systeem vastgelegd |
| vr 31 jul | Oplossingsrichtingen vergeleken | Voorkeursoptie per kernvraagstuk, getoetst op impact en doorlooptijd |
| vr 7 aug | PRD met architectuurplaat geaccordeerd · go/no-go fase 2 | Schriftelijk akkoord van alle consortiumpartijen |
| medio aug | Terugkoppeling Werkgroep Dynamisch Plannen | Gekozen oplossingsrichting gepresenteerd en gedragen |
| vr 18 sep | Bouw klaar · go/no-go live | Koppelingen end-to-end getest, testrapport en runbook opgeleverd |
| ma 21 sep | Pilot start in shadow mode | Systeem doet aanbevelingen op live data, zonder acties |
| ma 12 okt | Beperkt live bij de eerste terminal · evaluatiemoment 1 | Eerste echte pull-acties, rapportage tegen de nulmeting |
| vr 6 nov | Evaluatiemoment 2, halverwege de pilot | KPI-rapportage en besluit over uitbreiding naar tweede terminal |
| vr 11 dec | Finale oplevering en eindpresentatie · evaluatiemoment 3 | Eindrapport, code-overdracht en formele acceptatie |
| Periode | Wat er gebeurt | Resultaat |
|---|---|---|
| 13 t/m 17 jul | Voorwerk HbR en Port Alert verwerken; gesprekken inplannen met RWG (Peter Muller), APMT-II (Marc Hoogland), Portbase en Port Alert-team; antwoorden vragenlijst verwerken | Compleet beeld huidige situatie, gespreksagenda staat |
| 20 t/m 31 jul | Verdiepende gesprekken per partij; opties uitwerken voor locatiedata/ETA, capaciteit vasthouden, triggers en spelregels; toetsen op impact en doorlooptijd per systeem | Vergeleken oplossingsrichtingen met voorkeursoptie (vr 31 jul) |
| 3 t/m 7 aug | PRD met architectuurplaat afronden; akkoord ophalen bij alle consortiumpartijen; technische voorbereiding starten (omgeving, sandbox-toegang) | Geaccordeerd PRD, go/no-go naar fase 2 (vr 7 aug) |
Vakantieperiode is ingecalculeerd: gesprekken plannen we deze week zodat afwezigheid per partij tijdig zichtbaar is en werk kan worden overgedragen.
Ontvangen op 8 juli, dank daarvoor: gespreksverslagen en contactpersonen RWG en APMT-II, de technische flow, het werkdocument van Delaja en Tim, en de simulatiestudie van de TU Delft. De vragenlijst van vrijdag is uitgezet.
| Nog nodig | Van | Wanneer |
|---|---|---|
| Resterende vragenlijst-antwoorden, in elk geval de vragen met een ster (eerste antwoorden 13 juli ontvangen, dank) | HbR · Portbase · Port Alert | deze week |
| Validatie van onze nagebouwde MCA/PA-koppelvlakken en de te-bouwen-contractvoorstellen (overzicht staat klaar in de demo-omgeving; testtoegang kan later, voor de integratie) | Portbase · Port Alert | vóór 31 jul |
| Sessies MCA-impact per richting inplannen met Delaja (8 u/wk, terug 20 juli) | Portbase | vanaf 20 jul |
| PA-locatie-endpoint inplannen bij het team en een eigenaar voor de privacy/security-toets aanwijzen (wij gaan uit van een positieve uitkomst) | Port Alert-team · HbR | vóór 31 jul |
| Information Security Policy Standards document (relevant voor onze hosting) | HbR | deze week |
| Introductie bij (planners van) vervoerders uit de pilotgroep, via Koen Masteling | Portbase (Ron, Koen) | vóór 24 jul |
| Status nulmetingen RWG en APMT-II en de beschikbare dashboarddata | HbR · terminals | vóór 7 aug |
Vast uur met het kernteam: voortgang, blokkades en besluiten. Stakeholders sluiten aan wanneer relevant; Hans schuift periodiek aan als inhoudelijke sparringpartner.
Snel schakelen via het gezamenlijke Teams-kanaal met alle betrokken stakeholders; documenten delen we per mail. Bellen mag altijd.
Elke fase sluit met een formeel go/no-go. De Werkgroep Dynamisch Plannen informeren we zodra het PRD en de architectuur staan, zodat we daar concreet kunnen zijn. Besluiten lopen via Liselotte en Tim.
| Besluit of actie | Wie |
|---|---|
| Akkoord op de herijkte planning: PRD 7 aug, bouw klaar 18 sep, pilot 21 sep t/m 11 dec | Allen |
| Formele instemming met oplevering op vrijdag 11 december, twee weken na de contractuele datum | HbR (Liselotte/Tim) |
| Gesprekken RWG, APMT-II, Portbase en Port Alert deze week ingepland | Bonsai (Justus) · HbR |
| Akkoord om de GPS-route voor locatiedata uit te werken als voorkeursoptie voor de ETA | HbR · Port Alert-team |
| Datum prikken voor terugkoppeling aan de Werkgroep Dynamisch Plannen, medio augustus | HbR (Liselotte/Tim) |
| Openstaande leveringen bevestigen: vragenlijst en security-document deze week | HbR · Portbase · Port Alert |
| Toegang tot de demo-omgeving voor het team (rol-accounts, wachtwoord via 1Password) | Bonsai levert |
flowchart LR
T1[1 vervoerder cancelt] --> V[plek valt vrij]
T2[2 terminal weigert bezoek] --> V
T3[3 DP voorspelt dat de truck het slot mist] --> V
T4[4 terminal verhoogt capaciteit] --> V
V --> H[DP houdt de plek vast en zoekt kandidaten]
H --> P[planner van de kandidaat akkoord binnen reactievenster]
P --> U[kandidaat-update met DP-vlag naar de terminal]
U --> B[terminal bevestigt, oude slot van de kandidaat komt vrij]
sequenceDiagram
participant C as Vervoerder
participant M as MCA
participant D as DP
participant P as Planner kandidaat
participant T as Terminal-TOS
Note over C,T: reguliere stroom: elke voormelding gaat eerst langs de DP
C->>M: voormelding
M->>D: besluit gevraagd (de lus)
D->>M: toewijzing volgens capaciteit en spelregels
M->>T: voormelding met toegewezen tijdslot
T-->>M: accept (accept-afspraak)
Note over C,T: bij vrijval (een van de vier vormen, DP ziet het via Tracking, ETA of capaciteits-poll)
D->>D: houdt het venster vast in eigen administratie en scoort kandidaten
D->>P: voorstel eerder rijden (reactievenster)
P-->>D: akkoord
D->>M: toewijzing kandidaat naar het vrijgevallen venster
M->>T: voormelding-update met toegewezen tijdslot
T-->>M: accept
Note over M,D: fail-safe: geen DP-antwoord binnen N seconden betekent ongewijzigd doorsturen
sequenceDiagram
participant C as Vervoerder
participant M as MCA
participant D as DP
participant P as Planner kandidaat
participant T as Terminal-TOS
Note over C,T: reguliere stroom: alleen bezoeken binnen nu plus X uur gaan langs de DP
C->>M: voormelding
alt gevraagd venster binnen nu plus X uur
M->>D: besluit gevraagd (de lus)
D->>M: toewijzing
M->>T: voormelding met toegewezen tijdslot
T-->>M: accept (accept-afspraak)
else buiten het venster
M->>T: voormelding direct door, terminal wijst toe zoals vandaag
T-->>M: accept of eigen tijdslot
end
Note over C,T: bij vrijval (vier vormen, DP ziet het via Tracking, ETA of capaciteits-poll): identiek aan Volledige overname
D->>P: voorstel eerder rijden (reactievenster)
P-->>D: akkoord
D->>M: toewijzing kandidaat naar het vrijgevallen venster
M->>T: voormelding-update
T-->>M: accept
Note over D,T: overdrachtsrand: een bezoek dat het venster in schuift wisselt van schrijver
sequenceDiagram
participant C as Vervoerder
participant M as MCA gate
participant D as DP
participant P as Planner kandidaat
participant T as Terminal-TOS
Note over C,T: reguliere stroom: ongewijzigd, MCA direct naar de TOS
C->>M: voormelding
M->>T: direct door
T-->>M: accept of eigen tijdslot
Note over C,T: bij vrijval (vier vormen, DP ziet het via Tracking, ETA of capaciteits-poll)
D->>M: zet de gate aan voor X minuten
M->>M: parkeert voormeldingen en verplaatsingen (3a alles voor de terminal, 3b alleen wat het venster raakt)
D->>P: voorstel eerder rijden (reactievenster)
P-->>D: akkoord
D->>M: kandidaat-update met DP-vlag
M->>T: doorsturen
T-->>M: accept
Note over M,T: HET STRUCTURELE LEK: de TOS kent de hold niet en mag elk bericht dat hij verwerkt een ander slot geven dan gevraagd, dus ook de vrijgevallen plek
Note over M,T: klein restrisico: de race in de seconden voordat de gate dichtgaat
sequenceDiagram
participant C as Vervoerder
participant M as MCA
participant D as DP
participant P as Planner kandidaat
participant T as Terminal-TOS
Note over C,T: reguliere stroom: ongewijzigd, MCA direct naar de TOS, niets wordt geparkeerd
C->>M: voormelding
M->>T: direct door
T-->>M: accept of eigen tijdslot
Note over C,T: bij vrijval (vier vormen, DP ziet het via Tracking, ETA of capaciteits-poll)
alt quarantaine-vlag (staande regel)
T->>T: de TOS verwerkte de cancel zelf en beschermt de plek X minuten, alleen toewijsbaar met DP-vlag
else TOS-reservering (expliciete aanroep)
D->>T: reserveer venster W tot tijdstip T (mini-endpoint)
T->>T: reserved-status, venster niet uitgeefbaar
end
D->>P: voorstel eerder rijden (reactievenster)
P-->>D: akkoord
D->>M: kandidaat-update via het normale kanaal, met DP-vlag
M->>T: gevlagde update
T->>T: borging-check, vlag aanwezig, toewijzen
T-->>M: accept
M-->>D: accept via Tracking, daarna pas het oude slot van de kandidaat cancelen
Note over D,T: fail-safe: de regel dooft na X minuten, de reservering verloopt op zijn vervaltijd, ook als de DP dood is
sequenceDiagram
participant C as Vervoerder
participant M as MCA
participant D as DP
participant P as Planner kandidaat
participant T as Terminal-TOS
Note over C,T: reguliere stroom: ongewijzigd, MCA direct naar de TOS
Note over C,T: bij vrijval (vier vormen, DP ziet het via Tracking, ETA of capaciteits-poll)
D->>M: plaatshouder-voormelding op het vrijgevallen venster (regulier bericht)
M->>T: voormelding
T-->>M: accept, plek is nu gewoon bezet
D->>P: voorstel eerder rijden (reactievenster)
P-->>D: akkoord
D->>M: plaatshouder annuleren en kandidaat-update indienen (omzetten bestaat waarschijnlijk niet)
Note over D,T: het gat tussen annuleren en herboeken is exact de race die we wilden vermijden
Vermoedelijke blokkades: Secure Chain-nominatie en carrier-binding van voormeldingen; expliciet ter toetsing bij Portbase.
flowchart LR
subgraph cap [Capaciteitsquotum: capaciteit van een tijdslot]
A[terminal-deel, eerste X procent]
B[DP-deel, de rest]
end
V1[vrijval in terminal-deel] -->|onbereikbaar voor de DP| A
V2[vrijval in DP-deel] -->|pull-afhandeling| B
flowchart LR
subgraph term [Blokgroep-splitsing]
G1[blokgroep Noord, DP-domein]
G2[blokgroep Midden en Zuid, terminal-domein]
end
V3[vrijval in Noord] -->|pull-afhandeling| G1
V4[vrijval in Midden of Zuid] -->|onbereikbaar voor de DP| G2
Het overgrote deel van de vrijval gebeurt in het terminal-domein en is voor de DP onbereikbaar; blokgroep-splitsing strandt bovendien op APMT-II (geen blokgroepen). Daarom afgevallen als startpunt.