diff --git a/docs/features/lifecycle/architecture/_assets/launch_manager_parallel_dep.puml b/docs/features/lifecycle/architecture/_assets/launch_manager_parallel_dep.puml new file mode 100644 index 0000000000..c9a90a4e28 --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/launch_manager_parallel_dep.puml @@ -0,0 +1,41 @@ +' ******************************************************************************* +' Copyright (c) 2026 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 +' ******************************************************************************* + +@startuml +title Launch Manager - Run Components in Parallel + +autonumber "[00]" + +participant "Launch Manager" as LM +participant "OS (kernel)" as kernel +participant "Reporting App 1" as app1 +participant "Reporting App 2" as app2 +activate LM + +LM -> LM: analyze current state +LM -> LM: determine transition plan + +LM -> kernel: Start Reporting App 1 +LM -> kernel: Start Reporting App 2 +kernel -> app1 **: Start +kernel -> app2 **: Start + +activate app1 +activate app2 + +app1 -> app1: Internal User app initialization +app1 -> LM: signal ready state via Lifecycle API +app2 -> app2: Internal User app initialization +app2 -> LM: signal ready state via Lifecycle API +... +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/launch_manager_random_crash.puml b/docs/features/lifecycle/architecture/_assets/launch_manager_random_crash.puml new file mode 100644 index 0000000000..1995458e25 --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/launch_manager_random_crash.puml @@ -0,0 +1,41 @@ +' ******************************************************************************* +' Copyright (c) 2026 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 +' ******************************************************************************* + +@startuml +title Launch Manager - Termination Request + +autonumber "[00]" + +participant "Launch Manager" as LM +participant "OS (kernel)" as kernel +participant "Crashing Process" as app1 + + +activate LM +activate app1 + +... + + +app1 -> app1: Random crash +app1 -> kernel: terminate +destroy app1 +kernel -> LM: process terminated + +LM -> LM: analyze current state +LM -> LM: determine transition plan.\nA recovery action has to be ran,\nthe recovery action is to switch to a different Run Target. +LM -> LM: Switch Run Target. + +... + +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/launch_manager_running_dep.puml b/docs/features/lifecycle/architecture/_assets/launch_manager_running_dep.puml new file mode 100644 index 0000000000..c99104625f --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/launch_manager_running_dep.puml @@ -0,0 +1,49 @@ +' ******************************************************************************* +' Copyright (c) 2026 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 +' ******************************************************************************* + +@startuml +title Launch Manager - Components Depends on Each Other + +autonumber "[00]" + +participant "Launch Manager" as LM +participant "OS (kernel)" as kernel +participant "Reporting App 1" as app1 +participant "Reporting App 2" as app2 +activate LM + +LM -> LM: analyze current state +LM -> LM: determine transition plan + +LM -> kernel: Start Reporting App 1 +kernel -> app1 **: Start +activate app1 +LM -> LM: wait for Reporting App 1 ready condition +app1 -> app1: Internal User app initialization +app1 -> LM: signal ready state via Lifecycle API + +LM -> LM: analyze current state +LM -> LM: determine transition plan + +LM -> kernel: Start Reporting App 2 +kernel -> app2 **: Start +activate app2 +LM -> LM: wait for Reporting App 2 ready condition +app2 -> app2: Internal User app initialization +app2 -> LM: signal ready state via Lifecycle API + +LM -> LM: analyze current state +LM -> LM: update current run target state to active + +... +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/launch_manager_terminate_dep.puml b/docs/features/lifecycle/architecture/_assets/launch_manager_terminate_dep.puml new file mode 100644 index 0000000000..fe5cbc6c07 --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/launch_manager_terminate_dep.puml @@ -0,0 +1,52 @@ +' ******************************************************************************* +' Copyright (c) 2026 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 +' ******************************************************************************* + +@startuml +title Launch Manager - Components Depends on Termination + +autonumber "[00]" + +participant "Launch Manager" as LM +participant "OS (kernel)" as kernel +participant "Reporting App 1" as app1 +participant "Reporting App 2" as app2 +activate LM + +LM -> LM: analyze current state +LM -> LM: determine transition plan + +LM -> kernel: Start Reporting App 1 +kernel -> app1 **: Start +activate app1 +LM -> LM: wait for Reporting App 1 ready condition +app1 -> app1: Internal User app initialization +app1 -> LM: signal ready state via Lifecycle API + +... + +app1 -> kernel: Termination +destroy app1 +kernel -> LM: Reporting App 1 Terminated +deactivate app1 + +LM -> LM: analyze current state +LM -> LM: determine transition plan + +LM -> kernel: Start Reporting App 2 +kernel -> app2 **: Start +activate app2 +LM -> LM: wait for Reporting App 2 ready condition +app2 -> app2: Internal User app initialization +app2 -> LM: signal ready state via Lifecycle API +... +@enduml diff --git a/docs/features/lifecycle/architecture/_assets/launch_manager_terminate_request.puml b/docs/features/lifecycle/architecture/_assets/launch_manager_terminate_request.puml new file mode 100644 index 0000000000..f823dd038d --- /dev/null +++ b/docs/features/lifecycle/architecture/_assets/launch_manager_terminate_request.puml @@ -0,0 +1,44 @@ +' ******************************************************************************* +' Copyright (c) 2026 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 +' ******************************************************************************* + +@startuml +title Launch Manager - Termination Request + +autonumber "[00]" + +participant "Launch Manager" as LM +participant "OS (kernel)" as kernel +participant "Non self-terminating (well behaving)" as app1 +participant "Non self-terminating (badly behaving)" as app2 + +activate LM +activate app1 +activate app2 + +== Switch Run Target == + +LM -> LM: analyze current state +LM -> LM: determine transition plan + + +LM -> app1: SIGTERM +app1 -> kernel: terminate +destroy app1 + +LM -> app2: SIGTERM +app2 -> app2: Ignore +LM -> app2: SIGKILL +app2 -> kernel: terminate +destroy app2 + +@enduml diff --git a/docs/features/lifecycle/architecture/alive.rst b/docs/features/lifecycle/architecture/alive.rst new file mode 100644 index 0000000000..bde2626bc7 --- /dev/null +++ b/docs/features/lifecycle/architecture/alive.rst @@ -0,0 +1,59 @@ +.. + # ******************************************************************************* + # 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 + # ******************************************************************************* + +Alive +##### + +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 + +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 + + diff --git a/docs/features/lifecycle/architecture/control_client.rst b/docs/features/lifecycle/architecture/control_client.rst new file mode 100644 index 0000000000..126eebc1ea --- /dev/null +++ b/docs/features/lifecycle/architecture/control_client.rst @@ -0,0 +1,82 @@ +.. + # ******************************************************************************* + # 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 + # ******************************************************************************* + +Control Client +############## + +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. + +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. + +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 +==================== + +.. 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 + + + diff --git a/docs/features/lifecycle/architecture/external_monitoring.rst b/docs/features/lifecycle/architecture/external_monitoring.rst index d8b6962335..ccc6661080 100644 --- a/docs/features/lifecycle/architecture/external_monitoring.rst +++ b/docs/features/lifecycle/architecture/external_monitoring.rst @@ -24,58 +24,77 @@ 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. +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. +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 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. +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` +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. 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 +.. feat_arc_dyn:: Launch Manager Watchdog Interaction + :id: feat_arc_dyn__lifecycle__watch + :status: valid + :version: 1 + :safety: ASIL_B + :security: YES + :fulfils: feat_req__lifecycle__lm_self_health_check[version==1], + :belongs_to: feat__lifecycle[version==1] + + .. uml:: _assets/external_monitoring_sequence.puml + :alt: External monitoring static arch + + + .. 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 index d335dd7379..502f045e13 100644 --- a/docs/features/lifecycle/architecture/health_monitor.rst +++ b/docs/features/lifecycle/architecture/health_monitor.rst @@ -99,61 +99,46 @@ Dynamic Architecture :status: valid :version: 1 :safety: ASIL_B - :fulfils: feat_req__lifecycle__liveliness_detection[version==1] + :fulfils: feat_req__lifecycle__liveliness_detection[version==1], + feat_req__lifecycle__hm_checkpoint[version==1], + feat_req__lifecycle__hm_deadline[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 + 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 @@ -161,7 +146,9 @@ Dynamic Architecture :status: valid :version: 1 :safety: ASIL_B - :fulfils: feat_req__lifecycle__liveliness_detection[version==1] + :fulfils: feat_req__lifecycle__liveliness_detection[version==1], + feat_req__lifecycle__hm_checkpoint[version==1], + feat_req__lifecycle__hm_logical[version==1], :belongs_to: feat__lifecycle[version==1] .. uml:: _assets/logical_sup.puml diff --git a/docs/features/lifecycle/architecture/index.rst b/docs/features/lifecycle/architecture/index.rst index 5e4b820cd3..ff5a5305d1 100644 --- a/docs/features/lifecycle/architecture/index.rst +++ b/docs/features/lifecycle/architecture/index.rst @@ -43,10 +43,6 @@ The concept is based on 2 major components: -Requirements ------------- - -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 ******************************************* @@ -64,8 +60,13 @@ Static Architecture :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] + :fulfils: feat_req__lifecycle__launch_support[version==1], + feat_req__lifecycle__logging_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:: @@ -73,26 +74,41 @@ Static Architecture :align: center {{ draw_feature(need(), needs) }} + artifact "Configuration" as cfg + + comp__lifecycle_launch_manager --> cfg: use Dynamic Architecture -------------------- -.. code-block:: rst +Interactions between the :term:`Launch Manager` and a User application +(through it's interfaces): + +.. toctree:: + :maxdepth: 1 + + ./control_client + ./lifecycle_client + ./alive + ./launch_manager_configuration + ./launch_manager + ./external_monitoring - .. feat_arc_dyn:: Dynamic View - :id: feat_arc_dyn__feature_name__dynamic_view - :security: YES - :safety: ASIL_B - :status: invalid - :fulfils: feat_req__feature_name__some_title - :belongs_to: feat__feature_name - Put here a sequence diagram +Interaction between the :term:`Health Monitor` and :term:`Launch Manager`: + +.. toctree:: + :maxdepth: 1 + + ./health_monitor + Logical Interfaces ------------------ -The logical interfaces of the feature are defined in the `interfaces` section of the feature documentation in the project repository: :need:`doc__lifecycle_architecture` +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 ---------------- @@ -117,14 +133,4 @@ Module Viewpoint NativeApplication --> posix_signals : implements comp__lifecycle_launch_manager --> posix_signals : use -Components Details ------------------- -.. toctree:: - :maxdepth: 1 - :glob: - - ./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 index 7f79310ce9..1d5b26a3ce 100644 --- a/docs/features/lifecycle/architecture/launch_manager.rst +++ b/docs/features/lifecycle/architecture/launch_manager.rst @@ -15,22 +15,40 @@ 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. +The following describes the intaraction between the +:need:`comp__lifecycle_launch_manager` and the user application. -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. + +Requirements +============ + +- :need:`feat_req__lifecycle__launch_support` +- :need:`feat_req__lifecycle__process_ordering` +- :need:`feat_req__lifecycle__parallel_launch_support` +- :need:`feat_req__lifecycle__conditional_startup` +- :need:`feat_req__lifecycle__start_named_run_target` +- :need:`feat_req__lifecycle__process_termination` +- :need:`feat_req__lifecycle__terminationn_dependency` +- :need:`feat_req__lifecycle__monitor_abnormal_term` +- :need:`feat_req__lifecycle__recovery_action_support` +- :need:`feat_req__lifecycle__recov_run_target_switch` 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. +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. +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 @@ -42,228 +60,274 @@ E.g. the configuration below consists of three :term:`Run Targets ` :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. +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 +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. + + +.. feat_arc_dyn:: Launch Manager - Components Depends on Each Other + :id: feat_arc_dyn__lifecycle__lcm_start + :security: YES :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] + :fulfils: feat_req__lifecycle__launch_support[version==1], + feat_req__lifecycle__process_ordering[version==1], + feat_req__lifecycle__start_named_run_target[version==1], + feat_req__lifecycle__conditional_startup[version==1], - .. uml:: _assets/control_interface_start_sequence.puml + .. uml:: _assets/launch_manager_running_dep.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 + Configuration: + Reporting App 2 depends on Reporting App 1, Reporting App 1 has a ready + condition of begin in state running. + + .. list-table:: Sequence diagram Description + :widths: 10 90 + :header-rows: 1 + + * - Sequence number + - Description + * - 001 + - Launch Manager analyzes the current state of the system. + * - 002 + - Launch Manager identifies the components that need to be started or stopped based on the current state. + * - 003 + - Launch Manager starts the components that need to be started. In this case Reporting App 1. + * - 004 + - Reporting App 1 is started. + * - 005 + - Launch Manager waits for the signal from the Lifecycle API. + * - 006 + - Reporting App 1 does its internal initialization. + * - 007 + - Reporting App 1 signals to the Launch Manager that it has reached the ready condition using the Lifecycle API. + * - 008 + - Launch Manager analyzes the current state of the system. + * - 009 + - Launch Manager identifies the components that need to be started or stopped based on the current state. In this case Reporting App 2 can be started. + * - 010 + - Launch Manager starts the components that need to be started. In this case Reporting App 2. + * - 011 + - Reporting App 2 is started. + * - 012 + - Launch Manager waits for the signal from the Lifecycle API. + * - 013 + - Reporting App 2 does its internal initialization. + * - 014 + - Reporting App 2 signals to the Launch Manager that it has reached the ready condition using the Lifecycle API. + * - 015 + - Launch Manager analyzes the current state of the system. + * - 016 + - Launch Manager marks the Run Target as active. + + +.. feat_arc_dyn:: Launch Manager - Termination Request + :id: feat_arc_dyn__lifecycle__lcm_term :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] + :fulfils: feat_req__lifecycle__launch_support[version==1], + feat_req__lifecycle__process_termination[version==1], + feat_req__lifecycle__process_ordering[version==1], - .. uml:: _assets/lifecycle_state_machine.puml + .. uml:: _assets/launch_manager_terminate_request.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 ---------- + .. list-table:: Sequence diagram Description + :widths: 10 90 + :header-rows: 1 + + * - Sequence number + - Description + * - 001 + - Launch Manager analyzes the current state of the system. + * - 002 + - Launch Manager determines the transition plan for switching the run target. In this case all components are to be terminated. + * - 003 + - Launch Manager sends SIGTERM to the well behaving application. + * - 004 + - The well behaving application terminates through the operating system. + * - 005 + - Launch Manager sends SIGTERM to the badly behaving application. + * - 006 + - The badly behaving application ignores the SIGTERM request. + * - 007 + - Launch Manager sends SIGKILL to force termination of the badly behaving application. + * - 008 + - The badly behaving application terminates through the operating system. + +.. feat_arc_dyn:: Launch Manager - Components Depends on Termination + :id: feat_arc_dyn__lifecycle__lcm_term_order + :security: YES + :status: valid + :version: 1 + :safety: ASIL_B + :belongs_to: feat__lifecycle[version==1] + :fulfils: feat_req__lifecycle__launch_support[version==1], + feat_req__lifecycle__process_termination[version==1], + feat_req__lifecycle__process_ordering[version==1], + feat_req__lifecycle__terminationn_dependency[version==1] -The alive interface is defined here: :need:`logic_arc_int__lifecycle__alive_if` + .. uml:: _assets/launch_manager_terminate_dep.puml + :scale: 50 + :align: center + Configuration: + Reporting App 2 depends on the termination of Reporting App 1. + + .. list-table:: Sequence diagram Description + :widths: 10 90 + :header-rows: 1 + + * - Sequence number + - Description + * - 001 + - Launch Manager analyzes the current state of the system. + * - 002 + - Launch Manager determines the transition plan. In this case Reporting App 1 can be started, Reporting App 2 needs to wait for Reporting App 1 to terminate. + * - 003 + - Launch Manager starts Reporting App 1. + * - 004 + - Reporting App 1 is started. + * - 005 + - Launch Manager waits for the ready condition of Reporting App 1. + * - 006 + - Reporting App 1 does its internal initialization. + * - 007 + - Reporting App 1 signals to the Launch Manager that it has reached the ready condition using the Lifecycle API. + * - 008 + - At some point Reporting App 1 terminates. + * - 009 + - The operating system reports the termination of Reporting App 1 to the Launch Manager. + * - 010 + - Launch Manager analyzes the current state of the system. + * - 011 + - Launch Manager determines the transition plan. In this case Reporting App 2 can be started. + * - 012 + - Launch Manager starts Reporting App 2. + * - 013 + - Reporting App 2 is started. + * - 014 + - Launch Manager waits for the ready condition of Reporting App 2. + * - 015 + - Reporting App 2 does its internal initialization. + * - 016 + - Reporting App 2 signals to the Launch Manager that it has reached the ready condition using the Lifecycle API. + + +.. feat_arc_dyn:: Launch Manager - Run Components in Parallel + :id: feat_arc_dyn__lifecycle__lcm_parallel + :security: YES + :status: valid + :version: 1 + :safety: ASIL_B + :belongs_to: feat__lifecycle[version==1] + :fulfils: feat_req__lifecycle__launch_support[version==1], + feat_req__lifecycle__process_ordering[version==1], + feat_req__lifecycle__parallel_launch_support[version==1] -Dynamic architecture --------------------- + .. uml:: _assets/launch_manager_parallel_dep.puml + :scale: 50 + :align: center -.. feat_arc_dyn:: Alive Monitoring - :id: feat_arc_dyn__lifecycle__alive_monitor + Configuration: + Reporting App 1 and Reporting App 2 can be started independently. + + .. list-table:: Sequence diagram Description + :widths: 10 90 + :header-rows: 1 + + * - Sequence number + - Description + * - 001 + - Launch Manager analyzes the current state of the system. + * - 002 + - Launch Manager determines the transition plan. In this case both Reporting App 1 and Reporting App 2 can be started in parallel. + * - 003 + - Launch Manager starts Reporting App 1. + * - 004 + - Launch Manager starts Reporting App 2. + * - 005 + - Reporting App 1 is started. + * - 006 + - Reporting App 2 is started. + * - 007 + - Reporting App 1 does its internal initialization. + * - 008 + - Reporting App 1 signals to the Launch Manager that it has reached the ready condition using the Lifecycle API. + * - 009 + - Reporting App 2 does its internal initialization. + * - 010 + - Reporting App 2 signals to the Launch Manager that it has reached the ready condition using the Lifecycle API. + + +.. feat_arc_dyn:: Launch Manager - Termination Request + :id: feat_arc_dyn__lifecycle__crash :security: YES :status: valid :version: 1 :safety: ASIL_B - :fulfils: feat_req__lifecycle__liveliness_detection[version==1] - :includes: :belongs_to: feat__lifecycle[version==1] + :fulfils: feat_req__lifecycle__monitor_abnormal_term[version==1], + feat_req__lifecycle__recovery_action_support[version==1], + feat_req__lifecycle__recov_run_target_switch[version==1] - .. uml:: _assets/alive_monitoring_dynamic.puml + .. uml:: _assets/launch_manager_random_crash.puml :scale: 50 :align: center -Requirements ------------- -- :need:`feat_req__lifecycle__liveliness_detection` + .. list-table:: Sequence diagram Description + :widths: 10 90 + :header-rows: 1 + + * - Sequence number + - Description + * - 001 + - The monitored process crashes unexpectedly. + * - 002 + - The crashed process terminates through the operating system. + * - 003 + - The operating system reports the terminated process to the Launch Manager. + * - 004 + - Launch Manager analyzes the current state of the system. + * - 005 + - Launch Manager determines the transition plan.\nIn this case a recovery action needs to be run,\nand the recovery action is to switch to a different Run Target. + * - 006 + - Launch Manager switches to the configured fallback Run Target. + diff --git a/docs/features/lifecycle/architecture/launch_manager_configuration.rst b/docs/features/lifecycle/architecture/launch_manager_configuration.rst index c42fc7de28..0a9b10e1e9 100644 --- a/docs/features/lifecycle/architecture/launch_manager_configuration.rst +++ b/docs/features/lifecycle/architecture/launch_manager_configuration.rst @@ -15,7 +15,8 @@ Launch Manager Configuration ############################ -The :term:`Launch Manager` supports a set of configuration parameters, which are grouped in the following categories: +The :term:`Launch Manager` supports a set of configuration parameters, which +are grouped in the following categories: Component Configuration Parameters ================================== @@ -65,7 +66,9 @@ Static Architecture :safety: ASIL_B :status: valid :version: 1 - :fulfils: feat_req__com__interfaces[version==1] + :fulfils: feat_req__lifecycle__component_group_config[version==1], + feat_req__lifecycle__config_file_support[version==1], + feat_req__lifecycle__run_target_support[version==1] .. uml:: _assets/config_params_static.puml :scale: 50 diff --git a/docs/features/lifecycle/architecture/lifecycle_client.rst b/docs/features/lifecycle/architecture/lifecycle_client.rst new file mode 100644 index 0000000000..7adaa3cd81 --- /dev/null +++ b/docs/features/lifecycle/architecture/lifecycle_client.rst @@ -0,0 +1,131 @@ +.. + # ******************************************************************************* + # 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 + # ******************************************************************************* + +Lifecycle Client +################ + +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 + +Requirements +============ + +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:: Component State Machine + :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], + feat_req__lifecycle__process_ordering[version==1], + feat_req__lifecycle__custom_cond_support[version==1], + feat_req__lifecycle__conditional_startup[version==1], + feat_req__lifecycle__prog_lang[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` +- :need:`feat_req__lifecycle__prog_lang` diff --git a/score/launch_manager/BUILD b/score/launch_manager/BUILD index 55dd202efc..c83a20c4dd 100644 --- a/score/launch_manager/BUILD +++ b/score/launch_manager/BUILD @@ -139,7 +139,7 @@ docs_bundle( bundles = [ { "bundle": "//score/launch_manager/src/lifecycle_client:docs", - "mount_at": "subcomponents/lifecycle_client", + "mount_at": "interfaces/lifecycle_client", }, ], code_targets = [ diff --git a/score/launch_manager/docs/architecture/component_architecture.rst b/score/launch_manager/docs/architecture/component_architecture.rst index 8bce3cb5d5..ddac16fc65 100644 --- a/score/launch_manager/docs/architecture/component_architecture.rst +++ b/score/launch_manager/docs/architecture/component_architecture.rst @@ -32,11 +32,28 @@ Overview :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__log_cpp__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] + :implements: logic_arc_int__lifecycle__controlif[version==1], + logic_arc_int__lifecycle__alive_if[version==1], + logic_arc_int__lifecycle__lifecycle_if[version==1], + :uses: logic_arc_int__log_cpp__logging[version==1], + logic_arc_int__baselibs__json[version==1], + logic_arc_int__os__unistd[version==1], :security: NO :belongs_to: feat__lifecycle[version==1] + 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. + + Requirements Linked to Component Architecture --------------------------------------------- diff --git a/score/launch_manager/docs/index.rst b/score/launch_manager/docs/index.rst index e1dc57ed47..35d5f4c2d9 100644 --- a/score/launch_manager/docs/index.rst +++ b/score/launch_manager/docs/index.rst @@ -34,9 +34,9 @@ Launch Manager safety_analysis/dfa.rst safety_analysis/aou_requirements.rst -Subcomponents -============= +Interfaces +========== .. toctree:: :titlesonly: - subcomponents/index + interfaces/index diff --git a/score/launch_manager/docs/subcomponents/index.rst b/score/launch_manager/docs/interfaces/index.rst similarity index 96% rename from score/launch_manager/docs/subcomponents/index.rst rename to score/launch_manager/docs/interfaces/index.rst index 7d3cd8326b..de58447f25 100644 --- a/score/launch_manager/docs/subcomponents/index.rst +++ b/score/launch_manager/docs/interfaces/index.rst @@ -12,7 +12,7 @@ # SPDX-License-Identifier: Apache-2.0 # ******************************************************************************* -Sub-Component documentation +Interfaces documentation --------------------------- .. toctree will be filled by docs_bundle via bazel