WG SXL Standardization 2024-07-02

[emiltin]

Participants

David, Emil

Traffic data

We want to start with these simple types:

• Count
• Speed
• Classification
• Occupancy (percentage)
• Presence (on/off)

Data is send and aggregated using the current RSMP 3 subscription mechanism. But we could consider adding a 'batch' flag to core, so you can get a package once in a while with more detailed data, to reduce overhead.

Per detector logic, or for all detector logics?

If this SXL arrives together with RSMP 4, the subscription/streaming model might be different.
If it arrives with RSMP 3, we might want to design status messages that handled dat efficiently

You could have either a single detector, or many.
Aggregation periods could short, 1s, or long 1h or 1d.

All of these combination should be handled efficiently.

Using indexes instead of component ids has some issues (as in the current TLC SXL), it would be good to solve this if possible.

Things beside actual data?

Is there a need for meta data or settings?

• Reset detector
• Accumulated counts and ability to reset/set total.
• Sensitivity? Or is this to specific to certain types of equipment? Seems it could be general.
• Naming/metadata. e.g DL001 = Bicycles in Northward direction
• Classification: what classification schema is used, e.g. Sweden, Denmark, EU? Read/set.
• Min/max values measure, to help you adjust sensitivity. Or perhaps a distribution of values?
• Type of equipment (general for all types of equipment, so perhaps RSMP 4?)

Speed

Average speed, but also min/max/distribution of speeds with the last period.

Presence

On/off.
Usually used with updateOnChange, so you act immediately when a presence is detected.
If you want to percentage of time if was on, which is occupancy.
Aggregation over time is not meaninful it seems?

Occupancy

This is an aggregation of presence - the percentage of time the presence was on.
Used with updateRate.
updateOnChange is not meaningful?

Alarms

Hardware errors - levels: less, serious, fatal.
Logical errors - e.g. a loop has been on or off for too long.
Error mode - if there's a hardware error, should a presence detector show on or off? This is probably better handled by the consumer of data.

Push buttons

This is a kind of presence detector. Perhaps it's on until a signal group is green.

Clock

A precise clock is important, otherwise traffic might not be useable. But this is the case for most types of equipment - perhaps this can be handled by a general module in RSMP 4. If the sensor SXL arrives on RMSP 3 we might need message for dealing with the clock. Reading/setting the clock, setting NTP server, etc.

Next steps

• Write up general description of what the sensor SXL is.
• Write a draft SXL with messages and descriptions (attributes can be left out for now).
• Get feedback from partners, suppliers, etc.