WG SXL Standardization 2024-06-06

[emiltin]

Participants

Toni, Martin, David, Emil

Steps ahead for VMS SXL

We need more input from authorities, but it's easier for them when they have a concrete project coming up.
It might be useful to have some kind of prototype to work with once we start detailing actual message. Perhaps we can find a company that would like to be involved? Or work with a group of the French vendors?

We can invite relevant vendors to a meeting where we inform about our SXL concept and ask for their input.

Traffic Sensors

We have a set of messages from the TLC SXL that we can re-use or build on., but we might want to extend it.
We might need to support different classification schemes, depending on country/use. We should also research possible EU or international standards.
STA has A test facility in with different equipment. Data needs to be compared, which can be challenging if data is send in different formats, with different protocols, etc.
Counting is different from presence detection. Detection sometimes require fast reaction time., should be 100ms or less.
How much lag does it incur on the equipment to construct a json message? Unless the equipment is very old, it usually shoul be very quick. More a question of how asynchronous processing is handled in the equipment, e.g.. avoid polling.

TLC's often have sensors connected, and RSMP is not currently used. It would be great if RSMP could be used. How would the architecture be, ie. would the controller act as a RSMP supervisor? Especially for more advanced types of equipment. For RSMP 4 this is also an interesting question. Passing data via a central broker is probably not a good idea when you need fast reaction time, e.g. from a presence detector - unless the network is good enough.

Next Steps

Write up VMS SXL concept
Invite suppliers to a info/feedback session on VMS SXL work.
Start exploring the Sensors SXL. Identify uses-cases, think about data types, classifications.