The MS2Data format is an XML file format that allows the transfer of data between traffic counter equipment and the MS2’s system. Since version 1.19.0, FLOW supports the following formats of the MS2Data Import Format Specification version 1.8:

This article will guide you through the set-up process for sending each of these formats.

In FLOW Insights, you can find the MS2 interface overview page in the left menu among the other interface types.

When you add a new MS2 interface and go to the edit screen, you'll be able to set up its various options.

Fill the address and port of the target MS2 server. The username and API key will be used as part of the request to authenticate FLOW messages. The protocol used will always be HTTPS.

Example: If the fields are filled as follows:

Then MS2 data HTTPS requests will be sent to https://example.ms2server.com:443/api/Import/v1/tcds/Upload/Ms2Data?username=JohnDoe with the ApiKey: FooBar header.

There's no conclusive mapping of FLOW vehicle categories to the 13 FHWA classes that MS2 uses. That's why the interface lets you define your own mapping if the default one doesn't suit your needs. Note that when sending TMC messages, FLOW presents its own category types and the mapping isn't used.

When you select Save settings and go Back to the interface overview, the Connection status column will show you whether FLOW has successfully connected and authenticated with the server using its /api/Import/v1/tcds/Upload/Ping endpoint.

To actually send data to the server, you first need to create a topic and connect it with an existing Traffic events widget or an Event expression widget.

For this example, a zone has been created over each traffic lane that approaches the intersection and an Events widget has been attached to each one.

You may want to change this setup depending on the chosen MS2 data format. You can find details about appropriate setups for each format below in the corresponding format sections.

Now you can go back to editing the MS2 interface. Add a topic, edit it, fill the required fields, and select the Events widget that should act as a source of data. Then select Apply on the bottom.

From now on, data collection starts for the new topic and, once the minimum duration has elapsed, it'll be sent to the MS2 server. In the topic table, the Last processed data timestamp column shows the timestamp of the end of the time interval before the current one. Alternatively, you can think of it as the start of the current data collection interval. Last message sent timestamp shows when data has last been successfully delivered to the MS2 server. All times are UTC.

The MS2 data module lets you select the data format as listed at the start of this article. Each format has specific fields to fill and determines FLOW's data collection and sending behavior as required by the MS2 format specification. Location specifiers (site ID, sensor ID, MS2 location ID, and TMC intersection ID) are assigned and provided by the MS2 company. If you opt to specify the location with the MS2 location, direction, and lane number, you may omit one or both of the latter to select the level of detail that the topic provides. I.e.:

Depending on the level on which you want to provide data, you should adjust the layout of the gates or zones in the associated analytic. E.g. if you provide only roadway-level data, create a zone that covers an area that all vehicles must pass. For directional-level data, create a gate for each leg of the intersection that covers all approach lanes. For lane-level data, make a gate for each approach lane separately. For each spatial operator/widget pair, you need to create a separate topic and assign it to the widget.

Analytics let you specify their WGS 84 coordinates in Analytics settings. In Topic settings, you may then choose to include these coordinates in data exports to the MS2 server. If you georegister the analytic, you can also include vehicles' average speed in the exports. Alternatively, you can pair a topic with an Events widget that is attached to a Movement operator and set the length of this operator. This lets you send Section speed of passing vehicles.

The Send only data newer than field lets you setup a survey for a specific time in the future—older data won't be sent. Keep in mind that the specified time will be considered UTC and compared to the current time of the analytic's video source (usually a camera).

This format lets FLOW send information about each passing vehicle on the chosen level of detail, namely: time when the vehicle trajectory has ended, FHWA class, and speed (its type is based on your choice during topic setup). Information that you entered during topic setup will also be included.

Due to MS2 server limitations, FLOW must collect at least 24 hours of continuous data before sending it. Therefore, video stream availability disruptions of a cumulative length larger than 72 minutes per 24 hours will cause FLOW to discard all collected data and start again. Restarting FLOW will also cause you to lose collected data that hasn't yet been sent to the server. As soon as FLOW has 24 hours of continuous data, it sends it to the MS2 server with a grace period of 10 seconds.

This format simply aggregates counts of passing vehicles for the specified roadway/direction/lane in 1, 15, or 60-minute intervals. It provides lower level of detail than the PVR format, but is less data transfer intensive. The same limitations regarding having at least 24 hours of data as with the PVR data format are also true with this format.

This arguably most detailed format is similar to PVR, but additionally it includes the direction in which vehicles travel through the intersection (left, straight, right etc.) and enables FLOW to send its own vehicle category name instead of using the FHWA class number. The location specifiaction must include a MS2 location ID, direction (which in this case is the approach direction), and TMC intersection ID. This format doesn't distinguish between individual lanes.

Therefore, the optimal setup for this data export might look something like this.

A single zone encompasses all approach legs, but could be replaced by a gate placed at the stop line across the full width of the road. A gate's been created for each possible direction the vehicles could go, and a movement is connecting each of them with the original zone. The movements were dragged to the canvas on the right and an Events widget's been attached to each of them.

Now that the Event widgets are separated by target direction, three different topics can be created, each being paired with a different widget. If your camera view encompasses multiple approach legs, you'll have to repeat the above process for each leg. (It's possible to reuse the gates, but movements and the attached widgets must be unique.)

Unlike with the previous formats, minimum length of collected TMC data before sending to the MS2 server is 15 minutes. That's also the interval in which FLOW will send the collected data to the server, with a grace delay of 10 seconds. However, the 15-minute time blocks must be complete (the maximum allowed cumulative gap is 45 seconds per 15 minutes) and aligned to the whole hour (intervals start at 0 minutes, 15 minutes, 30 minutes, and 45 minutes each hour). Therefore it's possible that in the topic table you could see that the Last processed data timestamp is in the future. This means that FLOW is waiting for the current incomplete interval to end so that it can start the next aligned one.

If you need further clarification or help, click the button on the bottom right to chat with us or contact us here. We're happy to help!