Differences
This shows you the differences between two versions of the page.
| en:safeav:softsys:midautsftarch [2026/06/17 14:14] – created karlisberkolds | en:safeav:softsys:midautsftarch [2026/06/17 14:58] (current) – karlisberkolds | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Middleware and autonomy software architecture ====== | ====== Middleware and autonomy software architecture ====== | ||
| + | |||
| + | ===== Layered architecture and middleware responsibilities ===== | ||
| + | |||
| + | 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, | ||
| + | |||
| + | 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, | ||
| + | |||
| + | 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, | ||
| + | |||
| + | ===== Autonomy stack and data flow ===== | ||
| + | |||
| + | 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, | ||
| + | |||
| + | 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. | ||
| + | |||
| + | <table Ref.Tab.2.2> | ||
| + | < | ||
| + | ^ Layer ^ Primary role ^ Typical V-model artefacts | ||
| + | | Hardware abstraction | Drivers, board support packages, sensor and actuator interfaces. | Interface specifications, | ||
| + | | Runtime and operating system | Scheduling, | ||
| + | | Middleware | Communication, | ||
| + | | Autonomy applications | Perception, | ||
| + | | Lifecycle infrastructure | Build, CI/CD, release, monitoring, update and rollback services. | Baselines, | ||
| + | |||
| + | </ | ||
| + | |||
| + | ===== Architecture as a technical and organisational blueprint ===== | ||
| + | |||
| + | 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. | ||
| + | |||
| + | {{: | ||
| + | |||
| + | ===== Real-time behaviour, resilience and interoperability ===== | ||
| + | |||
| + | 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, | ||
| + | |||
| + | |||
