[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

[ramceb]

2026-03-18

[ramceb]

2026-03-25

[ramceb]

2026-04-01

[ramceb]

2026-04-08

[ramceb]

2026-04-15