Feature/structure engine fluids

[kowend]

Several engine oil and coolant related attributes where spread in the main branch of the combustion engine.
The engine oil and coolant have been put under a branch.
Additional coolant lifespan and level (ISO 7000 2429) have been added under the coolant branch.

[erikbosch]

Topics to discuss:

• This is right now considered as a "major" change (to be included in a major release only) as some signals will change name
• Alternatively, one could for now "keep" the old names (in addition to the new ones) but mark them as deprecated

[kowend]

I think marking them as deprecated is fine, and leave them in. Is there any standard/rule for removing deprecations?
I can imagine we don't want too many deprecations left in the specs.

For which version would these signals then be deprecated?

[kowend]

Ah nevermind about the rule for deprecation. I found the description in the basics.md. But knowing the version for deprecation would still be useful. Would that be v5.0?

[erikbosch]

Ah nevermind about the rule for deprecation. I found the description in the basics.md. But knowing the version for deprecation would still be useful. Would that be v5.0?

Possibly. Historically we have selected "next release" as "deprecated from", but right now we have not really decided if we will release a 4.2 or if next release will be 5.0. I would say that 5.0 is the best option for now for main, if we decide to create a 4.2 then we as maintainers should anyway check all deprecation comments and adjust version if needed, like replacing 5.0 with 4.2 for the maintenance branch.

[kowend]

Clear! I'll add the deprecation attributes.
I've realised that the electrical motor could also have a cooling compartiment. At least the coolant temperature is mentioned as an optional.
I've moved the coolant branch into a separate spec file.

[ppb2020]

A few minor comments.

[ppb2020]

2016 -> 2024?

[erikbosch]

In one way 2016 can make sense, as some of the signals actually have been copied from another file and maybe they were added in 2016, I have not checked. So even if the file is created 2024, the content is older

[ppb2020]

Should this also have a HIGH and CRITICALLY_HIGH level as for EngineOil.Level?

[erikbosch]

It would at least not hurt. I actually do not know what sensors modern high-end vehicles have for coolant; like can they detect and report that there is too much coolant?

[ppb2020]

I don't know enough about the mechanisms, but one possibility may be that the same kind of sensor could be used for both, for example. As well, what I am proposing seems to provide consistency that could be reused for other "level" sensors (washer fluid, transmission fluid, etc.). We do have another issue tackling common signals. Maybe we should consider a fluid-level signal that can be re-used for all these kinds of sensors?

[kowend]

I did consider reusing this and have the same enums. Technically I don't know what a typical sensor for the coolant could do; From a functional perspective I don't know if it makes sense to have HIGH and CRITICALLY_HIGH. For the engine oil I can imagine that having the right amount between 2 thresholds is important. But with coolant I don't think there is an upper threshold (other than you'll probably get wet shoes).
ISO 7000 2429, which is meant for the coolant level telltale describes 'low' or 'out of specified values'. In that case it would maybe make more sense to have something like 'NORMAL', 'LOW', 'CRITICAL'.

[erikbosch]

MoM:

• Please review

[erikbosch]

MoM:

• Pierre Pierre not present
• Merge decision next week unless comments/remarks

[erikbosch]

MoM:

• Pierre on vacation, keep open. He is back next week

[erikbosch]

MoM:

• Possible merge decision next week
• @ppb2020 could you check if it is ok

[ppb2020]

I have no further comments. I am fine with the responses that were provided, with a note that I am still slightly in favour of reusing the set of enum values, but not enough to block merge.

[erikbosch]

MoM:

• Merge