Synchronize "Signal priority status" S0033 with J2735/ETSI

[otterdahl]

After discussion with the NordicWay3 project. There is a strong desire to synchronize the fields that are inteded to be 1:1 comparable between the SRM/SSM message in J2735/ETSI and priority messages M0022/S0033 in RSMP.

It is likely that a ETSI to RSMP converter needs to be etablished in the NordicWay3 project and therefore it is desirable the the standards match as closely togheter to avoid confusion. There is a risk that different interpretations can be made; ending up as issues in the future.

A comparison of the 's' field in the S0033 message:

RSMP	J2735/ETSI	Comment
(does not exist)	unknown
received	requested
queued	processing
activated	granted
(does not exist)	watchOtherTraffic	E.g. all red
completed	(does not exist)
timeout	maxPresence	Prioirization never gets activated (queued for too long)
rejected	rejected
cooldown	reserviceLocked
stale	(does not exist)	Priority active for too long without cancellation

The prosal is to either:

• Use the term from J275/ETSI instead. E.g. change:
  • recieved to requested
  • queued to processing
  • activated to granted
  • timeout to maxPresence
  • cooldown to reserviceLocked
• Or add a clarification in the comment how to map between RSMP/ETSI. It would be a very long comment.

And in the request message:

RSMP	J2735
connectionId	laneConnectionId
laneInId/laneOutId	inBoundlane/outBoundlane
type	priorityRequestType
vehicleType	basicVehicleRole

There may also be slight differences in vehicle types.

[emiltin]

I understand the desire of Nordic Way, but I think trying to match J2735/ETSI comes comes with it's own set of complications.

How much of J2735/ETSI should we copy? Unless we everything, people will complain that it's confusing that bits are missing.

If we match J2735/ETSI 1:1, I think we're implicitely promising to update RSMP everytime J2735/ETSI is updated. As long as we match 1:1 we loose the freedom to design RSMP as we see fit.

It's a tricky issus that I think relates to the long-term direction of RSMP. At the same time I don't want to hold back the release of the new SXL version.

[otterdahl]

I don't think we need to copy ETSI/J2735. The design goals between the protocols are slightly different.

But I am confident that there will be efforts within NordicWay that will make conversion between RSMP and ETSI/J2735, so it would be useful to have a table (like the one in the original post) to describe the recommended conversion between the protocols to avoid confusion.

We could of course add this table elsewhere, but I think having it directly in the SXL reduces the risk of developers forget about it and end up making their own interpretation. The SXL is usually the first place to look for.

[emiltin]

so just be be clear, your suggestion is to leave the sxl proposal, including enum names, but add one or more tables that describes how to translate between rsmp and etsi/j2735?

[otterdahl]

Correct

[emiltin]

ok that should be to much work

[otterdahl]

I've chosen to add a page to the wiki instead and added a reference to that page in S0033/M0022. It makes it a bit simpler and we can update the wiki without releasing a new SXL.

Do you think this is OK?

[emiltin]

yes i think that excellent

[emiltin]

maybe we can add comments for all the table items? https://github.com/rsmp-nordic/rsmp_sxl_traffic_lights/wiki/Signal-priority-and-ETSI-J2735

[otterdahl]

Perhaps. However, the items in the table are already explained in the SXL and I think most of them are quite self-explanatory. I just wanted to add additional clarification to those items that are difficult to interpret or easily missunderstod.

[emiltin]

ok

[otterdahl]

I think we can close this issue for now. We can open it again if any questions are raised.