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.

[emiltin]

We'll also removed the 'overridden' flag, and related fields in the status message.

[emiltin]

@otterdahl when updating the draft, i found it a bit inconsistent that we don't have a way to indicate a request that times out because it's never cancelled. although it's a bit towards debug info, i think it makes sense to include it. that's why i added a' remove' state, but maybe 'stale' would be a better term.

[otterdahl]

Let's close this issue since the command/status has been added