Toelichting release notes
Wij maken onderscheid tussen twee verschillende onderdelen waarop wij verbeteringen doorvoeren:
Het Nextlogic Informatie Platform: de webomgeving van de integrale planning: http://www.nextlogic-planning.com
De ‘optimizer’: het algoritme dat de integrale planning berekent.
Ga naar:
...
Informatie Platform: de webomgeving van de integrale planning: http://www.nextlogic-planning.com
De ‘optimizer’: het algoritme dat de integrale planning berekent.
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
Voorheen werden calls na afronding verwijderd uit de kadeplanning. Vanaf deze release is dit niet meer het geval en blijven deze calls zichtbaar, te herkennen aan hun grijze kleur. Hierdoor is het mogelijk om de situatie op een kade terug te zien. Een call is afgerond wanneer Nextlogic een ATD of ATLM ontvangt. De kadeplanning met afgeronde calls is zeven dagen terug te zien.
...
Schippers kunnen afspraken bij niet-deelnemende terminals in de volgorde van aangevraagde tijden zien
Voorheen zagen schippers in het schippersscherm alle afspraken op volgorde zoals deze door Nextlogic waren gepland. In de volgorde keek het systeem bij niet-deelnemende terminals naar de voorgestelde tijd door Nextlogic i.p.v. naar de aangevraagde tijd door de barge operator. In het schippersscherm kun je nu kiezen om de afspraakvolgorde te zien en te sorteren op basis van deze aangevraagde tijden bij niet-deelnemende terminals. Let op: het kan hierdoor zijn dat tijden overlappen.
...
Nieuwe operationele waarschuwingen voor het prioriteitsvenster / priority window
Vergelijkbaar als voor een fixed window zijn er nu ook operationele waarschuwingen te zien in het platform voor problemen bij het plannen van een call met een prio t.o.v. het prioriteitsvenster. Dit zijn een drietal mogelijke waarschuwingen:
De duur van de call groter is dan de lengte van het prioriteitsvenster. (bijvoorbeeld een call van 5 uur, terwijl er een prio is gegeven voor 3 uur)
...
Er is niet genoeg beschikbaarheid aangemaakt binnen het prioriteitsvenster door de terminal, maar de call zou qua lengte wel moeten passen binnen het prioriteitsvenster. (bijvoorbeeld een call van 5 uur in een prioriteitsvenster van 8 uur, maar er is niet voldoende beschikbaarheid gemaakt in de kadeplanning binnen deze 8 uur van minimaal 5 uur aaneengesloten beschikbaarheid)
...
De scope-in van een lichter loopt vertraging op waardoor deze niet meer voldoende tijd heeft in zijn prioriteitsvenster en beschikbaarheid binnen het prioriteitsvenster om de volledige call af te handelen.
...
Nieuwe operationele waarschuwing bij een conflict tussen de vroegste start BO en een fixed window
Nextlogic toonde al een aantal waarschuwingen wanneer een fixed window niet gehaald kon worden. We hebben met deze release een extra waarschuwing toegevoegd. Soms zagen we namelijk dat (door verkeerde input) een fixed window niet gehaald kon worden doordat het conflicteerde met de vroegste start BO. Om deze invoerfout te voorkomen, tonen we nu deze waarschuwing wanneer dit verkeerd gaat:
...
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.
...
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
...
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
...
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).
...
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.
...
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.
...
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 - Q2 2024
Release notes Optimizer
...
- Week 25
...
Opgeloste bugs
Aangepaste beschikbaarheden kwamen niet altijd door
...
We hebben de laatste stappen gezet in de ontwikkeling van lineair opschuiven, zodat deze zo snel mogelijk naar productie kan. Wat er in deze versie wel en niet inzit krijgen jullie via een aparte uitleg later te lezen.
...
Release notes Nextlogic Informatie Platform week 25 - 2024
Operationele waarschuwingen
...
Nauwkeuriger berekenen van de ETAS
Door een fout in het systeem kon het in sommige situaties mogelijk zijn dat de geschatte aankomsttijd scope-in (ETAS) niet klopte. De reden hiervan was dat deze berekend werd vanaf de verkeerde scope-in locatie (bijv. Heinenoordtunnel i.p.v. Brienenoordbrug). Met deze release wordt de geschatte aankomsttijd altijd berekend vanaf de scope-in locatie zoals die wordt opgegeven door de barge operator.
Verbetering op de ‘vroegste start BO ‘
Bij het uitplannen van een call werd de ingevulde ‘vroegste start BO’ ook verwijderd. Met deze release zal een ingevuld veld altijd behouden blijven en wordt er rekening mee gehouden in de planning.
...
Release notes Nextlogic Informatie Platform week 23 - 2024
Het oude schippersscherm is verwijderd
De nieuwe schippersschermen zijn al enige tijd in gebruik. De oude schermen waren ook nog zichtbaar voor de schippers. In deze release zijn de oude schermen verwijderd.
De sortering is verbeterd op de pagina ''kade beschikbaarheid''
Op deze pagina zijn alle beschikbaarheden in een overzicht te vinden die door de terminal operator zijn aangemaakt. Er zat geen logische sortering in deze lijst, met deze release is er een sortering gemaakt waar de eerste sortering op bolders is en daarna de sortering op datum en tijd.
...
De omschrijving bij de operationele waarschuwingen zijn leesbaar gemaakt
Op de pagina ''operationele waarschuwingen'' was de omschrijving niet direct te lezen. Hiervoor moest de gebruiker eerst verder klikken om de gehele omschrijving te zien. Met deze release is het standaard leesbaar en is er een duidelijk overzicht met alle operationele waarschuwingen. Momenteel worden alle operationele waarschuwingen weergegeven, ook die niet meer actueel zijn of überhaupt geen actie vereist. Op termijn werken we ernaar toe dat hier alleen nog maar operationele waarschuwingen staan waar actie wordt vereist van de TO of BO, zodat dit scherm actief gebruikt kan worden.
...
Release notes
...
Nextlogic Informatie Platform - Week 20
Een terminal kan een reden voor sluiting opgeven
Wanneer een terminal tijdelijk sluit, bestond er voor de terminals al de mogelijkheid om die tijden in te voeren in het Nextlogic Informatie Platform. Nu is er ook de mogelijkheid om een reden in te vullen. Dit is meteen zichtbaar voor iedereen in de kadeplanning onder sluitingstijden. Het aanmaken en aanpassen van sluitingen kan alleen gedaan worden door een locatie admin.
...
Oud schippersscherm wordt verwijderd met de volgende release
Op dit moment zijn er nog twee schermen beschikbaar waar de schipper zijn planning in kan zien. Het nieuwe scherm is al enige tijd in gebruik door de schippers. Het oude scherm zal daarom met de volgende release verwijderd worden.
Release notes Optimizer - Week 19
Bugfixes
In deze release zitten een aantal bugfixes die voor minder ongeplande calls zorgen na bepaalde gebeurtenissen die vervolgens weer ingepland worden na een iteratie. Dit zorgt ervoor dat bij bepaalde wijzigingen calls sneller automatisch herpland worden.
Lineair opschuiven
Naast bugfixes hebben we verder gewerkt aan ‘Lineair opschuiven’. Deze functionaliteit zit in de productie versie, maar staat nog uit, omdat we er nog een aantal essentiele ontwikkelingen moeten gebeuren in combinatie met verdere testen. Bij weinig bevindingen uit de testen zal de functionaliteit in een release in de nabije toekomst live kunnen. Echter is dit een ontwikkeling die uniek is voor het Nextlogic product en kunnen we pas een gedegen indicatie geven na een serie van uitgebreide testen.
...
Release notes Nextlogic Informatie Platform week 14 - 2024
Beschikbaarheden visueel aangepast
...
Aanpassing retry mechanisme
Een retry mechanisme is een functie dat automatisch een poging doet om een mislukte taak of operatie opnieuw uit te voeren als gevolg van een fout of storing. Bij een storing in het berichtenverkeer werden alle nieuwe berichten opgespaard en in één keer doorgestuurd, richting MCA, zodra de storing verholpen was. Dit kon voor extra verstoringen zorgen in een TOS systeem van één van de terminals. Vanaf nu sparen we de berichten niet meer op om in één keer door te sturen, maar sturen we altijd alleen het laatst opgeslagen bericht door zodra de storing is verholpen. Hiermee kunnen de extra verstoringen voorkomen worden.
Scope-out locatie vletwerk
Vanaf nu wordt de scope-uit tijd van een rotatie zonder scope-uit locatie niet meer geregistreerd na het passeren van de Brienenoordbrug of de Heinenoordtunnel/spui. Alleen de ATDT van de laatste call op de rotatie zorgt voor een werkelijke scope-uit tijd.
Instelling verplichte kade
Deze instelling is bedoeld voor terminals met verschillende kades. Als een terminal niet wil dat de geplande kade wijzigt ten opzichte van de invoer, hebben we daarvoor nu een nieuwe instelling toegevoegd. Hiermee kunnen we per terminal bepalen of de wisseling van kade wordt voorkomen. Hierdoor wordt de call altijd gepland op de opgegeven kade. Als daar geen of niet voldoende beschikbaarheid ligt wordt de call niet ingepland.
Kruisje kadeplanning call details weer terug
Bij het aanklikken van een call op de kadeplanning was onderstaand kruisje verdwenen. Deze staat er weer.
...
Release notes Optimizer week 14 - 2024
Lineair opschuiven
De eerste technische aanpassingen zijn gemaakt voor het mogelijk maken van lineair opschuiven. Voordat we dit live zetten gaan we dit uitgebreid testen. Daarnaast gaan we samen met de kennisgroep met de barge operators en terminals bepalen welke scenario’s hierin wel en niet meegenomen gaan worden.
Deze functionaliteit gaat dan ook nog niet live, maar we zijn wel begonnen met testen.
Automatische database kopieën
In een voorgaande release hebben we het mogelijk gemaakt om met dynamische data te gaan testen zodat we een dag uit de live omgeving kunnen naspelen en dat kunnen gebruikten voor het testen van nieuwe functionaliteiten. In deze release hebben we hieraan toegevoegd dat we op vaste tijdsstippen kopieën kunnen maken van onze datasets. Dit helpt bij het analyseren van de nagespeelde dag.
Bugs opgelost
Een drietal bugs is opgelost die zorgde voor het niet juist inplannen/herplannen van rotaties.
...
Release notes - Q1 2024
Release notes Optimizer week 11 - 2024
Eerdere start puntenscore containers
In de vorige release hebben we een nieuwe definitie geïntroduceerd van late calls. Onderdeel hiervan was dat reguliere calls als laat worden bestempeld zodra de geplande starttijd na de scope in + norm duration ligt (de door Nextlogic berekende tijd van een rotatie). In deze release hebben we ook het container window vervroegd naar scope-in + norm duration. Dit betekent dat de puntenscore per container gaat gelden vanaf dat moment. Hiermee creëren we een eerlijker speelveld tussen grote en kleine rotaties en tussen grote en kleine calls.
Zo vroeg mogelijk plannen
De optimizer rekent met punten voor containers, calls en rotaties die buiten de norm duration worden gepland. Tot nu toe was er binnen de normtijd geen duidelijke stimulans om calls zo vroeg mogelijk te plannen. Vanaf deze release krijgt elke individuele call een puntenscore per minuut dat ze in de haven liggen. Dus vanaf moment 1 is het qua score beter om calls zo vroeg mogelijk te plannen. Dit zal vooral effect hebben op kades waarbij er nog ruimte is om te schuiven en calls vooraan in de rotatie. Op kades waarop alle calls achter elkaar gepland liggen, zal het effect minimaal zijn en is de norm duration nog steeds de belangrijkste factor.
Aan- en afmeren mogelijk tijdens pauze
Eind vorig jaar hebben we de aan- en afmeertijden bij de meeste terminals verhoogd. Echter, konden calls niet beginnen in een pauze met aanmeren, terwijl dit in werkelijkheid wel kan. Vanaf nu kan een call beginnen in een pauze met aanmeren en eindigen in een pauze als de operatie klaar is. Hiermee brengen we de planning weer een stukje dichter naar de werkelijkheid.
Analyse mogelijkheden uitgebreid
Het analyseren van onze data is een belangrijk onderdeel voor het optimaliseren van de integrale planning. Aan de achterkant hebben we een aantal extra datavelden en filter mogelijkheden toegevoegd die het analyseren van de optimizer en iteraties makkelijker maakt.
...
Release notes Optimizer week 9 - 2024
Rust in de planning
We hebben twee functionaliteiten in de Optimizer aangepast om meer rust in de planning te creëren.
...
Bugs opgelost
Naast bovenstaande items hebben we ook een aantal bugs opgelost in de planning. Onder andere een bug in het verwijderen van calls op niet deelnemende terminals, dit is nodig voor het aansluiten van nieuwe terminals. En een verbetering van een doorgevoerde oplossing in de vorige release die betrekking heeft op stukken missende data.
...
Release notes Nextlogic Informatie Platform week 6 - 2024
Aanpassingen nieuwe schippersschermen n.a.v. feedback
...
De oude schermen zijn op dit moment nog beschikbaar, maar bij de volgende release is het de bedoeling de oude schermen te verwijderen. Voordat we dit doen hebben we een laatste enquête uitgezet bij de leden van de kennisgroep voor schippers om feedback te geven. Deze feedback verwerken we de komende periode.
Ben je geen lid van de kennisgroep en zie je iets dat nog niet goed gaat in de nieuwe schermen? Laat het ons weten via info@nextlogic.nl.
Aanpassing voor vlet rotaties
Aanpassing aankomsttijden en vertrektijden
Voor vlet rotaties zijn de aankomsttijden op de eerste terminal en vertrektijden op de laatste terminal van belang om te bepalen of een rotatie is gestart/beëindigd. Deze tijden vervangen de scope-in tijden die bij een reguliere rotatie gelden. Eerst keken we alleen naar de ATAT/ATDT als deze was opgepikt door AIS/first of last move, vanaf deze release nemen we deze tijden ook mee als ze handmatig worden ingevoerd.
Afronden rotatie na verplaatsen call
We zien bij vletwerkrotaties vaker dat calls van de ene rotatie naar een volgende rotatie worden overgezet. Als dit de laatste call is in een rotatie waarvan verder alle calls zijn afgerond, werd de volledige rotatie niet meer afgemeld. Nu checkt het algoritme iedere keer wanneer een call wordt verplaatst naar een andere rotatie of daarmee de vorige rotatie kan worden afgerond.
Automatisch opruimen onbeschikbaarheden
Bij terminals of bij barges kunnen onbeschikbaarheden worden doorgegeven. Deze tijden worden niet automatisch opgeruimd als deze in het verleden liggen en daarmee niet meer van toepassing zijn. Dit zorgt niet alleen voor handmatig werk aan de kant van de terminal en de barge operator, maar vertroebelt ook onze data. Vanaf nu worden onbeschikbaarheden in het verleden automatisch verwijderd.
Extra alert als er een storing is in de AIS-gegevens
Om de AIS-locatie te gebruiken maken we gebruik van twee AIS-bronnen. Eén bron kijkt naar het gebied in de Rotterdamse haven, de andere kijkt naar het gebied buiten Rotterdam. We hebben extra alerts ingebouwd om direct te kunnen signaleren als er een bron uit ligt.
...
Release notes Optimizer week 3 - 2024
Bolders verschuiven
We zien regelmatig dat beschikbaarheden 1 of 2 bolders van plaats verschuiven. Daarna liggen de calls buiten beschikbaarheid en gaat de Optimizer opnieuw rekenen en plannen. Dit kan voor veel onrust zorgen in de planning. Vanaf deze release verschuiven de geplande calls mee met de nieuwe beschikbaarheid bij het opschuiven van bolders. Hierdoor gaat het herplannen van deze calls sneller en zorgt het voor minder onrust bij verschuivingen van capaciteit.
Drie bugs opgelost
Met een complex algoritme als die van de integrale planning kunnen we er niet omheen dat er soms bugs naar voren komen. We zijn continu alert op dit soort foutjes in het systeem, in deze release hebben we er drie opgelost:
...
Testen met dynamische data
We hebben een optie toegevoegd aan het systeem waardoor het mogelijk is voor Nextlogic om te testen op basis van dynamische data. Gedurende de dag komt er veel data binnen in de vorm van berichten die de planning beïnvloeden. Denk hierbij aan tijden, containers, beschikbaarheden, etc.. Waar dat voorheen niet mogelijk was, is het vanaf nu wel mogelijk dat wij met deze berichten een dag uit de planning kunnen simuleren. Dit stelt ons in staat nieuwe functionaliteiten beter te testen en de impact van nieuwe oplossingen of aansluitingen beter te bepalen.
...
Release notes Nextlogic Informatie Platform week 2 - 2024
Nieuwe schippersschermen live
Het afgelopen half jaar hebben we in samenwerking met de kennisgroep voor schippers gewerkt aan nieuwe schippersschermen. Het doel was om overzichtelijkere schermen te maken met de planning als focus. Naast een duidelijke focus op de planning hebben schippers nu ook makkelijker inzicht in de gegeven restricties, operationele waarschuwingen en eventueel afgekeurde containers.
De schermen zijn zo gemaakt dat ze ook op mobiel goed leesbaar zijn. Meer uitleg over de schermen en over hoe je zelf een app kan maken van de webpagina kan je vinden via deze link.
Op dit moment zijn zowel de nieuwe als de oude schermen beschikbaar. De bovenste optie Bargeacties zijn de oude schermen en de onderste Bargeacties zijn de nieuwe schermen.
...
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.
...
Beschikbaarheid op spookbolders
In de vorige release hebben we een aanpassing gedaan waarbij beschikbaarheden die op een spookbolder begonnen of eindigden qua tijd aangepast kunnen worden, en dat de spookbolders dan blijven staan.
Vanaf nu kan je de beschikbaarheden ook van bolderrange naar een andere bolderrange wijzigen. Start je de beschikbaarheid op een spookbolder en verschuif je deze, dan zal de beschikbaarheid op de nieuwe plek ook op een spookbolder starten. Hetzelfde geldt als de beschikbaarheid eindigt op een spookbolder.
De verwachtte tijd voor de scope-uit kan niet meer vóór de verwachte of actuele tijd scope-in zijn
Naar aanleiding van een aantal cases waarbij de scope-uit vóór de scope-in was gegeven, hebben we een validatie toegevoegd op de ’Schipper verwachtte scope-in/uit tijd’. De verwachtte tijd voor scope-uit kan hierdoor niet meer voor de verwachte of actuele tijd scope-in zijn.
...
Release notes - 2023
Release notes Nextlogic Informatie Platform week 47 - 2023
...
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.
...