[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]

Agenda proposal for 2026-02-25

• Roadmap for providing unit tests and mocks
  • Topic moved from 2026-02-18 (still waiting for extra information)
• Safety qualification of Health Monitoring library
  • We will go into more details that today (2026-02-18)

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