[TIME] Add ASIL related requirements and rework existing by BjoernAtBosch · Pull Request #3020 · eclipse-score/score

BjoernAtBosch · 2026-06-23T16:18:08Z

Requirements for Time feature:

Define safety-related stakeholder and feature requirements
For that I mainly focused on two areas:
- Requesting FFI for Time API users
- Requesting the support of a reliable/safe time qualification (this requires support by the involved components/ECUs of the vehicle)
Fix some requirement types
Improve some time related stakeholder and feature requirements

This is a draft PR for now as it requires some discussion
Closes eclipse-score/time#33

github-actions · 2026-06-25T09:28:49Z

The created documentation from the pull request is available at: docu-html

lavrovvalera · 2026-07-09T09:15:24Z

+   :status: valid
+   :version: 1
+
+   Usage of the vehicle time base API shall be free from interfrences for the consuming components.


I would have a quesitons here

what FFI means here? which aspect? memory, data, cpu?

would ut make sense to specify, the API shall provide some funcitonality within the asil-b quality? then it will be out fro the box implicitly

Hmh - not sure about the "correct wording" here. I thought "FFI" is a wording requiring the denoted part to be qualifiable to not to contain software issues which interfere the parts where it's linked to.

lavrovvalera · 2026-07-09T09:23:34Z

+
+   Note:
+   * This does not apply to willful interferences by malicious software components or components in control by malicious actors, which are out of scope of this requirement.
+   * The end-to-end quality of the time information provided by the time base API may require components and protocols outside of the scope of this SW-platform to be qualified accordingly (e.g. the respective time master) or at least support this requirement (e.g. time-aware bridges/switches supporting the AUTOSAR Time Synchroization Protocol).


why here the Autosar is mentioned?
Shoud it be in general Time aware bridges and switches

My knowledge is, that "pure" gPTP is not supporting e2e protection of the time sync data. If that shall be supported we need to use the AUTOSAR Time Sync Protocol extension. Also, it is mentioned in the S-CORE feature description to stay compatible to AUTOSAR Adaptive (see https://eclipse-score.github.io/score/main/features/time/index.html#in-vehicle-time-synchronization).

The AUTOSAR time sync protocol is an extension of the gPTP. It does not mean that any extensions need to be used but could be used.

Will reformulate without mentioning Autosar

lavrovvalera · 2026-07-09T09:24:22Z

+   :status: valid
+   :version: 1
+
+   Usage of the absolute time base API shall be free from interfrences for the consuming components.


I'm not sure I get the intention of the requirement, coudl you exaplain, what did you want to acheive her?

In general, the usage of the time API(s) shall be free from interference. In fact, we require ASIL level for the vehicle time only (cuurently), but ASIL applications shall be able to access QM level absolute time without being interfered by using the absolute time API library (if that's separated from the other time API libs at all).

lavrovvalera · 2026-07-09T09:27:57Z

+   :status: valid
+   :version: 1
+
+   Usage of the time base APIs shall be free from interfrences for the consuming components.


Not sure, what exactly do you mean here.
if we will have the API or access to the time base with qsil-b inegrity, tht will already mean FFI support just out fro mthe iso26262
what do we want to achieve wit hthis one?

There need to be a requirement what exactly demands that. Current requirements do not demand that yet.

There is stkh_req__dependability__automotive_safety which requests "The SW-platform shall support applications with an automotive safety integrity level up to ASIL-B."

BUT: I think this is requesting the ability in general. It is not explicitly requesting it for each and every feature/component of the platform. If it would, EVERYTING would need to be ASIL. But that is not what is wanted.

That's the reason to explicitly state it here for the time API.

To - maybe - make it clearer what I want to achieve:
I just want to request that the usage of the API by an application does not lead to any interference of the application code. More concrete: the time library (and its mechanisms used to communicate to the Time Daemon) must not induce any interference if linked to the application code. But this latter, more concrete wording is not suitable on stakeholder level as the implementation details shall not be "visible" here.

I don't want to rate the whole API with an ASIL label. This would (imho) mean, that every element of the API is safety qualified (or at least qualifiable). But I don't think, that this wanted.

For that reason I split the ASIL requirements "in two":

FFI for using the API

Safety qualification for selected elements of the API, which also requires additional measures outside the scope of this SW platform

lavrovvalera · 2026-07-09T09:28:42Z

   :safety: QM
   :rationale: Enables the system to compare events from different ECUs chronologically, using the same time base for timestamping ingress and egress frames.
-   :status: valid
+   :status: invalid


Why is it marked as not valid?

This is a proposal. Imho we should not define such detailed requirements on stakeholder level.

pawelrutkaq · 2026-07-09T12:08:24Z


   The **score::time feature** shall provide an API to access the synchronized vehicle time.

+.. feat_req:: Usage of Vehicle Time base API has FFI


for me, if API is ASIL-B, the requirement below makes no sense since FFI is implicit, or did i read it wrong ?

Where is it stated that the API shall be ASIL-B? Furthermore, as I understood it ASIL is a process, not a goal.

Ah - you mean we should set the safety label of feat_req__time__vehicle_time_time_api to "ASIL"?
But then I think it's unclear what elements are ASIL: Is the usage of the API lib is FFI, or are all provided data ASIL qualified? I guess the latter one is not demanded in general.

pawelrutkaq · 2026-07-09T12:09:44Z

   :version: 1

-   The **score::time feature** shall provide an API to read the high precision clock in nanoseconds precision.
+   The **score::time feature** shall provide an API to read the high resolution clock in nanoseconds resolution.


This can only be fulfilled if supporting OS/HW is there, thus kind of generating AoU toward OS.

pawelrutkaq · 2026-07-09T12:10:41Z

 .. stkh_req:: Automotive Safety Integrity Level
   :id: stkh_req__dependability__automotive_safety
-   :reqtype: Functional
+   :reqtype: Non-Functional


guess not part of this PR really ?

It is. Should it be moved to separate PR?

pawelrutkaq · 2026-07-09T12:12:18Z

+
+   Note:
+   * This does not apply to willful interferences by malicious software components or components in control by malicious actors, which are out of scope of this requirement.
+   * The end-to-end quality of the time information provided by the time base API may require components and protocols outside of the scope of this SW-platform to be qualified accordingly (e.g. the respective time master) or at least support this requirement (e.g. time-aware bridges/switches supporting the AUTOSAR Time Synchroization Protocol).


not sure if we can/shall use AUTOSAR here.

See reply to Valery's comment.

(Will re-formulate this)

pawelrutkaq · 2026-07-09T12:13:06Z

+   The SW-platform shall provide access to the current high resolution clock from the system time provider in nanoseconds.

-   Note: to which clock the high precision clock is mapped, depends on the system design.
+   Note: to which clock the high resolution clock is mapped, depends on the system design.


Feels like copy-paste with feature req. Shall we flatten this ?

How to flatten this without loosing preciseness? If stakeholders want to explicitly have this distinction between the different local clocks it should be in.
Else there could be a single more unspecific requirement just requesting "access to local clocks via unified API" (mainly for enabling mockability).

Co-authored-by: Ryan Steel <str1yok@bosch.com> Signed-off-by: Björn Hornburg <Bjoern.Hornburg@de.bosch.com>

[TIME] Add ASIL related requirements and rework existing

f867792

github-project-automation Bot added this to S-CORE Roadmap and TLC - Technical Lead Circle Jun 23, 2026

github-project-automation Bot moved this to Backlog in S-CORE Roadmap Jun 23, 2026

BjoernAtBosch requested review from NEOatNHNG and lavrovvalera June 23, 2026 16:18

BjoernAtBosch commented Jun 23, 2026

View reviewed changes

Comment thread docs/requirements/stakeholder/index.rst Outdated

BjoernAtBosch added 2 commits June 25, 2026 10:22

Fix requirements linking and typo

91d61b8

Fix workflow findings

a03ef8c

BjoernAtBosch marked this pull request as ready for review June 26, 2026 13:08

BjoernAtBosch requested review from FScholPer, antonkri, johannes-esr and qor-lb as code owners June 26, 2026 13:08

lavrovvalera suggested changes Jul 9, 2026

View reviewed changes

pawelrutkaq reviewed Jul 9, 2026

View reviewed changes

ryan-steel reviewed Jul 10, 2026

View reviewed changes

Comment thread docs/features/time/docs/requirements/index.rst Outdated

BjoernAtBosch and others added 2 commits July 10, 2026 11:25

Rephrase notes to no mention Autosar

9028ded

Apply suggestion from @ryan-steel

fd50b35

Co-authored-by: Ryan Steel <str1yok@bosch.com> Signed-off-by: Björn Hornburg <Bjoern.Hornburg@de.bosch.com>


		The score::time feature shall provide an API to access the synchronized vehicle time.

		.. feat_req:: Usage of Vehicle Time base API has FFI

Uh oh!

Conversation

BjoernAtBosch commented Jun 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented Jun 25, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BjoernAtBosch Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BjoernAtBosch Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

BjoernAtBosch commented Jun 23, 2026 •

edited

Loading

BjoernAtBosch Jul 10, 2026 •

edited

Loading

BjoernAtBosch Jul 10, 2026 •

edited

Loading