Inspiration
Huge inspiration source was Just in Time (JIT)article from DCSA where it describes the "Hurry up and wait" paradigm that is incentivised by many shortcommings. Intent sharing and efficient communication has a long way to go in inland shipping. In order to deliver goods from point A to point B as efficiently as possible, inland shipping has to rely on multiple potential impediments. Missing a spot in a lock can delay and spiral out of control ETA of any inland ship. Furthermore, inland shipping has shorter, yet significantly more frequent trips. And within those trips(and almost every day) shippers have to rely on smooth operation of not only harbours, but also locks.
These small inefficiencies add up to a point where it is ridiculous not to start tackling problems with 'inefficient traffic'. We propose a Proof of Concept intent sharing between locks and inland vessels by utilizing DCSA OpenAPI JIT standard. DCSA OpenAPI JIT standard not only improves the interoperability between all parties, but also it is SAFE and MORE SECURE solution than relying on AIS protocol.
What it does
Waterway locks are listening for incoming AIS messages, but instead of trusting the broadcasted message*, the lock dispatcher (using intent sharing dashboard) is querying for information at DCSA compliant terminal and carrier APIs. Lock operator receives a concise information about incoming ships (ETA, RTA, time budget, destination etc.), the operator can plan which ships to prioritize as illustrated in the diagram bellow. By augmenting locally broadcasted information with compliant DSCA JIT API lock operators can reduce potential complications in time scheduling for all stakeholders.
*AIS messages can be maliciously produced by any party and act as any actor.
How we built it
Firstly, DCSA OpenAPI specification for JIT Portcalls was used.
In order to demonstrate the usefulness and high potential of DCSA OpenAPI JIT standard in inland shipping, Proof of Concept (PoC) dashboard with mockup data was developed. PoC consists of four parts:
- frontend: dashboard (User Interface)
- backend: DCSA JIT OpenAPI (Data Interface; non simulated)
- backend: ship data processor (simulated data)
- backend: lock worker - processes simulated data to mimic 'real' interactions
To fit right in with the shipping theme - PoC is shipped and deployed using docker containers and is temporarily available using the container orchestrator kubernetes (helmsman in greek).
Challenges we ran into
- Deploying and making the dashboard available on Google Kubernetes Engine was an ambitious task for a short project
- In order to build a representable PoC for intent sharing within limited time we had to cut corners in other Use Cases (see what's next)
Accomplishments that we're proud of
We are proud that we have made and deployed a well wrapped PoC that can demonstrate the power of both open source standards, but also the potential improvements that open APIs can give.
What we learned
We've learned that the DCSA organization is doing a very difficult job bringing everyone under the same umbrella. We've found out that it is not only useful, but there are many use cases both in inland shipping and out. We would like to see what other standards DCSA would develop. Also, having a well defined and documented standard for higher abstraction communication (not AIS and NMEA messages) has a lot of potential in reducing complexity and increasing interoperability.
What's next for Secure intent sharing and using DCSA API mediation
Firstly, this PoC of intent sharing has only designed one way communication between Ships/Shipping companies and Locks. If lock operations would be able to integrate JIT OpenAPI into their scheduling system, shipping companies could estimate ETA/RTA or any other times within the business process.
Secondly, a direct negotiation between locks and ships can be established. It can be as simple as the lock providing its own RTA for the lock arrival (EAGERLY)
Thirdly, to ensure fast, reliable and secure communication, JSON Web Token (JWT) or Platform Agnostic Security TOkens (PASETO) that is linked to a DCSA compliant API can be embedded in broadcasted AIS messages. The information embedding would provide all objects in proximity with instructions of how to interact with the 1st party in a more complex matter. The information embedding also ensures future proofing ourselves in ever growing complexity in intent sharing.
Log in or sign up for Devpost to join the conversation.