Toelichting release notes
...
Ga naar:
| Table of Contents |
|---|
...
Release notes Nextlogic Informatie Platform & Optimizer week 52 - 2024
Nextlogic Informatie Platform
‘Vroegste start TO’ werkt weer naar behoren
Na een vorige release ontstond er helaas een fout bij het invoeren van de ‘Vroegste start TO’. De voorbereidingstijd werd namelijk niet meer overschreven. Dit is met deze release weer opgelost. De ‘Vroegste start TO’ kan nu de voorbereidingstijd weer overschrijven en is hiermee leidend voor wanneer een call zou kunnen beginnen. Tenzij de ‘Vroegste start BO’ is ingevuld, dan is deze uiteraard leidend.
Visuele weergave verbeterd in schippersscherm voor vaartijden en afstanden
In het schipperscherm kon het voorkomen dat de vaartijden en afstanden niet altijd overeenkwamen met de daadwerkelijk af te leggen afstand. Op de achtergrond voor de rotaties werd er gelukkig wél met de juiste gegevens gerekend. Het ging enkel om de visuele weergave, wat verwarrend was voor de gebruiker. Dit is nu opgelost en hiermee zouden de vaartijden en afstanden tussen de bezoeken weer goed getoond moeten worden.
Alle terminal gebruikers kunnen nu incidentele sluitingen toevoegen
Tot nu toe was het alleen mogelijk voor terminal admins om incidentele sluitingen toe te voegen. Deze optie wordt gebruikt als de terminal dichtgaat voor bijvoorbeeld een IT update of kortdurend onderhoud. Vanuit verschillende terminals hebben wij het verzoek gekregen om dat breder te trekken. Vanaf nu hebben alle terminal gebruikers de mogelijkheid om incidentele sluitingen toe te voegen.
Het toevoegen van incidentele sluitingen werkt als volgt:
Ga met je terminal account naar de pagina voor ‘Locaties/Locations”.
Klik door naar jouw terminal, waarmee je vervolgens bij de instellingen en informatie van jouw terminal terecht komt. Je ziet hier alle instellingen
Klik op het potloodje om te kunnen bewerken. Dan kom je in een scherm waarbij je alleen de sluitingen kan aanpassen. De rest van de instellingen blijft gelijk staan.
Klik op ‘Incidentele sluiting toevoegen/Add incidental closing’. Dan krijg je een nieuwe regel om de details in te vullen voor het aanmaken van de incidentele sluiting.
Belangrijk: let goed op dat alle gegevens correct zijn ingevuld en het schuifje zo staat dat ‘Gesloten/Closed’ zichtbaar is.
Klik op de knop ‘Opslaan/Save’, anders wordt de wijziging niet doorgezet.
Deze uitzondering is vervolgens ook te zien op de locatie pagina onder ‘Details’, bij de subkop ‘Uitzonderingen’.
Let op: na het toevoegen van de incidentele sluiting moet de terminal operator ook altijd in de kadeplanning de beschikbaarheid opnieuw opslaan die overlapt met de incidentele sluiting. Anders gaat dit niet goed in de integrale planning.
Optimizer
Stapsgewijs naar meer betrouwbaarheid en zekerheid
We hebben belangrijke stappen gezet in het verhogen van de betrouwbaarheid en zekerheid van de planning.
Allereerst hebben we in de kennissessie met barge operators en terminals een concept uitgedacht hoe we naar een betrouwbaardere planning kunnen komen. Dit concept hebben we uitgewerkt in concrete systeemverbeteringen. Hiervan is de basis opgeleverd. Vanuit deze basis gaan we verder finetunen met relevante praktijkvoorbeelden.
...
Uitleg
In de eerste 6 uur voor de start van de operatie plannen we alleen met noodzakelijke optimalisatie. Dit houdt in dat de volgorde van de calls waarin ze gepland liggen wordt vastgehouden en bij uitloop wordt er lineair doorgeschoven. Deze werking hebben we in eerdere communicatie “lineair opschuiven” genoemd en staat al een tijd lang live.
Tussen de 6 en 30 uur werken we met gelimiteerde optimalisatie. Dit houdt in dat de volgorde van calls op de kade nog kan verschuiven, maar dat hier wel een limiet op zit. Als er verder geen verstoringen zijn, dan zal de planning alleen veranderen als dat voor iedereen beter is.
Na 30 uur vanaf de start van de operatie maken we gebruik van vrije optimalisatie. Dat is en blijft de huidige werking. Omdat er na deze tijd geen zekerheid gegeven kan worden op zowel capaciteit als scope-in tijd, container aantallen etc. Daardoor is het ook niet mogelijk om met gelimiteerde optimalisatie te werken, maar levert de huidige werking de beste planning op.
Automatisering van de testomgeving
Zie ook: Hier werken wij aan / Automatiseren van de testomgeving
Om de optimizer continu te blijven verbeteren zijn veel analyses nodig om te zien waar de verbetermogelijkheden het grootst zijn. Om dit te doen hebben we voortdurend nieuwe data nodig. Met deze release hebben we een stuk van het analyse- en testwerk geautomatiseerd, zodat de oplossingen voortaan nog beter aansluiten op de wensen van de markt.
...
Release notes Optimizer week 47 - 2024
In deze release van de Optimizer hebben we een verdere aanscherping doorgevoerd in de verdeling van de wachttijd van schepen bij een terminal. Dit hebben we gedaan door meer onderscheid te maken in hoeveel een schip te laat gepland is.
Voorheen: Als alle schepen op één terminal later dan gewenst gepland waren, dan zag de Optimizer deze schepen als uitwisselbaar. De Optimizer maakte in sommige situaties niet voldoende onderscheid tussen deze te late schepen, ongeacht hoeveel te laat een schip gepland was.
Nu: Er is meer onderscheid gemaakt tussen verschillende gradaties van te late schepen. Dit zorgt ervoor dat alle schepen de vertraging evenveel ervaren. Dit betekent dat als alle condities gelijk zijn, de calls die het langst wachten als eerste worden gepland (first come, first serve principe).
...
Release notes Optimizer week 40 - 2024
Verbeterde werking van de optimizer
Zie ook: Hier werken wij aan – Performance improvements
In deze release hebben we ervoor gezorgd dat het systeem sneller werkt. Als gebruiker zal je merken dat calls die elkaar overlappen, sneller goed gezet worden. Ook worden calls die buiten de beschikbaarheid vallen, sneller verplaatst naar een beschikbare tijd. Met deze optimalisatie zorgen we ervoor dat alles steeds beter en klaar voor de toekomst is.
Verbeteringen aan wachtlocatie
Zie ook: Hier werken wij aan – Tijdelijk parkeren van onmogelijke vraag
Vorig jaar hebben we de wachtlocatie (ook wel: waiting area) geïntroduceerd. (Zie release notes Week 2 – 2024). Naast dat je in de kadeplanning kan zien wanneer je op een wachtlocatie gepland ligt, krijg je vanaf nu ook een operationele waarschuwing die getoond wordt in zowel het platform van Nextlogic als in MCA Barge en de schippersschermen. Door deze informatie weet je dat die call sowieso nog naar een reguliere beschikbaarheid gepland wordt, en dus een andere tijd krijgt.
Wachtlocatie als operationele waarschuwing:
...
Wachtlocatie in kadeplanning:
...
Eerst behandelde de optimizer de wachtlocatie hetzelfde als een reguliere beschikbaarheid in de planning. Daardoor kon het gebeuren dat een afspraak op de wachtlocatie terecht kwam, terwijl er voldoende ruimte was in de reguliere planning. Nu hebben we het systeem zo aangepast dat afspraken minder vaak op de wachtlocatie worden gezet als er nog plek is in de reguliere planning. Hierdoor wordt de wachtlocatie alleen gebruikt wanneer het echt nodig is.
Wat is een wachtlocatie? Dit is tijdelijke beschikbaarheid die je terugziet in de kadeplanning en ontstaat bij terminals die veel vertraging ondervinden. Deze tijdelijke beschikbaarheid wordt ingezet om alle aangevraagde calls tijdelijk in te kunnen plannen. Dit voorkomt dat het planningsproces vastloopt wanneer er te weinig reguliere beschikbaarheid is bij de terminals. De wachtlocatie is altijd op dag 5 of 6. Uiteindelijk zal de barge worden ingepland op een reguliere beschikbaarheid, aangezien de wachtlocatie een tijdelijke oplossing is.
...
Release notes - Q3 2024
Release notes Optimizer week 37 - 2024
Performance
Nieuw model van de optimizer zorgt voor meer rekenkracht
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 het uitzicht op nieuwe deelnemers kunnen we meer rekenkracht 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 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 alle gebruikers inzichtelijk gemaakt, zodat iedereen weet wanneer er een call is toegewezen aan een unieke bolderpositie binnen een tijdswindow.
Voor de terminal werkt de functionaliteit als volgt. Bij het toevoegen van beschikbaarheid kan je vanaf nu het vinkje “Is een verplichte kade” aanklikken. Vervolgens selecteer je de call die je wil plannen op die beschikbaarheid.
...
Op de kadeplanning heeft 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 kade mee krijgt, móet de optimizer deze call op deze beschikbaarheid plannen. 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 minimaal overeen komen met de call.
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 1 minuut, dan werd de volgende call meteen weggepland. 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 buiten een beschikbaarheid gepland stond, ging de optimizer zich hier op focussen voor een oplossing. Bij het aanmaken van een nieuwe rotatie bleef de optimizer zich 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, 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 heeft een extra focus op het opnieuw inplannen van prio calls, terwijl een prio call soms helemaal niet ingepland kán worden door bijvoorbeeld onvoldoende beschikbaarheid. Daarom wordt er vanaf nu eerst gecontroleerd door de optimizer of de prio calls überhaupt ingepland kunnen worden. Als dat niet mogelijk is, wordt er nu van tevoren een 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 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
Onbeschikbaarheid barge kwam niet goed door
We kregen een melding dat een onbeschikbaarheid van een barge soms niet goed doorkwam in het systeem. Deze bug bleek in de optimizer te zitten en is nu opgelost. Onbeschikbaarheden komen nu altijd goed door.
...
Release notes Nextlogic Informatie Platform week 31 - 2024
Afgeronde calls blijven zichtbaar in de kade planning
...
Twinning heeft nu een snelheidsfactor van 1,5 i.p.v. 2 bij de berekening van de ETLM
Het algoritme van Nextlogic berekent tijdens het verloop van de operatie de geschatte tijd van de laatste move, de ETLM (Estimated Time Last Move). De berekening gebeurt op basis van de afgehandelde containers (codeco’s). Voorheen werd bij de berekening van de ETLM in het geval van de mogelijkheid van twinnen rekening gehouden met een snelheidsverhoging van 2x. Dit was echter niet realistisch omdat de afhandeling gecompliceerder is dan bij enkele containers. Vanaf nu wordt er daarom rekening gehouden met een snelheidsverhoging van 1,5x om de ETLM te berekenen.
Opgeloste bug: verwachte scope-in locatie werd niet meegenomen in berekeningen
Wanneer een barge operator een verwachte scope-in locatie aanpast werd dit voorheen niet meegenomen in de berekeningen die het platform uitvoerde. Vanaf nu neemt het platform dit wel mee in de berekeningen bij een aanpassing.
...
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.
...
Zie je iets dat nog niet goed loopt? Laat het ons weten via info@nextlogic.nl. Bij de volgende release gaan we de oude schermen verwijderen.
Wachtlocaties zichtbaar in de kadeplanning
Vanaf nu is beschikbaarheid die is aangemaakt als wachttijd zichtbaar in de kadeplanning. Deze beschikbaarheid heeft schuine strepen. Zo kunnen barge operators en schippers inzien dat ze zijn ingedeeld op een wachtlocatie. Hiervan weet je dat deze beschikbaarheid niet permanent is. Dit betekent dat je call naar een andere plek en tijd zal verschuiven.
...
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.
...