VSS to VHAL mapper.

[jankubovy]

This mapper should serve as a basis for the ongoing generic VHAL discussions. See the docs/vhal.md for more information.

[mikehaller]

Would you be able to provide an example vss_to_android_property_map.json ?

[jankubovy]

Would you be able to provide an example vss_to_android_property_map.json ?

Just generate one with:
vspec export jsonvhal --vspec /path/to/vehicle_signal_specification/spec/VehicleSignalSpecification.vspec --min-property-id 32768 --vhal-map vss_to_android_property_map.json --output-dir /path/to/output

The --vhal-map is input/output. If the file does not exist it will be created. You just need to point to checked out https://github.com/COVESA/vehicle_signal_specification with the --vspec param.

Eventually COVESA should maintain a common vss_to_android_property_map.json but that should be discussed further. For now and testing everyone can just generate their own.

[jankubovy]

Would you be able to provide an example vss_to_android_property_map.json ?

@mikehaller there are minimal examples in the tests if you just want to see how it may look like. E.g. tests/vspec/test_static_uids_vhal/validation_jsons/validation_group_1_min_32768.json

[erikbosch]

MoM:

• Presented at meeting

[slawr]

From the doc (https://github.com/COVESA/vss-tools/blob/a2c86a73c939c0818d88116771461c7186aee2c1/docs/vhal.md#property-change-mode):

STATIC : used to VSS node types ATTRIBUTE and ACTUATOR

Can you explain why an VSS actuator node has a static change mode? Perhaps I misunderstand the meaning of change mode in the mapper.

[jankubovy]

From the doc (https://github.com/COVESA/vss-tools/blob/a2c86a73c939c0818d88116771461c7186aee2c1/docs/vhal.md#property-change-mode):

STATIC : used to VSS node types ATTRIBUTE and ACTUATOR

Can you explain why an VSS actuator node has a static change mode? Perhaps I misunderstand the meaning of change mode in the mapper.

Hi, I have overlooked https://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/sensor_actuator/#actuator-type:

..., can be read and written. ...

should be same as sensor. I will fix that.

[erikbosch]

Still intentionally in draft @jankubovy ?

[jankubovy]

Still intentionally in draft @jankubovy ?

Hi @erikbosch, thanks for asking. Since the AOSP part is now also out I need to just rebase it and then it can be merged.

[erikbosch]

If I understand things correctly you are copying the current vspec and using it as test data. That is fine. But what is the intended approach forward? Shall these files be updated regularly when VSS master branch changes or is it ok to keep them static as long as they work. I was thinking if a small comment here or in a README on the tests are supposed to be maintained could be useful.

[jankubovy]

I have updated the README: https://github.com/COVESA/vss-tools/pull/441/changes#diff-f1415ece96a952959d72922ac30b30733f6a914bda3c055ccafa09afdd9a2c11R108-R115

[erikbosch]

Should be --continuous-change-mode ?

[erikbosch]

Also for the JSON files mentioned here - do we have any example files? I think it could have an example of the syntax for both vhal-map and continuous-list as well as example files so you easily could test out the tool.

In VSS we have as part of https://github.com/COVESA/vehicle_signal_specification/blob/master/.github/workflows/buildcheck.yml calls to Makefile to execute all exporters. If we would have a very simple example file just including say 5 stable VSS signals we could use that in VSS Continuous Integration for a sanity check that things seems still to work when VSS catalog changes.

[jankubovy]

I have added an explanation to the example: --continuous-change-mode is shown above, --vhal-map does not need to exist - it will be created upon first run.

[jankubovy]

I can add some example in the Makefile of vehicle_signal_specification later :)