====== Application Domains – Aerial, Ground, and Marine Vehicle Architectures ======
===== Application Domains Overview =====

Autonomous systems operate across diverse environments that impose unique constraints on perception, communication, control, and safety. While all share a foundation in modular, layered architectures, the operational domain strongly influences how these layers are implemented ((Kendoul, F. (2012). Four-dimensional guidance and control of autonomous aerial vehicles. IEEE Transactions on Control Systems Technology, 20(1), 283–297.))((Corke, P., Roberts, J., & Sukkarieh, S. (2017). Networked robotics: Building large-scale autonomy. Annual Reviews in Control, 43, 19–35)). Some of the most important challenges and differences are listed in the following table:

^ Domain ^ Environmental Constraints ^ Architectural Challenges ^
| Aerial | 3D motion, strict safety & stability, limited power | Real-time control, airspace coordination, fail-safes |
| Ground | Structured/unstructured terrain, interaction with humans. Complex localisation and mapping | Sensor fusion, dynamic path planning, V2X communication |
| Marine | Underwater acoustics, communication latency, and localisation drift | Navigation under low visibility, adaptive control, and energy management |


===== Aerial Vehicle Architectures =====

Aerial autonomous systems include Unmanned Aerial Vehicles (UAVs), drones, and autonomous aircraft. Their software architectures must ensure flight stability, real-time control, and safety compliance while supporting mission-level autonomy ((Kendoul, F. (2012). Four-dimensional guidance and control of autonomous aerial vehicles. IEEE Transactions on Control Systems Technology, 20(1), 283–297)).
UAV architectures are often tightly coupled with flight control hardware, leading to a split architecture:
  - Onboard system (real-time control and perception)
  - Ground control system (mission management, supervision)

<figure UAV Architecture >
{{ :en:safeav:as:rtu_ch1_figure7.png?400| UAV Architecture}}
<caption>Simplified UAV Architecture (based on PX4 and ArduPilot frameworks)</caption>
</figure>

Some of the most popular architectures:

**PX4 Autopilot**
An open-source flight control stack supporting multirotors, fixed-wing, and VTOL aircraft.  The PX4 architecture is divided into Flight Stack (estimation, control) and Middleware Layer (uORB) for data communication ((Meier, L., Tanskanen, P., Heng, L., Lee, G. H., Fraundorfer, F., & Pollefeys, M. (2015). PX4: A node-based multithreaded autopilot architecture. IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS))). The technical implementation of the architecture ensures compatibility with MAVLink communication and ROS 2 integration, making it a very popular and widely used solution.

**ArduPilot**
In comparison, the ArduPilot is a Modular architecture with layers for HAL (Hardware Abstraction Layer), Vehicle-Specific Code, and Mission Control. The technical implementation are widely used by the community and used in research and commercial UAVs for mapping, surveillance, and logistics ((ArduPilot Development Team. (2023). ArduPilot Documentation. https://ardupilot.org)).

Still, some challenges remain:
  * Safety and Redundancy: Flight-critical functions must survive component failures.
  * Communication Constraints: Limited bandwidth and intermittent connectivity.
  * Energy Efficiency: Trade-offs between payload weight and computational power.
  * Airspace Regulation: Compliance with UAV Traffic Management (UTM) systems ((EUROCONTROL. (2022). UAS Traffic Management (UTM) Framework 2.0. Brussels: EUROCONTROL)).

===== Ground Vehicle Architectures =====

Ground autonomous systems encompass self-driving cars, unmanned ground vehicles (UGVs), and delivery robots. Their architectures must manage complex interactions with dynamic environments, multi-sensor fusion, and strict safety requirements ((Bojarski, M., et al. (2016). End to end learning for self-driving cars. arXiv preprint arXiv:1604.07316.)). A ground vehicle’s software stack integrates high-level decision-making with low-level vehicle dynamics, ensuring compliance with ISO 26262 functional safety standards ((Broy, M., et al. (2021). Modeling Automotive Software Architectures with AUTOSAR. Springer)). One of the reference architectures used is Autoware.AI (and its successor Autoware.Auto), which is an open-source reference architecture for autonomous driving built on ROS/ROS 2. It implements all functional modules required for L4 autonomy, including:
  * Perception (object recognition, segmentation)
  * Planning (route, behaviour, trajectory)
  * Control (PID, MPC)
  * Simulation and visualisation tools
Autoware emphasises modularity, allowing integration with hardware-in-the-loop (HIL) simulators and real vehicle platforms ((Kato, S., et al. (2018). Autoware on board: Enabling autonomous vehicles with embedded systems. Proceedings of the 9th ACM/IEEE International Conference on Cyber-Physical Systems (ICCPS))).
Currently, the automotive industry is using several standards to foster the development and practical implementations of future autonomous ground transport systems:
  * **AUTOSAR Adaptive Platform:** Provides safety-certified, service-oriented design.
  * **ISO 26262:** Functional safety standard ensuring risk assessment and hazard analysis.
  * **SAE J3016:** Defines levels of driving automation (0–5).
  * **OpenDrive / OpenScenario:** Data models for simulation and testing.

Due to the environmental complexity, in the autonomous ground vehicles domain, the following main challenges still remain:
  * Sensor Fusion Complexity: Handling heterogeneous sensor data in urban environments.
  * Uncertainty and Prediction: Managing unpredictable behaviours of pedestrians and other vehicles.
  * Computation Load: Real-time inference on limited onboard computing resources.
  * V2X Communication: Integration with smart infrastructure and other vehicles.

===== Marine Vehicle Architectures =====

Marine autonomous vehicles operate in harsh, unpredictable environments characterised by communication latency, limited GPS access, and energy constraints. They include AUVs (Autonomous Underwater Vehicles), ASVs (Autonomous Surface Vehicles) and ROVs (Remotely Operated Vehicles). These vehicles rely heavily on acoustic communication and inertial navigation, requiring architectures that can operate autonomously for long durations without human intervention ([(Benjamin12)].

<figure Marine Vehicle Architecture  >
{{ :en:safeav:as:rtu_ch1_figure8.png?400| Marine Vehicle Architecture }}
<caption>Simplified Marine Vehicle Architecture (based on MOOS-IvP)</caption>
</figure>

The reference architecture is based on the MOOS (Mission-Oriented Operating Suite) IvP architecture discussed previously. It provides interprocess communication and logging, while IvP Helm enables a decision-making engine using behaviour-based optimisation via IvP functions. The architecture supports distributed coordination (multi-vehicle missions) and robust low-bandwidth communication ([(Benjamin12)]. The architecture is extensively used in NATO CMRE and MIT Marine Robotics research ((Curcio, J. A., Leonard, J. J., & Patrikalakis, A. (2005). SCOUT—An autonomous surface craft for oceanographic research. Proceedings of the IEEE/MTS OCEANS Conference.)).

===== Comparative Analysis Across Domains =====

While the overall trend is to take advantage of modularity, abstraction and reuse, the are significant differences among the application domains. 

^ Aspect ^ Aerial ^ Ground ^ Marine ^
| Primary Frameworks | PX4, ArduPilot, ROS 2 | Autoware, ROS 2, AUTOSAR | MOOS-IvP |
| Communication | MAVLink, RF, 4G/5G | Ethernet, V2X, CAN | Acoustic, Wi-Fi |
| Localization | GPS, IMU, Vision | GPS, LiDAR, HD Maps | DVL, IMU, Acoustic |
| Main Challenge | Real-time stability | Sensor fusion & safety | Navigation & communication delay |
| Safety Standard | DO-178C | ISO 26262 | IMCA Guidelines |
| Emerging Trend | Swarm autonomy | Edge AI | Cooperative fleets |

An important trend in recent years is the convergence of architectures across domains. Unified software platforms (e.g., ROS 2, DDS) now allow interoperability between aerial, ground, and marine systems, enabling multi-domain missions such as coordinated search-and-rescue (SAR) operations. The integration of AI, edge computing, and cloud-based digital twins has blurred domain boundaries, giving rise to heterogeneous fleets of autonomous agents working collaboratively. Aerial systems look after stability, lightweight real-time control, and airspace compliance; open stacks like PX4/ArduPilot show how flight-critical loops coexist with higher-level autonomy. Ground systems exploit dense, dynamic scenes, heavy sensor fusion, and functional safety; stacks like Autoware illustrate a full L4 pipeline from localisation to MPC-based control. Marine systems suffer from low-bandwidth communications, GPS-denied navigation, and long-endurance missions; MOOS-IvP’s shared-database and behaviour-arbitration approach fits these realities.
Summarising, a successful autonomy is based on sound software architecture instead of any particular single algorithm. The developed frameworks provide practical blueprints that can be adapted, mixed, and extended to meet mission demands across air, land, and sea.