Describe the feature
When testing an ADAS system, some of the behaviours you want to test are notifications that would be sent to a human driver. For example a Blind Spot Warning (BSW) might be an indication on wing-mirror, or a Forward Collision Warning (FCW) may result in a dashboard or audible warning.
At the moment, there is no way for a traffic participant to provide any indication that such a notification was raised which means that such features cannot be detected by external systems for verification purposes.
Describe the solution you would like
After discussions in the OSI architecture meetings, consensus was around adding this to the existing VehicleClassification message, which is inside a MovingObject. This would allow:
- Reporting of this information as part of
GroundTruth
- Publishing of this information as part of a
TrafficUpdate
In general, we want to have "well known" features and states to be captured via enums, but also allow for customisation where necessary.
Describe alternatives you have considered
In would also be possible for the CustomNotification to be a new top level message rather than being inside the existing MovingObject message. The downside of this is that often this will be coupled with existing output from a component so then you need to correctly correlate this state with those messages. Also, moving out to a new top level message could be achieved at a later date as the requirement arose.
Describe the backwards compatibility
All new fields are optional so there are no backwards compatibility issues.
Additional context
The different ADAS features and recognised terminology can be found here.
Describe the feature
When testing an ADAS system, some of the behaviours you want to test are notifications that would be sent to a human driver. For example a Blind Spot Warning (BSW) might be an indication on wing-mirror, or a Forward Collision Warning (FCW) may result in a dashboard or audible warning.
At the moment, there is no way for a traffic participant to provide any indication that such a notification was raised which means that such features cannot be detected by external systems for verification purposes.
Describe the solution you would like
After discussions in the OSI architecture meetings, consensus was around adding this to the existing
VehicleClassificationmessage, which is inside aMovingObject. This would allow:GroundTruthTrafficUpdateIn general, we want to have "well known" features and states to be captured via enums, but also allow for customisation where necessary.
Describe alternatives you have considered
In would also be possible for the
CustomNotificationto be a new top level message rather than being inside the existingMovingObjectmessage. The downside of this is that often this will be coupled with existing output from a component so then you need to correctly correlate this state with those messages. Also, moving out to a new top level message could be achieved at a later date as the requirement arose.Describe the backwards compatibility
All new fields are optional so there are no backwards compatibility issues.
Additional context
The different ADAS features and recognised terminology can be found here.