Module 45 - A309b
A309b: Understanding Requirements for Ramp Meter Control (RMC) Units Based on NTCIP 1207 Standard v02
HTML of the PowerPoint Presentation
(Note: This document has been converted from a PowerPoint presentation 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.)
Slide 1:
(Extended Text Description: Welcome - Graphic image of introductory slide. A large dark blue rectangle with a wide, light grid pattern at the top half and bands of dark and lighter blue bands below. There is a white square ITS logo box with words "Standards ITS Training" in green and blue on the middle left side. The word "Welcome" in white is to the right of the logo. Under the logo box is the logo for the U.S. Department of Transpotation, Office of the Assistant Secretary for Research and Technology.)
Slide 2:
(Extended Text Description: This slide, entitled "Welcome" has a photo of Ken Leonard, Director, ITS Joint Program Office, on the left hand side, with his email address, Ken.Leonard@dot.gov. A screen capture snapshot of the home webpage is found on the right hand side - for illustration only - from August 2014. Below this image is a link to the current website: www.its.dot.gov/pcb - this screen capture snapshot shows an example from the Office of the Assistant Secretary for Research and Development - Intelligent Transportation Systems Joint Program Office - ITS Professional Capacity Building Program/Advanced ITS Education. Below the main site banner, it shows the main navigation menu with the following items: About, ITS Training, Knowledge Exchange, Technology Transfer, ITS in Academics, and Media Library. Below the main navigation menu, the page shows various content of the website, including a graphic image of professionals seated in a room during a training program. A text overlay has the text Welcome to ITS Professional Capacity Building. Additional content on the page includes a box entitled What's New and a section labeled Free Training. Again, this image serves for illustration only. The current website link is: https://www.its.dot.gov/pcb.)
Slide 3:
Slide 4:
A309b:
Understanding Requirements for Ramp Meter Control
(RMC) Units Based on NTCIP 1207 Standard v02
Slide 5:
Instructor
Raman K. Patel, Ph.D., P.E. President
RK Patel Associates, Inc. New York City, NY, USA
Slide 6:
Target Audience
- Traffic management and engineering staff
- Traffic Management Center/operations staff
- Freeway and traffic signal maintenance staff
- System developers
- Private and public sectors users including manufacturers
Slide 7:
Recommended Prerequisite(s)
- I101: Using ITS Standards: An Overview
- A101: Introduction to Acquiring Standards-based ITS Systems
- A102: Introduction to User Needs Identification
- A201: Details On Acquiring Standards-based ITS Systems
- A202: Identifying and Writing User Needs When ITS Standards Do Not Have SE Content
- A103: Introduction to ITS Standards Requirements Development
- A203: Writing Requirements When ITS Standards Do Not Have SE Content
- C101: Introduction to the Communications Protocols and Their Uses in ITS Applications
- A309a: Understanding User Needs for Ramp Meter Control (RMC) Units Based on NTCIP 1207 Standard v02
Slide 8:
Curriculum Path
(Extended Text Description: Curriculum Path: A graphical illustration indicating the sequence of training modules that lead up to and follow each course. Each modules is represented by a box with the name of the module in it and an arrow showing the logical flow of the modules and the current module highlighted. This slide focuses on the modules that lead up to the current course. The module titles are as follows:
- I101 Using ITS Standards: An Overview
- A101 Introduction to Acquiring Standards-based ITS Systems
- A102 Introduction to User Needs Identification
- A201 Details on Acquiring Standards-based ITS Systems
- A202 Identifying and Writing User Needs When ITS Standards Do Not Have SEP Content
- A103 Introduction to ITS Standards Requirements Development
- A203 Writing Requirements When ITS Standards Do Not Have SEP Content
- C101 Intro. to Comm. Protocols and Their Uses in ITS Applications
- A309a Understanding User Needs for Ramp Meter Control (RMC) Units Based on NTCIP 1207 Standard v02
- A309b Understanding Requirements for Ramp Meter Control (RMC) Units Based on NTCIP 1207 Standard v02
)
Slide 9:
abbrs Used
- ASN.1 Abstract Syntax Notation 1 Language (ASN.1)
- ATDM Active Traffic Demand Management
- CGs Conformance Groups
- ICM Integrated Corridor Management
- MDC Major Desired Capability
- >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
- Vphpl Vehicle per hour per lane
Slide 10:
Learning Objectives
- Develop requirements using the NTCIP 1207 v02 RMC Units Standard
- Establish Interoperability and vendor-independence
- Prepare traceability tables for RMC
- Incorporate requirements not supported by standardized objects
- Develop an RMC specification
Slide 11:
Learning Objective #1: Develop Requirements Using the NTCIP 1207 v02 RMC Unit Standard
- Review the structure of the NTCIP 1207 Standard v02
-
Identify requirements from various sources
- Based on the user needs developed in Module A309a
- Derived from the Annex-A NTCIP 1207 Standard v02
- RMC units configuration-control and monitoring perspectives
- Review criteria for well-formed requirements
- Develop sample requirements
Slide 12:
Learning Objective #1
Review the Structure of the NTCIP 1207
Standard v02
The Standard has Four Sections and Five Annexes:
Section 1 General: Scope, references, terms, definitions.
Section 2 Standards-Based RMC
System: References to various standards.
The Ramp Meter Control (RMC) unit consists of the field controller, its suite of sensors (detectors), and its warning signs and signals.
The RMC System produces and implements a metering rate (release rate), e.g. 500 vehicles per hour per lane (vphpl).
(Extended Text Description: Review the Structure of the NTCIP 1207 Standard v02 Unit: The slide has two graphic images. The top layout shows 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 inward arrows going toward the freeway mainline, labeled a queue detector, demand detector, and passage detector being the last one after the STOP line. The second layout at the bottom is a photo of a ramp being metered, with vehicles passing at the ramp signal and merging onto the freeway segment.)
Slide 13:
Learning Objective #1
Section 3: Management Information Base
(MIB) Provides Design Data for RMC System
(Extended Text Description: This slide contains the following text:
-
MIB provides structured design objects for RMC functionality:
- Mainline Detectors
- Metered Lane
- Metering Plan-Levels-Table
- Sign Control
- Input-Output
- Scheduling
- Block Objects.
The bulleted list has an arrow leading from the word "structured" to a box outlined in red, which contains the text:
3.4.1.5.9 Requested Rate
rmcRequestRate OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Indicates the metering rate that is requested if the rmcRequestAction-object
has a value of 'fixedRate'. This value shall be expressed in 1-vph increments.
<Unit> vehicles per hour
<Object Identifier>
1.3.6.1.4.1.1206.4.2.2.3.1.8.1.9"
::={ rmcMeterStatEntry 9 }
)
Slide 14:
Learning Objective #1
New Additional Information
Section 4: RMC Block Object Definitions (Supports Efficiency)
(Extended Text Description: This slide contains the text:
Annex A - RMC Unit Operations Description
Metering Plan
The RMC unit shall have a Metering Plan Table containing all of the Metering Plans…….a Maximum Number of Metering Plans parameter to indicate the number of metering plans (4-100) ……… a Number of Metering Plans parameter to indicate how many metering plans are currently supported……… a Metering Plan Number parameter identifying which plan it represents……..
A box on the left contains the text:
Each Metering Level shall consist of:
Occupancy Threshold
(0, 5.0-30.0 percent in 0.1-percent increments)
Flow Rate Threshold
(0, 1000-3600 vph in 1-vph increments)
Speed Threshold
(0, 15-100 km/h in 1-km/h increments)
This box has an arrow to the right with the text:
Metering Rate
(0, 120-1800 vph in 1-vph increments)
)
Slide 15:
Learning Objective #1
Additional New Information (Annex B)
(Later, we will discuss how to use this information)
(Extended Text Description: B.2 RMC UNIT REQUIREMENTS
The Conformance Group definitions for RMC units are defined in this clause. A RMC unit has multiple functions; thus, Conformance Groups are defined for each function
The following table lists functional requirements for an RMC unit, and asks if the listed features have been implemented.
| 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 Based Queue 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.5 | 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 Output | NTCIP 1207- 3.7 | O | Yes /No | |
| - Dependency Group Output | NTCIP 1207- 3.7 | O | Yes/No | |
| B.11 | Block Object Conformance Group | NTCIP 1207- 3.8 | O | Yes/No |
| B.12 | Configuration Conformance Group | NTCIP 1201 -2.2 | M | Yes |
Note: Line B.3 has a set of red arrows pointing to Object 1, Object 2, Object n. Line B.5 has a set of blue arrows pointing to Object x, Object y, Object z.)
Annex C: Object tree diagram; Annex D: Future test procedures; Annex E: Documentation of revisions
Slide 16:
Learning Objective #1
What is NOT offered by the NTCIP 1207 Standard v02?
(Extended Text Description: Author's relevant notes: What is not offered by the NTCIP 1207 v02 Standard? Diagram of the slanted part of a Vee diagram on the left that outlines ConOps, Requirements, and Design. Two separate arrows attached to user needs and requirements to indicate that the user needs and requirements sections are not offered by this standard.)
Slide 17:
Learning Objective #1
Traceability Tools NOT Offered by the NTCIP 1207 Standard v02
(Extended Text Description: Author's relevant notes: Traceability Tools Not Offered by the NTCIP v02 Standard: A graphic with three circles with separate in and out arrows are shown on the left side to indicate relationships among user needs in top circle, requirements in the middle circle, and design in the lowermost circle. This graphic illustrates the point that PRL and RTM tools are not offered by the standard.)
PRL: Protocol Requirements List RTM: Requirements Traceability Matrix
Slide 18:
Learning Objective #1
Definition of a Requirement
A description of a condition or capability to which a system is obligated to conform; either derived directly from user needs, or stated in a contract, standard, specification, or other imposed document. A desired feature, property, or behavior of a system.
-NTCIP 1203 v03 DMS Standard
Slide 19:
Learning Objective #1
User Needs' Relationship to Requirements
(Extended Text Description: Author's relevant notes: User Needs' Relationship to Requirements: Arrows are used to show relationships. In the top graphic, there is an arrow from user need pointing to Requirement 1; in the middle, two separate arrows point to Requirement 1 and Requirement 2; in the last, bottom graphic, there is an arrow from "Many User Needs" pointing to Requirement 1.)
Slide 20:
Learning Objective #1
Illustration of the Relationship
User Need: TMC needs to control RMC functions remotely
Requirement: "The RMC unit shall allow the management station to request implementation of an updated metering plan
using communications command source...
(Extended Text Description: Author's relevant notes: Illustration of Relationship: At the bottom left, traffic controller is shown as a TARGET with a signal head; on the right side, a TMC workstation is shown as an ACTOR. Both are connected with an arrow from TMC to the controller-ACTION.)
Slide 21:
Learning Objective #1
RMC Requirements are to be Identified from Various Sources
(Extended Text Description: Author's relevant notes: RMC Requirements are to be Identified from Various sources: Four title pages of standard cover pages are shown: SEP-Based Standard, followed by PCB A309a Module, NTCIP 1207 v02 standard Annex A, and NTCIP 1207 standard Annex B.)
Slide 22:
Learning Objective #1
RMC Requirements Must be Well-Formed Using a Criteria
Provide a Structure to a Requirement:
(Extended Text Description: This slide contains the following text:
- Actor identifies who requests the action.
- Action identifies what is to happen.
- Target identifies who or what receives the action.
- Constraint identifies how to measure the success or failure of the requirement.
- Localization identifies the circumstances under which the requirement applies.
The bottom two items, 4 and 5, have a bracket to the right which points to the following text: Not all
requirements will have both.)
Slide 23:
Learning Objective #1
Review Criteria for Well-Formed Requirements
Applying Characteristics:
- Necessary: Must be useful and traceable to needs.
- Concise: Minimal, understandable, and expressed as a shall statement.
- Attainable: Realistic to achieve within available resources and time.
- Standalone: Stated completely in one place.
- Consistent: Does not contradict itself, nor any other stated requirement.
- Unambiguous: Susceptible to only one interpretation.
- Verifiable: Requirement can be verified through inspection, analysis, demonstration, or test.
Slide 24:
Learning Objective #1
Applying the Criteria to Types of RMC Requirements
(Extended Text Description: There are three boxes on the left with text, more text in the center, then three boxes on the right. The first box on the left contains the text "Architectural
Requirements" with "Supports general communication capabilities," then a box to the right with "SNMP Interface." The second box on the left contains the text "Data Exchange Requirements" with "Supports
device feature-functions", then box to the right with "Traffic responsive." The third box on the left contains the text "Supplemental Requirements" with "Not covered above
Special project need," wthen box to the right with "Local".)
Slide 25:
Learning Objective #1
Organizing Requirements for a Project Specification
Sample Format to Follow in this Module
Section 3 RMC Unit Requirements
3.1 General Background Information
3.2 Architectural Requirements
3.2.1 Provide Live Data
3.2.2 Provide Off-Line Logged Data
3.3 Data Exchange Requirements
3.3.1 Managing Configuration
3.3.2 RMC Unit Control
3.3.3 Monitoring Status
3.4 Supplemental Requirements
3.4.1 Traffic Controller Firmware (if applicable)
See Student Supplement for Details
Slide 26:
Learning Objective #1
Identifying Requirements Based on User Needs Developed in Module A309a
(Extended Text Description: Identifying Requirements Based on User Needs Developed in Module A309a: An arrow from the User Needs table points to a text box on the bottom right. There is a box with the following text:
UN 2.1: Provide Live Data Exchange (Clause F. 1.1.1)
A management station (central software) has a need to conduct a live data exchange with the RMC unit to retrieve any set of data at any time.
UN 2.2: Provide Logged Data Exchange (Clause F.1.1.3)
A management station has a need to retrieve logged-data at a later time from the RMC unit in a situation when communication is lost or not-always on communications (e.g. dial-up links).
UN 2.3: Provide Capability to Retrieve RMC Identity (Clause F.1.2.1)
A TMC Operator desires to inquire basic information about the RMC unit such as its location, make, model and version of the device components.
To the right is a box that says "See list of RMC user needs in Student Supplement".
A blue arrow leads to to a box that says "We need to translate UNs into requirements" in the lower right hand corner.)
Slide 27:
Learning Objective #1
3.2 Architectural Requirements
3.2.1 Provide Live Data
3.2.1.1 Retrieve Data
The RMC unit (TARGET) shall allow the management station (ACTOR) to retrieve data (ACTION) from the RMC unit.
3.2.1.2 Deliver Data
The RMC unit shall allow the management station to deliver data (e.g. configuration data; commands.)
(Extended Text Description: Author's relevant notes: Architectural Requirements: At the bottom of the slide, two boxes are connected with a two-headed arrow. The text box on the left is "Management Station" and the one on right is "RMC Unit". This conveys that the RMC unit shall allow the management station to deliver data.)
Provide Live Data: Monitor-Control RMC Unit System when connected.
Slide 28:
Learning Objective #1
3.2 Architectural Requirements (cont.)
3.2.2 Provide Off-Line Logged Data
3.2.2.3 Retrieve Logged Data Collected During Off-Line Situations
The RMC unit shall allow the management station to retrieve one or more available logged data from the event log gathered during certain off-line conditions such as loss of communications and a dial-up link.
(Extended Text Description: Architectural Requirements (cont.): In the middle of the slide, two boxes are connected with a two-headed arrow. The text box on the left is "Management Station" and one on right is "RMC Unit". This conveys that the RMC unit shall allow the management station to retrieve data.)
3.2.2.4 Clear Log
The RMC unit shall allow the management station to clear any or all log entries of a given event class.
Slide 29:
Learning Objective #1
3.3 Data Exchange Requirements Background
Module A309a identified the data exchange user needs to:
- Manage the RMC unit configuration (e.g., set metering table)
- Control the RMC unit functions (e.g., operations)
- Monitor the Status of the RMC unit (e.g., detector data)
(Extended Text Description: Data Exchange Requirements: A photo of the TMC is shown on the left side of the slide; RMC Unit photo is on the right, with an arrow connecting both with text above the arrow stating "Center-to-Field Communications".)
Slide 30:
Learning Objective #1
Data Exchange Requirement (Configuration)
(Extended Text Description: This slide contains the following text: Configuration Management - The management station [ACTOR] shall be able to retrieve information [ACTION] about the configuration of the RMC unit [TARGET].
✓Necessary
✓Attainable
✓Standalone
✓Verifiable
✓ …….
)
Slide 31:
Learning Objective #1
Data Exchange Requirement (Monitor and Control)
(Extended Text Description: This slide contains the following text: Data Exchange Requirement (Monitor and Control) - The central system [ACTOR] shall be able to make a request to the RMC unit [TARGET] with the communications command source (priority 2) to exchange data [ACTIONS] to inquire about the current configuration.
✓Necessary
✓Attainable
✓Standalone
✓Verifiable
✓ …….
)
Slide 32:
Slide 33:
Learning Objective #1
Which of the following is a well-formed requirement?
Answer Choices
- TMC shall be allowed to retrieve the plan from the RMC unit
- TMC needs to retrieve information from the RMC unit
- TMC needs to monitor metering operations
- The RMC unit shall comply with all requests
Slide 34:
Learning Objective #1
Review of Answers
a) TMC shall be allowed to retrieve the plan from the RMC unit
Correct! The requirement statement meets the criteria— Actor/Action/Target; standalone...necessary....
b) TMC needs to retrieve information from the RMC unit
Incorrect. This is a user need, not a requirement.
c) TMC needs to monitor metering operations
Incorrect.
This is also a user need, not a requirement.
d) The RMC unit shall comply with all requests
Incorrect. This statement is not well-formed as it does not include an actor and action, and is NOT a standalone.
Slide 35:
Summary of Learning Objective #1
Develop Requirements Using the NTCIP 1207 v02 RMC Unit Standard
- Reviewed the structure of the standard
- Learned how to identify types of RMC requirements from various sources including user needs and Annex A and B
- Discussed criteria for writing well-formed requirements
- Developed sample requirements using the criteria
Slide 36:
Learning Objective #2: Establish Interoperability and Vendor-Independence
- Understand SNMP Interface and Dialogs
-
Understand NTCIP Objects:
- OID (Object Identifier)
- Value
- varBinding, PDU (Protocol Data unit)
-
Develop Sample Dialogs:
- F.3.1 Get
- F.3.2 GetNext
- F.3.3 Set
Slide 37:
Learning Objective #2
Achieving Interoperability with SNMP Interface Parts of SNMP Interface
(Extended Text Description: Author's relevant notes: Achieving Interoperability with SNMP Interface: Has the following bulleted items: SNMP (Discussed in Module C101), Messages (Data Content for Actions by RMC unit), and Dialogs (Conversations). A text box is shown on the bottom left, with the text "SNMP Manager" and one on the right, marked as "SNMP Agent" with a two-way arrow connecting them.)
Slide 38:
Learning Objective #2
Types of SNMP Messages
(Extended Text Description: Types of SNMP Messages: A table presents four types of messages in the first column, which are then connected with an outbound arrow to a text box that states "Each message contains a PDU". The table contains the following content:
| Message | Operation | Action |
|---|---|---|
| 1 GetRequest | READ | Retrieves Data from a Device |
| 2 GetNextRequest | READ | Retrieves More Data |
| 3 SetRequest | WRITE | Controls-Modifies a Function |
| 4 GetResponse | READ | Reply-Status |
)
Slide 39:
Learning Objective #2
Object's Structure Provides Content for a PDU
(Extended Text Description: This slide contains the followig text:
varBinding={OID, value}
3.4.1.1 Maximum Number of Metered Lanes
rmcMaxNumMeteredLanes OBJECT-TYPE
SYNTAX INTEGER (1..255) [VALUE] [For example, 3 metered lanes]
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Indicates the maximum number of metered lanes that can be stored in the
Metered Lane Configuration Table, and, by association, in all other metered
lane tables.
<Unit> number
<Object Identifier> 1.3.6.1.4.1.1206.4.2.2.3.1.1 [OID]
REFERENCE
"See Clause A.2.2"
::={ rmcMeterMain 1 }
The REFERENCE line has a blue arrow leading to the following text:
A.2.2Metered Lanes
The RMC unit shall have a maximum number of metered lanes parameter to indicate the number supported by the RMC unit.)
Slide 40:
Learning Objective #2
Developing Sample SNMP Dialogs
Generic SNMP Dialogs are Adopted from NTCIP 1204 v03 ESS (Annex, Section 3.5)
(Extended Text Description: The slide contains the following text:
- F.3.1 SNMP Get Interface Retrieves Data from a Device
- F.3.2 SNMP Get-Next interface Retrieves More Data
- F.3.3 SNMP Set Interface Sends Data to the Device
At the bottom of the slide, two boxes are connected with a two-headed arrow. The text box on left is "Management Station" and the one on right is "RMC Unit". Two separate arrows connect them to convey request message and response message.)
Slide 41:
Learning Objective #2
Example: Metered Lanes (Based on Annex A.2.2)
Management station retrieves metered lane data from the RMC unit with a GetRequest (Get), and receives a GetResponse indicating number of lanes currently metered. (1, 2 or 3 lanes metered)
(Extended Text Description: Author's relevant notes: 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. The Get message originates from the management station with an arrow pointing to the RMC unit. A separate Get response originates from RMC unit with an arrow pointing to Management Station. This is a dialog.)
[F3.2 GetNext Dialog follows this sequence also, but for more data to be retrieved from table content.]
Slide 42:
Learning Objective #2
Example: Metered Lanes (Based on Annex A.7.1)
Management station requests the RMC unit with a SetRequest (Set) to selected metering plan, numbered as XX, and receives a confirmed action reply though GetResponse with a metering plan number being implemented
(Extended Text Description: Example of Metered Lane: Same as above in slide 41, except Set Generic SNMP interface is shown.)
Slide 43:
Slide 44:
Learning Objective #2
(Extended Text Description: Answer choice: At the top left a TMC photo is shown and on the top right a photo of a RMC unit is shown. A two headed arrow connects them. Which SNMP interface will modify the current metering plan?)
Which SNMP interface will modify the current metering plan?
Answer Choices
- GET interface
- GETNext Interface
- SET Interface
Slide 45:
Learning Objective #2
Review of Answers
a) GET Interface
Incorrect. Get operation ONLY retrieves (READ) the metering plan from the RMC unit.
b) GetNext Interface
Incorrect. GetNext Interface retrieves multiple data from the RMC unit.
c) SET Interface
Correct! ONLY SET operation modifies (WRITE) the current metering plan in effect.
Slide 46:
Summary of Learning Objective #2
Establish Interoperability and Vendor-Independence
- Discussed SNMP interface and dialogs for communications
- Reviewed NTCIP object structure and message content, varBinding value, OID pair, and PDU
- Developed sample Get, GetNext, and Set dialogs
Slide 47:
Learning Objective #3: Prepare Traceability
Tables for RMC
-
Protocol Requirements List (PRL)
- User needs to requirements traceability
- Benefits of PRL
-
Requirements Traceability Matrix (RTM)
- Requirements to design traceability within the context of a dialog
- Benefits of RTM
Slide 48:
Learning Objective #3
What is Traceability and How is it Achieved?
(Extended Text Description: The slide contains the following text: Traceability is the ability to follow or study the logical progression among the need, requirements, and design details in a step-by-step fashion." (NTCIP 1204 v03 ESS)
The are two boxes below with the following text: On the left, User Needs to Requirements with PRL, and Requirements to Design with RTM
Below those boxes is another bos in red with the text "PRL and RTM for RMC System are NOT available" And below that box is a box in yellow with the textL "Users develop project-level PRL and RTM
by adopting formats from the NTCIP 1204 v03 ESS Standard.".)
Slide 49:
Learning Objective #3
Protocol Requirements List (PRL)
(Format adopted from SEP ESS standard)
(Extended Text Description: This slide contains a table with the follow content. The text "A table that maps the user needs to the requirements…" has an arrow pointing to the first row of the table.
| UN ID | User Need | FR. ID | Functional Requirement | Conformance | Project Requirement | Additional Project Requirements |
|---|---|---|---|---|---|---|
| 2.1 | RMC Configuration | 3.1 | RMC Configuration | M | YES | |
| 2.N |
The text "Designed to help specify what you want the interface to do" points to the the bottom right of the table.
…must be part of agency's RMC unit specification.
.)
Slide 50:
Learning Objective #3
Steps for Developing a PRL for RMC System
- Step 1: Develop user needs as per Module A309a's discussion and assign them under Section 2 clause; e.g., 2.1 to 2.N and enter them in column 1 and 2.
- Step 2: Develop requirements as per this module's (A309b) discussion and assign them under Section 3; e.g., 3.1 to 3.N and enter them in column 3 and 4.
- Step 3: Select [Mandatory-M or Optional-O] and [YES/NO] in column 5 and 6 for conformance.
- Step 4: Insert project specific requirements if necessary
(Extended Text Description: This slide contains the following tabe. The first two columns are outlined in red, the next two in black, the next two in blue and the final colulmn in blue.
| UN ID | User Need | FR. ID | Functional Requirement | Conformance | Project Requirement | Additional Project Requirements |
|---|---|---|---|---|---|---|
| 2.1 | RMC Configuration | 3.1 | RMC Configuration | M | YES | |
| O | YES/NO | |||||
| 2.N | 3. N |
)
Slide 51:
Learning Objective #3
Organize User Needs and Requirements for Project Level PRL
(Extended Text Description: This slide contains the following text. On the left is a box outlined in red with the text:
UN 2.1 Provide Live Data
UN 2.2 Provide Logged Data
UN 2.3 Provide Capability to Retrieve RMC Identity
UN 2.4 Fixed Rate
UN 2.5 Queue Override
UN 2.6 Traffic Responsive
UN 2.7 Signal Service
UN 2.8 Transitioning
UN 2.9 Configure a RMC Unit
UN 2.10 Command Source Priority
UN 2.11 Command Source Parameters
UN 2.12 Metering Action
On the right is box outlined in blue with the text:
3.2 Architectural Requirements
3.2.1 Provide Live Data
3.2.2 Provide Off-Line Logged Data
3.3 Data Exchange Requirements
3.3.1 Configuration
3.3.2 RMC Unit Control
3.3.3 Monitoring Status
3.4 Supplemental Requirements
3.4.1 Traffic Controller Firmware (if applicable)
Under the boxes is a smaller box with arrows leading from the left box to the right box with the text "A Project Level PRL Mapping".)
Slide 52:
Learning Objective #3
Example of a Project PRL for a RMC System
(Extended Text Description: Users may modify entries in rows to suit local project needs, but columns should not be changed to remain consistent with SEP. M-Mandatory, O-Optional. The table on this slide 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 higlighted 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.)
Slide 53:
Learning Objective #3
Benefits of the Project PRL
-
For Users
- The project PRL shows relationship of user needs (features) to requirements (what capabilities we need and why)
- The project PRL becomes a checklist in a validation process: "Does the system meet my needs?
- Within the agency, PRL Forms a basis for potential interoperability with another implementation-regional context
-
For Users, Developers, and Vendors
- PRL connects all concerned parties on the project's objectives, and help eliminate "guess-work"
- Overall reduces risk of failure to conform to the standard
Slide 54:
Learning Objective #3
Requirements to Traceability Matrix (RTM)
(Format adopted from SEP ESS standard, including Dialogs)
(Extended Text Description: The slide contains the following content:
A box on the top left contains the text "RTM associates each requirement" with the word "to" in between another box on the right with the text "first to a standardizeddialog and then to associated objects (design)." The second box has arrowds that point to the second and fourth columns in the table below:
| Req.ID | Dialog (From ESS Annex F) | Requirement (Section 3 from a Specification) | Object ID (Section 3 from NTCIP 1207 v02) | Additional Requirements/Objects |
|---|---|---|---|---|
| 3.1 | F.3.1 | 3.2.1 | NTCIP 1207 v02 clause | |
| F.3.2 | ||||
| 4.1 | F.3.3 |
.)
Slide 55:
Learning Objective #3
Steps for Developing a RTM for RMC System
Step 1 Requirements: enter in column 1, 3
Step 2 Generic Dialog: enter in column 2
Step 3 Objects: using Annex B enter in column 4 associated objects or in some cases user maps requirement directly to pertinent objects (Sec.3)
Step 4 Project Specific Requirements: enter in column 5
| Req.ID | Dialog (From ESS Annex F) | Requirement (Section 3 from a Specification) | Object ID (Section 3 from NTCIP 1207 v02) | Additional Requirements/Objects |
|---|---|---|---|---|
| 3.1 | F.3.1 | 3.2.1 | NTCIP 1207 v02 clause | |
| F.3.2 | ||||
| 4.1 | F.3.3 |
Slide 56:
Learning Objective #3
Example of a Project RTM for RMC System
| Req.ID | Dialog (From ESS Annex F) | Requirement (Section 3 from a Specification) | Object ID (Section 3 from NTCIP 1207 v02) | Additional Requirements/Objects |
|---|---|---|---|---|
| 3.2.1 | F.3.1 | Provide Live Data | NTCIP 1204 v03 ESS Annex F | |
| 3.2.2 | F.3.1 | Provide Off-Line Logged Data | NTCIP 1204 v03 ESS Annex F | |
| 3.3.1 | F.3.1 | General Configuration | ||
| 3.3.1 | F.3.1 | Configuration of Device | ||
| 3.3.2 | Metered Lane | |||
| 3.3.3 | Queue Override | Some agency may have override queue policy | ||
| 3.3.X | F.3.3 | Retrieve Current Time | NTCIP 1201 v03 sec.2.4.1 | GlobalTime |
Slide 57:
Learning Objective #3
Benefits of the Project RTM
-
For Users
- RTM shows relationship of requirements to the specific design items of the interface (dialogs and data objects)
- Helps in system acceptance: "Did they build the RMC system right?" /"Does my interface deliver the desired functionality?"
-
For Agencies, System Developers, Vendors, and Testers
- Requirements are traced to dialogs and then to objects. This order is key to interoperability needs, a great benefit to designers
- Testing of RMC functions becomes easier for system acceptance
Slide 58:
Slide 59:
Learning Objective #3
Which of the following ensures precise objects necessary to fulfill a requirement?
Answer Choices
- The Project PRL table
- The Project RTM table
- Generic SNMP Get Interface
- Major Desired Capability (MDC)
Slide 60:
Learning Objective #3
Review of Answers
a) The Project PRL table
Incorrect. PRL traces user needs to requirements, not objects.
b) The Project RTM table
Correct! RTM identifies objects necessary to fulfill a requirement.
c) Generic SNMP Get Interface
Incorrect. Generic SNMP Get interface does not contain objects.
d) Major Desired Capability (MDC)
Incorrect. MDC is part of a user need.
Slide 61:
Summary of Learning Objective #3
Understand Traceability
-
Discussed how to develop a project PRL to trace user needs to RMC unit requirements
- Reviewed benefits of PRL
-
Discussed how to develop a project RTM to trace requirements to dialogs and objects (design) within the context of a dialog
- Reviewed benefits of RTM
Slide 62:
Learning Objective #4:
Incorporate Requirements Not Supported by Standardized Objects
- Context and conditions for extending the standard
- Example of extending the standard
Slide 63:
Learning Objective #4
Context and Conditions for Extending the Standard
-
Context of Missing Requirements:
- Current standard (v02) provides for common requirements anticipated by the NTCIP effort for ramp metering
- However, there may be some features and requirements specific to certain application, e.g., corridor-wide metering
-
Conditions for Extension:
- Adding new objects to RMC MIB is possible if it is documented and made available to anyone (agency, other vendors, developers)
- RMC design objects are based on ASN.1 format and must be complied with for the structure
- Private objects impact interoperability/interchangeability
Slide 64:
Learning Objective #4
Technical Conditions for Extension
- When a new requirement associates a design object, behavior of the device may be affected
- ASN.1 based objects must support READ operation for retrieval and WRITE operation for control functions without restrictions
- Syntax must be a non-negative integer/bytes
- Object must have an OID within the current MIB node
- Only SNMP interface will be allowed (as per NTCIP 1103 rules)
Slide 65:
Learning Objective #4
Extensions - Drawbacks
-
Interoperability may be compromised:
- Other management stations that do not support the new objects will be unable to exercise the new capabilities
- If the agency is not consistent on defining how the requirement is fulfilled, interoperability cannot be achieved without custom integration for each deployment
Slide 66:
Learning Objective #4
Example of Extending the Standard
(Extended Text Description: Relevant Author's Notes for this slide: Example of Extending the Standard: Graph at the bottom right of the slide showing density and flow rate. The example conveys that RMC shall support density-based metering level. This standard does not support this, so the requirement is labeled as Extended.)
Slide 67:
Slide 68:
Learning Objective #4
Which of the following answers is FALSE?
Answer Choices
- An extended requirement is non-conformant to the standard
- An extended requirement will break the interoperability
- Only SNMP interface is permitted in the RMC system
- The project RTM may contain private objects
Slide 69:
Learning Objective #4
Review of Answers
a) An extended requirement is non-conformant to the standard
Incorrect. The statement is true.
b) An extended requirement will break the interoperability
Incorrect. The statement is true.
c) Only SNMP interface is permitted in the RMC system
Incorrect. The statement is true.
d) The project RTM may contain private objects
Correct! The statement is FALSE. Project RTM does not reference a private object for an extended requirement.
Slide 70:
Summary of Learning Objective #4
Incorporate Requirements Not Supported by Standardized Objects
- Reviewed context and conditions for extending the RMC unit standard, including technical conditions
- Discussed an example of extending the standard
Slide 71:
Learning Objective #5: Develop RMC Specification
- How the RMC unit specification fits in the specification package
- Checklist of key elements that must be present in a specification
Slide 72:
Learning Objective #5
(Extended Text Description: The slide contains the following text: Plans-Specifications and Estimates (PS&E)
1 - General contractual requirements during system development, testing, deployment, integration, and operations/maintenance.
Hardware specification; Functional requirements; Performance requirements; Electrical-Mechanical-Environmental requirements
2 - Software specification; Functional requirements; Performance requirements
3 - RMC Specification
Communication Interface Specifications
Architectural Requirements
Data Exchange Requirements
Project PRL and RTM.)
Slide 73:
Learning Objective #5
RMC Specification
-
Minimum required sections:
- Communication Interface Specifications
- Architectural Requirements
- Data Exchange Requirements
- Project PRL and RTM
-
Checklist of key elements that must be present:
- Address Interoperability Issues
- Integrate Project PRL and RTM in the Specification
- Coordination Requirements
- Controller Type/Mainline Detector Station
Slide 74:
Learning Objective #5
1. Addressing Interoperability Issues
Agencies Seeking Interoperability (Specifications) Must Select the Same User Needs/Requirements; Objects-Messages-PDUs and Dialogs
(Extended Text Description: This slide contains the following content: On the left are three black boxes with text, the first which reads, "MIB-Objects", the second which reads, "GetRequest, GetNextRequest, SetRequest, GetResponse" and the third which reads, "PDU, varBindList". The black boxes point to the right to another box which reads, "Dialogs, F.3.1, F3.2, F3.3". This box points to another box to the right which reads, "RMC Unit". Above "RMC Unit" is the text, "Dialogs are adopted from SEP standards". )
Slide 75:
Learning Objective #5
2. Integrating PRL in the Project Specification
- A project PRL defines data exchange requirements for the communications interface
- Underlying communications standards need to also be specified (protocols at various levels)
- Reference to interface standards must be specific to the version and publication date
- Include the completed PRL with object value ranges for all the objects to clarify parameters
Slide 76:
Learning Objective #5
3. Coordination of Requirements
- The requirements for the communications interface must be consistent with the RMC unit system specification
- Include statement to use standardized design solutions as specified in the project RTM
- Include a completed copy of the PRL plus the RTM as a source for the design of the system and the test plan
Slide 77:
Learning Objective #5
4. Controller Types/Mainline Detectors Station
- Go over hardware/firmware details, versions, upgrades, etc.
- Please consult PCB modules on ASC and ATC for technical details
- Need for mainline detectors station for traffic responsive metering
- Need for ramp detectors (demand-passage, queue, etc.) for metering capability
Slide 78:
Slide 79:
Learning Objective #5
Which of the following statements is FALSE?
Answer Choices
- The Project RTM specifies the objects and dialogs
- RMC unit can be readily replaced with a traffic controller
- RMC unit can also control an advanced warning sign
- SNMP must be specified to conform to NTCIP 1207 standard v02
Slide 80:
Learning Objective #5
Review of Answers
a) The Project RTM specifies the objects and dialogs
Incorrect. The statement is true.
b) RMC unit can be readily replaced with a traffic controller
Correct! This is a FALSE statement. RMC is a special controller equipped for Ramp Operations.
c) RMC unit can also control an advanced warning sign
Incorrect. The statement is true. RMC unit has outputs that turn signs ON during ramp operation and turn OFF when no metering condition is in effect.
d) SNMP must be specified to conform to NTCIP 1207 standard v02
Incorrect. The statement is true.
Slide 81:
Summary of Learning Objective #5
Develop a RMC Unit System Specification
- Discussed how an RMC system specification fits in the overall project specification package
- Discussed a checklist of key elements for a specification
Slide 82:
What We Have Learned
- RMC unit standard does not provide requirements and users must identify and write them for project specification.
- A requirement is a translation of a user need and has a structure and certain characteristics.
- Requirements are linked to interoperability and vendor-independence.
Specifically at the project level:
- Each requirement is traced to at least one user need in the project PRL.
- Requirements should be traced to objects and dialogs in the project RTM.
Slide 83:
What We Have Learned (cont.)
- To retrieve data (reading operation) from the RMC unit device,SNMP GET interface is used.
- To control an RMC unit (writing operation), SNMP SET interface is used.
- To support the same features, the Management station and a RMC unit device must have the same MIB, and must use the same dialogs.
Slide 84:
Resources
- Student Supplement
-
NTCIP Documentation available at www.ntcip.org:
- NTCIP 1201 v03 Global Object Definitions
- NTCIP 1207 v02 RMC Units
- NTCIP 9001: Guide v04
-
PCB Training Modules Available at stds training.aspx
- Module A103: Introduction to ITS Standards Requirements Development) to review "well-formed" requirements:
- Module A203: Writing Requirements When ITS Standards Do Not Have SE Content
- Module A309a: Understanding Requirements for Ramp Meter Control (RMC) Units Based on NTCIP 1207 v02 Standard
Slide 85:
Next Course Module
T309:
Applying Your Test Plan to the Ramp Meter Control (RMC) Units Based on the NTCIP 1207 v02 Standard
- The key objective is to assists user agencies in their efforts to create test plans specific to their RMC needs based on the NTCIP 1207 Standard v02.
Slide 86:
