Module 41 - T203

T203: How to Develop Test Cases For an ITS Standards-Based Test Plan

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

T203: How to Develop Test Cases For an ITS Standards-Based Test Plan

Table of Contents

Introduction - 2

abbrs and Testing Documentation Terminology - 3

Process to Develop a Test Case - 7

Example Test Cases - 8

References - 29

Study Questions - 29

Module Description

This module is about preparing testing documentation with focus on Test Case Specification (TCS), a component of the overall testing documentation required by an ITS project specification. Previous modules have discussed How to Write a Test Plan (T201) and provided an Overview of Test Design Specifications, Test Cases, and Test Procedures (T202). This module will extend this discussion by providing participants with an in-depth overview of the general structure and parts of test case specifications (TCS). All modules are available at the PCB website (Ref 6). Students are advised to take module T202 to prepare for this module.

The module has two parts: The first part covers the general structure of the testing documentation and parts of a TCS with representative examples, how test cases fit into the testing process and their relationship to the test plan, test design specification, and test procedures (as defined in IEEE 829). This module will also show students how to develop test cases to verify requirements for standards that have been through the SEP (ESS) and contain test documentation, and those that do not have SEP (ASC). The second part covers how to develop a test case specification for specific project requirements, how to develop requirements to test case matrix, and how to handle errors and failures. Subsequent modules will define how to prepare test procedures and how to perform tests.

This student supplement covers both parts of the module on Test Case Development.

1. Introduction

Prior to deployment, all equipment and system interface that must conform to ITS standards should be tested according to well-defined test documentation that includes a test plan and complete definition of the test design, test cases, and test procedures. The subject of this module is Test Case, which identifies a particular requirement to be tested and shows how to include it in the TCS document. For example, an agency needs to monitor a DMS sign in the field and has set a requirement for that; a Test Case will ensure this by listing this requirement and specify how to test it in a real environment so that system interface can be verified. Specific benefits are listed below.

Benefits specific to test cases include:

2. abbrs and Test Documentation Terminology

ASN.1 - Abstract Syntax Notation 1

C2C - Center to Center (Information Exchange)

C2F - Center to Field (NTCIP Devices)

CCTV - Closed Circuit Television

DMS - Dynamic Message Sign

ESS - Environmental Sensor Station

MIB - Management Information Base

NRTM - Needs to Requirements Traceability Matrix

NTCIP - National Transportation Communications for ITS Protocol

PRL - Protocol Requirements List

PDU - Protocol Data Unit

RTM - Requirements Traceability Matrix

RTCTT - Requirements to Test Case Traceability Table

TMDD - Traffic Management Data Dictionary

TDS - Test Design Specification

TCS - Test Case Specification

SE - Systems Engineering

SEP - Systems Engineering Process

XML - Extensible Markup Language

Test Process: Consider Testing as an activity that is carried out with a series of steps in a life cycle of an ITS project. To ensure that the system interface delivers what the users have specified, a testing process is necessary to ensure outcomes. Such requirements are "communicated" in the testing documentation, beginning with a Test Plan (TCS is a component of the Test Plan). The purpose of software and software-based systems testing is:

Test Plan: A test plan provides a description of the overall approach to testing all of the requirements to be verified. The Test Plan outlines the scope, approach, resources, and schedule of testing activities. Breakdown of Key Point: This first key point describes a test plan - the master document that will include the test cases. Explaining this key point shows the hierarchical structure (test plan - test design specification - test case) that is required to develop a fully system-engineered test plan.

Test Design Specification (TDS): A test design breaks apart testing into smaller efforts and describes a test design specification - the specification that outlines the requirements to be tested and which test cases cover which requirements. Explaining this key point shows the hierarchical structure (test plan - test design specification - test case) that is required to develop a fully system-engineered test plan.

Test Case Specification (TCS): A test case identifies and specifies the inputs, outcomes, and conditions for execution of a test and included in a document called Test Case Specification (TCS) as part of an ITS project overall Test Plan. A test case specifies the inputs, outcomes, and conditions for execution of a test. It identifies a specific input and/or output that needs to be tested, and records the purpose of the test, a description of the test, the input and output test specification, the environmental needs, references the test procedure, and describes the results of the test.

The suggested outline for a TCS is shown below:

What does a Test Case verify?

Data Structure: What is being tested as per a defined Test Case centers around key parts of a dialog, the data structure-content, values and sequence, which affects:

Example of a Test Case:

The following ESS example shows content of a test case.

NTCIP 1204 v03.08 Page 154

Requirement Test Case
ID Title ID Title
3.5.1.1.2 Retrieve Compressed Station Metadata
    C.2.3.1.2 Retrieve Compressed Station Metadata
3.5.1.1.3 Configure ESS Manager
    C. 2.3.1.1 ESS Characteristics
3.5.1.2 ESS Status Monitoring Requirements
3.5.1.2.1 Retrieve ESS Door Status
    C.2.3.1.3 Retrieve ESS Door Status
3.5.1.2.2 Retrieve Battery Status
    C.2.3.1.4 Retrieve Battery Status

Test Procedure Specification (TPS): Defines the steps to execute a test. Multiple Test Cases may reference a single Test Procedure.

IEEE Std 829 Documentation Structure: Figure 1 lists the prescribed structure by the IEEE approach to preparing testing documentation.

Please see the Extended Text Description below.

(Extended Text Description:This slide shows a diagram with test documentation in a layered diagram.

Three boxes made of dashed lines run from top to bottom along the left side. The first box contains the text – Test Plan describes the overall approach to testing. The second box contains the text – Test Design Specification describes which requirements are to be tested and associated test cases. The third box contains the text – Text Case Specification identifies objectives and inputs, outcomes, and conditions for execution of a test. Each box points to its corresponding place on the diagram to the right. The layers from top to bottom are labeled: Test Plan, Test Design Specification, Test Case Specification, Test Procedure Specification, Test Execution, Test Reports. The Test Plan layer contains a large dashed rectangle surrounding four other rectangles. Each rectangle is labeled differently. They are, from left to right, Unit Test, Integration Test, System Acceptance Test, and Periodic Maintenance Test. The Test Design Specification Layer contains four boxes, each connecting to a corresponding box on the previous layer. They are labeled, from left to right, Test Design Unit Test, Test Design Integ. Test, Test Design Sys. Acceptance, and Test Design Periodic Mtce.
The Test Case Specification layer contains five boxes that are labelled Test Case 001, Test Case 002, Test Case 003, Test Case 004, and Test Case N. Each Test Case is connected to multiple boxes in the previous layer. Test Case 001 is connected to Test Design Unit Test and Test Design Integ. Test. Test Case 002 is connected to Test Design Unit Test, Test Design Integ Test, and Test Design Sys. Acceptance. Test Case 003 is connected to Test Design Integ Test and Test Design Sys. Acceptance. Test Case 004 is connected to Test Design Sys. Acceptance and Test Design Periodic Mtce. Test Case N is connected to Test Design Periodic Mtce. The Test Procedure Specification layer contains two rectangles containing the text Test Procedure 001 and Test Procedure 002. Test Procedure 001 links back to Test Cases 001 – 003. Test procedure 002 links back to Test Case 004 and N. The Text Execution layer has a single dashed oval labeled Test Plan Execution (Process) and Is linked back to both Test Procedures. The final layer is Test Reports and contains three text boxes. The top two are labeled Test Logs and Test Incident Reports and they connect back to Test Plan Execution. These boxes also lead down to the final box via arrows and this final box is labeled Test Plan Execution Summary Report.)

Figure 1: IEEE Std 829 Documentation Structure (Ref.1)

Test Reports: Generally, test reporting is covered by four document types: a) A test item transmittal report identifies the test items being transmitted for testing in the event that separate development and test groups are involved or in the event that a formal beginning of test execution is desired. b) A test log is used by the test team to record what occurred during test execution. c) A test incident report describes any event that occurs during the test execution which requires further investigation. d) A test summary report summarizes the testing activities associated with the execution of test plan specifications" [IEEE Std 829, p. iii]. The test summary report can summarize key results captured in the test logs and test incident reports.

Requirements: A requirement is a condition or capability needed by a user to solve a problem or achieve an objective [IEEE Std 1233, p. 3]. Definition of requirements for system software is one of the key activities of the systems engineering process. A set of requirements to describe the entire scope of the project shall be developed to precisely define what functions the software will perform, how well it must perform, and under what conditions this performance takes place. This portion of the development process identifies the system interface requirements that satisfy the expressed user needs.

RTM (Requirements Traceability Matrix): RTM is a project-specific (tailored) table that links each requirement to its standard design elements. Every project must have a RTM based on SEP style format such as one offered in C2F-ESS or DMS standards and NRTM in C2C-TMDD standard. RTM is the basis on which a system interface will be designed-built; therefore TCS refers to RTM for inputs/outputs.

NRTM (Needs to Requirements Traceability): for a C2C project, TMDD provides a NRTM which is tailored to a project. NRTM links user needs and requirements to prescribed data structures. TCS derives its inputs/outputs and dialogs from NRTM for a C2C testing.

PRL (Protocol Requirements List): A project-level table that traces a requirement to a user need for all NTCIP devices. SEP standards such as ESS and DMS do have PRL, however, CCTV and RMC do not and user must develop one for a project.

RTCTT (Requirements to Test Case Traceability Table): It will be used to verify that the software being implemented fulfills all of the system interface requirements. The following example shows details of a c2c project.

Requirement ID Requirement Title Test Case ID Test Case Title
REQ 10.1 Share Incident Description Upon Request TC001 IM Incident Description Request-Response Dialog Verification
REQ 10.2.1 Content! of tte Incident Information Request
REQ 10.3.1 Content: of an Incident Description Response

NTCIP Device standards with PRL, RTM and Test Plan: The following SEP-based NTCIP standards will help students to understand testing plan and related components (Ref.4). C2C standard TMDD provides NRTM for use in a test case (Ref.5).

Please see the Extended Text Description below.

(Extended Text Description: This page contains the covers for the NTCIP 1204 Environmental Sensor Status Standard, and NTCIP 1203 Dynamic Message Sign Standard. Both standards contain Annex C Test Procedures. For illustration only.)

3. Process to Develop a Test Case

This module introduces a process for developing a test case.

  1. Identify User Needs. In this step, the test case developer uses the NRTM or PRL, if one is available in the standard. The NRTM or PRL can be used to document project-relevant User Needs. If there is no NRTM or PRL in the standard, such as for the NTCIP 1205 CCTV standard, then the project's system engineer or test engineer will need to develop user needs for the project, and provide a trace to related requirements that fulfill the user needs. The course A317a: Understanding User Needs for CCTV Systems Based on NTCIP 1205 Standard & A317b: Understanding Requirements for CCTV Systems Based on NTCIP 1205 Standard provide an excellent tutorial on this process.
  2. Identify Requirements. In this step, the test case developer uses the NRTM or PRL (or similar) to identify mandatory requirements (based on the user needs from step 1), and those requirements that are optional for the standard, but mandatory for the project, plus any other requirements (optional, performance, etc.).
  3. Identify Design Content: Dialogs, Inputs, Outputs. The test engineer uses the RTM to trace from requirements to design, identifying relevant dialogs, inputs, and outputs. At this point the test engineer should have a list of data concepts (whether NTCIP objects or TMDD data elements, list of valid structure for the data, and valid dialogs (i.e., valid information exchange sequences). Center-to-field communications relies on a sequence of GET and SET operations, while center-to-center information exchanges are based on exchange of messages. At this point the test engineer may be able to fill in a portion of the test case: Identifier, Objective
  4. Document Value Constraints of Inputs/Outputs. In this step, the test engineer reads object and data element specifications to identify value type (INTEGER, TEXT STRING, ENUMERATED LIST), and value ranges. For NTCIP standards, this information is contained in the object definitions and encoded in the ASN.1 format. For center-to-center standards, such as the TMDD, the value constraints are contained in the data element definitions and encoded in both ASN.1 and XML formats. The valid value rules of data content are documented in either an input specification or output specification. Both input and output specifications follow the same format. The format used in the course is a carry-over from the previous version of IEEE Std 829-1998.
  5. Develop Test Case. As a final step, the test engineer completes the test case. The test case identifier and objective may have been entered early on (see step 3). The Inputs and Outcomes can be filled in, and reference the Input and Output Specifications, if applicable. Lastly, depending on test case-specific needs, the test engineer may fill in the environmental needs, special procedural requirements, and intercase dependencies.

4. Example Test Cases

Three case studies were developed in Part 2 using the steps described above. Due to the limited amount of information that can be shown in presentation format, this supplement contains all the information gathered by the author to develop the case studies.

4.1. CCTV Case Study

4.1.1. Identify User Needs

UN ID User Need Req ID Requirement
3.0 Remote Monitoring 3.3.3 Status condition within the device
3.3.3.2 Temperature
3.3.3.2 Pressure
3.3.3.2 Washer fluid
3.3.3.3 ID Generator

4.1.2. Identify Requirements

Req ID Requirement Dialog Object Reference and Title NTCIP 1205 Section 3
3.3.3 Status condition within the device D.1 Generic SNMP GET Interface
3.3.3.2 Temperature 3.7.5 alarmTemperatureCurrentValue
3.3.3.2 Pressure 3.7.6 alarmPressureHighLowThreshold
3.7.7 alarmPressureCurrentValue
3.3.3.2 Washer fluid 3.7.8 alarmWasherFluidHighLowThreshold
3.7.9 alarmWasherCurrentValue
3.3.3.3 ID Generator 3.11 cctv label Objects

4.1.3. Identify Design Content

3.7.5 Temperature Alarm Current Value Parameter
alarmTemparatureCurrentValue OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
ACCESS read-write
STATUS mandatory
DESCRIPTION "Identifies the current value for the temperature within the camera enclosure measured in degrees C."
::= {cctvAlarm 5}

3.7.6 Pressure Alarm High-Low Threshold Parameter
alarmPresureHighLowThreshold OBJ ECT-TYPE
SYNTAX OCTET STRING (SIZE(2))
ACCESS read-write
STATUS mandatory
DESCRIPTION "Identifies the high and low thresholds for the pressure alarm, as shown below;
Byte1 Low Threshold denotes the value of minimum pressure within the camera enclosure measured in psig,
Byte2 HighThreshold denotes the value of maximum pressure within the camera enclosure measured in psig."
::= {cctvAlarm 6}

3.7.7 Pressure Alarm Current Value Parameter
alarmPresureCurrentValue OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
ACCESS read-write
STATUS mandatory
DESCRIPTION "Identifies the current value for the pressure within the camera enclosure measured in psig."
::= {cctvAlarm 7}

3.7.8 Washer Fluid Alarm High-Low Threshold Parameter
alarmWasherFluidHighLowThreshold OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(2))
ACCESS read-write
STATUS mandatory
DESCRIPTION "Identifies the high and low thresholds for the washer fluid alarm, as shown below;
Byte1 Low Threshold denotes the percentage of minimum filled capacity between zero (0) and 100 percent,
Byte2 HighThreshold denotes the percentage of maximum filled capacity between zero (0) and 100 percent."
::= {cctvAlarm 8}

3.7.9 Washer Fluid Alarm Current Value Parameter
alarmWasherFluidCurrentValue OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
ACCESS read-write
STATUS mandatory
DESCRIPTION "Identifies the current value for the washer fluid level measured as the amount of filled capacity between zero (0) and 100 percent."
::= {cctvAlarm 9}

4.1.4. Document Value Constraints for Inputs and Outputs

Test Case Output Specification
ID: TCOS001 Title: Status Condition within the Device
Data Concept ID Data Concept Name (Variable) Data Concept Type Value Domain
3.7.5 alarmTemperatureCurrentValue Data Element OCTET STRING (SIZE(1)) - Range: 0 to 255.
3.7.6 alarmPressureHighLowThreshold Data Element OCTET STRING (SIZE(2)) - Range: 0 to 255 each byte. Note: B yte1 Low Threshold denotes the value of minimum pressure within the camera enclosure measured in psig, Byte2 High Threshold denotes the value of maximum pressure within the camera enclosure measured in psig
3.7.7 alarmPressureCurrentValue Data Element OCTET STRING (SIZE(1)) - Range: 0 to 255
3.7.8 alarmWasherFluidHighLowThreshold Data Element OCTET STRING (SIZE(2)) - Range: 0 to 100 each byte. Note: Byte1 Low Threshold denotes the percentage of minimum filled capacity between zero (0) and 100 percent, Byte2 HighThreshold denotes the percentage of maximum filled capacity between zero (0) and 100 percent.
3.7.9 alarmWasherCurrentValue Data Element OCTET STRING (SIZE(1)) - Range: 0 to 100
3.11 cctv label Objects Data Element etc. 3.11 contains numerous object definition entries.

4.1.5. Develop Test Case

Test Case
ID: TC001 Title: Request Status Condition within the Device Dialog Verification (Positive Test Case)
Objective: To verify system interface implements (positive test case) requirements for a sequence of OBJECT requests for:
  • 3.7.5 alarmTemperatureCurrentValue
  • 3.7.6 alarmPressureHighLowThreshold
  • 3.7.7 alarmPressureCurrentValue
  • 3.7.8 alarmWasherFluidHighLowThreshold
  • 3.7.9 alarmWasherCurrentValue
  • 3.11 cctv label Objects
The test case verifies that the data content of the OBJECTs requested are correct. No data inputs are required. An output specification is provided showing valid value constraints per the NTCIP 1205 v01 object definitions.
Inputs: No data inputs are required.
Outcome(s): All data are returned and verified as correct per the OBJECT constraints of NTCIP 1205 v01. See Test Case Output Specification TCOS001 - Status Condition within the Device (Positive Test Case)
Environmental Needs: No additional needs outside of those specified in the test procedure
Tester/Reviewer M.I.
Special Procedural Requirements: None
Intercase Dependencies: None

4.2. ESS Case Study

4.2.1. Identify User Needs

Excerpt from NTCIP 1204 v03 Section 3.3 Profile Requirements List (PRL)

User Need ID User Need FR ID Functional Requirement Conformance Project Requirement Additional Project Requirements
2.5.2.1.2 (Wind) Monitor Winds O.3 (1..*) Yes / No / NA  
    3.5.2.3.2.2 Retrieve Wind Data M Yes / NA  
    3.6.2 Required Number of Wind Sensors M Yes / NA The ESS shall support at least ___ wind sensors.

4.2.2. Identify Requirements

Excerpt from NTCIP 1204 v03 - ANNEX A Requirements Traceability Matrix

Req ID Dialog Requirement Object ID Add'l Requirements/Object
3.5.2.3.2.2 F.4.6 Retrieve Wind Data  
      5.6.8 windSensorTableNumSensors
      5.6.10.1 windSensorIndex
      5.6.10.4 windSensorAvgSpeed
      5.6.10.5 windSensorAvgDirection
      5.6.10.6 windSensorSpotSpeed
      5.6.10.7 windSensorSpotDirection
      5.6.10.8 windSensorGustSpeed
      5.6.10.9 windSensorGustDirection
      5.6.10.10 windSensorSituation

Excerpt from NTCIP 1204 v03 - ANNEX C Test Procedures

C.2.3.3.3 Retrieve Wind Data

Test Title: Retrieve Wind Data
Case: 3.3 Description: This test case verifies that the ESS allows a management station to determine current wind information.
  Variables: Required_Wind_Sensors PRL 3.6.2
  Pass/Fail Criteria: The device under test (DUT) shall pass every verification step included within the Test Case in order to pass the Test Case.

4.2.3. Identify Design Content

Excerpt from Object Definitions

5.6.8 Number of Wind Sensors
windSensorTableNumSensors OBJECT-TYPE
SYNTAX INTEGER (0..255)
ACCESS read-only
STATUS mandatory
DESCRIPTION "<Definition>Indicates the number of entries in the wind sensor table.
<Informative>This value may automatically change upon connecting or disconnecting a sensor; however, the table is still defined as a static table since the creation/deletion of rows is not managed through SNMP logic.
<SetConstraint>read-only
<DescriptiveName>WindSensorTable.numSensors:quantity
<Data Concept Type>Data Element
<Unit>count"
::= { essNtcipWind 7 }

5.6.10 Wind Sensor
windSensorEntry OBJECT-TYPE
SYNTAX WindSensorEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "<Definition>Parameters for specific wind sensor data fields.
<DescriptiveName>WindSensor
<Data Concept Type>Class"
INDEX { windSensorIndex }
::= { windSensorTable 1 }
WindSensorEntry ::= SEQUENCE {
windSensorIndex INTEGER,
windSensorHeight INTEGER,
windSensorLocation DisplayString,
windSensorAvgSpeed INTEGER,
windSensorAvgDirection INTEGER,
windSensorSpotSpeed INTEGER,
windSensorSpotDirection INTEGER,
windSensorGustSpeed INTEGER,
windSensorGustDirection INTEGER,
windSensorSituation INTEGER }

5.6.10.1 Wind Sensor Index
windSensorIndex OBJECT-TYPE
SYNTAX INTEGER (1..255)
ACCESS read-only
STATUS mandatory
DESCRIPTION "<Definition>Enumerated list of row entries that will provide wind sensor data. The first entry shall be that of the primary wind sensor.
<SetConstraint>read-only
<DescriptiveName>WindSensor.index:identifier
<Data Concept Type>Data Element"
::= { windSensorEntry 1 }

5.6.10.2 Wind Sensor Height
windSensorHeight OBJECT-TYPE
SYNTAX INTEGER (-1000..1001)
ACCESS read-only
STATUS mandatory
DESCRIPTION "<Definition>The height of the wind sensor with respect to the essReferenceHeight in meters.
<SetConstraint>read-only
<DescriptiveName>WindSensor.height:quantity
<Valid Value Rule>
The value of 1001 shall indicate a missing value.
<Data Concept Type>Data Element
<Unit>meters"
::= { windSensorEntry 2 }

5.6.10.3 Wind Sensor Location
windSensorLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION "<Definition>A textual string indicating the location of the wind sensor.
<SetConstraint>always
<DescriptiveName>WindSensor.location:text
<Data Concept Type>Data Element"
::= { windSensorEntry 3 }

5.6.10.4 Wind Sensor Average Speed
windSensorAvgSpeed OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION "<Definition>A two-minute average of the wind speed in tenths of meters per second as measured by the wind sensor. <SetConstraint>read-only
<DescriptiveName>WindSensor.avgSpeed:quantity <Valid Value Rule>
The value of 65535 shall indicate an error condition or missing value.
<Data Concept Type>Data Element
<Unit>tenths of meters per second"
REFERENCE "WMO Binary Code Form FM 94 BUFR Table B item 0 11 002." ::= { windSensorEntry 4 }

5.6.10.5 Wind Sensor Average Direction
windSensorAvgDirection OBJECT-TYPE
SYNTAX INTEGER (0..361)
ACCESS read-only
STATUS mandatory
DESCRIPTION "<Definition>A two minute mode (average) of the direction from which the wind is blowing measured clockwise in degrees from true north as measured by the wind sensor.
<SetConstraint>read-only
<DescriptiveName>WindSensor.avgDirection:quantity <Valid Value Rule>
The value of zero (0) shall indicate 'calm', when the associated speed is zero (0), or 'light and variable,' when the associated speed is greater than zero (0). Normal observations, as defined by the WMO, shall report a wind direction in the range of 1 to 360 with 90 meaning from the east and 360 meaning from the north. The value of 361 shall indicate an error condition and shall always be reported if the associated speed indicates error.
<Data Concept Type>Data Element
<Unit>degrees"
REFERENCE "WMO Code Form FM 94 BUFR Table B item 0 11 001."
::= { windSensorEntry 5 }

5.6.10.6 Wind Sensor Spot Speed
windSensorSpotSpeed OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION "<Definition>The wind speed in tenths of meters per second measured by the wind sensor. For mobile platforms, the wind speed shall be corrected for vehicle movement.
<SetConstraint>read-only
<DescriptiveName>WindSensor.spotSpeed:quantity
<Valid Value Rule>
The value of 65535 shall indicate an error condition or missing value.
<Data Concept Type>Data Element
<Unit>tenths of meters per second"
::= { windSensorEntry 6 }

5.6.10.7 Wind Sensor Spot Direction
windSensorSpotDirection OBJECT-TYPE
SYNTAX INTEGER (0..361)
ACCESS read-only
STATUS mandatory
DESCRIPTION "<Definition>The direction from which the wind is blowing measured in degrees clockwise from true North as measured by the wind sensor. For mobile platforms, the wind direction shall be corrected for vehicle movement.
<SetConstraint>read-only
<DescriptiveName>WindSensor.spotDirection:quantity
<Valid Value Rule>
The value of zero (0) shall indicate 'calm', when the associated speed is zero (0), or 'light and variable,' when the associated speed is greater than zero (0). Normal observations, as defined by the WMO, shall report a wind direction in the range of 1 to 360 with 90 meaning from the east and 360 meaning from the north. The value of 361 shall indicate an error condition and shall always be reported if the associated speed indicates error.
<Data Concept Type>Data Element
<Unit>degrees"
::= { windSensorEntry 7 }

5.6.10.8 Wind Sensor Gust Speed
windSensorGustSpeed OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION "<Definition>The maximum wind gust recorded by the wind sensor during the 10 minutes preceding the observation measured in tenths of meters per second.
<SetConstraint>read-only
<DescriptiveName>WindSensor.gustSpeed:quantity
<Valid Value Rule>
The value of 65535 shall indicate an error condition or missing value.
<Data Concept Type>Data Element
<Unit>tenths of meters per second"
REFERENCE "WMO Code Form FM 94 BUFR Table B item 0 11 041."
::= { windSensorEntry 8 }

5.6.10.9 Wind Sensor Gust Direction
windSensorGustDirection OBJECT-TYPE
SYNTAX INTEGER (0..361)
ACCESS read-only
STATUS mandatory
DESCRIPTION "<Definition>The direction of the maximum wind gust recorded during the 10 minutes preceding the observation measured in degrees clockwise from true North by the wind sensor.
<SetConstraint>read-only
<DescriptiveName>WindSensor.gustDirection:quantity
<Valid Value Rule>
The value of zero (0) shall indicate 'calm', when the associated speed is zero (0), or 'light and variable,' when the associated speed is greater than zero (0). Normal observations, as defined by the WMO, shall report a wind direction in the range of 1 to 360 with 90 meaning from the east and 360 meaning from the north. The value of 361 shall indicate an error condition and shall always be reported if the associated speed indicates error.
<Data Concept Type>Data Element
<Unit>degrees"
REFERENCE "WMO Code Form FM 94 BUFR Table B item 0 11 043."
::= { windSensorEntry 9 }

5.6.10.10 Wind Sensor Situation
windSensorSituation OBJECT-TYPE
SYNTAX INTEGER{
other (1),
unknown (2),
calm (3),
lightBreeze (4),
moderateBreeze (5),
strongBreeze (6),
gale (7),
moderateGale (8),
strongGale (9),
stormWinds (10),
hurricaneForceWinds (11),
gustyWinds (12)}
ACCESS read-only
STATUS mandatory
DESCRIPTION "<Definition>Describes the weather and travel situation in terms of wind from staffed stations only. Specific ranges for these values are defined in the Glossary of Meteorology.
<DescriptiveName>WindSensor.situation:code
<Valid Value Rule>
Range Meaning
other not defined within this standard, see manufacturers documentation
unknown Unknown conditions
calm Calm
lightBreeze Light breeze
moderateBreeze Moderate breeze
strongBreeze Strong breeze
gale Gale
moderateGale Moderate gale
strongGale Strong gale
stormWinds Storm winds
hurricaneForceWinds Hurricane force winds
gustyWinds defined by a peak and a lull of greater than 46.3 tenths of meters per second within a 2 minute period.
<Data Concept Type>Data Element"
::= { windSensorEntry 10 }

4.2.4. Document Value Constraints for Inputs and Outputs

Test Case Output Specification
ID: TCOS022 Title: Wind Data
Data Concept ID Data Concept Name (Variable) Data Concept Type Value Constraints
5.6.8 windSensorTableNumSensors Data Element INTEGER (0..255)
5.6.10.1 windSensorIndex Data Element INTEGER (1..255)
5.6.10.4 windSensorAvgSpeed Data Element INTEGER (0..65535) tenths of meters per second WMO Binary Code Form FM 94 BUFR Table B item 0 11 002
5.6.10.5 windSensorAvgDirection Data Element INTEGER (0..361) The value of zero (0) shall indicate 'calm', when the associated speed is zero (0), or 'light and variable,' when the associated speed is greater than zero (0). Normal observations, as defined by the WMO, shall report a wind direction in the range of 1 to 360 with 90 meaning from the east and 360 meaning from the north. The value of 361 shall indicate an error condition and shall always be reported if the associated speed indicates error.
5.6.10.6 windSensorSpotSpeed Data Element INTEGER (0..65535) tenths of meters per second The value of 65535 shall indicate an error condition or missing value.
5.6.10.7 windSensorSpotDirection Data Element INTEGER (0..361) The value of zero (0) shall indicate 'calm' , when the associated speed is zero (0), or 'light and variable,' when the associated speed is greater than zero (0). Normal observations, as defined by the WMO, shall report a wind direction in the range of 1 to 360 with 90 meaning from the east and 360 meaning from the north . The value of 361 shall indicate an error condition and shall always be reported if the associated speed indicates error.
5.6.10.8 windSensorGustSpeed Data Element INTEGER (0..65535), tenths of meters per second WMO Code Form FM 94 BUFR Table B item 0 11 041. The value of 65535 shall indicate an error condition or missing value.
5.6.10.9 windSensorGustDirection Data Element INTEGER (0..361) (See 5.6.10.7)
5.6.10.10 windSensorSituation Data Element INTEGER
other (1),
unknown (2),
calm (3),
lightBreeze (4),
moderateBreeze (5),
strongBreeze (6),
gale (7),
moderateGale (8),
strongGale (9),
stormWinds (10),
hurricaneForceWinds (11),
gustyWinds (12)
(See object definition for additional detail.)

4.2.5. Develop Test Case

Test Case
ID:TC001 Title: Retrieve Wind Data (Positive Test Case)
Objective: To verify system interface implements (positive test case) requirements for a sequence of OBJECT requests for:
  • 5.6.8 windSensorTableNumSensors
  • 5.6.10.1 windSensorIndex
  • 5.6.10.4 windSensorAvgSpeed
  • 5.6.10.5 windSensorAvgDirection
  • 5.6.10.6 windSensorSpotSpeed
  • 5.6.10.7 windSensorSpotDirection
  • 5.6.10.8 windSensorGustSpeed
  • 5.6.10.9 windSensorGustDirection
  • 5.6.10.10 windSensorSituation
The test case verifies that the data content of the OBJECTs requested are correct. No data inputs are required. An output specification is provided showing valid value constraints per the NTCIP 1204 v03 object definitions.
Inputs: No data inputs are required.
Outcome(s): All data are returned and verified as correct per the OBJECT constraints of NTCIP 1204 v03. See Test Case Output Specification TCOS022 - Wind Data.
Environmental Needs: No additional needs outside of those specified in the test procedure
Tester/Reviewer M.I.
Special Procedural Requirements: None
Intercase Dependencies: None

4.3. TMDD Case Study 4.3.1. Identify User Needs

UN ID User Need   Requirement ID Requirement Conformance Support Other Requirements
2.3.4.2.2 Need to Share Link State Optional [Yes] / No  
    Dialogs
      3.3.4.3.2.1 Send Link Status Information Upon Request M [Yes] The owner center shall respond within ___ (100ms - 1 hour; Default = 1 minute) after receiving the request. See Section 3.4.2.
      Publication and Subscription Dialog not shown.      
    Request Message
      3.3.4.1.1 Contents of the Traffic Network Information Request M [Yes]  
      3.3.4.1.1.1 Required Traffic Network Information Request Content M [Yes]  
      3.3.4.1.1.2.1 Authentication - Network (AuthNetwork) O [Yes] / No  
      3.3.4.1.1.2.1.1 Operator Identifier -Network AuthNetwork:O [Yes] / No / NA  
      3.3.4.3.2.4 Contents of the Link Status Request M [Yes]  
    Response Message
      3.3.4.3.2.5 Contents of the Link Status Information M [Yes]  
      3.3.4.3.2.5.1 Required Link Status Information Content M [Yes]  
      3.3.4.3.2.5.2.1 Restrictions - Link Status O [Yes] / No  
      3.3.4.3.2.5.2.2 Link Name - Link Status O [Yes] / No  
      3.3.4.3.2.5.2.3 Link Direction - Link Status O [Yes] / No  
      3.3.4.3.2.5.2.4 Lanes Open O [Yes] / No  
      3.3.4.3.2.5.2.19 Roadway Event Source O Yes / [No]  
      3.3.4.3.2.5.2.37 Event Description Time -Link Status O Yes / [No]  
      3.3.4.3.2.5.2.38 Link Status Date and Time Change Information O [Yes] / No  
    Error Report Message (detail not shown)

4.3.2. Identify Requirements

Req ID (Vol. I) Requirement Dialog DC Type Definition Class Name DC ID (Vol. II) Data Concept Instance Name
3.3.4.3.2.1 Send Link Status Information Upon Request 2.4.1 dialog dlLinkStatusRequest 3.1.13.2 dlLinkStatusRequest
3.3.4.3.2.2 Publish Link Status Information 2.4.3 dialog dlLinkStatusUpdate 3.1.34.2 dlLinkStatusUpdate
3.3.4.3.2.3 Subscribe to Link Status Information 2.4.2 dialog dlTrafficNetworkInformationSubscription 3.1.19.1 dlTrafficNetworkInformationSubscription
3.3.4.3.2.4 Contents of the Link Status Request message trafficNetworkInformationRequestMsg 3.2.19.1 trafficNetworkInformationRequestMsg
3.3.4.3.2.5 Contents of the Link Status Information message linkStatusMsg 3.2.13.2 linkStatusMsg
3.3.4.3.2.5.1 Required Link Status Information Content data-frame organizationInformation 3.3.16.3 organization-information
3.3.4.3.2.5.1 Required Link Status Information Content data-element transportation-network-identifier 3.4.20.1 network-id
3.3.4.3.2.5.1 Required Link Status Information Content data-element transportation-network-identifier 3.4.20.1 link-id
3.3.4.3.2.5.1 Required Link Status Information Content data-element link-status 3.4.14.34 link-status
3.3.4.3.2.5.2.1 Restrictions - Link Status data-frame restrictions 3.3.16.5 restrictions
3.3.4.3.2.5.2.2 Link Name - Link Status data-element transportation-network-name 3.4.21.1 link-name
3.3.4.3.2.5.2.3 Link Direction - Link Status data-element link-direction 3.4.14.9 link-direction
3.3.4.3.2.5.2.4 Lanes Open data-element link-lanes-count 3.4.14.12 lanes-number-open
3.3.4.3.2.5.2.5 Link Priority data-element link-priority-type 3.4.14.21 priority-type
3.3.4.3.2.5.2.6 Link Restrictions - Axles data-element link-restriction-axle-count 3.4.14.22 restriction-axle-count
3.3.4.3.2.5.2.7 Link Restrictions - Height data-element link-restriction-height 3.4.14.23 restriction-height
3.3.4.3.2.5.2.8 Link Restrictions - Length data-element link-restriction-length 3.4.14.24 restriction-length

RTM continues. Entire link status message not shown.

4.3.3. Identify Design Content

3.2.13.2 linkStatusMsg

3.2.13.2.1 ASN.1 REPRESENTATION
linkStatusMsg ITS-MESSAGE ::= {
DESCRIPTIVE-NAME "LinkStatusMsg:message"
ASN-NAME "LinkStatusMsg"
ASN-OBJECT-IDENTIFIER { tmddMessages 63 }
DEFINITION "The information content describing an owner center's traffic network link status."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
ARCHITECTURE-REFERENCE {
"road network conditions",
"traffic information for media" }
ARCHITECTURE-NAME {"U.S. National ITS Architecture"}
ARCHITECTURE-VERSION {"7.0"}
DATA-CONCEPT-TYPE message
STANDARD "TMDD"
META-DATA-SOURCE direct
PRIORITY "routine"
FREQUENCY-OR-MESSAGE-MODE "on demand"
REFERENCED-DATA-FRAMES {
{ tmddDataFrames 150 } -- LinkStatus }
DATA-TYPE " LinkStatusMsg ::= SEQUENCE (SIZE(1..10240)) OF LinkStatus " }

3.3.14.4 linkStatus
3.3.14.4.1 ASN.1 REPRESENTATION
linkStatus ITS-DATA-FRAME ::= {
DESCRIPTIVE-NAME "LinkStatusframe"
ASN-NAME "LinkStatus"
ASN-OBJECT-IDENTIFIER { tmddDataFrames 150 }
DEFINITION "The information content describing an owner center's traffic network link status for a list of links."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}_
DATA-CONCEPT-TYPE data-frame
STANDARD "TMDD"
REFERENCED-DATA-FRAMES {
{ tmddDataFrames 160 }, -- Restrictions
{ tmddDataFrames 158 }, -- OrganizationInformation
{ tmddDataFrames 151 } -- LinkStatusList }
DATA-TYPE "LinkStatus ::= SEQUENCE {
restrictions Restrictions OPTIONAL,
organization-information OrganizationInformation,
link-status-list SEQUENCE (SIZE(1..10240)) OF LinkStatusList,
... }"
}

3.3.16.3 organization-information
3.3.16.3 organizationInformation
3.3.16.3.1 ASN.1 REPRESENTATION
organizationInformation ITS-DATA-FRAME ::= {
DESCRIPTIVE-NAME "OrganizationInformation:frame"
ASN-NAME "OrganizationInformation"
ASN-OBJECT-IDENTIFIER { tmddDataFrames 158 }
DEFINITION "The information content describing an organization information for a single organization."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
DATA-CONCEPT-TYPE data-frame
STANDARD "TMDD"
REFERENCED-DATA-FRAMES {
{ tmddDataFrames 156 }, -- ContactDetails
{ tmddDataFrames 157 }, -- OrganizationCenterInformation
{ tmddDataFrames 114 } -- DateTimeZone
}
REFERENCED-DATA-ELEMENTS {
{ tmddDataElements 192 }, -- Organization-resource-identifier
{ tmddDataElements 193 }, -- Organization-resource-name
{ tmddDataElements 191 }, -- Organization-location-fips
{ tmddDataElements 188 } -- Organization-function }
DATA-TYPE "OrganizationInformation ::= SEQUENCE {
organization-id Organization-resource-identifier,
organization-name Organization-resource-name OPTIONAL,
organization-location Organization-location-fips OPTIONAL,
organization-function Organization-function OPTIONAL,
organization-contact-details ContactDetails OPTIONAL,
center-contact-list SEQUENCE (SIZE(1..1024)) OF OrganizationCenterInformation OPTIONAL,
last-update-time DateTimeZone OPTIONAL,
... }"_
}

3.4.14.34 link-status
3.4.14.34.1 ASN.1 REPRESENTATION
link-status ITS-DATA-ELEMENT ::=
{ DESCRIPTIVE-NAME "Link.Link-status:cd"
ASN-NAME "Link-status"
ASN-OBJECT-IDENTIFIER { tmddDataElements 175 }
DEFINITION "The current status that provides an indication of standard or non-standard link or route operations."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
DATA-CONCEPT-TYPE data-element
STANDARD "TMDD"
DATA-TYPE "Link-status ::= ENUMERATED{
no-determination (1),
open (2),
restricted (3),
closed (4),
other (5) }"
FORMAT "ASN.1 encoding"
UNIT-OF-MEASURE ""
VALID-VALUE-RULE "see the ASN.1 DATA-TYPE" }

3.3.16.5 restrictions
3.3.16.5.1 ASN.1 REPRESENTATION
restrictions ITS-DATA-FRAME ::= {
DESCRIPTIVE-NAME "Restrictions:frame"
ASN-NAME "Restrictions"
ASN-OBJECT-IDENTIFIER { tmddDataFrames 160 }
DEFINITION "The information content describing restrictions on forwarding an owner center's information content by an external center."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
DATA-CONCEPT-TYPE data-frame
STANDARD "TMDD"
REFERENCED-DATA-ELEMENTS {
{ tmddDataElements 189 } -- Organization-information-forwarding-restrictions }
DATA-TYPE "Restrictions ::= SEQUENCE {
organization-information-forwarding-restrictions Organization-information-forwarding-restrictions,
... }"
}

3.4.21.1 link-name (This is the name of the element - what is in the RTM. A link-name is of type transportation-network-name. See below.)
3.4.21.1 transportation-network-name (
3.4.21.1.1 ASN.1 REPRESENTATION
transportation-network-name ITS-DATA-ELEMENT ::= {
DESCRIPTIVE-NAME "RoadwayNetwork.Transportation-network-name:txt"
ASN-NAME "Transportation-network-name"
ASN-OBJECT-IDENTIFIER { tmddDataElements 203 }
DEFINITION "The user-defined name for a roadway, roadway reference, roadway network, route, link, node or intersection name. Also applies to transit elements."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
DATA-CONCEPT-TYPE data-element
STANDARD "TMDD"
DATA-TYPE "Transportation-network-name ::= IA5String (SIZE(1..256))"
FORMAT "ASN.1 encoding"
UNIT-OF-MEASURE ""
VALID-VALUE-RULE "see the ASN.1 DATA-TYPE" }

3.4.14.9 link-direction
3.4.14.9 link-direction
3.4.14.9.1 ASN.1 REPRESENTATION
link-direction ITS-DATA-ELEMENT ::= {
DESCRIPTIVE-NAME "Link.Link-direction:cd"
ASN-NAME "Link-direction"
ASN-OBJECT-IDENTIFIER { tmddDataElements 150 }
DEFINITION "The direction(s) of travel referenced on a link, or a node."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
DATA-CONCEPT-TYPE data-element
STANDARD "TMDD"_
DATA-TYPE "Link-direction ::= ENUMERATED {
any-other (0),
n (1),
ne (2),
e (3),
se (4),
s (5),
sw (6),
w (7),
nw (8),
not-directional (9),
positive-direction (10),
negative-direction (11),
both-directions (12),
other (13) }"
FORMAT "ASN.1 encoding"
UNIT-OF-MEASURE ""
VALID-VALUE-RULE "see the ASN.1 DATA-TYPE" }

3.4.14.12 lanes-number-open
3.4.14.12 link-lanes-count
3.4.14.12.1 ASN.1 REPRESENTATION
link-lanes-count ITS-DATA-ELEMENT ::= {
DESCRIPTIVE-NAME "Link.Link-lanes-count:qty"
ASN-NAME "Link-lanes-count"
ASN-OBJECT-IDENTIFIER { tmddDataElements 153 }
DEFINITION "A count describing total number of lanes. Used to describe the total number of lanes on a link for a given direction of travel, subset of lanes affected by a roadway event, or lanes monitored or controlled by a roadway device."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
DATA-CONCEPT-TYPE data-element
STANDARD "TMDD"
DATA-TYPE "Link-lanes-count ::= INTEGER (0..255)"
FORMAT "ASN.1 encoding"
UNIT-OF-MEASURE "lanes"
VALID-VALUE-RULE "see the ASN.1 DATA-TYPE" }

3.4.14.21 priority-type
3.4.14.21 link-priority-type
3.4.14.21.1 ASN.1 REPRESENTATION
link-priority-type ITS-DATA-ELEMENT ::= {
DESCRIPTIVE-NAME "Link.Link-priority-type:cd"
ASN-NAME "Link-priority-type"
ASN-OBJECT-IDENTIFIER { tmddDataElements 162 }
DEFINITION "The roadway priority assignments for which the roadway is restricted from general traffic access due to one of the listed priority functions."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
DATA-CONCEPT-TYPE data-element
STANDARD "TMDD"
DATA-TYPE "Link-priority-type ::= ENUMERATED {
special-events (1),
snow-ice-clearance (2),
weather-evacuation (3),
defense-movements (4),
hazmat (5),
agricultural-access (6),
none (7) }"
FORMAT "ASN.1 encoding"
UNIT-OF-MEASURE ""
VALID-VALUE-RULE "see the ASN.1 DATA-TYPE" }

3.4.14.22 restriction-axle-count
3.4.14.22 link-restriction-axle-count
3.4.14.22.1 ASN.1 REPRESENTATION
link-restriction-axle-count ITS-DATA-ELEMENT ::= {
DESCRIPTIVE-NAME "Link.Link-restriction-axle-count:qty"
ASN-NAME "Link-restriction-axle-count"
ASN-OBJECT-IDENTIFIER { tmddDataElements 163 }
DEFINITION "Maximum axle count for a vehicle allowed on the link."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
DATA-CONCEPT-TYPE data-element
STANDARD "TMDD"
DATA-TYPE "Link-restriction-axle-count ::= INTEGER (0..20)"
FORMAT "ASN.1 encoding"
UNIT-OF-MEASURE "axles"
VALID-VALUE-RULE "see the ASN.1 DATA-TYPE" }

3.4.14.23 restriction-height
3.4.14.23 link-restriction-height
3.4.14.23.1 ASN.1 REPRESENTATION
link-restriction-height ITS-DATA-ELEMENT ::= {
DESCRIPTIVE-NAME "Link.Link-restriction-height:qty"
ASN-NAME "Link-restriction-height"
ASN-OBJECT-IDENTIFIER { tmddDataElements 164 }
DEFINITION "Minimum vertical clearance on a link. Overpasses, bridges, and tunnels are examples. Measured in centimeters unless otherwise indicated by the link-restriction-units data element. 2000 centimeters = 65.6 feet."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
DATA-CONCEPT-TYPE data-element
STANDARD "TMDD"
DATA-TYPE "Link-restriction-height ::= INTEGER (0..2000)"
FORMAT "ASN.1 encoding"
UNIT-OF-MEASURE ""
VALID-VALUE-RULE "see the ASN.1 DATA-TYPE" }

3.4.14.24 restriction-length  
3.4.14.24 link-restriction-length 3.4.14.24.1 ASN.1 REPRESENTATION
link-restriction-length ITS-DATA-ELEMENT ::= {
DESCRIPTIVE-NAME "Link.Link-restriction-length:qty"
ASN-NAME "Link-restriction-length"
ASN-OBJECT-IDENTIFIER { tmddDataElements 165 }
DEFINITION "Maximum Vehicle Length allowable on a link. Measured in centimeters unless otherwise indicated by the link-restriction-units data element."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
DATA-CONCEPT-TYPE data-element
STANDARD "TMDD"
DATA-TYPE "Link-restriction-length ::= INTEGER (0..6000)"
FORMAT "ASN.1 encoding"
UNIT-OF-MEASURE""
VALID-VALUE-RULE "see the ASN.1 DATA-TYPE" }

4.3.4. Document Value Constraints for Inputs and Outputs

Test Case Input Specification
ID: TCIS001 Title: Link Status Information Request (Positive Test Case)
Data Concept ID Data Concept Name (Variable) Data Concept Type Value Constraints
3.2.19.1 trafficNetworkInformationRequestMsg Message  
3.3.16.3 organization-requesting Data Frame  
3.4.16.8 organization-id Data Element IA5String (SIZE(1..32))
3.4.16.9 organization-name Data Element IA5String (SIZE(1..128))
3.4.20.2 network-information-type Data Element 1 = "node inventory"
2 = "node status"
3 = "link inventory"
4 = "link status"
5 = "route inventory"
6 = "route status"
7 = "network inventory"
Test Case Output Specification
ID: TCOS001 Title: Link Status Information Request (Positive Test Case)
Data Concept ID Data Concept Name (Variable) Data Concept Type Value Constraints
3.2.13.2 linkStatusMsg Message  
3.3.16.3 organization-information Data Frame  
3.4.16.8 organization-id Data Element IA5String (SIZE(1..32))
3.4.16.9 organization-name Data Element IA5String (SIZE(1..128))
3.4.20.1 network-id Data Element IA5String (SIZE(1..32))
3.4.20.1 link-id Data Element IA5String (SIZE(1..32))
3.4.21.1 link-name Data Element IA5String (SIZE(1..128))
3.4.14.34 link-status Data Element 1 = "no determination"
2 = "open"
3 = "restricted"
4 = "closed"
3.4.14.37 travel-time Data Element INTEGER (0..65535), units=seconds

4.3.5. Develop Test Case

Test Case
ID:TC001 Title: Link Status Request-Response Dialog Verification (Positive Test Case)
Objective: To verify system interface implements (positive test case) requirements for:
  1. 1) Link Status Request-Response Dialog message exchange
  2. 2) Contents of the Link Status Request Message
  3. 3) Contents of the Link Status Information Message
The test case verifies that the dialog, request message content, and response message content are correct by sending a request message (verified to be correct) across the system interface, and verification that the response message is correct. Input and output specifications are provided to verify the request and response message are correct per the requirements for the request and response message.
Inputs: Use the input file linkStatusRequest_pos.xml. See Test Case Input Specification TCIS001 - LinkStatusRequest (Positive Test Case). Set network-information-type to 4 or the text "link status."
Outcome(s): All data are returned and verified as correct: correct sequence of message exchanges, structure of data, and valid value of data content. See Test Case Output Specification TCOS001 - LinkStatusInformation (Positive Test Case)
Environmental Needs: No additional needs outside of those specified in the test plan.
Tester/Reviewer M.I.
Special Procedural Requirements: None
Intercase Dependencies: None

5. References

  1. IEEE Std 829-2008 IEEE Standard for Software and System Test Documentation (http://www.ieee.org)
  2. IEEE Std 610-1990 Standard Glossary of Software Engineering Terminology 9 (http://www.ieee.org)
  3. NTCIP 8007Testing and Conformity Assessment Documentation within NTCIP Standards Publications (http://www.ntcip.org/library/)
  4. NTCIP 1204 v03 Environmental Sensor Station Interface Standard (http://www.ntcip.org/library/)
  5. Traffic Management Data Dictionary Version 3.03 (http://www.ite.org/standards/tmdd/)
  6. T202: Overview of Test Design Specifications, Test Case Specifications, and Test Procedures stds training.aspx

6. Study Questions

1. Which of the following IEEE Std 829-based component describes data inputs and outputs to be tested?

  1. Test Plan
  2. Test Case Specification
  3. Test Design Specification
  4. Test Procedure Specification

2. Which of the following defines the structure and data content of inputs and outputs?

  1. Data Dictionary Standard (e.g., NTCIP 1204 ESS, TMDD)
  2. Protocol Requirements List (PRL)
  3. Requirements to Test Case Traceability Matrix (RTCTM)
  4. All of the above

3. Which of the following will provide information on project needs for a C2C project?

  1. Needs to Requirements Traceability Matrix (NRTM)
  2. Requirements to Test Case Traceability Matrix (RTCTM)
  3. Requirements Traceability Matrix (RTM)
  4. Design (dialogs, data elements, valid values)

4. Which of the following is part of the IEEE Std 829 Test Case Specification?

  1. Description and valid values of inputs and outputs
  2. Project Sponsor
  3. Steps to Conduct a Test
  4. Test Pass-Fail