Date: Thu, 28 Mar 2024 23:33:30 +0000 (UTC) Message-ID: <2005797142.30.1711668810784@ip-172-31-8-223.us-west-2.compute.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_29_1365907033.1711668810780" ------=_Part_29_1365907033.1711668810780 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
There is a need to store the mapping between the VSS and Android propert= ies. The following needs to be considered:
As an example, it might look like
- Vehicle.Powertrain.FuelSystem.Level
=09aospId: VehicleProperty::FUEL_LEVEL
=09aospArea: VehicleArea::Global
=09translation:=20
=09 =09-complex: =E2=80=9E$INFO_FUEL_CAPACITY * _VAL_ / 100=E2=80=9D
where complex translation is described with another language considered = in different ticket
NOTE: = The first analysis of translation and description of linear-equation transl= ation is in
There is a need to store how to translate the signal from VSS to Android= Property. The idea is to have some meta language that can use the referenc= es to the other signals and mathematical equations
As an example
- Vehicle.Powertrain.FuelSystem.Level
=09translation:=20
=09 =09-complex: =E2=80=9E$INFO_FUEL_CAPACITY * _VAL_ / 100=E2=80=9D
By the above it means that: To translate the Vehicle.Power=
train.FuelSystem.Level
into VehicleProperty::FUEL_LEVEL
=
the result value is =3D VehicleProperty::INFO_FUEL_CAPACITY * / 100.
It means that this should be generated to something like:
conversionMap["Vehicle.Powertrain.FuelSys=
tem.Level"] =3D std::bind(convertFuelLevel,
std::placeholders::_1, VehicleProperty::FUEL_LEVEL, toInt(Vehic=
leArea::GLOBAL));
// ...
static VehiclePropValue convertFuelLevel(std::string value, VehicleProperty=
id, int32_t area) {
VehiclePropValue prop =3D initializeProp(id, area);
uint8_t valInt =3D std::stof(value);
float mililiters =3D GET_PROP(VehicleProperty::INFO_FUEL_CAPACITY) * va=
lInt / 100;
prop.value.floatValues =3D std::vector<float> { mililiters };
return prop;
}
There is a need to provide a way to bind enumerations, whether by meta l=
anguage (see ticket [How to describe the complex translations] ).
In Android: Subscribe for TIRE_PRESSURE for left-front wheel. In VSS is mor=
e flexible (the entities of TIRES can be more than 4)
For the AOSP Props that have multiple instances, another level of bindin= g needs to be introduced.
By idea the VHAL implementation is using the map between the VSS and And= roid Properties to translation:
VehiclePropValue aospValue =3D conversion=
Map[vssId](vssValue);
Conversion map fragment:
conversionMap["Vehicle.Powertrain.FuelSy=
stem.Level"] =3D std::bind(convertFuelLevel,
std::placeholders::_1, VehicleProperty::FUEL_LEVEL, toInt(Vehic=
leArea::GLOBAL));
The map can be included as a header file during compilation from the dep= loyment files described in other ticket.
There is a need for inverse to use "setProperty" from Android partition<= /p>
Introduced new example: The Tire Pressure signal which has multipl= e instances in the car
- Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure
aospId= : VehicleProperty::TIRE_PRESSURE
&nb= sp; aospArea: VehicleAreaWheel::LEFT_FRONT
- Vehicle.Chassis.Axle.Ro= w1.Wheel.Right.Tire.Pressure
= aospId: VehicleProperty::TIRE_PRESSURE
&nb= sp; aospArea: VehicleAreaWheel::RIGHT_FRONT
- Vehicle.Chassis.Axle.Row2.Wheel.Left.Tire.Pressure
&n= bsp; aospId: VehicleProperty::TIRE_PRESSURE
&nbs= p; aospArea: VehicleAreaWheel::LEFT_REA= R
- Vehicle.Chassis.Axle.Row2.Wheel.Right.Tire.Pressure
&nb= sp; aospId: VehicleProperty::TIRE_PRESSURE
aospArea: VehicleAreaWheel::RIG= HT_REAR
The idea is to have each VSS leave mapped to a specific pair aospI= d + aospArea. In Android types. hal defines multipe areas (generic and some= signal specific). See https://developer.android.com/ref= erence/android/car/VehicleAreaWheel = https://developer.android.com/reference/android/car/VehicleAreaSeat<= /a>
It is not sufficient for all Car configurations. Open questions: <= /span>
* When the Car has multiple "rows", which AOSP Area should be chos= en to query for "Right rear" * What if the CAr has multiple tires on each s= ide and axle?
Current proposal includes the prefix "aosp" for each aosp-specific= "decoration" of VSS Leaf object. Proposal of using the namesp= ace to group the AOSP specific fields + adds some meta fields with versioni= ng and other needed informations.
AD: Core fields for each namespace can be standardized inside Geni= vi.
Example:
- Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure
&n= bsp; AOSP:
version: 2.0
&n= bsp; package: android.hardware.automotive.vehicle
&nbs= p; id: VehicleProperty::TIRE_PRESSURE
&nbs= p; area: VehicleAreaWheel::LEFT_FRONT &n= bsp;
ANY_OTHER_OPERATING_SYSTEM_OR_IPC:
&= nbsp; version: 1.0
 = ; package: com.oem.foo
other_data_for_tra= nslation: true
Pros:
the fields introduced in namespaces can be kept in other vss l= ayer 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
There is a need to translate the value from VSS to AOSP and vice v= ersa when the signal originates in Android. For complex equations (like Fue= lLevel) there is no straight forward way for the compiler to inverse the tr= anslation.
To solve above we might have 2 fields. translation_set and transla= tion_get (names are chosed arbitrary and are subject to be agreed)= p>
For example when a need to convert from kpa(vss) to pa(aosp)
- Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure
&n= bsp; aospId: VehicleProperty::TIRE_PRESSURE
aospArea:= VehicleAreaWheel::LEFT_FRONT
aospTranslationFromVSS:= "_VAL_ / 1000"
aospTranslationToVSS: "_VAL_ * 1000"<= /pre>Focus on non-complex translation like linear<= /span>
One additional field that represents the linear equation: aospValue =3D k * vssValue + m. The translation in o= ther direction can be determined.
- Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure
&n= bsp; aospId: VehicleProperty::TIRE_PRESSURE
aospArea:= VehicleAreaWheel::LEFT_FRONT
aospTranslationFromVSS:=
k: 1000
= m: 0Approaches 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/int= erpreter
- Copy standard math expression directly into target language (works= in most cases)
=3D> Approach 3 seems to be our preference for now.<= /p>
Next Actions
Feedback from VSS working group about general strategies for metadat= a (hierarchical?) Gunnar Andersson=
Start work on code generator in vss-tools/contrib, output according = to chapter "How to describe the complex translations" abov= e.