From ad299fee3fe15831910643b795761cb6a1523ab7 Mon Sep 17 00:00:00 2001 From: aschemmel-git Date: Mon, 27 Jul 2026 15:14:24 +0200 Subject: [PATCH] Move lifecycle documentation to module --- MODULE.bazel | 8 + MODULE.bazel.lock | 13 - .../_assets/alive_monitoring_dynamic.puml | 32 + .../application_health_monitor_static.puml | 23 + ...application_health_monitoring_dynamic.puml | 54 ++ .../_assets/config_params_static.puml | 76 ++ .../control_interface_activate_sequence.puml | 47 ++ .../control_interface_start_sequence.puml | 42 + .../_assets/control_interface_static.puml | 19 + .../control_interface_stop_sequence.puml | 37 + .../control_interface_switch_sequence.puml | 63 ++ .../architecture/_assets/deadline_sup.puml | 54 ++ .../_assets/external_monitoring_sequence.puml | 93 ++ .../_assets/external_monitoring_static.puml | 14 + .../_assets/launch_manager_static.puml | 21 + .../_assets/launch_manager_target_tree.puml | 41 + .../_assets/lifecycle_state_machine.puml | 8 + .../architecture/_assets/logical_sup.puml | 58 ++ .../architecture/_assets/overview_static.puml | 47 ++ .../architecture/external_monitoring.rst | 81 ++ .../lifecycle/architecture/health_monitor.rst | 175 ++++ .../features/lifecycle/architecture/index.rst | 130 ++- .../lifecycle/architecture/launch_manager.rst | 269 ++++++ .../launch_manager_configuration.rst | 72 ++ docs/features/lifecycle/glossary.rst | 124 +++ docs/features/lifecycle/index.rst | 9 +- .../docs/architecture/index.rst | 60 +- .../architecture/component_architecture.rst | 30 +- .../docs/requirements/requirements.rst | 796 +++++++++++++++++- 29 files changed, 2363 insertions(+), 133 deletions(-) create mode 100644 docs/features/lifecycle/architecture/_assets/alive_monitoring_dynamic.puml create mode 100644 docs/features/lifecycle/architecture/_assets/application_health_monitor_static.puml create mode 100644 docs/features/lifecycle/architecture/_assets/application_health_monitoring_dynamic.puml create mode 100644 docs/features/lifecycle/architecture/_assets/config_params_static.puml create mode 100644 docs/features/lifecycle/architecture/_assets/control_interface_activate_sequence.puml create mode 100644 docs/features/lifecycle/architecture/_assets/control_interface_start_sequence.puml create mode 100644 docs/features/lifecycle/architecture/_assets/control_interface_static.puml create mode 100644 docs/features/lifecycle/architecture/_assets/control_interface_stop_sequence.puml create mode 100644 docs/features/lifecycle/architecture/_assets/control_interface_switch_sequence.puml create mode 100644 docs/features/lifecycle/architecture/_assets/deadline_sup.puml create mode 100644 docs/features/lifecycle/architecture/_assets/external_monitoring_sequence.puml create mode 100644 docs/features/lifecycle/architecture/_assets/external_monitoring_static.puml create mode 100644 docs/features/lifecycle/architecture/_assets/launch_manager_static.puml create mode 100644 docs/features/lifecycle/architecture/_assets/launch_manager_target_tree.puml create mode 100644 docs/features/lifecycle/architecture/_assets/lifecycle_state_machine.puml create mode 100644 docs/features/lifecycle/architecture/_assets/logical_sup.puml create mode 100644 docs/features/lifecycle/architecture/_assets/overview_static.puml create mode 100644 docs/features/lifecycle/architecture/external_monitoring.rst create mode 100644 docs/features/lifecycle/architecture/health_monitor.rst create mode 100644 docs/features/lifecycle/architecture/launch_manager.rst create mode 100644 docs/features/lifecycle/architecture/launch_manager_configuration.rst create mode 100644 docs/features/lifecycle/glossary.rst diff --git a/MODULE.bazel b/MODULE.bazel index c99b3017a..ca86b2da6 100644 --- a/MODULE.bazel +++ b/MODULE.bazel @@ -41,6 +41,14 @@ bazel_dep(name = "score_cpp_policies", version = "0.0.1", dev_dependency = True) bazel_dep(name = "score_process", version = "2.0.2", dev_dependency = True) bazel_dep(name = "score_platform", version = "0.6.2", dev_dependency = True) +# Needed until a release of score_platform includes +# https://github.com/eclipse-score/score/pull/3068 (merged to main). +git_override( + module_name = "score_platform", + commit = "b7d9c2ad93440387a5288917144b8d92b97f10e4", + remote = "https://github.com/eclipse-score/score", +) + ## Configure the C++ toolchain bazel_dep(name = "score_bazel_cpp_toolchains", version = "0.5.4", dev_dependency = True) diff --git a/MODULE.bazel.lock b/MODULE.bazel.lock index ac390b1af..269393533 100644 --- a/MODULE.bazel.lock +++ b/MODULE.bazel.lock @@ -50,7 +50,6 @@ "https://bcr.bazel.build/modules/aspect_rules_js/2.3.8/source.json": "411ec9d79d6f5fe8a083359588c21d01a5b48d88a2cbd334a4c90365015b7836", "https://bcr.bazel.build/modules/aspect_rules_lint/0.12.0/MODULE.bazel": "e767c5dbfeb254ec03275a7701b5cfde2c4d2873676804bc7cb27ddff3728fed", "https://bcr.bazel.build/modules/aspect_rules_lint/1.0.3/MODULE.bazel": "ed0fe929647ba21d2041e14ea3d757133ca306b72d4998e8a3d0d2f515196765", - "https://bcr.bazel.build/modules/aspect_rules_lint/1.3.1/MODULE.bazel": "06ce330900a7d6403bc8d88e5dfad6aeeb8ae40179f66bb89e69c8bf6f6b1a0b", "https://bcr.bazel.build/modules/aspect_rules_lint/1.4.2/MODULE.bazel": "78d025facf6fa675fd6f0b62fd6a9a2bec7ef5ae1e288e5b53f4383b98017105", "https://bcr.bazel.build/modules/aspect_rules_lint/1.4.4/MODULE.bazel": "24459eeeeb084bc3e7628c338e494746718bc17b3a3cbd94415c8df5c7c6dc37", "https://bcr.bazel.build/modules/aspect_rules_lint/1.5.3/MODULE.bazel": "7fee71b11be63f1cf0458cd8c731712a0e672d0bb6df8879ed70249bf8dfdfdc", @@ -444,7 +443,6 @@ "https://bcr.bazel.build/modules/rules_rust/0.67.0/MODULE.bazel": "87c3816c4321352dcfd9e9e26b58e84efc5b21351ae3ef8fb5d0d57bde7237f5", "https://bcr.bazel.build/modules/rules_shell/0.2.0/MODULE.bazel": "fda8a652ab3c7d8fee214de05e7a9916d8b28082234e8d2c0094505c5268ed3c", "https://bcr.bazel.build/modules/rules_shell/0.3.0/MODULE.bazel": "de4402cd12f4cc8fda2354fce179fdb068c0b9ca1ec2d2b17b3e21b24c1a937b", - "https://bcr.bazel.build/modules/rules_shell/0.4.0/MODULE.bazel": "0f8f11bb3cd11755f0b48c1de0bbcf62b4b34421023aa41a2fc74ef68d9584f0", "https://bcr.bazel.build/modules/rules_shell/0.4.1/MODULE.bazel": "00e501db01bbf4e3e1dd1595959092c2fadf2087b2852d3f553b5370f5633592", "https://bcr.bazel.build/modules/rules_shell/0.5.0/MODULE.bazel": "8c8447370594d45539f66858b602b0bb2cb2d3401a4ebb9ad25830c59c0f366d", "https://bcr.bazel.build/modules/rules_shell/0.6.1/MODULE.bazel": "72e76b0eea4e81611ef5452aa82b3da34caca0c8b7b5c0c9584338aa93bae26b", @@ -534,7 +532,6 @@ "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/aspect_rules_js/2.3.8/MODULE.bazel": "not found", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/aspect_rules_lint/0.12.0/MODULE.bazel": "not found", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/aspect_rules_lint/1.0.3/MODULE.bazel": "not found", - "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/aspect_rules_lint/1.3.1/MODULE.bazel": "not found", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/aspect_rules_lint/1.4.2/MODULE.bazel": "not found", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/aspect_rules_lint/1.4.4/MODULE.bazel": "not found", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/aspect_rules_lint/1.5.3/MODULE.bazel": "not found", @@ -847,7 +844,6 @@ "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/rules_rust/0.68.2-score/source.json": "f88ad98dd08f296a546677e86ad42b20f61851e41a9fd3e0449971162fcaf784", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/rules_shell/0.2.0/MODULE.bazel": "not found", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/rules_shell/0.3.0/MODULE.bazel": "not found", - "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/rules_shell/0.4.0/MODULE.bazel": "not found", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/rules_shell/0.4.1/MODULE.bazel": "not found", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/rules_shell/0.5.0/MODULE.bazel": "not found", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/rules_shell/0.6.1/MODULE.bazel": "not found", @@ -872,8 +868,6 @@ "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_devcontainer/1.7.0/MODULE.bazel": "f9a5971fbd05f0ed14e7a373dbf58af72a5c58d081537a75c314daaf61c92ae9", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_devcontainer/1.8.0/MODULE.bazel": "89f855b94d041d2e61ff9667562fb4539c146249f6fb4c5dddf3d13bb9064aa7", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_devcontainer/1.8.0/source.json": "ef316fad71fdbd53daf43fc0a82fbc7c293908a2712214ff79134c177d028024", - "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_docs_as_code/0.2.4/MODULE.bazel": "ea4801e96c87e2b8650a0fa9e5fed9b8bdbef05c1bc3e30003ba527d5af60a43", - "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_docs_as_code/0.2.6/MODULE.bazel": "1af2963e91c6472555e222f0aba3dc2f5492d04598298209a361978ee3e321e3", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_docs_as_code/0.3.3/MODULE.bazel": "95d2b7d44d461c1cf9bd016605f740716fd4ea1303f5f2ed93de3566b90feb1b", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_docs_as_code/1.0.0-RC1/MODULE.bazel": "e118b5cbdc453cde83b5ce481107d8e4a713d3458550b9d10445046d4bba2ff3", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_docs_as_code/1.0.0/MODULE.bazel": "a3ad204b7412c02a899034d78de62b5549bafba5530a256d1007cb3f4ed20a11", @@ -889,10 +883,6 @@ "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_format_checker/0.1.1/MODULE.bazel": "1acc254faa90e9f97b79ac69af25b6c21c561f8d6079914f6352b9b20d26bd37", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_itf/0.5.0/MODULE.bazel": "d3ae40173462419b4e14e3fea96a49eab8822be7292f94890beb8cc73173eaa1", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_itf/0.5.0/source.json": "3c0fcd761e221bc33e6ebbeb0f92ce71b5d6f1f946b60ccf4fe7cf3a4c00d211", - "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_platform/0.1.0/MODULE.bazel": "cc9eae86e76f2a930510ed6e50ec991bb5661687e24881685b39c322087adf6f", - "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_platform/0.1.1/MODULE.bazel": "eb086ba99f9319371fbbd0a9252dfd27b0817039b88bd4d691602974b1ada005", - "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_platform/0.6.2/MODULE.bazel": "e88e7d086a08e1b451a68b60038b8b1f3c028aae7efc0bc9d8b39b6261ba040d", - "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_platform/0.6.2/source.json": "87edd5be1382fec29c3276a7df3034d918f1d047e4814981d2ca725906460629", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_process/1.0.4/MODULE.bazel": "f74302cb90a7c4878db302276afae82966878099861dcfca3ef43256131dab52", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_process/1.0.5/MODULE.bazel": "ed17c232ebd65e9d50fd5c1832f90f95ffe95b2a1113d63a176295a2af64d111", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_process/1.1.0/MODULE.bazel": "97dd927309f87ecb73629725683028a5dbb37a49b1159c771292e6993569055b", @@ -905,8 +895,6 @@ "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_process/2.0.1/MODULE.bazel": "88bff0ed46da79d87f8c441a6bf6b760ee7c194b282e7e54a8b7db6ea2354db9", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_process/2.0.2/MODULE.bazel": "6d2b227bb6880e9f6871cc8cf94c83399e35c188424f7e9b826262de8149ed43", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_process/2.0.2/source.json": "5ae55f0dabcddeb5bfae16ce480e2c065f907d2b0ed6a8e4ed7409b259b004ee", - "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_python_basics/0.3.0/MODULE.bazel": "785ddd5295213e36c31ab86bdc34f29c0f7d1b72e9abd931bb08f42c0e48e2e9", - "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_python_basics/0.3.1/MODULE.bazel": "99c491109937542e61df090222666a8613ef946fa7bb2b2d5ba648b2baba03ad", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_python_basics/0.3.2/MODULE.bazel": "f25490f64035a0e3a0d53ad9cb6164e8325ce6cf2a7ee68c6ae153840cb2497e", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_python_basics/0.3.4/MODULE.bazel": "53bd16dfbb1fb8ecf6822fb26f9f4e8333bac7b14d12bb02bf84078063820a31", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_qnx_unit_tests/0.2.0/MODULE.bazel": "aaffff67916dd058737aac8e04368f12b214e7646ff58adbab48e6429d1a5410", @@ -916,7 +904,6 @@ "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_rust_policies/0.0.2/MODULE.bazel": "ade2bad4a331b02d9b7e7d9842e8de8c6fded6186486e02c4f7db5cd4b71d34d", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_rust_policies/0.0.5/MODULE.bazel": "7de02547bdf121d3dedf5141b97f0fd9a545bd255ff5c7b699056b35816ffad9", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_rust_policies/0.0.5/source.json": "22c8bf0a5cbf7c7b06f774f3f66498e0bc14346a8b2208f7427a8fbb78a42547", - "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_starpls_lsp/0.1.0/MODULE.bazel": "b2f8c4c8d8e851706255ff9002b448bff6e040b8f0c6adedbde2a09375aa16cc", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_toolchains_rust/0.9.1/MODULE.bazel": "40cab3f733d11fa7ebfa00667148c8da7c4c4168f0010cc8fff90d577f4f28f9", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_toolchains_rust/0.9.1/source.json": "af8b25d7a21b2f60678f31fef4ad767c6e0ad8935386d51e0e3180bf5989e8d9", "https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/modules/score_tooling/1.0.2/MODULE.bazel": "e70f396375b9d612b4f41ebceff7f18f68ab423b14625c138a354cc01bc62a10", diff --git a/docs/features/lifecycle/architecture/_assets/alive_monitoring_dynamic.puml b/docs/features/lifecycle/architecture/_assets/alive_monitoring_dynamic.puml new file mode 100644 index 000000000..9a208b091 --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/alive_monitoring_dynamic.puml @@ -0,0 +1,32 @@ +@startuml +title Alive Monitoring + +autonumber "[000]" + +participant "Launch Manager" as LM +participant "Application" as App + +activate LM + +LM --> LM: parse configuration +LM --> App: fork +activate App + +App -> LM: Register for alive notifications (callback) +LM --> App: Return value + +note over LM, App: Cyclicly report health state +loop health_status == ok + App --> LM : report_healt_status() +end + +note over LM, App: Trigger Error Reaction +alt health_status != ok + LM --> App: initiate Error Reaction +end + +App -> LM: Return value +deactivate App + +deactivate LM +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/application_health_monitor_static.puml b/docs/features/lifecycle/architecture/_assets/application_health_monitor_static.puml new file mode 100644 index 000000000..bc565f6b3 --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/application_health_monitor_static.puml @@ -0,0 +1,23 @@ +@startuml +title Component Architecture Diagram + +package "<> Launch Manager" { + [Launch Manager] as LM + interface AliveMonitoring + + LM --|> AliveMonitoring : offers +} + +package "<> Monitored Application (MA)" { + [Application logic] as MA + [Health Monitor (HM)] as HM + + interface HealthMonitorAPI + + HM --|> HealthMonitorAPI : implements + HM --> AliveMonitoring : connects to + MA --> HealthMonitorAPI : uses +} + + +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/application_health_monitoring_dynamic.puml b/docs/features/lifecycle/architecture/_assets/application_health_monitoring_dynamic.puml new file mode 100644 index 000000000..43bf771bd --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/application_health_monitoring_dynamic.puml @@ -0,0 +1,54 @@ +@startuml +autonumber "[000]" + +participant "Launch Manager" as LM + + +box "Monitored Application" + participant "Application Logic" as App + participant "HealthMonitor" as HM +end box + +LM -> LM: Parse monitoring rules\nof the monitored app +LM -> LM: Start startup grace period timer + +LM -> App : Start component + +activate App +App -> HM: Register health monitoring\n(Alive/Deadline/Logical) +activate HM +HM -> HM: sleep until the next wakeup time +App -> HM: Checkpoint +HM -> HM: Wakeup and check if the\ncheckpoints have been called +HM -> LM: Alive notification + +hnote across: Use Case: Missed checkpoint + +App --x HM: Missed Checkpoint +HM -> HM: Wakeup and check if the\ncheckpoints have been called + +HM -> LM: Supervision failure notification + +HM -X LM: Stop triggering alive +LM -> LM: Error reaction\n(notify State manager) + +hnote across: Use Case: Direct error report by the Application + +App -> HM: Report error +HM -> LM: Supervision failure notification + +HM -X LM: Stop triggering alive +LM -> LM: Error reaction\n(notify State manager) + +hnote across: Use Case: Crashed Application + +App -> App: application error, crash +destroy App +destroy HM + +LM -> LM: Wakeup and check if the\ncheckpoints have been called +LM -> LM: No alive notification seen +LM -> LM: Error reaction\n(notify State manager) + + +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/config_params_static.puml b/docs/features/lifecycle/architecture/_assets/config_params_static.puml new file mode 100644 index 000000000..4f05b9d13 --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/config_params_static.puml @@ -0,0 +1,76 @@ +@startuml + +class LaunchManager +{ + +} + +class LaunchConfiguration +{ + +} + +LaunchManager "1" -- "1" LaunchConfiguration + + +class ConfigFile +{ + +} + +LaunchConfiguration "1" -- "1..*" ConfigFile + + + +class ComponentConfig { + +} + +ConfigFile "1" -- "1..*" ComponentConfig + +class AliveMonitoring { + + alive notification interval + + Startup grace period + + failure tolerance limit +} + + +class RecoveryAction { + + recovery action type (eg. restart, stop, ignore, DSS) + + retry count (how many times to try) + + wait time (before the component can be started again) +} + + +class Dependency { + + depency type +} + +class SandboxConfig { ++ UID ++ GID ++ supplementary groups ++ runmask ++ priority ++ ability ++ security ++ cwd ++ environmental variables ++ command ++ arguments ++ stdin ++ stdout ++ stderr ++ aslr ++ rlimits ++ time between sigterm and sigkill +} + +ComponentConfig "1" -- "1" Dependency +ComponentConfig "1" -- "1" ProcessConfig +ComponentConfig "1" -- "1" AliveMonitoring +ComponentConfig "1" -- "1" RecoveryAction + +Dependency "1" --> "0..*" ComponentConfig: (reference to another component) + +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/control_interface_activate_sequence.puml b/docs/features/lifecycle/architecture/_assets/control_interface_activate_sequence.puml new file mode 100644 index 000000000..f2330127d --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/control_interface_activate_sequence.puml @@ -0,0 +1,47 @@ +@startuml +title Control Interface - Activate Run Target + +autonumber "[00]" + +participant "Tester" as Tester +participant "State Manager" as SM +participant "Launch Manager" as LM +participant "OS (kernel)" as kernel +participant "DemoApp1" as DemoApp1 +participant "DemoApp2" as DemoApp2 +participant "NetworkApp" as NetworkApp + +note over SM, LM: Current Run Target: "BasicApps" (DemoApp1 running) +note over SM, LM: Requested Run Target: "DemoGroup" (DemoApp1, DemoApp2) + +Tester -> SM: Activate Run Target "DemoGroup" +SM -> SM: evaluate request +SM -> LM: activate_run_target("DemoGroup") +activate LM + +LM -> LM: analyze current state +note right of LM: Current: BasicApps (DemoApp1)\nTarget: DemoGroup (DemoApp1, DemoApp2)\nAction: Start DemoApp2, keep DemoApp1 + +LM -> LM: validate run target "DemoGroup" +LM -> LM: check dependencies for DemoGroup +LM -> LM: determine transition plan + +alt DemoApp2 needs to be started + LM -> kernel: spawn DemoApp2 + kernel -> DemoApp2: spawn + activate DemoApp2 + kernel --> LM: result of spawning DemoApp2 + + LM -> LM: wait for DemoApp2 ready condition + DemoApp2 -> DemoApp2: initialize and register device /dev/Demo2 + DemoApp2 -> LM: signal ready state via Lifecycle API + kernel --> LM: event /dev/Demo2 registered +end + +LM -> LM: verify all components in "DemoGroup" are running +LM -> LM: update current run target state to "DemoGroup" +LM --> SM: run target "DemoGroup" activated successfully + +note over SM, LM: New Run Target: "DemoGroup" (DemoApp1, DemoApp2 running) + +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/control_interface_start_sequence.puml b/docs/features/lifecycle/architecture/_assets/control_interface_start_sequence.puml new file mode 100644 index 000000000..7f9f5d964 --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/control_interface_start_sequence.puml @@ -0,0 +1,42 @@ +@startuml +title Control Interface - Activate Run Target (Legacy) + +autonumber "[00]" + +participant "Tester" as Tester +participant "State Manager" as SM +participant "Launch Manager" as LM +participant "OS (kernel)" as kernel +participant "DemoApp1" as DemoApp1 +participant "DemoApp2" as DemoApp2 + +note over SM, LM: Activating Run Target "DemoTarget" + +Tester -> SM: Activate Run Target "DemoTarget" +SM -> SM: evaluate request +SM -> LM: activate_run_target("DemoTarget") +activate LM + +LM -> LM: validate run target exists +LM -> LM: analyze current vs target state +LM -> LM: determine components to start + +LM -> kernel: spawn DemoApp1 +kernel -> DemoApp1: spawn +activate DemoApp1 +kernel --> LM: result of spawning DemoApp1 + +LM -> kernel: spawn DemoApp2 +kernel -> DemoApp2: spawn +activate DemoApp2 +kernel --> LM: result of spawning DemoApp2 + +LM -> LM: wait for run target ready conditions +DemoApp2 -> DemoApp2: register device /dev/Demo2 +DemoApp2 -> LM: signal ready via Lifecycle API +kernel --> LM: event /dev/Demo2 registered + +LM -> LM: verify run target "DemoTarget" fully active +LM --> SM: run target "DemoTarget" activated + +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/control_interface_static.puml b/docs/features/lifecycle/architecture/_assets/control_interface_static.puml new file mode 100644 index 000000000..74c2a35e9 --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/control_interface_static.puml @@ -0,0 +1,19 @@ +@startuml +title Control Interface Static Architecture + +package "Launch Manager" { + [Launch Manager (LM)] as LM + interface ControlInterface + + LM -- ControlInterface : implements +} + +package "State Manager" { + [State Manager] as SM +} + +SM -up-> ControlInterface : uses + +note right of [ControlInterface] : Start/Stop/Restart components\nQuery status\n... + +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/control_interface_stop_sequence.puml b/docs/features/lifecycle/architecture/_assets/control_interface_stop_sequence.puml new file mode 100644 index 000000000..e4a23df1b --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/control_interface_stop_sequence.puml @@ -0,0 +1,37 @@ +@startuml +title Control Interface - Stop components + +autonumber "[00]" + + +participant "Tester" as Tester +participant "State Manager" as SM +participant "Launch Manager" as LM +participant "OS (kernel)" as kernel +participant "DemoApp1" as DemoApp1 +participant "DemoApp2" as DemoApp2 + + + +Tester -> SM: Stop Group (eg. UDS) +SM -> SM: evaluate request +SM -> LM: Stop group DemoApps +activate LM +LM -> DemoApp1: SIGTERM +activate DemoApp1 +LM -> DemoApp2: SIGTERM +activate DemoApp2 + +DemoApp1 -> DemoApp1: do shutdown actions +DemoApp2 -> DemoApp2: do shutdown actions + +destroy DemoApp1 + +LM -> LM: check if the apps terminated within\nthe termination timeout? +LM -> DemoApp2: SIGKILL +destroy DemoApp2 + + +LM --> SM: DemoApps terminated + +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/control_interface_switch_sequence.puml b/docs/features/lifecycle/architecture/_assets/control_interface_switch_sequence.puml new file mode 100644 index 000000000..f12b6717d --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/control_interface_switch_sequence.puml @@ -0,0 +1,63 @@ +@startuml +title Control Interface - Switch Run Target Scenario + +autonumber "[00]" + +participant "Tester" as Tester +participant "State Manager" as SM +participant "Launch Manager" as LM +participant "OS (kernel)" as kernel +participant "DemoApp1" as DemoApp1 +participant "DemoApp2" as DemoApp2 +participant "NetworkApp" as NetworkApp + +note over SM, LM: Current Run Target: "NetworkGroup" (NetworkApp running) +note over SM, LM: Requested Run Target: "DemoGroup" (DemoApp1, DemoApp2) + +Tester -> SM: Activate Run Target "DemoGroup" +SM -> SM: evaluate request +SM -> LM: activate_run_target("DemoGroup") +activate LM + +LM -> LM: analyze transition from "NetworkGroup" to "DemoGroup" +note right of LM: Current: NetworkGroup (NetworkApp)\nTarget: DemoGroup (DemoApp1, DemoApp2)\nAction: Stop NetworkApp, Start DemoApp1 & DemoApp2 + +LM -> LM: validate target run target "DemoGroup" +LM -> LM: check dependencies and resource conflicts +LM -> LM: create transition plan + +== Stop Current Run Target Components == +LM -> NetworkApp: send SIGTERM +NetworkApp -> NetworkApp: cleanup and shutdown +NetworkApp --> LM: shutdown complete via Lifecycle API +LM -> kernel: wait for NetworkApp termination +kernel --> LM: NetworkApp terminated + +== Start Target Run Target Components == +alt Start DemoApp1 + LM -> kernel: spawn DemoApp1 + kernel -> DemoApp1: spawn + activate DemoApp1 + kernel --> LM: spawn result for DemoApp1 + DemoApp1 -> LM: signal started via Lifecycle API +end + +alt Start DemoApp2 (depends on DemoApp1) + LM -> LM: wait for DemoApp1 ready condition + LM -> kernel: spawn DemoApp2 + kernel -> DemoApp2: spawn + activate DemoApp2 + kernel --> LM: spawn result for DemoApp2 + + DemoApp2 -> DemoApp2: initialize and register device /dev/Demo2 + DemoApp2 -> LM: signal ready via Lifecycle API + kernel --> LM: device /dev/Demo2 registered +end + +LM -> LM: verify all "DemoGroup" components are running +LM -> LM: update current run target to "DemoGroup" +LM --> SM: run target "DemoGroup" activated successfully + +note over SM, LM: New Run Target: "DemoGroup" (DemoApp1, DemoApp2 running) + +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/deadline_sup.puml b/docs/features/lifecycle/architecture/_assets/deadline_sup.puml new file mode 100644 index 000000000..4525acf80 --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/deadline_sup.puml @@ -0,0 +1,54 @@ +@startuml +actor "Client" as Client +participant "TimeConstraintMonitor" as TCM +participant "ConditionLink" as CL + +== Setup Phase == +Client -> TCM: configure_minimum_time(min_time) +activate TCM +TCM -> TCM: store min_time +deactivate TCM + +Client -> TCM: configure_maximum_time(max_time) +activate TCM +TCM -> TCM: store max_time +deactivate TCM + +Client -> TCM: link_condition(condition) +activate TCM +TCM -> CL: save reference to condition +deactivate TCM + +== Monitoring Phase == +Client -> TCM: mark_start() +activate TCM +TCM -> TCM: start internal_timer +deactivate TCM + +Client -> TCM: mark_end() +activate TCM +TCM -> TCM: stop internal_timer +deactivate TCM + +TCM -> TCM: on_timer_expiry() +activate TCM +alt Within allowed window + TCM -> TCM: set status to Success + TCM -> TCM: inform_linked_conditions() +else Outside allowed window + TCM -> TCM: set status to Failure + TCM -> TCM: inform_linked_conditions() +end +deactivate TCM + +Client -> TCM: enable_monitoring() +activate TCM +TCM -> TCM: set active +deactivate TCM + +Client -> TCM: disable_monitoring() +activate TCM +TCM -> TCM: set inactive +deactivate TCM + +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/external_monitoring_sequence.puml b/docs/features/lifecycle/architecture/_assets/external_monitoring_sequence.puml new file mode 100644 index 000000000..515a5f484 --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/external_monitoring_sequence.puml @@ -0,0 +1,93 @@ +@startuml +title External Monitoring + +autonumber "[000]" + +participant "External Watchdog" as EWD +participant "Watchdog Proxy" as WDP +participant "Launch Manager" as LM + +activate LM + +LM --> LM: parse configuration +deactivate LM + +activate WDP + +alt "Proxy registers to Launch Manager" +WDP -> LM: Register for alive notifications (callback) +activate LM +LM --> WDP: Return value +else "Launch manager opens the watchdog device itself" +LM -> WDP: open watchdog device (eg. /dev/watchdog) +WDP -> LM: Return value +end +deactivate WDP + + + +note right of WDP: IPC (POSIX or OS-specific event) +activate WDP +activate LM +LM --> LM: internal health check +alt "Health OK" +LM --> WDP: alive notification (callback) +activate WDP +end +deactivate LM + + +note right of EWD: ECU specific notification.\nGPIO, UART, SPI, etc. + +WDP --> EWD: notify external watchdog +deactivate WDP +activate EWD +EWD --> EWD: Check if the notification fits the alive window\nreset the timeout timer +deactivate EWD +note right of LM: Wait until the next scheduled notification time + + +activate LM +LM --> LM: internal health check +alt "Health OK" +activate WDP +LM --> WDP: alive notification (callback) +end +deactivate LM + +activate WDP +WDP --> EWD: notify external watchdog +deactivate WDP +activate EWD +EWD --> EWD: Check if the notification fits the alive window\nreset the timeout timer +deactivate EWD + +note right of LM: Wait until the next scheduled notification time + +activate LM +LM --> LM: internal health check +alt "Health OK" +activate WDP +LM --> WDP: alive notification (callback) +end +deactivate LM + + +activate WDP +WDP --> EWD: notify external watchdog +deactivate WDP +activate EWD +EWD --> EWD: Check if the notification fits the alive window\nreset the timeout timer +deactivate EWD + +note right of LM: Wait until the next scheduled notification time +activate LM +LM --> LM: internal health check +note right of LM: status failed, don't trigger + +activate EWD +EWD --> EWD: Check if the notification fits the alive window\nreset the timeout timer +deactivate EWD +note right of EWD: alive notification missed\nTrigger error reaction + +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/external_monitoring_static.puml b/docs/features/lifecycle/architecture/_assets/external_monitoring_static.puml new file mode 100644 index 000000000..1db241544 --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/external_monitoring_static.puml @@ -0,0 +1,14 @@ +@startuml + + +package "Monitored controller" { + [Watchdog Proxy] - Ext_IPC + HealthStatus -[Watchdog Proxy] + [Launch Manager] - HealthStatus +} + +package "External monitor" { + Ext_IPC - [Watchdog] : UART\nGPIO\netc. +} + +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/launch_manager_static.puml b/docs/features/lifecycle/architecture/_assets/launch_manager_static.puml new file mode 100644 index 000000000..9dc9164e3 --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/launch_manager_static.puml @@ -0,0 +1,21 @@ +@startuml +title Launch Manager Static Architecture + +package "Launch Manager" { + [Launch Manager] as LM + interface AliveMonitoring + interface ConfigurationFiles + interface HealthStatus + interface CommandLineArguments + interface Logging + + + LM --> AliveMonitoring : provides + LM --> ConfigurationFiles : requires + LM --> CommandLineArguments : requires + LM --> HealthStatus: offers + LM --> Logging: requires +} + + +@enduml \ No newline at end of file diff --git a/docs/features/lifecycle/architecture/_assets/launch_manager_target_tree.puml b/docs/features/lifecycle/architecture/_assets/launch_manager_target_tree.puml new file mode 100644 index 000000000..6a875eefb --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/launch_manager_target_tree.puml @@ -0,0 +1,41 @@ +@startuml + title Dependency based lifecycle management + + state debug #lightblue + state running #lightblue + state ready_for_shutdown #lightblue + + state app1: /opt/bin/app1 + state app2: /opt/bin/app2 + state app3: /opt/bin/app3 + + state ssh: /usr/bin/ssh + state setup_filesystems: /etc/setup_filesystems.sh + state eth_driver: /bin/net-dev-eth + state filesystem: /bin/net-dev-ufs + state flash_driver: /bin/dev-emmc + + [*] --> debug + [*] -[hidden]-> running + [*] -[hidden]-> ready_for_shutdown + + + running --> app1 + app1 --> app2 + app2 --> networking + running --> app3 + app3 --> networking + + debug --> ssh + ssh --> networking + networking --> setup_filesystems + setup_filesystems --> filesystem + networking --> eth_driver + filesystem --> flash_driver + + legend right + |Color| Type | + |<#lightblue>| Run States provided by the ControlInterface| + |<#WhiteSmoke>| Components | + endlegend +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/lifecycle_state_machine.puml b/docs/features/lifecycle/architecture/_assets/lifecycle_state_machine.puml new file mode 100644 index 000000000..e34fc6ffc --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/lifecycle_state_machine.puml @@ -0,0 +1,8 @@ +@startuml +[*] --> Created : set-up Sandbox +Created --> Terminated +Terminated --> Init : fork()/exec() +Init --> Run : report run +Run --> Terminated : exit/SIGTERM/SIGKILL +Terminated --> [*] +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/logical_sup.puml b/docs/features/lifecycle/architecture/_assets/logical_sup.puml new file mode 100644 index 000000000..36f2e393e --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/logical_sup.puml @@ -0,0 +1,58 @@ +@startuml +autonumber "[000]" +actor "Client" as Client +participant "LogicalFlowSupervisor" as LFS +participant "Transition" as T +participant "Condition" as C + +== Initialization Phase == +Client -> LFS: add_entry_point(checkpoint_id) +activate LFS +LFS -> LFS: Add checkpoint_id to entry_points +deactivate LFS + +Client -> LFS: add_exit_point(checkpoint_id) +activate LFS +LFS -> LFS: Add checkpoint_id to exit_points +deactivate LFS + +Client -> LFS: add_allowed_transition(transition) +activate LFS +LFS -> T: get_source() +LFS -> T: get_target() +LFS -> LFS: Add edge to allowed_transitions (source -> target) +deactivate LFS + +Client -> LFS: link_condition(condition) +activate LFS +LFS -> C: Store reference to condition +LFS -> LFS: Add to linked_conditions +deactivate LFS + +== Supervision (Runtime) Phase == +Client -> LFS: record_checkpoint(checkpoint_id) +activate LFS +LFS -> LFS: Check if transition is allowed +alt Allowed transition + LFS -> LFS: Update last_checkpoint + LFS -> LFS: Update state + LFS -> LFS: Notify linked conditions +else Invalid transition + LFS -> LFS: Set status to Failure + LFS -> LFS: Notify linked conditions +end +deactivate LFS + +Client -> LFS: enable() +activate LFS +LFS -> LFS: Set enabled state +LFS -> LFS: Prepare for supervision +deactivate LFS + +Client -> LFS: disable() +activate LFS +LFS -> LFS: Set disabled state +LFS -> LFS: Cleanup +deactivate LFS + +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/overview_static.puml b/docs/features/lifecycle/architecture/_assets/overview_static.puml new file mode 100644 index 000000000..c6db8dc2f --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/overview_static.puml @@ -0,0 +1,47 @@ +@startuml +title Launch Manager Static Architecture + + +package "<> Launch Manager" { + [Launch Manager] as LM #A9DCDF + interface AliveMonitoring + interface ConfigurationFiles + interface HealthStatus + interface CommandLineArguments + interface Logging + interface ControlInterface + + + LM --> AliveMonitoring : provides + LM --> ConfigurationFiles : requires + LM --> CommandLineArguments : requires + LM --> HealthStatus: provides + LM --> ControlInterface: provides + LM --> Logging: requires +} + +package "<> Monitored Application (MA)" { + [Application logic] as MA + [Health Monitor (HM)] as HM #A9DCDF + + interface HealthMonitorAPI + + HM --|> HealthMonitorAPI : implements + MA --> HealthMonitorAPI : uses +} +HM -up-> AliveMonitoring : connects to + +package "<> State Manager" { + [State Manager] as SM +} + +SM -up-> ControlInterface : uses + +note left of [SM] : Start/Stop/Restart components\nQuery status\n... + +legend right + |Color| Type | + |<#A9DCDF>| Part of feature| +endlegend + +@enduml diff --git a/docs/features/lifecycle/architecture/external_monitoring.rst b/docs/features/lifecycle/architecture/external_monitoring.rst new file mode 100644 index 000000000..d8b696233 --- /dev/null +++ b/docs/features/lifecycle/architecture/external_monitoring.rst @@ -0,0 +1,81 @@ +.. + # ******************************************************************************* + # Copyright (c) 2024 Contributors to the Eclipse Foundation + # + # See the NOTICE file(s) distributed with this work for additional + # information regarding copyright ownership. + # + # This program and the accompanying materials are made available under the + # terms of the Apache License Version 2.0 which is available at + # https://www.apache.org/licenses/LICENSE-2.0 + # + # SPDX-License-Identifier: Apache-2.0 + # ******************************************************************************* + +External Monitoring +################### + + +.. uml:: _assets/external_monitoring_static.puml + :alt: External monitoring static Architecture + +The following participants are related to the concept. + +Launch Manager +-------------- + +As the :term:`Launch Manager` is critical component for the system, it shall support alive monitoring of itself. This means it must implement internal health management, such as +a worker thread, that wakes up every N milliseconds, checks if the component is in a consistent state, and send a notification to the external monitor. + +External monitor +---------------- + +The aliveness of the :term:`Launch Manager` shall be monitored by an `external monitor, or a watchdog `_, to be able to detect "hanging" of the +`Launch Manager`. The implementation of the external watchdog is out of scope in S-SCORE, as it is ECU and/or project specific. + +Watchdog Proxy +-------------- + +The component `Watchdog Proxy` is the project specific logical component, which has to implement the logical interface `HealthStatus` and translate alive events from the :term:`Launch Manager` as +project specific messages to the `External monitor`. The channel for sending these notifications is project specific, and can be for example `GPIO`, `UART` or `SPI`. +In a hypervisor based environment, the `external monitor` could also run with the same SoC as software only solution. + +The `Watchdog Proxy` implementation is not specified in the S-CORE with high details, as the realization depends heavily on OS, :term:`Launch Manager` or even project specific needs. +For example, in Linux and `systemd` as the :term:`Launch Manager`, the interface can be `/dev/watchdog`, and `systemd` can use the interface directly. + +In QNX, one could implement a component listening to the events (or even poll) from the :term:`Launch Manager` and translate these events as hardware specific notifications. + +Requirements related to the external monitoring +=============================================== + +- :need:`feat_req__lifecycle__lm_self_health_check` + + +Dynamic Architecture +==================== + +.. uml:: _assets/external_monitoring_sequence.puml + :alt: External monitoring static arch + +The most important interactions are the following: + +.. list-table:: Sequence diagram Description + :widths: 10 90 + :header-rows: 1 + + * - Sequence number + - Description + * - 001 + - The configuration. (notification interval, startup grace period, etc.) Additionally, if a watchdog interface is used, the used interface name (eg. /dev/watchdog) must be configurable. + * - 002 + - If the :term:`Launch Manager` provides a client library implementation, the library must connect and attach to the :term:`Launch Manager` + * - 006 + - Check the internal status and trigger alive notification (007) + * - 007 + - Send the alive notification to the external monitor. (UART/SPI/GPIO/etc.) + * - 009 + - Watchdog to check if the notification fits the expected window + * - 018 + - If the status check fails, do not trigger alive notification (or :term:`Launch Manager` has crashed) + * - 019 + - If there is no alive notification, trigger watchdog error reaction diff --git a/docs/features/lifecycle/architecture/health_monitor.rst b/docs/features/lifecycle/architecture/health_monitor.rst new file mode 100644 index 000000000..d335dd737 --- /dev/null +++ b/docs/features/lifecycle/architecture/health_monitor.rst @@ -0,0 +1,175 @@ +.. + # ******************************************************************************* + # Copyright (c) 2024 Contributors to the Eclipse Foundation + # + # See the NOTICE file(s) distributed with this work for additional + # information regarding copyright ownership. + # + # This program and the accompanying materials are made available under the + # terms of the Apache License Version 2.0 which is available at + # https://www.apache.org/licenses/LICENSE-2.0 + # + # SPDX-License-Identifier: Apache-2.0 + # ******************************************************************************* + +Health Monitor +############## + +The :term:`Health Monitor` is a library, that together with the :term:`Launch Manager` provide a way to monitor +the application health in similar fashion as the AUTOSAR `Platform Health Manager` (PHM). + +The main features of the :term:`Health Monitor` are the following monitoring functions: + +- Checkpoint supervision + - Periodic monitoring of checkpoints, which must fit the pre-configured expected number of notifications in the given interval (not too many, not too few) + - Protecting from running checks too often or too rarely +- Deadline supervision + - Timing requirement between two checkpoints. +- Logical + - Specifies in which order two or more checkpoints must be called + +The :term:`Health Monitor` itself is monitored via the :term:`Launch Manager` with via alive supervision only. + + +Overview +======== + +- Inter process communication (IPC) only needed for the alive monitoring between :term:`Health Monitor` and :term:`Launch Manager` +- Easier configuration + - The monitoring rules can be configured dynamically on demand basis + - The monitoring can be started and stopped dynamically +- Debugging of problems possibly easier + - Mapping of the events from a single process vs. the monitored application and the monitor + +Drawbacks over classical external process monitoring +---------------------------------------------------- + +- Harder safety argumentation. The following chapter describes the issues and the possible solutions. + +Safety +------ + +As the :term:`Health Monitor` is linked as part of the monitored application, it raises the following concerns +with respect to safety: + +- How can it be ensured, that the monitored application does not interfere with the monitoring functionality? +- How can it be ensured, that the :term:`Health Monitor` does not incorrectly report alive to the :term:`Launch Manager` when it has detected + a supervision error? + + +These concerns are valid, but can be addressed using the following techniques: + +- Hiding of the internal data from the user: + - For example, if the monitoring is implemented in a thread, the thread ID must not be exposed to the calling application. + - Hide the implementation for example with the pImpl-approach +- Protecting the memory of the library by using guard pages where the application memory is located, and protect it with mprotect() + - possibly with a help of a custom allocator +- Protecting the data with a checksum and possibly a sequence counter + - The internal data of the library can be checksum'ed every operation cycle, and by adding for example, a sequence + counter (or some more complex mathematical function), further checkpoints for detecting misbehavior can be implemented +- Using a safe programming language, which does not allow a raw pointer access +- Testing the application with Valgrid etc. +- Redundant monitoring, if the self monitoring with above is not sufficient, an another library in another memory location can detect sporadic corruption of the other. + + +Error Reactions +--------------- + +- When the :term:`Health Monitor` detects a failed supervision, it shall stop triggering alive notifications to the :term:`Launch Manager`. +- Additionally, when the error occurs, the :term:`Health Monitor` triggers a failure notification to the :term:`Launch Manager` to reduce the time + to react on the error. This obviously will only work if the :term:`Health Monitor` is still working and correctly scheduled. Thus the + worst case reaction time calculations must be made on the monitoring rules specified in the :term:`Launch Manager` for the monitored application. + + +Deadline Monitor API +==================== + +Interface +--------- + +The deadline monitor interface is defined here: :need:`logic_arc_int__lifecycle__deadline_monitor_if` + + +Dynamic Architecture +-------------------- + +.. feat_arc_dyn:: Application health monitoring + :id: feat_arc_dyn__lifecycle__app_health_mon + :security: YES + :status: valid + :version: 1 + :safety: ASIL_B + :fulfils: feat_req__lifecycle__liveliness_detection[version==1] + :belongs_to: feat__lifecycle[version==1] + + .. uml:: _assets/application_health_monitoring_dynamic.puml + :scale: 50 + :align: center + +The most important interactions are the following: + +.. list-table:: Sequence diagram Description + :widths: 10 90 + :header-rows: 1 + + * - Sequence number + - Description + * - 001 + - :term:`Launch Manager` configuration for the alive monitoring of the `Monitored application` is parsed. This contains for example, what is the expected interval of alive notifications, + how long grace period is given before failing to a missed (never received) alive notification etc. + * - 002 + - Start the startup grace period timer to allow the application to startup, before timing out to a missed alive notification + * - 003 + - The `Monitored application` is started. (To simplify, no startup checks drawn here) + * - 004 + - The `Monitored application` instantiate and configure the HealthMonitor + * - 006 + - Cyclic reporting aliveness to the monitor. + * - 007 + - HealthMonitor waking up and checking if the checkpoint(s) have been called + * - 008 + - Report aliveness to the LM's application specific supervision, observing the health of the HealthMonitor itself + * - 009 + - Checkpoint sent, but not on time + * - 010 + - Wake up and check if the checkpoint(s) have been triggered. In this case it was not, and thus actions 011 and 012 are triggered. + * - 011 + - Trigger a failure event to the Launch Manager. This event allows the monitor react faster than waiting for the timeout to expire. + * - 012 + - Additionally, triggering alive must be stopped + +Requirements +------------ + +- :need:`feat_req__lifecycle__hm_deadline` + +Logical Monitor API +=================== + +Interface +--------- + +The logical monitor interface is defined here: :need:`logic_arc_int__lifecycle__logical_monitor_if` + + +Dynamic Architecture +-------------------- + +.. feat_arc_dyn:: Logical control flow monitoring + :id: feat_arc_dyn__lifecycle__app_ctrl_flow_mon + :security: YES + :status: valid + :version: 1 + :safety: ASIL_B + :fulfils: feat_req__lifecycle__liveliness_detection[version==1] + :belongs_to: feat__lifecycle[version==1] + + .. uml:: _assets/logical_sup.puml + :scale: 50 + :align: center + + +Requirements +------------ + +- :need:`feat_req__lifecycle__hm_logical` diff --git a/docs/features/lifecycle/architecture/index.rst b/docs/features/lifecycle/architecture/index.rst index 55cc80792..7c1e7610f 100644 --- a/docs/features/lifecycle/architecture/index.rst +++ b/docs/features/lifecycle/architecture/index.rst @@ -15,21 +15,29 @@ Feature Architecture ==================== -.. document:: Lifecycle Architecture - :id: doc__lifecycle_architecture - :status: draft +.. document:: Lifecycle Module Architecture + :id: doc__lifecycle_module_architecture + :status: valid :safety: ASIL_B - :security: NO - :realizes: wp__feature_arch + :security: YES + :version: 1 + :realizes: wp__feature_arch[version==1] Overview -------- - + +A brief overview of Lifecycle is described :need:`doc__lifecycle`. Description ----------- - +The concept is based on 2 major components: + +* **Launch Manager**: Responsible for starting and stopping components based on + the defined Run States and alive supervision of the started components + +* **Health Monitor**: Provides process local monitoring functionalities such as + deadline monitoring and logical program flow monitoring @@ -38,7 +46,7 @@ Description Requirements ------------ -The requirements for the feature architecture are defined in the `requirements` section of the feature documentation in the project repository. +The requirements for the feature architecture are defined in the `requirements` section of the feature documentation in the project repository: :need:`doc__lifecycle_requirements` Rationale Behind Architecture Decomposition ******************************************* @@ -50,25 +58,21 @@ Mandatory: A motivation for the decomposition Static Architecture ------------------- -The live feature architecture template snippets are maintained in the -`module template documentation `__. - -.. code-block:: rst - - .. feat_arc_sta:: Feature Static View - :id: feat_arc_sta__feature_name__static_view - :security: YES - :safety: ASIL_B - :status: invalid - :fulfils: feat_req__feature_name__some_title - :includes: logic_arc_int__feature_name__interface_name1 - :belongs_to: feat__feature_name +.. feat_arc_sta:: Lifecycle Static View + :id: feat_arc_sta__lifecycle__static_view_arch + :security: YES + :safety: ASIL_B + :status: valid + :version: 1 + :fulfils: feat_req__lifecycle__launch_support[version==1] + :includes: logic_arc_int__lifecycle__lifecycle_if[version==1], logic_arc_int__lifecycle__alive_if[version==1], logic_arc_int__lifecycle__controlif[version==1], logic_arc_int__lifecycle__deadline_monitor_if[version==1], logic_arc_int__lifecycle__logical_monitor_if[version==1] + :belongs_to: feat__lifecycle - .. needarch:: - :scale: 50 - :align: center + .. needarch:: + :scale: 50 + :align: center - {{ draw_feature(need(), needs) }} + {{ draw_feature(need(), needs) }} Dynamic Architecture -------------------- @@ -88,56 +92,38 @@ Dynamic Architecture Logical Interfaces ------------------ -The logical interfaces of the feature are defined in the `logical interfaces` section of the feature documentation in the project repository. +The logical interfaces of the feature are defined in the `interfaces` section of the feature documentation in the project repository: :need:`doc__lifecycle_architecture` Module Viewpoint ---------------- -The following modules are needed to be defined to be able to draw the static feature view. -They will be replaced by linking the proper module definitions in the used module's repositories as soon as those exist. - -The rendered module and used-component examples are maintained in the -`module template documentation `_. - -.. code-block:: rst - - .. mod:: Module Name - :id: mod__module_name - :includes: comp__component_name_template - - - .. mod_view_sta:: Module Name Static View - :id: mod_view_sta__feature_name__module_name - :includes: comp__component_name_template - - .. needarch:: - :scale: 50 - :align: center - - {{ draw_module(need(), needs) }} - -Used Components ---------------- - -The following components are needed to be defined to be able to draw the static feature view. -They will be replaced by linking the proper SW component definitions in the used module's repositories as soon as those exist. - -.. code-block:: rst - - .. comp:: Component Name - :id: comp__component_name_template - :safety: ASIL_B - :security: YES - :status: invalid - :implements: logic_arc_int__feature_name__interface_name1 - -.. note:: - Architecture can be split into multiple files, it is an high level architecture design - which can be shown without actual c++/rust interfaces and data types - and there will be link to internal architecture till code to get actual api descriptions. +.. mod_view_sta:: Module architecture + :id: mod_view_sta__lifecycle__all + :version: 1 + :includes: comp__lifecycle_launch_manager, comp__health_monitor + + .. needarch:: + :scale: 50 + :align: center + + {{ draw_module(need(), needs) }} + LifecycleApplication --> logic_arc_int__lifecycle__lifecycle_if : implements + LifecycleApplication --> logic_arc_int__lifecycle__controlif : use + LifecycleApplication --> logic_arc_int__lifecycle__alive_if : use + LifecycleApplication --> logic_arc_int__lifecycle__logical_monitor_if : use + LifecycleApplication --> logic_arc_int__lifecycle__deadline_monitor_if :use + LifecycleApplication --> posix_signals : implements + NativeApplication --> posix_signals : implements + comp__lifecycle_launch_manager --> posix_signals : use + +Components Details +------------------ -.. attention:: - The above directives must be updated according to your feature architecture. +.. toctree:: + :maxdepth: 1 + :glob: - - Replace the example content by the real content (according to :need:`gd_guidl__arch_design`) - - Set the status to valid and start the review/merge process + ./launch_manager + ./launch_manager_configuration + ./health_monitor + ./external_monitoring diff --git a/docs/features/lifecycle/architecture/launch_manager.rst b/docs/features/lifecycle/architecture/launch_manager.rst new file mode 100644 index 000000000..7f79310ce --- /dev/null +++ b/docs/features/lifecycle/architecture/launch_manager.rst @@ -0,0 +1,269 @@ +.. + # ******************************************************************************* + # Copyright (c) 2025 Contributors to the Eclipse Foundation + # + # See the NOTICE file(s) distributed with this work for additional + # information regarding copyright ownership. + # + # This program and the accompanying materials are made available under the + # terms of the Apache License Version 2.0 which is available at + # https://www.apache.org/licenses/LICENSE-2.0 + # + # SPDX-License-Identifier: Apache-2.0 + # ******************************************************************************* + +Launch manager +############## + +The :term:`Launch Manager` is a component that provides a framework for managing +the lifecycle of processes in the S-CORE platform. It allows for launching, +monitoring, and controlling processes based on defined configurations and +requirements. As such, it is a central part of the lifecycle management in +S-CORE and knows about the state of all processes in the system. + +It's foreseen ECU projects will need a custom state management to fulfill ECU-project specific requirements. The S-CORE stack will offer a framework to control application lifecycle, but will not specify the State Manager. + +Overview +======== + +The functionality of the :term:`Launch Manager` is defined by configuration data, which spawns a directed acyclic graph (DAG) of :term:`Components ` and so called :term:`Run Targets `. +The :term:`Run Targets ` are virtual nodes in the DAG and represent :term:`Run States ` of the system. +The :term:`Launch Manager` is responsible for starting and stopping the processes in the correct order, based on the dependencies defined in the configuration data. + +E.g. the configuration below consists of three :term:`Run Targets ` managing 9 components. If the user selects e.g. the :term:`Run Target` "debug" the :term:`Launch Manager` will start the components in the following order defined by the dependencies. + +1. flash driver +2. filesystem +3. setup filesystems +4. networking +5. ssh + +.. uml:: _assets/launch_manager_target_tree.puml + :scale: 50 + :align: center + +The :need:`comp__lifecycle_launch_manager` implements the following interfaces,for the selection of :term:`Run Target` s, starting and stopping of components and monitoring of the processes. + +Switching between Run Targets +----------------------------- + +The :term:`Launch Manager` allows switching between different :term:`Run Targets `. When a switch is requested, the :term:`Launch Manager` evaluates the current state and the target state, +determining which components need to be started or stopped based on their dependencies. + +When a component is started the :term:`Launch Manager` will start the corresponding process and monitor its state via :term:`Ready Conditions `. + +:term:`Ready Conditions ` are essential mechanisms that determine when a component has successfully completed its startup phase and is ready to fulfill its intended role in the system. These conditions provide flexibility in defining what constitutes a "ready" state for different types of components. For SCORE applications, components can actively report their readiness through the Lifecycle Interface by signaling specific states or custom conditions. For native applications, the :term:`Launch Manager` relies on external indicators such as process existence, file creation, network socket availability, or successful process termination. This dual approach ensures that both modern SCORE-aware applications and legacy native applications can participate in the dependency management system, allowing the :term:`Launch Manager` to orchestrate complex startup sequences where components depend on each other's readiness rather than just their launch order. + + +Control Interface +================= + +This interface provides control functionality for activating and managing run targets.It allows users to trigger execution of configured :term:`Run targets ` through a standardized activation mechanism. + +Interface +--------- + +The control interface is defined here: :need:`logic_arc_int__lifecycle__controlif` +The :term:`Launch Manager` provides an interface, which allows an external State Manager application to request the :term:`Launch Manager` to start, stop or restart applications or groups of applications, +which allows the implementation of a state management applications to support dynamic state control. + + + +Dynamic architecture +-------------------- + +The following use cases are supported by the `ControlInterface` provided by the :term:`Launch Manager`. + +**Activating a Run Target** + +When a request to activate a run target is received via the `ControlInterface`, the :term:`Launch Manager` shall perform the following operations: + +1. **Validation**: Evaluate if the conditions are correct for activating the requested run target: + - The run target exists in the configuration + - All dependencies for the run target are resolvable + - Required resources are available + +2. **Transition Logic**: Determine the transition from the current state to the target state: + - If a different run target is active, perform a switch operation (stop current, start requested) + - If the same run target is already active, verify its state and potentially restart failed components + +3. **Execution**: Execute the transition in the correct dependency order: + - Stop components that are not part of the new run target + - Start components that are required for the new run target + - Respect dependency relationships during both stop and start operations + +4. **Response**: Return status to the caller: + - Success if all components transitioned correctly + - Failure with detailed error information if any component failed to transition + +This unified approach allows external state managers to request any run target activation without needing to know the current system state, as the :term:`Launch Manager` handles the transition logic internally. + + +.. feat_arc_dyn:: Control interface dynamic architecture activate run target + :id: feat_arc_dyn__lifecycle__control_activate + :status: valid + :version: 1 + :safety: ASIL_B + :security: YES + :fulfils: feat_req__lifecycle__control_commands[version==1], feat_req__lifecycle__request_run_target_start[version==1], feat_req__lifecycle__switch_run_targets[version==1] + :belongs_to: feat__lifecycle[version==1] + + .. uml:: _assets/control_interface_start_sequence.puml + :scale: 50 + :align: center + + + +Requirements +------------ + +- :need:`feat_req__lifecycle__control_commands` +- :need:`feat_req__lifecycle__request_run_target_start` +- :need:`feat_req__lifecycle__switch_run_targets` + + + +Lifecycle Interface +=================== + + +The :term:`Launch Manager` provides interfaces for communication with launched applications, supporting two distinct application types: + +1. **SCORE Applications**: Implement the full Lifecycle Interface for bidirectional communication with state reporting, liveliness indication, and conditional signaling +2. **Native Applications**: Controlled exclusively via POSIX signals (SIGTERM, SIGKILL, etc.) without direct API communication + +This dual approach enables the :term:`Launch Manager` to manage both legacy native applications and SCORE-aware applications within the same system. + +The Lifecycle Interface serves as the communication channel between applications and the :term:`Launch Manager`: + +**For SCORE Applications:** +- Application state reporting (started, running, stopped) +- Conditional signaling for application dependencies + +**For Native Applications:** +- Process lifecycle control via POSIX signals +- Basic process monitoring (PID-based status checking) +- Exit code evaluation for failure detection + +Interface +--------- + +The lifecycle interface is defined here: :need:`logic_arc_int__lifecycle__lifecycle_if` + +The following use cases are supported by the Lifecycle Interface, with different capabilities depending on the application type. + +**SCORE Application State Communication** + +SCORE applications implementing the Lifecycle Interface can communicate their internal state to the :term:`Launch Manager`. The state information includes: + +- **Started**: Application has successfully initialized and is ready to operate +- **Running**: Application is actively executing its main functionality +- **Stopped**: Application has terminated or is in the process of shutting down + +The :term:`Launch Manager` uses this state information for: + +- Dependency resolution for other applications +- Recovery action decisions +- Status reporting to external state managers via the Control Interface + + +**SCORE Application Conditional Signaling** + +SCORE applications can signal custom conditions to the :term:`Launch Manager` via the Alive Interface. This enables: + +- Complex dependency management beyond simple process startup +- Coordination between interdependent applications + +Custom conditions can be used by other applications as launch dependencies, allowing for sophisticated startup orchestration. + +**Native Application Control** + +Native applications that do not implement the Lifecycle Interface are controlled through POSIX signals: + +- **SIGTERM**: Graceful shutdown request +- **SIGKILL**: Forced termination (after timeout) +- **SIGUSR1/SIGUSR2**: Application-specific signals (if configured) + +The :term:`Launch Manager` monitors native applications through: + +- Process ID (PID) tracking +- Exit code evaluation +- Resource usage monitoring via OS facilities +- Timeout-based failure detection + +For native applications, the :term:`Launch Manager` provides: + +- Basic lifecycle control (start/stop) +- Simple dependency management based on process existence +- Configurable startup/shutdown timeouts +- Exit code-based success/failure determination + + +Dynamic Architecture +-------------------- + +.. feat_arc_dyn:: Lifecyle Interface + :id: feat_arc_dyn__lifecycle__state_machine_if + :security: YES + :status: valid + :version: 1 + :safety: ASIL_B + :fulfils: feat_req__lifecycle__process_termination[version==1], feat_req__lifecycle__launch_support[version==1] + :belongs_to: feat__lifecycle[version==1] + + .. uml:: _assets/lifecycle_state_machine.puml + :scale: 50 + :align: center + +Requirements +------------ + +- :need:`feat_req__lifecycle__process_termination` +- :need:`feat_req__lifecycle__launch_support` + + + +Alive Interface +=============== +The Alive Interface provides a basic watchdog functionality interface that delivers essential monitoring capabilities for system health and responsiveness tracking. +It implements core watchdog operations including heartbeat signals to ensure reliable operation and automatic recovery from unresponsive states. + +**SCORE Application Liveliness Reporting** + +SCORE applications can periodically signal their liveliness to the :term:`Launch Manager` through the Alive Interface. This mechanism allows the :term:`Launch Manager` to: + +- Detect application failures or hangs +- Trigger recovery actions when liveliness is lost +- Maintain accurate process health status + +The liveliness mechanism includes: + +- Configurable heartbeat intervals per application +- Timeout detection and failure handling + +Interface +--------- + +The alive interface is defined here: :need:`logic_arc_int__lifecycle__alive_if` + + +Dynamic architecture +-------------------- + +.. feat_arc_dyn:: Alive Monitoring + :id: feat_arc_dyn__lifecycle__alive_monitor + :security: YES + :status: valid + :version: 1 + :safety: ASIL_B + :fulfils: feat_req__lifecycle__liveliness_detection[version==1] + :includes: + :belongs_to: feat__lifecycle[version==1] + + .. uml:: _assets/alive_monitoring_dynamic.puml + :scale: 50 + :align: center + +Requirements +------------ +- :need:`feat_req__lifecycle__liveliness_detection` diff --git a/docs/features/lifecycle/architecture/launch_manager_configuration.rst b/docs/features/lifecycle/architecture/launch_manager_configuration.rst new file mode 100644 index 000000000..c42fc7de2 --- /dev/null +++ b/docs/features/lifecycle/architecture/launch_manager_configuration.rst @@ -0,0 +1,72 @@ +.. + # ******************************************************************************* + # Copyright (c) 2024 Contributors to the Eclipse Foundation + # + # See the NOTICE file(s) distributed with this work for additional + # information regarding copyright ownership. + # + # This program and the accompanying materials are made available under the + # terms of the Apache License Version 2.0 which is available at + # https://www.apache.org/licenses/LICENSE-2.0 + # + # SPDX-License-Identifier: Apache-2.0 + # ******************************************************************************* + +Launch Manager Configuration +############################ + +The :term:`Launch Manager` supports a set of configuration parameters, which are grouped in the following categories: + +Component Configuration Parameters +================================== + +These parameters specify the arguments needed for spawning a process. + +- :need:`comp_req__launch_man__uid_gid_support` +- :need:`comp_req__launch_man__supplementary_groups` +- :need:`comp_req__launch_man__runmask_support` +- :need:`comp_req__launch_man__launch_priority_support` +- :need:`comp_req__launch_man__cwd_support` +- :need:`comp_req__launch_man__process_launch_args` +- :need:`comp_req__launch_man__std_handle_redir` +- :need:`comp_req__launch_man__aslr_support` +- :need:`comp_req__launch_man__process_rlimit_support` +- :need:`comp_req__launch_man__support_secpol_type` + +Dependency parameters +===================== + +These parameters specify how the components depend on each other. + +Recovery parameters +=================== + +These parameters specify the recovery actions for a component, when it fails. + +Alive monitoring parameters +=========================== + +These parameters specify the alive monitoring rules for the application. + +Requirements related to the external monitoring +=============================================== + +These parameters specify how the :term:`Launch Manager` itself is monitored. + +- :need:`feat_req__lifecycle__lm_self_health_check` + + +Static Architecture +=================== + +.. logic_arc_int:: Configuration parameters static architecture + :id: logic_arc_int__lifecycle__cfg_params_static + :security: YES + :safety: ASIL_B + :status: valid + :version: 1 + :fulfils: feat_req__com__interfaces[version==1] + + .. uml:: _assets/config_params_static.puml + :scale: 50 + :align: center diff --git a/docs/features/lifecycle/glossary.rst b/docs/features/lifecycle/glossary.rst new file mode 100644 index 000000000..f0075d78b --- /dev/null +++ b/docs/features/lifecycle/glossary.rst @@ -0,0 +1,124 @@ +.. + # ******************************************************************************* + # Copyright (c) 2025 Contributors to the Eclipse Foundation + # + # See the NOTICE file(s) distributed with this work for additional + # information regarding copyright ownership. + # + # This program and the accompanying materials are made available under the + # terms of the Apache License Version 2.0 which is available at + # https://www.apache.org/licenses/LICENSE-2.0 + # + # SPDX-License-Identifier: Apache-2.0 + # ******************************************************************************* + +Glossary +======== + +.. glossary:: + Lifecycle Feature + Feature providing support for starting and stopping processes. + + Launch Manager + Component to start and stop processes on a POSIX like operating system. + + Health Monitor + Provides process local monitoring functionalities such as deadline monitoring + and logical program flow monitoring. + + Control Interface + Interface to control the lifecycle of the system, e.g. to start and stop processes. + + Alive Interface + Interface to monitor the aliveness of a process. + + Sandbox + A sandbox is a set of configurations, which are applied to a process when it + is started. It can include environment variables, secpol policies, cgroup + configurations, user and group IDs etc. + + Health Monitor Interface + Interface to monitor the health of a process, e.g. to check if a process is + alive or if it is running as expected. + + Alive Monitoring + Checks if an application reports an alive state in a certain period. + + Deadline Monitoring + Monitor to detect if a state was reached within a specified time related to + another event. + + Logical Programflow Monitoring + Monitor to detect if certain states were reached in a defined sequence and + time interval. + + Run State + An Run State defines a set of components, which are in status running + and are supervised by the software platform. If the health management system + detects abnormal situation it can change the :term:`Run State`. + + Component + A configurable unit in the Launch Manager that describes an executable and its runtime environment (sandbox). Components can be grouped together in Run Targets to define system operational states. + + Lifecycle Component + Node of the dependency tree. + + Process + Instantiation of an Executable programs running on the system that are managed by the Launch Manager. + + UID + User Identifier - a unique number assigned to each user on a Unix-like operating system. + + GID + Group Identifier - a unique number assigned to each group on a Unix-like operating system. + + Polling Interval + The time interval between successive checks of a condition or status. + + Working Directory + The current directory from which a process is executed, also known as CWD (Current Working Directory). + + File Descriptor + A handle used by a process to access files or other input/output resources. + + Procmgr + Process Manager - a QNX system component that manages process creation and execution. + + ASLR + Address Space Layout Randomization - a security technique that randomizes the memory layout of processes. + + Recovery Action + Actions taken by the Launch Manager when a process fails or terminates abnormally. + + Ready Condition + A configurable condition that must be satisfied before a component is considered ready and operational. Ready conditions can include file system checks, network availability, or custom application-specific signals. + + Ready conditions can either be reported by the component itself through the Lifecycle Interface or determined via external state monitoring. External state examples include: process started, file is available, socket was opened, or that the process finished successfully. + + Liveliness + The state indicating that a process is active and responding as expected. + + Watchdog + A monitoring mechanism that detects system failures and can trigger recovery actions. + + Interval + A period of time between events or measurements. + + QNX + A real-time operating system commonly used in embedded systems. + + + DSS + Device Safe State - a safe operational state that a system can enter during failures. + + DAG + Directed Acyclic Graph - a data structure used to represent dependencies between processes. + + SWC + Software Components - modular software units that can be independently managed. + + Run target + A named collection of processes and their dependencies that can be launched, stopped, or switched as a group to achieve a specific operational mode or configuration. + + Operating System + The system software that manages computer hardware and software resources and provides common services for computer programs. diff --git a/docs/features/lifecycle/index.rst b/docs/features/lifecycle/index.rst index 17248bf26..284c4ffa0 100644 --- a/docs/features/lifecycle/index.rst +++ b/docs/features/lifecycle/index.rst @@ -12,15 +12,15 @@ # SPDX-License-Identifier: Apache-2.0 # ******************************************************************************* -[Your Feature Name] -################### +Lifecycle +######### Abstract ======== -[A short (~200 word) description of the feature.] +The lifecycle feature provides a set of functionalities to manage the lifecycle of components in the S-SCORE platform. The goal is to ensure that components can be started, stopped, and monitored effectively, providing a robust framework for managing the state of the system. -For the main feature description and requirements, see the belonging `Feature `_ in the project repository. +For the main feature description and requirements, see the belonging Feature in the project repository: :need:`doc__lifecycle` .. toctree:: :hidden: @@ -32,3 +32,4 @@ For the main feature description and requirements, see the belonging `Feature +.. comp:: Launch Manager + :id: comp__lifecycle_launch_manager + :status: valid + :version: 1 + :safety: ASIL_B + :implements: logic_arc_int__lifecycle__controlif[version==1], logic_arc_int__lifecycle__alive_if[version==1] + :uses: logic_arc_int__logging__logging[version==1], logic_arc_int__baselibs__json[version==1], logic_arc_int__os__unistd[version==1], logic_arc_int__lifecycle__lifecycle_if[version==1] + :security: NO + :belongs_to: feat__lifecycle[version==1] Requirements Linked to Component Architecture --------------------------------------------- @@ -59,12 +67,20 @@ Mandatory: A motivation for the decomposition or reason for not further splittin Static Architecture ------------------- -The components are designed to cover the expectations from the feature architecture -(i.e. if already exists a definition it should be taken over and enriched). +.. comp_arc_sta:: Launch Manager Static View + :id: comp_arc_sta__launch_manager__lm + :status: valid + :version: 1 + :safety: ASIL_B + :security: NO + :belongs_to: comp__lifecycle_launch_manager[version==1] + :fulfils: comp_req__launch_man__process_launch_args[version==1] -A component can optional also consist of lower level components to further structure the architecture. The component and its static views can also optionally use interfaces provided by other components. + .. needarch:: + :scale: 50 + :align: center -tbd + {{ draw_component(need(), needs) }} Dynamic Architecture -------------------- diff --git a/score/launch_manager/docs/requirements/requirements.rst b/score/launch_manager/docs/requirements/requirements.rst index 8134892db..1a8741317 100644 --- a/score/launch_manager/docs/requirements/requirements.rst +++ b/score/launch_manager/docs/requirements/requirements.rst @@ -17,41 +17,793 @@ Component Launch Manager Requirements .. document:: Launch Manager Requirements :id: doc__launch_manager_requirements - :status: draft + :status: valid :safety: ASIL_B :security: YES - :realizes: wp__requirements_comp + :version: 1 + :realizes: wp__requirements_comp[version==1] - -=================================================================== +Launching Processes +=================== -Functional Requirements ------------------------ +.. comp_req:: Forward process information + :id: comp_req__launch_man__process_input_output + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 -tbd + The :term:`Launch Manager` shall provide support to pass the output of one or + multiple :term:`Processes ` as input arguments to another process. -Assumption of Use Requirements ------------------------------- +.. comp_req:: Handling process args + :id: comp_req__launch_man__process_launch_args + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 -tbd + The :term:`Launch Manager` shall provide support for launching a process with a + given set of arguments. -Environmental Requirements --------------------------- +.. comp_req:: Launching process in debug mode + :id: comp_req__launch_man__debug_support + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 -tbd + The :term:`Launch Manager` shall provide support for launching process with a + given set of debug arguments in debug mode. -Hints ------ +.. comp_req:: Launching process in state waiting for a debugger connection + :id: comp_req__launch_man__support_held_state + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 -.. attention:: - The above directives must be updated according to your component requirements. + The :term:`Launch Manager` shall provide support for launching a process in a state + waiting for a debugger connection. - - Replace the example content by the real content for your first requirement (according to :need:`gd_guidl__req_engineering`) - - Set ``safety`` and ``security`` to the right value (ASIL B/QM; YES/NO) - - Set ``reqtype`` with a link to the right value () - - Add other needed requirements for your feature - - Set ``status`` to ``valid`` and start the review/merge process + +.. comp_req:: Process user, group IDs support + :id: comp_req__launch_man__uid_gid_support + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for launching a process with a + given :term:`UID`/:term:`GID` (user name/Group Identifier). + +.. comp_req:: Process priority support + :id: comp_req__launch_man__launch_priority_support + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for launching a process with a + given priority. + + +.. comp_req:: CWD support + :id: comp_req__launch_man__cwd_support + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for launching a process with a + given :term:`Working Directory`. + +.. comp_req:: Launching terminal + :id: comp_req__launch_man__terminal_support + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for launching a terminal or a + session leader. + +.. comp_req:: Standard handle redirection + :id: comp_req__launch_man__std_handle_redir + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for stdin, stdout, stderr + redirection. + +.. comp_req:: Non-root support + :id: comp_req__launch_man__secpol_non_root + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support to be started with security + policy as non-root. + +.. comp_req:: Configurable amount of retries + :id: comp_req__launch_man__retries_configurable + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall support a configurable amount of retries in + case error occurs during startup of a component (e.g. file not available) occurs. + +.. comp_req:: Process capability support + :id: comp_req__launch_man__capability_support + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for launching :term:`Processes ` + with configured OS-specific capabilities and privileges. + +.. comp_req:: File descriptor inheritance support + :id: comp_req__launch_man__fd_inheritance + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for launching a process with + given :term:`File Descriptor` inheritance restrictions. + + +.. comp_req:: Security policy support + :id: comp_req__launch_man__support_secpol_type + :reqtype: Functional + :security: YES + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for launching a process with a + given security policy. + +.. comp_req:: Supplementary group support + :id: comp_req__launch_man__supplementary_groups + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for launching a process with a + given set of supplementary groups. + +.. comp_req:: Scheduling support + :id: comp_req__launch_man__scheduling_policy + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for launching a process with + certain scheduling policy. + +.. comp_req:: CPU runmask support + :id: comp_req__launch_man__runmask_support + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for launching a process with a + given runmask. + + +.. comp_req:: ASLR support + :id: comp_req__launch_man__aslr_support + :reqtype: Functional + :security: YES + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for launching process with + :term:`ASLR` (Address Space Layout Randomization). + +.. comp_req:: Resource limit support + :id: comp_req__launch_man__process_rlimit_support + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for launching a process with a + given set of system resource limits (rlimit). + + +.. comp_req:: Process detach from parent support + :id: comp_req__launch_man__detach_parent_process + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__custom_cond_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for launching a process to + detach from parent. + +Conditional Launching +===================== + +.. comp_req:: Conditionally launch of processes + :id: comp_req__launch_man__cond_process_start + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__conditional_startup[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support to conditionally start a process + or process group based on the return value of a single or multiple :term:`Processes ` + executed before. + +.. comp_req:: Condition timeout + :id: comp_req__launch_man__total_wait_time_support + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__conditional_startup[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for per condition configurable + total wait time for launch conditions to be satisfied. + +.. comp_req:: Conditional launch polling interval + :id: comp_req__launch_man__polling_interval + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__conditional_startup[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for per condition configurable + :term:`Polling Interval` for launch conditions to be checked. + +.. comp_req:: Pre-start validation + :id: comp_req__launch_man__validate_conditions + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__conditional_startup[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall be able to validate the pre-start conditions of the executable using the conditions. + +.. comp_req:: post-start validation + :id: comp_req__launch_man__validation_conditions + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__conditional_startup[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall be able to validate the start of the executable using the conditions. + +.. comp_req:: Launched Process status + :id: comp_req__launch_man__launcher_status_storage + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__conditional_startup[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide a way to store the status of the launched process. + +.. comp_req:: Condition check based on status + :id: comp_req__launch_man__condition_check_method + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__conditional_startup[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide a method for condition check based on process state. + +.. comp_req:: Configuration of action based on condition evaluation + :id: comp_req__launch_man__config_actions_cond + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__conditional_startup[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide a way to configure actions based on condition evaluation i.e. to be able to configure SUCCESS and FAILURE case. + +.. comp_req:: Condition check based on path + :id: comp_req__launch_man__path_condition_check + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__conditional_startup[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide a method for condition check for a path. + +.. comp_req:: Condition check based on ENV + :id: comp_req__launch_man__env_variable_cond_check + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__conditional_startup[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide a method for condition check for environment variable. + +.. comp_req:: Condition check based on all dependency + :id: comp_req__launch_man__dependency_check + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__conditional_startup[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide a method to check if all dependencies have been executed. + +.. comp_req:: Condition check based on at least one dependency + :id: comp_req__launch_man__check_dependency_exec + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__conditional_startup[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide a method to check if at least one dependency has been executed. + +.. comp_req:: Condition check for each SWC its dependencies + :id: comp_req__launch_man__define_swc_dependencies + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__conditional_startup[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide a way to define for each :term:`SWC` (Software Components), its dependencies. + + +Process Management +================== + +.. comp_req:: Dropping process responsibility + :id: comp_req__launch_man__drop_supervsion + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__running_processes[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support to dropping all surveillance + and failure reaction activities of :term:`Processes `. + + +.. comp_req:: Multiple instance of executable + :id: comp_req__launch_man__multi_start_support + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__running_processes[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall permit an executable to be launched more than once. + + +.. comp_req:: Invalid dependency + :id: comp_req__launch_man__consistent_dependencies + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__running_processes[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall reject an inconsistent definition of set of executables dependencies. + + +.. comp_req:: Dangling dependency + :id: comp_req__launch_man__stop_process_dependents + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__running_processes[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall be able to stop a process when all it's dependents are stopped if specified in the set of executables. + + +.. comp_req:: Coordination stop dependency + :id: comp_req__launch_man__stop_order_spec + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__running_processes[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall permit the stop order of non-dependent processes to be specified. + + +Run targets +=========== + +.. comp_req:: Process state + :id: comp_req__launch_man__process_state_comm + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__switch_run_targets[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall have a means for the launched :term:`Processes ` + to communicate a state, which represents the launched processes' internal state, + to the launcher. + + +Terminating Processes +===================== + +.. comp_req:: Stop timeout + :id: comp_req__launch_man__configurable_timeout + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__switch_run_targets[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for configurable timeout + :term:`Interval` to wait for the process to be stopped. + +.. comp_req:: Configurable delay between SIGTERM and SIGKILL + :id: comp_req__launch_man__time_to_wait_config + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__terminationn_dependency[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall offer a configuration of the time to wait before + SIGKILL is sent. In case "0" is stated, the SIGKILL shall be sent immediately. + +.. comp_req:: Normal shutdown + :id: comp_req__launch_man__launch_manager_shutdown + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__terminationn_dependency[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall support normal shutdown by terminating all + process in the dependency order. + +.. comp_req:: Fast shutdown + :id: comp_req__launch_man__fast_shutdown_support + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__terminationn_dependency[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall support fast shutdown by terminating itself + without considering the started :term:`Processes `. + +.. comp_req:: Launch Manager shutdown + :id: comp_req__launch_man__launcher_exit_shutdown + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__terminationn_dependency[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall exit after performing shutdown operation by + stopping all the :term:`Processes ` it owns in the dependency order when requested. + +.. comp_req:: Shutdown signal handling + :id: comp_req__launch_man__shutdown_signal + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__terminationn_dependency[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall implement a shutdown by sending a SIGTERM to + the process. In case the process does not terminate itself, a SIGKILL shall be sent. + + +Monitoring, Notification and Recovery +===================================== + +.. comp_req:: Process state notification + :id: comp_req__launch_man__ext_monitor_notify + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__monitor_abnormal_term[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for external monitors to get + notified on process life status. + +.. comp_req:: Monitoring and recovery: recovery wait time + :id: comp_req__launch_man__configurable_wait_time + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__conditional_startup[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for configurable wait time + that shall elapse before repeating :term:`Recovery Action`. + +.. comp_req:: Monitoring and recovery: adopted process monitoring + :id: comp_req__launch_man__monitoring_processes + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__liveliness_detection[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for monitoring adopted + :term:`Processes `. + +.. comp_req:: Process launch monitoring + :id: comp_req__launch_man__failure_detect + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__switch_run_targets[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall be able to detect and react to failure of the + process launch. + +.. comp_req:: Recovery + :id: comp_req__launch_man__process_failure_react + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__liveliness_detection[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall be able to react to a process failure by + optionally performing one of relaunching the process, stopping the process, + stopping the process and starting another process, or triggering :term:`QNX` + :term:`Operating System` Device Safe State (:term:`DSS`). + +.. comp_req:: Launch manager external watchdog notification + :id: comp_req__launch_man__lm_ext_watchdog_notify + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__lm_self_health_check[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall trigger a notification to an external + :term:`Watchdog` for each successful self monitoring test execution. + +.. comp_req:: Launch manager external watchdog notification - failed test + :id: comp_req__launch_man__lm_ext_wdg_failed_test + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__lm_self_health_check[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall not trigger an external :term:`Watchdog` + notification if an internal health check failed. + +.. comp_req:: Launch manager external monitoring configuration + :id: comp_req__launch_man__lm_ext_watchdog_cfg + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__lm_self_health_check[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall support configuring the :term:`Interval` of + the internal health check executions. + +Logging +======= + +.. comp_req:: Logging slog2 and file support + :id: comp_req__launch_man__slog2_logging + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__logging_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall support OS specific logging facilities to analyze the early + boot sequence. + +.. comp_req:: Logging state transitions + :id: comp_req__launch_man__process_logging_support + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__logging_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide support for logging process launches, + :term:`Processes ` exit/recovery, internal tasks, and interaction with external monitor. + +.. comp_req:: Logging timestamp + :id: comp_req__launch_man__log_timestamp + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__logging_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` logs shall contain timestamp information. + + +.. comp_req:: Logging DAG + :id: comp_req__launch_man__dag_logging_controlif + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__logging_support[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall provide the possibility to log the :term:`DAG` + in a human readable format, triggered via :term:`Control Interface`. + + +.. comp_req:: Configuration dependency view + :id: comp_req__launch_man__dependency_visu + :reqtype: Functional + :security: NO + :safety: QM + :derived_from: feat_req__lifecycle__deps_visualization[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall have the means to log the current dependencies in a format that can be visualized when requested. + +Configuration file +================== + +.. comp_req:: Configuration file support + :id: comp_req__launch_man__modular_config_support + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__config_file_support[version==1] + :status: valid + :version: 1 + + The launch manager shall provide modular configuration file support to configure process attributes. + +.. comp_req:: Runtime configuration compliance + :id: comp_req__launch_man__runtime_config_compat + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__config_file_support[version==1] + :status: valid + :version: 1 + + The launch manager shall provide modular configuration files support for configurations coming from `OCI runtime configuration`. + + +.. comp_req:: Global process properties + :id: comp_req__launch_man__central_default_defines + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__component_group_config[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall be able to centrally define defaults for specific properties for the set of executables. + + +.. comp_req:: Lazy check of configured commands + :id: comp_req__launch_man__lazy_check + :reqtype: Functional + :security: NO + :safety: ASIL_B + :derived_from: feat_req__lifecycle__component_group_config[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall check availability of executables in the filesystem only when the executable shall required to be executed. + + +.. comp_req:: Configuration Verification tool + :id: comp_req__launch_man__offline_config_valid + :reqtype: Functional + :security: NO + :safety: QM + :derived_from: feat_req__lifecycle__deps_visualization[version==1] + :status: valid + :version: 1 + + The :term:`Launch Manager` shall have a means to validate the configuration offline. .. needextend:: is_external == False and "__launch_manager__" in id :+tags: lifecycle, launch_manager