Skip to main content

RSMP (Traffic Management)

RSMP, the Road Side Message Protocol, is an open standard for supervising roadside equipment. It comes out of a Nordic cooperation between road authorities, is maintained by RSMP Nordic, and is used beyond the Nordics as well, including in other European countries. Because it is open and vendor-neutral, equipment from any supplier that implements it is supervised the same way.

It is also not specific to one kind of equipment. Traffic light controllers, variable message signs, weather stations, tunnel and barrier equipment are all supervised through the same protocol, each described by its own SXL.

Yggio speaks RSMP as a supervision system. Whatever is connected becomes ordinary Yggio devices: they appear in views, they can be filtered on, they drive rules and reports, and they sit on the map alongside everything else in the estate.

What Yggio decodes today. The implementation covers the traffic light controller SXL (1.0.15): signal groups, detector logics, alarms and aggregated status. Other RSMP equipment types use the same connection and the same protocol, but each needs its own SXL decode before its values arrive named rather than raw. Ask support if you have equipment that is not a traffic light controller.

Setting up a site is three steps: create the RSMP connector, install the controller component, then install the detector logics and signal groups. The connector is one page on its own; the two installation steps are described below.

What a traffic light controller reports

An intersection is one site, and a site contains many parts. Two status messages carry almost everything:

  • S0001, signal group status. One character per signal group, describing what that group is showing: green, red, yellow, red-yellow, dark, flashing.
  • S0002, detector logic status. One character per detector logic, 1 when the detector is occupied and 0 when it is not.

Both arrive as a single string covering the whole array, not as separate values. A real S0001 from a twelve-group intersection looks like this:

"sCI": "S0001", "n": "signalgroupstatus", "s": "F5F35F5F1F5F"

and a detector logic message from a site with a hundred detectors like this, truncated:

"sCI": "S0002", "n": "detectorlogicstatus", "s": "0100000001100011100000000000..."

Position 2 is a 1, so detector logic 2 is occupied. Everything else in that excerpt is clear.

Fan-out: one position per device

A string is not much use in a dashboard, so Yggio cuts it up. Each component you install claims one position, and Yggio writes only that position's value to that device.

A device list showing 100 detector logics fanned out, each with its own value and quality

The four roles decide how a component reads the raw status:

RoleRepresents
ControllerThe controller itself: aggregated status, alarms, connection state
Detector logicOne position of S0002
Signal groupOne position of S0001
GroupA chosen set of positions, gathered into one device

Because each position becomes a device, everything that works on devices works here. A view filtered on signalGroup gives the state of an intersection at a glance:

A device view of six signal groups, showing output colour, green, yellow and red state, and quality

A second RSMP device view

For watching detector logics as they happen, the Swimlane widget is an excellent choice. It gives each detector its own lane and scrolls them together, so a vehicle crossing several detectors in sequence is visible as a pattern rather than as separate numbers changing. A detector logic is occupied or not, which makes the lanes easy to read side by side. It is a live view and keeps no history, so use it to watch an intersection rather than to look one up afterwards.

You need the SXL

The SXL, signal exchange list, is the controller's own specification: which detector logic and which signal group occupies which position, and what each one is for. It is an RSMP concept, not a Yggio one, and the site's road authority or controller supplier has it.

Without the SXL, positions are guesswork. This matters more than it sounds, because a component pointed at the wrong position does not fail: it reports a real value from the wrong detector, and it does so convincingly. Confirm at least two positions against the SXL before trusting the rest.

Get it before starting the installation below, not after.

Installing components

Nothing is created automatically. After the connector exists, each component you want in Yggio is installed as a device, from New device with the RSMP device type. The same form is used for all of them; the role is what makes one a controller and the next a detector logic.

Install the controller first, then the detector logics and signal groups.

The RSMP Component info step of Install device, with component ID, external node ID, connector, status codes, role and detector logic number

FieldDescription
Component IDThe component's identifier in the controller, in SXL form, for example AA+BBCCC=DDDDL001. It must match the controller exactly, and each device needs its own
External Node IDThe node identifier, for example X00001
RSMP ConnectorThe connector for this site
Status CodesWhich status messages this component subscribes to: S0001 - Signal group status, S0002 - Detector logic status, or both
RoleWhat this component represents, which decides how the raw status is read
Detector logic number / Signal group numberWhich position in the status string this device reads, counting from 1. Shown for the roles that need it

The devices are siblings rather than a hierarchy. A detector logic does not sit underneath the controller device: each one references the connector directly and carries its own component ID. The controller is simply the component whose role is Controller.

Verifying

  1. Check that the controller connects: the controller component's connection state should be live rather than timed out.
  2. Install one detector logic and wait for the next status message.
  3. Confirm its value matches what the SXL says that position should be.
  4. Compare a second position before trusting the rest, since an off-by-one in the index produces plausible values rather than an error.

When a component misbehaves

It reports nothing. Check that the status code subscription matches the role: a detector logic needs S0002, a signal group needs S0001. A component subscribed to neither receives no status.

It reports the wrong thing. Almost always the index. Positions count from 1 and are defined by the site's SXL, not by the order the components were installed.

Its values repeat. That is the controller, not Yggio. See repeated values.

Repeated values

The controller sends the whole array whenever anything changes, including the values that did not. If one detector out of a hundred goes occupied, all hundred positions are sent again, and the ninety-nine unchanged ones arrive with the same value they had before. A detector logic sitting at 0 can therefore be reported as 0 many times over.

This is normal RSMP behaviour, not a fault, but it matters for anything downstream:

  • Yggio suppresses the repeats. Each component's slice is compared against the last value written for it, and an identical repeat is not written again. So the device's history reflects actual changes rather than message traffic.
  • Do not count messages as events. A rule that fires on "reported" rather than on a change would fire on every uplink for every position. Trigger on the value changing.
  • The timestamps are the controller's. In the example data above, ten status messages arrive within about three and a half minutes, which is the cabinet reporting, not the detectors changing that often.

Freshness

Signal group status carries a quality flag from the controller, and Yggio surfaces it on the device. In the views above it reads recent on live data and old on stale data.

Treat it as part of the reading. A signal group showing green with quality old is telling you what it last knew, not what the light is doing now, and an operational view should make that visible rather than hide it behind the value.

Alarms and aggregated status

Alongside the status messages a controller sends:

  • Alarms, each with an alarm code, a state and a timestamp, for example code A0010 moving to inActive. These route to the component they belong to.
  • Aggregated status, the controller's own summary of its condition.

Both land on the controller component, which is why it is worth installing one even when the detectors and signal groups are what you are really after.