Application Domains – Aerial, Ground, and Marine Vehicle Architectures

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 ^[1,2]. Some of the most important challenges and differences are listed in the following table:

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 ^[3]. UAV architectures are often tightly coupled with flight control hardware, leading to a split architecture:

1. Onboard system (real-time control and perception)
2. Ground control system (mission management, supervision)

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 ^[4]). 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 ^[5].

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 ^[6].

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 ^[7]. A ground vehicle’s software stack integrates high-level decision-making with low-level vehicle dynamics, ensuring compliance with ISO 26262 functional safety standards ^[8]. 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 ^[9]). 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.