Middleware and autonomy software architecture

Modern autonomous systems use layered software stacks. Low-level firmware and drivers manage sensors, actuators and compute hardware. Operating systems and runtimes provide scheduling, memory management, process isolation and resource control. Middleware provides communication services, discovery, time synchronization, quality-of-service policies, logging and health monitoring. Application-level modules implement perception, localisation, planning, control and mission functions. Supervisory services handle diagnostics, fleet operation, updates and data analytics.

Middleware is the backbone that allows these layers to operate as a system rather than as disconnected modules. Frameworks such as ROS 2, DDS-based communication, AUTOSAR services, MQTT or ZeroMQ may be used depending on the domain and criticality. For safety work, middleware must not be treated as a neutral transport layer. Queue depth, reliability policy, data freshness, timestamp semantics, discovery behaviour and clock synchronization can all affect safety. A control function that receives a delayed but valid-looking message may act on stale information, while a perception system may fail if sensor streams are synchronized incorrectly.

A good architecture therefore makes middleware assumptions explicit. It defines message contracts, rates, deadlines, ownership, allowed losses, fault behaviour and security properties. The same interfaces should support testing across model-in-the-loop, software-in-the-loop, hardware-in-the-loop and field environments so that evidence accumulates rather than fragments across tools.

An autonomy stack transforms raw environmental interaction into controlled action. Perception modules convert camera, LiDAR, radar, sonar, inertial and other data into objects, maps, free-space estimates and uncertainty representations. Localization estimates position and orientation relative to a map, route, waterway, airspace or celestial frame. Planning generates behaviour and trajectory options that satisfy mission goals while respecting constraints. Control executes selected actions through actuators and compensates for disturbances and modelling error.

This functional decomposition is simple to draw and difficult to verify. The layers exchange probabilistic information, operate at different rates and use different computational models. A perception algorithm may be dominated by AI inference and data quality. A localization module may combine deterministic filters with uncertain sensor inputs. A planner may be rule-based, optimization-based, search-based or learned. A controller may have a mathematical stability argument that is valid only under assumptions about actuator limits and input latency.

The stack also includes cross-cutting services. Diagnostics detect node failures, deadline misses and degraded sensor health. Degraded-mode management defines what the system does when full autonomy is no longer justified. Logging provides evidence for debugging, incident reconstruction and certification. Simulation support allows the same interfaces to be exercised before hardware is available. Update services distribute new code and configuration while preserving rollback and traceability.

A software stack is not merely a technical artefact. It also structures engineering work. Perception, planning, control, middleware, platform, simulation and DevOps teams often align with layers in the architecture. This division enables parallel development and reuse, but it also creates integration risk at interfaces. The architecture must therefore define responsibilities clearly enough that each team knows what evidence it must produce and what assumptions it depends on from other teams.

For the book's V-model framework, each architectural interface becomes a verification obligation. Message contracts are verified by integration tests, timing budgets by scheduling and latency analysis, middleware QoS by stress and fault-injection tests, and operational behaviour by scenario validation. Architectural clarity is therefore a prerequisite for V&V clarity.

Autonomous systems operate under real-time constraints. Perception must process data quickly enough for planning, planning must provide feasible trajectories before the world changes, and control must execute commands at stable rates. Real-time behaviour is not only a property of the operating system. It depends on the full path from sensor sampling and driver buffering through middleware queues, application scheduling, network transfer, actuator command and feedback.

Determinism is especially important for V&V. A system that passes a scenario once but fails under the same conditions because thread scheduling, message ordering or GPU load changed is difficult to certify. Deterministic design does not mean that every outcome is identical in a stochastic world; it means that the software platform provides predictable execution and bounded behaviour under specified conditions. This requires timing budgets, scheduling analysis, resource monitoring, priority discipline and careful treatment of shared accelerators.

Resilience requires more than restarting failed nodes. The architecture must decide what information is trusted after a partial failure, how redundant channels vote or cross-check each other, how stale data is detected, how degraded modes are entered and how the system returns to nominal operation. Interoperability must also be treated carefully. Standard interfaces reduce integration cost, but a standard message format does not guarantee common semantics, units, coordinate frames, timestamp meaning or safety assumptions.

From a V-model perspective, real-time and resilience requirements should be allocated to architecture early, verified through integration and stress testing, and validated through operational scenarios that include faults and degraded conditions. These properties cannot be added reliably at the end of development.