**Intelligent Transportation Systems/**

**Commercial Vehicle Operations**

**(ITS/CVO)**

**Interoperability Test Suite Package**

**Part 1: Test Specifications**

**POR-98-7122 V1.0**

**Baseline Version**

**July 2001**

Provide comments to:

Mary W. Stuart, JHU/APL

Phone: 240-228-7001

Fax: 240-228-6149

Mary.Stuart@jhuapl.edu

**NOTE**

The Motor Carrier Safety Improvement Act was signed into law on
December 9, 1999. This act established a new FMCSA within the US DOT,
effective January 1, 2000. Prior to that, the motor carrier and highway
safety program was administered under the Federal Highway Administration
(FHWA).

The mission of the FMCSA is to improve truck and commercial passenger
carrier safety on our nation's highways through information technology,
targeted enforcement, research and technology, outreach, and
partnerships. The FMCSA manages the ITS/Commercial Vehicle Operations
(CVO) Program, a voluntary effort involving public and private
partnerships that uses information systems, innovative technologies, and
business practice reengineering to improve safety, simplify government
administrative systems, and provide savings to states and motor
carriers. The FMCSA works closely with the FHWA's ITS JPO to ensure the
integration and interoperability of ITS/CVO systems with the national
ITS program.

**This is a Baseline Issue**

This document has completed internal and external reviews of previously
published drafts and preliminary versions. All comments received to date
have been incorporated or addressed.

Note: This document and other CVISN-related documentation are available
for review and downloading by the ITS/CVO community from the JHU/APL
CVISN site on the World Wide Web. All updates to this document will be
maintained and published on that site; hardcopies of future versions
will not normally be distributed. The URL for the CVISN site is:
<http://www.jhuapl.edu/cvisn/>

Additional review and comments to this document are welcome.

> Ms. Mary W. Stuart
>
> The Johns Hopkins University
>
> Applied Physics Laboratory
>
> 11100 Johns Hopkins Road
>
> Laurel, MD 20723-6099
>
> Phone: 443-778- 7001
>
> Fax: 443-778-6149
>
> Email: <Mary.Stuart@jhuapl.edu>

**Intelligent Transportation Systems / Commercial Vehicle Operations
(ITS/CVO)**

**Interoperability Test Suite Package**

**Part 1: Test Specifications**

Table of Contents

[Introduction v](#introduction)

[1. Credentials Administration Pairwise Interface Tests
1--5](#credentials-administration-pairwise-interface-tests)

[1.1 Carrier -- State (e.g., CAT -- CI) Electronic Credentialing
1--5](#carrier-state-e.g.-cat-ci-electronic-credentialing)

[1.1.1 Scenario ID PW-Cred-01: IRP; Add Vehicle
1--5](#scenario-id-pw-cred-01-irp-add-vehicle)

[1.1.2 Scenario ID PW-Cred-02: IFTA Renewal
1--5](#scenario-id-pw-cred-02-ifta-renewal)

[1.1.3 Scenario ID PW-Cred-03: IFTA Quarterly Tax Filing
1--5](#scenario-id-pw-cred-03-ifta-quarterly-tax-filing)

[2. Roadside Electronic Screening Pairwise Interface Tests
2--5](#roadside-electronic-screening-pairwise-interface-tests)

[2.1 Vehicle -- Roadside Scenarios 2--5](#vehicle-roadside-scenarios)

[2.1.1 Scenario ID PW-Scr-01: Type II Transponder, ASTM Version 6
Compatible, Transponder ID Only
2--5](#scenario-id-pw-scr-01-type-ii-transponder-astm-version-6-compatible-transponder-id-only)

[2.1.2 Scenario ID PW-Scr-02: Type III Transponder, ASTM Version 6
Compatible, Transponder ID Only
2--5](#scenario-id-pw-scr-02-type-iii-transponder-astm-version-6-compatible-transponder-id-only)

[2.1.3 Scenario ID PW-Scr-03: Type IIIm Transponder, ASTM Version 6
Compatible, Transponder ID Only
2--5](#scenario-id-pw-scr-03-type-iiim-transponder-astm-version-6-compatible-transponder-id-only)

[2.1.4 Scenario ID PW-Scr-04: Type IIIm Transponder, ASTM Version 6
Compatible, IEEE CMV Electronic Screening Identification Message
2--5](#scenario-id-pw-scr-04-type-iiim-transponder-astm-version-6-compatible-ieee-cmv-electronic-screening-identification-message)

[3. Safety Information Exchange Pairwise Interface Tests
3--5](#safety-information-exchange-pairwise-interface-tests)

[3.1 State Deskside -- APL SAFER (e.g., CVIEW or equivalent -- APL
SAFER) Snapshot Scenarios
3--5](#state-deskside-apl-safer-e.g.-cview-or-equivalent-apl-safer-snapshot-scenarios)

[3.1.1 Scenario ID PW-Safe-01: CVIEW Sends a Vehicle Snapshot Segment
Update to APL SAFER (IRP Supplemental: Add Vehicle)
3--5](#scenario-id-pw-safe-01-cview-sends-a-vehicle-snapshot-segment-update-to-apl-safer-irp-supplemental-add-vehicle)

[3.1.2 Scenario ID PW-Safe-08: CVIEW Receives Subscription Update for
Vehicle Snapshots via APL SAFER for an Out-of-Service (OOS) Vehicle
3--5](#scenario-id-pw-safe-08-cview-receives-subscription-update-for-vehicle-snapshots-via-apl-safer-for-an-out-of-service-oos-vehicle)

[3.1.3 Scenario ID PW-Safe-04: CVIEW Receives Subscription Update for
Carrier Snapshots via APL SAFER
3--5](#scenario-id-pw-safe-04-cview-receives-subscription-update-for-carrier-snapshots-via-apl-safer)

[3.1.4 Scenario ID PW-Safe-05: CVIEW Sends Subscription Update for
Carrier Snapshots to APL SAFER
3--5](#scenario-id-pw-safe-05-cview-sends-subscription-update-for-carrier-snapshots-to-apl-safer)

[3.1.5 Scenario ID PW-Safe-06: CVIEW Sends a TS 285 Query for a Carrier
Snapshot to APL SAFER
3--5](#scenario-id-pw-safe-06-cview-sends-a-ts-285-query-for-a-carrier-snapshot-to-apl-safer)

[3.1.6 Scenario ID PW-Safe-07: CVIEW Sends a TS 285 Query for a Vehicle
Snapshot to APL SAFER
3--5](#scenario-id-pw-safe-07-cview-sends-a-ts-285-query-for-a-vehicle-snapshot-to-apl-safer)

[3.2 State Roadside -- CVIEW (e.g., Roadside Operations -- CVIEW)
Snapshot Scenarios
3--5](#state-roadside-cview-e.g.-roadside-operations-cview-snapshot-scenarios)

[3.2.1 Scenario ID PW-Safe-02: Roadside Operations System Sends a
Request for a Vehicle Snapshot to CVIEW using a Vehicle Identification
Number (VIN)
3--5](#scenario-id-pw-safe-02-roadside-operations-system-sends-a-request-for-a-vehicle-snapshot-to-cview-using-a-vehicle-identification-number-vin)

[3.3 State Roadside -- APL SAFER (e.g., ASPEN - APL SAFER) Snapshot
Scenarios
3--5](#state-roadside-apl-safer-e.g.-aspen---apl-safer-snapshot-scenarios)

[3.3.1 Scenario ID PW-Safe-15: ASPEN Sends a Request for a Carrier
Snapshot to APL SAFER
3--5](#scenario-id-pw-safe-15-aspen-sends-a-request-for-a-carrier-snapshot-to-apl-safer)

[3.4 State Roadside -- APL SAFER (e.g., ASPEN - APL SAFER) Inspection
Scenarios
3--5](#state-roadside-apl-safer-e.g.-aspen---apl-safer-inspection-scenarios)

[3.4.1 Scenario ID PW-Safe-09: ASPEN Sends Inspection Reports to APL
SAFER (CIA)
3--5](#scenario-id-pw-safe-09-aspen-sends-inspection-reports-to-apl-safer-cia)

[3.4.2 Scenario ID PW-Safe-14: ASPEN Sends a Request for an Inspection
Report to APL SAFER (CIA)
3--5](#scenario-id-pw-safe-14-aspen-sends-a-request-for-an-inspection-report-to-apl-safer-cia)

[3.5 State Roadside to CVIEW (i.e., ASPEN to CVIEW) Snapshot Scenarios
3--5](#state-roadside-to-cview-i.e.-aspen-to-cview-snapshot-scenarios)

[3.5.1 Scenario ID PW-Safe-03: CVIEW Receives Request for a Carrier
Snapshot from ASPEN (CIA)
3--5](#scenario-id-pw-safe-03-cview-receives-request-for-a-carrier-snapshot-from-aspen-cia)

[4. End-to-End Interface Tests 4--5](#end-to-end-interface-tests)

[4.1 Scenario ID ETE--01: Carrier Adds Vehicle (IRP Supplemental)
4--5](#scenario-id-ete01-carrier-adds-vehicle-irp-supplemental)

[4.2 Scenario ID ETE--02: Vehicle Inspected and Placed Out-Of-Service
4--5](#scenario-id-ete02-vehicle-inspected-and-placed-out-of-service)

[4.3 Scenario ID ETE--03: Screening an Interstate Vehicle
4--5](#scenario-id-ete03-screening-an-interstate-vehicle)

[4.4 Scenario ID ETE-04: Carrier Adds Jurisdiction (IRP Supplemental)
4--5](#scenario-id-ete-04-carrier-adds-jurisdiction-irp-supplemental)

[4.5 Scenario ID ETE-05: Carrier Renews IRP Credential
4--5](#scenario-id-ete-05-carrier-renews-irp-credential)

[4.6 Scenario ID ETE-06: Carrier Renews IFTA Credential
4--5](#scenario-id-ete-06-carrier-renews-ifta-credential)

[4.7 Scenario ID ETE-07: Carrier Submits IFTA Quarterly Tax Filing
4--5](#scenario-id-ete-07-carrier-submits-ifta-quarterly-tax-filing)

[4.8 Scenario ID ETE-08: ASPEN Requests Inspection Report from SAFER via
CVIEW
4--5](#scenario-id-ete-08-aspen-requests-inspection-report-from-safer-via-cview)

[4.9 Scenario ID ETE-09: ASPEN Sends Inspection Report to SAFER via
CVIEW
4--5](#scenario-id-ete-09-aspen-sends-inspection-report-to-safer-via-cview)

[4.10 Scenario ID ETE-10: ASPEN Requests Carrier Snapshot from SAFER via
CVIEW
4--5](#scenario-id-ete-10-aspen-requests-carrier-snapshot-from-safer-via-cview)

[4.11 Scenario ID ETE-11: Carrier Adds More Than One Vehicle (IRP
Supplemental)
4--5](#scenario-id-ete-11-carrier-adds-more-than-one-vehicle-irp-supplemental)

[5. Web-Based Credential End-to-End Interface Tests
5--5](#web-based-credential-end-to-end-interface-tests)

[5.1 Scenario ID WETE-01: Carrier Adds Vehicle (IRP Supplemental)
5--5](#scenario-id-wete-01-carrier-adds-vehicle-irp-supplemental)

[5.2 Scenario ID WETE-04: Carrier Adds Jurisdiction (IRP Supplemental)
5--5](#scenario-id-wete-04-carrier-adds-jurisdiction-irp-supplemental)

[5.3 Scenario ID WETE-05: Carrier Renews IRP Credential
5--5](#scenario-id-wete-05-carrier-renews-irp-credential)

[5.4 Scenario ID WETE-06: Carrier Renews IFTA Credential
5--5](#scenario-id-wete-06-carrier-renews-ifta-credential)

[5.5 Scenario ID WETE-07: Carrier Submits IFTA Quarterly Tax Filing
5--5](#scenario-id-wete-07-carrier-submits-ifta-quarterly-tax-filing)

[5.6 Scenario ID WETE-11: Carrier Adds More Than One Vehicle (IRP
Supplemental)
5--5](#scenario-id-wete-11-carrier-adds-more-than-one-vehicle-irp-supplemental)

[6. References 6--5](#references)

[7. CVISN Change Request Form 7--5](#cvisn-change-request-form)

# Introduction {#introduction .unnumbered}

Intelligent Transportation Systems/Commercial Vehicle Operations
(ITS/CVO) interoperability testing is planned to:

-   Verify that interfaces between selected pairs of deployed
    products/systems meet the applicable standards (pairwise interface
    testing), and

-   Verify dataflow and data usage among several selected
    products/systems (end-to-end interface testing).

This ITS/CVO Interoperability Test Suite Package defines the
interoperability test specifications, test cases and procedures, test
tools, and the test data. This document provides specifications for the
interoperability tests. There are multiple pairwise tests specified for
each functional area: credentials administration, electronic screening,
and safety information exchange. There are multiple end-to-end tests
that include all three functional areas.

The test suite package is updated periodically to provide material to
support successive stages of CVISN development. Four additional
end-to-end tests have been added to this version of the document, as
well as a section to support Web-based credential applications. An
additional pairwise test in the safety area was included to support
ASPEN-CVIEW exchanges.

It is important to note that the safety information exchange pairwise
interface tests contain the EDI Transaction Set (TS) 824 Application
Advice. The TS 824 capability will be available with APL SAFER/CVIEW
version 3.0. Additional end-to-end tests for alternative interfaces may
be developed and released in future versions of the interoperability
test documentation.

![](media/image1.wmf){width="4.682638888888889in"
height="3.501388888888889in"}

***Interoperability Test Suite Package Structure***

This package is divided into several parts:

Part 1 -- Test Specifications

Part 2 -- Test Cases and Procedures

Part 3 -- Test Tool Description

Part 4 -- Test Data

Test criteria are defined in the COACH Part 5, Interoperability Test
Criteria.

The Interoperability Test Suite Package Part 1, Test Specifications
defines the test environment and test scenarios for ITS/CVO
interoperability testing. A test scenario is a high-level description of
the function to be tested.

The Interoperability Test Suite Package Part 2, Test Cases and
Procedures defines the test cases, specific test configurations, and
procedures for each test scenario identified in Part 1. One or more test
cases are defined for each scenario. COACH Part 5 relates the test
cases/configurations to the test criteria. Each case uses a different
set of data from the test database and/or different test conditions.
There is one procedure for each test case.

The Interoperability Test Suite Package Part 3, Test Tool Description
defines the tools available to support the tests. Tool descriptions are
or will be provided by those who develop the tools.

The Interoperability Test Suite Package Part 4, Test Data describes the
test data for ITS/CVO interoperability testing. The test data is
organized in a Microsoft Access 2000 Database, with data records keyed
to the test cases defined in Part 2 of the Test Suite Package. This part
of the Test Suite Package will describe the database tables, data
relations, and how to extract data for a particular test case. Data will
be delivered to users in MS Access form, on removable media (e.g.,
CD-ROM, Iomega Zip disk). Users will be required to have Microsoft
Access 2000 installed on an Intel processor-based system in order to use
the data. This set of test data supports the test procedures as written.
This data must be tailored by the user as required, if test procedures
are modified to support variations in system design.

Throughout this set of documents a generic CVISN design is used to
describe the tests. Individual states may design their systems
differently, even to the extent that different products are involved in
information exchanges. If that is the case, the test scenarios,
descriptions and procedures as stated in these documents may need to be
tailored to a different set of products. For instance, the tests include
steps in which CVIEW updates interstate vehicle snapshots in SAFER. If a
state chooses to have IRP segments of the vehicle snapshot updated by
the state IRP product, then the steps stated herein should be applied to
the interaction between the IRP product and SAFER for that function.

***Interoperability Test Suite Package, Part 1 Description***

This part defines the test environment and test scenarios for ITS/CVO
interoperability testing. A test scenario is a high-level description of
the function to be tested. Pairwise test scenarios are grouped according
to functional areas (credentials administration, electronic screening,
safety information exchange). End-to-end scenarios may involve more than
one functional area.

For each group of scenarios, the following descriptive information is
provided:

-   Objectives

-   Test environments

```{=html}
<!-- -->
```
-   Items under test

-   General configurations (test sites, facilities)

-   Participants and roles

For each scenario, the following descriptive information is provided:

-   Test identifier and name

-   Test items

-   Function being demonstrated

-   Sequencing

-   Data recording and evaluation

This issue provides the test specification for tests defined in the
Interoperability Test Suite Package Part 2, dated July 2001. The
companion parts of the test suite package describe other aspects of
these tests. Additional end-to-end tests may be developed and documented
in a future release of the interoperability test documentation.

The following is a list of tests that have been added to the test suite
package since the last update.

Safety Information Exchange Pairwise Interface Test:

Scenario ID PW-Safe-03: CVIEW Receives a request for Carrier Snapshot
from ASPEN (CIA)

End-to-End Interface Tests:

4.8 Scenario ID ETE-08: ASPEN Requests Inspection Report from SAFER via
CVIEW

4.9 Scenario ID ETE-09: ASPEN Sends Inspection Report to SAFER via CVIEW

4.10 Scenario ID ETE-10: ASPEN Requests Carrier Snapshot form SAFER via
CVIEW

4.11 Scenario ID ETE-11: Carrier Adds More than One Vehicle (IRP
Supplemental)

End-to-End Interface Tests for Web-based Credential Applications

5.1 Scenario ID WETE-01: Carrier Adds Vehicle(IRP Supplemental)

5.2 Scenario ID WETE-04: Carrier Adds Jurisdiction

5.3 Scenario ID WETE-05: Carrier Renews IRP Credential

5.4 Scenario ID WETE-06: Carrier Renews IFTA Credential

5.5 Scenario ID WETE-07: Carrier Submits IFTA Quarterly Tax Filing

5.6 Scenario ID WETE-11: Carrier Adds More Than One Vehicle (IRP
Supplemental)

# Credentials Administration Pairwise Interface Tests

The test scenarios that follow represent a subset of the various
credentials that can be issued electronically. In addition, IFTA fuel
tax filing is included here as one of the credentials administration
processes although it is not actually a credential application.
Recognizing the growth of the World Wide Web for business applications,
scenarios for web-based testing are included as Chapter 5 of this
document as additional end-to-end scenarios.

#### Objectives: {#objectives .TestSuite_Objective .unnumbered}

In these tests, the focus is on the application of the ASC X12 EDI
standards (151, 286, 813, and 997) that support credentials
administration functions.

#### Test Environments: {#test-environments .TestSuite_Objective .unnumbered}

-   Items under test. The tests could be used in several ways:

```{=html}
<!-- -->
```
-   To check that the carrier's system (e.g., CAT, fleet administrative
    products, etc.) interacts correctly with a simulated state system
    for electronic credentialing. The simulation is "dumb"; i.e., it
    will only provide interface transactions, not the normal processing
    of inputs from the carrier.

-   To check that the state's system (e.g., the CI) interacts correctly
    with a simulated carrier system for electronic credentialing. The
    simulation is "dumb"; i.e., it will only provide interface
    transactions, not the normal processing of inputs from the state.

-   To check that the carrier's system interacts correctly with the
    state's system for electronic credentialing.

-   \[similar purposes related to clearinghouse interactions to be added
    in a later revision\]

> These tests focus on the information exchanges between state and
> carrier systems.

-   General configurations (test sites, facilities):

```{=html}
<!-- -->
```
-   This section describes the configurations envisioned for the initial
    credentials administration tests. When additional tests are
    identified, more configurations may be added. The tests will be
    executed from the state and/or carrier sites. In initial pairwise
    interface testing, it is possible for the APL CVISN Test Facility to
    act as one end of the interface, simulating either the carrier or
    state system, depending on which items are under test.

> For the most part, tests will be evaluated using normal data access
> mechanisms. For example, when a credentialing test is conducted, the
> state personnel will use their standard procedures and tools to access
> the carrier's application inputs.

-   Participants and roles:

```{=html}
<!-- -->
```
-   State and/or carrier personnel or their designees will execute the
    tests. APL will provide test support for tests in which the APL test
    facility is used, as required.

Figure 1--1 illustrates the initial pairwise interface test
configuration in which the carrier system is under test, and the APL
CVISN test facility simulates the state system.

![](media/image2.wmf){width="4.163194444444445in"
height="3.1194444444444445in"}

Figure 1--1.  Carrier System Under Test

Figure 1--2 illustrates the initial pairwise interface test
configuration in which the state system is under test, and the APL CVISN
test facility simulates the carrier system.

![](media/image3.wmf){width="4.154166666666667in"
height="3.1131944444444444in"}

Figure 1--2.  State System Under Test

Figure 1--3 illustrates the configuration in which the carrier and state
interact to verify operational interfaces.

![](media/image4.wmf){width="4.125694444444444in"
height="3.1694444444444443in"}

Figure 1--3.  Carrier and State Systems Under Test

## Carrier -- State (e.g., CAT -- CI) Electronic Credentialing

### Scenario ID PW-Cred-01: IRP; Add Vehicle 

#### Test items: {#test-items .TestSuite_Objective .unnumbered}

In this scenario, the carrier system (e.g., CAT) and state IRP-related
products (e.g., CI) are the test items.

#### Function being demonstrated: {#function-being-demonstrated .TestSuite_Objective .unnumbered}

In this scenario, a carrier adds one or more vehicles to an existing
valid IRP account. The carrier pays by check. The carrier is authorized
to print its own credentials, and does so.

#### Sequencing: {#sequencing .TestSuite_Objective .unnumbered}

General data flow:

1.  Carrier transmits TS 286 Supplemental Application to state.

2.  State acknowledges receipt of TS 286 via TS 997.

3.  State evaluates the supplemental application (not part of test when
    state is simulated).

4.  State sends invoice information to the carrier via TS 286 Invoice
    Notice.

5.  Carrier acknowledges receipt of TS 286 via TS 997.

6.  Carrier pays by check (not part of test that is evaluated) and tells
    state via 286 Payment Information.

7.  State acknowledges receipt of TS 286 via TS 997.

8.  State receives payment (not part of test that is evaluated) and
    processes credential (not part of test when state is simulated).

9.  State sends cab card information (credential) to carrier via TS 286
    Credential Return.

10. Carrier acknowledges receipt of TS 286 via TS 997.

11. Carrier prints cab card (not part of test that is evaluated).

#### Data recording and evaluation: {#data-recording-and-evaluation .TestSuite_Objective .unnumbered}

The EDI transactions will be processed normally by the receiving and
sending systems. Post-test analysis will involve looking at the results
of the interchanges using normal user-access tools and verifying that
every field contains the correct value in the correct format. In
addition, EDI transactions will be recorded by both the sender and
receiver. If necessary, post-test analysis may also involve viewing the
contents of the transactions using special tools.

### Scenario ID PW-Cred-02: IFTA Renewal

#### Test items: {#test-items-1 .TestSuite_Objective .unnumbered}

In this scenario, the carrier system (e.g. CAT) and state IFTA-related
products (e.g., CI) are the test items.

#### Function being demonstrated: {#function-being-demonstrated-1 .TestSuite_Objective .unnumbered}

In this scenario, the state initiates the renewal process by sending the
IFTA credential information it has on hand to the registrant. The
registrant updates the information. The carrier pays electronically.

#### Sequencing: {#sequencing-1 .TestSuite_Objective .unnumbered}

General data flow:

1.  State transmits TS 286 Renewal Notice to carrier.

2.  Carrier acknowledges receipt of TS 286 via TS 997.

3.  Carrier updates information and transmits 286 Renewal Application to
    state.

4.  State acknowledges receipt of TS 286 via TS 997.

5.  State evaluates the application (not part of test when state is
    being simulated).

6.  Carrier initiates electronic payment and tells the state via TS 286
    Payment Information.

7.  State acknowledges receipt of TS 286 via TS 997.

8.  State receives payment, acknowledges same to bank (or other payer),
    and processes credential (not part of test that is evaluated).

9.  State sends credential to carrier via TS 286 Credential Return.

10. Carrier acknowledges receipt of TS 286 via TS 997.

11. State prints credential and mails to carrier (not part of test that
    is evaluated).

#### Data recording and evaluation: {#data-recording-and-evaluation-1 .TestSuite_Objective .unnumbered}

The EDI transactions will be processed normally by the receiving and
sending systems. Post-test analysis will involve looking at the results
of the interchanges, using normal user-access tools and verifying that
every field contains the correct value in the correct format. In
addition, EDI transactions will be recorded by both the sender and
receiver. If necessary, post-test analysis may also involve viewing the
contents of the transactions using special tools.

### Scenario ID PW-Cred-03: IFTA Quarterly Tax Filing

#### Test items: {#test-items-2 .TestSuite_Objective .unnumbered}

In this scenario, the carrier system (e.g. CAT) and state IFTA tax
related products (e.g., CI) are the test items.

#### Function being demonstrated: {#function-being-demonstrated-2 .TestSuite_Objective .unnumbered}

The carrier transmits the tax filing to the state. The carrier enters
the tax filing information and submits it to the CI as a TS 813.

#### Sequencing: {#sequencing-2 .TestSuite_Objective .unnumbered}

General data flow:

1.  Carrier transmits TS 813, Electronic Filing of Tax Return Data, to
    state.

2.  Carrier initiates electronic payment(not part of test that is
    evaluated).

3.  State acknowledges receipt of TS 813, via TS 997 and TS 151.

4.  State CI evaluates the filing (not part of test when state is being
    simulated).

5.  State CI forwards tax filing and payment information to legacy
    system.

6.  CI routes the return TS 151 message from the legacy system to the
    carrier CAT.

#### Data recording and evaluation: {#data-recording-and-evaluation-2 .TestSuite_Objective .unnumbered}

The EDI transactions will be processed normally by the receiving and
sending systems. Post-test analysis will involve looking at the results
of the interchanges, using normal user-access tools and verifying that
every field contains the correct value in the correct format. In
addition, EDI transactions will be recorded by both the sender and
receiver. If necessary, post-test analysis may also involve viewing the
contents of the transactions using special tools.

# Roadside Electronic Screening Pairwise Interface Tests

#### Objectives: {#objectives-1 .TestSuite_Objective .unnumbered}

In these tests, the focus is on the application of the IEEE message and
ASTM hardware standards that support vehicle-roadside dedicated
short-range communications (DSRC) electronic screening functions.

#### Test Environments: {#test-environments-1 .TestSuite_Objective .unnumbered}

-   Items under test. The tests could be used in several ways:

```{=html}
<!-- -->
```
-   To check that the state's roadside CV check facility (e.g., the
    combination of the reader, other sensors, screening, and roadside
    operations products) provides the correct external interface with a
    variety of transponders.

-   To check that the state's roadside CV check facility interacts
    correctly with a variety of vehicle transponders.

> These tests focus on the information exchanges between state roadside
> reader and vehicle transponder products. The on-board and roadside
> screening/roadside operations products are used to control test data
> and evaluate test results.

-   General configurations (test sites, facilities):

```{=html}
<!-- -->
```
-   The tests will be executed at the state commercial vehicle check
    stations. For the most part, tests will be evaluated using normal
    data access mechanisms. For example, when a DSRC test is conducted,
    the evaluation will involve looking at the information extracted
    from the transponder by the roadside operational computer.

```{=html}
<!-- -->
```
-   Participants and roles:

```{=html}
<!-- -->
```
-   The tests will be executed by state, transponder vendor, and/or
    carrier personnel, or their designees. APL will provide test support
    for tests in which the APL test facility is used, as required.

Figure 2--1 illustrates the initial pairwise interface test
configuration for electronic screening. This configuration applies
either when the state commercial vehicle check station is under test or
when the transponder and the check station interact to verify
operational interfaces

![](media/image5.wmf){width="5.579861111111111in" height="4.19375in"}

Figure 2--4.  CV Check Facility or Interactions Between Tag and Facility

## Vehicle -- Roadside Scenarios 

### Scenario ID PW-Scr-01: Type II Transponder, ASTM Version 6 Compatible, Transponder ID Only

#### Test items: {#test-items-3 .TestSuite_Objective .unnumbered}

In this scenario, a Type II transponder and the state commercial vehicle
check station are the test items.

#### Function being demonstrated: {#function-being-demonstrated-3 .TestSuite_Objective .unnumbered}

Type II transponders permit no memory write access from the external
port. So, in this scenario, only the transponder ID can be used for
screening.

#### Sequencing: {#sequencing-3 .TestSuite_Objective .unnumbered}

General data flow:

1.  Reader initiates interaction with transponder.

2.  Transponder responds with ID.

3.  Vehicle measures are made (not part of test that is evaluated).

4.  Tag ID is matched to vehicle/carrier snapshots (not part of test
    that is evaluated).

5.  Screening decision is made (not part of test that is evaluated).

6.  Reader sends transponder the signal that indicates bypass or
    pull-in.

#### Data recording and evaluation: {#data-recording-and-evaluation-3 .TestSuite_Objective .unnumbered}

DSRC messages will be recorded by both the sender and receiver.
Post-test analysis will involve viewing the contents of the messages
using normal user-access tools, or special test tools such as TagTalk
and ReaderTalk, and verifying that every field contains the correct
value in the correct format. For a description of TagTalk, ReaderTalk,
and other test tools, refer to Part 3 of the Interoperability Test Suite
Package.

### Scenario ID PW-Scr-02: Type III Transponder, ASTM Version 6 Compatible, Transponder ID Only

#### Test items: {#test-items-4 .TestSuite_Objective .unnumbered}

In this scenario, a Type III transponder and the state commercial
vehicle check station are the test items.

#### Function being demonstrated: {#function-being-demonstrated-4 .TestSuite_Objective .unnumbered}

Type III transponders permit no memory write access from the external
port. So, in this scenario, only the transponder ID can be used for
screening.

#### Sequencing: {#sequencing-4 .TestSuite_Objective .unnumbered}

General data flow:

1.  Reader initiates interaction with transponder.

2.  Transponder responds with ID.

3.  Vehicle measures are made (not part of test that is evaluated).

4.  Tag ID is matched to vehicle/carrier snapshots (not part of test
    that is evaluated).

5.  Screening decision is made (not part of test that is evaluated).

6.  Reader sends transponder the signal that indicates bypass or
    pull-in.

#### Data recording and evaluation: {#data-recording-and-evaluation-4 .TestSuite_Objective .unnumbered}

DSRC messages will be recorded by both the sender and receiver.
Post-test analysis will involve viewing the contents of the messages
using normal user-access tools, or special test tools such as TagTalk
and ReaderTalk, and verifying that every field contains the correct
value in the correct format. For a description of TagTalk, ReaderTalk,
and other test tools, refer to Part 3 of the Interoperability Test Suite
Package.

### Scenario ID PW-Scr-03: Type IIIm Transponder, ASTM Version 6 Compatible, Transponder ID Only

#### Test items: {#test-items-5 .TestSuite_Objective .unnumbered}

In this scenario, a Type IIIm transponder and the state commercial
vehicle check station are the test items.

#### Function being demonstrated: {#function-being-demonstrated-5 .TestSuite_Objective .unnumbered}

Type IIIm transponders support memory write access from the external
port, but not all screening programs plan to use that capability. So, in
this scenario, only the transponder ID will be used for screening.

#### Sequencing: {#sequencing-5 .TestSuite_Objective .unnumbered}

General data flow:

1.  Reader initiates interaction with transponder.

2.  Transponder responds with ID.

3.  Vehicle measures are made (not part of test that is evaluated).

4.  Tag ID is matched to vehicle/carrier snapshots (not part of test
    that is evaluated).

5.  Screening decision is made (not part of test that is evaluated).

6.  Reader sends transponder the signal that indicates bypass or
    pull-in.

#### Data recording and evaluation: {#data-recording-and-evaluation-5 .TestSuite_Objective .unnumbered}

DSRC messages will be recorded by both the sender and receiver.
Post-test analysis will involve viewing the contents of the messages
using normal user-access tools, or special test tools such as TagTalk
and ReaderTalk, and verifying that every field contains the correct
value in the correct format. For a description of TagTalk, ReaderTalk,
and other test tools, refer to Part 3 of the Interoperability Test Suite
Package.

### Scenario ID PW-Scr-04: Type IIIm Transponder, ASTM Version 6 Compatible, IEEE CMV Electronic Screening Identification Message

#### Test items: {#test-items-6 .TestSuite_Objective .unnumbered}

In this scenario, a Type IIIm transponder and the state commercial
vehicle check station are the test items.

#### Function being demonstrated: {#function-being-demonstrated-6 .TestSuite_Objective .unnumbered}

Type IIIm transponders permit memory write access from the external
port. So, in this scenario, the carrier and vehicle IDs can be used for
screening. These transponders do not contain sufficient memory to accept
the CMV screening event message, so the results of screening are simply
reflected in the command set sent back to the tag. Unlike the other
scenarios in this set of tests, this scenario is not a required CVISN
Level 1 test.

#### Sequencing: {#sequencing-6 .TestSuite_Objective .unnumbered}

General data flow:

1.  Reader initiates interaction with the transponder.

2.  Transponder responds with ID and CMV screening identification
    message.

3.  Vehicle measures are made (not part of test that is evaluated).

4.  Tag ID or carrier and vehicle IDs are matched to vehicle/carrier
    snapshots (not part of test that is evaluated).

5.  Screening decision is made (not part of test that is evaluated).

6.  Reader sends transponder the signal that indicates bypass or
    pull-in.

#### Data recording and evaluation: {#data-recording-and-evaluation-6 .TestSuite_Objective .unnumbered}

DSRC messages will be recorded by both the sender and receiver.
Post-test analysis will involve viewing the contents of the messages
using normal user-access tools, or special test tools such as TagTalk
and ReaderTalk, and verifying that every field contains the correct
value in the correct format. For a description of TagTalk, ReaderTalk,
and other test tools, refer to Part 3 of the Interoperability Test Suite
Package.

# Safety Information Exchange Pairwise Interface Tests

#### Objectives: {#objectives-2 .TestSuite_Objective .unnumbered}

In these tests, the focus is on the application of the ASC X12 EDI
standards Transaction Sets (285, 824, and 997) that support safety
information exchange functions.

#### Test Environments: {#test-environments-2 .TestSuite_Objective .unnumbered}

-   Items under test. The tests could be used in several ways:

```{=html}
<!-- -->
```
-   To check that the state's CVIEW (or equivalent) interacts correctly
    with APL test SAFER.

-   To check that the state's CVIEW (or equivalent) interacts correctly
    with Roadside Operations System at various sites.

-   To check that ASPEN units interact correctly with APL test SAFER
    system.

> These tests focus on the information exchanges between the state
> systems, and on information exchanges between the state systems and
> CVISN core infrastructure systems.

-   General configurations (test sites, facilities):

```{=html}
<!-- -->
```
-   This section describes the configurations envisioned for the initial
    safety information exchange tests. When additional tests are
    identified, more configurations may be also. The tests may be
    conducted with a CVISN core infrastructure system emulation (to
    protect the CVISN core infrastructure system's database) or with the
    real CVISN core infrastructure system. The tests will be executed
    from the states. For the most part, tests will be evaluated using
    normal data access mechanisms.

```{=html}
<!-- -->
```
-   Participants and roles:

```{=html}
<!-- -->
```
-   The tests will be executed by state and/or CVISN Core Infrastructure
    system personnel, or their designees. APL will provide test support
    for tests in which the APL CVISN test facility is used, as required.
    The "APL test system" in the CVISN test facility provides a test
    SAFER or a test CVIEW as needed in various test scenarios.

Figure 3--1 illustrates the initial pairwise interface test
configuration in which a state system (e.g., CVIEW) is under test, and
the APL test system emulates the production SAFER CVISN core
infrastructure system.

![](media/image6.wmf){width="5.000694444444444in"
height="3.2756944444444445in"}

Figure 3--5.  State System (CVIEW) and APL SAFER

Figure 3--2 illustrates the initial pairwise interface test
configuration in which a state system (e.g., ASPEN) is under test, and
the APL test system emulates the SAFER CVISN core infrastructure system.

![](media/image7.wmf){width="4.531944444444444in"
height="3.4722222222222223in"}

Figure 3--6.  State System (ASPEN) and APL SAFER

Figure 3--3 illustrates the initial pairwise interface test
configuration in which a state system (i.e., ROC) is under test, and the
APL test system emulates the state's CVIEW.

![](media/image8.wmf){width="5.277777777777778in"
height="3.682638888888889in"}

Figure 3--7.  State System (ROC) and APL SAFER

## State Deskside -- APL SAFER (e.g., CVIEW or equivalent -- APL SAFER) Snapshot Scenarios

### Scenario ID PW-Safe-01: CVIEW Sends a Vehicle Snapshot Segment Update to APL SAFER (IRP Supplemental: Add Vehicle)

#### Test items: {#test-items-7 .TestSuite_Objective .unnumbered}

In this scenario, the State CVIEW System or equivalent that supplies
snapshot segment updates to APL SAFER is the test item.

#### Function being demonstrated: {#function-being-demonstrated-7 .TestSuite_Objective .unnumbered}

In this scenario, CVIEW proactively sends an updated vehicle snapshot
segment, with IRP credential information, to APL SAFER data mailbox on
CVIEW. APL SAFER retrieves the snapshot and updates the appropriate
database record.

#### Sequencing: {#sequencing-7 .TestSuite_Objective .unnumbered}

General data flow:

1.  CVIEW receives (via a test tool) and processes a snapshot segment
    update.

2.  CVIEW sends snapshot to SAFER data mailbox on CVIEW.

3.  The APL SAFER System polls its mailbox on the CVIEW and determines
    it has new mail (the TS 285 EDI) in its mailbox.

4.  APL SAFER acknowledges successful interpretation of TS 285 contents
    via TS 824.

5.  APL SAFER updates its local database with the IRP snapshot segment
    update.

6.  CVIEW acknowledges receipt of TS 824 via TS 997.

#### Data recording and evaluation: {#data-recording-and-evaluation-7 .TestSuite_Objective .unnumbered}

There will be a manual and electronic log of events, and post-test
comparison of appropriate messages with steps in procedures. A summary
list of successful steps prior to failure will be reviewed. The Analyst
will examine the EDI messages using a mail tool, i.e., Eudora Light Mail
Client, to examine the APL SAFER Mailbox.

### Scenario ID PW-Safe-08: CVIEW Receives Subscription Update for Vehicle Snapshots via APL SAFER for an Out-of-Service (OOS) Vehicle 

#### Test items: {#test-items-8 .TestSuite_Objective .unnumbered}

In this scenario, the State CVIEW System or equivalent that receives
snapshot segment updates from APL SAFER is the test item.

#### Function being demonstrated: {#function-being-demonstrated-8 .TestSuite_Objective .unnumbered}

In this scenario, the APL SAFER System sends a vehicle snapshot segment
update, containing OOS inspection information to the State CVIEW System.

#### Sequencing: {#sequencing-8 .TestSuite_Objective .unnumbered}

General data flow:

1.  An OOS Vehicle Inspection report is sent to APL SAFER (the mail
    message that contains the OOS Inspection Report should be
    transferred to the proper directory in APL SAFER).

2.  APL SAFER processes the OOS Vehicle Inspection Report.

3.  APL SAFER sends a TS 285 (vehicle snapshot segment update) to the
    CVIEW system.

4.  CVIEW acknowledges receipt of TS 285 via a TS 824.

5.  CVIEW receives the segment update and updates its database.

#### Data recording and evaluation: {#data-recording-and-evaluation-8 .TestSuite_Objective .unnumbered}

There will be a manual and electronic log of events, and post-test
comparison of appropriate messages with steps in procedures. A summary
list of successful steps prior to failure will be reviewed. The Analyst
will examine the EDI messages using a mail tool, i.e., Eudora Light Mail
Client, to examine the CVIEW Mailbox.

### Scenario ID PW-Safe-04: CVIEW Receives Subscription Update for Carrier Snapshots via APL SAFER

#### Test items: {#test-items-9 .TestSuite_Objective .unnumbered}

In this scenario, the State CVIEW System or equivalent that receives
carrier snapshot update from APL SAFER is the test item.

#### Function being demonstrated: {#function-being-demonstrated-9 .TestSuite_Objective .unnumbered}

In this scenario, the APL SAFER System sends a carrier snapshot segment
update to the State CVIEW System.

#### Sequencing: {#sequencing-9 .TestSuite_Objective .unnumbered}

General data flow:

1.  A carrier snapshot is placed in the APL SAFER System (the mail
    message that contains the carrier snapshot should be transferred to
    the proper directory in APL SAFER).

2.  APL SAFER processes the carrier snapshot.

3.  APL SAFER sends a TS 285 (carrier snapshot) to the CVIEW system.

4.  CVIEW acknowledges receipt of TS 285 via TS 824.

5.  CVIEW receives the carrier snapshot and updates its database.

#### Data recording and evaluation: {#data-recording-and-evaluation-9 .TestSuite_Objective .unnumbered}

There will be a manual and electronic log of events, and post-test
comparison of appropriate messages with steps in procedures. A summary
list of successful steps prior to failure will be reviewed. The Analyst
will examine the EDI messages using a mail tool, i.e., Eudora Light Mail
Client, to examine the CVIEW Mailbox.

### Scenario ID PW-Safe-05: CVIEW Sends Subscription Update for Carrier Snapshots to APL SAFER

#### Test items: {#test-items-10 .TestSuite_Objective .unnumbered}

In this scenario, the State CVIEW System or equivalent that sends the
carrier vehicle snapshot update to APL SAFER is the test item.

#### Function being demonstrated: {#function-being-demonstrated-10 .TestSuite_Objective .unnumbered}

In this scenario, the APL SAFER System receives a carrier snapshot
segment update from the State CVIEW System.

#### Sequencing: {#sequencing-10 .TestSuite_Objective .unnumbered}

General data flow:

1.  CVIEW receives (via a test tool) and processes a snapshot segment
    update.

2.  CVIEW sends snapshot to SAFER data mailbox on CVIEW.

3.  The APL SAFER System polls its mailbox on the CVIEW and determines
    it has new mail (the TS 285 EDI) in its mailbox.

4.  APL SAFER acknowledges successful interpretation of TS 285 contents
    via TS 824.

5.  APL SAFER updates its local database with the IRP snapshot segment
    update.

6.  CVIEW acknowledges receipt of TS 824 via TS 997.

#### Data recording and evaluation: {#data-recording-and-evaluation-10 .TestSuite_Objective .unnumbered}

There will be a manual and electronic log of events, and post-test
comparison of appropriate messages with steps in procedures. A summary
list of successful steps prior to failure will be reviewed. The Analyst
will examine the EDI messages using a mail tool, i.e., Eudora Light Mail
Client, to examine the CVIEW Mailbox.

### Scenario ID PW-Safe-06: CVIEW Sends a TS 285 Query for a Carrier Snapshot to APL SAFER

#### Test items: {#test-items-11 .TestSuite_Objective .unnumbered}

In this scenario, the State CVIEW System or equivalent that queries the
APL SAFER System for a carrier snapshot and receives the carrier
snapshot is the test item.

#### Function being demonstrated: {#function-being-demonstrated-11 .TestSuite_Objective .unnumbered}

In this scenario, the State CVIEW System sends a query to the APL SAFER
System for a carrier snapshot and receives the requested snapshot from
the APL SAFER System.

#### Sequencing: {#sequencing-11 .TestSuite_Objective .unnumbered}

General data flow:

1.  The State CVIEW queries the APL SAFER System for a TS 285 carrier
    snapshot.

2.  The APL SAFER System receives the query and processes the request.

3.  The APL SAFER System sends the requested TS-285 carrier snapshot to
    the State CVIEW.

4.  CVIEW acknowledges receipt of TS 285 via TS 997.

5.  The State CVIEW receives the requested TS 285 carrier snapshot from
    the APL SAFER System.

#### Data recording and evaluation: {#data-recording-and-evaluation-11 .TestSuite_Objective .unnumbered}

There will be a manual and electronic log of events, and post-test
comparison of appropriate messages with steps in procedures. A summary
list of successful steps prior to failure will be reviewed. The Analyst
will examine the EDI messages using a mail tool, i.e., Eudora Light Mail
Client, to examine the CVIEW Mailbox.

### Scenario ID PW-Safe-07: CVIEW Sends a TS 285 Query for a Vehicle Snapshot to APL SAFER

#### Test items: {#test-items-12 .TestSuite_Objective .unnumbered}

In this scenario, the State CVIEW System or equivalent that queries the
APL SAFER System for a vehicle snapshot and receives the vehicle
snapshot is the test item.

#### Function being demonstrated: {#function-being-demonstrated-12 .TestSuite_Objective .unnumbered}

In this scenario, the State CVIEW System sends a query to the APL SAFER
System for a vehicle snapshot and receives the requested snapshot from
the APL SAFER System.

#### Sequencing: {#sequencing-12 .TestSuite_Objective .unnumbered}

General data flow:

1.  The State CVIEW queries the APL SAFER System for a TS 285 vehicle
    snapshot.

2.  The APL SAFER System receives the query and processes the request.

3.  The APL SAFER System sends the requested TS 285 vehicle snapshot to
    the State CVIEW.

4.  CVIEW acknowledges receipt of TS 285 via TS 997.

5.  The State CVIEW receives the requested TS 285 vehicle snapshot from
    the APL SAFER System.

#### Data recording and evaluation: {#data-recording-and-evaluation-12 .TestSuite_Objective .unnumbered}

There will be a manual and electronic log of events, and post-test
comparison of appropriate messages with steps in procedures. A summary
list of successful steps prior to failure will be reviewed. The Analyst
will examine the EDI messages using a mail tool, i.e., Eudora Light Mail
Client, to examine the CVIEW Mailbox.

## State Roadside -- CVIEW (e.g., Roadside Operations -- CVIEW) Snapshot Scenarios

### Scenario ID PW-Safe-02: Roadside Operations System Sends a Request for a Vehicle Snapshot to CVIEW using a Vehicle Identification Number (VIN) 

#### Test items: {#test-items-13 .TestSuite_Objective .unnumbered}

In this scenario, the Roadside Operations System that receives snapshot
segment updates from the State CVIEW System is the test item.

#### Function being demonstrated: {#function-being-demonstrated-13 .TestSuite_Objective .unnumbered}

In this scenario, the Roadside Operations System submits a request
(query) for a vehicle snapshot to CVIEW and receives the vehicle
snapshot.

#### Sequencing: {#sequencing-13 .TestSuite_Objective .unnumbered}

General data flow:

1.  The Roadside Operations System submits a query for a vehicle
    snapshot to the State CVIEW via TS 285, using the VIN to identify
    the vehicle.

2.  CVIEW sends the vehicle snapshot to the Roadside Operations System
    via TS 285.

3.  The Roadside Operations System acknowledges receipt of TS 285 via TS
    997.

#### Data recording and evaluation: {#data-recording-and-evaluation-13 .TestSuite_Objective .unnumbered}

There will be a manual and electronic log of events, and post-test
comparison of appropriate messages with steps in procedures. A summary
list of successful steps prior to failure will be reviewed. The Analyst
will examine the EDI messages using a mail tool, i.e., Eudora Light Mail
Client, to examine the CVIEW Mailbox.

## State Roadside -- APL SAFER (e.g., ASPEN - APL SAFER) Snapshot Scenarios

### Scenario ID PW-Safe-15: ASPEN Sends a Request for a Carrier Snapshot to APL SAFER 

#### Test items: {#test-items-14 .TestSuite_Objective .unnumbered}

In this scenario, the State ASPEN System that requests carrier snapshots
from the State APL SAFER System is the test item.

#### Function being demonstrated: {#function-being-demonstrated-14 .TestSuite_Objective .unnumbered}

In this scenario, ASPEN submits a request (query) via CIA to APL SAFER
for a carrier snapshot and receives the carrier snapshot as a result of
the query.

#### Sequencing: {#sequencing-14 .TestSuite_Objective .unnumbered}

General data flow:

1.  ASPEN submits a query to APL SAFER for a carrier snapshot via CIA.

2.  APL SAFER sends the carrier snapshot to ASPEN via CIA.

3.  ASPEN displays the carrier snapshot that was queried.

#### Data recording and evaluation: {#data-recording-and-evaluation-14 .TestSuite_Objective .unnumbered}

There will be a manual and electronic logging of events and post-test
analysis of message content. A summary list of successful steps prior to
failure will be reviewed.

## State Roadside -- APL SAFER (e.g., ASPEN - APL SAFER) Inspection Scenarios

### Scenario ID PW-Safe-09: ASPEN Sends Inspection Reports to APL SAFER (CIA)

#### Test items: {#test-items-15 .TestSuite_Objective .unnumbered}

In this scenario, the state roadside product (ASPEN or equivalent) that
sends the roadside inspection reports to APL SAFER is the test item.

#### Function being demonstrated: {#function-being-demonstrated-15 .TestSuite_Objective .unnumbered}

In this scenario, ASPEN sends an inspection report to APL SAFER. ASPEN
uses the Past Inspection Query (PIQ) to verify the inspection report was
received by APL SAFER.

#### Sequencing: {#sequencing-15 .TestSuite_Objective .unnumbered}

General data flow:

1.  ASPEN sends an inspection report to APL SAFER.

2.  ASPEN performs a PIQ to validate the inspection report.

#### Data recording and evaluation: {#data-recording-and-evaluation-15 .TestSuite_Objective .unnumbered}

There will be a manual and electronic log of events, and post-test
comparison of appropriate messages with steps in procedures. A summary
list of successful steps prior to failure will be reviewed.

### Scenario ID PW-Safe-14: ASPEN Sends a Request for an Inspection Report to APL SAFER (CIA)

#### Test items: {#test-items-16 .TestSuite_Objective .unnumbered}

In this scenario, the state roadside product (ASPEN or equivalent) that
sends an inspection report request to the APL SAFER System is the test
item.

#### Function being demonstrated: {#function-being-demonstrated-16 .TestSuite_Objective .unnumbered}

In this scenario, ASPEN sends an inspection report request to APL SAFER.

#### Sequencing: {#sequencing-16 .TestSuite_Objective .unnumbered}

General data flow:

1.  ASPEN sends a request for an inspection report to the APL SAFER
    System.

2.  APL SAFER sends the report to ASPEN.

3.  ASPEN displays the inspection report.

#### Data recording and evaluation: {#data-recording-and-evaluation-16 .TestSuite_Objective .unnumbered}

There will be a manual and electronic log of events, and post-test
comparison of appropriate messages with steps in procedures. A summary
list of successful steps prior to failure will be reviewed.

## State Roadside to CVIEW (i.e., ASPEN to CVIEW) Snapshot Scenarios

### Scenario ID PW-Safe-03: CVIEW Receives Request for a Carrier Snapshot from ASPEN (CIA)

#### Test items: {#test-items-17 .TestSuite_Objective .unnumbered}

In this scenario, the State ASPEN System is the test item; it requests
carrier snapshots from the State CVIEW System.

#### Function being demonstrated: {#function-being-demonstrated-17 .TestSuite_Objective .unnumbered}

In this scenario, ASPEN submits a request (query) via CIA to CVIEW for a
carrier snapshot and receives the carrier snapshot as a result of the
query.

#### Sequencing: {#sequencing-17 .TestSuite_Objective .unnumbered}

General data flow:

1.  ASPEN submits a query to CVIEW for a carrier snapshot via CIA.

2.  CVIEW sends the carrier snapshot to ASPEN via CIA.

3.  ASPEN displays the carrier snapshot that was queried.

#### Data recording and evaluation: {#data-recording-and-evaluation-17 .TestSuite_Objective .unnumbered}

There will be a manual and electronic logging of events and post-test
analysis of message content. A summary list of successful steps prior to
failure will be reviewed.

# End-to-End Interface Tests

#### Objectives: {#objectives-3 .TestSuite_Objective .unnumbered}

The objective of end-to-end interface testing is to ensure the systems
involved in a particular process are fully interoperable and meet
functional design requirements. The end-to-end test is used to verify
and evaluate the operational effectiveness of the system provided to the
users, for the purpose of performing a specific task, i.e., placing a
vehicle out-of-service in one state and providing that information to
all of the other states that the vehicle operates in. The following test
scenarios are written with the intent of providing a test that is
specific in function, but general in method, and is applicable in states
that may have varying degrees of physical architecture.

The end-to-end test scenarios cover a wide range of functions. The
threads being tested involve more than two products. A complete thread
may be verified in multiple steps. End-to-End tests for Web-based
electronic credential processes are provided in Chapter 5 of this
document.

#### Test Environments: {#test-environments-3 .TestSuite_Objective .unnumbered}

-   Items under test. The end-to-end test scenarios will be used to
    verify that the following real systems will interoperate:

```{=html}
<!-- -->
```
-   The Carrier's Electronic Credentialing System and the State
    Commercial Vehicle (CV) Administration

-   CV Administration and the State CVIEW System

-   The State CVIEW System and APL SAFER

-   The State CVIEW System and Roadside Operations

-   Roadside Operations and Screening System

```{=html}
<!-- -->
```
-   General configurations (test sites, facilities):

```{=html}
<!-- -->
```
-   The test will be executed from the carrier, state, and CVISN core
    infrastructure sites. The APL CVISN Test Facility is not expected to
    be involved in end-to-end tests, except to provide test data and to
    provide emulation for the production SAFER System. For the most
    part, tests will be evaluated using normal data access mechanisms.
    For example, when a test is conducted requiring state personnel to
    perform a credentials check, they will use their standard procedures
    and tools to access the carrier's application inputs.

```{=html}
<!-- -->
```
-   Participants and roles:

```{=html}
<!-- -->
```
-   Carrier, state, and CVISN core infrastructure personnel, or their
    designees will execute the tests. APL will provide test data, which
    may be tailored as needed by the state.

## Scenario ID ETE--01: Carrier Adds Vehicle (IRP Supplemental)

#### Test items: {#test-items-18 .TestSuite_Objective .unnumbered}

In this scenario, test data is verified by the carrier and at the State
CVIEW, APL SAFER, and Roadside Systems. The following test data are used
as test items throughout the test:

+--------------------------------+-------------------------------------+
| -   Identification             | -   Credentials                     |
+--------------------------------+-------------------------------------+
| -   VIN                        | -   USDOT Number                    |
+--------------------------------+-------------------------------------+
| -   Plate                      | -   IRP Account Number              |
+--------------------------------+-------------------------------------+
| -   State                      | -   IRP Base State                  |
+--------------------------------+-------------------------------------+

#### Functions being demonstrated: {#functions-being-demonstrated .TestSuite_Objective .unnumbered}

The test scenario is initiated when the carrier submits an IRP
Supplemental "Add Vehicle" application to the CV Administration. The CV
Administration will send an invoice notice to the carrier. A credential
will be sent to the carrier after payment information is provided by the
carrier. The CV Administration will provide the updated vehicle
information to the State CVIEW. The State CVIEW will then send the
information to APL SAFER and the state's Roadside Operations. The
functions are considered successful when the proper data transfer and
update is verified at the carrier, State CVIEW, APL SAFER, and Roadside
Operations, by checking the test items.

#### Sequencing: {#sequencing-18 .TestSuite_Objective .unnumbered}

General Data Flow: Carrier submits an IRP Supplemental "Add Vehicle"
application to the CV Administration.

1.  The carrier submits an IRP Supplemental Application for adding a
    vehicle and receives an Invoice Notice from the CV Administration.

2.  The CV Administration receives payment information and sends the
    credential to the carrier.

3.  The CV Administration sends a vehicle snapshot segment update to the
    State CVIEW System.

4.  The State CVIEW System sends a vehicle snapshot segment update to
    the APL SAFER System.

5.  The State CVIEW System sends a vehicle snapshot to the Roadside
    Operations System.

#### Data recording and evaluation: {#data-recording-and-evaluation-18 .TestSuite_Objective .unnumbered}

Using messages, databases, and displayed screens, the test analyst
verifies successful receipt and update of information resulting from the
submission of an IRP Supplemental application by the carrier. Post-test
analysis involves comparing the appropriate database updates to the test
items.

Figure 4--1 illustrates the end-to-end interoperability test for
scenario ETE--01: Carrier Adds Vehicle: (IRP Supplemental).

![](media/image9.wmf){width="5.997222222222222in"
height="4.2659722222222225in"}

Figure 4--8.  Carrier Adds Vehicle

## Scenario ID ETE--02: Vehicle Inspected and Placed Out-Of-Service

#### Test items: {#test-items-19 .TestSuite_Objective .unnumbered}

In this scenario, an Enforcement Officer at the inspection site enters
the vehicle's State and Plate to request the past inspection report. The
test data (OOS flag) entered by the Enforcement Officer during the
inspection is verified at the roadside, via a vehicle snapshot. The
following test data are used as test items:

+---------------------------------+------------------------------------+
| -   Identification              | -   Inspection                     |
+---------------------------------+------------------------------------+
| -   USDOT Number                | -   OOS Flag                       |
+---------------------------------+------------------------------------+
| -   VIN                         | -   OOS Order / Report ID          |
+---------------------------------+------------------------------------+
| -   Vehicle Plate / State       | -   OOS Violation Code             |
+---------------------------------+------------------------------------+

#### Functions being demonstrated: {#functions-being-demonstrated-1 .TestSuite_Objective .unnumbered}

The test scenario is initiated when the Enforcement Officer queries the
APL SAFER System for the vehicle's past inspection report. The Officer
conducts the inspection using the ASPEN system or equivalent, and places
the vehicle OOS. The Inspection Report is sent to the APL SAFER System.
APL SAFER updates its database and sends a vehicle snapshot segment
update to the State CVIEW System. The State CVIEW System sends an
updated vehicle snapshot to the Roadside Operations System. The
functions are considered successful when the proper data transfer and
update is verified at the Roadside Operations System, by checking the
test items.

#### Sequencing: {#sequencing-19 .TestSuite_Objective .unnumbered}

General Data Flow:

1.  Roadside personnel (Enforcement Officer) queries APL SAFER for the
    vehicle's past inspection report.

2.  The APL SAFER System sends the past inspection report that matches
    the query, to the Enforcement Officer.

3.  The inspection is performed and the vehicle is placed OOS.

4.  The inspection report is sent to the APL SAFER System.

5.  APL SAFER updates its database and sends a vehicle snapshot segment
    update to the State CVIEW System.

6.  The State CVIEW System sends updated vehicle snapshot data to the
    Roadside Operations System.

#### Data recording and evaluation: {#data-recording-and-evaluation-19 .TestSuite_Objective .unnumbered}

The messages, databases, and displayed screens will show the successful
receipt and update of information resulting from the vehicle OOS
inspection at the roadside. Post-test analysis involves comparing the
appropriate database updates to the test items.

Figure 4--2 illustrates the end-to-end interoperability test for
scenario ETE‑02: Vehicle Inspected and Placed Out-Of-Service (OOS).

![](media/image10.wmf){width="5.997222222222222in"
height="4.063888888888889in"}

Figure 4--9.  Vehicle Inspected and Placed Out-Of-Service (OOS)

## Scenario ID ETE--03: Screening an Interstate Vehicle

#### Test items: {#test-items-20 .TestSuite_Objective .unnumbered}

In this scenario, the Roadside Operations System receives carrier and
vehicle snapshots via the subscription process on SAFER and CVIEW, and
the snapshot data are used for screening a vehicle. The following test
data are used as test items:

+-----------------------------------+-----------------------------------+
| [[Carrier                         | [[Vehicle                         |
| S                                 | S                                 |
| napshot]{.underline}]{.smallcaps} | napshot]{.underline}]{.smallcaps} |
+-----------------------------------+-----------------------------------+
| -   Identification                | -   Identification                |
+-----------------------------------+-----------------------------------+
| -   USDOT Number                  | -   VIN                           |
+-----------------------------------+-----------------------------------+
| -   Carrier Name                  | -   Transponder ID                |
+-----------------------------------+-----------------------------------+
| -   Credentials                   | -   Credentials                   |
+-----------------------------------+-----------------------------------+
| -   IFTA Check Flag               | -   IRP Check Flag                |
+-----------------------------------+-----------------------------------+
| -   IFTA Account Number           | -   IRP Account Number            |
+-----------------------------------+-----------------------------------+
| -   IFTA Base Jurisdiction        | -   IRP Base State                |
+-----------------------------------+-----------------------------------+
| -   Safety                        | -   Inspection                    |
+-----------------------------------+-----------------------------------+
| -   SafeStat Score                | -   OOS Flag                      |
+-----------------------------------+-----------------------------------+

#### Functions being demonstrated: {#functions-being-demonstrated-2 .TestSuite_Objective .unnumbered}

This scenario uses three test cases to verify the following screening
decisions: 1) a successful "Bypass", with no failed checks; 2) a
"Pull-In" due to a failed carrier check, e.g., IFTA Check Flag; and 3) a
"Pull-In" due to a failed vehicle check, e.g., OOS Flag. APL SAFER
fulfills a subscription to CVIEW and CVIEW forwards the snapshots to the
roadside. The Roadside Operations System updates its database and
calculates screening values based on selected screening criteria, and
sends the screening values to the screening system. A vehicle equipped
with a transponder proceeds through the CV check station. The screening
system reads the transponder ID and screens the vehicle. A screening
decision is made and the vehicle receives a "Bypass" or "Pull-In" signal
from the screening system.

#### Sequencing: {#sequencing-20 .TestSuite_Objective .unnumbered}

General Data Flow:

1.  APL SAFER operator inputs test snapshot to CVIEW subscription
    mailbox, and CVIEW connects to APL SAFER and downloads snapshots
    from its subscription mailbox.

2.  The CVIEW System receives and passes the snapshots to Roadside
    Operations via subscription.

3.  Roadside receives the snapshots, updates its database, and sends
    screening values to the screening system.

4.  The vehicle's transponder ID is read by the screening system.

5.  A screening decision, i.e., "Bypass" or "Pull-In", is made and
    displayed to the vehicle operator.

6.  The screening results are displayed at the Roadside Operations
    System.

#### Data recording and evaluation: {#data-recording-and-evaluation-20 .TestSuite_Objective .unnumbered}

Examination of the Roadside Operations System database and displayed
screens will show the successful receipt and update of the vehicle
snapshot and receipt of the screening results. Post-test analysis
involves comparing the appropriate database updates to the test items.

Figure 4--3 illustrates the end-to-end interoperability test for
scenario ETE‑03: Screening An Interstate Vehicle.

![](media/image11.wmf){width="6.0784722222222225in"
height="4.183333333333334in"}

Figure 4--10.  Screening An Interstate Vehicle

## Scenario ID ETE-04: Carrier Adds Jurisdiction (IRP Supplemental)

#### Test items: {#test-items-21 .TestSuite_Objective .unnumbered}

In this scenario, test data is verified by the carrier and at the State
CVIEW, APL SAFER, and Roadside Systems, and if applicable, the IRP
Clearinghouse. The following test data are used as test items throughout
the test:

+------------------------+-----------------------+---------------------+
| -   Identification     | -   Credentials       | -   Registration    |
|                        |                       |     Information     |
+------------------------+-----------------------+---------------------+
| -   VIN                | -   USDOT Number      | -   DBA Name        |
+------------------------+-----------------------+---------------------+
| -   License Plate      | -   IRP Account       | -   Owner Name      |
|     Number             |     Number            |                     |
+------------------------+-----------------------+---------------------+
| -   License Plate      | -   IRP Base State    | -   Address         |
|     State              |                       |                     |
+------------------------+-----------------------+---------------------+
|                        | -   Jurisdictions and |                     |
|                        |     Weights           |                     |
+------------------------+-----------------------+---------------------+

#### Functions being demonstrated: {#functions-being-demonstrated-3 .TestSuite_Objective .unnumbered}

The test scenario is initiated when the carrier submits an IRP
Supplemental "Add Jurisdiction" application to the CV Administration
(two vehicles must be verified in this test, therefore, an application
must be submitted that will change the credentials for two vehicles
within the same fleet). The CV Administration processes the application
and sends an invoice notice to the carrier. The carrier sends payment
information and receives the credential from the CV Administration. The
CV Administration sends the updated information to the State CVIEW
system. The State CVIEW System sends the updated information to the APL
SAFER System and Roadside Operations System. The functions are
considered successful when the proper data transfer and update is
verified at the carrier, State CVIEW, APL SAFER, and Roadside
Operations, by checking the test items.

#### Sequencing: {#sequencing-21 .TestSuite_Objective .unnumbered}

General Data Flow:

1.  The carrier submits an IRP Supplemental Application for adding a
    jurisdiction and receives an Invoice Notice from the CV
    Administration. The carrier also sends payment information to the CV
    Administration.

2.  The CV Administration receives payment information and sends a
    credential for both vehicles to the carrier.

3.  The CV Administration sends a snapshot segment update to the State
    CVIEW System.

4.  The State CVIEW System sends a snapshot segment update to the APL
    SAFER System.

5.  The State CVIEW System sends a vehicle snapshot to the Roadside
    Operations System.

#### Data recording and evaluation: {#data-recording-and-evaluation-21 .TestSuite_Objective .unnumbered}

Using messages, databases, and displayed screens, the test analyst
verifies successful receipt and update of information resulting from the
submission of an IRP Supplemental application by the carrier. Post-test
analysis involves comparing the appropriate database updates to the test
items.

Figure 4--4 illustrates the end-to-end interoperability test for
scenario ETE‑04: Carrier Adds Jurisdiction: (IRP Supplemental).

![](media/image12.wmf){width="5.997222222222222in"
height="4.447916666666667in"}

Figure 4--11.  Carrier Adds Jurisdiction

## Scenario ID ETE-05: Carrier Renews IRP Credential

#### Test items: {#test-items-22 .TestSuite_Objective .unnumbered}

In this scenario, test data is verified by the carrier and at the State
CVIEW, APL SAFER, and if applicable, the IRP Clearinghouse. The
following test data are used as test items throughout the test:

+------------------------+-----------------------+---------------------+
| -   Identification     | -   Credentials       | -   Registration    |
|                        |                       |     Information     |
+------------------------+-----------------------+---------------------+
| -   VIN                | -   USDOT Number      | -   DBA Name        |
+------------------------+-----------------------+---------------------+
| -   License Plate      | -   IRP Account       | -   Owner Name      |
|     Number             |     Number            |                     |
+------------------------+-----------------------+---------------------+
| -   License Plate      | -   IRP Base State    | -   Address         |
|     State              |                       |                     |
+------------------------+-----------------------+---------------------+
|                        | -   Jurisdictions and |                     |
|                        |     Weights           |                     |
+------------------------+-----------------------+---------------------+
|                        | -   Registration      |                     |
|                        |     Expiration Date   |                     |
+------------------------+-----------------------+---------------------+

#### Functions being demonstrated: {#functions-being-demonstrated-4 .TestSuite_Objective .unnumbered}

The test scenario is initiated when the carrier receives an IRP Renewal
reminder from the CV Administration. The carrier then submits the
renewal application to the CV Administration using their Electronic
Credential System. The CV Administration will send an invoice notice to
the carrier. A credential will be sent to the carrier after payment
information is provided by the carrier. The CV Administration will
provide the updated vehicle information to the State CVIEW. The State
CVIEW will then send the information to APL SAFER. The functions are
considered successful when the proper data transfer and update is
verified at the carrier, State CVIEW, APL SAFER, by checking the test
items.

#### Sequencing: {#sequencing-22 .TestSuite_Objective .unnumbered}

General Data Flow:

1.  The CV Administration sends a renewal reminder to the carrier.

2.  The carrier submits the IRP Renewal Application to the CV
    Administration and receives an invoice notice back.

3.  The carrier sends payment information to the CV Administration and
    receives the IRP Credential.

4.  The CV Administration sends a vehicle snapshot segment update to the
    State CVIEW System.

5.  The State CVIEW System sends a vehicle snapshot segment update to
    the APL SAFER System and roadside operations system.

#### Data recording and evaluation: {#data-recording-and-evaluation-22 .TestSuite_Objective .unnumbered}

Using messages, databases, and displayed screens, the test analyst
verifies successful receipt and update of information resulting from the
submission of an IRP Supplemental application by the carrier. Post-test
analysis involves comparing the appropriate database updates to the test
items.

Figure 4--5 illustrates the end-to-end interoperability test for
scenario ETE‑05: Carrier Renews IRP Credential.

![](media/image13.wmf){width="5.997222222222222in"
height="4.442361111111111in"}

Figure 4--12.  Carrier Renews IRP Credential

## Scenario ID ETE-06: Carrier Renews IFTA Credential

#### Test items: {#test-items-23 .TestSuite_Objective .unnumbered}

In this scenario, test data is verified by the carrier and at the State
CVIEW, APL SAFER, Roadside Operations, ASPEN, and if applicable, the
IFTA Clearinghouse. The following test data are used as test items
throughout the test:

+-------------------------------------+--------------------------------+
| -   Credentials                     | -   Registration Information   |
+-------------------------------------+--------------------------------+
| -   USDOT Number                    | -   Contact Name               |
+-------------------------------------+--------------------------------+
| -   IFTA Account Number             | -   Address                    |
+-------------------------------------+--------------------------------+
| -   IFTA Base State                 |                                |
+-------------------------------------+--------------------------------+
| -   Jurisdictions                   |                                |
+-------------------------------------+--------------------------------+
| -   Expiration Date                 |                                |
+-------------------------------------+--------------------------------+

#### Functions being demonstrated: {#functions-being-demonstrated-5 .TestSuite_Objective .unnumbered}

The test scenario is initiated when the carrier receives an IFTA renewal
reminder from the CV Administration. The carrier then submits the
renewal application to the CV Administration using their Electronic
Credential System. The carrier sends payment information to the CV
Administration. If applicable, the CV Administration queries the IFTA
Clearinghouse for the carrier's account status. The CV Administration
validates the carrier's application and sends the credential to the
carrier. The CV Administration will send a snapshot segment update to
the State CVIEW. The State CVIEW will then send the information to APL
SAFER. The State CVIEW System sends snapshot information to the Roadside
Operations System. ASPEN queries either the APL SAFER System or the
State CVIEW System, depending on the version of ASPEN the state uses.
The functions are considered successful when the proper data transfer
and update is verified at the carrier, State CVIEW, APL SAFER, Roadside
System, ASPEN, and if applicable, the IFTA Clearinghouse, by checking
the test items.

#### Sequencing: {#sequencing-23 .TestSuite_Objective .unnumbered}

General Data Flow:

1.  The CV Administration sends a renewal reminder to the carrier.

2.  If applicable, The CV Administration queries the IFTA Clearinghouse
    for the carrier's account status.

3.  If applicable, the IFTA Clearinghouse sends the status back to the
    CV Administration.

4.  The carrier submits the IFTA Renewal Application to the CV
    Administration.

5.  The carrier sends payment information to the CV Administration.

6.  The CV Administration accepts/validates the carrier's application
    and sends the credential to the carrier.

7.  The CV Administration sends a snapshot segment update to the State
    CVIEW System.

8.  The State CVIEW System sends a snapshot segment update to the APL
    SAFER System.

9.  The State CVIEW System sends the updated snapshot to the Roadside
    Operations System.

10. ASPEN queries CVIEW or SAFER for the carrier snapshot which should
    reflect the update.

#### Data recording and evaluation: {#data-recording-and-evaluation-23 .TestSuite_Objective .unnumbered}

Using messages, databases, and displayed screens, the test analyst
verifies successful receipt and update of information resulting from the
submission of an IFTA Renewal application by the carrier. Post-test
analysis involves comparing the appropriate database updates to the test
items.

Figure 4--6 illustrates the end-to-end interoperability test for
scenario ETE‑06: Carrier Renews IFTA Credential.

![](media/image14.wmf){width="5.997222222222222in"
height="4.483333333333333in"}

Figure 4--13.  Carrier Renews IFTA Credential

## Scenario ID ETE-07: Carrier Submits IFTA Quarterly Tax Filing

#### Test items: {#test-items-24 .TestSuite_Objective .unnumbered}

In this scenario, test data is verified by the carrier and at the State
CVIEW, APL SAFER, Roadside Operations, and ASPEN. The following test
data are used as test items throughout the test:

+------------------------------------+---------------------------------+
| -   Credentials                    | -   Registration Information    |
+------------------------------------+---------------------------------+
| -   USDOT Number                   | -   Contact Name                |
+------------------------------------+---------------------------------+
| -   IFTA Account Number            | -   Address                     |
+------------------------------------+---------------------------------+
| -   IFTA Base State                |                                 |
+------------------------------------+---------------------------------+
| -   Jurisdictions                  |                                 |
+------------------------------------+---------------------------------+

#### Functions being demonstrated: {#functions-being-demonstrated-6 .TestSuite_Objective .unnumbered}

The test scenario may be initiated when the carrier receives an IFTA Tax
Filing Notification from the CV Administration. The carrier either
receives the tax rate tables automatically or has to request the tables
from the CV Administration. The CV Administration may store the tables
in their own system or request the tables from IFTA Inc. when required.
The carrier submits the tax filing to the CV Administration using their
Electronic Credentialing System. The CV Administration sends a Tax
Filing Acceptance Notification to the carrier. The CV Administration
sends a snapshot segment update to the State CVIEW. The State CVIEW will
then send the information to APL SAFER. The State CVIEW System sends
snapshot information to the Roadside Operations System. ASPEN queries
either the APL SAFER System or the State CVIEW System, depending on the
version of ASPEN the State uses. The functions are considered successful
when the proper data transfer and update is verified at the carrier,
State CVIEW, APL SAFER, Roadside System, ASPEN.

#### Sequencing: {#sequencing-24 .TestSuite_Objective .unnumbered}

General Data Flow:

1.  The CV Administration may send a Tax Filing Notification to the
    carrier. Depending on the state, the carrier may have to request the
    tax tables or the CV Administration may forward the tax tables with
    the notification. States may also store the tables in their own
    system, make them available on a Web site, or request the tables
    from IFTA Inc. when needed.

2.  The carrier submits the IFTA Quarterly Tax Filing Application to the
    CV Administration.

3.  The CV Administration validates the tax filing, calculates the tax
    liability, compares the amount submitted, and sends a Tax Filing
    Acceptance Notice to the carrier.

4.  The CV Administration sends a snapshot segment update to the State
    CVIEW System.

5.  The State CVIEW System sends a snapshot segment update to the APL
    SAFER System.

6.  The State CVIEW System sends the updated snapshot to the Roadside
    Operations System.

7.  ASPEN receives subscription containing updated carrier snapshot. If
    using ASPEN 32, the subscription will have updated vehicle and
    carrier snapshots.

#### Data recording and evaluation: {#data-recording-and-evaluation-24 .TestSuite_Objective .unnumbered}

Using messages, databases, and displayed screens, the test analyst
verifies successful receipt and update of information resulting from the
submission of IFTA Quarterly Tax filing by the carrier. Post-test
analysis involves comparing the appropriate database updates to the test
items.

Figure 4--7 illustrates the end-to-end interoperability test for
scenario ETE‑07: Carrier Submits IFTA Quarterly Tax Filing.

![](media/image15.wmf){width="5.997222222222222in"
height="4.490277777777778in"}

Figure 4--14.  Carrier Submits IFTA Quarterly Tax Filing

## Scenario ID ETE-08: ASPEN Requests Inspection Report from SAFER via CVIEW

#### Test items: {#test-items-25 .TestSuite_Objective .unnumbered}

In this scenario, an Enforcement Officer at the inspection site enters
the vehicle's State and Plate to request the past inspection report from
SAFER via CVIEW. The inspection report is returned to ASPEN via CVIEW.
The following test data are used as test items:

+-----------------------------------------------------------------------+
| -   Identification                                                    |
+-----------------------------------------------------------------------+
| -   Vehicle Plate / State                                             |
+-----------------------------------------------------------------------+

#### Functions being demonstrated: {#functions-being-demonstrated-7 .TestSuite_Objective .unnumbered}

The test scenario is initiated when the Enforcement Officer queries the
State CVIEW system for the vehicle's past inspection report. The State
CVIEW forwards the request to APL SAFER which returns the inspection
report to CVIEW. The State CVIEW System sends the inspection report to
ASPEN. The functions are considered successful when the proper data
transfer is verified at inspection site by checking the test items.

#### Sequencing: {#sequencing-25 .TestSuite_Objective .unnumbered}

General Data Flow:

1.  Roadside personnel (Enforcement Officer) queries CVIEW for the
    vehicle's past inspection report.

2.  CVIEW forwards the request to SAFER.

3.  SAFER returns the inspection report to CVIEW.

4.  The CVIEW System sends the past inspection report that matches the
    query, to the Enforcement Officer.

5.  The Enforcement Officer verifies the inspection report based on the
    test items.

#### Data recording and evaluation: {#data-recording-and-evaluation-25 .TestSuite_Objective .unnumbered}

The messages and displayed screens will show the successful receipt of
the inspection report.

Figure 4--8 illustrates the end-to-end interoperability test for
scenario ETE-08: ASPEN Requests Inspection Report from SAFER via CVIEW.

![](media/image16.wmf){width="6.028472222222222in"
height="4.574305555555555in"}

Figure 4--15.  ASPEN Requests Inspection Report

## Scenario ID ETE-09: ASPEN Sends Inspection Report to SAFER via CVIEW

#### Test items: {#test-items-26 .TestSuite_Objective .unnumbered}

In this scenario, an Enforcement Officer at the inspection site sends an
inspection report to SAFER via CVIEW. SAFER updates its database and
sends a snapshot segment update to CVIEW. CVIEW sends the update to the
roadside. The following test data are used as test items:

+---------------------------------+------------------------------------+
| -   Identification              | -   Inspection                     |
+---------------------------------+------------------------------------+
| -   Vehicle Plate / State       | -   OOS Flag                       |
+---------------------------------+------------------------------------+
|                                 | -   OOS Order / Report ID          |
+---------------------------------+------------------------------------+
|                                 | -   OOS Violation Code             |
+---------------------------------+------------------------------------+

#### Functions being demonstrated: {#functions-being-demonstrated-8 .TestSuite_Objective .unnumbered}

The test scenario is initiated when the Enforcement Officer queries the
State CVIEW system for the vehicle's past inspection report. The State
CVIEW forwards the request to APL SAFER, which returns the inspection
report to CVIEW. The State CVIEW System sends the inspection report to
ASPEN. The inspection is performed and the officer places the vehicle
out of service. The inspection report is sent to SAFER via CVIEW. SAFER
updates its database and sends a snapshot segment update to CVIEW. CVIEW
forwards the snapshot update to the roadside. The functions are
considered successful when the proper data transfer is verified at
roadside by checking the test items.

#### Sequencing: {#sequencing-26 .TestSuite_Objective .unnumbered}

General Data Flow:

1.  Roadside personnel (Enforcement Officer) uses ASPEN to query CVIEW
    for the vehicle's past inspection report.

2.  CVIEW forwards the request to SAFER.

3.  SAFER returns the inspection report to CVIEW.

4.  The CVIEW System sends the past inspection report that matches the
    query to ASPEN.

5.  The Enforcement Officer performs the inspection and places the
    vehicle out of service.

6.  ASPEN sends the report to CVIEW.

7.  CVIEW forwards the report to SAFER.

8.  SAFER updates its database and sends a snapshot segment update to
    CVIEW.

9.  CVIEW sends a snapshot segment update to the roadside.

#### Data recording and evaluation: {#data-recording-and-evaluation-26 .TestSuite_Objective .unnumbered}

The messages and displayed screens will show the successful receipt of
the inspection report and snapshot segment update.

Figure 4--9 illustrates the end-to-end interoperability test for
scenario ETE-09: ASPEN Sends Inspection Report to SAFER via CVIEW.

![](media/image17.wmf){width="5.997222222222222in" height="4.45in"}

Figure 4--16.  ASPEN Sends Inspection Report

## Scenario ID ETE-10: ASPEN Requests Carrier Snapshot from SAFER via CVIEW

#### Test items: {#test-items-27 .TestSuite_Objective .unnumbered}

In this scenario, an Enforcement Officer at the inspection site enters
the vehicle's State and Plate to request the carrier snapshot from SAFER
via CVIEW. The snapshot is returned to ASPEN via CVIEW. The following
test data are used as test items:

+-----------------------------------------------------------------------+
| -   Identification                                                    |
+-----------------------------------------------------------------------+
| -   USDOT Number                                                      |
+-----------------------------------------------------------------------+

#### Functions being demonstrated: {#functions-being-demonstrated-9 .TestSuite_Objective .unnumbered}

The test scenario is initiated when the Enforcement Officer queries the
State CVIEW system for the carrier snapshot. The State CVIEW forwards
the request to APL SAFER which returns the snapshot to CVIEW. The State
CVIEW System sends the snapshot to ASPEN. The functions are considered
successful when the proper data transfer is verified at inspection site
by checking the test items.

#### Sequencing: {#sequencing-27 .TestSuite_Objective .unnumbered}

General Data Flow:

1.  Roadside personnel (Enforcement Officer) queries CVIEW for the
    carrier snapshot.

2.  CVIEW forwards the request to SAFER.

3.  SAFER returns the snapshot to CVIEW.

4.  The CVIEW System sends the snapshot that matches the query, to the
    Enforcement Officer.

5.  The Enforcement Officer verifies the snapshot based on the test
    items.

#### Data recording and evaluation: {#data-recording-and-evaluation-27 .TestSuite_Objective .unnumbered}

The messages and displayed screens will show the successful receipt of
the inspection report.

Figure 4--10 illustrates the end-to-end interoperability test for
scenario ETE-10: ASPEN Requests Carrier Snapshot from SAFER via CVIEW.

![](media/image18.wmf){width="5.997222222222222in"
height="3.9444444444444446in"}

Figure 4--17.  ASPEN Requests Carrier Snapshot

## Scenario ID ETE-11: Carrier Adds More Than One Vehicle (IRP Supplemental)

#### Test items: {#test-items-28 .TestSuite_Objective .unnumbered}

In this scenario, test data is verified by the carrier and at the State
CVIEW, APL SAFER, and Roadside Systems. The following test data are used
as test items throughout the test:

+--------------------------------------+-------------------------------+
| -   Identification per vehicle       | -   Credentials               |
+--------------------------------------+-------------------------------+
| -   VIN                              | -   USDOT Number              |
+--------------------------------------+-------------------------------+
| -   Plate / State                    | -   IRP Account Number        |
+--------------------------------------+-------------------------------+
| -   Weight Group                     | -   IRP Base State            |
+--------------------------------------+-------------------------------+
| -   Unit Number                      |                               |
+--------------------------------------+-------------------------------+
| -   Jurisdictions and Weights        |                               |
+--------------------------------------+-------------------------------+

#### Functions being demonstrated: {#functions-being-demonstrated-10 .TestSuite_Objective .unnumbered}

The test scenario is initiated when the carrier submits an IRP
Supplemental "Add Vehicle" application to the CV Administration for two
vehicles in one weight category and one vehicle in another weight
category. The CV Administration will send an invoice notice to the
carrier. A credential will be sent to the carrier after payment
information is provided by the carrier. The CV Administration will
provide the updated vehicle information to the State CVIEW. The State
CVIEW will then send the information to APL SAFER and the state's
Roadside Operations. The functions are considered successful when the
proper data transfer and update is verified at the carrier, State CVIEW,
APL SAFER, and Roadside Operations by checking the test items.

#### Sequencing: {#sequencing-28 .TestSuite_Objective .unnumbered}

General Data Flow: Carrier submits an IRP Supplemental "Add Vehicle"
application to the CV Administration.

1.  The carrier submits an IRP Supplemental Application for adding one
    vehicle in one weight group and two vehicles in another weight
    group, and receives an Invoice Notice from the CV Administration.

2.  The CV Administration receives payment information and sends the
    credential to the carrier.

3.  The CV Administration sends a vehicle snapshot segment update to the
    State CVIEW System.

4.  The State CVIEW System sends a vehicle snapshot segment update to
    the APL SAFER System.

5.  The State CVIEW System sends a vehicle snapshot to the Roadside
    Operations System.

#### Data recording and evaluation: {#data-recording-and-evaluation-28 .TestSuite_Objective .unnumbered}

Using messages, databases, and displayed screens, the test analyst
verifies successful receipt and update of information resulting from the
submission of an IRP Supplemental application by the carrier. Post-test
analysis involves comparing the appropriate database updates to the test
items.

Figure 4--11 illustrates the end-to-end interoperability test for
scenario ETE‑11: Carrier Adds More Than One Vehicle: (IRP Supplemental).

![](media/image19.wmf){width="5.997222222222222in"
height="4.447916666666667in"}

Figure 4--18.  Carrier Adds More Than One Vehicle

This Page Intentionally Blank

# Web-Based Credential End-to-End Interface Tests

#### Objectives: {#objectives-4 .TestSuite_Objective .unnumbered}

The objective of the web-based end-to-end interface testing is to ensure
the systems involved in a particular process meet functional design
requirements. The end-to-end test is used to verify and evaluate the
operational effectiveness of the system provided to the users, for the
purpose of performing a specific task, i.e., placing a vehicle
out-of-service in one state and providing that information to all of the
other states that the vehicle operates in. The following test scenarios
are written with the intent of providing a test that is specific in
function, but general in method, and is applicable in states that have
web-based credential applications.

The end-to-end test scenarios cover a wide range of functions. The
threads being tested involve more than two products. A complete thread
may be verified in multiple steps.

#### Test Environments: {#test-environments-4 .TestSuite_Objective .unnumbered}

-   Items under test. The end-to-end test scenarios will be used to
    verify that the following real systems will interoperate:

```{=html}
<!-- -->
```
-   The Carrier's Browser and the State Commercial Vehicle (CV)
    Administration Web Site

-   CV Administration System and the State CVIEW System

-   The State CVIEW System and APL SAFER

-   The State CVIEW System and Roadside Operations

-   Roadside Operations and Screening System

```{=html}
<!-- -->
```
-   General configurations (test sites, facilities):

```{=html}
<!-- -->
```
-   The test will be executed from the carrier, state, and CVISN core
    infrastructure sites. The APL CVISN Test Facility is not expected to
    be involved in end-to-end tests, except to provide test data and to
    provide emulation for the production SAFER System. For the most
    part, tests will be evaluated using normal data access mechanisms.
    For example, when a test is conducted requiring state personnel to
    perform a credentials check, they will use their standard procedures
    and tools to access the carrier's application inputs.

```{=html}
<!-- -->
```
-   Participants and roles:

```{=html}
<!-- -->
```
-   Carrier, state, and CVISN core infrastructure personnel, or their
    designees will execute the tests. APL will provide test data, which
    may be tailored as needed by the state.

## Scenario ID WETE-01: Carrier Adds Vehicle (IRP Supplemental)

#### Test items: {#test-items-29 .TestSuite_Objective .unnumbered}

In this scenario, test data is verified by the carrier and at the State
CVIEW, APL SAFER, and Roadside Systems. The following test data are used
as test items throughout the test:

+-------------------------+--------------------------------------------+
| -   Identification      | -   Credentials                            |
+-------------------------+--------------------------------------------+
| -   VIN                 | -   USDOT Number                           |
+-------------------------+--------------------------------------------+
| -   Plate               | -   IRP Account Number                     |
+-------------------------+--------------------------------------------+
| -   State               | -   IRP Base State                         |
+-------------------------+--------------------------------------------+

#### Functions being demonstrated: {#functions-being-demonstrated-11 .TestSuite_Objective .unnumbered}

The test scenario is initiated when the carrier submits an IRP
Supplemental "Add Vehicle" application to the CV Administration Web site
via an Internet browser. The CV Administration will send an invoice
notice to the carrier. A credential will be sent to the carrier after
payment information is provided by the carrier. The CV Administration
will provide the updated vehicle information to the State CVIEW. The
State CVIEW will then send the information to APL SAFER and the state's
Roadside Operations. The functions are considered successful when the
proper data transfer and update is verified at the carrier, State CVIEW,
APL SAFER, and Roadside Operations, by checking the test items.

#### Sequencing: {#sequencing-29 .TestSuite_Objective .unnumbered}

General Data Flow: Carrier submits an IRP Supplemental "Add Vehicle"
application to the CV Administration.

1.  The carrier submits an IRP Supplemental Application via an Internet
    browser to the State Web site, adding a vehicle, and receives an
    Invoice Notice from the CV Administration.

2.  The CV Administration receives payment information and sends the
    credential to the carrier via the Web site.

3.  The CV Administration sends a vehicle snapshot segment update to the
    State CVIEW System.

4.  The State CVIEW System sends a vehicle snapshot segment update to
    the APL SAFER System.

5.  The State CVIEW System sends a vehicle snapshot to the Roadside
    Operations System.

#### Data recording and evaluation: {#data-recording-and-evaluation-29 .TestSuite_Objective .unnumbered}

Using messages, databases, and displayed screens, the test analyst
verifies successful receipt and update of information resulting from the
submission of an IRP Supplemental application by the carrier. Post-test
analysis involves comparing the appropriate database updates to the test
items.

Figure 5--1 illustrates the end-to-end interoperability test for
scenario WETE‑01: Carrier Adds Vehicle: (IRP Supplemental).

![](media/image20.wmf){width="5.997222222222222in"
height="4.2659722222222225in"}

Figure 5--19.  Carrier Adds Vehicle

## Scenario ID WETE-04: Carrier Adds Jurisdiction (IRP Supplemental)

#### Test items: {#test-items-30 .TestSuite_Objective .unnumbered}

In this scenario, test data is verified by the carrier and at the State
CVIEW, APL SAFER, and Roadside Systems, and if applicable, the IRP
Clearinghouse. The following test data are used as test items throughout
the test:

+-----------------------+-----------------------+----------------------+
| -   Identification    | -   Credentials       | -   Registration     |
|                       |                       |     Information      |
+-----------------------+-----------------------+----------------------+
| -   VIN               | -   USDOT Number      | -   DBA Name         |
+-----------------------+-----------------------+----------------------+
| -   License Plate     | -   IRP Account       | -   Owner Name       |
|     Number            |     Number            |                      |
+-----------------------+-----------------------+----------------------+
| -   License Plate     | -   IRP Base State    | -   Address          |
|     State             |                       |                      |
+-----------------------+-----------------------+----------------------+
|                       | -   Jurisdictions and |                      |
|                       |     Weights           |                      |
+-----------------------+-----------------------+----------------------+

#### Functions being demonstrated {#functions-being-demonstrated-12 .TestSuite_Objective .unnumbered}

The test scenario is initiated when the carrier submits an IRP
Supplemental "Add Jurisdiction" application via an Internet browser to
the State Web site, which is routed to the CV Administration (two
vehicles must be verified in this test, therefore, an application must
be submitted that will change the credentials for two vehicles within
the same fleet). The CV Administration processes the application and
sends an invoice notice to the carrier via the web site. The carrier
sends payment information and receives the credential from the CV
Administration via the web site. The CV Administration sends the updated
information to the State CVIEW system. The State CVIEW System sends the
updated information to the APL SAFER System and Roadside Operations
System. The functions are considered successful when the proper data
transfer and update is verified at the carrier, State CVIEW, APL SAFER,
and Roadside Operations, by checking the test items.

#### Sequencing: {#sequencing-30 .TestSuite_Objective .unnumbered}

General Data Flow:

1.  The carrier submits an IRP Supplemental Application via an Internet
    browser to the State Web site to add a jurisdiction and receives an
    Invoice Notice from the CV Administration via the Web site. The
    carrier also sends payment information to the CV Administration via
    the Web site.

2.  The CV Administration receives payment information and sends a
    credential for both vehicles to the carrier via the Web site.

3.  The CV Administration sends a snapshot segment update to the State
    CVIEW System.

4.  The State CVIEW System sends a snapshot segment update to the APL
    SAFER System.

5.  The State CVIEW System sends a vehicle snapshot to the Roadside
    Operations System.

#### Data recording and evaluation: {#data-recording-and-evaluation-30 .TestSuite_Objective .unnumbered}

Using messages, databases, and displayed screens, the test analyst
verifies successful receipt and update of information resulting from the
submission of an IRP Supplemental application by the carrier. Post-test
analysis involves comparing the appropriate database updates to the test
items.

Figure 5--2 illustrates the end-to-end interoperability test for
scenario WETE‑04: Carrier Adds Jurisdiction: (IRP Supplemental).

![](media/image21.wmf){width="5.997222222222222in"
height="4.447916666666667in"}

Figure 5--20.  Carrier Adds Jurisdiction

## Scenario ID WETE-05: Carrier Renews IRP Credential

#### Test items: {#test-items-31 .TestSuite_Objective .unnumbered}

In this scenario, test data is verified by the carrier and at the State
CVIEW, APL SAFER, and if applicable, the IRP Clearinghouse. The
following test data are used as test items throughout the test:

+------------------------+-----------------------+---------------------+
| -   Identification     | -   Credentials       | -   Registration    |
|                        |                       |     Information     |
+------------------------+-----------------------+---------------------+
| -   VIN                | -   USDOT Number      | -   DBA Name        |
+------------------------+-----------------------+---------------------+
| -   License Plate      | -   IRP Account       | -   Owner Name      |
|     Number             |     Number            |                     |
+------------------------+-----------------------+---------------------+
| -   License Plate      | -   IRP Base State    | -   Address         |
|     State              |                       |                     |
+------------------------+-----------------------+---------------------+
|                        | -   Jurisdictions and |                     |
|                        |     Weights           |                     |
+------------------------+-----------------------+---------------------+
|                        | -   Registration      |                     |
|                        |     Expiration Date   |                     |
+------------------------+-----------------------+---------------------+

#### Functions being demonstrated: {#functions-being-demonstrated-13 .TestSuite_Objective .unnumbered}

The test scenario is initiated when the carrier receives an IRP Renewal
reminder from the CV Administration. The carrier then submits the
renewal application to the CV Administration Web site using a Web
browser. The CV Administration will send an invoice notice to the
carrier. A credential will be sent to the carrier after payment
information is provided by the carrier. The CV Administration will
provide the updated vehicle information to the State CVIEW. The State
CVIEW will then send the information to APL SAFER. The functions are
considered successful when the proper data transfer and update is
verified at the carrier, State CVIEW, APL SAFER, by checking the test
items.

#### Sequencing: {#sequencing-31 .TestSuite_Objective .unnumbered}

General Data Flow:

1.  The CV Administration sends a renewal reminder to the carrier.

2.  The carrier submits the IRP Renewal Application to the State Web
    site via the internet; CV Administration sends an invoice notice
    back to the carrier via the Web site.

3.  The carrier sends payment information to the CV Administration and
    receives the IRP Credential via the Web site.

4.  The CV Administration sends a vehicle snapshot segment update to the
    State CVIEW System.

5.  The State CVIEW System sends a vehicle snapshot segment update to
    the APL SAFER System and roadside operations system.

#### Data recording and evaluation: {#data-recording-and-evaluation-31 .TestSuite_Objective .unnumbered}

Using messages, databases, and displayed screens, the test analyst
verifies successful receipt and update of information resulting from the
submission of an IRP Supplemental application by the carrier. Post-test
analysis involves comparing the appropriate database updates to the test
items.

Figure 5--3 illustrates the end-to-end interoperability test for
scenario WETE‑05: Carrier Renews IRP Credential.

![](media/image22.wmf){width="5.997222222222222in"
height="4.442361111111111in"}

Figure 5--21.  Carrier Renews IRP Credential

## Scenario ID WETE-06: Carrier Renews IFTA Credential

#### Test items: {#test-items-32 .TestSuite_Objective .unnumbered}

In this scenario, test data is verified by the carrier and at the State
CVIEW, APL SAFER, Roadside Operations, ASPEN, and if applicable, the
IFTA Clearinghouse. The following test data are used as test items
throughout the test:

+--------------------------------+-------------------------------------+
| -   Credentials                | -   Registration Information        |
+--------------------------------+-------------------------------------+
| -   USDOT Number               | -   Contact Name                    |
+--------------------------------+-------------------------------------+
| -   IFTA Account Number        | -   Address                         |
+--------------------------------+-------------------------------------+
| -   IFTA Base State            | -   Registration Expiration Date    |
+--------------------------------+-------------------------------------+
| -   Jurisdictions              |                                     |
+--------------------------------+-------------------------------------+

#### Functions being demonstrated: {#functions-being-demonstrated-14 .TestSuite_Objective .unnumbered}

The carrier submits the renewal application to the CV Administration via
an Internet browser connecting to the State Web site. The carrier also
sends payment information to the CV Administration via the Web site. If
applicable, the CV Administration queries the IFTA Clearinghouse for the
carrier's account status. The CV Administration validates the carrier's
application and sends the credential to the carrier via the Web site.
The CV Administration will send a snapshot segment update to the State
CVIEW. The State CVIEW will then send the information to APL SAFER. The
State CVIEW System sends snapshot information to the Roadside Operations
System. ASPEN queries either the APL SAFER System or the State CVIEW
System, depending on the version of ASPEN the state uses. The functions
are considered successful when the proper data transfer and update is
verified at the carrier, State CVIEW, APL SAFER, Roadside System, ASPEN,
and if applicable, the IFTA Clearinghouse, by checking the test items.

#### Sequencing: {#sequencing-32 .TestSuite_Objective .unnumbered}

General Data Flow:

1.  The CV Administration may send a renewal reminder to the carrier.

2.  If applicable, The CV Administration may query the IFTA
    Clearinghouse for the carrier's account status.

3.  If applicable, the IFTA Clearinghouse sends the status back to the
    CV Administration.

4.  The carrier submits the IFTA Renewal Application to the CV
    Administration Web site.

5.  The carrier sends payment information to the CV Administration Web
    site.

6.  The CV Administration accepts/validates the carrier's application
    and sends the credential to the carrier via the Web site.

7.  The CV Administration sends a snapshot segment update to the State
    CVIEW System.

8.  The State CVIEW System sends a snapshot segment update to the APL
    SAFER System.

9.  The State CVIEW System sends the updated snapshot to the Roadside
    Operations System.

10. ASPEN queries CVIEW or SAFER for the carrier snapshot which should
    reflect the snapshot updates.

#### Data recording and evaluation: {#data-recording-and-evaluation-32 .TestSuite_Objective .unnumbered}

Using messages, databases, and displayed screens, the test analyst
verifies successful receipt and update of information resulting from the
submission of an IFTA Renewal application by the carrier. Post-test
analysis involves comparing the appropriate database updates to the test
items.

Figure 5--4 illustrates the end-to-end interoperability test for
scenario WETE‑06: Carrier Renews IFTA Credential.

![](media/image23.wmf){width="6.668055555555555in" height="4.96875in"}

Figure 5--22.  Carrier Renews IFTA Credential

## Scenario ID WETE-07: Carrier Submits IFTA Quarterly Tax Filing

#### Test items: {#test-items-33 .TestSuite_Objective .unnumbered}

In this scenario, test data is verified by the carrier and at the State
CVIEW, APL SAFER, Roadside Operations, and ASPEN. The following test
data are used as test items throughout the test:

+------------------------------------+---------------------------------+
| -   Credentials                    | -   Registration Information    |
+------------------------------------+---------------------------------+
| -   USDOT Number                   | -   Contact Name                |
+------------------------------------+---------------------------------+
| -   IFTA Account Number            | -   Address                     |
+------------------------------------+---------------------------------+
| -   IFTA Base State                |                                 |
+------------------------------------+---------------------------------+
| -   Jurisdictions                  |                                 |
+------------------------------------+---------------------------------+

#### Functions being demonstrated: {#functions-being-demonstrated-15 .TestSuite_Objective .unnumbered}

The test scenario may be initiated when the carrier receives an IFTA Tax
Filing Notification from the CV Administration. The carrier either
receives the tax rate tables automatically or may request the tables
from the CV Administration via the State Web site. The CV Administration
may store the tables in their own system or request the tables from IFTA
Inc. when required. The carrier submits the tax filing to the CV
Administration via an Internet browser connecting to the State Web site.
The CV Administration sends a Tax Filing Acceptance Notification to the
carrier via the Web site. The CV Administration sends a snapshot segment
update to the State CVIEW. The State CVIEW will then send the
information to APL SAFER. The State CVIEW System sends snapshot
information to the Roadside Operations System. ASPEN queries either the
APL SAFER System or the State CVIEW System, depending on the version of
ASPEN the State uses. The functions are considered successful when the
proper data transfer and update is verified at the carrier, State CVIEW,
APL SAFER, Roadside System, ASPEN.

#### Sequencing: {#sequencing-33 .TestSuite_Objective .unnumbered}

General Data Flow:

1.  The CV Administration may send a Tax Filing Notification to the
    carrier. Depending on the state, the carrier may have to request the
    tax tables via the Web site, the rates may be posted on the Web
    site, or the CV Administration will forward the tax tables with the
    notification. States may store the tables in their own system or
    they may request the tables from IFTA Inc. when needed.

2.  The carrier submits the IFTA Quarterly Tax Filing Application to the
    CV Administration via the Web site.

3.  The CV Administration validates the tax filing, calculates the tax
    liability, compares the amount submitted, and sends a Tax Filing
    Acceptance Notice to the carrier via the Web site.

4.  The CV Administration sends a snapshot segment update to the State
    CVIEW System.

5.  The State CVIEW System sends a snapshot segment update to the APL
    SAFER System.

6.  The State CVIEW System sends the updated snapshot to the Roadside
    Operations System.

7.  ASPEN queries either CVIEW or SAFER for the updated carrier
    snapshot.

#### Data recording and evaluation: {#data-recording-and-evaluation-33 .TestSuite_Objective .unnumbered}

Using messages, databases, and displayed screens, the test analyst
verifies successful receipt and update of information resulting from the
submission of IFTA Quarterly Tax filing by the carrier. Post-test
analysis involves comparing the appropriate database updates to the test
items.

Figure 5--5 illustrates the end-to-end interoperability test for
scenario WETE‑07: Carrier Submits IFTA Quarterly Tax Filing.

![](media/image24.wmf){width="5.997222222222222in"
height="4.483333333333333in"}

Figure 5--23.  Carrier Submits IFTA Quarterly Tax Filing

## Scenario ID WETE-11: Carrier Adds More Than One Vehicle (IRP Supplemental)

#### Test items: {#test-items-34 .TestSuite_Objective .unnumbered}

In this scenario, test data is verified by the carrier and at the State
CVIEW, APL SAFER, and Roadside Systems. The following test data are used
as test items throughout the test:

+--------------------------------------+-------------------------------+
| -   Identification per vehicle:      | -   Credentials               |
+--------------------------------------+-------------------------------+
| -   VIN                              | -   USDOT Number              |
+--------------------------------------+-------------------------------+
| -   Plate / State                    | -   IRP Account Number        |
+--------------------------------------+-------------------------------+
| -   Weight Group                     | -   IRP Base State            |
+--------------------------------------+-------------------------------+
| -   Unit Number                      |                               |
+--------------------------------------+-------------------------------+
| -   Jurisdictions and Weights        |                               |
+--------------------------------------+-------------------------------+

#### Functions being demonstrated: {#functions-being-demonstrated-16 .TestSuite_Objective .unnumbered}

The test scenario is initiated when the carrier submits an IRP
Supplemental "Add Vehicle" application to the CV Administration via the
Web site for two vehicles in one weight category and one vehicle in
another weight category. The CV Administration will send an invoice
notice to the carrier via the Web site. A credential will be sent to the
carrier after payment information is provided by the carrier, also via
the Web site. The CV Administration will provide the updated vehicle
information to the State CVIEW. The State CVIEW will then send the
information to APL SAFER and the state's Roadside Operations. The
functions are considered successful when the proper data transfer and
update is verified at the carrier, State CVIEW, APL SAFER, and Roadside
Operations by checking the test items.

#### Sequencing: {#sequencing-34 .TestSuite_Objective .unnumbered}

General Data Flow: Carrier submits an IRP Supplemental "Add Vehicle"
application to the CV Administration.

1.  The carrier submits an IRP Supplemental Application for adding one
    vehicle in one weight group and two vehicles in another weight
    group, and receives an Invoice Notice from the CV Administration via
    the State Web site.

2.  The CV Administration receives payment information and sends the
    credential to the carrier via the Web site.

3.  The CV Administration sends a vehicle snapshot segment update to the
    State CVIEW System.

4.  The State CVIEW System sends a vehicle snapshot segment update to
    the APL SAFER System.

5.  The State CVIEW System sends a vehicle snapshot to the Roadside
    Operations System.

#### Data recording and evaluation: {#data-recording-and-evaluation-34 .TestSuite_Objective .unnumbered}

Using messages, databases, and displayed screens, the test analyst
verifies successful receipt and update of information resulting from the
submission of an IRP Supplemental application by the carrier. Post-test
analysis involves comparing the appropriate database updates to the test
items.

Figure 5--6 illustrates the end-to-end interoperability test for
scenario WETE‑11: Carrier Adds More Than One Vehicle: (IRP
Supplemental).

![](media/image25.wmf){width="5.997222222222222in"
height="4.447916666666667in"}

Figure 5--24.  Carrier Adds More Than One Vehicle

This Page Intentionally Blank

# References

1.  JHU/APL, Interoperability Test Suite Package, Introduction and Part
    1, Test Specifications, POR-98-7122 V1.0, dated February 2001.

2.  JHU/APL, ITS/CVO Interoperability Test Suite Package, Part 2, Test
    Cases and Procedures, POR-98-7123, V1.0, dated July 2001.

3.  JHU/APL, ITS/CVO Interoperability Test Suite Package, Part 3, Test
    Tool Description, POR-98-7124, D.1, dated July 1999.

4.  JHU/APL, ITS/CVO Interoperability Test Suite Package, Part 4, Test
    Data,\
    POR-98-7125, D.1, dated July 1999.

5.  ASTM Draft Standard for Dedicated, Short Range, Two-Way Vehicle to
    Roadside Communications Equipment, Draft 6, dated 23 February 1996.

6.  JHU/APL, CVISN Operational and Architectural Compatibility Handbook
    (COACH),\
    Part 5 -- Interoperability Test Criteria, POR-98-7126 V1.0, July
    2001.

This Page Intentionally Blank

# CVISN Change Request Form

Change Request Date: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ CRF Number:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Requestor's Full Printed Name:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Organization: \_\_\_\_\_\_\_

Requestor's Phone Number: ( \_\_ \_\_ \_\_ ) \_\_ \_\_ \_\_ \_\_ \_\_
\_\_ \_\_ ext. \_\_ \_\_ \_\_ \_\_ \_\_

Requestor's FAX Number: ( \_\_ \_\_ \_\_ ) \_\_ \_\_ \_\_ \_\_ \_\_ \_\_
\_\_

Requestor's E-Mail Address:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Priority (as perceived by the requestor): HIGH MEDIUM LOW (circle one)

Product:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Attachments: Yes No (circle one)

Location where the change request was
detected:\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

If it is a software change, please provide the software package and
build/version number.

If it is a documentation change, please provide the document title,
version, and date.

Title:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_Version #:
\_\_\_\_\_\_\_\_\_ Date: \_\_\_\_\_\_\_\_\_TS #: \_\_\_\_\_

Part 1 of 5: CHANGE

(Describe the change requested below and attach additional pages if
necessary. Please describe what you were doing and what you want
changed. Use a new form for each change requested.)

  -----------------------------------------------------------------------

  -----------------------------------------------------------------------

This Page Intentionally Blank