MAGI: A Low-Cost IoT Architecture for Distributed AIS-Based Vessel Monitoring and Maritime Emissions Assessment in Panama

Abstract

Real-time vessel tracking and environmental assessment in developing regions face significant challenges due to the high cost and proprietary constraints of commercial Automatic Identification System (AIS) services. We introduce MAGI, an open-source, low-cost, IoT-distributed architecture that integrates Orange Pi 5 edge nodes with software-defined radio (SDR) AIS receivers and containerized microservices to capture, preprocess, and stream AIS messages. During a ten-day field campaign in Panama, our decentralized deployment processed over 500,000 AIS transmissions, achieving 99% uptime and delivering vessel position and speed updates with sub-second latency. Based on the collected data, we also evaluated system scalability, energy consumption, and per node cost, demonstrating that a complete coastal network can be deployed for under USD 1200 per site. These results confirm that MAGI is a scalable, secure, and affordable IoT solution for AIS-based vessel tracking and environmental monitoring in resource-constrained settings.

1. Introduction

Maritime transport plays a fundamental role in global trade, accounting for over 80% of the world’s merchandise volume [1]. However, this sector is also one of the primary contributors to atmospheric pollution, emitting significant quantities of sulphur dioxide (SO₂), nitrogen oxides (NO_x), and carbon dioxide (CO₂), particularly near port areas and coastal communities [2]. In response, international regulatory bodies such as the International Maritime Organization (IMO) have enacted policies like MARPOL Annex VI, the Energy Efficiency Design Index (EEDI), and the Ship Energy Efficiency Management Plan (SEEMP), aimed at reducing emissions and enhancing the environmental performance of ships [3]. Despite regulatory efforts, many low- and middle-income regions face substantial technological and economic barriers to implementing effective maritime monitoring systems. Commercial Automatic Identification System (AIS) platforms—used for real-time vessel tracking and emissions assessment—are prohibitively expensive, operate under restrictive licenses, and are architecturally closed, limiting their use by local authorities, smaller vessel operators, and research institutions [4,5]. This constraint severely restricts access to the high-resolution, real-time data necessary for accurate emission inventories and evidence-based environmental policy-making. While several existing open-source SDR-based AIS projects offer solutions for signal decoding (e.g., AIS-Catcher [6]), they primarily function as standalone decoders. These projects lack a pre-integrated, robust, and distributed edge computing architecture with built-in data pipeline management (e.g., Kafka) and remote access security, features that are critical for achieving high scalability and operational reliability in remote, resource-constrained field deployments. This deficiency in integrated, low-cost, and robust open-source edge architectures represents the core research gap this paper addresses. Therefore, this work seeks to answer the following research question: Can a modular and open-source Internet of Things (IoT) architecture, built upon low-cost Software-Defined Radio (SDR) and edge computing, achieve the necessary scalability, reliability, and real-time performance to effectively monitor maritime traffic and assess emissions in resource-limited coastal regions, overcoming the limitations of commercial and existing open-source systems? To address this question, this paper presents MAGI, a modular and open-source IoT architecture designed for the complete lifecycle of AIS data: capture, real-time processing, and persistent storage. MAGI integrates Orange Pi 5 single-board computers, SDR receivers, Apache Kafka for data streaming, and a PostgreSQL backend with secure remote access. The system was deployed along the Panamanian coast, successfully collecting over 500,000 AIS messages from more than 500 vessels over a ten-day field campaign. The contributions of this work are as follows:

• The design and implementation of a low-cost, open-source architecture for real-time AIS data acquisition, utilizing SDR receivers and containerized edge computing platforms.
• Validation of the system in a demanding, real-world maritime environment in Panama, demonstrating high coverage and reliability under field conditions.
• Evaluation of MAGI’s scalability, cost-effectiveness, and operational feasibility for establishing robust coastal monitoring networks in resource-limited contexts.

The literature review focuses on three main areas relevant to this work: the application of AIS data for environmental assessment, the use of Software-Defined Radio (SDR) for low-cost AIS acquisition, and the architectural approaches in distributed monitoring systems. We aim to conceptually group existing works to establish the distinctive contribution of the MAGI architecture.

1.1. AIS Data for Maritime Emissions Assessment

The Automatic Identification System (AIS) was initially mandated for vessel safety and traffic management [7]. However, research has increasingly established its utility for environmental studies, particularly for estimating ship emissions based on operational parameters (speed, course, engine characteristics) [8,9,10,11]. The feasibility of using AIS data combined with established methodologies (e.g., Tier 1 emission factors) to assess port and coastal air quality has been validated in various regions, including South Korea [12] and Brazil [4]. While these studies successfully demonstrate the potential of AIS for environmental monitoring, the underlying data collection and processing infrastructure typically relies on expensive commercial AIS receivers and centralized proprietary platforms. This reliance on high-cost infrastructure is the primary limiting factor for adopting these methodologies in developing regions and independent research contexts.

1.2. Low-Cost AIS Acquisition and SDR Solutions

The high cost of commercial AIS receivers has prompted exploration into open-source alternatives. Software-Defined Radio (SDR) technology, using low-cost hardware like the RTL-SDR dongle [13], provides a viable pathway for acquiring AIS messages. Research has shown that SDR-based receivers can reliably decode AIS frames, proving the technical feasibility of replacing proprietary receivers with open-source alternatives [14]. However, existing open-source SDR projects, such as AIS-Catcher [6] or rtl-ais, focus almost exclusively on the local decoding of raw signals. They operate as standalone applications and typically lack integrated features for (1) managing a distributed network of edge devices, (2) providing a robust, fault-tolerant data streaming layer, or (3) ensuring secure remote access and centralized database persistence. Therefore, while the decoding problem has been addressed, the deployment and system management challenge in a distributed, resource-constrained network remains largely unsolved by existing open-source tools.

1.3. Distributed IoT Architectures for Monitoring

From an architectural standpoint, commercial AIS tracking services (e.g., MarineTraffic, VesselFinder [15,16]) offer cloud-based vessel position services. However, these are closed platforms that do not provide access to the raw AIS data stream, precluding custom, research-focused analysis pipelines (such as emissions modeling or local data enrichment). The literature on environmental monitoring has embraced modular, containerized microservices and edge computing to enhance scalability and resilience. However, few systems have successfully applied this architectural rigor specifically to the end-to-end AIS monitoring problem. Existing proposals often rely on monolithic designs or proprietary components, resulting in limited adaptability to distributed deployment scenarios and high maintenance overhead.

1.4. Conceptual Grouping and MAGI’s Position

To synthesize the preceding analysis, Table 1 presents a conceptual comparison of MAGI against the primary categories of existing solutions. This comparison explicitly evaluates the economic advantage and architectural superiority of MAGI over the commercial state-of-the-art. This comparison highlights MAGI’s unique position in the field, which addresses the gap between low-cost acquisition and robust, scalable system architecture.

Table 1. Conceptual Comparison of Maritime Monitoring Systems.

Feature/System Type	Commercial Platforms	AIS Emissions Studies	MAGI Architecture (This Work)
Cost of Hardware/License	High	High/Proprietary	Low/Open-Source
Access to Raw AIS Data	No (Position only)	Limited/Expensive	Yes (Distributed/API)
Data Pipeline (Kafka/MQ)	Proprietary/Internal	Absent/Custom	Integrated (Kafka)
Edge Computing	Absent/Centralized	Absent/Centralized	Integrated (Containerized)
Scalability/Distribution	High (Cloud)	Low (Site-specific)	High (Distributed Edge)
Applicability in Dev. Regions	Low	Low	High

This work addresses the critical need for an integrated, low-cost, and robust open-source edge architecture. MAGI is distinct because it is the only system that combines all four essential features: low-cost SDR acquisition, distributed edge processing via microservices, fault-tolerant real-time data streaming (Kafka), and open, customizable access to raw data.

2. Materials and Methods

2.1. System Overview

The proposed system is a modular, distributed architecture for real-time AIS signal acquisition, processing, and storage. It combines low-cost embedded computers, software-defined radio (SDR) receivers, containerized services, and a relational database backend to deliver a scalable solution for vessel monitoring and emissions estimation. The system is structured into three main components, as shown in Figure 1:

Figure 1. Architecture and components for real-time AIS signal acquisition.

• The AIS Signal Acquisition Module: This component is responsible for capturing and decoding AIS signals in real time from a remote location.
• The Messaging Middleware Layer: Implemented using Apache Kafka, this layer serves as a central, decoupled data bus that efficiently handles the high volume of AIS messages.
• The Backend Processing Stack: This comprises a series of containerized microservices that process, enrich, and store the AIS data in a PostgreSQL database.

2.2. Hardware Components

As shown in Figure 2, the MAGI system comprises four main hardware elements: (a) the Shakespeare AIS-5250 VHF antenna, (b) the NESDR SMART v5, (c) the Orange Pi 5 and internal electronic components, and (d) the backend server.

Figure 2. MAGI-Receptor hardware. (a) Shakespeare AIS-5250 VHF antenna, (b) Software-Defined Radio (SDR) receiver NESDR SMArt v5. (c) MAGI-Receptor components (Orange Pi 5 + SDR Receiver) inside the box. (d) The backend server (Two Orange Pi 5 + 4TB HDD for storage).

The Shakespeare Skinny Mini^TM Style 5250-AIS (Shakespeare Company LLC, Columbia, SC, USA), an omnidirectional high-gain antenna specifically designed for AIS applications, was used for signal acquisition. This 36-inch-long antenna with a 1/2-wave end-fed design is optimized to operate on the marine VHF frequencies of 161.975 MHz and 162.025 MHz [17]. Its internal construction includes a sealed, tinned-plated copper wire coil, and it connects to the equipment using an RG-58 coaxial cable and a PL-259 connector. The antenna has a gain of 6 dB, which allowed the reception range to be extended up to 60 nautical miles under ideal conditions. Its robust design, ease of mounting, and the advantage of not requiring an external or internal ground system make it an ideal choice for coastal or on-board installations. Due to its omnidirectional design and fixed installation, the antenna does not require continuous calibration or alignment checks following weather events. However, given the corrosive environment of a tropical coast, we recommend a visual inspection every three months to verify the integrity of the cable connections and the mounting structure. Furthermore, the real-time performance monitoring dashboard (provided by ais-catcher) allows for indirect verification of reception quality (via message rate and maximum range), serving as a crucial indicator for detecting any potential signal degradation that might necessitate a physical maintenance intervention.

The Software-Defined Radio (SDR) receiver ‘NESDR SMArt v5’ (Nooelec LLC, Tonawanda, NY, USA) was selected, recognized as a high-performance, low-cost device. This SDR, based on the ‘RTL2832U’ demodulator and the ‘R820T2/R860’ tuner, is capable of capturing radio frequency signals in a range of 100 kHz to 1.75 GHz, with an instantaneous bandwidth of up to 3.2 MHz [18]. It offers an improvement in signal-to-noise ratio (SNR) of up to 6 dB in VHF and UHF frequencies compared to previous versions, thanks to an ultra-low phase noise TCXO (Temperature-Compensated Crystal Oscillator) of 0.5 PPM. The device features a female SMA antenna connector, and its narrow form factor is ideal for tightly-spaced embedded devices like the Orange Pi. Its compatibility with operating systems such as Windows, Mac OS, Linux, and Android, and its USB connection, make it ideal for implementation in this type of architecture.

An Orange Pi 5 single-board computer (Shenzhen Xunlong Software Co., Ltd., Shenzhen, China) was selected as the main processing node, equipped with an ARM-based 8-core processor, 16 GB of RAM, and 128 GB of integrated storage [19]. This hardware provides sufficient performance to run the microservices in Docker containers. Its low power consumption, of less than 10 W, makes it ideal for deployments in remote locations or with limited power sources. Two additional microcomputers of the same type were used for the system’s backend infrastructure. The correct integration of these components not only allowed for the construction of a functional system but also laid the groundwork for its field deployment.

The system was installed on the rooftop of a university research building located approximately 90 m above sea level, ensuring line-of-sight reception of maritime signals near both entrances of the Panama Canal. A schematic overview of the MAGI-Receptor station deployed is presented in Figure 3, which illustrates the integration of the antenna, the SDR receiver, the Orange Pi nodes and the backend services within the secured communication framework.

Figure 3. Schematic overview of the deployed MAGI-Receptor station, showing the integration of the VHF antenna, SDR receiver, Orange Pi 5 edge nodes, messaging middleware (Kafka), backend database, and VPN-secured communication layer.

2.3. Software Architecture

The system was developed using a microservices-based software architecture, where each component fulfils a specific function within the AIS data processing flow. The MAGI platform is entirely open-source, and its complete source code, including Dockerfiles and deployment scripts, are available under the MIT license at our public repository: https://github.com/YESUBZERO/MAGI-System (accessed on 18 August 2025). The implementation was focused on efficiency, portability, modularity, and scalability, leveraging modern tools such as Docker, Python, Golang, and Kafka, all deployed on a Linux base. The overall conceptual design, illustrating the components and data flow, is presented in Figure 4 and the software versions used for key components are summarized in Table 2. The main modules that make up the software environment are detailed below.

Figure 4. Conceptual Diagram of MAGI’s Distributed Software Architecture and Data Pipeline.

Table 2. Key Software Components, Versions, and Manufacturers

Component	Role	Language/Framework	Version	Manufacturer
ais-catcher [6]	SDR Decoder	C	0.17	Independent Developer, Austria
Docker	Containerization	-	24.0.5	Docker Inc., Palo Alto, CA, USA
Docker Compose	Orchestration	-	2.20.2	Docker Inc., Palo Alto, CA, USA
Apache Kafka [20]	Messaging Middleware	Scala/Java	3.9	Apache Software Foundation, Wakefield, MA, USA
PostgreSQL [21]	Database	-	15.0	PostgreSQL Global Development Group, Berkeley, CA, USA
MAGI Microservices	Processing Logic	Python/Go	3.10/23.5	Our

2.3.1. AIS Capture and Decoding

The ‘MAGI-Receptor’ module constitutes the first operational layer of the system, responsible for capturing and decoding AIS signals transmitted by vessels within the coverage range. This functionality is implemented through the open-source tool ‘ais-catcher’ [6], deployed in a Docker container, in conjunction with a Python service that transforms the data into a structured format and forwards it to the Kafka messaging system. The ‘ais-catcher’ microservice listens for AIS signals using the SDR device connected via USB to the Orange Pi 5 microcomputer (Shenzhen Xunlong Software Co., Ltd., Shenzhen, China), decodes the AIS frames, and forwards the data in NMEA-0183 format via UDP ports to the ‘ais-decoder’ microservice. The ‘ais-decoder’ microservice, in turn, receives the NMEA frames, validates and classifies them as static or dynamic data, and then transforms the data into JSON structures to publish them to a Kafka topic for subsequent storage. The ‘ais-catcher’ microservice was chosen for being a modern and efficient decoder. Unlike tools such as ‘rtl_ais’, ‘ais-catcher’ allows for multiple simultaneous outputs (UDP, TCP, HTTP), advanced gain configuration, multi-channel support, and continuous operation. Its main features include real-time decoding of AIS-A and AIS-B channels; data forwarding via UDP to multiple destinations; output in NMEA format compatible with commercial systems; and an embedded HTTP module that provides a web dashboard for live visualization and monitoring of real-time performance metrics. The advantages of the approach lie in the low resource consumption, ideal for embedded devices such as the Orange Pi 5, and the complete decoupling of the system through Docker and Kafka.

2.3.2. Kafka Messaging System

The central component that facilitates efficient and decoupled communication between the system’s modules and services is the Kafka messaging broker. This service was selected for its ability to handle high-volume, low-latency data streams, in addition to its guarantees of durability, fault tolerance, and horizontal scalability [20]. Its topic-based architecture (‘static-message’, ‘dynamic-message’, ‘scraper-message’, and ‘enriched-message’) organizes the information by category, allowing each consumer to access only the data it needs. The system’s flow begins with the publication of messages from the ‘MAGI-Receptor’ to the ‘static-message’ and ‘dynamic-message’ topics, which are then consumed by the backend microservices. This segmented design ensures a clear, modular, and extensible pipeline for AIS data processing.

2.3.3. Backend and RESTful API

The backend consists of a series of microservices developed in Go (Golang), each with defined responsibilities in the data flow from Kafka to the database. These microservices transform AIS data into structured, enriched, and queryable information. The modular design favors system maintenance, scalability, and resilience.

• MAGI-Consumer: Consumes messages from the ‘static-message’ topic, validates them, and sends them to the ‘MAGI-Enricher’ via the ‘scraper-message’ topic for enrichment.
• MAGI-Enricher: Enhances static AIS messages with technical information about vessels (e.g., year built, engine type, dimensions). Once enriched, the data are published back to Kafka in the ‘enriched-message’ topic.
• MAGI-Storage: Is responsible for consuming dynamic messages from the ‘dynamic-message’ topic for persistent storage in the PostgreSQL database.
• MAGI-Exporter: Constitutes the RESTful API that exposes the stored data through a public endpoint (‘/export/ship-positions’), allowing data to be exported in formats compatible with external analysis systems. Figure 4 illustrates an end-to-end data pipeline for processing AIS signals.

2.3.4. PostgreSQL Database

The system database was implemented using the PostgreSQL relational management engine, leveraging its compatibility with advanced SQL operations, large-scale stability, and extensibility [21]. The database contains two main tables: ‘ship_positions’, which stores dynamic data such as latitude, longitude, course, and speed; and ‘ships’, which holds static and enriched vessel information, such as dimensions and propulsion. This relational model is essential for future emissions calculations and ensures the referential integrity and efficiency of historical queries.

2.3.5. Containerization with Docker and Docker Compose

To ensure the system’s portability, scalability, and reproducibility, all components were containerized using Docker. This strategy encapsulates the dependencies and configurations of each microservice, ensuring their consistent execution across different environments, from embedded devices to remote servers. Each microservice has its own ‘Dockerfile’, and their orchestration is managed using a ‘docker-compose’ file, which defines the containers, internal networks, volumes, and environment variables [22].

2.3.6. Private Network and Remote Access with Tailscale VPN

For secure remote administration of the system in the field, a virtual private network (VPN) based on Tailscale was implemented. This tool, which uses the WireGuard protocol, creates a mesh network between the nodes, facilitating a direct, encrypted, and authenticated connection without needing to expose public ports. Tailscale simplifies the configuration by using identity-based authentication, which allowed secure access to internal services (REST API, database) from remote workstations, ensuring the security of the monitoring environment.

2.4. Data Validation and Consistency

To ensure the quality and consistency of the collected data, a multi-stage validation process was integrated into the software architecture.

• NMEA Frame Validation (Edge Layer): The ais-decoder microservice first performs a basic integrity check on the incoming NMEA-0183 messages received from ais-catcher. This includes verifying the checksum and message length to filter out corrupted frames caused by environmental noise or poor signal reception.
• Schema Consistency (Storage Layer): The MAGI-Storage service applies strict schema validation before persistence. Data types are verified against the predefined PostgreSQL table schema. Furthermore, the ships table uses the MMSI (Maritime Mobile Service Identity) as the primary key, ensuring referential integrity and preventing duplication of static vessel information.

This multi-layered approach ensures that data stored in the PostgreSQL database are accurate, internally consistent, and reliable for subsequent emissions modeling.

2.5. Deployment Site and Experimental Protocol

The system was deployed on the rooftop of a university research building located approximately 90 m above sea level (coordinates: 9°01′27.6″ N, 79°32′03.4″ W). This strategic location provided direct line-of-sight visibility of the maritime approaches of both the Atlantic and Pacific oceans. The experiment was conducted over a 10-day period in April 2025. Data were collected continuously and summarized in daily batches. Each 24-h cycle included synchronization with a project database and dashboard system to track newly detected vessels. The following variables were monitored during the campaign:

• Number of AIS messages received per minute.
• Number of unique vessels detected.
• Maximum detection range (in nautical miles).
• Frequency and type distribution of AIS messages.
• Availability and resource usage of backend services.

System performance was evaluated using log files, service monitors, response times from API endpoints, and dashboard visualizations. Metrics included latency, operational uptime, and accuracy of vessel classification.

3. Results and Discussion

During the ten-day field experiment conducted in April 2025, the proposed system operated continuously, successfully capturing AIS transmissions from vessels transiting through both the Pacific and Atlantic approaches of the Panama Canal. Applying the multi-stage validation procedure detailed in Section 2.4, the raw AIS messages successfully passed the NMEA checksum and content range checks. This resulted in a total of 500,000 clean, structured records stored in the PostgreSQL database, confirming the high integrity of the data pipeline and the effectiveness of the validation filters in eliminating corrupted or spurious transmissions, thereby fulfilling the objectives of this experimental phase. The collected data were analysed from multiple perspectives, including message volume, message type distribution, vessel classification, spatial coverage, system stability, and data quality. Real-time graphs generated using the monitoring platform facilitated continuous assessment of the operational behaviour of the MAGI-Receptor station.

The total non-recurrent cost (hardware and licenses) for a single MAGI-Receptor station and its associated backend infrastructure (excluding deployment costs) was estimated to be USD 700. This cost is dominated by the high-gain VHF antenna ($95) and the Orange Pi 5 microcomputers ($180 each). This investment represents a significant reduction—an estimated 80–90%—compared to commercial, licensed AIS receiver stations (which often exceed USD 1500 for a single unit) combined with proprietary cloud subscription fees.

3.1. Cost-Performance and Energy Trade-Off Analysis

The primary objective of the MAGI architecture was to balance cost with professional-grade performance suitable for continuous monitoring, with energy efficiency being a critical factor for remote deployment. The empirical results validate this trade-off: a total investment under USD 1200 yielded operational metrics comparable to commercial systems. A detailed power assessment showed that the total power draw for the MAGI-Receptor station (Orange Pi 5 running decoder, Kafka producer, SDR, and antenna) averages approximately 5 W for the entire edge node. This low requirement contrasts sharply with the 20–60 W typically consumed by proprietary AIS receiver units. This profile translates directly into enhanced deployment flexibility and cost savings, particularly in resource-limited regions:

• Autonomy: The average power draw of 5 W allows the system to be sustainably powered using small, cost-effective solar power systems. For instance, a basic 50 W solar panel with a small battery (e.g., 50 Ah) can ensure continuous 24/7 operation, providing energy autonomy critical for remote coastal sites.
• Thermal Management: The low power dissipation reduces the thermal load inside the protective enclosure, simplifying the cooling requirements and increasing the long-term reliability of the system’s electronic components in hot climates.

3.2. System Performance: Coverage and Message Rate

Figure 5 illustrates the temporal evolution of system performance: (a) shows the number of AIS messages processed per minute and the number of vessels detected, consistently exceeding 250 messages per minute with peaks above 350 vessels simultaneously. (b) presents the maximum detection distances, which fluctuated between 38 and 60 nautical miles (70–111 km), validating the effectiveness of the VHF antenna installation.

Figure 5. Performance and distance analysis of the MAGI-Receptor station: (a) AIS messages and vessels detected per minute; (b) maximum detection range in nautical miles.

A geospatial analysis of reception coverage is presented in Figure 6. The MAGI-Receptor installation achieved robust detection zones spanning both entrances of the Panama Canal, extending further offshore. The hexagonal tiling highlights the effective reception boundaries and distribution of detected vessels.

Figure 6. Geospatial coverage of the MAGI-Receptor deployment, showing vessel detections and reception boundaries near Panama City.

3.3. Real-Time Response Time and Reliability

The real-time performance of MAGI is evaluated across two critical dimensions: the processing time at the edge and the data delivery latency to external consumers. The internal pipeline, from signal capture (SDR) to publication in the Kafka messaging system, exhibited a near-real-time performance, with an estimated end-to-end latency below 200 ms. This rapid processing is attributed to the optimized ais-catcher decoder and the high-speed I/O capabilities of the Orange Pi 5. This low latency is essential for applications requiring immediate situational awareness, offering a significant advantage over satellite-based AIS systems, which typically introduce delays of several minutes due to orbital transmission and ground station processing. Furthermore, the system sustained a consistent data ingestion rate, reliably handling over 250 position messages per minute.

The MAGI-Exporter RESTful API further guarantees rapid data access for external applications. During the field trial, the API consistently delivered responses with latencies below 180 ms (for querying recent vessel positions). This performance is highly competitive with commercial web services and ensures that MAGI can serve real-time dashboard applications effectively.

Operationally, the system demonstrated high stability, maintaining 99% uptime with only minimal interruptions attributed to brief power fluctuations. The RESTful API developed for remote access consistently delivered responses with latencies below 180 ms. This API was used both for internal validation and for daily synchronization with an external dashboard, enabling real-time monitoring by the AirES research group as part of the INEMIS-SEA project.

The reliability of the MAGI system, crucial for maritime monitoring, is structurally superior to monolithic proprietary solutions due to its modular microservices architecture and the integration of Apache Kafka. While the measured $99\%$ uptime confirms high stability, the architectural design ensures enhanced data integrity and fault tolerance. Specifically, the Kafka messaging queue acts as a durable buffer, decoupling the acquisition layer (SDR/Orange Pi) from the processing stack (Go microservices). This prevents data loss in the event of transient failures in downstream components (e.g., database outages) by retaining the message stream until services recover. This distributed resilience contrasts sharply with traditional single-receiver systems, where failure of a single component often leads to catastrophic data loss, validating MAGI as a reliable and robust platform for continuous operational use.

The distribution of AIS message types, as shown in Figure 7, revealed a clear predominance of dynamic Class A position reports (messages 1, 2, and 3), which accounted for more than 60% of all transmissions (181.1). These reports are fundamental for real-time vessel tracking, as they provide dynamic data such as position, course, and speed, thereby supporting both maritime safety and traffic management. The second most frequent category was static and voyage-related data (message 5), with 46.7 transmissions, offering complementary information including vessel identification, dimensions, and intended destination.

Figure 7. Dashboard screenshot illustrating the distribution of AIS message types processed during the experiment. Dynamic position reports (Types 1–3) and static information (Type 5) were the most frequent.

Overall, this pattern reflects the operational design of the AIS system, as shown in Figure 8, where priority is placed on the frequent update of vessel positions, complemented by static and infrastructure-related information that provides additional context and reliability for maritime monitoring and surveillance. In terms of vessel classification, cargo and tanker ships represented the majority of detections, consistent with the commercial profile of maritime traffic in the region. Additional classes included passenger vessels, tugs, and specialized ships. Figure 9 depicts the proportional breakdown of detected vessel categories.

Figure 8. AIS-catcher dashboard visualizations, illustrating the real-time monitoring interface for performance metrics, message statistics, and vessel classifications.

Figure 9. Proportional distribution of vessel types detected by the MAGI-Receptor system, highlighting the predominance of cargo and tanker ships.

Overall, the results confirm the technical viability of the MAGI-Receptor architecture for continuous maritime monitoring in resource-constrained environments. The system effectively captured high-frequency AIS transmissions, ensured reliable coverage across critical maritime corridors, and provided structured data streams suitable for subsequent emissions estimation and environmental analysis.

4. Conclusions and Future Work

This work presented the design, implementation, and field validation of MAGI, a low-cost, modular, and distributed system for real-time AIS signal acquisition and maritime monitoring. Built entirely using open-source tools and embedded devices, MAGI aims to democratize access to vessel traffic data and support future integration with environmental assessment frameworks.

The system was successfully deployed for a ten-day experimental campaign in April 2025, near the Panama Canal. During this period, it captured over 500,000 AIS messages from 500 unique vessels, achieving a maximum detection range of 60 nautical miles and maintaining 99% operational availability. The architecture integrates SDR receivers, embedded edge computing, microservices, and a VPN-secured communication layer to deliver structured AIS data through a RESTful API.

Despite minor limitations related to incomplete enrichment of static vessel metadata, the system consistently captured and stored dynamic messages, supporting real-time access and synchronization with external dashboards. These results confirm MAGI’s technical viability and cost-effectiveness as a platform for vessel tracking in resource-constrained environments.

Significantly, the design of MAGI extends beyond technical utility, promoting democratization of maritime data. By offering an accessible, transparent, and reproducible monitoring platform, this architecture empowers local authorities and research institutions—particularly in developing countries—to establish cost-effective surveillance networks. This capability directly supports evidence-based policy making, enhances regulatory enforcement (e.g., MARPOL Annex VI compliance), and facilitates citizen science initiatives related to environmental governance in critical waterways like the Panama Canal.

Looking ahead, several lines of development are proposed. First, the system will incorporate a real-time emissions estimation module using Tier 1 emission factors from the EMEP/EEA Guidebook. Given the system’s reliance on standard AIS formats (IEC 61162),Additionally, to strengthen data integrity, future versions of MAGI will integrate AIS signal verification and anomaly detection mechanisms to identify potential false or spoofed transmissions—an increasingly relevant challenge in modern maritime monitoring. We will also develop specific operational contingencies, such as local data buffering during communication failure and refined power management policies, to ensure graceful shutdowns during severe weather events, thereby maximizing continuous monitoring capability. Finally, the architecture will be extended to support multi-zone deployments along Panama’s coastline, enabling simultaneous coverage of multiple maritime corridors.

These future developments will strengthen MAGI’s role as a foundational tool for environmental monitoring, emissions modelling, and AI-assisted maritime analytics in developing coastal regions.