Module 45 - A309b

A309b: Understanding Requirements for Ramp Meter Control (RMC) Units Based on NTCIP 1207 Standard v02

HTML of the Student Supplement

(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)


Understanding Requirements for Ramp Meter Control (RMC) Units Based on NTCIP 1207 Standard v02

Table of Contents

Ramp Metering Layout, Terminology and abbrs - 2

Ramp Metering Strategies - 5

Understanding RMC Requirements - 6

RMC Functions Covered in Annex B of the Standard - 11

Procedure to Write a Well-Formed Requirement - 13

Preparing Project Level PRL and RTM - 13

References - 17

Study Questions - 18

Module Description

The purpose of this module is to help users learn how to identify and prepare well-developed requirements. This step is necessary because the RMC standard was developed without systems engineering process (SEP) and hence does not have documented user needs and requirements, but does have Ramp Meter Control (RMC) design objects. This module also helps users understand the scope and application of the NTCIP 1207 v02 Standard.

This module is conceptually similar to a freeway management system (also called Traffic Management System (TMS) that uses ramp meters to control the flow of traffic from an on-ramp to the mainline freeway lanes to improve mainline traffic speed and throughput and reduces travel time and rear-ends crashes at merging lanes on highways. To achieve these key objectives within freeway traffic management, the NTCIP 1207 v02 Standard provides standardized design objects (but without documenting user needs and requirements).

This module focuses on the RMC requirements and the communications interface aspects—how to

configure, monitor, and control ramp meters remotely from a TMC or locally at the front-panel— using data objects provided by the NTCIP 1207 v02 Standard. The metering plan includes fixed control interval, local-responsive, and a coordinated-corridor wide strategy. By deploying standard-based data objects, users will gain interoperability, maintain compatibility, and achieve vendor-independence. It will provide participants with information on how to identify the appropriate use of the NTCIP 1207 v02 Standard and acquire RMC units based on what the user is seeking to accomplish. This will be supported with tools and resources such as a management information base (MIB), conformance groups (CGs), and the SEP.

Readers are advised to follow the curriculum path with modules I101, A101, A102, A103, and A201, A202, A203 and A309a as prerequisites (last three modules on the development of user needs). Students are also advised to consult SEP-based standards such as NTCIP 1204 v03 ESS (Annex F) to learn how to organize and adopt requirement applicable to RMC.

1. Ramp Metering Layout, Terminology and abbrs

The following RMC terminology and the components shown in Figure 1 have one or more associated Requirements and corresponding design-objects. It is important to understand what each term means and why.

Ramp Meter is a traffic controller (such as Type 170 or 2070 or ATC) equipped with software/firmware and algorithms specific to a freeway ramp to control (to meter) traffic flow entering freeway lanes. A ramp controller also can be used to control an intersection.

Ramp Metering is a release rate, expressed in vehicle per hour per lane (vphpl), at which vehicles are allowed to proceed through the metered lane signal. For example, a Ramp Meter could allow 500 vph per lane (vphpl) release rate, based on one or two vehicles per green.

Figure 1: Ramp Metering Layout. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant notes: Figure 1: Ramp Metering Layout. The slide has two graphics on the right. The top right layout is shown with detailed components of the RMC unit. Three detectors on the mainline are shown as small square boxes with three outbound arrows for each lane, showing the direction of traffic flow. On the metered lane, several detectors are shown on a ramp with an inward facing arrow that goes towards the freeway mainline with the labels queue detector, demand detector, and passage detector being the last one after the STOP line)

Figure 1: Ramp Metering Layout

Ramp Metering Control (RMC) is a system in which the entry of vehicles onto a freeway from an on-ramp is controlled by a traffic signal, allowing a fixed number of vehicles to enter from each metered lane of the on-ramp during each cycle. A ramp metering system consists of various components. Often these components are elements within larger freeway management architecture. Each of these components has a certain requirement that we must identify and include in a project specification.

RMC Unit consists of the field controller, its suite of sensors, its warning signs and signals, and stop bar pavement marking. A stop bar pavement marking is where the vehicle must stop first for green. Figure 1 illustrates a typical layout of a ramp meter installation. Please note that not all projects require multiple lanes and associated detectors on the ramp, however, for a responsive operation, mainline detectors are required.

A typical RMC system unit has the following components:

Ramp Metering Signal and Controller - The signal is typically located to the driver's left; or both sides of the on-ramp. Each ramp meter typically has one nearby weatherproof control cabinet which houses the controller, modem(s), and inputs for each loop. A multi-lane ramp meter is served with a single cabinet. The controller is set to a specified algorithm, which controls the ramp metering rate.

Advance Warning Signage - MUTCD (Manual of Uniform Traffic Control Devices) recommends one or two advance warning signs with flashing beacons indicating that ramp metering is active.

Demand or Check-In Detector - The check-in, or demand detector is located before the stop line. The check-in detector notifies the controller that a vehicle is approaching and to activate the green interval. It is common to use two or more demand detectors per lane to avoid situations where a vehicle stopped just upstream of the detector is not recognized by the controller and the ramp meter fails to switch to green.

Check-Out Detector - The check-out, or passage detector is located downstream of the ramp metering cordon line. The check-out detector notifies the controller that a vehicle has passed

through the ramp meter and that the signal should be returned to red. In this manner, one vehicle passes per green interval. (Note that in a situation where a ramp meter allows two vehicles per green, controller will confirm departure of both vehicles).

Merge Detector - The merge detector is an optional component which senses the presence of vehicles in the primary merging area of the ramp. To prevent queuing in the primary merging area, the controller holds a red indication if the merge detector indicates a vehicle within this area. This prevents vehicles having to merge onto the freeway from a stopped position, requiring additional acceleration distance on the mainline and disrupting mainline vehicle speeds. This typically occurs when a timid motorist hesitates, impacting subsequent vehicles. In the case of single-entry metering, subsequent green intervals are preempted until the vehicle merges.

Queue Detector - The queue detector is located on the ramp, upstream of the check-in detector. The queue detector prevents spillover onto the surface street network. Continued actuation of the queue detector with no actuation of the check-in detector indicates that the first queued vehicle has stopped in advance of the check-in detector, and the ramp metering signal should be turned to green to allow this vehicle to proceed. Once ramp queues reach the queue detector and queues begin to spill onto the surface street, the metering rate is altered or metering is terminated. This is also prevented with multiple check-in detectors, as already discussed.

Mainline Detectors - Mainline detectors are located on the freeway upstream, and downstream of the on-ramp. For isolated ramp metering applications, only the occupancy/flow registered from upstream detectors influences the ramp metering rate if the metering is adaptive (not preset), responding to traffic conditions. For ramp metering systems, data from both upstream and downstream detectors influence the metering rate.

On-Ramp - The on-ramp, itself, must possess characteristics suitable for metering, namely the availability of vehicle storage space on the ramp, and adequate acceleration and merge distance downstream of the meter cordon line. Storage requirements to prevent queues from backing up onto the arterial network can be estimated from the projected metering rate and ramp demand. Ramp design manuals issued by many state agencies are available on agencies' websites.

Flow Rate - The flow rate is the rate at which vehicles pass a detection zone, expressed in vehicles per hour per lane (vphpl), e.g. 400 vphpl.

Dependency Group - The dependency group is a group of metered lanes in which the signal sequencing is dependent on the other lanes in the group. Metered Lane Dependency is a relationship between metered lanes under control of a single RMC unit. (Note: In multi-lane configurations, metered lanes may operate independently of each other, or the interval of one may depend on the interval of the others.)

Metered Lane is the lane on the ramp that is equipped with a signal. Typically one lane, but in some cases two lanes are found to be metered. In some rare cases, a three-lane operation is possible.

Metering Plan is a table of metering rates, and occupancy, speed and volume thresholds to be used for traffic responsive metering decisions.

Metering Rate - The rate at which vehicles are allowed to proceed through the metered lane signal, expressed in vphpl.

Occupancy is the percentage of time that vehicles are present in a detection zone, expressed in units of 0.1%.

Passage Detector is the detector on the downstream side of the metered lane stop bar and detects vehicles passing the ramp meter. It is used for signal sequencing and metered lane volume counts.

Queue Override is the process that adjusts the metering rate based on traffic conditions at the queue detectors to shorten the length of the queue.

abbrs used in this Module

ASN.1 Abstract Syntax Notation 1 Language (ASN.1)

ATDM Active Traffic Demand Management

CGs Conformance Groups

ICM Integrated Corridor Management

MIB Management Information Base

NTCIP National Transportation Communications ITS Protocol

OID Object Identifier

PDU Protocol Data Unit

PRL Protocol Requirements List

RMC Ramp Metering Control

RTM Requirements Traceability Matrix

SNMP Simple Network Management Protocol

VarBinding Variable Binding

Vphpl Vehicle per hour per lane

2. Ramp Metering Strategies

Why Ramp Metering?

Freeway on-ramp supply demands: balancing demand with fixed capacity of the mainline lanes is the core objective. To achieve this objective, agencies implement freeway management strategies around key actions listed here. The RMC standard documentation provides for management of such strategies in the form of an Action, which implies what the ramp meter does (a Function).

All RMC operational actions are outlined as: fixed rate metering action, traffic responsive metering action, dark (no metering), and green. Both fixed and responsive metering is heavily practiced in the country, while the recent emergence of corridor wide metering (also called coordinated metering) which uses complex adaptive algorithms such as SWARM (Caltrans) and Washington DOT bottleneck. Thus, in general using Ramp Metering strategies, agencies influence the outcomes (benefits) within the freeway management on a time of day basis.

The following section discuses features (user needs) covered by the standard for which design objects are provided. In most cases, user is required to state a major desired capability (MDC) in detail for these user needs and ensuing requirements. For example, does the agency have a need for a fixed rate or a traffic responsive rate operation; and how many metering plans are to be developed?

3. Understanding RMC Requirements

Typically, RMC unit operates within key areas of metering-detectors, metered lane, command source and actions performed, metering plans and their levels. This section explains how they are described as translation of user needs. The standard covers the following areas of the RMC requirements:

Freeway Segment:

On-Ramp Operation:

Command Sources:

Command Actions:

Each of these functions is illustrated in Figure 2 below. In our approach for developing RMC requirements, we must understand how RMC works so that we can properly specify what and how these functions are to be performed at a project level.

Figure 2: Illustration of RMC Functions. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant notes: Figure 2: Illustration of RMC Functions. The figure uses several photos to describe what RMC functions are. A detector station using an arrow feeds current data to the RMC controller in the middle, and a TMC connects to the RMC unit. The RMC unit connects to a signal head shown on the top right side, another signal head underneath, and to a sign that shows meter ON. Thus, the RMC receives data and controls on the left side and provides for passing of controlled number of vehicles per green on the right side.)

Figure 2: Illustration of RMC Finctions

The following are high level descriptions of the requirements taken from Annex A, which translate the above functions.

A.1.1 Mainline Detector Station

The RMC unit shall have a maximum number of mainline lanes parameter to indicate the number supported by the RMC unit, and a number of mainline lanes parameter to indicate how many mainline lanes are currently operational. Each lane shall have a mainline lane number parameter identifying which lane it represents. (Note: for a traffic responsive metering, a detector station is required).

A.2.2. Metered Lanes

The RMC unit shall have a maximum number of metered lanes parameter to indicate the number supported by the RMC unit, and a number of metered lanes parameter to indicate how many metered lanes are currently operational. Each lane shall have a metered lane number parameter identifying which metered lane it represents.

Each lane consists of one passage detector, one demand detector, and a variable number of queue detectors.


Each metered lane shall have a priority-based mechanism with five metering command sources:

Note: Image of an arrow pointing down is located on the left of the following numbered list 1-5. A box at the top has the word Highes.

  1. Manual: Manual commands are entered into the RMC unit locally through front panel, laptop or other user interface; fixing this at the highest priority indicates that an authorized user at the RMC unit may need to take complete control.
  2. Communications: Communications commands are issued by the Transportation Management Center or other control center. (NTCIP 1207 Focus)
  3. Interconnect: Interconnect commands are peer-to-peer communications from other field controller(s) which may have more knowledge of local conditions or may contain the mainline detectors instead of the RMC unit.
  4. Time Base Control: Time Base Control commands use the NTCIP global plan and event tables and are executed on a regular basis or for special events / holidays.
  5. Default: Default commands are implemented in the absence of any other mode or upon initial startup.

Each metering command source shall have four parameters which are Action, Rate, Plan and Vehicles-per-Green.

Each Action parameter shall operate as follows:


The RMC unit shall have a metering plan table containing all of the Metering Plans. The RMC unit shall have a maximum number of metering plans parameter to indicate the number of metering plans (4-100) supported by the Metering Plan Table, and a number of metering plans parameter to indicate how many metering plans are currently supported, e.g., have one or more Metering Levels with non-zero Metering Rate entries. Each plan shall have a metering plan number parameter identifying which plan it represents.

The RMC unit shall have a maximum number of levels per metering plan parameter to indicate the number of levels (2-50) in each plan supported by the Metering Plan Table for each plan, and a number of metering levels parameter to indicate how many metering levels are currently operational. Each metering level shall consist of:

  1. Metering Rate (0, 120-1800 vph in 1-vph increments).
  2. Occupancy Threshold (0, 5.0-30.0 percent in 0.1-percent increments).
  3. Flow Rate Threshold (0, 1000-3600 vph in 1-vph increments).
  4. Speed Threshold (0, 15-100 km/h in 1-km/h increments).

Figure 3 illustrates how a typical traffic responsive plan works.

Figure 3: Traffic Responsive Metering. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant notes: Author's relevant notes: Figure 3: Traffic Responsive Metering: same as Figure 1 description. In this figure a text box is added at the top to show how Occupancy, Flow Rate, and Speed parameters are used in traffic responsive metering.)

Figure 3: Traffic Responsive Metering

The general theory driving the traffic responsive practice is based on an approximate relationship between lane volumes (Flow Rate) and lane occupancy at capacity. For each level of occupancy measured (by mainline detectors), a metering rate can be computed that corresponds to the difference between the predetermined estimate of capacity (such as 2000 vphpl) and the real-time estimate of volume (average taken of computing period, usually 30 seconds). If the measured occupancy exceeds or equals the preset capacity, a minimum metering rate is selected. The lowest metering rate is also used when demand exceeds capacity. For further reading, students should consult the FHWA Freeway Management & Operations Handbook (Ref. 6-7 and Ref. 11-12 for original work by the state agencies).

Figure 4 illustrates a change in Occupancy (due to mainline traffic condition) at different time intervals and how it links to a new metering rate needed to avoid/reduce congestion. The figure presents a scenario with a reported 20% occupancy rate (7:30 AM), which changes to 31% rate an hour later. Metering rates are computed at 480 and 240 vph respectively. The table shows the relationship, a published one by FHWA for guidance. This example also indicates that levels are in essence pre-sets for a metering rate.

[Note: Some states DOTs have also developed proprietary algorithms that use density as a measure to develop responsive-forecasting based metering. The standard does not support that method currently].

Figure 4: Illustration of Metering Rate computation Based on Change in Condition. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant notes: Figure 4: Illustration of Metering Rate computation Based on Change in Condition. The photo to the left of the table in the center of the slide shows a roadway section with cars at about 8 a.m. The photo to the right shows another roadway with more traffic at 9 a.m. The table presents various Occupancy % in the first column and Metering Rate in second column. A green arrow points to 20% Occupancy on the left and the red arrow points to 31% occupancy, also on the left column of the table. Both show metering rate (8 and 4 respectively). Thus, we are showing how occupancy at a particular time will determine what rate will be computed by the RMC at that time.)

Figure 4: Illustration of Metering Rate Computation Based on Change in Condition

Quick Summary: An agency decides to implement a traffic responsive plan, stored and available in a table, by selecting Plan X , with level Y (a combination of Flow rate, Occupancy and Speed data threshold). Such stored plans vary in number (from 4-100) and levels vary from from (2-50) to provide flexibility as and when needed to manage congestion on freeway lanes. Howewer in reality, an agency must decide based on a project need and avoid large numbers as cost and complexity will make it impractical. For example, a table with 10 plans would be too complex for a level-5 threshold, and thus impractical.

4. RMC Functions Covered in Annex B of the Standard

Figure 5: Navigating RMC Requirements Content. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant notes, for illustration purposes only: Figure 5: Navigating RMC Requirements Content. How to Navigate the Documentation. The figure presents a chart with text boxes that lead to requirements. On the left it starts with RMC Function (in this case a metered lane), which then leads to Objects for a CG, with Partial listing and Object name, which then leads to MIB Section with NTCIP 1207 Clause, which then leads to the Requirements (partial listing). Note RMS requirements areas are listed but not described by the standard-users will need to do that.)

Figure 5: Navigating RMC Requirements Content

Figure 5 indicates various sections linked in the documentation. We can navigate the key concepts, staring with RMC function. At the beginning, CG B.5 serves a metered lane function which leads to a grouping of related objects. A partial listing is shown here due to space limitation. The related objects are collected from the MIB section by their section clauses. Finally, Table B.2 provides RMC Unit requirements and references to pertinent standards. (Note, all NTCIP devices also need to include NTCIP 1201). Although RMC Requirements are not described by the standard, we will use Annex A and B to prepare them for each desired function.

In the RMC standard, functions are provided by Conformance Group (CG), which is a basic unit of conformance (traceability) and is used to specify a collection of related managed objects. The following portion of Table B.2 in Annex B lists these areas.

Ref Areas Clause of Profile Status Support
B.3 General Configuration Conformance Group NTCIP 1207-3.2 O Yes/No
B.4 Traffic Responsive Conformance Group NTCIP 1207-3.3 O Yes/No
B.5 Metered Lane Conformance Group NTCIP 1207-3.3 M Yes
B.6 Dependency Group Conformance Group NTCIP 1207-3.4 O Yes/No
B.7 Queue Detection Conformance Group NTCIP 1207-3.4 O Yes/No
  - Length Based Queue Detection   O Yes/No
  - Occupancy Eased Oueue Detection   O Yes/No
  - Quick Occupancy Based Queue Detection   O Yes/No
  - Rate Adjusted Queue Adjustment   O Yes/No
  - Level Adjusted Queue Adjustment   O Yes/No
  - Fixed Rate Queue Adjustment   O Yes/No
B.8 Passage Detection Conformance Group NTCIP 1207-3.B O Yes/No
  - Long Stop NTCIP 1207-3.5 O Yes/No
B.9 Time Base Conformance Group NTCIP 1207-3.6 O Yes/No
  - Mainline Scheduling NTCIP 1207-3 6 O Yes/No
B.10 Physical I/O Conformance Group NTCIP 1207-3.7 O Yes/No
  - Metered Lane Qutpul NTCIP 1207-3.7 O Yes/No
  - Dependency Group Output NTCIP 1207-3.7 O Yes/No
B.I 1 Block Object Conformance Gmup NTCIP 1207-3.8 O Yes/No
B.12 Configuration Conformance Group NTCIP 1201 -2.2 M Yes

The above table shows areas of RMC requirements and associated object clauses and columns for choosing if support is required for the project and checks yes or no.

RMC Conformance Group (CG) designation applied to a set of design objects provides a systematic means for determining which objects are required to support a function. If a device has multiple functions, a CG will be defined for each function. Figure 6 shows the relationship between key CGs and their multiple objects located in the MIB.

Figure 6: Relationship between Conformance Groups and their design objects. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant notes: Figure 6: Relationship between Conformance Groups and their design objects. The figure uses CGs on the left (Configuration, Metered lane, Traffic Responsive, Queue Detection, Block Objects) that lead to pertaining objects, in the middle (Object 1-n, Object x-z, Object a-c), and RMC Unit MIB on the right.)

Figure 6: Relationship between Conformance Groups and their design objects

The next concept we need to understand is traceability. "Traceability is the ability to follow or study the logical progression among the need, requirements, and design details in a step-by-step fashion".

For the RMC standard, the CG table discussed above traces functions to design objects. There is NO provision for tracing requirements to user needs in the standard.

However, CGs method of preparing a specification has been updated with a SEP-based PRL and an RTM tables approach. We have discussed in the training module, Learning Objective #3, how to prepare for and use traceability needs between user needs and requirements (PRL) and between requirements and associated design elements (RTM). As a result, we can use CGs content and insert that in both tables as it applies.

The next section provides a procedure to develop requirements, once they are identified from various sources.

Section 6 provides examples of PRL and RTM in which users can enter RMC requirements as rows.

5. Procedure to Write a Well-Formed Requirement

As discussed in the training module presentation, a well-formed RMC requirement is formed using the following two step process:

Step 1: Provide Structure of a Requirement (providing strong resolve)

  1. Actor identifies who requests the action.
  2. Action identifies what is to happen.
  3. Target identifies who or what receives the action.
  4. Constraint identifies how to measure success or failure of the requirement.
  5. Localization identifies the circumstances under which the requirement applies.

Step 2: Include Characteristics of a Requirement (forming sentences)

  1. Necessary: Must be useful and traceable to needs.
  2. Concise: Minimal, understandable, and expressed as a "shall" statement.
  3. Attainable: Realistic to achieve within available resources and time.
  4. Standalone: Stated completely in one place.
  5. Consistent: does not contradict itself, or any other stated requirement.
  6. Unambiguous: Susceptible to only one interpretation.
  7. Verifiable: Requirement can be verified through inspection, analysis, demonstration, or test.

Example: The following requirement is a necessary, concise, attainable, standalone, and unambigous statement. The requirement has Actor, Action, and Target at the core. This is a "well-formed" requirement. The user must check for the presence of each, while developing other requirements. Force is emphasized by using "shall" in the requirement.

Configuration Management

The management station (ACTOR) shall be able to retrieve information (ACTION) about the configuration of the RMC unit (TARGET).

(Every RMC unit needs this, it is necessary, can be done and stand-alone.)

6. Preparing Project PRL and RTM

In general, use of any NTCIP standard requires traceability between user needs and requirements; and between requirements and their allocated design elements-objects. SEP standards such as ESS and DMS have done well for users by providing clear cut use of traceability tables - PRL and RTM. Each project prepares a PRL and RTM for specification by customizing. However, in this module we have adopted formats for both tables and will learn how to enter user-developed user needs, requirements and standard supplied design objects, including generic dialogs from ESS standard. The following examples of PRL and RTM should guide users to prepare project level specification.

A project level Protocol Requirement List (PRL) traces requirements to the source that caused a requirement-user need. The PRL example shown below allows users to make row entries based on

what we have covered in two modules on RMC standard. First two columns are for user needs and next for requirements. If there is no user need, there is no requirement, meaning there has to be at least one user need for requirements to emerge in a PRL.

The benefits of PRL are:

  1. The project level PRL shows the relationship of user needs (features) to requirements: What capabilities we need and why?
  2. The project PRL becomes a checklist in a validation process: Does the system meet my needs?
  3. Within the agency, PRL Forms a basis for potential interoperability with another implementation-regional context.
  4. PRL connects all concerned parties on the project's objectives, and help eliminate "guess-work."
  5. Overall reduces risk of failure to conform to the standard.

The information on conformance column is drawn from the project needs and if support is needed or not. Sometimes we need to add additional comments in the last column to ensure project special needs.

Users may modify entries in rows to suit local project needs, but columns should not be changed to remain consistent with SEP. Please see the Extended Text Description below.

(Extended Text Description: The table in this figure contains the following content:

UN ID User Need RQ. ID Requirement Conformance Project Requirement Additional Project Requirements
2.1 Provide Live Data 3.2.1 Provide Live Data M YES  
2.2 Provide Logged Data 3.2.2 Provide Off-Line Logged Data M YES  
2.3 Retrieve Identity 3.3.1 General Configuration M YES NTCIP 1207 v02 Annex B, CG B.3
2.9 Configure RMC unit 3.3.1 Configuration of Device M YES NTCIP 1201, CL 2.2
2.4 Fixed Rate 3.3.2 Metered Lane M YES NTCIP 1207-3.3
2.5 Queue Override 3.3.3 Queue Override O YES/NO Not widely used
2.N Block Objects 3.N   O Yes/No Undecided, per agency need

The content in the Conformance and Project Requirement columns is highlighted in a red outline from UN ID 2.1 to 2.4. Under the table is the text: Users may modify entries in rows to suit local project needs, but columns should not be changed to remain consistent with SEP.)

Here is how users can complete a project level PRL: With the following three simple steps, users may modify entries in rows to suit local project needs, but columns should not be changed to remain consistent with SEP. At the time of project specification preparation, the user can also refer to the ESS standard PRL for guidance.

Step 1: Enter requirements in columns 1 and 3 (used in the PRL) .

Step 2: Enter pertinent generic dialog in column 2 (F.3.1/F3.2 for Monitoring- Retrieval, and, F3.3. Control) .

Step 3: Enter associated objects from the Annex B in column 4.

Step 4: A local project related requirements, if any, should be inserted if necessary in the last column.

A project level Requirements Traceability Matrix (RTM) associates each requirement with a standardized dialog and the associated objects. The audience for RTM is implementers (vendors and central system developers) and conformance testers. Additionally, other interested parties might use RTM to determine how particular functions are to be implemented using the standardized dialogs, interfaces, and object definitions.

To conform to a requirement, an RMC system shall implement all objects traced from that requirement.

Req.lD Dialog (From ESS Annex F) Requirement [Section 3 from a Specification) Object C (Section 3from NTCIP 1207 v02) Additional Requirements/Objects
3.2.1 F.3.1 Provide Live Data   NTCIP 1204 V03 Annex F
3.2.2 F.3.1 Provide Off-Li ne Legged Data   NTCIP 1204 V03 Annex F
3.3.1 F.3.1 General Configuration    
3.3.1 F.3.1 Configuration of DEvict    
3.3.2   Metered Lane    
3.3.3   Queue Override    

In SEP-based standards such as ESS and DMS, RTM is strictly a standard-driven tool. It has been made "ready" for users by SEP standards such as ESS and DMS. Conformance requirements for any object is determined by the use of the RTM provided in SEP standards. To support any defined requirement, an implementation shall support all objects (design) to which the requirement traces in the RTM. In this module, we have adopted SEP format for RTM and in the above example, users are guided by the following simple steps:

Step 1 Requirements: enter in column 1 and 3. Step 2 Generic Dialog: enter in column 2.

Step 3 Objects: using Annex B, enter associated objects or, in some cases, user maps requirement directly to pertinent objects (Sec.3) in column 4.

Example of Role of a Dialog, F3.1 (Figure 7 shown on next page)

RTM plays a key role in ensuring dialog, objects and requirements are working coherently to achieve intended objective, allow a management station to complete a communication action.

Example: Metered Lanes (Based on Annex A.2.2)

Figure 7: F.3.1 Generic Dialog Example: Example metered Lanes. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant notes: Figure 7: F.3.1 Generic Dialog Example: Example metered Lanes. A graphic is shown to convey a dialog-F3.1 Generic SNMP Get message-interface. On the left Management station is show with a sketch of a person. On the left is an RMC unit controller. Get message originates from the Management Station with an arrow pointing to the RMC unit. A separate Get response originates from the RMC unit with an arrow pointing to Management Station. This is a dialog.)

Figure 7: F.3.1 Generic Dialog Example

The benefits of RTM are the following:

  1. RTM shows the relationship of requirements to the specific design items of the interface (dialogs and data objects) (see Figure 7 above).
  2. RTM encourages system acceptance: "Did they build the RMC system correctly?"/"Does my interface deliver the desired functionality?"
  3. Requirements are traced to dialogs and then to objects. This order is critical to meeting interoperability needs; a great benefit to designers.
  4. Testing RMC functions becomes easier for system acceptance; a testing plan will test this dialog for message completion.

7. References

  1. NTCIP 1201 v03 Global Objects,
  2. NTCIP 1207 v02 RMC Units,
  3. NTCIP 9001: Information Report- NTCIP Guide v04,
  4. A202: Identifying and Writing User Needs When ITS Standards Do Not Have SEP Content, training.aspx
  5. Kansas City SCOUT-Video on Ramp Metering (4 min.)
  6. Ramp Management and Control 2006, FHWA, mgmt handbook/manual/manual/pdf/rm han dbook.pdf
  7. Freeway Management and Operations Handbook, Updated in 2006, FHWA mgmt handbook/report info.htm
  8. Developing an Area-Wide System for Coordinated Ramp Meter Control, Y. Wang et el. University of Washington, 2008,
  9. Blumentritt, C.W., et al. "Guidelines for Selection of Ramp Control Systems, NCHRP Report 232" National Research Council, Transportation Research Board, Washington, DC, May 1981.
  10. McDermott, J.M., S.J. Kolenko, and R.J. Wojcik. Chicago Area Expressway Surveillance and Control: Final Report, Report Number FHWA-IL-ES-27. Illinois Department of Transportation, Oak Park, IL, 1979.

8. Study Questions

  1. Which of the following is a well-formed requirement?
    1. TMC shall be allowed to retrieve the plan from the RMC unit
    2. TMC needs to retrieve information from the RMC unit
    3. TMC needs to monitor metering operations
    4. The RMC unit shall comply with all requests
  2. Which SNMP interface will modify the current metering plan?
    1. GET Interface
    2. GetNext Interface
    3. SET Interface
  3. Which of the following ensures precise objects necessary to fulfill a requirement?
    1. The Project PRL table
    2. The Project RTM table
    3. Generic SNMP Get Interface
    4. Major Desired Capability (MDC)
  4. Which of the following answers is FALSE?
    1. An extended requirement is non-conformant to the standard
    2. An extended requirement will break the interoperability
    3. Only SNMP interface is permitted in the RMC system
    4. The project RTM may contain private object
  5. Which of the following statements is FALSE?
    1. The Project RTM specifies the objects and dialogs
    2. RMC unit can be readily replaced with a traffic controller
    3. RMC unit can also control an advanced warning sign
    4. SNMP must be specified to conform to NTCIP 1207 standard v02