Module 53 - T251

T251: Center-to-Center (C2C) Reference Implementation (RI) Introduction

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.)

 

T251: Center-to-Center (C2C) Reference Implementation (Rl) Introduction

 

Table of Contents

1. Module Description - 2

2. Introduction/Purpose - 2

3. Outline for a Level Test Plan - 3

4. Samples/Examples - 4

4.1. Test Case Specification - 4

4.2. Example Test Procedure - 5

5. Reference to Other Standards - 9

6. Glossary - 9

7. Study Questions - 11

8. Icon Guide - 12

 

1. Module Description

The Center-to-Center (C2C) Reference Implementation (RI) is a tool developed under contract to the USDOT that mimics an operational traffic management system. It supports all features defined in the traffic management data dictionary (TMDD) v3.03 standard and serves as a useful development and testing tool to verify that the system being tested is able to interoperate with a known reference.

Data exchanges among multiple management centers are termed "Center-to-Center" (C2C) communications. The mechanisms used to enable these exchanges are defined in NTCIP 2306 v1.69. Traffic management centers (TMCs) often rely upon this standard to exchange data with other centers (external centers) to enable ITS services. TMDD v3.03 is an information level standard jointly developed and published by ITE and AASHTO, which defines the data that TMCs might need to exchange with external centers.

Previously developed Modules, A321 and A321b, covered the details of TMDD user needs and requirements respectively and T321 covered testing of deployments based on the TMDD standard. The purpose of this module is to make users aware of the capabilities of the C2C Reference Implementation (RI) and its ability to verify that C2C interfaces conform to the NTCIP 2306 v1.69 and TMDD v3.03c standards and are compliant to Section 1201 of SAFETEA-LU. The Module will teach students why the C2C RI is important, how it makes testing easier and how it reduces cost.

This module will also explain how individuals can obtain a copy of the C2C RI. The main focus of this module will be to introduce personnel to the Center-to-Center (C2C) Reference Implementation (RI) so that they are aware of its existence, purpose, capabilities, and value to deployment projects; it will also alert participants to the limitations of the software and the resources required for its proper use. The module will explain how the tool can be used to verify that a deployed system conforms to the standardized exchanges.

 

2. Introduction/Purpose

This module will be placed in the context of the SE process as well in the acquisition curriculum path. The complete series of ITS Standards Training Modules for acquisition of a C2C system is as follows: I101, A101, A102, A103, A201, A321a, A321b, T101, T201, T202, T203, T321, T251, and T351. Participants that plan on being a hands-on user of the C2C RI are encouraged to follow this course with T351; otherwise those in a more managerial role may choose to make this their final module in the series.

At the conclusion of this course, participants will be able to:

1. Recognize the purpose of the C2C Reference Implementation (RI)

  • Understand C2C communications
  • Appreciate the Purpose of the RI
  • Explain the communication stack supported by the C2C RI
  • Know where to obtain the RI software

2. Acknowledge key capabilities and limitations of the C2C RI

  • What functions can be tested
  • What functions are currently unavailable (planned?)
  • Operational environment required (Does it require an external PC, etc.)
  • Skills required to use

3. Follow a defined process for producing test documentation that relies upon the C2C RI

  • Explain how IEEE 829 test documentation relates to C2C environment
  • Understand the contents of a C2C test plan
  • Show partial example for a C2C test design specification
  • Show example test case for C2C
  • Show sample test procedure for C2C using RI

4. Recognize the type of results a tester might produce after using the C2C RI

  • Understand that hands-on guidance is provided in T351
  • Explain what should be included in results
  • Explain how to interpret test results
  • Recognize limitations of test results

 

3. Outline for a Level Test Plan

IEEE 829-2008 recommends the following outline for a Level Test Plan:

1. Introduction

1.1. Document identifier

1.2. Scope

1.3. References

1.4. Level in the overall sequence

1.5. Test classes and overall test conditions

2. Details for this level of test plan

2.1. Test items and their identifiers

2.2. Test Traceability Matrix

2.3. Features to be tested

2.4. Features not to be tested

2.5. Approach

2.6. Item pass/fail criteria

2.7. Suspension criteria and resumption requirements

2.8. Test deliverables

3. Test management

3.1. Planned activities and tasks; test progression

3.2. Environment/infrastructure

3.3. Responsibilities and authority

3.4. Interfaces among the parties involved

3.5. Resources and their allocation

3.6. Training

3.7. Schedules, estimates, and costs

3.8. Risk(s) and contingency(s)

4. General

4.1. Quality assurance procedures

4.2. Metrics

4.3. Test coverage

4.4. Glossary

4.5. Document change procedures and history

Definitions for each of these sections are provided in IEEE 829-2008.

 

4. Samples/Examples 4.1. Test Case Specification

The following sub clauses provide a complete example of a TMDD test case specification as used by the C2C RI.

4.1.1. Test Case Specification Identifier

Identifier Description
TCS-1-dlCenterActiveVerificationRequest-OC-Valid This test case is used to verify the SUTs support of the dlCenterActiveVerificationRequest dialog as an OC using the variable values specified by the Test Plan.

This test case supports verification of requirements related to user need 2.3.1.1 [Verify Connection Active]. This Test Case tests for a valid response result.

4.1.2. Test Items

  • 3.3.1.1.1
  • 3.3.1.1.5
  • 3.3.1.1.5.1
  • 3.3.1.1.5.2.1

4.1.3. Input Specifications

Inputs Procedures
Refer to the Test Case Data Variable Table in the appendix for the test case input parameters. TPS-1-dlCenterActiveVerificationRequest-OC

4.1.4. Output Specifications

Outputs Procedures
Each input execution shall generate an RI Test Result Status of Passed or Failed associated with the matching expected result shown in the Test Case Data Variable Table in the appendix.  

4.1.5. Environmental Needs

Hardware
See C2C RI SRS

Software
See C2C RI SRS

Other
None

4.1.6. Special Procedural Requirements

None

4.1.7. Intercase Dependencies

None

4.2. Example Test Procedure

The following sub clauses provide a complete example of a TMDD test procedure as used by the C2C RI.

Test Procedure: TPS-2-dlCenterActiveVerificationRequest-OC Need 2 Support for Request-Response (using dlCenterActiveVerificationRequest) for a SUT in OC Mode
Description: This test procedure is called by a test case and is used to verify the SUTs support of the dlCenterActiveVerificationRequest dialog as an OC using variables provided by the calling test case.

This procedure supports verification of requirements related to user need 2.3.1.2 [Support for Request-Response] and is used for both valid and invalid test cases.
Requirement(s): 3.3.1.1.2 3.4.2
Variable(s): ApplicationLayerStandard [String]
TMDD_N1R1_Send_Center_Active_Verification_Upon_Request_Parameter [Integer]
TMDD_N1R8_Restrictions___Center_Active_Supported [Boolean]
TMDD_N1R14_Restrictions___Error_Report_Supported [Boolean]
RequestMessage [String]
ErrorResponseExpected [Boolean]
ErrorTypeExpected [String]
CONTENTVERIFIED [Boolean]
Pass/Fail Criteria: The SUT shall pass every verification step included within the Test Procedure in order to pass the Test Procedure.

If a verification step fails, then test execution will proceed at the next subsequent Post Condition step, if present. Otherwise, test execution will proceed to the final Exit step.
Test Step Number Test Procedure Results
1 CONFIGURE: Determine the Application Layer Standard that will be used for this test. RECORD this information as: ApplicationLayerStandard NA
2 CONFIGURE: Determine the dialog performance requirement for Send Center Active Verification Upon Request (NRTM 3.3.1.1.1). RECORD this value as: TMDD_N1R1_Send_Center_Active_Verification_Upon_Request_Para meter NA
3 CONFIGURE: Determine whether Restrictions - Center Active is required by the specification. (NRTM 3.3.1.1.5.2.1). RECORD this information as: TMDD_N1R8_Restrictions___Center_Active_Supported NA
4 CONFIGURE: Determine whether Restrictions - Error Report is required by the specification. (NRTM 3.3.1.4.1.2.1). RECORD this information as: TMDD_N1R14_Restrictions___Error_Report_Supported NA
5 CONFIGURE: Define the message that will be sent to the SUT. RECORD this information as: RequestMessage NA
6 CONFIGURE: Determine whether an error response message is expected for this test. RECORD this information as: ErrorResponseExpected NA
7 CONFIGURE: IF ErrorResponseExpected is true, determine the expected error code response for this test. RECORD this information as: ErrorTypeExpected NA
8 REQUEST-RESPONSE-EC with the following parameters:
DIALOG=dlCenterActiveVerificationRequest
RESPONSETIMEREQUIRED=TMDD_N1R1_Send_Center_Active_Verification_Upon_Request_Parameter
REQUESTMESSAGE = RequestMessage
ERRORRESPONSEEXPECTED = ErrorResponseExpected
ERRORTYPEEXPECTED = ErrorTypeExpected
PASS/FAIL (3.3.1.1.2, 3.4.2)
9 IF ErrorResponseExpected is not equal to TRUE THEN CONTINUE, OTHERWISE skip the following substeps. Note: If a verification step fails, then test execution will proceed at the next subsequent Post Condition step, if present. Otherwise, test execution will proceed to the final Exit step. NA
9.1 VERIFY that a centerActiveVerificationResponseMsg message was received. PASS/FAIL
9.2 VERIFY that an organization-information data frame exists within message centerActiveVerificationResponseMsg. PASS/FAIL
9.3 VERIFY that a center-id data element exists within message centerActiveVerificationResponseMsg. PASS/FAIL
9.4 VERIFY that a center-name data element exists within message centerActiveVerificationResponseMsg. PASS/FAIL
9.5 IF TMDD_N1R8_Restrictions___Center_Active_Supported is equal to TRUE THEN CONTINUE; OTHERWISE skip the following substeps. NA
9.5.1 VERIFY that a restrictions data frame exists within message centerActiveVerificationResponseMsg. PASS/FAIL
9.6 VERIFY that the values within the RESPONSE message are correct per the TMDD standard and known operational conditions. PASS/FAIL
10 IF ErrorResponseExpected is equal to TRUE THEN CONTINUE, OTHERWISE skip the following substeps. If a verification step fails, then test execution will proceed at the next subsequent Post Condition step, if present. Otherwise, test execution will proceed to the final Exit step. NA
10.1 VERIFY that an errorReportMsg message was received. PASS/FAIL
10.2 VERIFY that an organization-information data frame exists within message errorReportMsg. PASS/FAIL
10.3 VERIFY that an organization-requesting data frame exists within message errorReportMsg. PASS/FAIL
10.4 VERIFY that an error-code data element exists within message errorReportMsg. PASS/FAIL
10.5 VERIFY that an error-text data element exists within message errorReportMsg. PASS/FAIL
10.6 VERIFY that data element error-code is set to ErrorResponseTypeExpected. PASS/FAIL
10.7 IF TMDD_N1R14_Restrictions___Error_Report_Supported is equal to TRUE THEN CONTINUE; OTHERWISE skip the following substeps. NA
10.7.1 VERIFY that a restrictions data frame exists within message errorReportMsg. PASS/FAIL
11 EXIT NA
Test Procedure Results
Tested By: Date Tested: PASS/FAIL
Test Procedure Notes:

 

5. Reference to Other Standards

ITE TMDD v03.03c - Traffic Management Data Dictionary, July 16, 2014. http://www.ite.org/standards/tmdd/

NTCIP 2306 v01.69 - National Transportation Communications for ITS Protocol: Application Profile for XML Message Encoding and Transport in ITS Center-to-Center Communications, December 2008. http://ntcip.org/library/standards/default.asp?documents=yes&qreport=no&standard=2306

 

6. Glossary

To include additional descriptions/acronyms used primarily in the module.

Term Definition
AASHTO American Association of State Highway and Transportation Officials.
Agency Specification A document that has been prepared by an agency to define requirements for a subject item or process when procured by the agency.
C2C Center-to-Center.
Compliance A condition that exists when an item meets all of the requirements of an agency specification.
Concept of Operations A document that describes the purpose for a system project, including a description of the current and proposed system, as well as key user needs that the new system is required to address.
Conformance A condition that exists when an item meets all of the mandatory requirements as defined by a standard. It can be measured on the standard as a whole, which means that it meets all mandatory (and applicable conditional) requirements of the standard or on a feature level (i.e., it conforms to feature X as defined in section X.X.X), which means that it meets all mandatory (and applicable conditional) requirements of the feature.
DXFS Data eXchange File Specification.
EC External Center.
FTP File Transfer Protocol.
HTTP HyperText Transfer Protocol.
HTTPS HyperText Transfer Protocol Secure.
IEEE Institute of Electrical and Electronic Engineers.
IP Internet Protocol.
ITE Institute of Transportation Engineers.
ITS Intelligent Transportation System.
JRE Java standard edition Runtime Environment.
NRTM Needs to Requirements Traceability Matrix.
NTCIP National Transportation Communications for ITS Protocol.
OC Owner Center.
PC Personal Computer.
PCB Professional Capacity Building.
RI Reference Implementation.
RTCM Requirements to Test Case traceability Matrix.
RTM Requirements Traceability Matrix.
SAFETEA-LU Safe, Accountable, Flexible, Efficient Transportation Efficiency Act: A Legacy for Users.
SE Systems Engineering.
SOAP Simple Object Access Protocol.
SRS System Requirements Specification.
SUT System Under Test.
TCIP Transit Communication Interface Protocols.
TCP Transport Control Protocol.
TCS Test Case Specification.
Test Case A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. (B) Documentation specifying inputs, predicted results, and a set of execution conditions for a test item. [IEEE 829-2008]
Test Design Documentation specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests (commonly including the organization of the tests into groups). [IEEE 829-2008]
Test Plan (A) A document describing the scope, approach, resources, and schedule of intended test activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. (B) A document that describes the technical and management approach to be followed for testing a system or component. Typical contents identify the items to be tested, tasks to be performed, responsibilities, schedules, and required resources for the testing activity. [IEEE 829-2008]
Test Procedure (A) Detailed instructions for the setup, execution, and evaluation of results for a given test case. (B) A document containing a set of associated instructions as in (A). (C) Documentation that specifies a sequence of actions for the execution of a test. [IEEE 829-2008]
TMC Traffic Management Center.
TMDD Traffic Management Data Dictionary.
TPS Test Procedure Specification.
TRANSCOM Transportation Operations Coordinating Committee.
UN User Need.
USDOT United States of America Department of Transportation.
WSDL Web Service Definition Language.
XML eXtensible Markup Language.
XSD XML Schema Definition.

 

7. Study Questions

To include the quiz/poll questions and answer choices as presented in the PowerPoint slide to allow students to either follow along with the recording or refer to the quiz at a later date.

1. Which standard is not supported by the C2C RI off-the-shelf (without customization)?

  1. Internet Protocol
  2. Center-to-Center Profile (NTCIP 2306)
  3. Transit Communications Interface Profiles (TCIP)
  4. Traffic Management Data Dictionary (TMDD)

2. What skill is not needed to use the C2C RI?

  1. Windows networking
  2. Windows anti-virus
  3. HTTP
  4. WSDL

3. Which test document requires information from sources beyond the C2C RI?

  1. Test plan
  2. Test design specification
  3. Test cases
  4. Test procedures

4. Which is the best way to describe the C2C RI generated test reports?

  1. The conformance report provides the final assessment whether the implementation conforms to the communications interface
  2. When combined together, the various reports produce all of the elements of IEEE 829 test documentation
  3. The reports assist the tester in identifying issues for further analysis
  4. The reports fail to provide the information that they were intended to provide

 

8. Icon Guide

The following icons are used throughout the module to visually indicate the corresponding learning concept listed below, and/or to highlight a specific point in the training material.

1) Background information: General knowledge that is available elsewhere and is outside the module being presented. This will be used primarily in the beginning of the slide set when reviewing information readers are expected to already know.

Background information icon indicates general knowledge that is available elsewhere and is outside the module being presented.

2) Tools/Applications: An industry-specific item a person would use to accomplish a specific task, and application of that tool to fit the need.

Tools/Applications icon. An industry-specific item a person would use to accomplish a specific task, and applying that tool to fit your need.

3) Remember: Used when referencing something already discussed in the module that is necessary to recount.

Remember icon. Used when referencing something already discussed in the module that is necessary to recount.

4) Refer to Student Supplement: Items or information that are further explained/detailed in the Student Supplement.

Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.

5) Example: Can be real-world (case study), hypothetical, a sample of a table, etc.

Example icon. Can be real-world (case study), hypothetical, a sample of a table, etc.

6) Checklist: Used to indicate a process that is being laid out sequentially.

Checklist icon used to indicate a process that is being laid out sequentially.