M00XX - Add support to Advanced Public Transport Prioritization APTP

[rafaelcf2]

Hello Guys,

Today the city of Copenhagen wishes to have a more advanced buspriorisation which can benefit more from the advanced traffic controllers that exist today. The goal is to use the function not only to prioritise the buses but also to utilize the result for further analysis.

[Server] ------> [TLC]

Name	Command	Type	Value
securityCode	string	[text]	Security code 1
SignalGroup	ordinal	[1-255]	Signal Group Number
Direction	ordinal	[1-255]	0,1,2,3...
BusName	string	[text]	5C, 32, 800, Belo Horizonte
JourneyNo	long	[1-65025]	Journey Number
UniqueID	string	[text]	Unique Identifyer from BUS operator
status	boolean	False- Cancel / True - Request

[Server] <------ [TLC]

aK or Nak if not implemented

if aK returns also if status is true (Request) (for further analysis)

signalgroupstatus	string	[text]	Signal group status as text field
UniqueID	string	[text]	Unique Identifyer from BUS operator
GreenExtension	[unit]	[0-999]	If greenTime gets extended
RedReduction	[unit]	[0-999]	If redTime gets reduced
cyclecounter	unit	[0-999]	Cycle counter
basecyclecounter	unit	[0-999]	Base cycle counter
stage	integer	[0-999]	Current stage (isolated)

We have already Advanced Public Transport Prioritization in our traffic signals but wish to do in the future using only RSMP

/Rafael

[PetterEistrand]

• In Nordic Way 2 we have concluded that any public transport data should follow terminology and data models from Transmodel. That will simplify any integration with PT authority and operator ITS systems. This would in this case concern the JourneyNo for example.
• There is also a set of data defined in J2735 Signal Request Message SRM and Signal Status Message regard priority request (SRM) and the following priority execution status (SSM) /Petter Eistrand, SWARCO Sweden

[rafaelcf2]

@PetterEistrand I'm not member of Nordic Way 2, but i will take a look. maybe we can consolidate in this format

/Rafael

[otterdahl]

I'm investigating the details of the J2735 Signal Request Message (SRM) and Signal Status Message (SSM) to see how well it fits within the RSMP context.

As far as I understand:

• The SRM message sent by a vehicle to a signalized intersection to request priority.
• Each request defines a path through the intersection which is desired in terms of lanes and approaches to be used.
• Each request can also contain the time of arrival and the expected duration of the priority.
• Multiple requests to multiple intersections are supported.
• The requestor identifies itself in various ways (using methods supported by the RequestorDescription data frame, e.g. vehicle id, routeName), and its current speed, heading and location can be placed in this structure as well.
• The specific request for service is typically based on previously decoding and examining the list of lanes and approaches for that intersection (sent in MAP messages).
• The outcome of all of the pending requests to a signal can be found in the Signal Status Message (SSM), and may be reflected in the SPAT message contents if successful.

This means that the receiving party of the SRM message needs to interpret the MAP data in order to relate the SRM request to the requested route in the intersection and translate that into the relevant signal group.

In other words, in order to be able to send SRM to the traffic controller, it needs to deal with MAP data as well. The same goes for the vehicle. It need to not only know which routeNo it has but also which in inbound and outbound lane/approach of the specific intersection it desires to use.

[josvanvlerks]

Hi all,

Jos van Vlerken from Copenhagen here.

It would of course be very interesting if RSMP was to be aligned the European standards for priority messaging. We also use SSM or SRM in the European C-Mobile project in Copenhagen in the few places where we have priority via the ETSI-G5 Roadside Units. So in that sense we have some experience with this.

But there is - in addition to what Otterdahl mentions - a pretty big practical problem with the MAP messages in particular.

The MAP messages must be adjusted or changed every time something changes in the intersection. Whether it is striping, geometric changes, additions in the signals or groups, etc., the MAP message for the intersection must be adjusted according to the actual changes.

That in itself makes sense and is reasonable. The problem lies in the fact that there are no user-friendly tools to create or adjust MAP. As an example i can mention that even one of the biggest traffic signal providers does not have a good tool for this and must do workarounds in a cumbersome and inefficient manner to create MAP messages.

In addition, we, as a public authority, do not request updated MAP messages when contracting road works, geometry or signal changes (especially because the contractors do not have a means to create them).

So at the moment there is no case for implementing the SSM and SRM full scale and we will, for the next few years at least, rely on a simplified way to do priority.

I am therefore wondering whether it is possible to get Raphael's proposal for bus priority introduced in one of the next versions of RSMP and then, at a later time, when all the other preconditions are in place, to start thinking about how to work with EU standards?

[rafaelcf2]

Hello,

Maybe we can make it easy to implement. I believe most of the users of this message just want the priority in the traffic with a simple solution. So i propose we implement in two new messages, one more simple like i wrote in the first post and can fulfill City of Copenhagen wishes and another one more advanced who take full advantage like David suggests in compliance with nordic way 2. So with two new different messages we can delivery both a simple and more advance solution to our customers and they can decide with one they will use based in the use cases they want to solve.

BR Rafael

[rafaelcf2]

Hello again, It has now been 3 weeks since my last message with the suggestion of implementation of 2 types of messages. As I have not received any objections to this suggestion, I believe we can go ahead with the implementation of my suggestion.

BR Rafael

[emiltin]

I think it's a good ideas to work on a simple RSMP messages now, and then later add more advanced messages that are more tightly integrated with other EU standards.

I would like to add a bit of context.

In Copenhagen we have a bus priority system, with a central server. Movia have GPS in their busses, and when a bus enters a geofence, a messages is sent to the server. The server then sends an RSMP message to the traffic light controller, to request priority. But since there is no specific RSMP message yet for requesting priority, it's done by activating an input with M0019, http://rsmp-nordic.github.io/rsmp_sxl_traffic_lights/sxl_traffic_light_controller.html#m0019. The signal program is designed to give priority when this input is activated. However, priorty is not always possible, depending on other active priorities, etc.

The drawback with this approach is that we don't get any information about which priorities could actually be given. The M0019 command response just tells you if the input was activated. The approach also requires prior signalprogramming, connecting inputs to signal group priorities

So the proposal should make it possible to:

1. activite priority, preferably without prior signal programming
2. track priority request and see which resulted in actual priority

I think the ability to activaty priority could also be useful for other modes, besides bus, and I think the command can be more general, and simply be a way to activate priority for a given signal group, rather than specifically be for public transport.

• Signal group: This should be the RSMP component id of the signal group.
• Direction: Why is this needed? Doesn't all lamps in a group change together?
• BusName and JourneyNo: I don't see why this these are needed, as they cannot be used by the TLC? If there's a need to corrololate requests and activations, it can be done via a single id.

All messages in RSMP have a unique message id. When you send an RSMP command, you first get an aknowledgement, which references the original message. Many commands take time for the TLC to complete. So later you get a command responses, telling you whether the command was complete, or failed. Unfortunately, a command response does not reference the original command.

We should either send a request id in the command (the UniqueID in the original proposal), or rely on the RSMP message id, and as a more general solution require that command responses reference the rsmp message id of the cmmand that triggered them.

Based on that I have this updated suggestion:

Name	Type	Values	Explanation
securityCode	string	[text]	Security code 1
signalGroup	ordinal	[text]	rsmp component id of signal group
direction	ordinal	[1-255]	is this needed?
requestID	string	[text]	Unique identifer, used for tracking later activations
status	boolean	True/False	True: request priority, False: cancel request

In addition I think we should consider a status for priorities. That way you can get data about all priorities that are requested/activated/cancelled. This could cover priorities activated by inputs/loop, although in that case there will be no request id, since there was no priority command.

[rafaelcf2]

Hi,

Looks good, maybe we can arrange a meeting i net next days to discuss this. I Believe we establish the draft for the message very soon.

BR Rafael

[emiltin]

If we define a status message for priorities it could have info like Rafael suggest, with the request id, signal group, direction, cycle counter, green extensions, etc. The command response could be then be kept simple, simply telling you if the priority was given.

[emiltin]

After some discussion, here's an updated proposal.

A command request is send to activate priority of a specific signal group. The signal group is referenced by it's component id. You can specify a level; higher level requests override lower levels. You pass an id that is arbitrary, but can be used to track the request status in later responses, or to cancel the request:

Name	Type	Values	Explanation
securityCode	string	[text]	Security code 1
componentId	string	[text]	rsmp component id of signal group
requestId	string	[text]	Unique identifier, used for tracking later activations
level	integer	[0-100]	0: cancel, 1: lowest, 100: highest

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

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

CommandResponse: 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 was not acticated

If you want additional data, you can subscribe to status messages. This can be done from a different system that the system sending requests. Only update rate 0 is allowed, ie. you get a status every time there's a change. Otherwise the TLC would need to aggregate these statuses, and it's not clear how that would work?):

Name	Type	Values	Explanation
componentId	string	[text]	rsmp component id of signal group
requestId	string	[text]	Unique identifier, used for tracking later activations
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 of queued. This makes it possible for other system to see when a request is initiated.

The attributes greenExtension, redReduction and previousStage are omitted when status is queued.

In case a priority is given, but later 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 sum all extension times to see how much priority was really given.

[otterdahl]

With this proposal there is a lot of parameters (green/red time extensions, etc.) transmitted using RSMP with each priority request. In other priority strategies, e.g. PRIBUSS, all of those parameters are predefined in the TLC configuration.

Is APTP implmeneted in other protocols? or is it an internal configuration of the TLC? Have any vendors implemented this yet?

[SwarcoPalm]

I just wanted to raise the PRIBUSS flag also, it’s already in heavy use in Sweden.

[rafaelcf2]

Anyone have link to PRIBUSS implementation? Maybe we can harmonize with this message. Dynniq have a similar implementation in CPH but don't know if this solution is used in other locations

[emiltin]

With the proposal, data about extension time is only send if you subscribe to it. The command response only contains a true/false status.

But of course, if the priority is always the same, perhaps there is no need for the status mesage to contain the data.

[emiltin]

With this proposal there is a lot of parameters (green/red time extensions, etc.) transmitted using RSMP with each priority request. In other priority strategies, e.g. PRIBUSS, all of those parameters are predefined in the TLC configuration.

The proposal does not send this green/red time extensions with the request. You only send a request id, and a level. green/red time extensions are optionally returned in a status message, if you subscribe to it.

[SwarcoPalm]

The question I think is if RSMP should try to encompass many PT priority algorithms/modes (which might be harder to properly test with all available methods), or if it should adapt an already used approach (PRIBUSS or similar), or it should try to force its own way of doing priority (which would make it less compatible to existing methods)

[emiltin]

@SwarcoPalm Good question. To answer that I think we need to first look at these other specifications.

How can we access the PRIBUSS specifikation? What other PT algorithms should we look at?

[otterdahl]

How can we access the PRIBUSS specifikation?

I suggest contacting city of Stockholm, since they developed the standard. I'll send contact info

[emiltin]

Some standards allow passing an expected arrival when you request priority. This enables the controller to better plan priorities ahead of time. I suggest we support this. I imagine you can send several requests with the same requestId, to update your request as you get nearer the intersection. If you leave our the expected arrival time, or its set to "now", you request the priority immediately. You can also just just a single request without expected arrival.

[josvanvlerks]

expected arrival time is already part of the data from the bus service provider Movia in Copenhagen and can easily be part of any bus priority system. So it might be a good idea to take this into account in the RSMP message in some way, even though the arrival timing and messaging etc. can also be handed by the bus priority system itself.

[emiltin]

With the current proposal a signal group (or compoent id of a signal group) is used to indicate the direction you want to prioritize. A drawback, compared to activating input, is that you can't take advantage of signal program logic.

Many existing solutions work (eg in Copenhagen) work by activating an input. The signal program can then be setup to extend specific phases, etc.

Maybe it's better that our priority message specifies an input. This is then activated, and the program logic is used to extend, etc. The benefit over simply activating the input would be that you have a request id that you can use to track how much priority is actually given. We can also still use a level, if the signal programming can somehow use it.

[otterdahl]

City of Stockholm currently procures a system for bus priority and I think they would like to be part of this discussion as well.

[PetterEistrand]

I co-manage* the Swedish Traffic Signal Priority pilot in the C-ITS project NordicWay3. In the project group we have Region Stockholm (PTA), to which the procurement link goes, not City of Stockholm.

We will coordinate with the Region Stockholm procurement group in order to support them in avoiding proprietary solutions.

Most likely RSMP will be included in the NW3 architecture and probably the Region Stockholm dito as well.

*Sweco on behalf of Trafikverket

PS. City of Stockholm is now procuring an Asset Management System, for among others TLCs. Stockholm is also in NW3.

[josvanvlerks]

Hi all,

I know that Oslo is also having a bus priority system developed, and they are also using RSMP. Should they also be invited?

[otterdahl]

NordicWay3 has decided to publish some presentations on "Common learning sessions". You can check out my presentation on RSMP and bus priority and listen to the discussion afterwards.

[emiltin]

Due to length of discussion, this is continued in a new issue at #129