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. https://www.ite.org/tripgenappendices/
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)?
- Internet Protocol
- Center-to-Center Profile (NTCIP 2306)
- Transit Communications Interface Profiles (TCIP)
- Traffic Management Data Dictionary (TMDD)
2. What skill is not needed to use the C2C RI?
- Windows networking
- Windows anti-virus
- HTTP
- WSDL
3. Which test document requires information from sources beyond the C2C RI?
- Test plan
- Test design specification
- Test cases
- Test procedures
4. Which is the best way to describe the C2C RI generated test reports?
- The conformance report provides the final assessment whether the implementation conforms to the communications interface
- When combined together, the various reports produce all of the elements of IEEE 829 test documentation
- The reports assist the tester in identifying issues for further analysis
- 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.
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.
3) Remember: 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.
5) Example: 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.
