AIS en positiedata Vlootoperatie ETA en havenaanloop

Vessel tracking software laten maken

Een schip zendt zijn positie elke paar seconden uit, maar de vraag aan de wal is een andere: wanneer ligt het aan de kade, en wat betekent dat voor de planning van morgen? Tussen dat AIS-bericht en een bruikbaar antwoord zit verwerking, opslag, een aankomstverwachting die blijft schuiven en een dekking die op open zee gaten heeft. Appfront bouwt software die scheepsposities omzet in beslissingen, voor reders, bevrachters, agenten, terminals en verladers die op een aankomst plannen.

Gratis adviesgesprek Platform of maatwerk?

Wat een schip volgen anders maakt

Een bestelwagen volgen is een opgelost probleem: een boordcomputer of telefoon met mobiele dekking, een positie elke paar seconden, een route over een wegennet dat tot de meter bekend is en een aankomst binnen dezelfde dienst. Een zeeschip volgen lijkt daar oppervlakkig op en is in de praktijk een ander vak. De positie komt uit een uitzending over de marifoonband, opgevangen door ontvangers aan de wal of door satellieten, met alle onderbrekingen die daarbij horen. De route loopt over water, niet over een net met knopen en bochten. En de aankomst ligt zo ver vooruit dat de verwachting onderweg tientallen keren verschuift, terwijl er aan de wal wel al loodsen, sleepboten, kranen, personeel en vrachtwagens op vastgeprikt zijn.

Daar komt bij dat de operatie zelf verdeeld is over partijen die elkaars systemen niet in kunnen kijken. De rederij weet wat het schip doet, de agent regelt de aanloop, de terminal bepaalt de ligplaats en het venster, de douane wil de gegevens vooraf, en de verlader wil alleen weten of zijn lading haalbaar is. Vessel tracking software is daarom zelden een kaartje. Het is de laag die van een stroom ruwe posities een gedeeld beeld maakt waarop meerdere partijen hun eigen beslissing kunnen nemen.

Zit u hier goed? Deze pagina gaat over varen, niet over bouwen. Gaat uw vraag over de werf, over secties en hulpstukken, over engineering en het bouwdossier van een schip dat nog niet in de vaart is, dan hoort u bij software voor de scheepsbouw. Daar is het schip het product dat ontstaat; hier is het schip een bewegend punt met lading, papieren en een aankomstmoment.

De positie is openbaar

AIS is een uitzending, niet een privékanaal. Iedereen met een ontvanger ziet uw schip. Wat u beschermt is niet de positie, maar wat u eruit concludeert.

Het bericht is niet de waarheid

Bestemming, diepgang en verwachte aankomst worden met de hand ingevuld. Ze zijn een intentie, geen meting, en staan er soms nog van de vorige reis.

Eén aankomst raakt tien partijen

Loods, sleepdienst, ligplaats, kraan, ploeg, transport en aangifte hangen aan hetzelfde moment. Schuift dat, dan schuift de hele keten mee.

AIS verwerken: van bericht naar bruikbare positie

AIS staat voor Automatic Identification System en werkt als een omroep over twee vaste marifoonkanalen. Een transponder aan boord zendt met korte tussenpozen zijn positie, koers en snelheid uit, en iedere ontvanger binnen bereik pikt dat op. Zeegaande schepen van een zekere grootte en alle passagiersschepen zijn op grond van het internationale verdrag voor de veiligheid van mensenlevens op zee verplicht zo'n transponder te hebben en aan te houden. Kleinere vaartuigen gebruiken een lichtere klasse die minder vaak en met minder zendvermogen uitzendt. Dat verschil hoort u te kennen, want het bepaalt hoe vaak u een nieuwe positie mag verwachten en dus wanneer stilte een storing is.

De berichten komen in soorten. Een positiebericht bevat de kern: coördinaten, koers over de grond, snelheid over de grond, kop en draaisnelheid, plus een tijdstempel en een indicatie van de nauwkeurigheid van de positiebepaling. Een statisch bericht bevat de identiteit en de romp: naam, roepletters, scheepstype en afmetingen. Een derde categorie bevat de reisgegevens: bestemming, diepgang, aantal personen en verwachte aankomst. Die laatste groep wordt met de hand ingevoerd. Daarmee is de scheiding meteen duidelijk: de dynamische velden zijn metingen, de reisvelden zijn intenties, en een systeem dat die twee door elkaar opslaat produceert onbetrouwbare planning.

Identiteit: het nummer waarop u de historie hangt

Een schip heeft meerdere nummers en ze doen niet hetzelfde. Het nummer waarmee de transponder zich meldt hoort bij de radioregistratie en bij de vlag; het verandert dus als het schip van vlag of van eigenaar wisselt, en het wordt na uitschrijving opnieuw uitgegeven. Het scheepsidentificatienummer van de Internationale Maritieme Organisatie hoort bij de romp en blijft de hele levensduur hetzelfde, ook na herdopen en herregistreren. Hangt u uw vaarhistorie aan het radionummer, dan verliest u het verleden van een schip zodra het overvlagt, en erft u op een dag de historie van een ander schip dat hetzelfde nummer kreeg. De praktische oplossing is een eigen scheepsentiteit met een geldigheidsvenster per identificatie, zodat een positie uit het verleden bij het schip blijft dat hem toen uitzond.

Namen zijn nog onbetrouwbaarder. Ze worden verkeerd getypt, staan in hoofdletters met of zonder voorvoegsel, en komen bij meerdere schepen voor. Koppel dus nooit op naam, ook niet in een koppeling met een terminal of een expediteur. Leg een expliciete afbeelding vast tussen uw eigen scheepsentiteit en het nummer dat de tegenpartij gebruikt, beheer die afbeelding in het systeem en niet in een spreadsheet, en log welke aanname er gedaan is als een bericht op meerdere schepen kan passen.

Opslaan zonder dat de stroom u inhaalt

Een vloot volgen betekent een continue stroom kleine berichten opslaan, en daar zitten drie valkuilen die zich pas op termijn wreken. De eerste is dubbelwerk: dezelfde uitzending komt binnen via meerdere ontvangers en soms via meerdere leveranciers. Zonder ontdubbeling op scheepsidentificatie en meettijdstip groeit uw archief sneller dan nodig en gaat elke telling mank. De tweede is de volgorde. Berichten arriveren niet in de volgorde waarin ze verstuurd zijn: een satellietvangst kan later binnenkomen dan een positie die daarna vanaf de wal is opgepikt. Wie de laatst binnengekomen regel als huidige positie neemt, laat schepen zichtbaar achteruit varen. De laatste positie is de laatste naar meettijdstip, niet naar verwerkingstijdstip, en dat is een keuze in het datamodel, geen detail in de weergave.

De derde valkuil is dat men alles voor altijd wil bewaren in dezelfde vorm. Dat werkt niet en het is ook niet nodig. Ruwe berichten zijn waardevol voor een begrensde periode, voor foutzoeken en voor het opnieuw doorrekenen van gebeurtenissen. Voor historie is een vereenvoudigd spoor genoeg: een lijnvereenvoudiging houdt de vorm van de reis intact met een fractie van de punten. Zet daarnaast de afgeleide gebeurtenissen apart weg, want die zijn het antwoord op de vragen die later gesteld worden. Een gangbare inrichting is een tijdreeksopslag met ruimtelijke index, met de ruwe stroom in een aparte laag en een oplopende bewaartermijn per laag: fijn en kort voor ruwe data, grof en lang voor historie.

Aan de leeskant speelt hetzelfde probleem omgekeerd. Een kaart met een hele vloot erop is verleidelijk om rechtstreeks uit de positietabel te vullen, en dat gaat precies zolang goed als de proefopstelling klein is. Bij een groeiende vloot en een langere historie hoort de kaart geaggregeerd te worden bediend: samengevatte punten per zoomniveau, groepering waar schepen dicht op elkaar liggen, en een spoor dat in stappen wordt nageleverd in plaats van in één keer. Ook de vraag zelf verandert per gebruiker. Een planner wil de laatste stand van tien schepen, een analist wil drie reizen naast elkaar en een klantportaal wil één schip zonder de rest. Dat zijn drie verschillende leespaden en het is verstandig ze ook als drie paden te bouwen, met een aparte weergavetabel voor de actuele stand naast het archief. Reken er ten slotte op dat de browser niet de plek is waar u filtert: wat de gebruiker niet mag zien, hoort ook niet meegestuurd te worden.

Op zee zijn er hiaten in de dekking

Dit is het punt waarop demonstraties mooier zijn dan de werkelijkheid. Ontvangst vanaf de wal is beperkt tot de zichtlijn van de marifoonverbinding, dus tot enkele tientallen mijlen kust. Daarbuiten bent u afhankelijk van satellietontvangst, en die heeft twee eigenschappen die u moet inbouwen: er zit tijd tussen twee overkomsten, en in drukke gebieden overlappen de uitzendingen van veel schepen zodanig dat een deel niet gelezen kan worden. Daarnaast kan een transponder uitstaan, gestoord worden of een positie melden die uit een verstoord satellietnavigatiesignaal komt. Het gevolg is een spoor met gaten, met sprongen en soms met een positie midden op het land.

Wat een verantwoord systeem daarmee doet, is niet mooier maken maar eerlijk maken. Dat betekent per positie vastleggen uit welke bron hij komt en hoe oud hij is, en die ouderdom overal in beeld houden waar iemand een beslissing neemt. Het betekent plausibiliteitscontroles: een sprong die een onmogelijke snelheid vereist, een positie op land buiten een vaarweg, een koers die niet bij het spoor past. Zulke waarnemingen worden gemarkeerd en apart gehouden, niet stil weggegooid, want een reeks afwijkingen is zelf een signaal. En het betekent tussen twee metingen doorrekenen op de laatst bekende koers en snelheid, mits die tussenwaarden herkenbaar als schatting worden weergegeven en nooit als meting in het archief belanden. Tot slot: stel per bron een verwachte tussentijd in en meld het als een schip langer wegblijft dan daarbij past, want juist dat is voor een planner nieuws.

Wat een vessel tracking systeem moet kunnen

Deze onderdelen hangen samen. Een aankomstverwachting zonder bronregistratie is niet te verdedigen, geofences zonder reisdefinitie leveren losse gebeurtenissen op, en een koppeling zonder eenduidige scheepsidentificatie legt de fout bij de ontvanger neer.

Positieverwerking met herkomst

Ontdubbelen, sorteren op meettijdstip en per positie vastleggen uit welke bron hij komt, hoe oud hij is en of hij gemeten of geschat is.

Identiteit met een tijdlijn

Eén scheepsentiteit met een geldigheidsvenster per nummer, zodat overvlaggen en herdopen de vaarhistorie niet doorknipt.

Aankomstverwachting met marge

Een verwachting over de route over water, met een onzekerheidsband, een bron en een tijdstip, in plaats van één hard getal.

Geofences die gebeurtenissen maken

Havengrens, ankergebied en ligplaats als vlakken die binnenkomst, verblijf en vertrek melden, met drempels tegen heen en weer springen.

Reisdossier per reis

Spoor, gebeurtenissen, documenten en verbruik onder één reisnummer, met een vastgelegde definitie van waar een reis begint en eindigt.

Koppelingen die falen kunnen verdragen

Uitwisseling met planning, terminal en aangifte met herhaalbare berichten, correlatiekenmerken en een wachtrij voor wat niet aankwam.

De aankomstverwachting berekenen en blijven bijstellen

De eerste fout is de simpelste: afstand hemelsbreed nemen en delen door de snelheid. Dat leidt een schip dwars over land, negeert kanalen, sluizen, zeestraten en verkeersscheidingsstelsels, en geeft in bijna elk bekken een te vroege uitkomst. Een bruikbare berekening rekent de resterende afstand over een vaarbare route, met de bekende doorgangen als knopen. Daarmee wordt de vraag meteen scherper: welke route neemt dit schip, en wat gebeurt er met de verwachting als het onderweg een andere kiest?

De tweede fout zit in de snelheid. De laatst gemeten snelheid over de grond springt met elke golf en met elke koerscorrectie, en op een rivier of in een stroom zegt hij iets anders dan de snelheid door het water. Wie de laatste meting doorrekent naar een aankomst maakt een verwachting die per bericht verspringt en daarmee zijn geloofwaardigheid verliest. Bruikbaarder is een gladgestreken snelheid over een venster, met onderscheid tussen zeetraject en manoeuvreren, en met een correctie voor de vaste vertragingen die iedere aanloop kent.

De derde en belangrijkste fout is dat de aankomst als één moment wordt behandeld. In werkelijkheid zijn het er minstens drie: het bereiken van de havengrens, het aan de ligplaats komen en het moment dat het schip vast ligt en de behandeling kan beginnen. Daartussen zit wachten op een ankerplaats, een tijvenster voor een diepgangsbeperkte toegang, beschikbaarheid van loods en sleepboot, en een ligplaats die nog bezet is. De planner aan de wal heeft aan het laatste moment het meest, en juist dat is niet uit AIS af te leiden. Het volgt uit uw eigen model plus wat de haven en de terminal u vertellen.

Even nuttig is de vraag waaróm een schip afwijkt van de verwachting. Wind, golfhoogte en stroom scheiden de snelheid over de grond van de snelheid door het water, en op tegenstroom of in zwaar weer levert hetzelfde toerental een andere voortgang. Maar niet elke vertraging is weer: een schip dat weet dat zijn ligplaats nog bezet is, kan bewust langzamer varen in plaats van voor anker te gaan wachten, en dat is een besluit en geen oponthoud. Voor de wal maakt dat verschil, want in het ene geval schuift de aankomst en in het andere is de aankomst juist gericht op een afgesproken venster. Een systeem dat naast de verwachting ook de reden vasthoudt, geeft daarmee een ander gesprek: niet dat het later wordt, maar wat er nog te kiezen valt.

Meerdere bronnen, één verwachting

In de praktijk circuleren er voor hetzelfde schip verschillende verwachtingen naast elkaar: het handmatig ingevulde veld in het AIS-bericht, de melding van de agent, het bericht van de kapitein, de berekening van uw eigen model en het venster dat de terminal heeft ingepland. Ze spreken elkaar tegen en dat is normaal. Het werk zit in het samenbrengen: leg per verwachting vast wie hem afgaf, wanneer, en op basis van welke bron, kies een voorrangsregel die verklaarbaar is, en laat zien welke bron nu leidend is. Een systeem dat één getal toont zonder herkomst wordt bij het eerste conflict genegeerd.

Bewaar daarnaast elke verwachting die u ooit heeft afgegeven. Alleen zo kunt u achteraf de fout meten: hoe ver zat u ernaast bij een horizon van een dag, en hoe ver bij een horizon van een halve dag, per route en per scheepstype. Die foutcurve is het enige eerlijke bewijs dat uw model beter is dan een geoefende inschatting. Ze is bovendien de basis voor een marge in plaats van een puntgetal, en een planner die de marge kent, plant er anders op. Zie ook planning en scheduling software op maat als het accent bij het inplannen zelf ligt.

Tot slot: een verschuiving is pas nieuws als er iets aan te doen valt. Meld dus niet elke bijstelling, maar de bijstelling die een grens overschrijdt die voor de ontvanger betekenis heeft: een ploegwissel, een venster bij de terminal, een geboekte laadtijd, het moment waarop transport nog omgeboekt kan worden. Zonder die drempels is het resultaat voorspelbaar: iedereen zet de meldingen uit en niemand kijkt nog.

Afstand over een vaarbare route, niet hemelsbreed
Snelheid gladgestreken over een venster
Havengrens, ligplaats en vastliggen apart benoemd
Tij, loods, sleepboot en ligplaatsbezetting meegerekend
Per verwachting een bron, een tijdstip en een afzender
Verklaarbare voorrang bij tegenstrijdige verwachtingen
Elke afgegeven verwachting bewaard om de fout te meten
Melden alleen bij een planningsrelevante grens

Geofences, havenaanloop en het reisdossier

Een geofence is niets meer dan een vlak op de kaart waar het systeem op reageert: een havengebied, een ankergebied, een ligplaats, een kanaalvak, een emissiezone, een gebied waar u om verzekerings- of sanctieredenen op wilt letten. Zodra een spoor dat vlak binnenkomt of verlaat, ontstaat een gebeurtenis. Dat is het idee, en het is in de praktijk lastiger dan het klinkt, om drie redenen.

De eerste is dat een schip op een grens blijft liggen. Een sleepboot die langs de rand van een havengebied werkt, of een schip dat net buiten de lijn voor anker gaat, levert dan een reeks binnenkomsten en vertrekken op die niets betekent. De oplossing is niet een strakkere grens maar een drempel: een minimale verblijfsduur voordat een binnenkomst geldt, een marge tussen de grens voor binnenkomen en die voor verlaten, en een maximaal aantal wisselingen per periode. De tweede is dat vlakken in elkaar liggen. Een ligplaats zit in een terminal, die zit in een havengebied. Gebeurtenissen horen die nesting te volgen, zodat een aankomst aan de ligplaats niet los staat van de aankomst in de haven, en een rapportage niet dubbeltelt. De derde is de kwaliteit van de vlakken zelf. Officiële havengrenzen en ligplaatsgrenzen zijn iets anders dan een met de hand getekend blokje, en het verschil komt vroeg of laat terug als een discussie over wie te laat was.

De havenaanloop als reeks gebeurtenissen

Een aanloop is geen toestand maar een keten: aankomst op de havengrens, ankeren en anker op, loods aan boord, eerste tros, vast, start en einde van de behandeling, laatste tros, vertrek. Sommige van die momenten zijn met redelijke zekerheid uit positiedata af te leiden, bijvoorbeeld door snelheid onder een drempel binnen een ligplaatsvlak te combineren met een verblijfsduur. Andere zijn dat niet en komen alleen uit een bericht van de agent, de terminal of het havenbedrijf. Leg per gebeurtenis vast hoe hij tot stand kwam: afgeleid, gemeld of met de hand gezet. Dat onderscheid is precies wat u nodig heeft als er later een rekening of een claim aan hangt.

De internationale afspraken duwen deze uitwisseling naar één digitaal loket per haven, waarbij aanmelding van het schip en de gegevens over lading en bemanning elektronisch worden aangeleverd in plaats van per formulier. In Nederland loopt dat via het nationale loket en via de havengemeenschapssystemen die de meldingen doorzetten naar autoriteiten en terminals. Voor uw eigen systeem betekent dat zelden dat u de aangifte doet, maar wel dat u de juiste gegevens op het juiste moment gereed hebt en kunt aantonen wanneer ze klaarstonden. Meer over de systemen rond de aanloop leest u bij havensoftware ontwikkeling.

Reisdossier en vaarhistorie die een vraag achteraf overleven

Een reis is geen technisch feit maar een afspraak. Loopt een reis van vertrekligplaats tot aankomstligplaats, per charter, per lading, of per stel havens dat samen één rondvaart vormt? Elke keuze is verdedigbaar, maar één keuze moet vastliggen en overal gelijk worden toegepast, want anders komen aantallen in twee rapporten nooit meer overeen. Rond die reis hangt u het spoor, de gebeurtenissen, de bijgestelde verwachtingen, de documenten, de havenkosten en het verbruik. Zo wordt een reisdossier iets anders dan een archief: het is de plek waar een latere vraag beantwoord wordt.

Die vragen komen namelijk. Waarom was dit schip later dan gemeld. Is de wachttijd terecht doorbelast. Waar was het schip op een bepaald tijdstip. Welke route liep door welk gebied, en klopt dat met wat er in de vervoersdocumenten staat. Ook de verslaglegging over brandstofverbruik en emissies in de Europese regels rekent per reis en maakt onderscheid naar de havens die aan een traject te pas komen, waardoor de manier waarop u reizen afbakent geen cosmetische keuze meer is. Wie dat pas achteraf inricht, mag de historie opnieuw doorrekenen met vlakken en regels die inmiddels veranderd zijn.

Daaruit volgen drie ontwerpregels. Leg gebeurtenissen onveranderlijk vast, met bron en meettijdstip, en corrigeer door een nieuwe gebeurtenis toe te voegen in plaats van de oude te overschrijven. Bewaar bij elke afgeleide gebeurtenis de versie van het vlak en van de regel die hem voortbracht, zodat een hertekende geofence de geschiedenis niet herschrijft. En scheid meting van interpretatie in het model, zodat u uw regels kunt verbeteren zonder uw metingen kwijt te raken.

AIS-decodering Ontdubbeling op meettijdstip Scheepsidentiteit met tijdlijn Route over water Geofence-gebeurtenissen Reissegmentatie Spoorvereenvoudiging Tijdreeksopslag Ruimtelijke index Webhooks en API

Koppelen met planning, terminal en douane

De waarde van vessel tracking zit niet in de kaart maar in de overdracht. Een positie die alleen op een scherm staat, verandert niets; een aankomstverwachting die automatisch in de transportplanning landt, verandert de dag van een planner. Aan de landzijde zijn dat meestal drie richtingen. De eerste is uw eigen planning, of dat nu een transportmanagementsysteem is, een orderpakket of een eigen bord. Zie een TMS laten maken als die kant nog ontbreekt, en een track and trace systeem als de klant zelf moet kunnen meekijken.

De tweede richting is de terminal en het achterland. Daar gaat het over ligplaatsplanning, over vensters voor het aan- en afvoeren van lading, en over het boeken van tijdsloten voor wegvervoer. Een schuivende aankomst is pas echt verwerkt als het bijbehorende slot mee schuift, en dat vraagt een koppeling die niet alleen leest maar ook wijzigt en een bevestiging terugkoppelt. Hoe zo'n boekingsstroom eruitziet, staat beschreven bij het slot booking portal.

De derde richting is de aangifte. Vrachtgegevens moeten vóór aankomst bekend zijn, en de vooraanmelding en het manifest hangen aan hetzelfde aankomstmoment dat u volgt. Uw systeem is daarbij zelden de plek waar de aangifte wordt gedaan, maar wel de plek die weet wanneer welk gegeven beschikbaar was en welke wijziging daarna nog kwam. Voor die kant is automatisering van de douaneafhandeling de aangrenzende bouwsteen.

Technisch lopen deze koppelingen door twee werelden. In de ene wisselt men gestructureerde berichten uit volgens afspraken die al decennia meegaan, in de andere gaat het over webinterfaces met tokens en gebeurtenisstromen. Beide vragen hetzelfde fundament: berichten die twee keer verzenden overleven zonder dubbele boeking, een correlatiekenmerk dat vraag en antwoord bij elkaar houdt, een wachtrij met herhaalpogingen en een plek waar mislukte berichten zichtbaar blijven in plaats van te verdwijnen. En het lastigste onderdeel is geen techniek maar stamdata: uw scheepslijst, die van de terminal en die van de aangifte moeten expliciet op elkaar afgebeeld zijn, beheerd in het systeem en niet in het hoofd van één medewerker.

Wanneer een bestaand platform genoeg is

Eerlijk zijn over de grens van maatwerk hoort hierbij. Er bestaan volwassen aanbieders van AIS-data en volgplatformen met wereldwijde dekking, satellietontvangst, havenaanloopgegevens en kant-en-klare kaartlagen. De ontvangst zelf opbouwen is voor bijna iedereen een slecht idee: u koopt die data in. En wilt u vooral kunnen kijken, filteren, een vloot volgen en bij een gebeurtenis een bericht krijgen, dan is een abonnement op zo'n platform de verstandigere route, en dat zeggen we liever nu dan halverwege een traject.

Maatwerk begint te lonen zodra de beslislogica van u is. Dat is het geval als u meerdere bronnen tot één verantwoorde verwachting moet samenbrengen, als uw reisdefinitie en uw rapportageplicht niet in het model van een platform passen, als de historie in uw eigen omgeving moet staan omdat er claims en verantwoording aan hangen, of als de positie alleen waarde krijgt in combinatie met uw orders, contracten en afspraken. Vaak is de beste vorm een combinatie: data en dekking inkopen, en zelf de laag bouwen die daar beslissingen van maakt. Ligt uw vraag breder dan positie en aankomst, dan is maritieme software op maat de bredere ingang, en voor de keten voorbij de haven supply chain management software.

Bij die keuze hoort één praktische waarschuwing. Lees de licentievoorwaarden van uw databron voordat u een archief inricht. Bewaren, doorleveren en zichtbaar maken aan derden zijn daarin geregeld, en de uitkomst bepaalt mede hoe u opslag en rechten inricht. Bouwt u zelf, dan ligt het bijhouden van veranderende voorschriften en berichtformaten bij uw eigen organisatie.

Data en dekking inkopen, logica zelf bouwen
Platform als kijken, filteren en melden de vraag is
Maatwerk bij een eigen verwachting over meerdere bronnen
Maatwerk als historie in uw eigen omgeving moet staan
Koppelen op identificatie, nooit op scheepsnaam
Berichten herhaalbaar, met wachtrij en zichtbare uitval
Stamdata afgebeeld en beheerd in het systeem
Licentievoorwaarden van de databron eerst gelezen

Veelgestelde vragen over vessel tracking software

Omdat die ETA met de hand wordt ingevoerd, net als de bestemming en de diepgang. Het veld verandert alleen als iemand aan boord het bijwerkt, en het bevat vaak een afkorting, een havencode of nog de waarde van de vorige reis. Lees het als een bedoeling, niet als een planningsgetal, en bereken uw eigen aankomstverwachting uit positie, koers, snelheid en de route over water.

Het laat het verschil zien tussen een gemeten en een geschatte positie. Ontvangst vanaf de wal reikt tot de horizon van de VHF-verbinding, satellietontvangst kent herhaalintervallen en in drukke gebieden overlappen berichten. Een verantwoord systeem toont daarom de ouderdom van de laatste meting, rekent tussen twee metingen door op koers en snelheid, markeert die tussenwaarden als schatting en meldt zodra een schip langer wegblijft dan bij zijn bron past.

Dat hangt van de licentie af, en die vraag hoort vooraf op tafel. Commerciële databronnen stellen voorwaarden aan bewaren, doorleveren en zichtbaar maken aan derden, en die voorwaarden bepalen mede hoe u uw archief inricht. Let daarnaast op posities van kleine vaartuigen: zodra een positie aan een persoon te koppelen is, komt gegevensbescherming in beeld en horen een doel en een bewaartermijn vast te liggen.

Nee. Scheepsbouwsoftware ondersteunt het bouwen: secties, engineering, hulpstukken en het bouwdossier van een schip dat nog niet vaart. Deze pagina gaat over de operatie van een schip dat al vaart: waar het is, wanneer het aankomt en wat dat betekent voor de planning aan de wal. Zoekt u de werf, dan is de pagina over software voor de scheepsbouw de juiste ingang.

Voor kijken, filteren en waarschuwen vaak wel. Er bestaan volwassen aanbieders van AIS-data en volgplatformen met wereldwijde dekking, satellietontvangst en havenaanloopgegevens, en de ontvangst zelf nabouwen levert zelden voordeel op. Maatwerk wordt interessant zodra de beslislogica van u is: een eigen aankomstverwachting over meerdere bronnen, een eigen reisdefinitie, of historie die in uw eigen systemen moet staan voor claims en verantwoording.

De broncode en de documentatie zijn eigendom van de opdrachtgever en staan in een repository waar u zelf toegang toe heeft. Bij oplevering hoort een beschrijving van de architectuur, de datamodellen, de koppelingen en de deployment, zodat een andere partij het kan overnemen zonder eerst te reverse-engineeren. We werken met gangbare technologie, omdat dat bepaalt hoeveel partijen het onderhoud kunnen oppakken.

Gerelateerde diensten

Software voor de scheepsbouw

Zoekt u niet de operatie maar de werf, met secties, engineering, hulpstukken en het bouwdossier van een schip dat nog niet vaart, dan is software voor de scheepsbouw de juiste ingang. Daar is het schip het product; hier is het een bewegend punt met lading en een aankomstmoment.

Maritieme software op maat

Speelt de vraag breder dan positie en aankomst, rond onderhoud, certificaten, bemanning, charters of facturatie per reis, dan is maritieme software op maat het bredere vertrekpunt, met vessel tracking als één van de onderdelen.

Haven, terminal en de keten erna

Voor de aanloop en de afhandeling in de haven zelf: havensoftware ontwikkeling. Voor het inplannen van vervoer op een aankomst een TMS laten maken, en voor het meekijken door klanten een track and trace systeem.

Van AIS-bericht naar kadeplanning

Vertel ons welke bronnen u nu gebruikt, hoe de aankomstverwachting bij de planner terechtkomt en wat er gebeurt als een schip uit de dekking valt. Uit die drie antwoorden blijkt meestal of u data moet inkopen, logica moet bouwen of beide.

Plan een adviesgesprek info@appfront.nl