How the system is reconfigured
Six ROS2 framework modules, a configuration catalogue, and three independent real-time constraints. The architecture and its timing analysis are documented in Chapter 4 of the dissertation.
§ 4.2–4.7 · ARCHITECTURE
More than switching. A complete control loop.
The system is modelled across four abstraction levels: mission → function → service → resource. Six modules cover state assessment, decision making, safe switching, and stability supervision.
| Module | Role |
|---|---|
| HealthMonitor | Assesses physical resource health and diagnostic inputs. |
| DecisionEngine | Selects an admissible configuration for the current mission and state. |
| ReconfigManager | Manages transitions, Hot Standby and Rollback. |
| StabilityAnalyzer | Checks stability conditions of configurations and transitions. |
| ConfigStore | Stores the catalogue of available, verified configurations. |
| SafetySupervisor | Independently supervises safety and inadmissible operating modes. |
§ 4.10 · REAL-TIME ANALYSIS
What the timing analysis actually shows
Functional correctness does not guarantee a timely result. The dissertation evaluates task schedulability, response to a single fault, and the admissibility of repeated reconfigurations.
| Property | Result / requirement | Interpretation |
|---|---|---|
| Task schedulability | U = 0.396; bound 0.735 | The sufficient schedulability condition holds for the defined task set. |
| Task response | max R/D = 0.176 | All modelled tasks meet their deadlines. |
| DEGRADED reaction | 54.80 ms; required 50 ms | The present timing budget does not meet this requirement. |
| Hot Standby switch | 35 ms; must be ≤ 30.2 ms | Switching latency must be reduced; the requirement must not be relaxed. |
Three independent conditions: task deadlines; end-to-end fault response; and a lower bound on the interval between successive reconfigurations (Equation 4.106).
Source: D. O. Humennyi, dissertation, §§ 4.2–4.7, 4.10.3–4.10.6, Equations (4.98)–(4.106). These figures describe the specified analytical model, not an arbitrary hardware product.
Software reference, verification and hardware path
Related engineering material. Planned stages are distinguished from the results documented in the dissertation.
Four runtime questions.
Stage 2 starts only after the software model is verified against the mathematical specification.
Reference software: C++ core → ROS 2.
Plant, health, capability, decision, stability and reconfiguration logic remain independent of ROS 2.
Planned hardware path: RISC-V → SoC IP.
Capability, stability and transition supervision migrate from the software reference without changing their interfaces.
What must be demonstrated before the next stage?
The implementation must stay within defined error bounds relative to the mathematical golden model.