====== Typical Autonomous System Software Architecture ======

Autonomous systems, regardless of their physical domain — ground, aerial, or marine — share a common architectural logic that structures how data flows from sensors to decision-making and control units. This section explores the typical functional architecture and the operational pipeline that enable autonomous behaviour.

===== The Sense–Plan–Act Paradigm =====

The foundation of most autonomous systems lies in the Sense–Plan–Act (SPA) paradigm, introduced in early robotics and still relevant today. It slightly extends a general controllable system’s architecture by introducing explicit steps of sensing, decision making and acting. This model organises operations into three distinct but interdependent stages:
  - **Sense:** Gather and interpret data from sensors to build an internal representation of the environment.
  - **Plan:** Use that representation to decide on goals, trajectories, or actions.
  - **Act:** Execute those actions through control and actuation mechanisms.
This conceptual model remains universal across domains and can be represented as follows.

<figure The Sense–Plan–Act Cycle >
{{ :en:safeav:as:rtu_ch1_figure2.png?400| The Sense–Plan–Act Cycle}}
<caption>The Sense–Plan–Act Cycle ((Russell, S. J., & Norvig, P. (2021). Artificial Intelligence: A Modern Approach (4th ed.). Pearson)) </caption>
</figure>

The SPA cycle forms the basis for layered architectures in autonomous vehicles, where each layer refines or extends one part of this process. In practice, modern architectures also include learning and communication layers that enhance adaptability and collaboration between agents ((Kendoul, F. (2012). Four-dimensional guidance and control of autonomous aerial vehicles. IEEE Transactions on Control Systems Technology, 20(1), 283–297)).

A simplified data-flow architecture illustrates how perception data transitions through layers to produce control actions via extending the SPA architecture to a more applicable one :

<figure Data Flow in a Typical Autonomous System  >
{{ :en:safeav:as:rtu_ch1_figure3.png?400| Data Flow in a Typical Autonomous System }}
<caption>Data Flow in a Typical Autonomous System  (Inspired by ROS and JAUS standards) </caption>
</figure>

This closed-loop interaction ensures that systems continuously update their understanding of the world, adjusting behaviour based on environmental changes or feedback from control execution ((Kroeger, T., et al. (2019). Real-time control architectures for robotics. Annual Review of Control, Robotics, and Autonomous Systems, 2, 45–68)).

===== Distributed vs. Centralised Architectures =====

Architectural organisation also depends on whether processing is centralised or distributed:
  * **Centralised Architectures:**
    * All decision-making occurs on a single computing unit.
    * Easier synchronisation but can become a bottleneck.
    * Common in small-scale robots and drones.
  *** Distributed Architectures:**
    * Tasks are distributed among multiple computing nodes or agents.
    * Enhanced scalability and fault tolerance.
    * Essential for multi-vehicle coordination (swarm robotics, fleet operations).
Middleware frameworks like ROS 2 and DDS are inherently designed to support distributed computation, enabling decentralised data exchange in real time ((Maruyama, Y., Kato, S., & Azumi, T. (2016). Exploring the performance of ROS2. Proceedings of the 13th Embedded Real-Time Systems Workshop (ERTS 2016))).

===== Safety and Redundancy =====

Safety is a critical design consideration. Redundant architectures replicate essential components (e.g., dual sensors, parallel computing paths) to ensure operation even during failures. For example, aircraft autopilot systems employ triple-redundant processors and cross-monitoring logic ((FAA. (2021). Advisory Circular 20-167A: Airborne Systems Safety. Federal Aviation Administration)). Similarly, marine vehicles use redundant navigation sensors to counter GPS outages caused by water interference.
Architectural safety mechanisms include:
  * Failover controllers
  * Health monitoring nodes
  * Watchdog timers
  * Self-diagnostics and logging subsystems
These ensure resilience, especially in mission-critical or human-in-the-loop systems.