Handling ACEA FMS / COVESA VSS mapping conflicts

[tguild]

COVESA and the ACEA Fleet Management Standard (FMS) are formally collaborating, mapping their SAE J1939 subset of signals being exposed to fleet owners to VSS to support an onboard API.

We are actively mapping signals in FMS to VSS, identifying gaps and differences, typically unit or type.

For example Vehicle.Powertrain.CombustionEngine.Speed (RPM) in VSS is data type uint16 whereas J1939 and FMS have it as a float.

We will be handling these differences on a case by case basis and see our options as follows:

• Lobby VSS to consider changing data type, unit etc
• Create an overlay in which we redefine the existing signal with a new name and the different definition
• Consider a new release of FMS to better match VSS
• Replace the VSS signal with the new definition in tooling.

Although this last idea seems the least desireable as it would fragment VSS and has the potential to cause complications, the working assumption is that VSS will differ based on the specific make/model vehicle. The number of seats in a two door coupe is different than in a minivan for example.

This too may be a topic for Vehicle Data Model discussion.

Open to other suggestions and want to know how COVESA would like to handle this.

[SebastianSchildt]

I feel a combination of "1" and "3" is best, i.e. discussing the rationale behind some differences.

Also, while you example might be one warranting discussion, I would say if it where reversed, e.g. having a float and FMS want some integer it might not be an immediate issue at all (for reasonable value ranges)

I think VDM - however that might turn out - probably might provide a nice way to "collect/store/reference" a FMS-only related set of data out of the whole standard catalogue, but the underlying question probably remains: What if the underlying signal is represented in two different way?

For trivial things like changing instantiation (i.e. "deployment info), I assume an overlay is fine, and this might get cleaner in VDM, but again, I think the core challenge is discussing/aligning the actual VSS signals.

[erikbosch]

MoM:

• Ted presented issue
• Related to TraveledDistance granularity #822
• E: Quite a lot of discussion on datatype/unit
• Sebastian: We need a default type. Should be discussed on case by case meeting. In some cases VSS is changed, in other FMS:
• S. Would have the same discussion also for VDM

[erikbosch]

MoM:

• Ted: To be handled case by case
• T: Can start with rpm, float instead of int, trivial PR
• E: Suggest creating PR

[tguild]

Although we have a separate and distinct issue with #867 on namespaces, I see it as very closely related to this one.

Ideally, I want to say a particular VSS signal is the exact same as a J1939 or nearly the same and represent the difference in a human and machine readable manner. I have been looking around and have not yet found an existing convention on how to represent definition differences, closest so far is SKOS which categorizes how closely they may align and more suitable for an ontology (or Graph effort in VDM) than YAML.

https://www.w3.org/TR/skos-reference/#mapping

For YAML, YAML-LD would be good for namespace references to the other specs (J1939, VHAL, Sensoris) but do not see how it can address differences. I found YAML script which could provide us with conditional logic and mathematical expressions for converting unit differences.

https://yamlscript.org/doc/

ACEA Fleet Management Standard (FMS) is backed by J1939 and in production trucks, buses, construction equipment etc for a number of years. The earlier option mentioned of seeing if we can influence FMS (and subsequently J1939) is impractical to the point of impossible. The idea of bringing up signals on a case by case basis isn't desireable, we have a couple that have been outstanding for awhile EngineSpeed - RPM in this issue although lacking a PR and TraveledDistance granularity, data type and unit differences respectively.

The HD truck OEM are fine with VSS with overlays or additional branches to provide VSS needed for a given make/model of truck. One option being played with is gomplate. They want an assurance that VDM will not break the modular vspec files of VSS.

https://docs.gomplate.ca/syntax/

[tguild]

Under discussion in VDM

https://covesa.github.io/s2dm/1-approach-overview/index.html

[erikbosch]

MoM:

• Ted: Discussions ongoing, on e.g. how tree structure should look like, involving .e.g. Scania, Volvo, Bosch