Skip to content
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

Jump to bottom

Adding concept of 'format' #771

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Adding concept of 'format' #771

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
48 changes: 48 additions & 0 deletions docs-gen/content/rule_set/data_entry/data_formats.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
---
title: "Data Formats"
date: 2024-08-29T12:36:12+02:00
weight: 25
---

## Data Formats

For some data it is necessary to specify the format.
An example are dates.
Let's say we specify a leaf e.g. `Vehicle.ProductionDate` and give it
the datatype `string`. How would a consumer know what to expect in this string?
It could be ISO8601, it could be a unix-timestamp or it could be something totally different.
To provide that info, a `format` field can be used.

A complete definition of a `ProductionDate` field could then look like this:

```yaml
Vehicle.ProductionDate:
description: The production date of the car
datatype: string
format: iso8601
```

All formats being used have to be specified in format definition files.

## Format definitions file

It has the following format:

```yaml
unix-time:
description: Unix Timestamp
allowed-datatypes: ['uint32','uint64','int64']
```

Both fields are required:
- `description`: Should specify how the format is specified
- `allowed-datatypes`: Datatypes allowed when using this format. The consistency will be enforced by `vss-tools`

Please note that you can either specify `unit` or `format`.


## Supported Data Formats in VSS Standard Catalog

The catalog defines common formats in the `formats.yaml` file similar to how units are handled. `vss-tools` provides an interface to pass one or more format files.
Like with unit files, `formats.yaml` will be loaded if it is present on the level
of the given entry point `vspec` file.
2 changes: 1 addition & 1 deletion spec/Cabin/Infotainment.vspec
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -234,7 +234,7 @@ HMI.IsScreenAlwaysOn:
HMI.LastActionTime:
datatype: string
type: sensor
unit: iso8601
format: iso8601
description: Time for last hmi action, formatted according to ISO 8601 with UTC time zone.

HMI.DisplayOffDuration:
Expand Down
4 changes: 2 additions & 2 deletions spec/Powertrain/TractionBattery.vspec
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ Id:
ProductionDate:
datatype: string
type: attribute
unit: iso8601
format: iso8601
description: Production date of battery in ISO8601 format, e.g. YYYY-MM-DD.

ErrorCodes:
Expand Down Expand Up @@ -634,7 +634,7 @@ Charging.Timer.Mode:
Charging.Timer.Time:
datatype: string
type: actuator
unit: iso8601
format: iso8601
description: Time for next charging-related action, formatted according to ISO 8601 with UTC time zone.
Value has no significance if Charging.Timer.Mode is 'inactive'.

Expand Down
4 changes: 2 additions & 2 deletions spec/Powertrain/TractionBattery/BatteryConditioning.vspec
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -64,15 +64,15 @@ BatteryConditioning.StartTime:
datatype: string
description: Start time for battery conditioning,
formatted according to ISO 8601 with UTC time zone.
unit: iso8601
format: iso8601
comment: If the vehicle is asleep, this is the time the vehicle and the battery conditioning system must wake up
and start monitoring the battery and if necessary start heating/cooling of the battery.

BatteryConditioning.TargetTime:
type: actuator
datatype: string
description: Target time when conditioning shall be finished, formatted according to ISO 8601 with UTC time zone.
unit: iso8601
format: iso8601
comment: For FAST_CHARGING mode this is typically the time when charging is supposed to start.
For DRIVING mode this is typically the expected departure time.
Battery conditioning will be deactivated when this time has passed.
Expand Down
12 changes: 6 additions & 6 deletions spec/Vehicle/Vehicle.vspec
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -97,7 +97,7 @@ VehicleIdentification.BodyType:
VehicleIdentification.DateVehicleFirstRegistered:
datatype: string
type: attribute
unit: iso8601
format: iso8601
description: The date in ISO 8601 format of the first registration of the vehicle with the respective public authorities.

VehicleIdentification.LicensePlate:
Expand All @@ -114,19 +114,19 @@ VehicleIdentification.MeetsEmissionStandard:
VehicleIdentification.ProductionDate:
datatype: string
type: attribute
unit: iso8601
format: iso8601
description: The date in ISO 8601 format of production of the item, e.g. vehicle.

VehicleIdentification.PurchaseDate:
datatype: string
type: attribute
unit: iso8601
format: iso8601
description: The date in ISO 8601 format of the item e.g. vehicle was purchased by the current owner.

VehicleIdentification.VehicleModelDate:
datatype: string
type: attribute
unit: iso8601
format: iso8601
description: The release date in ISO 8601 format of a vehicle model (often used to differentiate versions of the same make and model).

VehicleIdentification.VehicleConfiguration:
Expand Down Expand Up @@ -221,7 +221,7 @@ StartTime:
datatype: string
type: attribute
default: '0000-01-01T00:00Z'
unit: iso8601
format: iso8601
description: Start time of current or latest trip, formatted according to ISO 8601 with UTC time zone.
comment: This signal is supposed to be set whenever a new trip starts.
A new trip is considered to start when engine gets enabled (e.g. LowVoltageSystemState in ON or START mode).
Expand Down Expand Up @@ -452,7 +452,7 @@ CurrentLocation:
CurrentLocation.Timestamp:
datatype: string
type: sensor
unit: iso8601
format: iso8601
description: Timestamp from GNSS system for current location, formatted according to ISO 8601 with UTC time zone.

CurrentLocation.Latitude:
Expand Down
15 changes: 15 additions & 0 deletions spec/formats.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
unix-time:
description: Unix time in seconds
allowed-datatypes: ['uint32','uint64','int64']
unix-time-ms:
description: Unix time in milliseconds
allowed-datatypes: ['uint32','uint64','int64']
iso8601:
description: Date and Time expressed as a string according to ISO 8601
allowed-datatypes: ['string']
ipv4:
description: Internet Protocol version 4
allowed-datatypes: ['string']
ipv6:
description: Internet Protocol version 6
allowed-datatypes: ['string']
13 changes: 0 additions & 13 deletions spec/units.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -214,19 +214,6 @@ years:
quantity: duration
allowed-datatypes: ['numeric']

# Datetime

unix-time:
definition: Number of non-leap seconds which have passed since 00:00:00 UTC on Thursday, 1 January 1970
unit: UNIX Timestamp
quantity: datetime
Copy link
Collaborator

Choose a reason for hiding this comment

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

We need to discuss if we still want to use something like quantity for formats, to indicate that some formats represent the same type of content, like if you use iso8601 you could possibly convert it to unix-time-ms, but not to ipv4.

If we do not want to reuse the quantity concept then we should possibly remove datetime from the quantity file.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good point. I did not think about quantities so much here

allowed-datatypes: ['uint32','uint64','int64']
iso8601:
definition: Date and Time expressed as a string according to ISO 8601
unit: ISO 8601
quantity: datetime
allowed-datatypes: ['string']

# Pressure

mbar:
Expand Down
Loading