1.1 draft #132
1.1 draft #132
Conversation
Discussed in #94
Remove docs/ used to publish the documentation in HTML format. The documentation is published in the rsmp_specification repo instead
Also remove the creation of docs/ in the Makefile
Reported by @wWestendorf. Fixes #136
- Clarify - Fix error in example - Add another example - Use ";" according to spec (rather then ":"). Also applies to M0012
Use integer instead of long in S0016,S0017,S0018,S0019,S0201,S0202
Shorter description text of A0005 and A0007. Also adds additional information in A0007 about the source of the error e.g. RSMP or NTP Fixes #77
Rename 'type' to 'protocol' to make it clearer Discussion in #77
Discussion in #90
Remove unnecessary column in aggregated status and fine tune column widths in order to improve readability
Improve the definition. Discussed in #102
A number of statuses uses comma separated lists for all values in order to have different status for each intersection (ring). - S0007 - S0008 - S0010 - S0011 - S0012 - S0013 - S0020 Discussion in #122
"Source" contain the reason for the new status,
e.g. "operator panel", "calendar clock", "control block", "forced" etc..
Affects the following statuses:
S0007 Controller switched on
S0008 Manual control
S0009 Fixed time control
S0010 Isolated control
S0011 Yellow flash
S0012 All red
S0014 Current time plan
S0015 Current traffic situation
Discussion in #67
| ============ ======= ================================================================================= ================================================================================================================================================================================================================================================= | ||
| intersection integer [0-255] Comma separated list of intersections which the status relates to, |br| e.g. "1,2". Use "0" for all intersections of the TLC | ||
| status boolean -False |br| -True False: Traffic Light Controller in dark mode |br| True: Traffic Light Controller not in dark mode | ||
| source string -operator_panel |br| -calendar_clock |br| -control_block |br| -forced |br| -other operator_panel: Operator panel is the source |br| calendar_clock: Calendar/clock is the source |br| control_block: Control block is the source |br| forced: Forced due to command from e.g. RSMP |br| other: TLC switched status due other reason |
There was a problem hiding this comment.
what status is it in after starting up?
There was a problem hiding this comment.
Good point. I suggest adding startup as a source
| -emergency |br| tram: Trams used for Public transport |br| | ||
| -safetyCar |br| emergency: Police, fire or ambulance |br| | ||
| -specialTransport |br| safetyCar: For e.g. escort vehicles |br| | ||
| -other specialTransport: For e.g. heavy load |
There was a problem hiding this comment.
description of 'other' missing
|
|
||
| Set timeout for dynamic bands | ||
|
|
||
| Switch to a designated time plan if this timeout is reached due to lost connection with the supervisor. |
There was a problem hiding this comment.
we could explain this better. i think the intention is that the conection to the supervisor has been down for a certain time, then the timeplan is switched.
another thing: if multiple supervisor are connected, is it enough for one to be offline for the specified time?
There was a problem hiding this comment.
Should we change to: "lost connection to the primary supervisor"?
It also doesn't state which time plan to switch to. Should this be added?
There was a problem hiding this comment.
well, yes, but in that case, why is this even related to dynamic bands?
is the intention rather to reset dynamic bands when the timeout is reached?
There was a problem hiding this comment.
Ok. I see.
Either we change the description to either say "Reset the dynamic bands if this timeout is reached..." or we add timeplan and make it generic (not specific to dynamic bands).
I remember that we have discussed whether this command should be universal or specifically target dynamic bands. I understand that this type of functionallity is basically required for dynamic bands, but I have previously not been convinced about the actual need for it for other types of commands -- at least not in Sweden (and we're not using dynamic bands).
At least here, commands are not continously sent as part of the regular traffic control. But of course, things my be different elsewere. And I guess we don't have to use it unless we need it.
Clarify that cycle counter needs to be calculated using modulo
Don't specify if new priority requests can override existing ones
…ights into 1.1-draft
The latest draft can be viewed at http://rsmp-nordic.org/rsmp_specifications/rsmp_sxl_traffic_lights/1.1-draft/