Module 13 - T202

T202: Overview of Test Design Specifications Test Cases, and Test Procedures

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

T202 - Overview of Test Design Specifications Test Cases, and Test Procedures

(Extended Text Description: Large graphic cover page with dark blue background with the title in white letters “T202 - Overview of Test Design Specifications Test Cases, and Test Procedures.” At the middle left is the “Standards ITS Training” logo with a white box and letters in blue and green. The words “Student Supplement” and “RITA Intelligent Transportation Systems Joint Program Office” in white lettering are directly underneath the logo. Three light blue lines move diagonally across the middle of the blue background.)

T202: Overview of Test Design Specifications, Test Cases, and Test Procedures

Table of Contents

System Engineering “V” Diagram - 2
 Sample Test Design Specification – DMS - 4
 Sample Test Case Specification – DMS - 6
 Sample Test Procedure Specification – DMS - 9
 Sample Test Case Specification – TSS - 10
 Sample Test Procedure Specification – TSS - 12
 Sample Test Case Specification – CCTV - 13
 Sample Test Procedure Specification – CCTV - 16
 Terminology/Glossary - 19
References - 22

Systems Engineering “V” Diagram

The “V” diagram used by the ITS industry, as shown in Figure 1, reflects a customization of the more general systems engineering process (SEP), but follows widely accepted guidelines.

Figure 1: Systems Engineering V Diagram for ITS. Please see the Extended Text Description below.

(Extended Text Description: Slide 10: A graphic of the FHWA “V” diagram of the Project Life Cycle is shown. The main graphic is a V-shaped diagram with some additional horizontal “wings” on the left and right side of the top of the V. Starting from the left “wing” the steps are Regional Architecture(s) and Feasibility Study / Concept Exploration. At this point the steps begin to descend the left side of the V with: Concept of Operations; System Requirements; High-Level Design; and Detailed Design. The base of the V shows Software / Hardware Development & Field Installation. At this point the steps begin to ascend the right side of the V with: Unit / Device Testing; Subsystem Verification; System Verification & Deployment; and System Validation. Finally, the right “wing” includes steps that occur past the testing phases: Operations and Maintenance; Changes and Upgrades; and Retirement / Replacement. Each phase on the left of the “V” is associated by means of a dashed arrow with a phase on the right “V” (from the bottom): Detailed Design is associated with Unit / Device Testing by the Unit / Device Test Plan; High-Level Design is associated with Subsystem Verification by the Subsystem Verification Plan (Subsystem Acceptance); System Requirements is associated with System Verification & Deployment by the System Verification Plan (System Acceptance); and Concept of Operations is associated with System Validation by the System Validation Plan. The left side of the “V” is labeled “Decomposition and Definition”, the bottom is labeled “Implementation”, and the right side of the “V” is labeled “Integration and Recomposition”. At the bottom, a rightward facing arrow is labeled “Time Line".)

Figure 1: Systems Engineering “V” Diagram for ITS

The “V” starts with identifying the portion of the regional ITS architecture that is related to the project. Other artifacts of the planning and programming processes that are relevant to the project are collected and used as a starting point for project development. This is the first step in defining an ITS project.

Next, the agency develops a business case for the project. Technical, economic, and political feasibility is assessed; benefits and costs are estimated; and key risks are identified. Alternative concepts for meeting the project's purpose and need are explored, and the superior concept is selected and justified using trade study techniques. Once funding is available, the project starts with the next step.

The “V” then begins to dip downwards to indicate an increased level of detail. The project stakeholders reach a shared understanding of the system to be developed and how it will be operated and maintained. The Concept of Operations is documented to provide a foundation for more detailed analyses that will follow. It will be the basis for the system requirements that are developed in the next step.

At the system requirements stage, the stakeholder needs identified in the Concept of Operations are reviewed, analyzed, and transformed into verifiable requirements that define what the system will do but not how the system will do it. Working closely with stakeholders, the requirements are elicited, analyzed, validated, documented, and version controlled.

The system design is created based on the system requirements including a high-level design that defines the overall framework for the system. Subsystems of the system are identified and decomposed further into components. Requirements are allocated to the system components, and interfaces are specified in detail. Detailed specifications are created for the hardware and software components to be developed, and final product selections are made for off-the-shelf components.

Hardware and software solutions are created for the components identified in the system design. Part of the solution may require custom hardware and/or software development, and part may be implemented with off-the-shelf items, modified as needed to meet the design specifications. The components are tested and delivered ready for integration and installation.

Once the software and hardware components have been developed, the “V” changes direction to an upward slope. The various components are individually verified and then integrated to produce higher-level assemblies or subsystems. These assemblies are also individually verified before being integrated with others to produce yet larger assemblies, until the complete system has been integrated and verified.

Eventually, the system is installed in the operational environment and transferred from the project development team to the organization that will own and operate it. The transfer also includes support equipment, documentation, operator training, and other enabling products that support ongoing system operation and maintenance. Acceptance tests are conducted to confirm that the system performs as intended in the operational environment. A transition period and warranty ease the transition to full system operation.

After the ITS system has passed system verification and is installed in the operational environment, the system owner/operator, whether the state DOT, a regional agency, or another entity, runs its own set of tests to make sure (i.e., validate) that the deployed system meets the original needs identified in the Concept of Operations.

Once the customer has approved the ITS system, the system operates in its typical steady state. System maintenance is routinely performed and performance measures are monitored. As issues, suggested improvements, and technology upgrades are identified, they are documented, considered for addition to the system baseline, and incorporated as funds become available. An abbreviated version of the systems engineering process is used to evaluate and implement each change. This occurs for each change or upgrade until the ITS system reaches the end of its operational life.

Finally, operation of the ITS system is periodically assessed to determine its efficiency. If the cost to operate and maintain the system exceeds the cost to develop a new ITS system, the existing system becomes a candidate for replacement. A system retirement plan will be generated to retire the existing system gracefully.

To find more information on the systems engineering process, see the links provided in the References section of this supplement.


Sample Test Design Specification - DMS

Test Design Specification Identifier
TDS-C-DMS

Introduction
This Test Design Specification is to clarify and expand on the details given in Test Plan TP-C-DMS2-1, which defines testing to be performed on a DMS to verify conformance with NTCIP 1203 v03.

Features to be Tested
All mandatory requirements of NTCIP 1203 v03 shall be tested. In addition, optional requirements selected in the NTCIP 1203 Protocol Requirements List (PRL) as shown below shall be tested.

Protocol Requirements List (excerpts)

NTCIP 1203 Protocol Requirements List (PRL)

USER NEED SECTION NUMBER

USER NEED

FR SECTION NUMBER

FUNCTIONAL REQUIREMENT

CONFORMANCE

SUPPORT/ PROJECT REQUIREMENT

ADDITIONAL PROJECT REQUIREMENTS

2.3.2.3

DMS Display Matrix Configuration

M

Yes

The DMS shall be 9,000 millimeters wide (0..65535) and 2,700 millimeters high (0..65535), inclusive of borders.

The Sign's Border shall be at least 400 millimeters wide (0..65535) and 400 millimeters high (0..65535).

2.3.2.3.1

Non-Matrix

0.2 (1)

Yes/No

2.3.2.3.2 (Matrix)

Matrix

0.2 (1)

Yes/No

The pitch between pixels shall be at least 66 millimeters (0..255).

2.3.2.3.2.1

Full Matrix

0.3 (1)

Yes/No

The sign shall be    pixels wide (0..65535) and    pixels high (0..65535).

2.3.2.3.2.2

Line Matrix

0.3 (1)

Yes/No

The sign shall have     lines with each line being    pixels wide and    pixels high.

2.3.2.3.2.3

Character Matrix

0.3(1)

Yes/No

The sign shall be 18 characters wide and 3 characters high with each character being 5 pixels wide (0..255), 7 pixels high (0..255).

(Additional Notes from the Author: Below the text, an excerpt from the NTCIP 1203 Protocol Requirements List (PRL) shows a table with the following columns: user Need Section Number, User Need, FR Section Number, Functional Requirement, Conformance, Support / Project Requirement and Additional Project Requirements. Entries for User Need 2.3.2.3 through 2.3.2.3.2.3 are shown. Under the Support / Project Requirement column, individual entries indicating “Yes/No” have had either Yes or No highlighted.)

NTCIP 1203 Protocol Requirements List (PRL)

USER NEED SECTION NUMBER

USER NEED

FR SECTION NUMBER

FUNCTIONAL REQUIREMENT

CONFORMANCE

SUPPORT/ PROJECT REQUIREMENT

2.5.1.2

Determine Sign Display Capabilities

O

Yes/No

3.5.1.2.1.1

Determine the Size of the Sign Face

M

Yes

3.5.1.2.1.2

Determine the Size of the Sign Border

M

Yes

3.5.1.2.1.3

Determine Beacon Type

M

Yes

3.5.1.2.1.4

Determine Sign Access and Legend

M

Yes

3.5.1.2.2.1

Determine Sign Face Size in Pixels

Matrix:M

Yes/NA

3.5.1.2.2.2

Determine Character Size in Pixels

Matrix:M

Yes/NA

3.5.1.2.2.3

Determine Pixel Spacing

Matrix:M

Yes/NA

(Additional Notes from the Author: Above an excerpt from the NTCIP 1203 PRL shows a table with the same column headings as described in slide 32. The Entry for User Need Section Number 2.5.1.2, with FR Section Numbers 3.2.1.2.1.1 through 3.5.1.2.2.3, is shown. The first entry shows User Need Section Number 2.5.1.2, User Need “Determine Sign Display Capabilities”, Conformance “O”, and Support / Project Requirement “Yes / No”, with Yes highlighted. For the three requirements at the bottom of the table the Conformance column indicates “Matrix: M”, and the Support / Project Requirement column shows “Yes / NA”, with Yes highlighted.)

Approach Refinements
The testing approach is to be as defined in the Test Plan TP-C-DMS2-1. In addition to the use of NTESTER v2.0 as a testing tool, Intelligent Devices’ DeviceTester shall also be allowed.

Test Identification
Test Cases and Test Case Identifiers are as defined in the Test Case Specification TCS-C-DMS.

Feature Pass/Fail Criteria
Pass/Fail criteria shall be as defined in the test procedures defined in NTCIP 1203 v03.

SAMPLE Test Case Specification - DMS

Test Case Specification Identifier
TCS-C-DMS

Purpose
This document defines the test cases to be used to verify conformance of the DMS with NTCIP 1203 v03. They specify the input and output parameters and special conditions for use with the published NTCIP 1203 v03 Test Cases/Test Procedures.

Test Items
The items selected for testing are in accordance with the project Protocol Requirements List (PRL) as given in Test Design Specification TDS-C-DMS. The required test cases listed in Appendix A were determined by means of the Requirements to Test Cases Traceability Matrix found in NTCIP 1203 v03.

Input Specifications
The individual input specifications for each test case are given in Appendix A.

Output Specifications
The individual output specifications for each test case are defined in the NTCIP 1203 v03 Test Procedures.

Environmental Needs
In addition to the testing facilities defined in the Test Plan TP-C-DMS2-1, the following Test Cases will require special tools:

Test Case ID

Special Items Required:

TC 1.2

Tape measure, 30m, marked in mm

TC 1.3

Tape measure, 30m, marked in mm

TC 1.8

Tape measure, 30m, marked in mm

Special Procedural Requirements
No special procedural requirements exist.

Intercase Dependencies
Intercase Dependencies are as detailed in NTCIP 1203 v03.

Appendix A (excerpt)
* NOTE: Variables with the same name must be assigned the same value. The user only needs to define variable values for those test cases that are selected.

NTCIP 1203 Test Case/Test Procedure ID

Test Case/Test Procedure

Selected

Variable

Reference

Value

1.1

Determine Sign Type and Technology

 X

Required_Sign_Type

PRL 2.3.2.1 and 2.3.2.3

4 (vmsChar)

Required_Sign_Technology

PRL 2.3.2.2

 2 (LED 0000 0010)

1.2

Determine the Size of the Sign Face

X

Required_Sign_Height

PRL 2.3.2.3

 2700 (mm)

Required_Sign_Width

PRL 2.3.2.3

 9000 (mm)

1.3

Determine Size of the Sign Border

X

Required_Horizontal_Border

PRL 2.3.2.3

 400 (mm)

Required_Vertical_Border

PRL 2.3.2.3

 400 (mm)

1.4

Determine Beacon Type

X

Required_Beacon_Configuration

PRL 2.3.2.4

 2 (None)

1.5

Determine Sign Access and Legend

 X

Required_Sign_Access

per specification

 8 (front, bit 3 =1)

Required_Legend

per specification

2 (No legend)

1.6

Determine Sign Face Size in Pixels

X 

Required_Sign_Pixel_Height

PRL 2.3.2.3.2.1-2.3.2.3.2.3,

 21

Required_Sign_Pixel_Width

PRL 2.3.2.3.2.1-2.3.2.3.2.3

 90

1.7

Determine Character Size in Pixels

X 

Required_Character_Pixel_Height

PRL 2.3.2.3.2.3

7

Required_Character_Pixel_Width

PRL 2.3.2.3.2.3

5

1.8

Determine Pixel Spacing

X 

Required_Horizontal_Pitch

PRL 2.3.2.3.2

 66 (mm)

Required_Vertical_Pitch

PRL 2.3.2.3.2

 66 (mm)

SAMPLE Test Procedure Specification – DMS

The Test Case/Test Procedure below are excerpted from NTCIP 1203 v03, which includes Test Cases and Test Procedures.

Test Case:
1.6

Title:

Determine Sign Face Size in Pixels

Description:

This test case verifies that the DMS indicates that it has a height and width in pixels that meet the requirements of the specifications.

Variables:

Required_Sign_Pixel_Height

PRL 2.3.2.3.2.1-2.3.2.3.2.3

Required_Sign_Pixel_Width

PRL 2.3.2.3.2.1-2.3.2.3.2.3

Pass/Fail Criteria:

The DUT shall pass every verification step included within the Test Case to pass the Test Case.

Step

Test Procedure

Results

Additional References

1

CONFIGURE: Determine the sign height in pixels as required by the specification (PRL 2.3.2.3.2.1-2.3.2.3.2.3). RECORD this information as:
    »Required_Sign_Pixel_Height

2

CONFIGURE: Determine the sign width in pixels as required by the specification (PRL 2.3.2.3.2.1-2.3.2.3.2.3). RECORD this information as:
    »Required_Sign_Pixel_Width

3

SET-UP: Determine the actual sign height in pixels. RECORD this information as:
    »Actual_Pixel_Height

4

SET-UP: Determine the actual sign width in pixels. RECORD this information as:
    »Actual_Pixel_Width

5

GET the following object(s):
    »vmsSignHeightPixels.0
    »vmsSignWidthPixels.0

Pass / Fail
(Section 3.5.1.2.2.1)

6

VERIFY that the RESPONSE VALUE for vmsSignHeightPixels.0 is equal to Required_Sign_Pixel_Height.

Pass / Fail
(PRL 2.3.2.3.2.1-2.3.2.3.2.3)

7

VERIFY that the RESPONSE VALUE for vmsSignWidthPixels.0 is equal to Required_Sign_Pixel_Width.

Pass / Fail
(PRL 2.3.2.3.2.1-2.3.2.3.2.3)

8

VERIFY that the RESPONSE VALUE for vmsSignHeightPixels.0 is equal to Actual_Pixel_Height.

Pass / Fail
(Section 3.5.1.2.2.1)

9

VERIFY that the RESPONSE VALUE for vmsSignWidthPixels.0 is equal to Actual_Pixel_Width.

Pass / Fail
(Section 3.5.1.2.2.1)

Test Case Results

Tested By:

Date Tested:

Pass / Fail

Test Case Notes:

SAMPLE Test Case Specification – TSS

The Test Case Specification below was created for this webinar, as NTCIP 1209, TSS, does not include Test Cases or Test Procedures.

Test Case Specification Identifier
TCS-1209

Purpose
These test cases are to be used to verify conformance of the TSS (Transportation Sensor System) with NTCIP 1209 v02. They specify the input and output parameters for use with the Test Procedures TPS-1209.

Test Items
These test cases will provide details of the tests to be performed to verify conformance of the TSS with NTCIP 1205 v01. The Test Item is to consist of a Transportation Sensor System. The Test Procedure steps that support each Test Case are mapped in the table in Appendix A.

Input Specifications
The individual input specifications for each test case are given in Appendix A.

Output Specifications
The individual output specifications for each test case are given in Appendix A.

Environmental Needs
No additional needs exist beyond those defined in the Test Plan.

Special Procedural Requirements
No special procedural requirements exist.

Intercase Dependencies
No intercase dependencies exist.

Appendix A:

Test Case Number

Test Case Name

Test Procedure

Object(s) Under Test

Variables

Result

TC1205-001

Restart TSS

TP1205-001

sensorSystemStatus.0,

sensorSystemReset.0

Command = ‘restart’

sensorSystemStatus.0 = oK

TC1205-002

Reinitialize TSS

TP1205-001

sensorSystemStatus.0,

sensorSystemReset.0

Command = ‘reinitializeUserSettings’

sensorSystemStatus.0 = oK

TC1205-003

Restore TSS

TP1205-001

sensorSystemStatus.0,

sensorSystemReset.0

Command = ‘restoreFactoryDefaults’

sensorSystemStatus.0 = oK

TC1205-004

Retune TSS

TP1205-001

sensorSystemStatus.0,

sensorSystemReset.0

Command = ‘retune’

sensorSystemStatus.0 = oK

TC1205-005

Re-sync TSS

TP1205-001

sensorSystemStatus.0,

sensorSystemReset.0

Command = ‘resyncSamplingPeriods’

sensorSystemStatus.0 = oK

TC1205-006

Run Short Diagnostics

TP1205-001

sensorSystemStatus.0,

sensorSystemReset.0

Command = ‘shortDiagnostics’

sensorSystemStatus.0 = oK

TC1205-007

Run Long Diagnostics

TP1205-001

sensorSystemStatus.0,

sensorSystemReset.0

Command = ‘fullDiagnostics’

sensorSystemStatus.0 = oK


SAMPLE Test Procedure Specification - TSS

The Test Procedure below was created for this webinar, as NTCIP 1209, TSS, does not include Test Cases or Test Procedures.

Test Procedure:

TP1209-001

Title:

Description:

Pass/Fail Criteria:

Variables:

Reset the TSS

This Test Case verifies that the operator can correctly reset the TSS.

The DUT shall pass every verification step included within the Test Case in order to pass the Test Case.

Command   Command to be implemented

Test Step Number

Test Step

Results

1.

GET sensorSystemStatus.0

Pass / Fail

2.

IF the RESPONSE VALUE to sensorSystemStatus.0 is ‘initializing’, ‘pendingConfigurationChange’, or ‘validatingPendingConfiguration’ EXIT the Test Procedure, and correct the deficiency before restarting the test.

3.

SET sensorSystemReset.0 to Command.

Pass / Fail

4.

GET sensorSystemStatus.0

Pass / Fail

5.

IF the RESPONSE VALUE for sensorSystemStatus.0 equals 'initializing', then GOTO Step 4.

NOTE--If the RESPONSE VALUE remains at ‘initializing’ for more than the maximum TSS initialization time, this test fails.

Pass / Fail

6.

VERIFY that the RESPONSE VALUE for sensorSystemStatus.0 equals ‘oK’.

Pass / Fail

Test Procedure Result:

Pass / Fail

Test Procedure Notes:

SAMPLE Test Case Specification – CCTV

The Test Case Specification below was created for this webinar, as NTCIP 1205, CCTV, does not include Test Cases or Test Procedures.

Test Case Specification Identifier
TCS-1205

Purpose
These test cases are to be used to verify conformance of the CCTV (closed circuit TV) camera with NTCIP 1205 v01. They specify the input and output parameters for use with the NTCIP 1205 v01 Test Procedures.

Test Items
These test cases will provide details of the tests to be performed to verify conformance of the camera with NTCIP 1205 v01. The items selected for testing are in accordance with the Test Design Specifications TDS-1205. The Test Procedure steps that support each Test Case are mapped in the table in Appendix A.

Input Specifications
The individual input specifications for each test case are given in Appendix A.

Output Specifications
The individual output specifications for each test case are given in Appendix A.

Environmental Needs
No additional needs exist beyond those defined in the Test Plan.

Special Procedural Requirements
No special procedural requirements exist.

Intercase Dependencies
No intercase dependencies exist.

Appendix A:

Test Case Number

Test Case Name

Test Procedure Steps

Object(s) Under Test

Variables

Result

TC1205-001

Zoom absolute -  maximum telephoto

TP1205-003 Steps 4-10

positionZoomLens.0

Mode = 2 (absolute)

Speed_Tele_Fast = 127

Offset = rangeZoomLimit.0

Camera should zoom to its maximum setting at its maximum speed

TC1205-002

Zoom absolute -  maximum wide

TP1205-003 Steps 11-17

positionZoomLens.0

Mode = 2 (absolute)

Speed_Wide_Fast = -128

Offset = 0

Camera should zoom to its widest angle setting at its maximum speed

TC1205-003

Zoom absolute -half-way

TP1205-003 Steps 18-24

positionZoomLens.0

Mode = 2 (absolute)

Speed_Tele_Fast = 127

Offset = (rangeZoomLimit.0)/2

Camera should zoom halfway to its maximum setting at its maximum speed

TC1205-004

Zoom delta

TP1205-003 Steps 25-30

positionZoomLens.0

Mode = 1 (delta) Speed_Tele_Mid = 50

Offset = (rangeZoomLimit.0)/10

Camera should zoom 1/10th toward its maximum zoom at midspeed with each delta command

TC1205-005

Zoom continuous

TP1205-003 Steps 31-33

positionZoomLens.0

Mode = 3 (continuous)

Speed_Wide_Slow = -30

Offset = 0

Camera should zoom wide at a slow speed

TC1205-006

Zoom stop

TP1205-003 Steps 34-38

positionZoomLens.0

Mode = 0 (stop)

Speed = 0

Offset = 0

Camera should stop

TC1205-007

Zoom past rangeZoomLimit.0

TP1205-003 Steps 39-41

positionZoomLens.0; rangeZoomLimit.0

Mode = 1 (absolute)

Speed_Tele_Fast = 127

Offset = 65535

Response Error is badValue

TC1205-008

Zoom for greater duration than  timeoutZoom.0

TP1205-003 Steps 40-46

positionZoomLens.0; timeoutZoom.0

Mode = 3 (continuous)

Speed_Tele_Slow = 10

Offset = rangeZoomLimit.0

Camera begins zooming toward its maximum telephoto setting, but stops after Zoom_Timeout seconds


SAMPLE Test Procedure Specification - CCTV

The Test Procedure below was created for this webinar, as NTCIP 1205, CCTV, does not include Test Cases or Test Procedures.

Test Procedure:

TP1205-003

Title:

Description:

Pass/Fail Criteria:

Variables:

Zoom Camera

This Test Case verifies that the operator can correctly zoom the camera in and out.

The DUT shall pass every verification step included within the Test Case in order to pass the Test Case.

Speed_Tele_Fast      [85..127]

Speed_Wide_Fast     [-85..-128]

Speed_Tele_Mid       [42..84]

Speed_Wide_Slow    [-1..-41]

Speed_Tele_Slow     [1..41]

Zoom_Timeout          [0..65535] (in milliseconds)

Test Step Number

Test Step

Results

1.

Get rangeZoomLimit.0

Pass / Fail

2.

RECORD this integer value and its two-byte hex value as:

>> Zoom_Limit

>> Zoom_Limit_Hex

3.

Set timeoutZoom.0 to 0, turning off this feature.

Pass / Fail

4.

Set positionZoomLens.0 to

Mode: 2 (absolute)

Speed: Speed_Tele_Fast

Position or Offset: Zoom_Limit

Pass / Fail

5.

Delay for 10 seconds

6.

Verify that the camera zoomed to its absolute telephoto position.

Pass / Fail

7.

Get positionZoomLens.0

Pass / Fail

8.

Verify that the Response Value equals

Mode: 02

Speed: Speed_Tele_Fast

Position or Offset: Zoom_Limit_Hex

Pass / Fail

9.

Get positionQueryZoom.0

Pass / Fail

10.

Verify that the Response Value equals Zoom_Limit. A Response Error of noSuchName indicates that positionQueryZoom.0 is unsupported.

Pass / Fail / Pass Unsupported

11.

Set positionZoomLens.0 to

Mode: 2 (absolute)

Speed: Speed_Wide_Fast

Position or Offset: 0

Pass / Fail

12.

Delay for 10 seconds

13.

Verify that the camera zoomed to its absolute wide position.

Pass / Fail

14.

Get positionZoomLens.0

Pass / Fail

15.

Verify that the Response Value equals

Mode: 02

Speed: Speed_Wide_Fast

Position or Offset: 00 00

Pass / Fail

16.

Get positionQueryZoom.0

Pass / Fail

17.

Verify that the Response Value equals 0. A Response Error of noSuchName indicates that positionQueryZoom.0 is unsupported.

Pass / Fail / Pass Unsupported

18.

Set positionZoomLens.0 to

Mode: 2 (absolute)

Speed: Speed_Wide_Fast

Position or Offset: Zoom_Limit / 2

Pass / Fail

19.

Delay for 5 seconds

20.

Verify that the camera is zoomed in half way

Pass / Fail

21.

Get positionZoom.0

Pass / Fail

22.

Verify that the Response Value equals

Zoom_Limit_Hex / 2

Pass / Fail

23.

Get positionQueryZoom.0

Pass / Fail

24.

Verify that the Response Value equals Zoom_Limit / 2. A Response Value of 0 indicates that positionQueryZoom.0 is unsupported.

Pass / Fail / Pass Unsupported

25.

For each value N, from 1 to 5, perform steps 26 through 30.

26.

Set positionZoomLens.0 to

Mode: 1 (delta)

Speed: Speed_Tele_Mid

Position or Offset: Zoom_Limit / 10

Pass / Fail

27.

Delay for 2 seconds

28.

Verify that the camera zooms in by some amount

Pass / Fail

29.

Get positionQueryZoom.0

Pass / Fail

30.

Verify that the Response Value has been incremented by Zoom_Limit / 10 from the previous value of this step, where the initial value (N=1) is Zoom_Limit / 2. A Response Error of noSuchName indicates that positionQueryZoom.0 is unsupported.

Pass / Fail / Pass Unsupported

31.

Set positionZoomLens.0 to

Mode: 3 (continuous)

Speed: Speed_Wide_Slow

Position or Offset: 0

Pass / Fail

32.

Delay for 5 seconds

33.

Verify that the camera zooms out continuously

Pass / Fail

34.

Set positionZoomLens.0 to

Mode: 3 (continuous)

Speed: Speed_Tele_Slow

Position or Offset: 0

Pass / Fail

35.

Delay for 5 seconds

36.

Verify that the camera begins zooming in continuously.

Pass / Fail

37.

While the camera is still zooming, Set positionZoomLens.0 to

Mode: 0 (stopMovement)

Speed: 0

Position or Offset: 0

Pass / Fail

38.

Verify that the camera stops zooming.

Pass / Fail

39.

IF Zoom_Limit equals 65535, GOTO Step 42 - the camera allows all levels of zoom.

40.

Set positionZoomLens.0 to

Mode: 2 (absolute)

Speed: Speed_Tele_Fast

Position or Offset: 65535

Pass / Fail

41.

Verify that the RESPONSE ERROR is badValue.

Pass / Fail

42.

Set positionZoomLens.0 to

Mode: 2 (absolute)

Speed: Speed_Wide_Fast

Position or Offset: 0

Pass / Fail

43.

Verify that the camera zooms to its widest angle.

Pass / Fail

44.

Set timeoutZoom.0 to Zoom_Timeout.

Pass / Fail

45.

Set positionZoomLens.0 to

Mode: 2 (absolute),

Speed: Speed_Tele_Slow

Position or Offset: Zoom_Limit

Pass / Fail

46.

Verify that the lens begins slowly zooming in, then stops after two seconds.

Pass / Fail

Test Procedure Result:

Pass / Fail

Test Procedure Notes:
 

Terminology/Glossary

Term

Definition

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.

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.

Device Under Test (DUT)

NTCIP device that is the object of testing.

Dialogs

A sequence of information or message exchanges.

Environmental Sensor Station (ESS)

A location that includes a remote processor unit (RPU) connected to one or more sensors for the collection of environmental or meteorological data. It may also include a pavement treatment system (PTS).

NOTE-The abbr ESS may also be used in the plural.

Feature

A behavior of the device.

Interchangeable

A condition which exists when two or more items possess such functional and physical characteristics as to be equivalent in performance and durability, and are capable of being exchanged one for the other without alteration of the items themselves, or adjoining items, except for adjustment, and without selection for fit and performance.

NOTE-See National Telecommunications and Information Administration, U.S. Department of Commerce

Interoperable

The ability of two or more systems or components to exchange information and use the information that has been exchanged.

NOTE-See NTCIP 8004 v02.

Management Station

The computer system with which the device communicates. Typically, the management station commands and monitors the device.

Protocol Requirements List (PRL)

A table mapping user needs with its associated requirements, along with whether the requirement is mandatory for conformance to the standard. This table allows procurement personnel to specify the desired features of a DMS or can be used by a manufacturer to document the features supported by their implementation.

Remote Processor Unit (RPU)

A field processor that collects data from sensors and can communicate the collected data to other computers; the processor may also process the collected data and/or control equipment.

Requirement

A condition or capability to which a system shall conform.

Requirements Traceability

The ability to follow or study the logical progression among the needs, requirements, and design details in a step-by-step fashion.

Requirements to Test Cases Traceability Matrix (RTCTM)

A table that defines the traceability from a requirement to the associated test case.

Requirements Traceability Matrix (RTM)

A table that links the requirements to the corresponding dialogs and objects.

Sensor

A device that is capable of detecting a condition and reporting the result to an RPU.

Specification

A document that specifies, in a complete, precise, verifiable manner, the requirements, design, behavior, or other characteristics of a system or component, and, often, the procedures for determining whether these provisions have been satisfied.

Systems Engineering Process (SEP)

Interdisciplinary collaborative approaches to derive, evolve, and verify a life-cycle balanced system solution, which satisfies customer expectations and meets public acceptability. (IEEE)

Test Case Specification (TCS)

A document that specifies the actual inputs, predicted results, and set of execution conditions for a test. It also identifies constraints on the test procedures resulting from use of that specific test case.

NOTE—See IEEE 829 for a more detailed discussion of test cases.

Test Design Specification (TDS)

Per IEEE 829, “A document specifying the details of the test approach for a ... feature or combination of ... features and identifying the associated tests.”  For testing NTCIP conformance, this document includes the completed PRL and Requirements to Test Cases Traceability Matrix.

Test Plan

A document that prescribes the scope, approach, resources, and schedule of the testing activities. It identifies the items to be tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with the plan.

Test Procedure Specification (TPS)

A document that specifies a sequence of actions for the execution of a test. The test procedures test the implementation of the requirement. Test procedures are separated from test design as they are intended to be followed step by step and should not have extraneous detail.

Validation

A quality control process that determines if a product fulfills its intended purpose.

Verification

A quality control process that determines if a product meets specified requirements.


References

ITS

IEEE

FHWA