...
where complex translation is described with another language considered in different ticket
NOTE: The first analysis of translation and description of linear-equation translation is in
Jira | ||||||
---|---|---|---|---|---|---|
|
How to describe the complex translations
...
By the above it means that: To translate the Vehicle.Powertrain.FuelSystem.Level
into 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
- Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure
aospId: VehicleProperty::TIRE_PRESSURE
aospArea: VehicleAreaWheel::LEFT_FRONT
- Vehicle.Chassis.Axle.Row1.Wheel.Right.Tire.Pressure
aospId: VehicleProperty::TIRE_PRESSURE
aospArea: VehicleAreaWheel::RIGHT_FRONT
- Vehicle.Chassis.Axle.Row2.Wheel.Left.Tire.Pressure
aospId: VehicleProperty::TIRE_PRESSURE
aospArea: VehicleAreaWheel::LEFT_REAR
- Vehicle.Chassis.Axle.Row2.Wheel.Right.Tire.Pressure
aospId: VehicleProperty::TIRE_PRESSURE
aospArea: VehicleAreaWheel::RIGHT_REAR
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.
Example:
- Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure
AOSP:
version: 2.0
package: android.hardware.automotive.vehicle
id: VehicleProperty::TIRE_PRESSURE
area: VehicleAreaWheel::LEFT_FRONT
ANY_OTHER_OPERATING_SYSTEM_OR_IPC:
version: 1.0
package: com.oem.foo
other_data_for_translation: true
Pros:
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.
Cons:
VSS Leaf starts to be a complex structure
Translation description
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)
- Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure
aospId: VehicleProperty::TIRE_PRESSURE
aospArea: VehicleAreaWheel::LEFT_FRONT
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.
- Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure
aospId: VehicleProperty::TIRE_PRESSURE
aospArea: VehicleAreaWheel::LEFT_FRONT
aospTranslationFromVSS:
k: 1000
m: 0
Approaches to define and evaluate calculation formula
- Use RPN because it is easy to parse and process, no precedence rules to enforce etc.
- Use standard math expression (with parantheses) and create a parser/interpreter
- Copy standard math expression directly into target language (works in most cases)
=> Approach 3 seems to be our preference for now.
Next Actions
Feedback from VSS working group about general strategies for metadata (hierarchical?) Gunnar Andersson
Start work on code generator in vss-tools/contrib, output according to chapter "How to describe the complex translations" above.
- Question: Introduce templating language (JINJA2) in vss-tools? It is used in vsc-tools and could be useful also for VSS for more complex code generation than we have today.
- Stefan awaiting approval to publish "hard-coded" example code.