Repository navigation
Feature Architecture Improvements #720
Description
What
Goal
Prepare for the Feature Architecture Inspection checklist, requested for Score 0.10 release
Identified Gaps
Static Architecture
- Static Architecture View is currently missing many dependencies to other modules (e.g. mw::com, baselibs flatbuffer, etc) and should be extended
- Add also link to baselibs OSAL interface, once PR is merged and changes released
- Extend configuration structure to depict configuration of RunTargets
Dynamic Architecture
Sequence Diagrams improvements
-
Extending the Launch Manager sequence diagrams #741:
- lcm_start diagram traces to start_named_run_target, but does not Show activating a named RunTarget.
- lcm_term diagram traces to launch_support, but does not including launching any processes
- lcm_term diagram traces to process_ordering, but the scenario shown does not include any ordering of processes.
- term_order diagram traces to launch_support, but the scenario shown does not including launching any processes.
- control_activate links to switch_run_target, but only shows the cold-start of a RunTarget - no processes are stopped.
-
Component State machine diagram should refer to Ready Conditions to reach a "Ready" state. Currently only depicts the case where application report a Running state.
-
Diagram feat_arc_dyn__lifecycle__alive_monitor currently shows dynamic supervision registration - although the monitoring starts at the time when Running state is reported. Recommendation: Change to current behaviour. Make dynamic registration a possible extension for the future.
-
Review sequence diagrams whether error paths are shown
General
There are 8 diagrams in the repo that are not included in the rendered documentation:
application_health_monitor_static.puml, control_interface_activate_sequence.puml, control_interface_static.puml, control_interface_stop_sequence.puml, control_interface_switch_sequence.puml, deadline_sup.puml, launch_manager_static.puml, overview_static.puml
-
Review diagrams and include into documentation or delete
-
Inconsistent behaviour: "If the same run target is already active, verify its state and potentially restart failed components". Any failed components would have already triggered a recovery action.
-
We have no formally documented design decisions currently. We can make the existing rationales for HealthMonitor into a dec_rec element.
-
Handle AoUs from dependent modules
-
Check if all main used OS functionality is depicted in the static view
-
Add description to logical operation elements
-
Cover in the design what is done to achieve certain resource/performance KPIs
Questions
- What about traces to requirements in state "invalid"? Should they be removed?
- Should the
ReportRunning APIbe added as a separate interface, include the operation in the current Lifecycle API element or treat as implementation detail? Currently, applications can choose to use the full Lifecycle API or the simplevoid report_running()function.- Discussion Result: yes, PR #3297
- Currently we have no requirements regarding Startup Time, resource consumption, etc.
Acceptance Criteria (DoD)
All findings resolved
How
No response
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsBacklog
Activity
NicolasFussberger commentedon Sep 30, 2026
#708