[lifecycle&health] Meeting Minutes 2026

[ramceb]

2026-01-07

Agenda

• Review PRs
  • Review if Health monitoring FMEA 2026-01-09 9 am.
• Review Open topics
  • Design proposal for configuration 2026-01-8 4 pm

[pawelrutkaq]

Meeting 2026-01-09, 09:00
https://teams.microsoft.com/l/meetup-join/19%3ameeting_MjMyMDkxNWYtNzIyNS00OTlhLThiZGItYWYzMmYwNzkxNDMz%40thread.v2/0?context=%7b%22Tid%22%3a%22ab1be58c-0a5a-47f0-8b55-1c095dbd46f5%22%2c%22Oid%22%3a%220c966945-d6f6-4ec4-b8b2-fd7770f4bd96%22%7d

@ramceb
@pawelrutkaq
@S-MOHAMD
@NicolasFussberger
@FScholPer

Summary:

We concluded FMEA for HM Library. The summary is documented in code, specifically in this commit: eclipse-score/lifecycle@e5fc9b1

[ramceb]

2026-01-14

Participants

@ramceb
@pawelrutkaq
@S-MOHAMD
@NicolasFussberger
@FScholPer
@odra
@SimonKozik
@vinodreddy-g

Agenda

• Goals for iteration 13 S-CORE Roadmap
  • Integrate lifecycle in reference integration
    • Merge PR Improvement: otterdog extended configuration with branch protection #33 afterwards rename repo from inc_lifecycle to lifeycle.
    • Step 1. Create Release
      • Release 0.0.0 created.
      • Component set up in bazel registry.
    • Step 2: Add to Reference integration
      • Add to reference integration image
      • Provide config to start example apps from reference integration.
      • We start with a MVP and treat all apps as native processes.
    • Step 3: Add lifecycle reference app
• Library topics
  • For the health monitor we want to use the iceoryx2-bb for now. The dependency to iceoryx2 has to be discussed in another context.
• Review open PRs
• Review open topics
• Feedback round
  • Emphasize release planing
  • Agree on release goals

[ramceb]

2026-01-21

Participants

@ramceb
@pawelrutkaq
@S-MOHAMD
@NicolasFussberger
@FScholPer
@odra
@SimonKozik
@vinodreddy-g

Agenda

• Meeting to discuss configuration setup: Friday, 23rd of january, 9-10 am.
• Proposal for migration path from process group to run target based config
  • Decision: The migration path presented is accepted. @NicolasFussberger: Please add presented diagrams to the minutes.
  • Discussion about configuration of alive channels:
    • Decisions:
      • We only have a single alive channel per process.
      • Configuration of the alive channel shall be ready by the application and communicated to the launch_manager via API.
      • @pawelrutkaq Prepare proposal for sequence diagrams between health monitor and launch_manager.
• Review PRs
• Backlog grooming

[NicolasFussberger]

The proposed migration path from ProcessGroups to RunTargets is depicted here:

We are currently thinking that for the intermediate migration steps we can map a RunTarget-based configuration to the ProcessGroup-based implementation as follows:

[S-MOHAMD]

2026-01-28

participants:

@pawelrutkaq
@S-MOHAMD
@NicolasFussberger
@SimonKozik
@antres1
@FScholPer

Agenda:

• Reference integration - how to discussion?
  • @FScholPer will clarify on where to integrate
• Backlog grooming
• Agreed to continue for the initial integration using the current IPC API and move to mw::com in the next version
• @pawelrutkaq presented sequence diagrams for communication between APP & LM Create sequence diagrams for communcation between App and LM #2476
  • Agreed to start monitoring on the report_running() timestamp
  • suggestion: start() & report_running() calls should be tied together as part of the initialization sequence. probably within init() call.
  • LM shall support:
    • Native applications (no access to score API's)
    • score applications (managed & supervised by LM)
    • score applications (reports Running but not supervised) - based on configuration
    • Self-terminated applications
      • open point: should we provide stop_supervision() API? What happens to each application type when it is called?

Topics for next meeting:

• Configuration proposal.

[SimonKozik]

2026-02-04

Participants:

@odra
@pawelrutkaq
@S-MOHAMD
@NicolasFussberger
@SimonKozik
@antres1
@FScholPer
@vinodreddy-g
@basheerFZ
@ramceb
@shegazyy
@telemaco
@vec-HossamZidan

Agenda:

• S-CORE configuration
• Findings from trial usage of Launch Manager
• Tickets for 0.6 release
• Poll for next meeting about Recovery Actions and Run Targets

Minutes

• Meeting about Recovery Actions and Run Targets
  • @NicolasFussberger will send a poll.
• Findings from trial usage of Launch Manager
  • There was an attept to integrate Launch Manager from reference integration repository (https://github.com/telemaco/reference_integration/tree/add-autosd-inc-lifecycle) into autosd
  • LM image will be generated automatically
  • LM will be started by systemd
  • However LM is not starting
    • At the moment it is not clear if this is because broken configuration or something else
  • It's worth to note that some patches had to be applied to the source code
    • Looks like most of them were centered around hardcoded file paths
  • Key takeaways messages:
    • LM is building
    • Image is created
    • Some patches are needed
    • LM is not starting correctly yet - this is under investigation.
  • Issue will be created and our team will try to support investigation
• Release 0.6
  • Examples that showcase a use cases of S-CORE will be integrated into reference integration and kept long term.
    • We needs to decide if we are going with standalone or use case examples.
    • It is suggested to simplify current examples and say that it is showcasing a basic use case of S-CORE: starting and stopping an application, plus health monitoring of that applications.
    • At the moment the autosd uses the example directory. However new examples can be relatively easy integrated.
      • There is request to use bazel targets in example director. This will make integration easier.
    • @NicolasFussberger will create PR to commit a a working configuration in json format (aka static configuration). This is seen as a first step for simplification of examples.
      • Deadline for this PR 13/02/2026
      • @pawelrutkaq will call Nicolas
  • Additionally volunteer is needed for Support correct targets & toolchains in each S-CORE module #2538
    • @pawelrutkaq will ask for volunteer in the channel
• S-CORE configuration
  • We discussed configuration, changes will be documented with following up PR
  • Next meeting will be scheduled for Friday 06/02/2026 at 15:00 CET (2 hours)
    • @S-MOHAMD will send invitation.

Topics for next meeting:

• No topics at the moment

[eclipse-impl]

I'd like to ask add a topic to the next meeting: I'd like to understand the roadmap for providing unit tests and mocks, that can be used on unit tests for config_management.

[FScholPer]

@ramceb can you please add it to the next agenda?!

[SimonKozik]

2026-02-11

Participants:

@pawelrutkaq
@ramceb
@NicolasFussberger
@antres1
@telemaco
@S-MOHAMD
@SimonKozik
@VamsiKrishna-max
@Rutuja-Patil-Bosch

Agenda:

• Roadmap for providing unit tests and mocks.
• Automatic agenda creation for next meeting.
• Architecture modules?
  • How many reusable modules we have?
  • How many safety modules out of context we have?
• Update on the integration activities.

Minutes:

• Automatic agenda creation for next meeting.
  • At the end of the meeting we will create a separate post titled: "Agenda proposal for YYYY-MM-DD"
  • Then everybody could add agenda point as a replay to that post.
  • As far as we know there is not special rights needed for posting in our discussion board.
  • We will try this and see how this will work.
• Update on the integration activities
  • Integration of sample application with integration repo are progressing.
  • This is going fine, but we have small problems.
  • However those problems are not considered critical and it looks like all is going OK and is on track for 0.6.
  • C++ and Rust applications (which are supervised) will be up and running.
  • This is considered 80% done.
  • Pull request for those activities: Integrate simple lifecycle examples reference_integration#89
  • There is a question about list of the outstanding tasks for integration, aka ToDo list.
    • This is available here: Checklist v0.6 #2564
    • There is question if we should divide the lifecycle & health tasks, but at the moment we are waiting for @paulquiring to integrate toolchain, then @pawelrutkaq will organize help in that Slack channel on the as needed basis
  • Images in the reference integration are available here: https://github.com/eclipse-score/reference_integration/tree/main/integration/images
    • Looks like this will be the structure after restructure.
• Architecture modules
  • In the SW Dev Process Community there was discussion on this topic: https://github.com/orgs/eclipse-score/discussions/407#discussioncomment-15605348
  • What is the dependable element?
    • Looks like dependable element is also safety element out of context
    • For example Health Monitoring library can be a single dependable element.
    • Dependable elements can be defined in bazel
    • It sounds a lot like dependable element is essentially our public API that we publish for use in the rest of S-CORE
  • How many dependable elements we would like to have?
    • Having above in mind, the question is, should we publish everything in a single package, aka dependable package or we should divide into smaller packages.
    • Each dependable element will need to have it's own architecture and safety artefacts.
    • There is suggestion to have a single dependable element for lifecycle & health.
      • Alternatively we can carve out Health Monitoring library as a separate dependable element.
    • What reuse use cases we have for our API? Maybe this will tell us what elements we have.
    • We decided to have a single dependable element for all the artefacts.
      • PR will follow
• Roadmap for providing unit tests and mocks
  • Will be moved to the next week. @ramceb will check with Luiz what is needed.
• Safety qualification of Health monitoring library in Rust
  • This will be followed up next week
  • The question is, what we do?
    • Continue or follow a fallback strategy.

Meeting minutes review:

This will be done offline by participants

[SimonKozik]

Agenda proposal for 2026-02-18

• Roadmap for providing unit tests and mocks
  • Topic from @eclipse-impl
• Safety qualification of Health Monitoring library

If you would like to add further agenda topics, please feel free to replay to this message.

[S-MOHAMD]

• Discuss local test execution PR Local test execution setup lifecycle#63

[SimonKozik]

2026-02-18

Participants:

@SimonKozik
@pawelrutkaq
@S-MOHAMD
@NicolasFussberger
@vinodreddy-g
@antres1
@odra
@Rutuja-Patil-Bosch
@FScholPer
@VamsiKrishna-max

Agenda:

• Roadmap for providing unit tests and mocks
• Safety qualification of Health Monitoring library
• Local test execution PR Local test execution setup lifecycle#63
• Location of the json schema in LM repo

Minutes:

• Roadmap for providing unit tests and mocks.
  • We still do not have enough information to discus this topic.
  • Still waiting for @ramceb to speak with Luiz and provide feedback
• Location of the json schema in LM repo.
  • Potential location: https://github.com/eclipse-score/lifecycle/tree/main/src/launch_manager_daemon/config
  • One problem might be that this schema is not yet in use (at least during run time).
    • This may be confusing to the end user.
  • We will go for this folder https://github.com/eclipse-score/lifecycle/tree/main/src/launch_manager_daemon/config
    • We will create a subfolder like new_schema and use it for future development.
    • We may need to find a better place for this later, but this is not so important now.
• Local test execution PR Local test execution setup lifecycle#63
  • Developers are asking for the possibility to compile natively and run tests natively.
  • This is in addition to traditional build targets.
  • In essence it is a new build target that gives a choice to a developer where and how to run code inside sandbox.
  • There is question why we should add extra complexity to the build system if we can use containers.
    • The concerns of the overhead to maintain this solution is something that is voiced strongly
  • There is question of the fact that process for a change was not followed.
    • In the essence: there should be change to the requirements and the change to the code.
  • The native test build is not meant to be used in CI/CD infrastructure - essentially not intended to be used in pipelines.
  • Decision: we mere this now and we will keep it as long as needed, then we can remove.
• Safety qualification of Health Monitoring library
  • Integration of tooling for safety artefacts (for example static analysis tools) is progressing
    • See Rust certification (view)
  • Info about safety certified toolchain is expected end of Feb 2026
  • Some libraries have safety certification already
  • At the moment outlook looks positive
  • Details will follow next week

Meeting minutes review:

• Minutes reviewed at 10:57 CET

[SimonKozik]

2026-02-25

Participants:

@pawelrutkaq
@S-MOHAMD
@vinodreddy-g
@ramceb
@Rutuja-Patil-Bosch
@basheerFZ
@FScholPer
@shegazyy
@VamsiKrishna-max
@antres1

Minutes

• Roadmap for providing unit tests and mocks

  • Topic moved from 2026-02-18 (still waiting for extra information)
  • @S-MOHAMD will review the PR for: Mb add mocks for unit testing lifecycle#78

• Safety qualification of Health Monitoring library

  • @pawelrutkaq gave an overview of the current status in Rust certification project
  • The group is targeting Q3-2026 to start qualification
  • Code coverage for rust is now available
  • With reduced dependency to baselib-rust only it is possible to certify the rust tool- chain
  • Decision: We go forward with the rust approach, and we do not need to re-implement the HM-lib in C++

• PR for JSON schema: New configuration schema for Launch Manager lifecycle#88

  • We need to avoid draft schema, move it to correct location
  • Discussed: For Schema validation we need some UT coverage mainly to cover the bundle tooling
    • Suggestion: to always validate the schema against the example configuration
    • Depends on the defined failure (FMEA) we might decide to test or not the generation tooling
    • FMEA example from Per: https://eclipse-score.github.io/score/main/features/persistency/safety_analysis/fmea.html#doc__persistency_fmea

• Feature request Feature Request for Vehicle Service Orchestrator #2597

  • @FScholPer: Please read the feature request Feature Request for Vehicle Service Orchestrator #2597 then we might need to a dedicated meeting to discuss it
  • Suggestion from @ramceb to bring the topic to official pitch in Arch meeting

[SimonKozik]

PR for JSON schema: eclipse-score/lifecycle#88

[pawelrutkaq]

Lifecycle HM Lib Rust state:

• Rust coverage & UT execution executed on each PR
• Static code analysis via bazel comming next week (currently done via cargo) - settings from the common S-CORE location
• Formatting in place - settings from the common S-CORE location
• Depends only on baselibs_rust from S-CORE and baselibs_rust does not depend on anything (and also contains coverage, formatting, static analysis in place)
• Usage of ferrocen compiler is in place
• Considered overall Rust Cert topic from Rust certification (view)
  • QNX + Feroceen shall give official toolchain certification at the end of the month (Ferrocen will also provide a statement (timeline/pricing) that they can do it without QNX on OEM request)
  • extensions to libcore + libstd (beyond current ASIL-B libcore certification) are feasible to certify - ferrocene also providing offer for it
    • This library still have possibility to ditch out libstd usage since we don't rely much on it.

[ramceb]

2026-03-04

[SimonKozik]

Agenda

• PR New configuration schema for Launch Manager lifecycle#88
  • And remaining pull requests
• Schema roadmap

Participants:

• @ramceb
• @S-MOHAMD
• @odra
• @basheerFZ
• @Rutuja-Patil-Bosch
• @antres1
• @VamsiKrishna-max ]
• @shegazyy

Minutes:

• State of New configuration schema for Launch Manager lifecycle#88 was discussed.
  • There is general agreement that this PR represent the first version of the configuration and can be merged.
• Mb add mocks for unit testing lifecycle#78
  • This API is already actively used in other teams
  • There is problem with license check --> this will be investigated by @ramceb
  • The question about splitting of bazel targets was discussed
    • This is answered here: Mb add mocks for unit testing lifecycle#78 (comment)
  • @S-MOHAMD will look at this PR and it should be merged as soon as possible.
• Configuration description for Launch Manager lifecycle#54
  • This PR outlived its usefulness.
  • It will be dropped when PR 88 is merged and schema doc is provided
    • To preserve the info we have in this PR
• ITF integration lifecycle#75
  • This is review from ETAS side, @ramceb will review from S-CORE side
• hmon: add C++ interface to heartbeat monitor lifecycle#72
  • @NicolasFussberger or @SimonKozik will try to do review
• hmon: add heartbeat monitor lifecycle#67
  • @NicolasFussberger or @SimonKozik will try to do review
• Implementing report running state in lifecycle manager lifecycle#55
  • @NicolasFussberger reviewed this PR
  • @ramceb will approve and merge
• Schema roadmap
  • The existing schema is quite powerful
  • Further development of the schema should driven by user needs

Meeting minutes review:

• Minutes reviewed and accepted.

[ramceb]

2026-03-11

[SimonKozik]

Agenda proposal

• Migrate lifecycle showcase to new launch manager configuration reference_integration#181
• Planning for the 0.7 release (21 or 23 April 2026)

Participants:

• @arkjedrz
• @S-MOHAMD
• @NicolasFussberger
• @shegazyy
• @odra
• @basheerFZ
• @schaudhary
• @FScholPer

Minutes:

• Migrate lifecycle showcase to new launch manager configuration reference_integration#181
  • Example applications configuration was translated to the new configuration schema.
  • At the moment we only implement the translation layer, implementation stay unchanged for now.
    • This will change in the future.
  • This PR is in draft status because it depends on PR implement reusable workflows for module integration testing reference_integration#75
    • Those two PRs touch the same files.
  • @FScholPer proposes to first merge Migrate lifecycle showcase to new launch manager configuration reference_integration#181
    • There is no objections to this proposal.
• lifecycle: Add exception handling for CPU affinity lifecycle#113
  • At the moment this PR doesn't look like a proper fix.
  • A proper fix would include changes to OS abstraction layer.
  • @FScholPer will ask in comment about the status of this PR. At the moment it is draft.
• Cleanup and document file descriptor usage in launch manager lifecycle#109
  • @FScholPer will try to approve
  • Need to double check with @eelcoem if his comments were addressed.
• There was proposal on slack to introduce new role of a code owner.
  • After discussion we concluded that currently we don't see a need for such a role.
• Planning for the 0.7 release (21 or 23 April 2026).
  • At the moment we plan release for CW17 (Tuesday or Thursday).
  • Scope of the release?
    • Configuration concept lifecycle#38
    • [HmLib] C++ Logical Monitor API lifecycle#16
    • [HmLib] Rust Logical Monitor API lifecycle#15
    • Create basic test suite based in s-core integration test framework. #2320
    • @pawelrutkaq will clarify status of Health Monitoring library lifecycle#10
      • @arkjedrz will ping Pawel to look in to this.
  • Who will be responsible for the release of lifecycle?
    • The proposal will be to open a PR for lifecycle and we should have somebody responsible for merging this PR.
      • This proposal originated from this discussion https://github.com/orgs/eclipse-score/discussions/1595#discussioncomment-15998223
    • Discussion was shifted to the next meeting.

Meeting minutes review:

• Minutes reviewed and agreed @11:08 CET

[ramceb]

2026-03-18

status of eclipse-score/lifecycle#10

Status is documented in the issue. @pawelrutkaq is tracking the implementation.

Migration of IPC mechanism to score solution

We should replace the existing ipc solution with either message_passing or mw::com.
We need a solution with a rust binding.
Option A: Use mw::com (already has a rust binding)
Option B: Implement rust binding for message_passing.
@ramceb to check with com guys.

• 1:n communication
• static connection, no discovery mechanism needed.
• event driven communication.
• small pyload
• high frequency.

Open PRs

Open Reviews

• Launch Manager supports the new configuration format lifecycle#110 <-- LM Supporting new configuration @pawelrutkaq
• Schema documentation lifecycle#114 <-- Configuration documentation @ramceb

Missing support of aarch64_linux_platform in rust_toolchain

Target is to enable it for score 0.7

[SimonKozik]

Agenda proposal:

• We need to decide who will be responsible for releases on the lifecycle side.

[ramceb]

2026-03-25

Agenda

-We need to decide who will be responsible for releases on the lifecycle side

Migration of IPC mechanism to score solution

We should replace the existing ipc solution with either message_passing or mw::com.
We need a solution with a rust binding.
Option A: Use mw::com (already has a rust binding)
Option B: Implement rust binding for message_passing.

How to continue: eclipse-score/lifecycle#75

[SimonKozik]

I would suggest to add eclipse-score/lifecycle#124 to the Agenda

[NicolasFussberger]

One more topic to be discussed is the slightly confusing naming we have in the repo and the availability of APIs for C++ and Rust.
This diagram gives an overview:

Topics for discussion would be:
Naming Confusion

• What is part of the Lifecycle HealthMonitor component? Only the health_monitoring_lib or also the launch_manager part for alive supervision (currently called HealthMonitor)?
• Possibly rename the HealthMonitor subcomponent within LaunchManager to avoid confusion
• Rename the lifecycle_client (launch_manager internal API) to something else
• Do we want to follow a naming pattern for cc and rust version of the same library target?

API Visibility

• Make Monitor API private
• Make LifecycleClient private (leave rust API public, as we have nothing else at the moment)

Availability of APIs for C++ and Rust

• Decide on rust interface for Lifecycle API (currently not available)
• Decide on rust interface for Control Client

[pawelrutkaq]

Good point!

[SimonKozik]

Agenda:

• We need to decide who will be responsible for releases on the lifecycle side
• Migration of IPC mechanism to score solution
• ITF integration lifecycle#75
• docs: update to supported formats lifecycle#124
• Names for APIs and libraries of the Lifecycle

Participants:

• @SimonKozik
• @pawelrutkaq
• @NicolasFussberger
• @odra
• @basheerFZ
• @jaakkoaho
• @MaciejKaszynski
• Uwe Martin (AVL)
• Hari Babu Sannapaneni (L&T)

Minutes:

• We need to decide who will be responsible for releases on the lifecycle side.
  • Following people volunteer: @NicolasFussberger and @pawelrutkaq.
• Migration of IPC mechanism to score solution.
  • Assessment criteria that we could use:
    • Some of the LM APIs are probably security relevant. So how easy it will be to limit the access with new IPC. We are talking mostly about configuration effort probably.
    • We will need communication with most of the processes that are started by LM. So scalability is important for us.
  • Proposed next step --> a breakout session with COM team.
    • https://sdvworkinggroup.slack.com/archives/C08C0JATADP/p1774430374626029
• ITF integration lifecycle#75
  • PR for QNX images is still dragging on.
    • Proposal will be to the solution we have in the PR (no changes).
    • Change needed to use QNX OS images will not be a huge change, so we can do that later.
  • Is this PR urgent or we can wait and incorporate potential changes on this PR?
    • It will be nice to get test environment working.
  • Version of ITF that we should use should be taken from reference integration repo.
    • Reference integration is pinpointed to a specific commit hash. This is what we should use in our repo as well.
    • This is probably not the ideal solution. Maybe tags should be used...
  • Decision is documented here: ITF integration lifecycle#75 (comment)
    • We decided to remove the qnx support as of now and go ahead with merging the PR.
    • We add back the qnx support using os_images once ready.
• docs: update to supported formats lifecycle#124
  • It could be difficult to use PlantUML for anything but very simple diagrams.
    • For example see https://github.com/etas-contrib/score_lifecycle/blob/feature/schema_documentation/src/launch_manager_daemon/config/config_schema/docs/images/example_conf_graph.svg
  • There is general agreement that PlantUML cannot fulfill all our needs.
    • If something is hard to achieve then we should use drawio + svg format.
  • @jaakkoaho will try to check if he can migrate the drawings to PlantUML.
• Names for APIs and libraries of the Lifecycle.
  • There is a clear agreement that we should tackle this topic.
  • There is a discussion which APIs are public and which ones are Lifecycle internal...
  • @NicolasFussberger will create a story for this topic and we will start working on it.
    • The public API of Rust and C++ should be the same (if possible).
      • Reason: applications should follow the same patterns as much as possible.
      • There is question if current application API is fitting Rust language very well.
  • Topic will be discussed on the ticket.

Meeting minutes review:

• Meeting minutes reviewed and accepted at 11:09 CET

[ramceb]

2026-04-01

Participants:

• @ramceb
• @NicolasFussberger
• @odra
• @antres1
• @SimonKozik
• @S-MOHAMD

Agenda:

• Naming convention recap
• Open PRs

Minutes:

• Naming convention recap
  • At the moment we did not yet taken a decision about naming convention.
  • This is meant to be discussed in this issue: Align naming&visibility of APIs and libraries lifecycle#137
  • When we are working on this task, we should also restrict the visibility of some of lifecycle targets.
    • In general bazel targets intended for use inside our build system should not be exported / available outside of lifecycle repo.
  • There is preference to use AliveMonitor as the name for the health monitoring part of LM.
  • There is discussion about current architecture of the health monitoring library.
    • There is potential discussion on changing the health monitoring library.
    • The idea will be to remove alive supervision form the library and application would need to use LM API directly.
      • Instead of removing this from library, we should provide alternative way of using alive monitoring from LM directly.
    • Maybe we should list the use cases that we support in S-CORE and shortly describe how user can use them.
      • We should have some documentation on how application / end user choose which alive supervision to use.
  • We briefly discussed which APIs should be public and which private.
    • Looks like we should start documenting our public APIs.
    • At the moment this is chaotic, so we should follow up the right naming convention (aka C++ namespace).
  • Looks like our bazel targets should also be renamed...
    • At the moment bazel targets names feels a bit arbitrary and often depends on the order of development.
      • So first target will have and then second target will be _cc or _rust.
    • There is suggestion that we should follow base libs naming convention.
      • There is no objection to this proposal, so it's accepted.
  • There is discussion on how to rollout those changes.
    • Proposal will be to do this in few steps:
      • 1 Add aliases to the existing structure.
      • 2 Deprecate old things.
      • 3 Remove elements marked as deprecated after few releases.
• There was discussion on how to move documentation from S-CORE repo to lifecycle repo
  • @ramceb will create a proposal for this.

Meeting minutes review:

• Minutes reviewed and accepted at 11:09 CEST

[ramceb]

Here is the link to bazel deprecation messages

[pawelrutkaq]

To the points:

There is discussion about current architecture of the health monitoring library.
There is potential discussion on changing the health monitoring library.
The idea will be to remove alive supervision form the library and application would need to use LM API directly.
Instead of removing this from library, we should provide alternative way of using alive monitoring from LM directly.
Maybe we should list the use cases that we support in S-CORE and shortly describe how user can use them.
We should have some documentation on how application / end user choose which alive supervision to use.

I would expect that we include lifecycle CFT in this discussion ;)

[NicolasFussberger]

Lets bring up the topic next time again. I think the meeting minutes could be misleading here. There is no change to the health monitoring library functionality that was discussed. The only thing clarified was that as per feature architecture, a "lightweight" application should have the ability to alternatively use the LaunchManagers Alive API (currently called "Monitor" API in the code) directly as per current plan. Therefore we shall not make the LaunchMangers Alive API a private bazel target.

[SimonKozik]

2026-08-05

Participants:

• @pawelrutkaq
• @aschemmel-tech
• @NemanjaTrifunovicRTRK
• @NicolasFussberger
• @SimonKozik
• @vec-HossamZidan
• @FScholPer
• @TimoSteuerwaldETAS
• @S-MOHAMD
• @ramceb

Agenda:

• Move lifecycle documentation to module lifecycle#374
• ASSAM update
• First version of new API for Launch Manager lifecycle#377
• Split RunTarget/Component config from LaunchManager config? lifecycle#396

Minutes:

• Move lifecycle documentation to module lifecycle#374
  • We are moving documentation to the right repo.
  • PR is ready for review.
  • There is not much changes, mostly a move.
  • @NicolasFussberger will do the review
  • In general there is duplication of the content at the feature level and component level...
    • There is brief discussion of what should be available at which level in this PR.
  • There is agreement that this PR should only do the move.
    • Removal of duplication in documentation and documentation improvements will be done on a different PR.
• ASSAM update
  • Multiple proposals were made from @FScholPer / lifecycle side, but this was rejected.
  • We are not sure how to incorporate this concept...
    • The lifecycle group is not sure about the daemon approach at the moment.
    • QNX implementation is planned or is in progress at the moment.
  • The plan is to invite people involved in ASSAM to our weekly telco and see how we can progress on the topic.
    • @FScholPer will take care of this.
• First version of new API for Launch Manager lifecycle#377
  • Comments should be resolved now.
    • It is true that API documentation is verbose, but this is on purpose.
  • The outstanding problem is about https://github.com/eclipse-score/lifecycle/pull/377/changes#r3672366970
    • The question is how to address this issue...
    • Maybe logging of component startup errors could be enough?
    • Or callback can be extended with extra data, but what that data could be?
  • The conclusion is, this PR should be merged now and @FScholPer will think how to introduce extra information to the callback.
    • This change will be done as a separate PR.
• Split RunTarget/Component config from LaunchManager config? lifecycle#396
  • We briefly discussed this last week.
  • In general we are trying to figure out how multiple LM configuration files could work.
  • General problem: some configuration should exist / been acted on just once.
    • For example what should happen if fallback_run_target is configured more than once.
  • The suggestion is to combine option 1 and 2, from the ticket.
    • Some pros and cons of the options were discussed, but there is no clear winner.
    • It could be because we don't have clear requirements / use cases, on how this should work from the end user perspective.
  • @ramceb and @FScholPer will add use cases to the ticket and we will discuss them next week.

Meeting minutes review:

• Meeting minutes will be reviewed offline.

[SimonKozik]

2026-08-12

Participants:

• @lavrovvalera
• @TimoSteuerwaldETAS
• @MaciejKaszynski
• @SimonKozik
• @ramceb

Agenda:

• Requirements clarification
• Split RunTarget/Component config from LaunchManager config? lifecycle#396

Minutes:

• Split RunTarget/Component config from LaunchManager config? lifecycle#396
  • At the moment there is an idea that each application should have its own config file..
    • Which would contain LM config for this application.
  • Those files are later combined into a single Run Target / Components configuration (aka database).
  • Daemon should have its own config file, this file is going to be separated from Run Target / Components configuration.
  • How many flatbuffer files we should have on the target machine?
    • Currently we would propose to have two files on target machine (one for daemon config and another for rest).
    • But this may change as the tooling use case will be clearer.
  • There is desire to have possibility to read json files, during development phase of the project.
    • In other words: during development json is preferred for frequent changes, but during production flatbuffer format is preferred.
  • More info is available here: Split RunTarget/Component config from LaunchManager config? lifecycle#396 (comment)
• Requirements clarification part 1
  • The feat_req__lifecycle__conditional_startup looks OK at the moment.
  • The comp_req__launch_man__cond_process_start this requirement is about dependency tree and the fact that a failed startup, stops Run Target activation.
  • comp_req__launch_man__total_wait_time_support this is fulfilled by ready timeout.
  • comp_req__launch_man__polling_interval this should be restricted to ready condition that wait for file.
  • comp_req__launch_man__validate_conditions this is about dependency tree.
  • comp_req__launch_man__env_variable_cond_check reject for now
  • A PR will follow to clarify this requirements.
• Requirements clarification part 2
  • comp_req__launch_man__process_input_output this is about a mechanism similar to piping concept in shell. This requirement should be probably postponed to the later version.
  • comp_req__launch_man__support_held_state we probably reject this requirement and say that this can be configured through env var or cli args.
  • comp_req__launch_man__configurable_timeout and comp_req__launch_man__time_to_wait_config are related and probably talking about one thing.
• Next steps regarding Recovery Action: ETAS internal concept document is used as basis for additional component requirements. Pull Request will be provided to discuss with others

Meeting minutes review:

• Meeting minutes will be reviewed offline.

[MaciejKaszynski]

Clarifications

feat_req__lifecycle__waitfor_support

Renamed to feat_req__lifecycle__conditional_startup.

Probably all component requirements about ready conditions shall link to this.

Current Text:

The :term:`Lifecycle Feature` shall provide launching processes based on conditions.

Keeps as is, this is generic for reason.

feat_req__lifecycle__cond_process_start

Renamed to comp_req__lifecycle__cond_process_start and then to comp_req__launch_man__cond_process_start.

Current Text:

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 <Process>`
executed before.

This is solved with our current implementation.
Components specify their ready condition and other components depend on these
components being ready.

feat_req__lifecycle__total_wait_time_support

Renamed to comp_req__lifecycle__total_wait_time_support and then to comp_req__launch_man__total_wait_time_support.

Original Text:

The :term:`Launch Manager` shall provide support for per condition configurable
total wait time for launch conditions to be satisfied.

Implemented with the config param run_target[].transition_timeout

feat_req__lifecycle__polling_interval

Renamed to comp_req__lifecycle__polling_interval and then to comp_req__launch_man__polling_interval.

Current Text:

The :term:`Launch Manager` shall provide support for per condition
configurable :term:`Polling Interval` for launch conditions to be checked.

This is actually specific to the given ready condition.
e.g. wait for file shall take polling time, waiting for process to terminate
shall not

Add another requirement for waiting for a file.

feat_req__lifecycle__validate_conditions

Renamed to comp_req__lifecycle__validate_conditions and then to comp_req__launch_man__validate_conditions.

Current Text:

The :term:`Launch Manager` shall be able to validate the pre-start conditions
of the executable using the conditions.

This is solved with our current implementation.
Components specify their ready condition and other components depend on these
components being ready.

feat_req__lifecycle__validation_conditions

Renamed to comp_req__lifecycle__validation_conditions and then to comp_req__launch_man__validation_conditions.

Current Text:

The :term:`Launch Manager` shall be able to validate the start of the executable using the conditions.

This is the ready condition.
Delete.

feat_req__lifecycle__env_variable_cond_check

Renamed to comp_req__lifecycle__env_variable_cond_check and then to comp_req__launch_man__env_variable_cond_check.

Current Text:

The :term:`Launch Manager` shall provide a method for condition check for environment variable.

Currently reject this and the user shall touch a file and use the wait for file
ready condition instead.
Need a usecase to consider if this is useful.

[SimonKozik]

2026-08-19

Participants:

@MaciejKaszynski
@NicolasFussberger
@aschemmel-tech
@pawelrutkaq

Agenda:

• Repo structure, sync from project level.

Minutes:

• Make an issue to remove the src dir.
  ** No strong opinions on this from the team. If the decision record goes through might as well do it.

Meeting minutes review:

[SimonKozik]

2026-08-26

Participants:

• @pawelrutkaq
• @lavrovvalera
• @odra
• @NicolasFussberger
• @SimonKozik

Agenda:

• Release v0.9 common checklist #3186
  • Things todo for the next release.

Minutes:

• Release v0.9 common checklist #3186
  • This check list was recently created recently by Piotr
  • At the moment it is not entirely clear what should be done for the renaming.
    • Or to be more precise, how this should be done...
    • The conclusion was to not change repo name, but only change the bazel module name
  • For llvmcov we have this PR: Introduce LLVM code coverage lifecycle#526
  • Last time we did our release last minute, but this time looks like other components depends on us.
    • So maybe we should release sooner.
    • However we could do renaming sooner, so other components can pull this change and give ourselves more time.
  • @NicolasFussberger will take look ate renaming.
  • @pawelrutkaq will take look at verification report.

Meeting minutes review:

• Minutes reviewed at 10:18 CEST

[SimonKozik]

2026-09-02

Participants:

• @TimoSteuerwaldETAS
• @lavrovvalera
• @MaciejKaszynski
• @SimonKozik
• @pawelrutkaq

Agenda:

• Requirement questions

Minutes:

• Requirement questions
  • Get rid of no longer needed component level requirements lifecycle#562
  • Add test for comp_req__launch_man__fast_shutdown_support lifecycle#573
  • It will be good to get review comments on those requirements.
    • @TimoSteuerwaldETAS will try to contact @aschemmel-tech for comments for PR 562
    • @lavrovvalera will have look at PR 573
  • There is question what fast shutdown means?
    • Does fast shutdown means SIGKILL?
    • There is question if test should relay on SIGKILL in our test or we need an extra functionality in LM.
  • Main questions are:
    • What is meant by fast shutdown.
    • How is the fast shutdown initiated.

Meeting minutes review:

• Minutes reviewed at 10:28 CEST

[SimonKozik]

2026-09-09

Participants:

• @TimoSteuerwaldETAS
• @ramceb
• @lavrovvalera
• @NicolasFussberger
• @SimonKozik
• @S-MOHAMD

Agenda:

• Alignment on documentation structure
• Requirements clarification:
  • https://eclipse-score.github.io/lifecycle/main/components/launch_manager/requirements/requirements.html#comp_req__launch_man__monitoring_processes
  • https://eclipse-score.github.io/lifecycle/main/components/launch_manager/requirements/requirements.html#comp_req__launch_man__drop_supervsion
  • https://eclipse-score.github.io/lifecycle/main/components/launch_manager/requirements/requirements.html#comp_req__launch_man__detach_parent_process
  • https://eclipse-score.github.io/lifecycle/main/components/launch_manager/requirements/requirements.html#comp_req__launch_man__fast_shutdown_support
  • See also PR here: Add test for comp_req__launch_man__fast_shutdown_support lifecycle#573

Minutes:

• Alignment on documentation structure
  • Recently we moved some content of the lifecycle documentation from s-core repo to the lifecycle repo.
  • Looks like this bring us closer to what other platform components are doing.
    • However there is still more work to be done.
  • We were discussing which technology we should use for diagrams.
    • Decision: we should use PlantUML for diagrams.
    • PlantUML looks simpler than the current solution.
• Requirements clarification:
  • comp_req__launch_man__monitoring_processes: The Launch Manager shall provide support for monitoring adopted Processes.
    • Use case: If there is a process that was started before Launch Manager, then Launch Manager should be able to monitor it.
    • At the moment it is recommended to defer this requirement to v2.0
    • @TimoSteuerwaldETAS will add use case to the requirement.
  • comp_req__launch_man__drop_supervsion: The Launch Manager shall provide support to dropping all surveillance and failure reaction activities of Processes.
    • Use case: If Launch Manager is shutting down, then it should be possible to allow some process to stay alive and continue execution without interruption.
    • At the moment it is recommended to defer this requirement to v2.0
    • @TimoSteuerwaldETAS will add use case to the requirement.
  • comp_req__launch_man__detach_parent_process: The Launch Manager shall provide support for launching a process to detach from parent.
    • There is discussion if this requirement is required or what is the functionality specified by this requirement.
      • The decision was that after daemon is started, parent sees the exit of that child process and further monitoring is not required.
    • Use case: Launch Manager should be able to start a process that performs demonization.
    • @TimoSteuerwaldETAS will add use case to the requirement.
  • comp_req__launch_man__fast_shutdown_support: The Launch Manager shall support fast shutdown by terminating itself without considering the started Processes.
    • It is unclear what is meant by fast shutdown...
      • For example this requirement can be implemented by sending SIGKILL to the Launch Manager.
    • Use case: Launch Manager should shutdown in a controlled manner, performing any clean up actions, but it should not request child processes termination.
    • At the moment it is recommended to defer this requirement to v2.0
    • @TimoSteuerwaldETAS will add use case to the requirement.

Meeting minutes review:

• Meeting minutes will be reviewed offline.

[SimonKozik]

2026-09-16

Participants:

• @TimoSteuerwaldETAS
• @aschemmel-tech
• @NicolasFussberger
• @SimonKozik
• @lavrovvalera
• @FScholPer
• @pawelrutkaq

Agenda:

• Clarify traceability from feature requirement to component requirement
  • We have multiple feature requirement that have no derived component requirement (see Clarify feature level requirement which have no derived component level requirement lifecycle#628)
• Roadmap for v0.10
• Split requirement and also clarify it:
  • comp_req__launch_man__process_failure_react:
    • What is the usecase of "stopping the process and starting another process"? Is this some kind of alias for switching to another run target?
    • We would like to split this requirement, to partly ("triggering QNX Operating System Device Safe State (DSS)") move this to version 2.0 via "valid_from:" clause
• Clarify if FEP is needed: Incrementing version for features not planned for lcm v1 #3249
• Clarify requirements related to "Conditional Launching":
  • comp_req__launch_man__cond_process_start
  • comp_req__launch_man__polling_interval
  • comp_req__launch_man__validate_conditions
  • comp_req__launch_man__validation_conditions
  • comp_req__launch_man__condition_check_method
  • comp_req__launch_man__total_wait_time_support: Same as ready_timeout?
  • comp_req__launch_man__launcher_status_storage: Launch Manager must be capable to store process status, to be sure run graph is in consistent condition. Do we need a requirement for that?
  • To be continued...

Minutes:

• Clarify traceability from feature requirement to component requirement
  • At the moment some of the feature level requirements (for the lifecycle feature), do not have component requirements. Is this OK or not.
  • There is suggestion that if a feature level requirement do not have component requirements derived, then it is a candidate for component level requirement.
  • Unit tests can only be linked to component requirements (not feature requirement).
  • In theory all feature requirement should have component requirement linked / derived.
  • Feature level requirements should be high level requirements.
    • Probably an API level of abstraction requirements.
    • Or user observable requirements.
  • Agreement is as follow:
    • We either add component level requirement that map to the feature level requirement.
    • Or we demote feature level requirement to a component level requirement if this make sense.
  • @TimoSteuerwaldETAS and @aschemmel-tech will work on this.
• comp_req__launch_man__process_failure_react is too big.
  • The 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 QNX Operating System Device Safe State (DSS).
    • This requirement is also not atomic.
  • The proposal will be to split this requirement.
    • There is general agreement that this requirement should be split.
    • Maybe some sequence diagrams could help to figure out what smaller requirements should be.
  • @TimoSteuerwaldETAS will try to came up with a proposal on how to split this requirement.
  • Additionally there is question if this requirement applies to health / watchdog monitoring or just existence monitoring at LM level
    • The answer is, it applies to both...
      • So split is urgently needed.
• Roadmap for v0.10
  • S-CORE Roadmap
  • Do we have v0.10 planned?
  • https://eclipse-score.github.io/reference_integration/main/s_core_v_1/roadmap/pi3.html
  • Looks like the v0.10 release is not planned
    • Who should be responsible for release planning of our feature?
    • @SimonKozik will try to do this
      • The planned release date 8 September – 2 November 2026
  • What about SCA rules?
    • https://github.com/eclipse-score/lifecycle/actions/workflows/github-code-scanning/codeql
    • Looks like scans are currently disabled...
      • But some results are available: https://github.com/eclipse-score/reference_integration/actions/runs/34458977936
• Incrementing version for features not planned for lcm v1 #3249
  • The FEP is something that is not yet very well understand in our group
    • https://eclipse-score.github.io/score/main/platform_management_plan/change_management.html#the-fep-track
    • There is general feeling that we need some guidance here.
  • Current proposal will be to change status from valid to invalid (for the requirements in PR) and leave version at v1.0.0
    • We should add comment that says all requirement that are in invalid state are set to this state because, they are unplanned for v1.0.0 and at the moment it is unclear in which version they will be considered / planned.
• @FScholPer is working on AI automation.
  • If somebody has a candidate for automation pls ping Frank.

Meeting minutes review:

• Meeting minutes will be reviewed offline.

[SimonKozik]

2026-09-23

Participants:

• @TimoSteuerwaldETAS
• @MaciejKaszynski
• @NicolasFussberger
• @S-MOHAMD
• @SimonKozik
• @FScholPer

Agenda:

• Clarify requirements related to "Conditional Launching": (leftover from 2026-09-16)
  • comp_req__launch_man__cond_process_start
  • comp_req__launch_man__polling_interval
  • comp_req__launch_man__validate_conditions
  • comp_req__launch_man__validation_conditions
  • comp_req__launch_man__condition_check_method
  • comp_req__launch_man__total_wait_time_support: Same as ready_timeout?
  • comp_req__launch_man__launcher_status_storage: Launch Manager must be capable to store process status, to be sure run graph is in consistent condition. Do we need a requirement for that?
• PRs which needs some attention:
  • Agreed component requirement split-up and set to state invalid for component requirements not planned in 1.0: Requirement rephrasing and split-up lifecycle#647
  • Feature requirements not planned in 1.0 set to state invalid: Incrementing version for features not planned for lcm v1 #3249
    • TBC: Should these features still have a valid_from field?
• Clarify feat_req__lifecycle__smart_watchdog_config feature requirement: What is a "smart Watchdog"?
• Who is defining the component requirements for the health monitor?
• Clarify ready condition requirements Ready condition reqs reword lifecycle#687

Minutes:

• Since we are using valid status for accepted and planned requirements and invalid status for unclear and unplanned requirements, there is feeling that we are squashing few things into one field.
  • There is a question if it will be beneficial if we have more possibilities for the status (for example accepted, rejected, unplanned).
  • There is also valid from field, but it is not used at the moment.
    • We are not sure how useful this field is going to be. Users usually looks at releases / tags and in that case status field clearly indicates what is valid and what is invalid in this release.
  • Some extra info can be found here: https://eclipse-score.github.io/process_description/main/process_areas/requirements_engineering/requirements_concept.html
• Looks like some of the requirements on the agenda were cleaned / removed by this PR: Changing ready condition reqs lifecycle#467
• https://eclipse-score.github.io/lifecycle/main/components/launch_manager/requirements/requirements.html#comp_req__launch_man__condition_check_method
  • Condition check based on status
  • There is a question if comp_req__launch_man__conf_of_comp_ready_cond is a potential replacement for comp_req__launch_man__condition_check_method?
  • We probably should link from ready_condition in configuration schema to comp_req__launch_man__conf_of_comp_ready_cond
  • Proposal: we should remove comp_req__launch_man__condition_check_method as a duplicate of comp_req__launch_man__conf_of_comp_ready_cond
• https://eclipse-score.github.io/lifecycle/main/components/launch_manager/requirements/requirements.html#comp_req__launch_man__launcher_status_storage
  • Launched Process status
  • This requirement sounds like a detail design and not really a requirement.
  • Do we have an interface / API to retrieve this information form Launch Manager
    • In other words: is this information observable from user perspective.
    • Looks like we have feat_req__lifecycle__query_commands
      • The :term:Lifecycle Feature shall provide support for commands to query component states.
  • Proposal: remove comp_req__launch_man__launcher_status_storage and create github issue to provide means to recover from Launch Manager crash.
• Requirement rephrasing and split-up lifecycle#647
  • There are questions about comp_req__launch_man__recovery_relaunch and comp_req__launch_man__recovery_stop
  • There is comment that acting on a single component risk endangering Run Target semantics...
    • For example a component crashes after a successful Run Target activation. If we just stop this component, then what that means for Run Target?
      • There are some voices saying there may be no use case for this...
      • Other voices are saying that this may be useful and desired...
        • So there is no consensus at the moment.
      • If components start crashing and we simply stop components, where is the tipping point at which we should react and switch Run Target?
  • Proposal is to set at least comp_req__launch_man__recovery_stop to invalid
• Plan for v0.10
  • Lifecycle for S-CORE Release v0.10 #3050
  • Scope was presented by @S-MOHAMD
  • There is question what is the feature set targeted for v1.0
    • @TimoSteuerwaldETAS and @MaciejKaszynski are driving this discussion with requirements clarification.

Meeting minutes review:

• Meeting minutes will be reviewed offline.

[SimonKozik]

2026-09-30

Participants:

• @S-MOHAMD
• @aschemmel-tech
• @NicolasFussberger
• Rudolf Lindl
• @ramceb
• @TimoSteuerwaldETAS
• @SimonKozik
• @FScholPer

Agenda:

• Integration feedback from Rudolf
• Feature Architecture Improvements lifecycle#720
• From 2026-09-23:
  • Clarify https://eclipse-score.github.io/score/main/features/lifecycle/requirements/index.html#feat_req__lifecycle__smart_watchdog_config feature requirement: What is a "smart Watchdog"?
  • Clarify https://eclipse-score.github.io/lifecycle/main/components/launch_manager/requirements/requirements.html#comp_req__launch_man__ext_monitor_notify component requirement: What is an "external monitor"?
  • Who is defining the component requirements for the health monitor?

Minutes:

• BMW integrated lifecycle feature into their protype project.
  • AUTOSAR Execution Manager was replaced with S-CORE Launch Manager (including Health Monitor).
  • In general integration was not too difficult.
  • There is question when supervision should start.
    • This is especially important during platform boot sequence (when the load on CPU is strong) and checkpoint reporting could be not reliable.
    • In S-CORE alive supervision starts / being enforced after reporting running.
      • Conclusion: to check if running is not reported too early in application.
    • Few patches had to be applied.
      • GitHub issue / PR will be created to bring the changes to the community.
  • General remarks:
    • Debugging of startup issues can be difficult. Going through the logs is sometimes confusing.
    • All S-CORE components should integrate with Launch Manager.
      • They should report to LM when they finished initialization.
        • This is needed for startup ordering / dependency definition.
    • There is no apparent functionality gaps in lifecycle at the moment.
    • On one hand, having entire launch manager configuration in one file is easier to keep overview, but deploying it to the target is a bit difficult.
      • You need to compile flatbuffers and then deploy them, which is a bit difficult / slow when you prototyping.
      • Maybe S-CORE could make prototyping use case a bit easier.
      • It is worth to note that, the current approach with a single config is liked, despite its drawbacks.
        • It will be good if json file could be consumed on ECU, it will allow config changes on ECU without build system involvement.
• Feature Architecture Improvements lifecycle#720
  • For the release gate we have multiple check lists that we should do.
    • Unfortunately not everything is clear there.
    • There is question how to improve https://eclipse-score.github.io/lifecycle/main/features/lifecycle/architecture/alive.html#feat_arc_dyn__lifecycle__alive_monitor sequence diagram.
      • @NicolasFussberger will change it as discussed.
    • Looks like the feature interface definitions needs to be extended / adapted, so the sequence diagrams could be extended and be more accurate.
    • We still have uncertainty what documentation should go into the feature level and what should go at the component level.

Meeting minutes review:

• Meeting minutes will be reviewed offline.

[SimonKozik]

2026-10-07

Participants:

• @aschemmel-tech
• @S-MOHAMD
• @NicolasFussberger
• @SimonKozik
• @FScholPer
• @pawelrutkaq

Agenda:

• Spillover from previous meeting:
  • Clarify https://eclipse-score.github.io/score/main/features/lifecycle/requirements/index.html#feat_req__lifecycle__smart_watchdog_config feature requirement: What is a "smart Watchdog"?
  • Clarify https://eclipse-score.github.io/lifecycle/main/components/launch_manager/requirements/requirements.html#comp_req__launch_man__ext_monitor_notify component requirement: What is an "external monitor"? Is a watchdog or the health monitor library meant by that?
  • Clarify https://eclipse-score.github.io/lifecycle/main/components/launch_manager/requirements/requirements.html#comp_req__launch_man__stop_order_spec component requirement: What is the use case?
  • Who is defining the component requirements for the health monitor?
• Move feature requirements to component requirements (link to github issue):
  • PR for SCore-Repo: Feature requirements clarification for lifecycle #3281
  • PR for Lifecycle-Repo: Feature requirements clarification for lifecycle lifecycle#718
• Clarify intended "Normal Shutdown" behaviour of Launch Manager (in contrast to "Fast Shutdown")
• Feedback about collapsing the ready_recovery_action and recovery_action configuration options into a single recovery_action configuration. The difference between these recovery actions gets ambiguous if Ready Condition other than Running state is used.
• Who is defining the component requirements for the health monitor?

Minutes:

• PR for SCore-Repo: Feature requirements clarification for lifecycle #3281
  • This is merged now, so no point discussing this.
• Clarify https://eclipse-score.github.io/score/main/features/lifecycle/requirements/index.html#feat_req__lifecycle__smart_watchdog_config
  • What is a "smart Watchdog"?
  • Looks like nobody knows what is the smart watchdog...
  • Since this requirement is not valid for v1.0.0 we are removing this topic from agenda.
• Clarify https://eclipse-score.github.io/lifecycle/main/components/launch_manager/requirements/requirements.html#comp_req__launch_man__ext_monitor_notify
• Usually external means external hardware.
  • Or a software running on a separate SoC.
• Is this a valid suggestion in S-CORE context?
  • Can this be an external process.
• There are different opinions if external means a separate hardware / SoC or just a separate address space i.e. different process inside the same OS instance.
• Decision: It is agreed that Launch Manager should have an interface, that allows a connection to either an external hardware / process on a separate SoC or to an external process on the same OS.
  • Where this is connected is out of the scope of S-CORE, as this is project decision.
  • Requirement should be reformulated to reflect this.
  • @NicolasFussberger will look into this.
• What is the use case for https://eclipse-score.github.io/lifecycle/main/components/launch_manager/requirements/requirements.html#comp_req__launch_man__stop_order_spec ?
  • As far as we know, there is no similar requirement for startup order.
  • @aschemmel-tech will ask @ramceb if he knows an use case.
  • Additionally status of this requirement should be set to invalid. This is due to the fact that it is not implemented so far and it is too late to implement this for v1.0.0
    • @NicolasFussberger will set this requirement to invalid.
• Who is defining the component requirements for the health monitor?
  • At the moment we don't have component requirements for health monitoring.
  • As we are trying to fulfill quality metrics, we need to pick up some tasks on the health monitoring.
  • @pawelrutkaq will look into this.
• Current release introduced checklist...
  • It will beneficial if safety manager could help us understand what exactly should be done
  • @aschemmel-tech is available on Thursday from 10:30 - 12:00 CEST
    • @aschemmel-tech will invite for 1h meeting (@NicolasFussberger, @S-MOHAMD)
• Feature requirements clarification for lifecycle lifecycle#718
  • This is just for information, no action needed from participants of this meeting.
• Clarify intended "Normal Shutdown" behavior of Launch Manager (in contrast to "Fast Shutdown")
  • In the mean time, the meaning is a bit more clearer
  • Normal shutdown:
    • Graceful termination of all child processes, then Launch Manager exits.
  • Fast Shutdown:
    • Launch Manager just exits and leaves orphaned children behind.
  • Real question: how would you arrange OS shutdown, using Launch Manager
    • This is needed to be documented in feature / component architecture.
  • Current shutdown sequence starts from SIGTERM, which is send to Launch Manager
    • This is good enough for now.
    • In the future we may need a better defined shutdown sequence for LM.
• The Feature requirements clarification for lifecycle #3281 introduced a docu build error
  • @NicolasFussberger will have look into this.

Meeting minutes review:

• Meeting minutes will be reviewed offline.

[SimonKozik]

2026-10-14

Participants:

• @TimoSteuerwaldETAS
• @aschemmel-tech
• @MaciejKaszynski
• @NicolasFussberger
• @S-MOHAMD
• @SimonKozik
• @ramceb
• @pawelrutkaq

Agenda:

• Recovery actions
  • Proposed behavior:
  • Shall LM SIGKILL processes that are misreporting alive notifications?
  • Shall we remove ready_recovery_action?
• Add description to lifecycle arch elements #3317

Minutes:

• Add description to lifecycle arch elements #3317
  • @aschemmel-tech will have look
• Recovery actions
  • Draft proposal is shown in the attached picture.
  • Any Component failure during Run Target activation, is a Run Target activation failure.
  • If Run Target is already activated you have chance to recover Component or recover the run target.
  • If a recovery action fails, then there is an escalation path up to the watchdog.
  • It looks complicated, but the question is what alternative could looks like.
  • If we try to shift some of this complexity / decision making from LM to State Manager, then we are putting mw::com on the critical path...
    • If mw::com goes down, then it may bring entire machine down.
    • Currently it feels like leaving full recovery action inside LM, creates a bit more robust system.
  • One simplification which we could do, will be to route failure from Component recovery action directly to Fallback Run Target.
    • This will force users to put Component recovery action into one of two buckets:
      • Components recovers with the Run Target.
      • Component has an individual recovery path.
  • In general current picture doesn't look too complicated
    • There is some potential for simplification, but this will not result in huge change.
  • The version for v1.0.0 was discussed and is attached here: https://github.com/orgs/eclipse-score/discussions/2386#discussioncomment-18920227
• Shall LM SIGKILL processes that are misreporting alive notifications?
  • The question is: shall we first send SIGTERM and give the Component a grace period (the exit timeout).
  • We don't know in which state Component is...
    • It could be the case that if Component gets extra time, it may create more damage to the running system
  • However if we are debugging a system, it may be useful to give the Component a chance to write down some logs and exit.
  • For simplicity we send SIGKILL straight away.
    • If graceful termination is needed, then this can be added after v1.0.0
• Shall we remove ready_recovery_action?
  • This can be a robustness issue...
  • The usage was seen in real life
    • For example network connection was not established in time and second startup attempt could be successful
    • Or a file was not created in time
  • One possibility could be to keep it and rename it, to not introduce confusion in recovery action diagram.

Meeting minutes review:

• Meeting minutes will be reviewed offline.

[MaciejKaszynski]

the simplified diagram for v1

[SimonKozik]

2026-10-21

Participants:

• @pawelrutkaq
• @TimoSteuerwaldETAS
• @SimonKozik
• @MaciejKaszynski

Agenda:

• No topics

Minutes:

• There is not topics for discussion, meeting is finished early.

Meeting minutes review:

• Meeting minutes will be reviewed offline.

[SimonKozik]

2026-10-28

Participants:

Agenda:

Minutes:

Meeting minutes review:

[SimonKozik]

2026-11-04

Participants:

Agenda:

Minutes:

Meeting minutes review:

[SimonKozik]

2026-11-11

Participants:

Agenda:

Minutes:

Meeting minutes review: