We intend to represent different common data sampling campaigns (eg commercial fleet, EV range prediction, insurance etc) and others might use these conventions for partner or purpose specific campaigns - a company might want to request different signals be collected instead of or in addition to a common campaign.
We expect both VSS and these defined sampling campaigns to evolve.
Idea is to leverage and build on versioning as it exists in VSS.
From VSS:
#
VSS Versioning information
#
VersionVSS:
type: branch
description: Supported Version of VSS.
VersionVSS.Major:
datatype: uint32
type: attribute
default: 4
description: Supported Version of VSS - Major version.
VersionVSS.Minor:
datatype: uint32
type: attribute
default: 1
description: Supported Version of VSS - Minor version.
VersionVSS.Patch:
datatype: uint32
type: attribute
default: 0
description: Supported Version of VSS - Patch version.
VersionVSS.Label:
datatype: string
type: attribute
default: 'dev'
description: Label to further describe the version.
comment: COVESA VSS project typically use dev for latest master, and empty string for released versions.
Represents VSS version 4.1.0.dev
We can leverage VersionVSS.Label for our named data campaigns but feel we would be well served to add another field in the overlay providing a URI to the campaign represented in YAML (JSON or other). We should stick to the same numeric versioning convention for the campaign itself.
A commercial vehicle campaign could have VersionVSSLabel: dev.CommercialVehicle-1.0.3
It's full version would be VersionVSS: 4.1.0.dev.CommercialVehicle-1.0.3
Which specific sampling campaign data was collected under should be relayed to the server back end.
It would be possible to have the campaign URI be a link to the latest version and means to update the sampling campaign. OEM will likely want to moderate so the link could be to a server they maintain.
We intend to represent different common data sampling campaigns (eg commercial fleet, EV range prediction, insurance etc) and others might use these conventions for partner or purpose specific campaigns - a company might want to request different signals be collected instead of or in addition to a common campaign.
We expect both VSS and these defined sampling campaigns to evolve.
Idea is to leverage and build on versioning as it exists in VSS.
From VSS:
#
VSS Versioning information
#
VersionVSS: type: branch description: Supported Version of VSS.
VersionVSS.Major: datatype: uint32 type: attribute default: 4 description: Supported Version of VSS - Major version.
VersionVSS.Minor: datatype: uint32 type: attribute default: 1 description: Supported Version of VSS - Minor version.
VersionVSS.Patch: datatype: uint32 type: attribute default: 0 description: Supported Version of VSS - Patch version.
VersionVSS.Label: datatype: string type: attribute default: 'dev' description: Label to further describe the version. comment: COVESA VSS project typically use dev for latest master, and empty string for released versions.
Represents VSS version 4.1.0.dev
We can leverage VersionVSS.Label for our named data campaigns but feel we would be well served to add another field in the overlay providing a URI to the campaign represented in YAML (JSON or other). We should stick to the same numeric versioning convention for the campaign itself.
A commercial vehicle campaign could have VersionVSSLabel: dev.CommercialVehicle-1.0.3 It's full version would be VersionVSS: 4.1.0.dev.CommercialVehicle-1.0.3
Which specific sampling campaign data was collected under should be relayed to the server back end.
VersionVSSCampaign: https://github.com/COVESA/commecial-vehicle/releases/CommercialVehicle-1.0.3
It would be possible to have the campaign URI be a link to the latest version and means to update the sampling campaign. OEM will likely want to moderate so the link could be to a server they maintain.