Module 30 - T321

T321: Applying Your Test Plan to TMDD Standard

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

 

Cover image for T321: Applying Your Test Plan to TMDD Standard. Please see the Extended Text Description below.

(Extended Text Description: Large graphic cover page with dark blue background with the title in white letters "T321: Applying Your Test Plan to TMDD Standard." 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.)

 

T321: Applying Your Test Plan to TMDD Standard

 

Table of Contents

Introduction/Purpose - 2

Samples/Examples - 2

Reference to Other Standards - 8

Glossary - 8

References - 9

Study Questions - 10

 

 

Module Description

The module includes a brief description of the TMDD Standard with materials and examples that describe how to develop test documentation for the purposes of performing system interface validation and verification. This module covers the role of testing including: compliance, manufacturing and acceptance tests, and verification and validation as part of the testing and quality life cycle expressed in the systems engineering “Vee” model. The “Vee” model is depicted in Figure 1.

This is a figure depicting the life cycle of a system and the relationships between each process (or step) of a system life cycle. Please see the Extended Text Description below.

(Extended Text Description: This is a figure depicting the life cycle of a system and the relationships between each process (or step) of a system life cycle. The figure is laid like the letter "V", thus it is called the "VEE" diagram. Time progresses as we move from the left side of the "VEE" to the right side of the "VEE". Starting from the upper left hand corner of the "VEE" and moving right and down, the processes are Regional Architecture(s), Feasibility Study / Concept Exploration, Concept of Operations, System Requirements, High-Level Design, and Detailed Design. These processes on the left side of the "VEE" is part of the Decomposition and Definition step. At the bottom of the "VEE" is the Software / Hardware Development Field Installation Implementation process, which is called the Development Process step. Moving up the right side of the "VEE", the processes are the Unit/Device Testing, Subsystem Verification, System Verification and Deployment, System Validation, Operations and Maintenance, Changes and Upgrades, and finally Retirement/Replacement. These processes on the right side of the "VEE" is called the Integration and Recomposition step. For the completion of each process, starting with the Concept of Operations to the completion of the System Verification and Deployment process, a document is produced or some type of formal approval is expected before continuing onto the next process. Verification or validation is expected between the processes on the left side of the "VEE" and the right side "VEE", and are indicated by dotted lines with arrows on the end between them. There is a dotted line between the Concept of Operations on the left and the System Validation on the right, labeled System Validation Plan. This indicates that testing of the Concept of Operations is performed in the System Validation Plan during the System Validation process. The next dotted line is between the Systems Requirements on the left and System Verification & Deployment on the right, and the line is labeled System Verification Plan, or in parentheses, System Acceptance. The next dotted line is between the High-Level Plan and the Subsystem Verification and it is labeled Subsystem Verification Plan, or in parentheses, Subsystem Acceptance. The last dotted line is between the Detailed Design and the Unit/Device Testing, and it is labeled Unit/Device Test Plan.)

Figure 1. Systems Engineering "Vee" Diagram

 

Introduction/Purpose

This module assists user agencies to create a test plan specific to their TMDD v3 Standard based system interface. Prior to developing such a test plan, the user is expected to be knowledgeable of the TMDD v3 Standard and testing methodologies. This module covers material related to elements of the TMDD Standard required to apply test plans to verify that an agency’s product or system meets design specifications and other requirements of the TMDD Standard, while following standard testing methodologies discussed in the plan and in IEEE Std 829 IEEE Standard for Software Test Documentation.

The focus of this course is on development of test documentation to test for TMDD system interface compliance. During the test phase, the system interface implementation is tested against the requirements that were developed for the project. A Requirements to Test Case Traceability Matrix (RTCTM) will be used to verify that the software being implemented fulfills all of the system interface requirements. To conduct the system interface test phase, the interface must be isolated from the hardware and central system software. TMDD testing focuses on the compliance with the requirements and system interface specification and not the software implementation. The test documentation developed is used to guide and document the processes used to verify compliance with the requirements and specification to ensure that the dialogs and data content of message exchanges are implemented correctly.

1. Samples/Examples

This section contains an example that traces a specific user need, Need to Share DMS Inventory, to the requirements that satisfies that user need, then to the (standard) design that will fulfill those requirements. An example Requirements to Test Case Matrix is then created, along with portions of an example test design specification, test case specifications and test procedure specifications.

From TMDD v3.03 Volume I, the example, completed NRTM in Table 1 depicts the following for User Need 2.3.5.4.1, Need to Share DMS Inventory:

 

Table 1. Example NRTM

Requirement ID Requirement Conformance Support Other Requirements
Dialogs
3.3.5.5.1.1 Send DMS Inventory Information Upon Request M Yes* The owner center shall respond within ___ (100 ms – 1 hour; Default = 1 minute) after receiving the request. See Section 3.4.2.
3.3.5.5.1.2 Publish DMS Inventory Information Subscription:O Yes / No* / NA The owner center shall begin sending the updated response message within ___ (100 ms – 24 hours; Default = 15 minutes) after the information is updated in the owner center. See Section 3.4.1.
3.3.5.5.1.3 Subscribe to DMS Inventory Information Subscription:O Yes / No* / NA  
Request Message
3.3.5.1.1.1 Contents of Device Information Request M Yes*  
3.3.5.1.1.1.1 Required Device Information Request Content M Yes*  
3.3.5.1.1.1.2.1 Authentication - Device Information (DeviceAuth) O Yes / No*  
3.3.5.1.1.1.2.1.1 Operator Identifier - Device Information DeviceAuth:O Yes / No* / NA  
3.3.5.1.1.1.2.2 External Center Organization - Device Information O Yes / No*  
3.3.5.1.1.1.3.1 Device Identifier Filter O Yes / No*  
3.3.5.1.1.1.3.2 Roadway Network Identifier Filter O Yes / No*  
3.3.5.1.1.1.3.3 Link Identifier Filter O Yes / No*  
3.3.5.1.1.1.3.4 Route Designator Filter O Yes / No*  
3.3.5.1.1.1.3.5 Linear Reference Filter O Yes / No*  
3.3.5.5.1.4 Contents of the DMS Inventory Request M Yes*  
Response Message
3.3.5.1.2.1 Contents of the Device Inventory Header M Yes*  
3.3.5.1.2.1.1 Required Device Inventory Content M Yes*  
3.3.5.1.2.1.2.1 Restrictions - Device Inventory O Yes / No*  
3.3.5.1.2.1.2.2 Device Description O Yes* / No  
3.3.5.1.2.1.2.3 Device Control Type O Yes / No*  
3.3.5.1.2.1.2.4 Controller Description O Yes / No*  
3.3.5.1.2.1.2.5 Roadway Network Identifier - Device Inventory O Yes / No*  
3.3.5.1.2.1.2.6 Node Identifier - Device Inventory O Yes / No*  
3.3.5.1.2.1.2.7 Node Name - Device Inventory O Yes / No*  
3.3.5.1.2.1.2.8 Link Identifier - Device Inventory O Yes / No*  
3.3.5.1.2.1.2.9 Link Name - Device Inventory O Yes / No*  
3.3.5.1.2.1.2.10 Link Direction - Device Inventory O Yes / No*  
3.3.5.1.2.1.2.11 Linear Reference - Device Inventory O Yes / No*  
3.3.5.1.2.1.2.12 Linear Reference Version O Yes / No*  
3.3.5.1.2.1.2.13 Route Designator - Device Inventory O Yes / No*  
3.3.5.1.2.1.2.14 Device Uniform Resource Locator (URL) (DeviceURL) O Yes / No*  
3.3.5.1.2.1.2.15 Device URL Reference Medium DeviceURL:O Yes / No* / NA  
3.3.5.1.2.1.2.16 Device Inventory Date and Time Change Information O Yes / No*  
3.3.5.5.1.5 Contents of the DMS Inventory Information M Yes*  
3.3.5.5.1.5.1 Required DMS Inventory Content M Yes*  
3.3.5.5.1.5.2.1 Sign Technology O Yes / No*  
3.3.5.5.1.5.2.2 Sign Pixel Height O Yes / No*  
3.3.5.5.1.5.2.3 Sign Pixel Width O Yes / No*  
3.3.5.5.1.5.2.4 Sign Height O Yes / No*  
3.3.5.5.1.5.2.5 Sign Width O Yes / No*  
3.3.5.5.1.5.2.6 Character Pixel Height O Yes / No*  
3.3.5.5.1.5.2.7 Character Pixel Width O Yes / No*  
3.3.5.5.1.5.2.8 DMS Beacon Type O Yes / No*  
3.3.5.5.1.5.2.9 Vertical Border O Yes / No*  
3.3.5.5.1.5.2.10 Horizontal Border O Yes / No*  
3.3.5.5.1.5.2.11 Sign Vertical Pixel Pitch O Yes / No*  
3.3.5.5.1.5.2.12 Sign Horizontal Pixel Pitch O Yes / No*  
3.3.5.5.1.5.2.13 Maximum Number of Pages O Yes / No*  
3.3.5.5.1.5.2.14 Maximum Message Length O Yes / No*  
3.3.5.5.1.5.2.15 Color Scheme O Yes / No*  
3.3.5.5.1.5.2.16 MULTI Tags Supported O Yes / No*  
Error Report Message
3.3.1.4.1 Contents of the Error Report M Yes*  
3.3.1.4.1.1 Required Error Report Contents M Yes*  
3.3.1.4.1.2.1 Restrictions - Error Report O Yes / No*  

(Extended Text Description: Please note that for Table 1, the original example table had either "Yes" or "No" highlighted in each row of column Support. The higligheted items are designated with an asterisk *.)

For this example, requirement id 3.3.5.1.2.1.2.2, Device Description, is the only optional requirement that was selected for this test example. This completed NRTM can also be used to indicate the test items to be tested in a Test Design Specification.

Based on the requirements selected, Table 2 depicts the (standard) design that will fulfill each requirement according to the TMDD Standard.

 

Table 2. Example RTM

Req ID (Vol. I) Requirement Dialog DC Type Definition Class Name DC ID (Vol. II) Data Concept Instance Name
3.3.1.4.1 Contents of the Error Report   Message errorReportMsg 3.2.3.3 errorReportMsg
3.3.1.4.1.1 Required Error Report Contents   data-frame organizationInformation 3.3.16.3 organization-information
3.3.1.4.1.1 Required Error Report Contents   data-frame organizationInformation 3.3.16.3 organization-requesting
3.3.1.4.1.1 Required Error Report Contents   data-element error-report-code 3.4.3.1 error-code
3.3.1.4.1.1 Required Error Report Contents   data-element informationalText 3.4.3.2 error-text
3.3.5.1.1.1 Contents of Device Information Request   Message deviceInformationRequestMsg 3.2.5.4 deviceInformationRequestMsg
3.3.5.1.1.1.1 Required Device Information Request Content   data-frame organizationInformation 3.3.16.3 organization-information
3.3.5.1.1.1.1 Required Device Information Request Content   data-element device-type 3.4.5.15 device-type
3.3.5.1.1.1.1 Required Device Information Request Content   data-element device-information-type 3.4.5.7 device-information-type
3.3.5.1.2.1 Contents of the Device Inventory Header   data-frame deviceInventoryHeader 3.3.5.8 deviceInventoryHeader
3.3.5.1.2.1.1 Required Device Inventory Content   data-frame organizationInformation 3.3.16.3 organization-information
3.3.5.1.2.1.1 Required Device Inventory Content   data-element organization-resource-identifier 3.4.16.8 device-id
3.3.5.1.2.1.1 Required Device Inventory Content   data-frame geoLocation 3.6.9.4 device-location
3.3.5.1.2.1.1 Required Device Inventory Content   data-element organization-resource-name 3.4.16.9 device-name
3.3.5.1.2.1.2.2 Device Description   data-element organization-resource-name 3.4.16.9 device-description
3.3.5.5.1.1 Send DMS Inventory Information Upon Request 2.4.1 Dialog dlDMSInventoryRequest 3.1.6.1 dlDMSInventoryRequest
3.3.5.5.1.4 Contents of the DMS Inventory Request   Message deviceInformationRequestMsg 3.2.5.4 deviceInformationRequestMsg
3.3.5.5.1.5 Contents of the DMS Inventory Information   Message dMSInventoryMsg 3.2.6.4 dMSInventoryMsg
3.3.5.5.1.5.1 Required DMS Inventory Content   data-frame deviceInventoryHeader 3.3.5.8 device-inventory-header
3.3.5.5.1.5.1 Required DMS Inventory Content   data-element dmsSignType 3.6.3.35 dms-sign-type

 

Based on the requirements selected in Table 1, develop a Requirements to Test Case Traceability Matrix (RTCTM). An example RTCTM is shown in Table 3.

 

Table 3. Example RTCTM

Req ID (Vol. I) Requirement Test Case ID Test Case Title
3.3.1.4.1 Contents of the Error Report
    TC-Support-01 TC-ErrorReport
3.3.1.4.1.1 Required Error Report Contents
    TC-Support-01 TC-ErrorReport
3.3.5.1.1.1 Contents of Device Information Request
    TC-Device-01 TC-DevInformRequest-NoError
    TC-Device-02 TC-DevInformRequest-Error
3.3.5.1.1.1.1 Required Device Information Request Content
    TC-Device-01 TC-DevInformRequest-NoError
    TC-Device-02 TC-DevInformRequest-Error
3.3.5.1.2.1 Contents of the Device Inventory Header
    TC-Device-03 TC-DeviceInventory-NoError
    TC-Device-04 TC-DeviceInventory-Error
3.3.5.1.2.1.1 Required Device Inventory Content
    TC-Device-03 TC-DeviceInventory-NoError
    TC-Device-04 TC-DeviceInventory-Error
3.3.5.1.2.1.2.2 Device Description
    TC-Device-03 TC-DeviceInventory-NoError
    TC-Device-04 TC-DeviceInventory-Error
3.3.5.5.1.1 Send DMS Inventory Information Upon Request
    TC-DMS-01 TC-DMSInventory-NoError
    TC-DMS-02 TC-DMSInventory-Error
3.3.5.5.1.4 Contents of the DMS Inventory Request
    TC-DMS-01 TC-DMSInventory-NoError
    TC-DMS-02 TC-DMSInventory-Error
3.3.5.5.1.5 Contents of the DMS Inventory Information
    TC-DMS-01 TC-DMSInventory-NoError
    TC-DMS-02 TC-DMSInventory-Error
3.3.5.5.1.5.1 Required DMS Inventory Content
    TC-DMS-01 TC-DMSInventory-NoError
    TC-DMS-02 TC-DMSInventory-Error

 

The example RTCTM can then become part of a Test Design Specification. An example Test Design Specification is shown in Table 4.

 

Table 4. Example Test Design Specification

Test Design Specification
ID: TD-DMS-01 Title: Need to Share DMS Inventory
Approach Refinement: Automated test scripts will be used Communications configuration tables
Features to be Tested Test Identification
ID Title ID Title
3.3.1.4.1 Contents of the Error Report
    TC-Support-01 TC-ErrorReport
3.3.1.4.1.1 Required Error Report Contents
    TC-Support-01 TC-ErrorReport
3.3.5.1.1.1 Contents of Device Information Request
    TC-Device-01 TC-DevInformRequest-NoError
    TC-Device-02 TC-DevInformRequest-Error
3.3.5.1.1.1.1 Required Device Information Request Content
    TC-Device-01 TC-DevInformRequest-NoError
    TC-Device-02 TC-DevInformRequest-Error
3.3.5.1.2.1 Contents of the Device Inventory Header
    TC-Device-03 TC-DeviceInventory-NoError
    TC-Device-04 TC-DeviceInventory-Error
3.3.5.1.2.1.1 Required Device Inventory Content
    TC-Device-03 TC-DeviceInventory-NoError
    TC-Device-04 TC-DeviceInventory-Error
3.3.5.1.2.1.2.2 Device Description
    TC-Device-03 TC-DeviceInventory-NoError
    TC-Device-04 TC-DeviceInventory-Error
3.3.5.5.1.1 Send DMS Inventory Information Upon Request
    TC-DMS-01 TC-DMSInventory-NoError
    TC-DMS-02 TC-DMSInventory-Error
3.3.5.5.1.4 Contents of the DMS Inventory Request
    TC-DMS-01 TC-DMSInventory-NoError
    TC-DMS-02 TC-DMSInventory-Error
3.3.5.5.1.5 Contents of the DMS Inventory Information
    TC-DMS-01 TC-DMSInventory-NoError
    TC-DMS-02 TC-DMSInventory-Error
3.3.5.5.1.5.1 Required DMS Inventory Content
    TC-DMS-01 TC-DMSInventory-NoError
    TC-DMS-02 TC-DMSInventory-Error
Feature Pass-Fail Criteria This test design is passed if: 1) all test cases are passed; and 2) the data content of dialog responses are verified to be correct against the TMDD XML schema.

 

An example Test Case Specification is provided in Table 5.

 

Table 5. Example Test Case Specification

Test Case Specification
ID: TC-DMS-01 Title: TC-DMSInventory-NoError
Test Items
  • REQ 3.3.5.5.1.1 - Send DMS Inventory Information Upon Request
  • REQ 3.3.5.5.1.4 - Contents of the DMS Inventory Request
  • REQ 3.3.5.5.1.5 - Contents of the DMS Inventory Information
  • REQ 3.3.5.5.1.5.1 - Required DMS Inventory Content
Input Specifications TCI-DMS-01 - Need to Share DMS Inventory Inputs (No Error)
Output Specifications TCO-DMS-01 - Need to Share DMS Inventory Outputs (No Error)
Perform TPS-DMS-01
Environmental Needs No additional needs outside of those specified in the test plan
Special Procedure Requirements None
Intercase Dependencies None

 

Table 6. Example Test Procedure Specification

Test Procedure Specification
ID: TPS-DMS-01 Title: Need to Share DMS Inventory Procedures
Purpose This test procedure verifies that the dlDMSInventoryRequest dialog of an Owner Center system interface is implemented properly. It tests when a deviceInformationRequestMsg is sent to an owner center, that the owner center responds with an dMSInventoryMsg response message.
Special Requirements None
Preconditions
1. Verify that the XML Request Message is valid against Project XML Schema
2. Verify that the WSDL for the Dialog to be tested is correct
Step Test Procedure Results References
1 CONFIGURE: Determine the organization identifier, device identifier, location, name, and type of the dynamic message sign (per the Owner Center's database) being requested from the Owner Center. RECORD that information as, respectively: organization_id, dms_id, dms_location, dms_name, dms_type    
2 SETUP: Verify the deviceInformationRequestMsg inputs are:
>organization-id = "Center5"
>device-type = "dynamic-message-sign (3)"
>device-information-type = "device-inventory (1)"
Pass / Fail (Req 3.3.5.5.1.4) TCI-DMS-01 TMDD Vol. II (3.2.5.4)
3 SETUP: Start HTTP Client    
4 Load XML deviceInformationRequestMsg   TMDD Vol. II (3.2.5.4)
5 Send XML deviceInformationRequestMsg to Owner Center Pass / Fail (Req 3.3.5.5.1.1) TMDD Vol. II (3.1.6.1)
6 Receive XML dMSInventoryMsg from Owner Center Pass / Fail (Req 3.3.5.5.1.1) TMDD Vol. II (3.1.6.1) TMDD Vol. II (3.2.6.4)
7 Log XML dMSInventoryMsg from Owner Center to a file.    
8 Verify that the saved dmsInventoryMsg file validates against the TMDD XML Schema. Pass / Fail (Req 3.3.5.5.1.5)  
9 VERIFY that the XML dMSInventoryMsg contains only the following data elements, and each has a valid value:
>organization-id
>device-id
>device-location
>device-name
>dms-sign-type
Pass / Fail (Req 3.3.5.5.1.5) TCO-DMS-01 TMDD Vol. II (3.2.6.4)
10 VERIFY that the RESPONSE VALUE for organization-id is equal to organization_id. Pass / Fail (Req 3.3.5.5.1.5.1) TCO-DMS-01 TMDD Vol. II (3.3.5.8)
11 VERIFY that the RESPONSE VALUE for device-id is equal to dms_id. Pass / Fail (Req 3.3.5.5.1.5.1) TCO-DMS-01 TMDD Vol. II (3.3.5.8)
12 VERIFY that the RESPONSE VALUE for device-location is equal to dms_location. Pass / Fail (Req 3.3.5.5.1.5.1) TCO-DMS-01 TMDD Vol. II (3.3.5.8)
13 VERIFY that the RESPONSE VALUE for device-name is equal to dms_name. Pass / Fail (Req 3.3.5.5.1.5.1) TCO-DMS-01 TMDD Vol. II (3.3.5.8)
14 VERIFY that the RESPONSE VALUE for dms-sign-type is equal to dms_type. Pass / Fail (Req 3.3.5.5.1.5.1) TCO-DMS-01 TMDD Vol. II (3.6.3.35)
Test Procedure Results
Tested By:   Test Date: Pass / Fail
Test Notes:

 

2. Reference to Other Standards

 

3. Glossary

Additional descriptions/abbrs used primarily in the module.

Term Definition
Boundary Testing A test that verifies the System Under Test reacts properly to error conditions.
Requirements To Test Cases Traceability Matrix A matrix that defines the traceability from a requirements to the associated test case.
Risk A subjective estimate of the probability of an error occurring and the amount of damage that may occur as a result of the error.
Test Case Specification A document that specifies the test inputs, execution conditions, and predicted results for an item to be tested.
Test Design Specification Documentation specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests.
Test Documentation Documentation describing plans for, or results of, the testing of a system or component. Types include test case specification, test incident report, test log, test plan, test procedure, and test report.
Test Incident Report A document reporting on any event that occurs during the testing process which requires investigation.
Test Log A chronological record of relevant details about the execution of tests.
Test Plan 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.
Test Procedure Specification See Test Procedure.
Test Summary Report A document summarizing testing activities and results. It also contains an evaluation of the corresponding test items.

 

abbrs. A list of abbrs, and their definitions, used in the course materials.

ConOps Concept of Operations
INCOSE International Council On Systems Engineering
NRTM Needs to Requirements Traceability Matrix
RTCTM Requirements to Test Cases Traceability Matrix
RTM Requirements Traceability Matrix

 

4. References

Traffic Management Data Dictionary (TMDD)

Standards

Systems Engineering

 

5. Study Questions

Questions in the presentation

Question 1:

Which of the following is NOT a reason to perform testing?

  1. Develop Concept of Operations
  2. Verify requirements are fulfilled
  3. Validate the user needs are satisfied
  4. Assess a system upgrade versus the existing system

 

Question 2:

Which of the following does NOT belong in a well-written test plan?

  1. Testing Environment
  2. Testing Plan Staff Requirements
  3. Pass / Fail Criteria
  4. Sequence of Actions to be Performed

 

Question 3:

Which of the following is NOT in the TMDD Standard v03?

  1. Needs to Requirements Traceability Matrix
  2. Requirements Traceability Matrix
  3. Requirements to Test Case Traceability Matrix
  4. A single design to fulfill each requirement

 

Question 4:

Which of the following is part of the Requirements to Test Case Traceability Matrix?

  1. User Needs
  2. Requirements
  3. Design
  4. Test Plans

 

Question 5:

Which of the following is permitted by the TMDD Standard?

  1. Create a new message to fulfill a new requirement
  2. Change the meaning of an existing data element
  3. Create a new data element using an existing requirement
  4. Modify an existing dialog

 

Question 6:

Example TMDD Dialog. Please see the Extended Text Description below.

(Extended Text Description: The figure shows an Example TMDD Dialog, which is in the form of a related powerpoint slide from the powerpoint presentation. This slide contains the following text:

Learning Objective #6

Example TMDD Dialog

3.1.37.2 dlVideoSwitchStatusUpdate

3.1.37.2.1 PRE CONDITIONS

An owner center shall provide updates to an external center upon acceptance of a dlDevicelnformationSubscription dialog.

3.1.37.2.2 DIALOG REFERENCE

See Clause 2.4.3 Generic Publication Update Dialog

3.1.37.2.3 ASN.1 REPRESENTATION

dlVideoSwitchStatusUpdate ITS-INTERFACE-DIALOGUE {

DESCRIPTIVE-NAME "OwnerCenter<-DlVideoSwitchStatusUpdate->ExternalCenter"

ASN-NAME "DlVideoSwitchStatusUpdate"

ASN-OBJECT-IDENTIFIER { tmddDialogs 122 }

URL "Pub.gif"

DEFINITION "A publication dialog that allows an owner center to provide status updates to an external center on the owner center's video switches."

DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}

ARCHITECTURE-REFERENCE { "emergency traffic control information",
"device status",
"field equipment status" }

ARCHITECTURE-NAME {"U.S. National ITS Architecture"}

ARCHITECTURE-VERSION {"7.0"} DATA-CONCEPT-TYPE interface-dialogue

STANDARD "TMDD"

REFERENCED-MESSAGES {
{ tmddMessages 85 }, -- videoSwitchStatusMsg (Input Message)
{ c2cMessages c2cMessageReceipt(1) }, --c2cMessageReceipt (Output Message)
{ tmddMessages 10 } -- errorReportMsg (Fault Message)}

Additional descriptive notes: Please note that on the example graphical slide, there are two red ovals encircling the first five lines of text starting with 3.1.37.2 and the bottom four lines of text starting with REFERENCED-MESSAGES.)

Which of the following is not an appropriate test step for the previous dialog?

  1. The Owner Center sends the videoSwitchStatusMsg to the External Center
  2. Pre-condition to execute the dlDeviceInformationSubscription dialog
  3. The External Center sends a c2cMessageReceipt message to the Owner Center
  4. The External Center sends a deviceInformationRequestMsg to the Owner Center