Added timestamp struct based vspec, and posix timestamp as unit (#1) by ali-momin12 · Pull Request #884 · COVESA/vehicle_signal_specification

ali-momin12 · 2026-03-02T02:18:08Z

Added timestamp struct based vspec, and nanosecond as unit in units.yaml
This change is a pre-requisite to the issue 878 which then as all the concerned stakeholders agreed upon as an enhancement in vss-tools (an upcoming PR in vss-tools repo)

erikbosch · 2026-03-02T07:38:27Z

At least for me the diff seems a bit strange, only highlighting changes already on master. I think I have seen similar results in the past sometimes when there have been a merge/rebase on the source branch which makes github confused. Not sure if a rebase and force push of source/head branch can help

ali-momin12 · 2026-03-02T07:47:18Z

At least for me the diff seems a bit strange, only highlighting changes already on master. I think I have seen similar results in the past sometimes when there have been a merge/rebase on the source branch which makes github confused. Not sure if a rebase and force push of source/head branch can help

Apologies for the confusion due to rebase (i was getting the DCO check failed due to one commit not being signed off and after rebasing, the confusion happened)

I have fixed this, kindly review whenever you can. thanks.

erikbosch · 2026-03-02T13:19:15Z

spec/include/Timestamp.vspec

+
+#
+# Identifier
+# Based on OAuth 2.0. Subject is the UserID inside the claim of the Issuer Domain.


This is a copy paste error, right?

erikbosch · 2026-03-02T13:35:07Z

Thanks for the PR, we will bring it up at the next VSS meeting.

As this would be the first time we would enter datatypes to the standard catalog (even if not used for any signal in catalog) we need to align on how to handle it. I would like to see that the file actually is used in tests, and one potential idea is to create a file VehicleDataTypes.vspec that includes the new file:

VehicleDataTypes:
  type: branch
  description: Top-level branch for vehicle data types.

#include include/Timestamp.vspec VehicleDataTypes

If we would do it like that we could extend our Makefile so that the file is included in one or more of our tests, possibly running like below.


(.venv-vss) erik@vbox:~/vehicle_signal_specification$ vspec export json -u ./spec/units.yaml --strict -s ./spec/VehicleSignalSpecification.vspec -t spec/VehicleDataTypes.vspec -o hej.json
[14:28:58] INFO     Loaded 'VSSQuantity', file=/home/erik/vehicle_signal_specification/spec/quantities.yaml, elements=30                        units_quantities.py:30
           INFO     Loaded 'VSSUnit', file=/home/erik/vehicle_signal_specification/spec/units.yaml, elements=69                                 units_quantities.py:30
           INFO     VSpecs (Types) loaded, amount=2                                                                                                       vspec.py:130
           INFO     Dynamic datatypes added=1                                                                                                              main.py:139
           INFO     VSSNode('.VehicleDataTypes.Time_t', data=VSSDataStruct(fqn='VehicleDataTypes.Time_t', type=<NodeType.STRUCT: 'struct'>, description='A tree.py:574
                    point in time', comment=None, delete=False, deprecation=None, constUID=None, fka=[], instantiate=True))                                           
           INFO     VSpecs loaded, amount=90                                                                                                              vspec.py:130
           INFO     Generating JSON output...                                                                                                              json.py:100
           INFO     Adding custom data types to signal dictionary

sschleemilch · 2026-03-02T17:45:46Z

spec/include/Timestamp.vspec

+# Based on OAuth 2.0. Subject is the UserID inside the claim of the Issuer Domain.
+#
+
+Time_t:


Why the _t suffix? Because of the posix C header? I would just name it Timestamp.

updated in the commit effbca6

sschleemilch · 2026-03-02T17:46:36Z

spec/include/Timestamp.vspec

+  type: struct
+  description: A point in time
+
+Time_t.t_sec:


The t_ prefix also seems unnecessary. What about seconds and nanos?

updated in the commit effbca6

sschleemilch · 2026-03-02T17:47:46Z

spec/include/Timestamp.vspec

+  type: property
+  unit: unix-time
+  datatype: int64     # seconds (may use sentinel negative values)
+  description: time measured in seconds


Maybe a hint to Unix time? If that's what we even want to express?

Something like "Unix epoch seconds"

updated in the commit effbca6

sschleemilch · 2026-03-02T17:48:24Z

spec/include/Timestamp.vspec

+  type: property
+  unit: ns
+  datatype: int64    # nanoseconds in [0, 1e9]
+  description: time measured in nanoseconds


"Nanosecond offset" maybe?

updated in the commit effbca6

Based on COVESA/vss-tools#484 we now require unique unit names. This gives problems here. We could alternatively remove the old mpg unit. Signed-off-by: Erik Jaegervall <erik.jaegervall@se.bosch.com> Signed-off-by: Ali Momin <ali_momin@jp.honda>

Signed-off-by: Ali Momin <ali_momin@jp.honda>

Updates done to timestamp.vspec contents as per the feedback. --------- Signed-off-by: Ali Momin <ali_momin@jp.honda>

erikbosch · 2026-03-03T08:49:36Z

spec/include/Timestamp.vspec

+Timestamp.nanoseconds:
+  type: property
+  unit: ns
+  datatype: int64    # nanoseconds in [0, 1e9]


I am not a math expert, but shall range possibly be described as [0, 1e9), i.e. max value is 999999999 nanoseconds.

We support min/max also for properties, found this example in vss-tools, so possibly we could specify min and max explicitly. Technically a uint32 would suffice right? is int64 proposed because some other framework or std definition use int64 for the nanosecond part.

NestedStruct.x: type: property description: "x property" datatype: double min: -10 NestedStruct.y: type: property description: "y property" datatype: double max: 10

erikbosch · 2026-03-03T15:57:16Z

MoM:

Erik presented PR
Ulf: Should it not be in type tree
E: We do not yet have a type tree, I added a comment that it at least for testing should be in a type tree.
E: good idea, can provide a recommendation.
Ted: Related to https://docs.google.com/document/d/1OKjlefi6_gGIKYvbZIHdF8Syabj_7AvsiksKBXmT9mc/edit?tab=t.0

sschleemilch · 2026-03-04T08:12:07Z

Agreed that it should be in the type tree

ali-momin12 force-pushed the feature/struct_based_timestamp_addition branch from 9be1917 to 170f206 Compare March 2, 2026 02:22

erikbosch reviewed Mar 2, 2026

View reviewed changes

sschleemilch reviewed Mar 2, 2026

View reviewed changes

erikbosch and others added 4 commits March 3, 2026 02:11

Changing unit for mpg (COVESA#882)

3188fa4

Based on COVESA/vss-tools#484 we now require unique unit names. This gives problems here. We could alternatively remove the old mpg unit. Signed-off-by: Erik Jaegervall <erik.jaegervall@se.bosch.com> Signed-off-by: Ali Momin <ali_momin@jp.honda>

Force pushing the changes

5b3c873

Signed-off-by: Ali Momin <ali_momin@jp.honda>

adding missing changes due to previous rebase confusion

f0e7a4c

Signed-off-by: Ali Momin <ali_momin@jp.honda>

Updated the timestamp.vspec as per the feedback

effbca6

Updates done to timestamp.vspec contents as per the feedback. --------- Signed-off-by: Ali Momin <ali_momin@jp.honda>

ali-momin12 force-pushed the feature/struct_based_timestamp_addition branch from 51ecedc to effbca6 Compare March 3, 2026 02:11

ali-momin12 requested a review from sschleemilch March 3, 2026 02:14

erikbosch reviewed Mar 3, 2026

View reviewed changes

Conversation

ali-momin12 commented Mar 2, 2026

Uh oh!

erikbosch commented Mar 2, 2026

Uh oh!

ali-momin12 commented Mar 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

erikbosch commented Mar 2, 2026

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!

erikbosch commented Mar 3, 2026

Uh oh!

sschleemilch commented Mar 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants