Feature request: support lookup tables or dictionaries

[jdacoello]

I see the following cases that are related with the lack of a formal (and explicit) machine-readable lookup tables:

• Case A - The use of a predefined set of possible values is expected, but no ALLOWED construct is used.
• Case B - ALLOWED values are defined but their meaning is not explicit.

---

Case A

The use of a predefined set of possible values is expected, but no ALLOWED construct is used.

There are concepts whose description mentions the expected value according to some standard codes. However, the VSS model does not provide a machine-readable reference to that set of values. Hence, the end user is completely responsible to validate the correctness of the actual data assigned to that property, which is prone to errors. For example:

Vehicle.Cabin.Infotainment.HMI.CurrentLanguage:
 datatype: string
 description: ISO 639-1 standard language code for the current HMI
 type: sensor

Vehicle.Powertrain.CombustionEngine.EngineCode:
  comment: For hybrid vehicles the engine code may refer to the combination of combustion and electric engine.
  datatype: string
  description: Engine code designation, as specified by vehicle manufacturer.
  type: attribute

Vehicle.VehicleIdentification.AcrissCode:
  datatype: string
  description: The ACRISS Car Classification Code is a code used by many car rental companies.
  type: attribute

Vehicle.Body.BodyType:
  datatype: string
  description: Body type code as defined by ISO 3779.
  type: attribute

Vehicle.Cabin.Infotainment.HMI.CurrentLanguage:
  datatype: string
  description: ISO 639-1 standard language code for the current HMI
  type: sensor

---

Case B

ALLOWED values are defined as a set of codes whose meaning is not explicit.

The model should be self-explainable in a way that the user can understand the meaning of the data without the need to consult external resources. For example:

Vehicle.ADAS.SupportedAutonomyLevel:
  allowed:
  - SAE_0
  - SAE_1
  - SAE_2
  - SAE_3
  - SAE_4
  - SAE_5
  datatype: string
  description: Indicates the highest level of autonomy according to SAE J3016 taxonomy the vehicle is capable of.
  type: attribute

Vehicle.Powertrain.FuelSystem.SupportedFuel:
  allowed:
  - E5_95
  - E5_98
  - E10_95
  - E10_98
  - E85
  - B7
  - B10
  - B20
  - B30
  - B100
  - XTL
  - LPG
  - CNG
  - LNG
  - H2
  - OTHER
  comment: RON 95 is sometimes referred to as Super, RON 98 as Super Plus.
  datatype: string[]
  description: Detailed information on fuels supported by the vehicle. Identifiers originating from DIN EN 16942:2021-08, appendix B, with additional suffix for octane (RON) where relevant.
  type: attribute

---

Suggestion

Define a mechanism to include lookup tables (or dictionaries) that allow the user to easily interpret or process the codes or allowed values.

[erikbosch]

Is this a request of support for some type of enum-support where we with some synatx (VSS-like or totally different) give a more formal definition? Like for Vehicle.Powertrain.FuelSystem.SupportedFuel, one could think of defining something like:

FuelType:
  - key: E5_95
    definition: Gasoline with at most 5% ethanol, fulfilling requirements in DIN EN 16942:2021-08, appendix B, and with at least 95 Octane RON
  - key: E5_98
    definition: Gasoline with at most 5% ethanol, fulfilling requirements in DIN EN 16942:2021-08, appendix B, and with at least 98 Octane RON

... and then the signal could specify that it use FuelType.

I think that is feasible where we in COVESA has defined the list and the list is of limited length, but more complex in other areas like:

• Language codes (ISO 639-1) - the list is long and it would be quite some work to create a list of our own. On the other hand - maybe some machine readable representation already exist somewhere that we could reuse?
• ACRISS codes - the number of possible combinations is quite big (18226*18=42768) - so how should a table/dictionary look like? For this case maybe a regexp would be better? Or some form of "combined" dictionary, say that a value consist of keys from 4 dictionaries without separator.

[jdacoello]

I am pointing out the need for machine-readable lookup dictionaries. Some concepts in VSS define the meaning of their actual expected values within the description. However, in practice, the end user must implement the interpretation on his own. Here is another example:

Vehicle.Powertrain.Transmission.SelectedGear:
  datatype: int8
  description: The selected gear. 0=Neutral, 1/2/..=Forward, -1/-2/..=Reverse, 126=Park, 127=Drive.
  type: actuator

As you can see, the actual meaning is encoded as text in the description.