By the above it means that: To translate the
VehicleProperty::FUEL_LEVEL the result value is = VehicleProperty::INFO_FUEL_CAPACITY * / 100.
There is a need to provide a way to bind enumerations, whether by meta language (see ticket [How to describe the complex translations] ).
In Android: Subscribe for TIRE_PRESSURE for left-front wheel. In VSS is more flexible (the entities of TIRES can be more than 4)
There is a need for inverse to use "setProperty" from Android partition
Multiple instances of signal
Introduced new example: The Tire Pressure signal which has multiple instances in the car
The idea is to have each VSS leave mapped to a specific pair aospId + aospArea. In Android types. hal defines multipe areas (generic and some signal specific). See https://developer.android.com/reference/android/car/VehicleAreaWheel https://developer.android.com/reference/android/car/VehicleAreaSeat
It is not sufficient for all Car configurations. Open questions:
* When the Car has multiple "rows", which AOSP Area should be chosen to query for "Right rear" * What if the CAr has multiple tires on each side and axle?
Namespace "Android specific fields in VSS leave"
Current proposal includes the prefix "aosp" for each aosp-specific "decoration" of VSS Leaf object.
Proposal of using the namespace to group the AOSP specific fields + adds some meta fields with versioning and other needed informations.
AD: Core fields for each namespace can be standardized inside Genivi.
the fields introduced in namespaces can be kept in other vss layer files - less maintenance cost of conflicting field names
Enables clean code generation.
Relevant only during development process.
VSS Leaf starts to be a complex structure
There is a need to translate the value from VSS to AOSP and vice versa when the signal originates in Android. For complex equations (like FuelLevel) there is no straight forward way for the compiler to inverse the translation.
Define the fields for bi-directional translations
To solve above we might have 2 fields. translation_set and translation_get (names are chosed arbitrary and are subject to be agreed)
For example when a need to convert from kpa(vss) to pa(aosp)
aospTranslationFromVSS: "_VAL_ / 1000"
aospTranslationToVSS: "_VAL_ * 1000"
Focus on non-complex translation like linear
One additional field that represents the linear equation: aospValue = k * vssValue + m. The translation in other direction can be determined.