Launch manager#
The following describes the interaction between the Launch Manager (comp__lifecycle_launch_manager) and the user application.
Overview#
The functionality of the Launch Manager is defined by configuration data, which spawns a directed acyclic graph (DAG) of Components and so called Run Targets. The Run Targets are virtual nodes in the DAG and represent Run States of the system. The 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 Run Targets managing 9 components. If the user selects e.g. the Run Target “debug” the Launch Manager will start the components in the following order defined by the dependencies.
flash driver & eth driver
filesystem
setup filesystems
networking
ssh
The Launch Manager (comp__lifecycle_launch_manager) implements the following interfaces,for the selection of Run Target s, starting and stopping of components and monitoring of the processes.
Switching between Run Targets#
The Launch Manager allows switching between different Run Targets. When a switch is requested, the 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 Launch Manager will start the corresponding process and monitor its state via Ready Conditions.
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 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.
Interacting with processes#
The Launch Manager provides interfaces for communication with launched applications, supporting two distinct application types:
SCORE Applications: Implement the full Lifecycle Interface for bidirectional communication with state reporting, liveliness indication, and conditional signaling
Native Applications: Controlled exclusively via POSIX signals (SIGTERM, SIGKILL, etc.) without direct API communication
This dual approach enables the 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 Launch Manager.
SCORE Applications#
For SCORE Applications: - Application state reporting (started, running, stopped) - Conditional signaling for application dependencies
See Lifecycle Client for the full description of the Lifecycle Interface.
Native Applications#
Native applications that do not implement the Lifecycle Interface are controlled through POSIX signals:
SIGTERM: Graceful shutdown request
SIGKILL: Forced termination (after timeout)
The 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 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#
Example Dependency Graph#
Consider the following simplified dependency graph for the upcoming sequence diagrams.
The Component setup_filesystems starts a shell script setup_filesystems.sh and reaches its Ready state when the script completed. The Component random starts a binary /bin/random and is considered Ready when the file /dev/random exists. The Component app1 starts a binary /opt/bin/app1 and is considered Ready when the process signaled its Running state via the Lifecycle API.
Launch Manager Initial Startup#
Launch Manager Startup
|
status: valid
security: YES
safety: ASIL_B
|
||||
In case of initialization failure, the Launch Manager fails to start. Once initialization is successful, the Launch Manager activates the configured initial Run Target. The continuation of this sequence, in which the Launch Manager starts the Components of the Run Target Running, is depicted in Launch Manager - Component ... (feat_arc_dyn__lifecycle__lcm_start). |
|||||
Launch Manager Shutdown
|
status: valid
security: YES
safety: ASIL_B
|
||||
When the Launch Manager receives a SIGTERM signal, it will initiate transition to Run Target Off which leads to termination of all components. Afterwards, Launch Manager process itself exits. The transition to the Run Target Off, in which the Launch Manager terminates the Components of the currently active Run Target, is depicted in Launch Manager - Component ... (feat_arc_dyn__lifecycle__lcm_term). |
|||||
Component Dependencies and Ready Conditions#
Launch Manager - Component Dependencies
|
status: valid
security: YES
safety: ASIL_B
|
||||
While setup_filesystems and /bin/random can be started in parallel, /opt/bin/app1 can only be started once both Components are Ready. |
|||||
Component Termination#
Launch Manager - Component Termination
|
status: valid
security: YES
safety: ASIL_B
|
||||
Since app1 depends on both setup_filesystems and random, it must be terminated first before the other two components can be safely terminated. Afterwards, setup_filesystems and random can be terminated in parallel as they do not depend on each other. Note that if a component does not terminate within the configured termination timeout, it is forcefully killed. |
|||||
Recovery Action#
Component crashes outside an active transition#
Launch Manager - Crash Recovery
|
status: valid
security: YES
safety: ASIL_B
|
||||
Note: If a Restart Recovery Action is configured then only the crashed component is restarted, not dependent components. |
|||||