Skip to content

[TIME] Add ASIL related requirements and rework existing #3020

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
BjoernAtBosch wants to merge 5 commits into
base: main
Choose a base branch
from
Open

[TIME] Add ASIL related requirements and rework existing #3020

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
f867792
[TIME] Add ASIL related requirements and rework existing
BjoernAtBosch Jun 19, 2026
91d61b8
Fix requirements linking and typo
BjoernAtBosch Jun 25, 2026
a03ef8c
Fix workflow findings
BjoernAtBosch Jun 25, 2026
9028ded
Rephrase notes to no mention Autosar
BjoernAtBosch Jul 10, 2026
fd50b35
Apply suggestion from @ryan-steel
BjoernAtBosch Jul 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 44 additions & 6 deletions docs/features/time/docs/requirements/index.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -59,6 +59,17 @@ Time Synchronization

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

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

@pawelrutkaq pawelrutkaq Jul 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@BjoernAtBosch BjoernAtBosch Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@BjoernAtBosch BjoernAtBosch Jul 10, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

:id: feat_req__time__vehicle_time_base_api_ffi
:reqtype: Non-Functional
:security: NO
:safety: ASIL_B
:derived_from: stkh_req__time__time_base_api_ffi
:status: valid
:version: 1

Usage of the vehicle time base API shall be free from interference for the consuming components.

.. feat_req:: Vehicle Time base accuracy qualifier
:id: feat_req__time__vehicle_time_acc_qual_api
:reqtype: Functional
Expand All @@ -76,6 +87,22 @@ Time Synchronization
* are there any instabilities, like time jumps to the past or to the future
* does the time increase in a monotonic manner.

.. feat_req:: Reliability of Vehicle Time base accuracy qualifier
:id: feat_req__time__veh_time_reliable_accur_qual
:reqtype: Non-Functional
:security: NO
:safety: ASIL_B
:derived_from: stkh_req__time__qualified_time_information
:status: valid
:version: 1

The architecture and implementation parts of the time feature shall support to ensure,
that the provided accuracy qualifier always reflects the actual quality of the local time base.

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 requires 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 end-to-end protection extensions of gPTP).

.. feat_req:: Vehicle Time base time point qualifier
:id: feat_req__time__vehicle_time_time_pt_qual
:reqtype: Functional
Expand All @@ -91,7 +118,7 @@ Time Synchronization

.. feat_req:: Vehicle Time control flow
:id: feat_req__time__vehicle_time_ctrl_flow
:reqtype: Functional
:reqtype: Non-Functional
:security: NO
:safety: QM
:derived_from: stkh_req__time__vehicle_time_api[version==1]
Expand Down Expand Up @@ -148,6 +175,17 @@ Time Synchronization to absolute external sources

The **score::time feature** shall provide an API to read the absolute time base, synchronized to external time sources.

.. feat_req:: Usage of Absolute Time base API has FFI
:id: feat_req__time__abs_time_base_api_ffi
:reqtype: Non-Functional
:security: NO
:safety: ASIL_B
:derived_from: stkh_req__time__time_base_api_ffi
:status: valid
:version: 1

Usage of the absolute time base API shall be free from interfrences for the consuming components.

@lavrovvalera lavrovvalera Jul 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@BjoernAtBosch BjoernAtBosch Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).


.. feat_req:: Absolute Time base accuracy qualifier
:id: feat_req__time__abs_acc_qual
:reqtype: Functional
Expand Down Expand Up @@ -207,18 +245,18 @@ Time Synchronization to absolute external sources
Local Clock
^^^^^^^^^^^^^^^^^^^^

.. feat_req:: High precision clock API
:id: feat_req__time__high_prec_clock_api
.. feat_req:: High resolution clock API
:id: feat_req__time__high_res_clock_api
:reqtype: Functional
:security: NO
:safety: QM
:derived_from: stkh_req__time__high_precision_clock_api[version==1]
:derived_from: stkh_req__time__high_res_clock_api[version==1]
:status: valid
: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.

@pawelrutkaq pawelrutkaq Jul 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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.

*Use case:* such clocks might be used for time-critical applications, such as audio/video streaming, event logging, and diagnostics.

Expand Down
51 changes: 38 additions & 13 deletions docs/requirements/stakeholder/index.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -254,7 +254,7 @@ Dependability

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

@pawelrutkaq pawelrutkaq Jul 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

guess not part of this PR really ?

@BjoernAtBosch BjoernAtBosch Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is. Should it be moved to separate PR?

:security: NO
:safety: ASIL_B
:rationale: The SW-platform shall be usable by safety relevant applications.
Expand Down Expand Up @@ -840,12 +840,11 @@ Time
:reqtype: Functional
:security: NO
:safety: QM
:rationale: Enables the system to compare events chronologically.
:rationale: Enables the system to compare in-vehicle events chronologically.
:status: valid
:version: 1

The SW-platform shall provide a time synchronization framework to synchronize its clock
to Time Master within the vehicle.
The SW-platform shall provide a framework to synchronize its local vehicle clock representation to a Time Master within the vehicle.

.. stkh_req:: Vehicle Time base API
:id: stkh_req__time__vehicle_time_api
Expand All @@ -856,15 +855,15 @@ Time
:status: valid
:version: 1

The SW-platform shall provide access to synchronized vehicle time.
The SW-platform shall provide access to the synchronized vehicle time.

.. stkh_req:: Synchronize the HW clock with Vehicle Time
:id: stkh_req__time__hw_clock_sync
:reqtype: Functional
:security: NO
: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

@lavrovvalera lavrovvalera Jul 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is it marked as not valid?

@BjoernAtBosch BjoernAtBosch Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

:version: 1

The SW-platform shall synchronize the local HW clock to vehicle time.
Expand All @@ -874,11 +873,11 @@ Time
:reqtype: Functional
:security: YES
:safety: QM
:rationale: Enables the system to validate a certificate or token with temporal validity conditions, adding a UTC-timestamp to a data set.
:rationale: Enables the system to validate a certificate or token with temporal validity conditions, to add a UTC-timestamp to a data set, etc.
:status: valid
:version: 1

The SW-platform shall provide a framework to synchronize the clock to external-to-vehicle absolute time base (UTC).
The SW-platform shall provide a framework to synchronize its local absolute clock representation to an external-to-vehicle absolute time base (e.g. UTC).

.. stkh_req:: Absolute time base API
:id: stkh_req__time__absolute_time_api
Expand All @@ -891,18 +890,44 @@ Time

The SW-platform shall provide access to the absolute time base, synchronized with external time sources.

.. stkh_req:: Local High precision Clock API
:id: stkh_req__time__high_precision_clock_api
.. stkh_req:: Usage of Time base APIs has FFI
:id: stkh_req__time__time_base_api_ffi
:reqtype: Non-Functional
:security: NO
:safety: ASIL_B
:rationale: Enables an application requiring a rating up to ASIL-B to use the time base API.
:status: valid
:version: 1

Usage of the time base APIs shall be free from interfrences for the consuming components.

@lavrovvalera lavrovvalera Jul 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@BjoernAtBosch BjoernAtBosch Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@BjoernAtBosch BjoernAtBosch Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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":

  1. FFI for using the API
  2. Safety qualification for selected elements of the API, which also requires additional measures outside the scope of this SW platform


.. stkh_req:: Reliable Qualification of Time Information
:id: stkh_req__time__qualified_time_information
:reqtype: Non-Functional
:security: NO
:safety: ASIL_B
:rationale: Depending on the user needs and their SW platform configuration, it can be guaranteed that applications can rely on the quality rating of the time reference of a certain time base, even in case of interferences induced into or by QM-rated software components involved in the synchronization process.
:status: valid
:version: 1

The architecture and common implementation parts of the time synchronization framework shall support to ensure, that the provided qualification information of a synchronized time base always reflects the actual quality of the provided time (stamp) information.

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 requires 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 end-to-end protection extensions of gPTP).

.. stkh_req:: Local High Resolution Clock API
:id: stkh_req__time__high_res_clock_api
:reqtype: Functional
:security: NO
:safety: QM
:rationale: Enables an application to get the current system time, which is essential for time-sensitive operations and event scheduling, via common, mockable and standardized API.
:status: valid
:version: 1

The SW-platform shall provide access to the current high precision clock from the system time provider in nanoseconds.
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.

@pawelrutkaq pawelrutkaq Jul 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@BjoernAtBosch BjoernAtBosch Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).


.. stkh_req:: Local Monotonic Clock API
:id: stkh_req__time__monotonic_clock_api
Expand All @@ -917,10 +942,10 @@ Time

Note: to which clock the monotonic clock is mapped, depends on the system design.


AI SW-platform
--------------


.. stkh_req:: On-board ML Workloads
:id: stkh_req__ai_platform__enablement
:reqtype: Functional
Expand Down
Loading