Toelichting release notes
...
Ga naar:
| Table of Contents |
|---|
...
Release notes Nextlogic Optimizer week 28 - 2024
Lineair doorschuiven
Afgelopen maanden hebben we gewerkt aan lineair doorschuiven. Dit houdt in dat calls die gepland liggen tussen nu en 4 uur recht naar achter doorschuiven bij een vertraging in operatie. In andere woorden de volgorde van calls op de kade met een geplande starttijd tussen nu en 4 uur houden we vast.
Er zijn uitzonderingen op deze regel. De werking en de uitzonderingen staan hieronder in scenario’s uitgelegd.
Standaard situatie
In de standaard situatie schuiven calls door bij uitloop op de eerste barge.
Voorbeeld scenario:
Vogue, Amazone en CTT liggen achter elkaar
Vogue loopt uit
Amazone en CTT schuiven lineair door naar achter
...
2e call in rotatie ligt ook binnen de twee uur
Als er twee calls van dezelfde rotatie binnen de bevries periode van 4 uur liggen, ligt de tweede call niet vast in volgorde.
Voorbeeld scenario:
Ensemble ligt gepland op RWG en daarna op Euromax. Beide starttijden liggen binnen de 4 uur grens
Op RWG loop de call van de Ensemble uit waardoor ze ook doorschuift op Euromax
Omdat de call op Euromax de tweede call is in de rotatie schuift die naar achter
De Roermond Max kan naar voren worden gepland.
...
De eerste 4 uur beschikbaarheid wordt weggehaald
Wanneer de eerste 4 uur aan beschikbaarheid wordt weggehaald, worden alle calls herpland. Calls die een nieuwe planning krijgen en daardoor een starttijd hebben buiten de eerste 4 uur worden niet meer op volgorde vastgehouden. De volgorde kan dus veranderen. Calls die binnen de 4 uur gelegen hebben krijgen wel een kenmerk dat ze daar gepland zijn geweest. Met dit kenmerk proberen we de call zo vroeg mogelijk tegen de originele tijd te plannen.
Voorbeeld scenario:
Er liggen drie calls gepland binnen nu en 4 uur
4 uur kade beschikbaarheid wordt weggetrokken
Alle drie de calls worden vrij opnieuw gepland, ze krijgen allemaal een vlaggetje met de origineel geplande tijd
...
Prio’s en fixed windows
Fixed windows en prio’s worden niet meegenomen in lineair doorschuiven. Een fixed window en een prio moet altijd in haar window worden afgehandeld (tenzij dat onmogelijk is door externe factoren als wind).
Voorbeeld scenario:
La terna ligt voor het fixed window van de Oxford die aan het einde van haar window ligt en dus niet meer naar achter kan
Alfa Rosso loopt uit waardoor de Oxford buiten haar window wordt gepland
Oxford wordt achter de Alfa Rosso gepland zodat de fixed window eindtijd wordt gehaald
As de Oxford een prio zou hebben in plaats van een fixed window zou dit hetzelfde werken.
Calls schuiven alleen door over dezelfde bolder positie
Voorbeeld scenario
Er liggen twee beschikbaarheden op RWG, voor twee verschillende kranen
De rechter beschikbaarheid wordt weggetrokken waardoor de Roermond max niet meer past in de beschikbaarheid
De Hyade schuift door naar deze beschikbaarheid en de Roermond max wordt naar een later tijdstip herpland
Performance
We hebben twee veranderingen doorgevoerd om de performance van de Optimizer te verbeteren. Als eerste is de snelheid van het versturen van planningen verbeterd. Dit zorgt ervoor dat de optimizer hier minder tijd mee kwijt is en meer tijd kan besteden aan andere berekeningen. Als tweede hebben we een verbetering doorgevoerd in de puzzel die de optimizer constant aan het maken is. Beide performance verbeteringen individueel hebben een klein effect. Door continue kleine verbeteringen door te voeren krijgen we uiteindelijk wel een significante performance verbetering in snelheid.
Bugs
Relevante input doorsturen bij planprobleem
In de vorige release verminderden we het aantal berichten naar de Optimizer. We zagen dat het langer duurde om een planprobleem op te lossen als er steeds niet relevante input voor de oplosbaarheid van het planprobleem naar de Optimizer werd gestuurd (Bijvoorbeeld de containervolgorde). We hebben in deze release weer een paar triggers toegevoegd die relevant zijn om het probleem wel op te kunnen lossen (bijvoorbeeld het verwijderen van een call of een restrictie verandering).
Volgorde van calls bij een TEU wijziging
Een TEU wijziging op een call kan ervoor zorgen dat de volgorde van je rotatie moet veranderen. Bijvoorbeeld omdat je ineens een stuk meer gaat laden, waardoor je eerst moet lossen voordat de lading erin past. Deze wijziging werd niet altijd snel en goed opgepakt. We hebben een fix doorgevoerd waardoor de volgorde sneller wordt aangepast.
Release notes Optimizer week 25 - 2024
...
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.
...