Advanced Priority for Busses (or other modes)

[emiltin]

Note: This is a continuation of #99, to make the latest proposal clear.

Background

Many cities in the Nordic region are working with bus priority, and priority of green transport modes in general. But there's a need for better support for this in RSMP.

Sometimes, a bus priority system is separate from the traffic management or supervisor system. This is one reason behind the separate proposal to require that sites can connect to multiple supervisors, see https://github.com/rsmp-nordic/rsmp_core/issues/19.

Current RSMP Solutions

It's possible to use RSMP for bus priority today, but it could be improved. The typical way to do it today is to use the existing RSMP messages for activating either a Detector Logic, or an I/O Input.

The signal program in the TLC must be set up so that activating a specific detector logic or input triggers priority of the relevant signal group(s).

There are at least two variations of this method:

1. Two detector logics or inputs are used. One is used to activate the priority, the other to deactivate the priority.
2. A single detector logic or input is used. You activate by setting it to on, and deactivate by setting to off.

The current solution involving RSMP has some drawbacks and limitations.

1. You cannot specify a priority level. For example, you might want to give a delayed bus, or a bus with many passengers a higher priority´.
2. You don't get any information back about what priority was actually given You know you request priority, but don't know the effect.
3. The link between detector logic (or input) and the signal group, must be programmed as part of the signal program.

Other Protocols. Standards. etc

• The ITS standard J2735 defines a Signal Request Message (SRM) and a Signal Status Message (SSM). Although these messages are intended for much the same purpose, a SRM can reference an in-bound or out-bound lane. But to use a lane reference to provide priority, the TLC needs to know the topology of the intersection and what lanes correspond to what signal groups, in essence what's called MAP data. Establishing and maintaining MAP data (especially on the equipment) is not currently feasible and would at least require a very substantial investment.

• PRIBUSS is a swedish system for buspriority. But it seems it's not published anywhere. Is there things in PRIBUSS that we should take into account?

Proposal

The proposal aims to provide better support for priority in RSMP, while keeping things as simple as possible.

We don't want to create overlap with EU standards like J2735. But we do want to give road authorities that use RSMP a valuable tool that will provide immediate value and make it easier to prioritize busses, and understand the effect.

The proposal includes a command to request priority, and a status message providing info about requests

Command Request

A command request is send to the TLC to activate priority of a specific signal group. The signal group is referenced by it's component id.

You can specify a level, and higher level requests override lower levels.

All rsmp message (except acknoeldgements) include a unique message id. The message id of a priority command request is used if you later need to reference the request, eg. if you want to subscribe to status update, or want to cancel the request.

Name	Type	Values	Explanation
securityCode	string	[text]	Security code 1
componentId	string	[text]	rsmp component id of a signal group.
requestId	string	[text]	rsmp message id of a previous request, or empty if this is a new request.
level	integer	[0-255]	0: cancel, 1: lowest, 255: highest

If you pass a request id of an previous command request, you can change the priority of the request, or cancel it by setting priority to zero.

The TLC immediately responds with either a MessageAck if the command is understood, or MessageNoAck otherwise.

Command Response

When a requested priority is activated or skipped by the TLC, a CommandResponse is send by the TLC, indicating simply whether the request succeeded:

Name	Type	Values	Explanation
componentId	string	[text]	rsmp component id of signal group
requestId	string	[text]	Original request id
status	boolean	[True, False]	True if priority was activated
reason	string	[text]	Reason why priority could not be activated, or empty if was activated

The request id is the rsmp message id of the original CommandRequest used to request priority.

Status

If you want more data about priority than what is provided by the CommandResponse, you can subscribe to status messages. You then get updates about all priority request. You can't subscribe to updates about individual priority requests.

Note that you can subscribe to priority request statuses from a different supervisor system that the system sending requests.

Only update rate 0 is allowed, meaning that you get a status message every time there's a change. Otherwise the TLC would need to aggregate these statuses, and it's not clear how that would work.

Whenever a priority request changes state, a status message is send by the TLC:

Name	Type	Values	Explanation
componentId	string	[text]	rsmp component id of signal group
requestId	string	[text]	rsmp message id of original command request
status	string	[queued, activated, rejected, cancelled, overridden]	State of request
reason	string	[text]	Reasons why priority was not activated
overrideRequestId	string	[text]	Id of overriding request
greenExtension	[float]	[-999 - 999]	Green time extension, in seconds
redReduction	[float]	[-999 - 999]	Red time reduction, in seconds
previousStage	integer	[0-255]	Stage before priority was activated

A status is send immediately when a request is acknowledged, with the status set to queued. This makes it possible for other system to know when a request is initiated.

The attributes greenExtension, redReduction and previousStage are omitted when status is set to queued or rejected. When the status is activated, they indicate the actual priority given.

In case an activated priority is cancelled, or overridden by another priority with a higher level, an new status message is send, with negative greenExtension and redReduction values. This makes it possible to accumulate all extension times to see how much priority was really given during a given period of time.

[rafaelcf2]

Hi, Not sure about requestId but we can talk about this in the next week

[emiltin]

Not sure about requestId but we can talk about this in the next week

The idea is is to have a unique identifier for each request, in case you later want to cancel it, change priority level, or receive status updates. Since all rsmp message have a unique id (mId), it could be used. This could in fact be generalized by including the original mId in all command responses, see https://github.com/rsmp-nordic/rsmp_core/issues/60. But here the proposal is to include a requestId in this particular response type.

An alternative would be to let the requester provide the id, e.g. a bus journey number. But unless the requester can guarantee that they are unique across time it might be problematic to link the correct requests and status messages for analysis purposes.

[rafaelcf2]

Maybe an extra field with string can solve the problem. some systems uses Journey number other Bus system unique priority identifier.

[emiltin]

Maybe the CommandRequest has a single requestId attribute, as suggsted above. You can either provide a custom id like a bus journey id, or set it to null, in which case the mId will be used as the request id.

Note that if we allow the sender to provide a custom request id, we cannot validate it using JSON Schema, except by checking that it's not empty. If we use the mId, it has a particular format that we can validate.

[emiltin]

Do we need a status message when the priority is complete? The current proposal sends a status with 'activated', when it starts.

To be able to accumulate the actual given priority, the current proposal is that negative values for greenExtension/redReduction are send if a request is cancelled (to cancel out the previous positive values). We would not need this if we only send positive greenExtension/redReduction values when the priority is completed.

[rafaelcf2]

Normally after bus passes the stopline the GPS system of the bus company sends the deactivation pulse to the traffic light controller, so I think the system will only send one priority and the TLC will give continually the prioritization until deactivation is received or the timeout is reached. (normally 120 sec)

[PetterEistrand]

THIS COMMENT RELATES TO THE REQUEST PART OF THE SXL

Suggest that as much as possible from SR(E)M/SS(E)M is re-used in order to minimize any mapping issues within the priority system.

Proposals to align with SR(E)M/SS(E)M

Current SXL-proposal requestId string [text]****

J7235 SRM 7.153 Data Element: DE_RequestID Use: The RequestID data element is used to provide a unique ID between two parties for various dialog exchanges. Combined with the sender’s VehicleID (consisting of a TempID or a Station ID), this provides a unique string for some mutually defined period of time. A typical example of use would be a signal preemption or priority request dialog containing multiple requests from one sender (denoted by the unique RequestID with each). When such a request is processed and reflected in the signal status messages, the original sender and the specific request can both be determined. ASN.1 Representation: RequestID ::= INTEGER (0..255)

Current SXL-proposal level integer [0-255]****

J7235 SRM 7.154 Data Element: DE_RequestImportanceLevel Use: The RequestImportanceLevel data element is used to state what type of signal request is being made to a signal controller by a V2X device in a defined role (such as a police vehicle). The levels of the request typically convey a sense of urgency or importance with respect to other demands to allow the controller to use predefined business rules to determine how to respond. These rules will vary in terms of how details of overall importance and urgency are to be ranked, so they are to be implemented locally. As a result of this regional process, the list below should be assigned well-defined meanings by the local deployment. These meaning will typically result in assigning a set of values to list for each vehicle role type that is to be supported. ASN.1 Representation: RequestImportanceLevel ::= ENUMERATED { requestImportanceLevelUnKnown (0), requestImportanceLevel1 (1), -- The least important request requestImportanceLevel2 (2), -- The values here shall be assigned requestImportanceLevel3 (3), -- Meanings based on regional needs requestImportanceLevel4 (4), -- for each of the basic roles which requestImportanceLevel5 (5), -- are defined elsewhere requestImportanceLevel6 (6), requestImportanceLevel7 (7), requestImportanceLevel8 (8), requestImportanceLevel9 (9), requestImportanceLevel10 (10), requestImportanceLevel11 (11), requestImportanceLevel12 (12), requestImportanceLevel13 (13), requestImportanceLevel14 (14), -- The most important request

Current SXL-proposal 0: cancel, 1: lowest, 255: highest

The way J2735 handles the request is that the statuses mean (1) initiated (2) updated (3) cancelled. Not set to level 0.

J7235 SRM 7.142 Data Element: DE_PriorityRequestType Use: The PriorityRequestType data element provides a means to indicate if a request (found in the signal request message) represents a new service request, a request update, or a request cancellation for either preemption or priority services. ASN.1 Representation: PriorityRequestType ::= ENUMERATED { priorityRequestTypeReserved (0), priorityRequest (1), priorityRequestUpdate (2), priorityCancellation (3), ... }

[emiltin]

thank you @PetterEistrand

[otterdahl]

Some thoughts and questions about the proposal

1. The CommandRequest and CommandResponse have the same set of parameters (cCI, n, v, age) in the specification. See https://rsmp-nordic.github.io/rsmp_core/applicability/basic_structure.html#id11. In the proposal there is a different set of parameters in the request and the response which makes it a little confusing.

2. I don't understand how the status is supposed to work. If there are multiple active priority requests, how does it send a list of all of them?

3. I think it is a little unclear how redReduction, greenExtension is supposed to be interpreted if there are multiple reductions/extensions in several stages in the cycle.

4. Using signal group as the identifier of the priority function in the TLC might limit the flexibility. For instance, there might be several priority functions in the TLC for the same signal group. (different bus routes?)

[PetterEistrand]

THIS COMMENT RELATES TO THE RESPONSE PART OF THE SXL

Suggest that as much as possible from SR(E)M/SS(E)M is re-used in order to minimize any mapping issues within the priority system.

Proposals to align with SR(E)M/SS(E)M:

Current SXL proposal status - string - [queued, activated, rejected, cancelled, overridden] - State of request reason - string - [text] - Reasons why priority was not activated

In J2735 SSM the status and reason are combined to the following data element:

7.140 Data Element: DE_PrioritizationResponseStatus Use: The PrioritizationResponseStatus data element is used in the PrioritizationResponse data frame to indicate the general status of a prior prioritization request. ASN.1 Representation: PrioritizationResponseStatus ::= ENUMERATED { unknown (0), -- Unknown state requested (1), -- This prioritization request was detected -- by the traffic controller processing (2), -- Checking request -- (request is in queue, other requests are prior) watchOtherTraffic (3), -- Cannot give full permission, -- therefore watch for other traffic -- Note that other requests may be present granted (4), -- Intervention was successful -- and now prioritization is active rejected (5), -- The prioritization or preemption request was -- rejected by the traffic controller maxPresence (6), -- The Request has exceeded maxPresence time -- Used when the controller has determined that -- the requester should then back off and -- request an alternative. reserviceLocked (7), -- Prior conditions have resulted in a reservice -- locked event: the controller requires the -- passage of time before another similar request -- will be accepted ... }

[PetterEistrand]

Some thoughts and questions about the proposal

1. The CommandRequest and CommandResponse have the same set of parameters (cCI, n, v, age) in the specification. See https://rsmp-nordic.github.io/rsmp_core/applicability/basic_structure.html#id11. In the proposal there is a different set of parameters in the request and the response which makes it a little confusing.
2. I don't understand how the status is supposed to work. If there are multiple active priority requests, how does it send a list of all of them?
3. I think it is a little unclear how redReduction, greenExtension is supposed to be interpreted if there are multiple reductions/extensions in several stages in the cycle.
4. Using signal group as the identifier of the priority function in the TLC might limit the flexibility. For instance, there might be several priority functions in the TLC for the same signal group. (different bus routes?)

To add to @otterdahl The data listed last in the status segment (reason , overrideRequestId , greenExtension , redReduction , previousStage ) are related to local traffic control often deeply embedded with the control algorithm. To "dig out" such data from the algorithm and present in the protocol might require extensive work.

Therefore it shall carefully be thought through before any such requirements are added. What value it brings etc.

The listed elements should be optional and any system designer should be advised to not design features depending on the listed elements.

[emiltin]

1. The CommandRequest and CommandResponse have the same set of parameters (cCI, n, v, age) in the specification. See https://rsmp-nordic.github.io/rsmp_core/applicability/basic_structure.html#id11. In the proposal there is a different set of parameters in the request and the response which makes it a little confusing.

yes, we need to follow that convention, although it seems a bit limiting that output fields must be the same as input fields, so for example you cannot provide any reason why something couldn't be done. i guess we will have to move that to a status.

I don't understand how the status is supposed to work. If there are multiple active priority requests, how does it send a list of all of them?

the idea was that you can only subscribe with update rate=0, so you always get these as they happen, one at a time. there's no way (with the proposal above) to get a list of priorities. to support that we would need to work with e.g. json arrays to provide a list of requests. if we do this, we could allow any update rates, since they would be aggregated into a list

[emiltin]

An updated proposal based on the input above.

CommandRequest:

Name	Type	Values	Explanation
componentId	string		rsmp component id of a signal group.
requestId	string		request id identifying the request.
type	enum	new,update,cancel	type of request
level	integer	0-14	0: lowest, 14: highest

The request id in J7235 SRM is just an integer 0-255, but is combined with a Vehicle ID. We have no concept of vehicle id in RSMP, so I think the request id needs to be more than just the integer. If we use a string, it can cover both an integer (as string) and integer+vehicleID. Note that the request id must now be provided by the sender, whereas before you could leave it empty, and the tlc would return an id.

The type and level now matches J7235.

CommandResponse must have the same attributes, according to the RMSP spec. So it cannot contain any additional info, like reaon in case it was rejected.

The security code was removed, i don't think it's needed?

We could allow inbound/outbound lane as an alternative to signal group. If/when the TLC has MAP data or similar data, these can be used instead of a signal group, if desired.

StatusUpdate:

Name	Type	Values	Explanation
componentId	string		rsmp component id of signal group
requestId	string		request id
status	enum	queued, activated, rejected, cancelled, overridden	State of request
reason	string		Reasons in case priority could not be given
overrideId	string		if request was overridden: request id of overriding request
gained	float		estimated extra seconds of green time provided by the priority

The previous attributes greenExtension, redReduction, previousStage has been replaced by a single attribute 'gained' that aims to provide the key metric of how much priority was actually given, with less coupling to implementation details.

[emiltin]

If we also want to allow inbound/outbound lane as an alternative to signal group, then the command must be send to the main component, rather that to a signal group component. Can a message be send to either a main component or a signal group? Or must be define two different messages? @otterdahl

[emiltin]

A PR for this proposal is being maintained at #137

[otterdahl]

Can a message be send to either a main component or a signal group? Or must be define two different messages? @otterdahl

You'd have to define two different messages

[emiltin]

Regarding the status, the issue with the above proposal is that there's no way of providing the status for several requests at once, which would be what you would want if update rate is not zero.

If we don't want to change the core spec I see a few possibilities, based on the fact that the curent spec puts no requirements on the format of the "s" attribute. It simply states it's a "Value".

1) We pass arrays for all values. You have to pick item x from each array to assembly the status for a request.

{
  "mType": "rSMsg",
  "type": "StatusRequest",
  "mId": "f1a13213-b90a-4abc-8953-2b8142923c55",
  "ntsOId": "",
  "xNId": "",
  "cId": "O+14439=481SG001",
  "sS": [
    {
      "sCI": "S0032",
      "n": "requestId",
      "s": ["f90c","e33a2"],
      "q": "recent",
    },
    {
      "sCI": "S0032",
      "n": "status",
      "s": ["activated","overridden"],
      "q": "recent"
    },
    {
      "sCI": "S0032",
      "n": "overrideId",
      "s": ["","ff30"],
      "q": "recent"
    },
    {
      "sCI": "S0032",
      "n": "reason",
      "s": ["",""],
      "q": "recent"
    },
    {
      "sCI": "S0032",
      "n": "gained",
      "s": ["5",""],
      "q": "recent"
    },
]}

The "q" field can only be one of a few predefined string values, like "recent", so we can't pass an array. So the q must related to the collection of values.

A variation would be to use comma-separed string list instead of JSON arrays, so instead of e.g. ["activated","overridden"] it would "activated,overridden".

2) We pack the list of request statuses into a a single value. For example we could use a hash with the requestIds as keys.

{
  "mType": "rSMsg",
  "type": "StatusRequest",
  "mId": "f1a13213-b90a-4abc-8953-2b8142923c55",
  "ntsOId": "",
  "xNId": "",
  "cId": "O+14439=481SG001",
  "sS": [
    {
      "sCI": "S0032",
      "n": "list",
      "q": "recent",
      "s": {
        "f90c": {
          "status": "activated",
          "gained": "5"
        },
        "e33a2": {
          "status": "overridden",
          "overrideId": "ff30"
        }
      }
    }
]}

3) We could give up on providing data about individual request and only send some aggregated data, like number of requests that were accepted, rejected, etc, and the total number of seconds gained:

{
  "mType": "rSMsg",
  "type": "StatusRequest",
  "mId": "f1a13213-b90a-4abc-8953-2b8142923c55",
  "ntsOId": "",
  "xNId": "",
  "cId": "O+14439=481SG001",
  "sS": [
    {
      "sCI": "S0032",
      "n": "activated",
      "s": "2",
      "q": "recent",
    },
    {
      "sCI": "S0032",
      "n": "rejected",
      "s": "1",
      "q": "recent",
    },
    {
      "sCI": "S0032",
      "n": "overridden",
      "s": "0",
      "q": "recent",
    },
    {
      "sCI": "S0032",
      "n": "gained",
      "s": "14",
      "q": "recent",
    },
]}

[otterdahl]

After discussion internally, we would like use ConnectionID (Part of MAP-messages in J2735) rather signal group to identify a specific priority.

It's also a possibility to keep both signal group or ConnectionID in the priority message and use either depending on the configuration of the TLC.

[emiltin]

can you explain what a connection id is and how it relates to a signal group? is is something that already exists in the the TLC?

a signal group is identified by it's component id. another id like connection id would require that we either define these 'connections' as component, or always send the message to the main component with an additional 'connectionId' attribute.

[emiltin]

the latest proposal can now be viewed at:

http://rsmp-nordic.org/rsmp_specifications/rsmp_sxl_traffic_lights/1.1-draft/sxl_traffic_light_controller.html#m0022 http://rsmp-nordic.org/rsmp_specifications/rsmp_sxl_traffic_lights/1.1-draft/sxl_traffic_light_controller.html#s0033

any updates to the proposal will be reflected in these locations (and can also be seen here on github, which is the source for the online version)

discussions about the proposal still happens here in this issue

[emiltin]

@rafaelcf2 what do you think about the simplified reporting that provides only the seconds gained, not details about greenExtension, redReduction and previousStage?

[emiltin]

@otterdahl any thoughts on the ideas 1,2,3 above for status on individual requests?

[otterdahl]

My thoughts:

1. This option is quite similar to what we already use elsewhere (e.g. "intersection"), but don't think it is easy to read (and perhaps a bit cumbersome to use with JSON schema?)

2. My favorite option. It's clear and easy to read. However, perhaps the Core spec needs to be updated? But as you say, It doesn't mention exactly what "value (s)" contains so perhaps it is not necessary. But we need to describe it well in the SXL.

3. Not a very good option since it is missing important information. E.g. the vehicle don't receive 100% confirmation about it's priority has been activated or not since all data is aggregated

[otterdahl]

My thoughts regarding "gain", "greenExtension":

Correct me if I'm wrong, but I think it may or may not be possible to use e.g. "gain" depending on the type of priority logic in the TLC. It is still possible to define "gain", for example. But I don't believe we can always require it. However, we could write something like: it is required if the priority logic in the TLC supports it.

[otterdahl]

can you explain what a connection id is and how it relates to a signal group? is is something that already exists in the the TLC?

ConnectionId is used to state a connection index for a lane to lane connection (e.g. incoming to outgoing lane) in J2735 MAP messages. Each lane has a signal group associated with it, but a lane may have multiple connections to outgoing lanes (e.g. straight a head and right turn). For instance, a "circular green" signal group may permit vehicles to drives straight ahead as well as permit left/right turn (may need to yield to pedestrians). This

There may be a need to a in a priority request be able to differentiate between vehicles which intends to drive straight ahead and those which intends to turn left/right. For comparison; the J2735 SRM message doesn't use signal group, it uses incoming and outgoing lane id's.

I think that this priority request can be used not only for buses, but for emergency vehicles and trucks as well. This information may be needed (but I'm not entirely sure)

However, ConnectionId is optional in MAP-messages, e.g. there may be connections without explicit connection indices, so that is something to keep in mind. It even states in J2735 that most intersection is not expected to need ConnectionId

An alternative method to use ConnectionId is to define incoming and outgoing lane, just as the SRM message in J2735. Those fields are required in MAP messages.

So... possibly support:

• Signal group or
• Incoming lane and outgoing lane

a signal group is identified by it's component id. another id like connection id would require that we either define these 'connections' as component, or always send the message to the main component with an additional 'connectionId' attribute.

I think it is better to define it on the main component if we choose to support connectionId/incoming lane/outgoing lane

[emiltin]

Are connectionIds available in TLCs today? it sounds to me like it would require MAP data on the TLC?

An alternative method to use ConnectionId is to define incoming and outgoing lane, just as the SRM message in J2735. Those fields are required in MAP messages.

How would ingoing/outgoing lanes be defined? I think it would also require MAP data on the TLC?

I think it is better to define it on the main component if we choose to support connectionId/incoming lane/outgoing lane

I agree. But if we use signal group, it would be much more natural to directly address the component.

[emiltin]

2. My favorite option. It's clear and easy to read. However, perhaps the Core spec needs to be updated? But as you say, It doesn't mention exactly what "value (s)" contains so perhaps it is not necessary. But we need to describe it well in the SXL.

ok

My thoughts regarding "gain", "greenExtension": Correct me if I'm wrong, but I think it may or may not be possible to use e.g. "gain" depending on the type of priority logic in the TLC. It is still possible to define "gain", for example. But I don't believe we can always require it. However, we could write something like: it is required if the priority logic in the TLC supports it.

sure we can state that it's required if the priority logic supports it.

[emiltin]

are priority logics available as component? would that be a way to address the priority you want, as an alternative to signal group, in/out lane or connectionId?

[emiltin]

Regarding the status message, if we go for 2) above, maybe we need a timestamp for each item? Eg.

{
  "mType": "rSMsg",
  "type": "StatusRequest",
  "mId": "f1a13213-b90a-4abc-8953-2b8142923c55",
  "ntsOId": "",
  "xNId": "",
  "cId": "O+14439=481SG001",
  "sS": [
    {
      "sCI": "S0032",
      "n": "list",
      "q": "recent",
      "s": {
        "f90c": {
          "status": "activated",
          "gained": "5",
          "timestamp": "2021-11-09T15:06:38.796Z"
        },
        "e33a2": {
          "status": "overridden",
          "overrideId": "ff30",
          "timestamp": "2021-11-09T15:06:45.431Z"
        }
      }
    }
]}

Should "q" be set to "recent"?

If uRt=0, then I think changes will usually be send one at a time, unless two things happen at the same time (or maybe within the same time slot of the site)? If there's only one item, should we follow the same list format, eg:

{
  "mType": "rSMsg",
  "type": "StatusRequest",
  "mId": "f1a13213-b90a-4abc-8953-2b8142923c55",
  "ntsOId": "",
  "xNId": "",
  "cId": "O+14439=481SG001",
  "sS": [
    {
      "sCI": "S0032",
      "n": "list",
      "q": "recent",
      "s": {
        "f90c": {
          "status": "activated",
          "gained": "5",
          "timestamp": "2021-11-09T15:06:38.796Z"
        }
      }
    }
]}

[emiltin]

A benefit of adressing the main component would be that you can easily subscribe to priority updates for all signal groups with a single message.

[otterdahl]

Are connectionIds available in TLCs today? it sounds to me like it would require MAP data on the TLC?

I don't know if they are available. But yes, it is based on MAP data, however I don't think it means that MAP data needs to be available on the TLC. The TLC just need to translate connectionId's to the corresponding priority function in it's configuration. I think that some kind of configuration like this is unavoidable and needs to made anyway regardless of id used (signal group/input/lanes, etc).

[otterdahl]

are priority logics available as component? would that be a way to address the priority you want, as an alternative to signal group, in/out lane or connectionId?

No they are not really a component. In it's original meaning, component-id are supposed to represent physical components of the equipment, but sometimes It's more convenient to use them for a "logical" set of components, such as a signal group and detector logic - since it's the way the TLC controls signal groups and that's how we receive alarms.

To make things more complicated, TLC's usually provides priority functionality in several ways. It can be done using e.g. PRIBUSS functions, control blocks (internal language of the TLC), and several more ways. It is very dependent of the manufacturer.

[emiltin]

A problem with the proposed hash structure in 2) is that you can't have multiple updates for the same requestId. so I think it must be changed to e.g.:

{
  "mType": "rSMsg",
  "type": "StatusRequest",
  "mId": "f1a13213-b90a-4abc-8953-2b8142923c55",
  "cId": "O+14439=481SG001",
  "sS": [
    {
      "sCI": "S0032",
      "n": "changes",
      "q": "recent",
      "s": {
        "f90c": [
          {
            "timestamp": "2021-11-09T15:06:38.796Z",
            "status": "activated"
          },{
            "timestamp": "2021-11-09T15:06:39.796Z",
            "status": "complete",
            "gained": "5"
          }
        ],
        "e33a2": [
          {
            "timestamp": "2021-11-09T15:06:48.796Z",
            "status": "overridden",
            "overrideId": "ff30"
          }
        ]
      }
    }
]}

[emiltin]

We could choose to define the above status for a status code like 'changes', and then define a different status code 'summary' that provides an aggregated format with total gained, perhaps number of requests, complete, rejected, etc.

[otterdahl]

A couple of remarks regarding comparison with SRM/SSM in J2735 and this suggestion.

I think there is a real value in being able to easily translate between SRM/ SSM and the priority request/update in RSMP, but It is quite complicated. It basically refers to properties of the physical intersection (lanes, connections, etc) and not any internal variables of the TLC (signal group, I/O, etc).

SRM (request):

• Contains an ETA (Estimated Time of Arrival) of the vehicle to arrive at the stop line - as an optional field. Do we need it?
• Contains a (temporary?) id of the vehicle as an optional field. Do we need it?
• Contains "type" with request, update and cancel just like our draft, but I don't see if there is any point in sending an update unless it contains an ETA. So I think we can remove update if we choose not to include ETA.
• RequestId is an integer (0-255), not a string as in our draft.
• Does not refer to a signal group, instead refers to inBoundLane (required) and outBoundLane (optional) of a type called IntersectionAccessPoint
• IntersectionAccessPoint can either be a lane-id, approach-id or connection-id.
• A lane can have one or many connections, with an optional connection-id
• A connection refers to the path in the intersection that leads between an incoming lane and outgoing lane (as far as I understand)
• Each connection has a signal group associated with it, but there can be several connections with the same signal group

To sum it up:

• It is possible to convert Connection to signal group if the MAP-file contains ConnectionID (optional field, but we can choose to require it in NordicWay3)
• A lane may contain several connections, with several signal groups. So it may be a little difficult to convert
• A approach (ingress/egress) may contain several lanes. Same problem as lane

[emiltin]

Would the idea be to allow addressing in several different ways, e.g either signal group, connection id or in/out lane?

Connection id and in/out lane would required data or configurations on the TLC which is not available today, but can offer more advanced functionality, like differentiating between different priority types for the same signal group (e.g. straight ahead vs. a turn).

Signal group is available today, but cannot differentiate between different priorities for the same signal group.

[otterdahl]

Would the idea be to allow addressing in several different ways, e.g either signal group, connection id or in/out lane?

Yes. Either that, or we could consider adding multiple priority request commands, one for each addressing mode. Perhaps signal group or connection id is enough for our needs

[emiltin]

The proposal at http://rsmp-nordic.org/rsmp_specifications/rsmp_sxl_traffic_lights/1.1-draft/sxl_traffic_light_controller.html#m0022 has been update to include different ways to reference the movement to prioritize - let's discuss which of these we want to keep.

(It seems the link behaves a bit odd. The relevant command is M0022).

Additional explanation has also been added.

[emiltin]

Dynniq created a number of MAP files for us in Copenhagen. I can't speak to the quality/validity (it seems commas are missing?) but it's interesting to see an example. It includes approaches, lanes and connections. https://gist.github.com/emiltin/a41127a4d292df32be9db9274e79cf8f

Do someone have an example, known to be valid?

[emiltin]

In the example MAP file, the connections doesn't have any id. They are defined as part af a lane, and reference another lane. If that's how the ETSI standard define connections, we should move connectionId as a reference method, and just rely on in/out lanes.

[emiltin]

Maybe a flexible approach to referencing the movement to prioritize would be to have just two fields:

referenceType
referenceId

Where referenceType would be an enum like [signalGroup, input, approach, inOutLanes, connection], and referenceId would then be either a string or integerer with the actual id(s). That way we can add referencing methods as they are needed

Something a bit awkward is that referencing a signal group would normally be done by sending the command directly to the component, but it we want to allow different methods, the command must be send to the main component, and the signal group passed as an attribute, which is an unusual way of referencing a component.

[emiltin]

I updated M0022. priorityId was removed, and componentId was renamed to signalGroupId.

S0033 was redesigned to provide list of events. As it's proposed now, S0033 does not provide the original movement reference, level, ETA and vehicle type used when initiating the request. In a multi-supervisor setting this might be an issue, because you (perhaps) didn't issue the request youself . But passing these attributes seems a waste in a single-supervisor mode. I though about adding a status called 'requests' that only sends new requests with these attributes, but it doesn't seem like the right answer to what's perhaps a more general question about multi-supervisor setups: should it be possible to know what commands other supervisors send? Eg. what priority requests they issue?

As currently proposed, S0033 optionally provide 'gain', the actual number of seconds gained by the priority. Optional would mean that the TLC would provide it if possible.

http://rsmp-nordic.org/rsmp_specifications/rsmp_sxl_traffic_lights/1.1-draft/sxl_traffic_light_controller.html#s0033 http://rsmp-nordic.org/rsmp_specifications/rsmp_sxl_traffic_lights/1.1-draft/sxl_traffic_light_controller.html#m0022

[emiltin]

An example of an S0033 message:

{
  "mType": "rSMsg",
  "type": "StatusRequest",
  "mId": "f1a13213-b90a-4abc-8953-2b8142923c55",
  "cId": "O+14439=481TC000",
  "sS": [
{
      "sCI": "S0033",
      "n": "events",
      "q": "recent",
      "s": [
        {
          "requestId": "f90c",
          "timestamp": "2021-11-09T15:06:38.796Z",
          "status": "queued"
        },{
          "requestId": "f90c",
          "timestamp": "2021-11-09T15:06:38.796Z",
          "status": "activated"
        },{
          "requestId": "f90c",
          "timestamp": "2021-11-09T15:06:39.796Z",
          "status": "completed"
        },{
          "requestId": "e33a2",
          "timestamp": "2021-11-09T15:06:48.796Z",
          "status": "overridden",
          "override": "ff30"
        },{
          "requestId": "58c0",
          "timestamp": "2021-11-09T15:06:48.796Z",
          "status": "timeout"
        }
      ]
    }
  ]
}

Hash keys could be shortened, per RSMP tradition, eg.

{
  "r": "f90c",
  "t": "2021-11-09T15:06:38.796Z",
  "s": "queued",
}

[otterdahl]

Since the M0022 was updated to accept multiple types of ID's. I've noticed that ObjectType is still Signal group. Updating this to Traffic Light Controller

[otterdahl]

I've updated S0033 to clarify that timestamp uses UTC

[emiltin]

should we shorten keys in S0033 array items? requestId => r timestamp => t status => s

[otterdahl]

Sure. Let's do that

[PetterEistrand]

Question, I am trying to understand from the discussion above, but cannot find the answer.

The current proposal of priority statuses in S0022 are -queued -activated -completed -overridden -timeout

whereas J2735 SRM uses the statuses

• unknown (0),
• requested (1),
• processing (2),
• watchOtherTraffic (3),
• granted (4),
• rejected (5),
• maxPresence (6),
• reserviceLocked (7),

Was there a specific reason for not using the same set of statuses as in J2735?

[Rodgulgronademonen]

I

Question, I am trying to understand from the discussion above, but cannot find the answer.

The current proposal of priority statuses in S0022 are -queued -activated -completed -overridden -timeout

whereas J2735 SRM uses the statuses

• unknown (0),
• requested (1),
• processing (2),
• watchOtherTraffic (3),
• granted (4),
• rejected (5),
• maxPresence (6),
• reserviceLocked (7),

Was there a specific reason for not using the same set of statuses as in J2735?

I don't know the reasons if there are any. But as an example "queued" is maybe similar to "watch other traffic" in J2735.

In one of the first statements around the Priotity messages it say's that we shouldn't overlap with the J2735 messages. The idea here is not overlaping, but instead to meet the J2735 standard messages. The messages is now ETSI standardized so if we are going to establish priority request messages they should comply to the same parameters and terminology. If so, we can make simple translations to RSMP for communication with tlc:s that can't communicate ETSI directly.

[emiltin]

Hi @PetterEistrand, Thank you for your input. We've looked more closely at the ETSI flags, and suggest aligning our flags to closer match ETSI. However we don't think it makes sense to just copy the flags one-to-one.

Updated draft:

RSMP (=ETSI)

received (=requested)
rejected (=rejected)
cooldown (=reserviceLocked)
queued (=processing)
  activated (=granted, watchOtherTraffic)
    completed (=  nothing)
  timeout (=maxPresence)

I'll write a more detailed explanation of each flag as I update the SXL draft.