Update Driver.vspec: Introduction & FatigueLevel

[hongkicha]

Hi, I'd like to update Driver.vspec.

The updates include: Introduction & FatigueLevel

[erikbosch]

Hi!

Thank you for your proposals. For them to be considered you must add a signoff to the commits, see https://www.covesa.global/contribute

In git you can add a signoff to an existing commit by git commit --amend -s.

There are also some linter errors like trailing blanks that cause CI checks to fail

[erikbosch]

Meeting notes:

• Please review

[slawr]

As an aside, it feels like this is a topic that could be added to a backlog list for improving data quality. Here better defining how the level is calculated and or interpreted.

[ppb2020]

This PR raises quite a few questions.

Clearly, the information provided by this signal is inferred from a model. Thus, there should be some confidence level associated with the value reported here. Or is it the confidence level that is reported here?

For signals that are model-generated, should there be additional information such as confidence level? Precision? Accuracy? If so, should they be separate signals or should VSS have additional elements to report this information for model-generated node?

Why would we have separate fatigue level and attention level? Attention level would seem to be more useful and more general. It would include not only fatigue, but driver looking at their cell phone, radio, passenger, etc.

As well, should we consider providing not only the "result" (fatigue level here), but also the signals/data from which this level was evaluated? The PR lists a number of factors that are considered. Should not each of these factors and their values be provided as well or instead? This would make it possible for other models to use the same data, use less data, or even use more. There are already some of these factors in the catalog: distraction level, eyes on road, attentive probability.

The description of the DMS already states: "Driver data is the foundational input that the DMS (Driver Monitoring System) uses to assess, analyze, and ensure the driver's alertness, safety, and overall driving condition." Hence, should the signals be the result of the model-based analysis of the various factors or only be the set of factors, and moving the calculated/inferred results somewhere else?

I think the whole area requires deeper discussion; possibly a topic for a side meeting at the AMM (although it may be too late to add to the agenda).

[ppb2020]

One more thought. I have not looked at this in detail, but these kinds of signals always bring the question of "direction". Just like for windows, is 100% representing fully open or fully closed? It depends on the name of the signal. Nonetheless, there is value in trying to align the "direction" of signals, such as deciding on whether we represent percentage of open or closed and use the same representation for other similar signals (all of them representing open or all of them representing closed).

Here, this is defined as FatigueLevel, so this is clearly 100% means fatigued. But for alertness level, 100% would be fully alert (the opposite direction as fatigued). In the same vein, distracted level would be in the same "direction" as fatigue level, but the reverse of alertness level.

Thus, do we need to or want to have some specification of a preferred direction? If not, we should probably have some guidance on naming conventions...

Apologies for the ramblings.

[erikbosch]

The "Driver" signals/datapoints have practically not been touched in the last years, and as seen in the discussion on this PR there are obviously areas that can be improved. I think this PR is a step in the right direction, but if there would be multiple parties interested in this area it could be an idea to form a subgroup or have a separate meeting on what needs to be done in this area to come up with a consistent proposal on needed changes, similar to what previously have been done for EV charging and power optimization. If there is an interest I believe @paulboyes can coordinate.

[hongkicha]

@erikbosch @slawr @ppb2020 Hi, this is Hongki. Thanks for your comments. We're having our Thanksgiving holiday in Korea until Tuesday. Considering the signed-off and other errors, I use GitHub Chrome directly, so I'm not sure how/where I can enter the command line. If necessary, I can set up my computer after I get back to my office. I'm attending next week's COVESA AMM, and if possible, we can meet there and talk about how to proceed.

[erikbosch]

Meeting notes:

• If you are interested in improving this area please indicate your interest
• Pierre: Blackberry has interest

[hongkicha]

Meeting notes:

• If you are interested in improving this area please indicate your interest
• Pierre: Blackberry has interest

ETRI has interest

[erikbosch]

Meeting notes:

• Please review/discuss

[erikbosch]

@ppb2020 - how do you think that we can drive this forward? I am thinking if a separate meeting between you and @hongkicha, possibly coordinated by @paulboyes would make sense to align or agree on a reasonable way to drive work or identify potential improvements in this area. Or if you rather want to suggest improvements or updates to this PR?

[ppb2020]

@erikbosch, To answer your earlier question, I think we can separate the discussions on this PR from the more general discussions. That is, deal with this PR on its own merit and move the more general discussion to another forum (be it a separate meeting, an birds of a feather discussion, or a new issue tracked in GitHub).

My current thinking (open to changing) on the general issue is that the signals in the COVESA signal catalog should not be subject to interpretation. "Raw" signals should be in the COVESA signal catalog and be clearly defined. For examples, IsHandsOnWheel is relatively raw. Signals that do not have a clear interpretation or whose interpretation could differ based on how they were produced (such as generated or synthesized signals, like FatigueLevel), should not be in the COVESA signal catalog and should instead be added using overlays by the respective OEMs or others who know how they are produced and have their own interpretation as to what they mean.

If we went that way, the COVESA signal catalog would become closer to a standard that can be enhanced "locally" with other generated (instead of raw) signals by each manufacturer. When signals are submitted for review, one of the criteria would be whether the signal's definition can be written in such a way to avoid misinterpretation. In that context, the change proposed in this PR would not be accepted as it is, given we are (at least for now) unable to define exactly what a driver fatigue level of 35% means (let alone how it could be used).

Now, there are already other signals, such as DistractionLevel, similar to the one being proposed in the sense of leaving a lot to interpretation. From that perspective, we could indeed allow the addition of FatigueLevel in this specific PR. In that case, I would like to discuss what we expect the relationship to be between DistractionLevel and FatigueLevel. Does fatigue lead to more distraction? If I am writing an application, which one of the two do I care about? Is there a need to make a difference between distraction level and fatigue level? These would be the questions I would try to answer in order to determine if there is value in adding this new signal.

I would also consider whether the signal would be used by anyone else than the manufacturer interested in adding this signal to the COVESA signal catalog. In other words, should this instead be something added locally using an overlay instead of adding it to the "reference" signal catalog?

Just my $0.02.

[ppb2020]

Re-adding this as I originally added it as a comment and it appears earlier in the discussion timeline instead of here...

Further thoughts. Is this signal indeed reflecting the driver's fatigue level or instead the probability that the driver is fatigued? It sure seems that the probability would be more of interest than the actual level. If indeed this is the probability, the signal would need to be renamed and the description would need to refer to probability instead of level.

[erikbosch]

My suggestion - from the comments it seems that there are lot of uncertainty on how FatigueLevel shall be used and what it means and how it is related to AttentiveProbability. This PR in itself as of today just adds some examples on what can be considered when calculating FatigueLevel but does not really say how it shall be calculated and what different values mean. I suggest we keep this PR on hold for now until a someone propose a more thorough definition/declaration of the signals.

[erikbosch]

Meeting notes:

• Daniel: We should stick to objective metrics
• Pierre: We need to be clear if there is a standard or if it subjective, if subjective maybe better part of overlay

[ppb2020]

Some of the questions raised against this PR were discussed at the 2024 April AMM. We did not reach hard conclusions on how to handle these kinds of signals, although we did make progress on better understanding the problem. Given this "status quo", there is no recommendation at this time on how to handle signals within the COVESA signal catalog whose definition may vary between manufacturers. There is a slight preference for more descriptive values than percentages, such as a set of enums "bucketizing" the various levels (see the Karolinska Sleepiness Scale, for example). However, in many cases the interpretation of the level represented by each enum value may also vary based on culture, context, etc.

Best is when the signal values can be expressed by referencing an established (or even de facto) standard. In the absence of such a standard, one option is to "define our own". Another option is to leave the signal value as a range (such as a percentage), but note in the comments that the expectation is that each manufacturer is free to have their own definition and interpretation of the value. It is left to the manufacturers to provide a definition or description of what their interpretation of the values are (and how best to provide this information), such that a third party coding an application that uses the signal understands how to use it.

For the more immediate question of how to handle the proposed signal herein, I would suggest the following options to choose from:

1. Not include the signals in the COVESA signal catalog and leave it to individual manufacturers to define their own using overlays.
2. Define our own set of "buckets" and define the values through enums instead of percentages.
3. Leave the definition as a percentage, but add a comment that explains the interpretation of the value is left to implementation by each manufacturer.

For 1., it is to be noted that there are at least two clear values for FatigueLevel: 0% - alert, 100% - "dead tired". Thus, there may still be value in introducing the signal in the COVESA catalog instead of deferring to each manufacturer. As well, defining the signal provides "an anchor" whereby there is some uniformity on how this signal is named across manufacturers.

I would personally have a slight preference for 2., but any of the above would be acceptable to me.

[ppb2020]

Of possible relevance is documents such as this EURO NCAP specification, especially section 3.5.3 on detection of driver state and section 3.5.3.2 on Fatigue, which defines three factors: drowsiness, microsleep, and sleep.

[erikbosch]

I like the link you provided to Euro NCAP. It gives my some ideas that we could have some derived signals like below to represent the conclusions that Euro NCAP expects from the OEM, and then possibly add some additional objective values, like a signal to represent whether eyes are shut or not. Might be more useful than an undefined percentage value like currently in this PR. One could off course consider allowing float values for a KSS scale value, to allow for OEMs to calculate the value with decimals if they would like to and then you come very close to a percentage scale 0-100%.

Signal	Type	Comment
Sleepiness	uint8	As estimated by OEM, KSS Scale
IsDrowsy	bool	Exact definition by OEM based on Euro NCAP recommendations
IsMicroSleeping	bool	Exact definition by OEM based on Euro NCAP recommendations
IsSleeping	bool	Exact definition by OEM based on Euro NCAP recommendations

[erikbosch]

MoM:

• PP: Like proposed values from NCAP. Unclear if they are mutually exclusive, possible use enum and a single value
• PP: For KSS, use enum or value
• Erik: Please continue discussions

[erikbosch]

We discussed old VSS Pull Requests briefly at the latest weekly VSS meeting. We are considering closing old pull requests where there have not been any progress or discussion lately, but would be glad to get your input. If you consider the PR still relevant and have time to work on it or discuss it in the near future please rebase it on latest VSS and I will bring it up on one of the next VSS-meetings (weekly on Tuedays 16.00 CET). If not we may opt for closing it, which off course does not prevent you from reopening it later.