Authorship statement: Mostly me with lots of quotes from Gemini Deep Research.
Back in Oct of last year (2025), I came back to the idea of writing an open book about the maritime Automatic Identification System. I thought that maybe with the power of Gemini Deep Research, I could maybe manage the process of creating a book without getting overwhelmed. Between the onslaught of AI generated text and the competing demands from the day job and all the other distractions of life, the idea collapsed by December. I had even tried talking to friends at NOAA to put some positive peer pressure on myself to make myself find enough focus to keep progress going. I totally failed. AIS can be an immensely broad topic and that by itself overwhelmed me. Doing even just a little bit of research pointed out to me how little I know about the current state of AIS.
So what if I start trying to blog about AIS again? I keep wanting to get back into periodic writing to force myself out of the narrow world view that comes from grinding through work with all of its processes, thrashing through code and bugs, and endlessly trying to understand massive volumes of code that is crazy diverse. This aims to be a quick start on that topic.
One key task in writing out topics boils down to which questions to ask. Each person’s skill level and background will heavily influence which directions an inquiry will go. We are all full of biases, but what questions will drive the research and writing in a positive direction?
Also when a question is asked and answered is crucial. Before AI, we only had to contend with the changing state of the material that we can query. Now we have to deal with the rapidly evolving state of LLMs’ ability to digest the internet’s massive trove of knowledge and turn it into a response. How will the LLM get things wrong; what biases will it bring? That changes every time the model or the harness / system prompt changes. And it changes from run-to-run. Repeatability is near impossible and fact checking / verifying is essential.
We can easily generate more LLM output than we can read and we can fact check an even smaller amount. Should we trust an LLM to fact check LLM output? Maybe a bit. It certainly does catch some problems.
Here is a funny response of an LLM reviewing a report created by an LLM. It’s not actually useful, but it isn’t wrong.
Monolithic Bloat & Schizophrenic Document Scope: The document collapses under its own ambition, conflating historical codebase archaeology, operational runbooks, speculative GenAI roadmaps, and threat models into an unreadable 850-line monolith that serves no single engineering persona effectively.
Here are three questions I asked today. I threw the questions in Google Gemini’s Deep Research. It was quick to generate, but takes a while to read the results.
To make matters worse here, I keep running into issues where Deep Research’s Export to Docs function doesn’t work for me.
1. What is the current state of open source software for maritime Automatic Identification System (AIS) messages? What are the currently used packages? What are the strengths and weaknesses of each?
Right off, this is helpful. It starts at the Software Defined Radio (SDR) level. GNU Radio back in the day supported AIS, but I never had the energy to get that working. The report points at SDRangel, which does support AIS and looks really nice. I soooo need to find the time to get an SDR setup and use it to receive some AIS messages at home. I should be able to get some messages as I am in line of sight of some boats even if I am not right near a big shipping areas.
https://github.com/f4exb/sdrangel/blob/master/plugins/channelrx/demodais/readme.md
https://github.com/f4exb/sdrangel/blob/master/plugins/feature/ais/readme.md
It also mentions rtl-ais, AIS-catcher, then leads into hardware that I didn’t know about like this: dAISy-catcher.
https://shop.wegmatt.com/products/daisy-catcher-high-performance-ais-receiver
At this point, I was less than 20% through the document and running out of time/energy for this post. I saw a mention of GPSD, but hadn’t run into my libais code. Sadly, this is where I found libais when I searched for it. Ouch. Yes, I haven’t had much time to work on libais, but it’s pretty complete for most message types.
Minor Historic and Niche Libraries
The open-source ecosystem also contains several smaller, single-developer projects designed for casual use or niche platforms:
ais-parser (kokufu): A simple Gradle-built Java library designed for basic message parsing. It parses standard sentences starting with !AIVDM or !AIVDO into structured Java instances, supporting Types 1, 2, 3, 5, 18, and 24. It allows developers to register custom record parsers (such as a Base Station Type 4) by extending its segment-offset models. However, it is an archived project with low community engagement.
libais (Schwehr): A legacy, high-performance C++ decoder with SWIG-generated Python bindings. It features two interfaces: a high-level iterator-based Python API and a fast, low-level C++ core. It supports translating parsed objects into legacy GPSD formats. The codebase is stable but is no longer actively maintained, limiting its support for newer ITU-R specifications
And then there are things like KPlex Multiplexer, OpenCPN Plotter, Signal K, canboat / canboatjs, and more. I hadn’t heard of Parameter Group Numbers (PGNs). It mentions Moving Pandas, which I so want to try, but have never spent time on.
I’m left with massive FOMO at this point with some many things like the above and this:
To clean raw AIS logs, analysts use data-driven frameworks such as the $\alpha$-method, which is implemented in Python through the PyTSA (Python Trajectory Search Agent) library.
And from the end of the Deep Research:
Conclusions and Technical Recommendations
The open-source maritime AIS software ecosystem provides a comprehensive set of tools, ranging from embedded software demodulators to high-level spatiotemporal analysis libraries.
When selecting and integrating these packages into production systems, developers should consider several technical guidelines:
SDR Demodulation: For deployments using SDR hardware, AIS-catcher is the industry standard. Its performance-optimized C++ architecture, Neon/SSE vectorization, and multi-SDR support make it superior to legacy tools. To manage its GPL-3.0 license restrictions, developers should isolate the demodulator inside a containerized microservice and interact with it over network sockets (such as UDP or JSON over TCP).
High-Volume Ingestion: For cloud pipelines handling millions of messages per second, the zero-allocation, C#-based Ais.Net core is the most performant option. Where copyleft licensing terms (AGPL-3.0) are a blocker, developers should use go-ais (MIT) or nmea-parser (Apache-2.0).
Data Integration and Sensor Fusion: On-board marine networks should utilize Signal K combined with canboatjs. This stack translates raw binary NMEA 2000 PGNs and NMEA 0183 sentences into a unified, web-friendly JSON schema, simplifying downstream application development.
Data Science and Spatial Analytics: For trajectory analysis and fleet pattern modeling, developers should pair the pure-Python pyais library with MovingPandas and PyTSA. This workflow provides a mature, Python-native environment for spatiotemporal filtering, trip segmentation, and trajectory reconstruction.
2. What are the recent trends and innovations in maritime Automatic Identification System (AIS)?
And now I realized I need to read up on VHF Data Exchange System (VDES). The spec’s first draft is from 2016, so I’m clearly very out of the loop by 10 years. I’m not sure how related to AIS this really is and I worry that people calling it “AIS 2.0” is likely yet more misleading terminology.
https://www.itu.int/rec/R-REC-M.2092
And there are terms I’m not familiar with like Decentralized Physical Infrastructure Network (DePIN). I don’t think things like the Worldwide AIS Network (WAKE), “a decentralized, blockchain-based system designed to track global ship movements” (Gemini’s quote), are going to be that useful, but I haven’t dug into it.
And I didn’t know about S&P Global buying ORBCOMM’s AIS business, but I did know that Andy Lorette died. He was what made my collaboration with ORBCOMM so awesome.
I have a hint about this stuff happening: “AI-Driven Anomaly Detection and Multi-Sensor Fusion for Dark Vessel Monitoring”
Conclusions and Strategic Outlook
The development of the Automatic Identification System (AIS) represents a major shift toward a more secure, digitized, and automated global maritime domain. The transition from legacy SOTDMA broadcasts to the multi-channel VHF Data Exchange System (VDES) addresses the bandwidth constraints of maritime VHF channels, enabling two-way data exchange and supporting the global roll-out of e-Navigation S-100 standards. Furthermore, VDES's IP-less architecture and integrated cryptographic protocols, such as the two-tiered TESLA authentication framework, provide a secure foundation to protect ships from GNSS spoofing, code injection, and electronic manipulation.
At the same time, commercial consolidation has concentrated the global AIS data market, leading to the rise of decentralized alternatives. Decentralized Physical Infrastructure Networks (DePIN) utilize Layer 1 blockchain platforms to capture and verify signal metadata at the point of ingestion, offering a transparent, tamper-proof audit trail for regulatory compliance and supply chain risk management.
Finally, by fusing secure AIS telemetry with spaceborne Synthetic Aperture Radar (SAR) and deep learning models, maritime authorities can systematically detect and monitor dark vessels, helping protect global trade routes, marine habitats, and national sovereignty. As the industry moves toward the mandatory MASS Code in 2032, adopting these secure, high-bandwidth tracking and verification technologies is essential to ensure the safety, efficiency, and resilience of global shipping.
3. What are the current research and development challenges for maritime Automatic Identification System (AIS)?
And at this point, I am totally out of time, so here is the end of the Gemini Deep Research report:
Structural Synthesis of Next-Generation AIS Challenges
The transition of the maritime Automatic Identification System into a secure, high-capacity tracking network is hindered by interrelated physical-layer, cryptographic, and operational challenges. To resolve these limitations, R&D initiatives must coordinate spectrum management, cybersecurity protocols, and autonomous navigation standards23.
The primary challenges and their required technological responses are synthesized below:
Addressing these technical challenges is essential to support the next generation of maritime operations. Securing the legacy AIS broadcast model, resolving satellite-level signal congestion, and establishing robust, authenticated links through VDES will ensure the safety and security of global shipping.
Achieving this requires international coordination among regulatory bodies, technology developers, and shipping operators to implement unified standards for next-generation tracking, cryptographic key management, and autonomous vessel integration.
No comments:
Post a Comment