Service Indicator datapoints

[erikbosch]

In #180 ACEA list a lot of datapoints related to service, but with no extra information on any of them:

7. Service Indicator
8. Distance to next service
9. Time to next service
25. Distance until Engine Oil Service
28. Remaining Brake Fluid Life
29. Distance Until Brake Service
30. Due date for Brake Fluid Change
32. Time until next required oil change

VSS has only one attribute related to service:

Vehicle.Powertrain.CombustionEngine.OilLifeRemaining

Other known APIs typically include datapoints related to service, see references below. It seems to be quite common to have at least 2 datapoints, time and range to next service. The other datapoints listed by ACEA above does not seem to be commonly used in public APIs. It is also possible that OEMs might have other datapoints or service intervals as well (e.g. for air filter change, HVAC filter change, transmission oil change, coolant change, timing belt change, spark plug replacement, airbag inspection, ...)

Topics to discuss:

• I suggest that we at least add two datapoints, initial suggestion: “Vehicle.TimeToService” (seconds?, float?) and “Vehicle.DistanceToService” (meter?, float?) to VSS.
• But do we want to add others as well, or wait until we see that they really are needed? I do not know what values vehicles typically maintain internally. (But nothing says that the datapoint needs to be maintained "inside" the car)
• Shall we allow negative values (to indicate service overdue by X seconds/meter)
• Do we need a separate “service indicator” ? Or use an implicit definition “(TimeToService<=0) OR (DistanceToService<=0)).
• I suggest that we deprecate Vehicle.Powertrain.CombustionEngine.OilLifeRemaining. Alternatively change it to being a sensor value (it is as of now an attribute)

Volvo: https://developer.volvocars.com/volvo-api/extended-vehicle/

kmToService (km), 
monthsToService (months, integer), 
serviceWarningStatus (NORMAL, ALMOST_TIME_FOR_SERVICE, TIME_FOR_SERVICE, TIME_EXCEEDED), 
serviceWarningTrigger (CALENDAR_TIME, DISTANCE, ENGINE_HOURS, ECM)

Mercedes: https://developer.mercedes-benz.com/products/connect_your_fleet/details

Service.Interval.Distance (Residual distance to service, km), 
Service.Interval.Time (Residual time to service, days)

[danielwilms]

Proposal following by @erikbosch

[erikbosch]

A proposal for discussion added in #261.

When investigating the ACEA list further it turns out that the term "service" is not that well defined, and in the proposed ACEA list there is no good definition of the difference between e.g. "8. Distance to next service" and "25. Distance until Engine Oil Service". OEMs typically use different names for different types of services (e.g. "Intermediate Oil Service", "Oil & Safety Service", "Inspection", "Brake service") but most of them include changing the oil. So it is not clear if "25. Distance until Engine Oil Service" refers to a service where you only change the oil, or any service where the oil will be changed.

Even if some OEMs seems to present distance/time to separate specific activities (e.g. change of brake fluid or replacement of brake Pads and disc/rotor) it seems that many OEMs only present a generic distance/time to service, like in the Volvo/Mercedes API above. By this reason the proposal for now is to not add any more detailed signals.

The proposal includes in total 3 signals:

DistanceToService/TimeToService

Defined as distance/time until the vehicle needs to visit the garage for any service activity. It could be for change of oil, or for a more extensive service/inspection/check.

ServiceDue

A boolean indicator as requested by ACEA. It can be discussed if we want to add this one. If a vehicle report DistanceToService/TimeToService any user could use their own logic to decide if there is a need for service now or in the near future. A possible condition could be service_due = (DistanceToService < 500 km) or (TimeToService < 30 days). But there might be vehicles that prefer reporting only the boolean indicator, and having an indicator also gives the vehicle (for good and bad) the possibility to control the indicator. This is a bit similar to Brake.BrakesWorn/Brake.PadWear where the report both wear as percent and a boolean indicator.