Time FT Meeting Minutes 2026

[lavrovvalera]

2026-02-27 Weekly

Location

Online via zoom: link to the meeting

Participants

@lavrovvalera
@umaucher
@mikehaller
@FScholPer
@BlueXMarv3l
@BjoernAtBosch

Meeting Minutes

Feature Team Lead

• Mondays tech syncs
• Moderating and managing the release
• -> @lavrovvalera

Planning

• Which dashboard to use?
  • it is available here: https://github.com/orgs/eclipse-score/projects/32

PR merging/integrating

• merge the exisiting PRs and then consider others (?)
• requirements
  • how does each pitch cover the requirements
  • Do we need to adjust the requirements
• ASIL label
  • do we need ASIL-B?
• How the PRs could be integrated, more detailed analysis, more "detailed" table -> @mikehaller
• BMW code will be published till 02.03 in bmw score::time pitch inc_time#6
• need to decide the Apps APIs -> also need to consider the needed APIs (except the Now)
• we could consider the discusions from 4 comnponents (create tickets:
  • Define Applications API
  • Needs to consider several use cases. Need some sketch and so on.
  • Passive Now and Notifications API
  • Collect relevant use cases
• Need co consider all artifacts, which are needed for the certification
• shall everything be part of the 1.0 release or split somehow?

System architecture

• Is it QNX * Hyp?
  • QNX8
• Discussion with com
  • the ipc between host and guests -> @mikehaller
• HW support
  • Assumption of use
  • Customisations support
  • could we agree on QNX * Qualcomm?
    • There are many vendors, but Qualcomm wanted to support
  • Discuss with Qualcomm about their support -> @FScholPer
  • ECARX suggested to make the verification for stack on their reference platform. The VPN access to the HW could be provided to the team.

The repo template was updated

• the src -> score (or something)
• template needs to be updated
• need to consider this point as additional efforts (without immediate actions)

Agenda for 05.03

• Decide the next step integration based on the source code (merge strategy)
• Prepare the SAD sketch to visualize the components, responsibilities, which could be used as base to make decisions.
  • -> @lavrovvalera
• Cross-check the SCORE requirements towards tooling (bazel/docascode/license check/...)
  • cpp toolchain to be used
  • need to cross check, that the source code should be built with the new toolchains, so that SCORE env is being used and prepared

[lavrovvalera]

2026-03-06 Weekly

Location

Online via zoom: link to the meeting

Participants

@lavrovvalera
@mikehaller
@anmittag
@BjoernAtBosch
@FScholPer
@gordon9901
Matthias Schulze
peng.zhu@ecarx
pengcaho.zhu
@BlueXMarv3l
@mwx2015

Meeting Minutes

ETAS made the AI-based approach analysis of the 3 pitches.

• S-CORE TIME comparison 2026-03-05 draft.pdf
• AI summary
• manual results aggregation
• review with 4 eyes the report
• results are in the presentation
• BMW is it copy-pasted or done from scratch?
  • score::time interfaces - from production, the rest is done from scratch
• ECARX updated the pitch with some design documents. Part is already in the PR, on the next weekend some design update will come
• ETAS has the large code basein C and a bit cpp17
• Approaches
  1. use BMW as base, cherry pick the ETAS and ECARY on the top
     • API discussions? go to AUTOSAR style or not?
     • What else needs to be done to get it release ready and how long will it take
  2. use ETAS as a base, which should be ready to next SCORE release
     • after this needs to make it nicer. which could be done after the first integration
  3. use ECARX as a base - hard to estimate of the production readiness, some open questions there.
     • mainly rely on performance increase
  4. base on BMW design and fill the components from the different pitches

• Decision

  • ETAS agreed to merge the BMW pitch as base
  • ECARX agreed to merge the BMW pitch as base
  • BMW agreed to merge the BMW pitch as base

• Points

  • What is our target
    • Earlier availability or long term having the best maintainable architecture
      • Agreed on the long term best solution
  • How far do we want to go away from AUTOSAR interfaces?
    • not everybody use the full AUTOSAR interfaces
    • @FScholPer will take a look, in which direction they have implemented it
  • Need to start with APIs and their stubs
  • Requirements coverage
    • main coverage is on the ETAS and on ECARX
    • priority is on the VehicleTime and possibility to scale
  • Create an issue: to bring the BMW to buildable and merge it
    • then define next step -> tickets will be created
    • The rest PRs to close the PR
      • ETAS: in case of needed further adaptations, the new PRs will be opened, code will be copied there with adaptations needed
    • API discussion (#2659):
      • needs a breakout session
    • TimeSlave (#2660)
      • ECARX has it
      • need to evaluate the integration
    • Verification
      • put to the backlog

[lavrovvalera]

2026-03-13 Weekly

Location

Online via zoom: link to the meeting

Participants

@lavrovvalera
An
@BjoernAtBosch
@FScholPer
@gordon9901
Matthias Schulze
pengcaho.zhu
@BlueXMarv3l
@mwx2015

Meeting Minutes

• The BMW PR (bmw score::time pitch inc_time#6) is merged
• Do we need to rename the repo or create the new one?
  • Need to catch up the best practice in the score -> @lavrovvalera
  • Need to find an answer, when the repo should indeed be transferred to the regular modules. -> Shall it be already released to be part of the "normal modules list" or just initial status is enough
  • Within the "normal" module, also all safety processes shall be applied. Suggestion is to work still in inc_repo until fulfilling most of the functional requirements
• Why do we need HighPrecisionLocalSteadyClock interface
  • to work with asil-b ClockCycles
  • to be able to mock the interface and use in the unit and component tests
• There should be also created a new interfaces for absolute time in score/time
  • @lavrovvalera -> create a ticket in the backlog: Improvement: Add Absolute Time support #2690
• Existing APIs in score/time/svt looks like should be fisible enough for the moment. Further discussions might be needed
  • AUTOSAR provides several time bases support. For us svt + abs time (wallclock/realtime/sdat) would be enough for the moment
  • Decision: we can stick to the provided APIs
• The rate deviation between GM and local clock
  • TimeSlave shall somehow adjust the rate and clock value of the local clock
  • That shall be somehow be reflected in the requirements
• TimeSlave
  • ECARX could support here and prepare the TimeSlave -> @BlueXMarv3l , @lavrovvalera -> create a ticket: https://github.com/eclipse-score/score/issues/2691
  • the ptp_machine module could be extended with the library to communicate with the TimeSlave process
  • TimeSlave could not be make the ASIL-B because of the network stack dependencies
  • ASIL-B/QM
    • need to cross check, what is in the requirements -> they are QM
    • Need to check if the requirements are correct in case of ASIL level -> create a ticket -> @lavrovvalera
  • as long as time info forwarding is not so frequent and not time critical several daemons would be fine for that -> TimeSlave could be
    organized as separated daemon
• The solution shall be based on the hw stable local clock.
• It shall be organize as AoU -> need to start to write the AoU document in the time repo -> Create a ticket
• mw::com -> need to check if it makes sense with Ulrich -> @lavrovvalera mainly performance reasons for our use-case
• create an example - client -> @lavrovvalera create ticket, assign to @lavrovvalera : https://github.com/eclipse-score/score/issues/2692
• ITF
  • try to consider the https://github.com/eclipse-score/communication/tree/main/quality/integration_testing
  • need to check if it would make sense to use that on instead of "heavy" ITF
  • create a ticket (epic) and start refining
• requirement
  • @FScholPer to prepare the draft requirement, the offsets between the time bases shall be available
• An could try to test from integration perspective -> create a ticket for that

Agenda for 2026-03-20

• API discussion
• System Requirements
  • ASIL-B/QM?

[lavrovvalera]

Weekly 2026-03-20

Participants

@lavrovvalera
@mikehaller
@gordon9901
pengchao.zhu
@BlueXMarv3l
@mwx2015

MoMs

• Create a vote to shift the weekly meeting at least on 30 mins -> @lavrovvalera
• API discussion: suggestion is to shift to next time (27.03), when @BjoernAtBosch should be available.
• TimeSlave https://github.com/eclipse-score/score/issues/2691:
  • Tracy and her team started working on the component
  • Suggestion: the EMAC update in the hw make optional.- configured via config.
  • hopefully, we could see some results before next sync (27.03)
• mw::com between TimeDaemon and the clients
  • @lavrovvalera will disscuss with Ulrigh and will present the results on 27.03
• System requirements ASIL-B/QM?
  • by default all components in SCORE shall be ASIL-B -> @lavrovvalera to confirm
  • Allocate 1/2 of next sync to update the requirements together -> put to agenda - > @lavrovvalera
• Refinement
  • Suggestion is to do it on the weekly syncs.
  • we could pick on topic, plan it and refine in the session. It means, it needs ot be known beforehand, what are we going to refine
• Vacations
  • @BjoernAtBosch and @mikehaller will be on vacation (in a sequence) because of the Osternferien

[lavrovvalera]

Weekly 2026-03-27

Participants

@lavrovvalera
@BjoernAtBosch

MoMs

• TimeSlave https://github.com/eclipse-score/score/issues/2691
  • the PR is ready for the review: feat: add TimeSlave process and libTSClient shm IPC channel inc_time#8
  • @lavrovvalera ping in slack with review request
• mw::com between TimeDaemon and the client
  • @lavrovvalera still in discussion with Ulrich. The concept to be prepared till next weekly
  • main idea to switch was o reuse the mw::com implementation for standalong OS as well as HYP architecture
  • as long as the update frequency is relatively seldom (~125 msec) and the data inside is handled by the library we don't need "super" performance solution here.
  • another point for mw::com would be, it does support the notification of status changed if it will be needed for the Apps
• API discussion
  • @lavrovvalera the use case documentation (diagram + md file) to address the API discussion
  • main APIs: poling (Now()) and notification APIs
  • question is do we need Autosar-like API, where multiple time bases are supported out from the box
• System requirements ASIL-B/QM
  • shifted to next meeting
• Next Friday (03.04) is public holiday in Germany -> Weekly meeting will be skipped. Next meeting will be on 10th of April
• Agenda for 10.04
  • TimeSlave implementation/presentation
  • mw::com between TimeDaemon and the client
  • System requirements ASIL-B/QM
  • API + use cases discussion
    • @lavrovvalera ask to collect use cases
  • Future refinements

[lavrovvalera]

Weekly 2026-04-10

Participants

@lavrovvalera
@BjoernAtBosch

MoMs

• TimeSlave https://github.com/eclipse-score/score/issues/2691
  • the PR review is ongoing: feat: add TimeSlave process and libTSClient shm IPC channel inc_time#8
• Autosar IP
  • there might be conflicts with Autosar IP in the time domain. Mabye because of the ETAS pull request, guys already updated it. In current solution, merged to the repo, there should be no problems
• @BjoernAtBosch will start working with ITF if it will fit to our integration tests
• @lavrovvalera will prepare the API proposal
• Clarify if the meeting was shifted -> @BjoernAtBosch will ping Christian.

Agenda for 17.04

• TimeSlave implementation/presentation
• mw::com between TimeDaemon and the client
• System requirements ASIL-B/QM
• API + use cases discussion
• @lavrovvalera ask to collect use cases
• Future refinements

[lavrovvalera]

Weekly 2026-04-17

Participants

@lavrovvalera
@BjoernAtBosch
@florianfueller
@gordon9901
@nhzpc122
@BlueXMarv3l

MoMs

• TimeSlave https://github.com/eclipse-score/score/issues/2691
  • the PR review is ongoing: feat: add TimeSlave process and libTSClient shm IPC channel inc_time#8
  • the deadline to merge it is on 24.04 -> we will push merge next meeting.
  • if it will be needed, we could organize additional discussion about the comments. Sync in Slack
• mw::com between TimeDaemon and the client
  • the disign can be "time sync service based on fields"
  • there might just several (or only one field) to carry all time info values or combined by groups (sync data, pdelay data, time info data)
  • aslong as the time, when the app will call the Now() is unpeicatable, library needs to cash the values in oder to release the mw::com context
  • because of caching, no zero copy finaly
  • gap: applciaiton shall model or configure the mw::com, so it will be visible on app level. the goal will be to cover it inside the library only. for that need to create a feature request towards mw::com guys
  • ipc for VM or hosts, is comletely done by modelling and is the build time dependency (different modeling or config could be deployed to image)
  • no need additional propriatory mechanism for ipc inside and outside the ECU/VM
  • no time critical to forward the time info
  • could we give an option to the customer to decide which ipc to use
    • yes, even now it is supported to have different implementaiton between
  • mw::come supports the cross-ECU comminucation, which shall NOT be used in time domain
    • it could be fomulated like AoU
  • in case of HYP, in case guests could be qnx/Android/Linux, there might be a scenario, when guest will not use score colutions, like mw::com. in this case they will need to use their own ptp4l or similar time slaves. That needs to be cross checked -> @BjoernAtBosch
  • @lavrovvalera prepare the detailed activity diagram to use mw::com
  • decision shall be taken next meeting on 24.04
• API + use cases discussion
  • main use cases: Now(), Callback mechanism, Timebase configuration like in autosar
  • @lavrovvalera to finalize the PR and present on 24.04
• System requirements ASIL-B/QM
  • Time library on App side and the communication shall be asil-b
  • If TimeDaemon shall be Asil -B as well
  • Need to go trough the system reqs and figure out which of them should be considierd as asil-b. @lavrovvalera @BjoernAtBosch
• Future refinements (create tickets for)
  • verifications between the release. @lavrovvalera create an epic for verificaiton.
  • Plan to discuss this topic to have an output: which steps are needed to come to first ITF, on which env, what the gaps. result shall be the tickets to be implemented. @lavrovvalera put to agenda on CW18
• on 01.05 is public holiday in Germany and China. we need to find another timeslot on the CW 18. @lavrovvalera organize a poll on slack

Agenda for 24.04

• 2merge: TimeSlave https://github.com/eclipse-score/score/issues/2691
• 2decide: mw::com between TimeDaemon and the client
• API + use cases discussion
• System requirements ASIL-B/QM

[lavrovvalera]

Weekly 2026-04-24

Participants

@BjoernAtBosch
Matthias Schulze
@BlueXMarv3l
@gordon9901
@florianfueller

MoMs

• TimeSlave feat: add TimeSlave process and libTSClient shm IPC channel inc_time#8
  • need to merge it if there is no veto
  • create a ticket to use base libs in the shmem handling, based on comment feat: add TimeSlave process and libTSClient shm IPC channel inc_time#8 (comment)
  • No decision to merge, because consent of @lavrovvalera was unclear
  • Objection by @BjoernAtBosch: Should we move all kind evaluation (e.g. calculation of path delay) from TimeSlave to TimeDaemon? Reason: TimeSlave could be only QM and isn't free of interference.
• 2decide: mw::com between TimeDaemon and the client
  • Undecided
  • @BjoernAtBosch: Objection (after discussion with architect):
    • With using mw::com, any update of timesync information needs to be notified to each application involved causing some overhead.
    • Unclear is the sizing of the message queues: In case of timesync, clients do not need a "history" of all received updates - only the last update is relevant. If we limit queue size to 1, the question arises if this will be always updated the latest information (even if any application did not yet read the previous update) or if the new update is lost as long as there is some older, not yet read content.
    • Advantage of the current shared memory solution: Timesync info is maintained in a single place updated by the daemon and all apps access it if needed without any overhead.
    • A possible update notification of the sync status would still need to be done via mw::com, of course
• API + use cases discussion
  • shifted to next weekly
  • @BlueXMarv3l: API should be defined in C++ and Rust to support both languages
  • @BjoernAtBosch: "Quick draw": Two basic options possible:
    • Rust API is using some interfacing to the C++ solution
    • Having two separate library implementations - seems to be the better option because of the limited functionality of the library
• System requirements ASIL-B/QM
  • Shifted to next weekly
  • @BjoernAtBosch: Our architect suggested to do a HARA and later an FMEA to determine this
• Testing:
  • @BlueXMarv3l mentioned that a clear test case description of the overall end-to-end test case is missing

Agenda for ??.04

• API + use cases discussion
• System requirements ASIL-B/QM
• Verification epic: which steps are needed to come to first ITF, on which env, what the gaps. result shall be the tickets to be implemented. The ticket: Improvement: Feature Verification inc_time#17

[BjoernAtBosch]

Wrote this as "minutes of my memory". @BlueXMarv3l please feel free to add missing or correct misunderstood things. Thx!

[lavrovvalera]

Weekly 2026-04-30

Participants

@lavrovvalera
@BjoernAtBosch
@florianfueller
Matthias Schulze

MoMs

• TimeSlave PR
  • feat: add TimeSlave process and libTSClient shm IPC channel inc_time#8
  • to merge it we need somebody with write acces (@FScholPer , @umaucher )
• 2decide: mw::com between TimeDaemon and the client
  • Objection from prev meeting:
    • With using mw::com, any update of timesync information needs to be notified to each application involved causing some overhead.
    • Unclear is the sizing of the message queues: In case of timesync, clients do not need a "history" of all received updates - only the last update is relevant. If we limit queue size to 1, the question arises if this will be always updated the latest information (even if any application did not yet read the previous update) or if the new update is lost as long as there is some older, not yet read content.
    • Advantage of the current shared memory solution: Timesync info is maintained in a single place updated by the daemon and all apps access it if needed without any overhead.
    • A possible update notification of the sync status would still need to be done via mw::com, of course
  • open quesiotns (main advantages):
    • what to do with the HYP design
      • to allocate the shmem we ned to use differnt QNX API-> ned to have another impl to allocate the memory, which could be configured.
    • mw::com solution is already asil-b
  • how to come to the decision?
    • @lavrovvalera : notify in slack, next time we need to come to some decision.
    • we need to ake the concept (2 concepts) and compare the siolutions. @lavrovvalera + @florianfueller
• API + use cases discussion
  • PR is repared Prepare the new score::time API inc_time#18
    • docs: https://eclipse-score.github.io/inc_time/pr-18/time/index.html
    • some cleaning are still needed, but is ready for the first review.
• System requirements ASIL-B/QM
  • How to makethe asil-b reqs without HARA?
• Verification
• @lavrovvalera to cretae a list of possible gaps in implementation
• @lavrovvalera to create a ticket to fix the QNX build, currently there is a license issue. -> assign to @BjoernAtBosch
• @lavrovvalera to create a ticket to make the HW clock manipulation n a stakeholder level a bit more clear

Agenda for 07.05

[lavrovvalera]

Weekly 2026-05-07

Participants

@lavrovvalera
@BjoernAtBosch
@florianfueller
@BlueXMarv3l
@gordon9901

MoMs

• TimeSlave PR is merged

• 2decide: mw::com between TimeDaemon and the client -> shift to next weekly

• Next weekly on 15.05 is a bridge day in Germany. Then we skip the meeting next week and meet next time on 22.05

• API + use cases discussion

  • main concern is about namings and design
  • main idea that the Tags shall fit to the real vehicle scenaious: Vehicle time (ptp), System_time -> sync to some absolute external time base
  • need to add the AbsTime (AbsoluteTime?) as additional tag. @lavrovvalera -> add into proposal, how it could be implemented.
    • the AbseTime should not be mapped to td:.chrono::system_clock, because the in the linux there might be a problem with the leap seconds.
  • Discussion with namings could be done offline.
  • Do we need some additional interfaces to different time_bases? In autosar there was a possibility to add some just via configuraiton.
    • At the moment, we don't have in mind any additional timebases or use cases where we need it.
    • proposal to think about that till next meeting.

• System requirements ASIL-B/QM

  • shift to next meeting

• Folder and namings updaze: the modlue template for folder structure was updated. we need to be complient wit hit. the epic was created: Improvement: Support SCORE Code Structure & Conventions inc_time#19

  • @lavrovvalera to cretae a ticket for TimeSlave -> assign to @BlueXMarv3l : Improvement: Update the TimeSlave to comply to SCORE conventions  inc_time#20
  • @lavrovvalera to create a ticket for the TimeDameon -> assign to @BjoernAtBosch : Improvement: Update the TimeDaemon to comply to SCORE conventions inc_time#21

• Make the chain runnable (PoC level)

  • We need to have the example client application -> @BlueXMarv3l : Improvement: Add the example to show the score::time interfaces usage inc_time#13
  • Run the chain on the hw -> @BlueXMarv3l

• Verification (first smoke test)

  • Using the working chain (see prev epic) Need to cretae the 1st ITF test and be able ru nit manually and on CI. @lavrovvalera to find the existing example
  • we need to consider the tests, based on input from @gordon9901 feat: add TimeSlave process and libTSClient shm IPC channel inc_time#8 (comment) -> move them to the Verificaiton strategy to the repo -> @BlueXMarv3l , @lavrovvalera to create a ticket about it.

• Qnx license (build) shift to next meeting

  • @lavrovvalera to create a ticket to fix the QNX build, currently there is a license issue. -> assign to @BjoernAtBosch

[lavrovvalera]

Weekly 2026-05-22

Participants

@lavrovvalera
@BjoernAtBosch
@NEOatNHNG
@gordon9901
@mikehaller
@BlueXMarv3l

MoMs

• Backlog
  • need to add the epic about mw::com discussion
• mw::com
  • Objection from prev meeting:
    • With using mw::com, any update of timesync information needs to be notified to each application involved causing some overhead.
    • Unclear is the sizing of the message queues: In case of timesync, clients do not need a "history" of all received updates - only the last update is relevant. If we limit queue size to 1, the question arises if this will be always updated the latest information (even if any application did not yet read the previous update) or if the new update is lost as long as there is some older, not yet read content.
    • Advantage of the current shared memory solution: Timesync info is maintained in a single place updated by the daemon and all apps access it if needed without any overhead.
    • A possible update notification of the sync status would still need to be done via mw::com, of course
    • open quesiotns (main advantages):
      • what to do with the HYP design
      • to allocate the shmem we ned to use differnt QNX API-> ned to have another impl to allocate the memory, which could be configured.
    • mw::com solution is already asil-b
  • Field works as notifications. need to use then field with event (without get/set)
  • get - >method call fro mthe daemon -> additional overhead
  • mw::com will have differnet infrustr for qm/asil clients -> to have the FFI (qm is too slow)
    • is done by cofiguration
  • problem: ifuse notification handler it is resource heavy in comparison with the polling
  • proc for mw::com
    • status notificytion
    • HYP setup
  • diag might be done as asilb for events
  • need to ping mw::com guas for the details about overhead and details, actual mechanisms
• Verificsation
  • @BlueXMarv3l prepared the first API test. video is presented with fake slave and demo app using the API change on QNX
  • Current demonstration environment: steady_clock -> fake_time_slave -> /dev/shmem/gptp_ptp_info -> demo_time_daemon -> SVT SHM -> demo_app
  • end-to-end test
    • IEEE 802.1AS Network -> TimeSlave -> /dev/shmem/gptp_ptp_info -> time_daemon(*) -> SVT SHM -> app
    • HW need to be setup, might be done till next time
    • hw timestamping will be used
• Linux support
  • @BjoernAtBosch opened a new pr to support the ticket: Fixes/improvements to let the whole chain run under Linux (Ubuntu 24.04 within WSL2): Try to get it running in Linux inc_time#25 -> @lavrovvalera need to look
  • @lavrovvalera support from backlog
• TimeSlave folder structure support
  • the PR is prepared: Improvement:Update the timeslave to comply to SCORE conventions and add full-chain demo inc_time#28 -> to review
• API discussion
  • Absolute time -> Global Time (?)
  • std::chrono wrappers
    • steady is mapped to CLOCK_MONOTONIC
    • system is appedto the CLOCK_REALTIME
    • wrappers shall stay
  • system ecarx
    • use case: system is used gps to sync to.
    • from score/time use case its ok to have the wrapper which most probably will not be used by ECAR
    • the std::crono:.system time (CLOCK_REALTIME) shall be synchronized to GPS in general -> to discuss i nthe scope of AbsTime/GloablTime/SDAt time