Ota DCSA:n API:t käyttöön nyt: priorisoi varaus-, tapahtuma- ja seuranta-rajapinnat ja ota käyttöön standardoidut tietosisällöt 12 viikon kuluessa vähentääksesi manuaalisia tehtäviä ~40 % ja toimittaaksesi lähes reaaliaikaisia päivityksiä jokaiselle käyttäjälle.
Aloita kolmella käytännön toimenpiteellä: kartoita nykyiset rajapinnat, paljasta ohut API-kerros vanhoille järjestelmille, jotka käyttävät edelleen EDI:tä, ja pilotoi satelliittipohjaisia sijaintisyötteitä tapahtumatiedon rikastamiseksi. Tämä lähestymistapa säilyttää nykyiset toiminnot samalla, kun luodaan saumaton polku automatisoiduille ilmoituksille ja ETA-korjauksille.
Mittaa tulokset todistaaksesi arvon: seuraa varauksen vahvistuksen keskimääräistä aikaa, sähköpostiketjujen prosentuaalista vähenemistä, tilapäivitysten tiheyttä matkakohtaisesti ja API-kutsujen käyttöä asiakasta kohden. Nämä mittarit osoittavat, miten muutos muuttaa hankintaa ja toimintoja koko toimitusketjussa ja miten tiimit työskentelevät yhdessä vähentääkseen odotusaikaa ja väärin reititystä laivalla.
Noudata selkeitä suunnitelmia: suorita kolmiosainen pilotti yhdellä operaattorilla, kahdella lähettäjällä ja terminaalilla; julkaise palvelutasosopimukset ja versiointisäännöt; tarjoa SDK:t ja esimerkkitietosisällöt; ja aikatauluta viikoittaiset integraatiotarkistuspisteet. Nämä konkreettiset toimenpiteet tuottavat toistettavia tuloksia tänään ja tekevät standardoidusta tiedosta saatavilla jatkojärjestelmille, analytiikalle ja kumppani-integraatioille.
DCSA:n API-standardit: Tiedon saatavuuden parantaminen globaalissa merenkulussa – Konttialusten saapumisten ja alustan käyttöönoton yhdenmukaistaminen digitalisaatiota varten
Ota DCSA:n API-standardit käyttöön 12 kuukauden kuluessa alusten ETA-julkaisujen, laituripaikkojen allokoinnin ja alustan käyttöönoton synkronointia varten, vähentäen manuaalisia tehtäviä ja mahdollistaen automaattiset operatiiviset päivitykset.
Vaadi API:ta julkaisemaan ETA- ja tilapäivitykset 15 minuutin välein ja tukemaan tapahtumapohjaisia webhookeja välitöntä viestintää varten operaattoreiden, terminaalien ja agenttien välillä. Integroi AIS- ja satelliittisyötteet, jotta sijainti ja nopeus tallennetaan reitin varrelta ja siirretään satamajärjestelmiin; standardoi tietosisällöt ISO 8601 -aikaleimoilla ja UN/LOCODEilla kartoitusvirheiden välttämiseksi siirron aikana. Suunnittele kolme suurta julkaisua vuodessa semanttisella versioinnilla ja selkeästi julkaistuilla ikkunoilla taaksepäin yhteensopivuudelle, jotta käyttäjät saavat ennakoitavat päivityssyklit.
Optimoi laituripaikkaikkunat yhdistämällä terminaalien käyttöjärjestelmien ja operaattorien suunnittelujärjestelmien operatiiviset syötteet; pilotit Maerskin ja terminaalikumppaneiden kanssa osoittavat jopa 20 % vähennyksen laituripaikkojen odotusajassa ja suuremman laituripaikkojen käyttöasteen verrattuna manuaaliseen aikataulutukseen. Käytä automaattisia laituripaikkojen uudelleenallokointisääntöjä ja ilmoitusviestintää vähentääksesi laituripaikkojen tyhjäkäyntiminuutteja alusten liikkeiden välillä, parantaen läpimenoa enemmän kuin ad hoc -viestintä voi saavuttaa.
Sisällytä ympäristömittarit jokaiseen API-datapakettiin: polttoaineenkulutus, apumoottoritunnit ja satelliittipohjaiset päästölaskelmat. Syötä tallennetut mittarit satama- ja operaattorinhallintapaneeleihin CO2:n laskemiseksi TEU:ta kohden ja määritä mitattavia tavoitteita kestävälle kehitykselle. Ne antavat operaattoreille mahdollisuuden verrata reititys- ja laituripaikkavalintoja päästöjen ja käyttökustannusten suhteen, mahdollistaen strategiset valinnat, jotka johtavat parempiin kestävyystuloksiin.
Perusta ohjaus, joka sitoo standardien noudattamisen sopimuksen mukaisiin palvelutasosopimuksiin, selventää viestintäprotokollia ja määrittää vastuun tiedon laadusta. Edistä kehittäjätyökaluja, hiekkalaatikko-ympäristöjä ja avointa dokumentaatiota kehityksen ja uusien käyttäjien käyttöönoton nopeuttamiseksi. Seuraa suorituskykymittareita – saapumisajan tarkkuus, automaattisen siirron onnistumisaste ja manuaalisten väliintulojen väheneminen – ja julkaise neljännesvuosittaisia raportteja, jotta osalliset voivat mitata edistymistä ja suunnitella jatkointegraatioita.
Operatiivinen suunnitelma: DCSA:n API:en soveltaminen alusten saapumistietojen yhdenmukaistamiseksi
Ota käyttöön standardoitu saapumistilan täsmäytysprosessi käyttämällä DCSA Event-, Voyage- ja Port Call -API:eita 24 tunnin palvelutasosopimuksella yhdenmukaistamaan alusten saapumisia operaattoreiden, satamien ja terminaalien välillä.
Kerää saapumistiedot kolmesta pääasiallisesta lähteestä: operaattorimanifestit DCSA Voyage API:n kautta, terminaalijärjestelmät Port Call API:n kautta ja AIS-syötteet. Käytä Event API -webhookkeja nopeisiin päivityksiin ja palaa ajoittaiseen kyselyyn 5 minuutin välein, kun webhookit epäonnistuvat. Merkitse jokainen tietue SOURCE-kentällä (lähde) ja capture_timestamp-kentällä alkuperän säilyttämiseksi ja tilintarkastusketjujen tukemiseksi.
Normalisoi saapuvat tietosisällöt yhteen operatiiviseen malliin näillä erityisillä kanonisilla kentillä: vessel_imo, voyage_id, eta_utc, ata_utc, berth, status_code, bunker_onboard_mt, estimated_fuel_burn_mt, customs_status ja event_origin. Muunna kaikki ajat UTC:ksi, pyöristä lähimpään minuuttiin ja kartoita eri tilakoodit 7-vaiheiseen saapumistaksonomiaan (suunniteltu, ETA päivitetty, matkalla, saapunut, rinnalla, laituriin, lähtenyt).
Käytä deterministisiä täsmäytyssääntöjä: tarkka täsmäytys vessel_imo + voyage_id:llä, jos saatavilla; muuten täsmäytys vessel_imo + ETA-ikkunalla ±72 tuntia käyttäen pisteitystoimintoa, joka painottaa Event API = 0,5, AIS = 0,3, terminaaliviestit = 0,2. Merkitse epäsuhdat pisteillä <0,6 ihmisen tarkistettaviksi. Määrittele epäsuhdan raja 60 minuutille ETA vs ATA; suuremmat erot käsitellään operatiivisina poikkeuksina, jotka voivat lisätä polttoaineenkulutusta ja tulliselvityksen odotusaikaa.
Integroi poikkeustenkäsittely käyttöliittymiin ja konekäyttöliittymiin samanaikaisesti. Lähetä korkean vakavuuden poikkeukset operaattoreiden operatiivisille tiimeille API-ilmoituksilla ja terminaalien suunnittelijoille käyttöliittymäpaneeleilla. Tarjoa käyttäjille ehdotettuja korjaavia toimenpiteitä: uudelleenohjaus vaihtoehtoiseen laituriin, pyyntö välittömästä polttoainetäydennyksestä tai tulliasiakirjojen ennakkoselvitys. Tallennna operaattorin päätökset ja ratkaisuaika myöhempää analyysiä varten.
Mittaa suorituskykyä näillä suorituskykymittareilla ja tavoitteilla: epäsuhtaitesynty (<5 % 6 kuukauden kuluessa), keskimääräinen yhdenmukaistumisaika (<4 tuntia), palvelutasosopimuksen noudattaminen (≥98 %), polttoainepoikkeama (±3 % raportoidusta tankissa olevasta), ja taloudellinen vaikutusarvio per saapuminen. Käytä viimeisintä kolmea kuukautta perustasona ja suorita lokakuun pilotti johtavalla Aasia-Eurooppa-reitillä 500 tallennetulla saapumisella säästöjen ja mallin tarkkuuden vahvistamiseksi.
Sovella muunnosohjeita, jotka vähentävät päällekkäisiä tapahtumia ja parantavat järjestelmärajapintojen käyttöä: pudota päällekkäisyydet 2 minuutin sisällä samasta lähteestä, yhdistä samanlaisilla vessel_imo+event_origin+timestamp-tiedoilla varustetut tapahtumat ja tallenna raakatiedot alkuperää varten. Merkitse tietueet events_history-taulukolla, jotta analyytikot voivat ymmärtää aikataulutusmallit, jotka johtivat epäsuhtiin matkan aikana.
Hallinnoi tietovirtoja versioiduilla API-sopimuksilla, OAuth2-tunnuksilla per kumppani, rajatuilla kiintiöillä huippuoperaatioiden mukaan (suositellaan 1 200 kutsua/min Event-tilauksille) ja säilytyskäytännöillä (raaka 12 kuukautta, aggregoitu 36 kuukautta). Ylläpidä toimialan laajuista skeemarekisteriä, jotta kumppanit voivat yhdenmukaistaa kenttäsemantiikkaa ja vähentää kartoituspyrkimyksiä alkuintegraatiota pidemmälle.
| DCSA API | Kaapattuja avainkenttiä | Toimenpide | Palvelutasosopimus / Tavoite |
|---|---|---|---|
| Tapahtum API | event_type, aikaleima, sijainti, vessel_imo, voyage_id | Reaaliaikainen kaappaus, webhook ensin, suodatus 2 min | Webhook-toimitus <30s; yritä uudelleen kahdesti |
| Matka API | voyage_id, eta_utc, planned_port_calls, cargo_manifest | Populei kanonisen matkatiedon, merkitse manifestin epäsuhdat | Synkronoi 4 tunnin välein; päivitykset 1 tunnin kuluessa |
| Satamapuhelu API | port_call_id, berth, alongside_time, berthed_time, customs_status | Yhdenmukaista sataman puolen tila, tuo tulliselvitykset esiin | Päivitys <15 min paikallisesta tapahtumasta |
| Referenssitiedot API | sijainnit, terminaalit, operaattorikoodit | Ratkaise nimet/tunnukset, vähennä kartoitusvirheitä | Viikoittainen päivitys; pikakorjaukset 24 tunnin kuluessa |
| Sijainti / AIS | lat, lon, sog, cog, aikaleima | Täydennä ETA/ATA, polttoaineenkulutuksen arviointi | Virtaan latenssi <60s |
Suorita kolmen kuukauden pilotti näillä vaiheilla: ota integraatiot käyttöön johtavalla reitillä lokakuussa, syötä 500 aiempia ja live-saapumisia täsmäytysmallin kouluttamiseksi, iteroi sääntöjä väärien positiivisten vähentämiseksi <8 %:iin ja mittaa taloudellista vaikutusta kuukausittain. Raportoi tulokset tullikumppaneille selvitysaikaikkunoiden lyhentämiseksi ja operatiivisille tiimeille odotusajan vähentämiseksi, joka lisää polttoaineenkulutusta. Käytä pilotoinnista saatuja oppeja laajentaaksesi koko toimialalle ja skaalataksesi rajapintoja, jotta käyttäjät näkevät yhdenmukaistetut saapumistiedot paikallisten siilojen ulkopuolella.
Tunnista kriittinen rajapintasetti alusten saapumistietojen yhdenmukaistamiseksi: vaaditut DCSA API:t ja tietosisällöt
Ota käyttöön tämä minimaalinen rajapintasetti alusten saapumistietojen yhdenmukaistamiseksi: Port Call (voyage/eta), Event Notifications (webhook), Transport/Movement, Booking, Equipment/Container, Terminal Interface, Reference/Location ja Party API:t.
Port Call -tietosisältö: sisällytä voyageId, vesselIMO, vesselName, voyageNumber, portCode (UN/LOCODE), scheduledArrival (ISO‑8601), estimatedArrival, scheduledDeparture, berthingWindowStart, berthingWindowEnd, berthCode, draftMeters, nextPortCode ja sequenceVersion. Käytä numeerisia kenttiä TEU:lle ja luonnokselle, ja toimita sourceSystem ja lastUpdatedBy. Esimerkiksi: scheduledArrival: "2026-03-10T14:00:00Z". Lähetä täydellinen matka-snapshot ensimmäisessä synkronoinnissa ja sen jälkeen deltana.
Event Notifications -tietosisältö: eventType, eventTimestamp, relatedId (voyageId, containerNumber, bookingReference), locationCode, statusCode, details, sequenceNumber ja idempotencyKey. Lähetä application/vnd.api+json JSON:API-muotoisia POST-pyyntöjä tilaajien rajapintoihin retry/backoff- ja eksponentiaalisilla ikkunoilla. Merkitse tapahtumat automaattisiksi tai manuaalisiksi ja sisällytä eventProvenance tunnistaaksesi tapahtuman luoneen järjestelmän.
Transport/Movement -tietosisältö: transportId (GUID), shipmentId, bookingReference, carrierBookingReference, billOfLadingNumber, originUNLOC, destinationUNLOC, mode, containers:[{containerNumber,sizeType,status}], cargoType, weightKg, loadedOnVoyageId ja currentStatusTimestamp. Toimita manifestReference ja estimatedOnboardTime, kun saatavilla, auttaaksesi terminaalin suunnittelussa.
Booking -tietosisältö: bookingReference, shipperPartyId, consigneePartyId, commodities, totalTEU, containerRequirements, portCutoffTimes:{terminalCutoff,gateCutoff,docsCutoff} aikavyöhykkeellä, requestedPickupDate ja confirmedStatus. Käytä näitä arvoja terminaalien aikataulutus- ja ajanvarausjärjestelmien ohjaamiseen; tallenna bookingVersion täsmäytystä varten.
Equipment/Container -tietosisältö: containerNumber, isoSizeType, tareKg, grossKg, currentLocationCode, lastFreeTime, containerStatus ja sealInfo. Yhdistää nämä tietueet transportId:hen ja voyageId:hen, jotta terminaalijärjestelmät ja asiakkaat näkevät yhden totuuden lähteen.
Terminal Interface -tietosisältö: terminalCode, berthCode, availableCraneCount, plannedBerthStart, plannedBerthEnd, gateSlots (aikaleimaikkunat), yardOccupancyPercent ja serviceLevels. Suunnittele malli siten, että terminaalit voivat lähettää laituriin vahvistukset ja paikkavaraukset takaisin Port Call- ja Booking-verkkotunnuksiin.
Reference ja Party -tietosisältö: partyId (operaattori, terminaali, lähettäjä, vastaanottaja), names, roles, contactMethods ja locationList. Toimita UN/LOCODE ja standardoidut roolitermit edistääksesi johdonmukaista täsmäytystä merenkulkualaan osallistuvien järjestelmien kokonaisuudessa.
Protokolla- ja käyttöönottosäännöt: ota käyttöön JSON:API content-type, vaadi RFC3339-aikaleimat, pakota pakolliset avaimet yllä, tue PATCH-pyyntöjä delta-muutoksille ja versioi rajapinnat. Käytä webhookkeja automaattiseen tapahtumien toimitukseen ja tarjoa pull-API täydelliseen synkronointiin. Rajataajuusohjeet: salli 5 pyyntöä/sekunti/asiakas synkronointirajapinnoille ja 1 000 webhook-tapahtumaa/min backoffilla 429-vastauksissa.
Operatiiviset suositukset: lähetä ETA-päivityksiä useammin, kun alus on lähempänä – esimerkiksi 15 minuutin välein, kun se on yli 48 tuntia ulkona, 5 minuutin välein 6 tunnin sisällä ja välittömästi todellisen saapumisen/laituriin menon yhteydessä. Sisällytä sequenceNumber ja lastProcessedEvent vastauksiin, jotta kuluttavat järjestelmät voivat jatkaa ilman päällekkäisyyksiä ja ylläpitää idempotenttiutta.
Valvonta ja käyttöönotto: paljasta mittarit deliverySuccessRate, averageLatencyMs ja processingErrors kuhunkin rajapintaan. Suorita käyttöönotto-tarkistuslista, joka sisältää skeeman validoinnin, webhook-uudelleenyritykset, todennuksen (mTLS tai OAuth2) ja päästä päähän -testit operaattori-, terminaali- ja asiakasjärjestelmien välillä. Määritä poikkitoiminnallinen tiimi kehittämään ja valvomaan näitä kohteita ensimmäisen sprintin aikana.
Kartoitus- ja malliohjeet: kartoita paikalliset kentät kanonisiin nimiin (voyageId, portCode, scheduledArrival) integraatiokerroksessa; säilytä alkuperäiset lähdetunnukset sourceRef-taulukossa. Käytä changeLog-mallia, joka tallentaa kuka muutti mitä ja milloin, ohjaamaan jatkotäsmäytystä ja asiakasilmoituksia.
Turvallisuus ja hallinto: vaadi token-laajuudet per rajapinta ja rajoita palautettavaa tietoa roolin mukaan. Tallenna suostumukset ja sopimusehdot tiedon jakamiseen ja sisällytä auditTrail-merkinnät lähetetyille tapahtumille, jotta asiakkaat ja terminaalit voivat varmistaa alkuperän.
Aloita käyttöönotto priorisoidulta tarkistuslistalta: 1) Port Call ja Event webhooks, 2) Transport ja Booking synkronointi, 3) Terminal interface ja Equipment, 4) Reference ja Party yhdistäminen, 5) valvonta ja käyttöönotto testit. Tämä järjestys vähentää integraatiotyötä kuin ad hoc -menetelmät ja antaa tiimille mahdollisuuden toimittaa näkyvän saapumistietojen yhdenmukaistamisen lähetyksille viikkojen kuluessa.
Muunna satamapuhelutapahtumat kanoniseen saapumisaikajanaan: kartoitusohjeet ja aikaleimojen etusija
Käytä viisivaiheista kartoitus- ja aikaleima-etusijasääntöjoukkoa luodaksesi yhden kanonisen saapumisaikajanan jokaiselle laivalle ja lähetykselle: kartoita raakatapahtumat kanonisiin vaiheisiin, valitse korkeimman prioriteetin aikaleima kullekin vaiheelle, liitä lähteen luotettavuus ja merkitse ristiriidat ihmisen tarkistettaviksi.
Määritä kanoniset vaiheet seuraavasti: lähestyminen (alus 24 NM etäisyydellä satamasta), pilotOnBoard, rinnalla/laituriin, startCargoOps (ensimmäisen konttiliikkeen vastaanottaminen), completeCargoOps ja departure. Kartoita lähdetapahtumat näihin vaiheisiin: AIS-sijaintiraportit, pilotti-/satamaviranomaisen manifestit, terminaalien käyttöjärjestelmän (TOS) laituritapahtumat, operaattorin toimintaviestit (SOC/COC), porttien sisään-/uloskäyntiskannaukset ja aluksen lokikirjamerkinnät. Tallenna yksi kanoninen aikaleima vaihetta kohden ja säilytä alkuperäiset tapahtumalistoitukset tilintarkastusta ja täsmäytystä varten.
Aikaleimojen etusija (korkeimmasta alimpaan): 1 – Satamaviranomainen / pilottiajanleimat pilotOnBoard- ja laiturilupia varten (auktoritatiivinen). 2 – Terminaalien käyttöjärjestelmän aikaleimat rinnallaolemiseen/laituriin menoon ja lastioperaatioiden aloittamiseen. 3 – Terminaali-/konttiporttiskannaukset vastaanottoa ja konttiliikkeitä varten. 4 – Operaattorin toimintaviestit (ETA/ATA, SOC/COC) suunniteltuja ja operaattorin vahvistamia virstanpylväitä varten. 5 – AIS-pohjaiset aikaleimat (sijainti ylittää X NM, pysähtynyt laiturissa) automaattista tunnistusta varten. Normalisoi aina UTC ISO 8601 -muotoon ja liitä lähdetunnus ja luotettavuusarvio.
Ratkaise ristiriidat deterministisillä säännöillä: jos korkeamman prioriteetin aikaleima on olemassa, käytä sitä kanoniseen vaiheeseen. Jos alemman prioriteetin tiedot edeltävät korkeamman prioriteetin aikaleimaa enemmän kuin kynnysarvo T1 = 30 minuuttia laituripaikkaa/rinnallaoloa varten tai T2 = 120 minuuttia lähestymistä/ETA:ta varten, säilytä molemmat aikaleimat, merkitse kanoninen vaihe "epäilyttäväksi" ja aseta sourceConfidence = low. Jos AIS osoittaa rinnallaoloa ennen TOS:ia <30 minuuttia, suosi TOS:ia, mutta tallenna AIS tukevaksi todisteeksi. Puuttuvan korkeamman prioriteetin tiedon tapauksessa promooi seuraava käytettävissä oleva lähde, mutta tallenna promotionReason ja expectedAccuracy (%) lähdetyypin perusteella.
Ota käyttöön kello- ja aikavyöhykehallinta: vaadi kaikkia lähteitä toimittamaan aikaleimat UTC-muodossa. Tunnetulle kellonsiirtymälle, käytä lähdekohtaisia siirtymiä, jotka on laskettu historiallisista vertailuista (tallenna viimeisin siirtymä ja keskihajonta). Hylkää yli 7 päivää vanhat aikaleimat saapumisvaiheille, ellei niihin liity allekirjoitettua satamaviranomaisen asiakirjaa. Käytä maksimikorjausta 60 minuuttia automaattisesti; suuremmat korjaukset vaativat manuaalista tarkistusta.
Suositeltu kanoninen tapahtumaskeema (esimerkki kentistä): eventType, canonicalTimestampUTC, sourceType, sourceId, sourceConfidence(0-1), rawTimestamps[listat], berthId, portUNLocode, vesselIMO, containerCount, affectedContainers[], phaseDurationMinutes. Käytä näitä kenttiä KPI-tulosten tuottamiseksi, kuten ETA-vaihtelun väheneminen, aikaisemmat asiakasilmoitukset ja mitattava siirtoaikojen väheneminen per kontti.
Operatiivinen ohjeistus käyttäjille ja liittoutumille: integroi nämä säännöt operaattori- ja terminaali-API:ihin mahdollistaaksesi johdonmukaiset viestit DCSA-yhteensopivien rajapintojen kautta. Jaa edistetyt säännöt lähettäjille ja asiakkaille, jotta järjestelmät voivat laajentaa automatisoituja työnkulkuja ja optimoida laituri-aikataulutusta. Seuraa viittä käyttöönotto-mittaria: prosentti vaiheista, joissa on auktoritatiivinen lähde, keskimääräinen edistymistiheys, prosentti epäilyttäviä merkintöjä, jotka ratkaistaan 24 tunnin kuluessa, keskimääräinen poikkeama kanonisen ja operaattorin ETA:n välillä, ja varhaisten/myöhästyneiden ilmoitusten väheneminen. Näiden kartoitusten digitalisointi lisää näkyvyyttä toimialojen välillä, auttaa optimoimaan konttiliikkeitä ja siirtämään toimialaa fragmentoituneiden aikaleimojen yli, jotta operaattorit, terminaalit ja lähettäjät saavat aikaisemman, luotettavamman lähetystiedon sekä konttitasoisia vastaanottoja ja tuloksia.
Varmista operaattori- ja konttitunnisteet ennen syöttöä: tarkistusnumerot, koodilistat ja hylkäyskäsittely
Varmista konttinumerot ja operaattorikoodit API-yhdyskäytävässä käyttämällä ISO 6346 -tarkistusnumerologiikkaa ja auktoritatiivisia koodilistoja ennen mitään jatkosyöttöä.
-
Tarkka konttimuoto ja tarkistusnumeron varmennus
- Hyväksy vain 11-merkkisiä ISO 6346 -merkintöjä: omistajakoodi (3 kirjainta) + laitteistoluokka (1 kirjain, tyypillisesti U/J/Z) + sarja (6 numeroa) + tarkistusnumero (1 numero).
- Laske tarkistusnumero: kartoita kirjaimet numeerisiksi arvoiksi (A=10, B=12, C=13