Toelichting release notes
...
Release notes Optimizer week 37 - 2024
Performance
Model upgrade Nieuw model van de optimizer zorgt voor meer rekenkrachtWe hebben een upgrade uitgevoerd op
Zie ook: Hier werken wij aan - Upgrade v2024.2 en verhogen naar 4 cores
In de afgelopen maanden is er hard gewerkt aan een model upgrade van de optimizer. Met deze upgrade het uitzicht op nieuwe deelnemers kunnen we meer rekenkracht toevoegen aan de optimizer. Dit zorgt voor snellere berekeningen. Doordat de berekeningen sneller worden, kunnen we ook meer berekeningen maken. Hierdoor gaat het optimaliseren van de integrale planning beter.goed gebruiken. Met deze upgrade kunnen er meer berekeningen en complexe puzzels tegelijkertijd uitgevoerd worden. Zo zorgen we steeds meer voor een toekomstbestendig algoritme.
Nieuw
Nieuwe optie toegevoegd bij een prio call: Verplichte kadeZoals bij de meeste gebruikers bekend is, geeft een terminal bij een prio call een specifieke tijd mee waarop deze afgehandeld moet worden. Vanaf nu is er een nieuwe optie toegevoegd aan een prio call, waarbij de terminal zowel een tijd als een specifieke kade (beschikbaarheid) mee kan geven. Dit is toegevoegd omdat bepaalde schepen ergens anders op de kade niet terecht kunnen. Dit komt o.a. door stuwage technische zaken of omdat deze kade dusdanig ingericht is voor bepaalde grote calls dat de rest van het barge programma er geen last van ondervindt.voor terminals: call wegplannen naar unieke bolderpositie
Zie ook: Hier werken wij aan - Call wegplannen naar unieke bolderpositie
Op basis van een klantvraag hebben we een functionaliteit toegevoegd die ervoor zorgt dat een call op een unieke bolderpositie gepland kan worden door terminal planners. Het komt namelijk voor dat bepaalde calls op een unieke positie aan de kade gepland moeten worden vanwege bijv. locatie containers, ruimte stack, type kraan, type containerspreader. Hiermee wordt ervoor gezorgd dat er geen onnodig intern transport plaatsvindt bij de terminals. Dit resulteert in een betere benutting van de capaciteit voor de gehele containerbinnenvaart.
In de kadeplanning is dit voor iedereen alle gebruikers inzichtelijk gemaakt, zodat iedereen weet wanneer er een prio call gegeven is op een specifieke beschikbaarheid. is toegewezen aan een unieke bolderpositie binnen een tijdswindow.
Voor de terminal werkt het de functionaliteit als volgt:. Bij het toevoegen van beschikbaarheid kan je vanaf nu het vinkje “Is een verplichte kade” aanklikken. Vervolgens moet selecteer je een de call selecteren die je wil plannen op dat stukje kadedie beschikbaarheid.
...
Op de kadeplanning heeft de deze beschikbaarheid een zigzag patroon. Verder is in de hoek te zien voor welke call de beschikbaarheid is aangemaakt. De barge operator en schipper kunnen dit ook zien.
...
LET OP!
Als de call de optie voor een verplichte beschikbaarheid kade mee krijgt MOET , móet de optimizer deze call op deze beschikbaarheid gepland wordenplannen. Als de beschikbaarheid niet lang genoeg is, of de tijden kloppen niet met de scope-in, dan kan de call niet gepland worden.
Er kunnen geen andere calls gepland worden op deze beschikbaarheid dan de verplichte call. De lengte van de beschikbaarheid moet dus precies minimaal overeen komen met de call. Als er een paar uur
Is er voor of na de call extra vrije capaciteit
...
, moet deze apart aangemaakt worden zonder het vinkje “Is een verplichte kade”.
Grace period (toegestane overlapping in de eerste 8 uur) nu ook buiten beschikbaarheid
Er was nog geen overlappingsperiode mogelijk aan het einde van een beschikbaarheid. Als er sprake was van een buitenbeschikbaarheid van bijvoorbeeld 1 minuut, dan werd de volgende call al meteen weggepland. Een Deze korte uitloop wordt vanaf nu ook geaccepteerd.
Per terminal is een totale duur vastgesteld van hoe lang een buitenbeschikbaarheid + overlap mag zijn. Bij ECT en RWG is dit 45 minuten, bij de andere terminals 30 minuten. Dit geldt alleen voor calls die in de komende 8 uur gepland zijn.
Betere keuzes van de optimizer voor het oplossen van problemen
Zie ook: Hier werken wij aan – Slimmere selectie scenario’s
Aanpassing prioritering van de optimizer
Als er een call in overlap of buitenbeschikbaarheid ontstondbuiten een beschikbaarheid gepland stond, ging de optimizer zich hier op focussen voor een oplossing. Bij het inschieten aanmaken van een nieuwe rotatie bleef de optimizer daar echter op focussenzich focussen op de oude calls, waardoor de nieuwe rotatie in de wacht werd gezet en niet gelijk werd ingepland. Dit bleek soms te lang te duren en daardoor niet wenselijk. Daarom , daarom hebben we er nu voor gezorgd dat de optimizer eerst aan de slag gaat met het inplannen van de nieuwe rotatie en daarna verder gaat met de overlap of buitenbeschikbaarheid.
Minder focus op onplanbare prio calls
De optimizer had heeft een extra focus op het opnieuw inplannen van prio calls, terwijl een prio call soms helemaal niet ingepland kón kán worden door bijvoorbeeld onvoldoende beschikbaarheid. Daarom wordt er vanaf nu eerst gecontroleerd door de optimizer of een de prio call calls überhaupt ingepland kan kunnen worden. Als dat niet mogelijk is, wordt er nu van tevoren een operationele waarschuwing gestuurd naar de planners. Hierdoor kunnen zij eerder actie ondernemen om te voorkomen dat een prio call niet of te laat wordt ingepland.
Performance verbeteringen
Als er een overlap is tussen twee calls op de kade is dit een planprobleem. Hetzelfde geldt voor een call die niet (volledig) in een beschikbaarheid gepland ligt. De optimizer probeert deze planproblemen zo’n planprobleem met een speciale berekening op te lossen. Er is een aantal verbeteringen doorgevoerd waardoor deze planproblemen sneller en beter opgelost worden.
Bugs
Barge onbeschikbaarheid
Een bug in het doorsturen van onbeschikbaarheden zorgde ervoor dat incidenteel Onbeschikbaarheid barge kwam niet goed door
We kregen een melding dat een onbeschikbaarheid van een barge soms niet goed doorkwam . Dit is in het systeem. Deze bug bleek in de optimizer te zitten en is nu opgelost. Onbeschikbaarheden komen nu altijd goed door.
...
Geen verschuiving door vertraging in sluiting los-/laadlijst
Momenteel wordt het sluiten van de los-/laadlijst gedaan in MCA Barge. Echter zit er ook een check in de optimizer of deze is gesloten. Dit vindt in beide systemen op hetzelfde moment plaats. Aangezien het berichtenverkeer tussen de systemen enkele minuten in beslag kan nemen levert dit in bepaalde gevallen een kleine verschuiving van een call op in de optimizer. De los-/laadlijst is daar dan nog niet gesloten, maar wel in MCA Barge. Met het deactiveren van dit mechanisme kan deze onnodige verschuiving niet meer voorkomen.
Duidelijke operationele waarschuwing (nog niet live, deze change zorgde voor problemen in de Optimizer. Zodra dit is opgelost, kan deze change ook live).
In te veel gevallen ontvang je nu als gebruiker (barge operator en terminal) de algemene melding “Deze rotatie kan niet worden gepland” voor een issue met de TEU balans. Deze rotaties worden nu één keer extra opgepakt door de optimizer zodat er een specifieke melding wordt gegenereerd met een duidelijke reden.
...
Voor de eerste call in een rotatie zat een bug waarbij de vaartijd niet werd meegenomen, deze is nu opgelost.
Extra triggers voor het in de juiste volgorde zetten van NCT calls (nog niet live, deze change zorgde voor problemen in de Optimizer. Zodra dit is opgelost, kan deze change ook live).
Voor rotaties met enkel niet-deelnemende terminals (NCT) was het aantal ‘triggers’ om de calls in de juiste volgorde te zetten beperkt. Gezien de beoogde opschaling met vletwerk kan dit in de toekomst vaker voorkomen en daarvoor zijn er nu meer van dit soort ‘triggers’ toegevoegd. Hiermee wordt de volgorde heroverwogen bij het door de BO aanpassen van de call size of call window op een call.
...