Intelligent Transportation Systems (ITS)

Commercial Vehicle Operations (CVO)

**Commercial Vehicle Information Systems**

**and Networks (CVISN)**

**Operational and Architectural**

**Compatibility Handbook (COACH)**

**Part 5**

Interoperability Test Criteria

**Baseline Version**

**POR-98-7126 V1.0**

**July** **2001**

**Note**

> > *The Motor Carrier Safety Improvement Act was signed into law on
> > December 9, 1999. This act established a new FMCSA (Federal Motor
> > Carrier Safety Administration) within the US DOT (United States
> > Department of Transportation), 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 (Joint Program Office) to
> > ensure the integration and interoperability of ITS/CVO systems with
> > the national ITS program.*

**This is a Baseline Version**

> 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
> Johns Hopkins University Applied Physics Laboratory (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. Theresa G. Nester

> The Johns Hopkins University
>
> Applied Physics Laboratory
>
> 11100 Johns Hopkins Road
>
> Laurel, MD 20723-6099
>
> Phone: 443-778-8760
>
> Fax: 443-778-6149

E-Mail: <theresa.nester@jhuapl.edu>

**Change Summary:**

This document is under configuration management by the CVISN
Architecture Configuration Control Board. The list below provides a
brief description of the change requests (CRs) processed by the board
that impacted this document. Soon we hope to post the CRs on the CVISN
Web site referenced above. See the Appendix for more information
concerning the impact of these CRs on this version of the document.

**Version V1.0** of the document incorporates revisions related to these
change requests:

  ----- ---- ------ ---- ------------------------------------------------------ -- -- -- -- --
  •     CR   1048   --   Survey on e-credentialing                                          

  •     CR   1084   --   Update Design Template and Stakeholder View                        

  •     CR   1099   --   Add Web to generic CVISN configuration                             

  •     CR   1159   --   Update DSRC references                                             

  •     CR   1164   --   Clarify interface options for Safety                               

  •     CR   1377   --   Update to COACH Part 5, Summary of Changes                         

  •     CR   1424   --   Delete interoperability test criteria to set or change             
                         subscription criteria via TS 285                                   

  •     CR   1463   --   IFTA Tax Scenario EDI Corrections/Clarifications                   

  •     CR   1508   --   CVIEW Version3 will not store inspection reports                   

  •     CR   1662   --   SAFER stores inspection reports for 60 days                        
  ----- ---- ------ ---- ------------------------------------------------------ -- -- -- -- --

**CVISN COACH**

**Part 5 -- Interoperability Test Criteria**

**Table of Contents**

[1 Introduction 1](#introduction)

[1.1 COACH Structure 2](#coach-structure)

[1.2 COACH Part 5 Description 2](#coach-part-5-description)

[1.3 CVISN System Design 3](#cvisn-system-design)

[1.4 How States Should Use this Document
4](#how-states-should-use-this-document)

[2 Terminology 9](#terminology)

[3 Pairwise Interface Interoperability Criteria: Credentials
Administration
11](#pairwise-interface-interoperability-criteria-credentials-administration)

[3.1 Carrier Automated Transactions (CAT) -- State Credentialing
Interface (CI) Electronic Credentialing
13](#carrier-automated-transactions-cat-state-credentialing-interface-ci-electronic-credentialing)

[3.2 State Credentialing Interface (CI) -- State International
Registration Plan (IRP) Registration
18](#state-credentialing-interface-ci-state-international-registration-plan-irp-registration)

[3.3 State Credentialing Interface (CI) -- State International Fuel Tax
Agreement (IFTA) Registration
23](#state-credentialing-interface-ci-state-international-fuel-tax-agreement-ifta-registration)

[3.4 Carrier Automated Transaction (CAT) -- State Credentialing
Interface (CI) Electronic Credentialing (for IFTA Tax Filing)
27](#carrier-automated-transaction-cat-state-credentialing-interface-ci-electronic-credentialing-for-ifta-tax-filing)

[3.5 State Credentialing Interface (CI) -- State International Fuel Tax
Agreement (IFTA) Tax Filing
34](#state-credentialing-interface-ci-state-international-fuel-tax-agreement-ifta-tax-filing)

[4 Pairwise Interface Interoperability Criteria: Electronic Screening
40](#pairwise-interface-interoperability-criteria-electronic-screening)

[4.1 Vehicle Transponder -- Electronic Clearance System Sensor (Roadside
Reader)
41](#vehicle-transponder-electronic-clearance-system-sensor-roadside-reader)

[5 Pairwise Interface Interoperability Criteria: Safety Information
Exchange
43](#pairwise-interface-interoperability-criteria-safety-information-exchange)

[5.1 State Commercial Vehicle Information Exchange Window (CVIEW) --
Safety and Fitness Electronic Records (SAFER) Snapshot Exchanges
45](#state-commercial-vehicle-information-exchange-window-cview-safety-and-fitness-electronic-records-safer-snapshot-exchanges)

[5.2 State ASPEN -- Safety and Fitness Electronic Record (SAFER)
Inspection Report Exchanges
51](#state-aspen-safety-and-fitness-electronic-record-safer-inspection-report-exchanges)

[5.3 State ASPEN -- Safety and Fitness Electronic Record (SAFER)
Snapshot Exchanges
52](#state-aspen-safety-and-fitness-electronic-record-safer-snapshot-exchanges)

[5.4 State ASPEN -- State Commercial Vehicle Information Exchange Window
(CVIEW) Inspection Report Exchanges
54](#state-aspen-state-commercial-vehicle-information-exchange-window-cview-inspection-report-exchanges)

[5.5 State ASPEN -- State Commercial Vehicle Information Exchange Window
(CVIEW) Snapshot Exchanges
56](#state-aspen-state-commercial-vehicle-information-exchange-window-cview-snapshot-exchanges)

[5.6 State Roadside Operations -- State Commercial Vehicle Information
Exchange Window (CVIEW) Snapshot Exchanges
58](#state-roadside-operations-state-commercial-vehicle-information-exchange-window-cview-snapshot-exchanges)

[6 End-To-End Interface Interoperability Criteria
64](#end-to-end-interface-interoperability-criteria)

[7 References 68](#references)

[8 CVISN Change Request Form 72](#cvisn-change-request-form)

[9 APPENDIX - CHANGE REQUESTS INCORPORATED INTO THE CURRENT VERSION
73](#appendix---change-requests-incorporated-into-the-current-version)

# Introduction

The Commercial Vehicle Information Systems and Networks (CVISN)
Operational and Architectural Compatibility Handbook (COACH) provides a
comprehensive checklist of what is required to be compatible with the
CVISN operational concepts, architecture, and standardized interfaces.
It is intended for use by state agencies with a motor carrier regulatory
function, by motor carriers, and by standards-compliant product vendors.
It is also intended to provide a quick reference for developers of CVISN
Core Infrastructure systems. This document contains test criteria for
the Level 1 interoperability tests. Reference 19 specifies those tests.
Interoperability tests will be used to verify that interfaces between
selected pairs of products or systems meet the applicable data exchange
standards (pairwise interface testing). Interoperability testing will
also be used to verify dataflow and data usage among several selected
products or systems (end-to-end interface testing). This version of the
document addresses computer to computer interfaces (predominately EDI,
ASPEN-unique, and DSRC); alternative interfaces (XML and flat file
format) and associated tests may be addressed in a later version. Note
that web-based credentials applications tests are addressed in the
context of end-to-end test criteria in Section 6. The ITS/CVO Glossary
(Reference 9) provides definitions of CVISN terms and acronyms that may
be useful to refer to while reading this document.

![](media/image1.wmf)

Figure 1--1. Interoperability Testing

## COACH Structure

Figure 1--2. The COACH Supports the Workshops

The COACH is divided into 5 parts:

Part 1 -- Operational Concept and Top-Level Design

Checklists

Part 2 -- Project Management Checklists

Part 3 -- Detailed System Checklists

Part 4 -- Interface Specification Checklists

Part 5 -- Interoperability Test Criteria

Parts 1 \[Reference 13\], 2 \[Reference 35\], 3 \[Reference 36\], and 4
\[Reference 37\] are available at the JHU/APL CVISN web site

<http://www.jhuapl.edu/cvisn/>, under Documents; CVISN Architecture and
Standards. This document is an update to an earlier version of COACH
Part 5 \[Reference 41\].

## COACH Part 5 Description

Part 5 includes:

-   Terminology: definitions of terms used in this document. \[Chapter
    2\]

-   Pairwise Interface Interoperability Criteria: top-level
    interoperability test criteria requirements organized around
    interfaces between pairs of products for electronic credentialing,
    electronic screening, and safety information exchange. These
    interoperability test criteria requirements are mapped to specific
    test cases that verify requirements. \[Chapters 3, 4, and 5\]

-   End-To-End Interface Interoperability Criteria: sample test criteria
    for verifying end-to-end functional capability of the CVISN system
    as a whole. These test criteria are mapped to specific test cases
    that verify requirements. \[Chapter 6\]

In Part 5, the checklists are intended to be used to indicate the
minimum test criteria the delivered systems should pass in order to be
interoperable and consistent with CVISN Level 1 interface definitions.
The test criteria must be applicable to the design that the state has
chosen to implement. The state CVISN designer makes that determination.
See Section 1.4, How States Should Use This Document.

## CVISN System Design

Chapters 3, 4, and 5 of this document focus on the three major
functional areas being implemented by the CVISN model deployment states:
Credentials Administration, Electronic Screening, and Safety Information
Exchange. Figure 1--3 depicts a typical CVISN Model Deployment State
Configuration. The CVISN model deployment states have adopted designs
comparable to this. This view of the CVISN system design illustrates the
three major categories of product interfaces that must be tested for
interoperability: state products that interface with carriers, state
products that interface with CVISN core infrastructure systems, and, at
the state's option, internal state products that connect to each other
using EDI.

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

**Figure 1--3. Typical CVISN Model Deployment State Configuration**

## How States Should Use this Document

This volume of the COACH summarizes interoperability test criteria. The
first sets of criteria (Chapter 3 to 5) are organized according to
interfaces between pairs of products. The second set of criteria
(Chapter 6) is organized according to major functions, which require
more than a pair of products to be completely exercised. This document
is intended to be a working document that becomes the core for planning
the interoperability testing of new or modified state systems. It will
also serve as a guideline for developers/testers of the related carrier
and CVISN Core Infrastructure systems.

To gain a more complete understanding of CVISN, state planners and
designers should read the Introductory Guide to CVISN \[Reference 1\];
the COACH, Part 1, Operational Concepts and Top-Level Design Checklists
\[Reference 13\]; the CVISN System Design Description \[Reference 11\];
the COACH, Part 3, Detailed System Checklists \[Reference 36\]; the
COACH, Part 4, Interface Specification Checklists \[Reference 37\]; and
the CVISN Guide to Top-Level Design \[Reference 38\].

Throughout this document a generic CVISN design is used as a basis for
the interoperability test criteria. Individual states may design their
systems differently, even to the extent that different products are
involved in standardized interface exchanges. If that is the case, the
criteria as stated in this document may need to be tailored to a
different set of products. For instance, this document will describe
test criteria for updating interstate vehicle snapshots in SAFER via the
state CVIEW. If a state chooses to have IRP segments of the vehicle
snapshot updated by the state IRP product, then the criteria stated
herein must be applied to the interaction between the IRP product and
SAFER for that function.

Complementing this document is an Interoperability Test Suite Package.
The package is organized into four parts:

-   Part 1 -- Test Specifications \[Reference 19\]

-   Part 2 -- Test Cases & Procedures \[Reference 30\]

-   Part 3 -- Test Tool Description \[Reference 31\]

-   Part 4 -- Test Data \[Reference 32\]

An early planning document, the Interoperability Testing Strategy
\[Reference 33\] described the overall approach to conducting
interoperability testing defined by the Interoperability Test Suite
Package. The combination of the COACH Part 5, the Guide to Integration
and Test \[Reference 29\], and the Interoperability Test Suite Package
is intended to provide a complete set of information about what should
be tested, how to accomplish the tests, and the data and common tools
needed for completing the tests.

The interoperability test criteria for the CVISN states have been
summarized in this document in a series of tables. Each table in this
document consists of these columns, unless otherwise noted: Exchange
Direction, Interoperability Test Criteria, State Design Check, Notes,
and Test Cases by Scenario and Configuration. The \"Exchange Direction\"
column indicates the sender and receiver of the data. The
\"Interoperability Test Criteria\" column states conformance
requirements in a manner that is specific and testable. Where needed for
clarification, comments are added in italics. The "Notes" column
provides explanations for those criteria that are not addressed in the
current set of interoperability tests.

The tables in this document are meant to serve as checklists for system
integrators. We recommend a two-step process.

-   The "State Design Check" column allows system designers and
    integrators to check off those interoperability criteria that are
    applicable to their state system design. As test planning gets
    underway for a particular subset of products or capabilities, the
    designers and integrators should review the test criteria that may
    apply to those products and capabilities to be tested, and identify
    the criteria that should have been implemented. They should fill in
    the State Design Check column with either a "Y" or a Build Number or
    whatever indication is useful to the state.

-   As more detailed test planning starts, the integrators should select
    the test cases that will be executed. For the applicable criteria,
    the system integrators can then use the "Test Cases by Scenario and
    Configuration" column (a cross-reference to the Interoperability
    Test Suite Package, Part 2, Test Cases and Procedures) to see which
    test case(s) support the specific test criteria. This column is
    first divided into scenarios (e.g., \"IRP Supplemental Add Vehicle\"
    and "IFTA Reg. Renewal" in Table 3-1 and Table 1-1 below). Each
    scenario is then split into one or more configurations that
    represent the system being tested (e.g., CAT, CI, or the interaction
    between CAT and CI). Under each configuration are columns denoting
    the test cases for that configuration. The test cases that verify a
    given test criteria are marked with an "X". The Interoperability
    Test Suite Package, Part 2, Test Cases & Procedures \[Reference 30\]
    should be consulted for specific test details in order to select
    which of the supporting test cases to run. To select a test case,
    the integrator should mark the applicable test case cells in the
    COACH Part 5 tables by changing the X to a Y (or some other
    indication that is useful to the state).

For an example, refer to the following tables, Tables 1-1 and 1-2. The
first table shows the first several rows of the CAT-CI Interface Table,
Table 3-1, which appears later in this document. Table 1-2 shows what it
would look like after state personnel follow the 2-step process
described above for IRP supplemental registration.

Step 1: State designers determine that the listed test criterion is
applicable to their design and insert a "Y" into the column under State
Design Check. The first row of Table 1-2 shows a "Y" in the state design
check column.

Step 2: Table 1-1 shows two "X"s under test cases for the CAT system for
the IRP Supplemental Add Vehicle Scenario. The "X"s indicate that these
test cases are appropriate for this test criterion. The test cases are
differentiated in the test procedure document by type and direction of
error. The first test case, 1.01.01, is a non-error case, while test
case 1.01.02 contains an Invoice Notice EDI error from the state to the
CAT. The state may choose to run the non-error case, or selected error
cases for any given test criteria and configuration. To indicate that
only the non-error case has been selected to test the IRP Supplemental
Add Vehicle scenario, the cell in the first row is changed from "X" to
"Y", as shown in Table 1-2.

By continuing this process for the other scenarios and interfaces, the
state CVISN system integrator can then refer to the edited versions of
the tables to see which test cases have been selected by scanning the
test case columns for "Y"s. All columns with one or more "Y"s have been
selected, and those tests should be executed.

Table 1‑1. Example From Table 3-1, CAT-CI Interface

<table>
<colgroup>
<col style="width: 9%" />
<col style="width: 38%" />
<col style="width: 8%" />
<col style="width: 6%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 3%" />
<col style="width: 4%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 7%" />
</colgroup>
<thead>
<tr class="header">
<th rowspan="4"><strong>Exchange</strong></th>
<th></th>
<th></th>
<th></th>
<th colspan="15"><strong>Test Cases by Scenario and
Configuration</strong></th>
</tr>
<tr class="odd">
<th rowspan="4"><strong>Interoperability Test Criteria</strong></th>
<th rowspan="2"></th>
<th rowspan="2"></th>
<th colspan="10">IRP Supplemental Add Vehicle</th>
<th colspan="5">IFTA Reg. Renewal</th>
</tr>
<tr class="header">
<th colspan="10"><p>Configuration:</p>
<p>(what is tested)</p></th>
<th colspan="5"><p>Configuration:</p>
<p>(what is tested)</p></th>
</tr>
<tr class="odd">
<th rowspan="2"><strong>State Design Check</strong></th>
<th rowspan="2"><strong>Notes</strong></th>
<th colspan="4">CAT</th>
<th colspan="4">CI</th>
<th colspan="2">Interaction</th>
<th colspan="2">CAT</th>
<th colspan="2">CI</th>
<th>Interaction</th>
</tr>
<tr class="header">
<th><strong>Direction</strong></th>
<th><blockquote>
<p>1.01.01</p>
</blockquote></th>
<th><blockquote>
<p>1.01.02</p>
</blockquote></th>
<th><blockquote>
<p>1.01.03</p>
</blockquote></th>
<th><blockquote>
<p>1.01.04</p>
</blockquote></th>
<th><blockquote>
<p>1.01.05</p>
</blockquote></th>
<th><blockquote>
<p>1.01.06</p>
</blockquote></th>
<th><blockquote>
<p>1.01.07</p>
</blockquote></th>
<th><blockquote>
<p>1.01.08</p>
</blockquote></th>
<th><blockquote>
<p>1.01.09</p>
</blockquote></th>
<th><blockquote>
<p>1.01.10</p>
</blockquote></th>
<th><blockquote>
<p>1.02.01</p>
</blockquote></th>
<th><blockquote>
<p>1.02.02</p>
</blockquote></th>
<th><blockquote>
<p>1.02.03</p>
</blockquote></th>
<th><blockquote>
<p>1.02.04</p>
</blockquote></th>
<th><blockquote>
<p>1.02.05</p>
</blockquote></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>CAT to CI</td>
<td>3.1.1. The CAT sends each kind of valid credential
application/modification using ANSI ASC X12 EDI transaction set 286
(abbreviated TS 286). <em>A valid credential transaction refers to one
that has no EDI syntax error or data application errors.</em></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>

**Table 1‑2. Example From Table 3-1, CAT-CI Interface, Edited with State
Inputs**

<table>
<colgroup>
<col style="width: 9%" />
<col style="width: 38%" />
<col style="width: 8%" />
<col style="width: 6%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 3%" />
<col style="width: 4%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 7%" />
</colgroup>
<thead>
<tr class="header">
<th></th>
<th></th>
<th></th>
<th></th>
<th colspan="15"><strong>Test Cases by Scenario and
Configuration</strong></th>
</tr>
<tr class="odd">
<th></th>
<th></th>
<th></th>
<th></th>
<th colspan="10">IRP Supplemental Add Vehicle</th>
<th colspan="5">IFTA Reg. Renewal</th>
</tr>
<tr class="header">
<th></th>
<th></th>
<th></th>
<th></th>
<th colspan="10"><p>Configuration:</p>
<p>(what is tested)</p></th>
<th colspan="5"><p>Configuration:</p>
<p>(what is tested)</p></th>
</tr>
<tr class="odd">
<th><strong>Exchange</strong></th>
<th><strong>Interoperability Test Criteria</strong></th>
<th rowspan="2"><strong>State Design Check</strong></th>
<th rowspan="2"><strong>Notes</strong></th>
<th colspan="4">CAT</th>
<th colspan="4">CI</th>
<th colspan="2">Interaction</th>
<th colspan="2">CAT</th>
<th colspan="2">CI</th>
<th>Interaction</th>
</tr>
<tr class="header">
<th><strong>Direction</strong></th>
<th></th>
<th><blockquote>
<p>1.01.01</p>
</blockquote></th>
<th><blockquote>
<p>1.01.02</p>
</blockquote></th>
<th><blockquote>
<p>1.01.03</p>
</blockquote></th>
<th><blockquote>
<p>1.01.04</p>
</blockquote></th>
<th><blockquote>
<p>1.01.05</p>
</blockquote></th>
<th><blockquote>
<p>1.01.06</p>
</blockquote></th>
<th><blockquote>
<p>1.01.07</p>
</blockquote></th>
<th><blockquote>
<p>1.01.08</p>
</blockquote></th>
<th><blockquote>
<p>1.01.09</p>
</blockquote></th>
<th><blockquote>
<p>1.01.10</p>
</blockquote></th>
<th><blockquote>
<p>1.02.01</p>
</blockquote></th>
<th><blockquote>
<p>1.02.02</p>
</blockquote></th>
<th><blockquote>
<p>1.02.03</p>
</blockquote></th>
<th><blockquote>
<p>1.02.04</p>
</blockquote></th>
<th><blockquote>
<p>1.02.05</p>
</blockquote></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>CAT to CI</td>
<td>3.1.1. The CAT sends each kind of valid credential
application/modification using ANSI ASC X12 EDI transaction set 286
(abbreviated TS 286). <em>A valid credential transaction refers to one
that has no EDI syntax errors or data application errors.</em></td>
<td><strong>Y</strong></td>
<td></td>
<td><strong>Y</strong></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>

The development of the test cases was governed by practical
considerations. For instance, it is impractical to completely test the
way the Credentialing Interface (CI) product handles incoming IRP
applications in isolation from a state's IRP Registration product. So,
much of the functional testing of the CI will be accomplished in
end-to-end tests involving the Carrier Automated Transaction (CAT)
product, the CI product, and the State legacy systems, such as the State
IRP Registration product. In some cases, pairwise test procedures were
not developed due to resource limitations, and in those cases the
end-to-end test cases will provide functional tests of the exchange.

The criteria included in this version cover these main areas:

-   Each product generates the correct outputs according to the
    applicable data exchange standards

-   Each product accepts inputs from partners according to the
    applicable data exchange standards

-   Each product acknowledges inputs according to the applicable data
    exchange standards

-   Each product handles errors according to the applicable data
    exchange standards

-   The flow of interactions occurs according to the implementation
    conventions

-   Each product interprets and handles inputs correctly

The criteria are based on the COACH Part 1 \[Reference 13\], the COACH
Part 3 \[Reference 36\], the COACH Part 4 \[Reference 37\], approved EDI
standards \[Reference 4\], EDI implementation guides \[References 14,
16--18, 34, 40\], the FMCSA Code Directory \[Reference 39\], and the
DSRC standards \[References 25--28\]. The MD and VA CARS \[References
22--23\] are also referenced to clarify processing requirements.

Note: The interoperability test criteria for EDI exchanges are based on
the assumption that State CVISN designers have elected to implement the
recommended full EDI acknowledgment protocol. For some aspects of your
state design, or for certain individual system components, this may or
may not be the case. Selection of the applicable test criteria should be
based on your state design and component system implementation.

# Terminology 

IEEE Standard 1220-1994 \[Reference 15\] defines the "pieces" of a
system as ***components, assemblies, subsystems, and products***. The
relationships between the pieces of a system are illustrated in
Figure 2--1. *CVISN* stands for Commercial Vehicle Information Systems
and Networks, and is, hence a *system of systems*. CVISN includes
information systems owned and operated by governments, carriers, and
other stakeholders.

> ![](media/image4.wmf)
>
> **Figure 2--2. Hierarchy of System Elements**

Starting at the lowest level,

-   A **component** is an element of the physical architecture. Example:
    subroutine, remote procedure to check IDs

-   An **assembly** is a group of components that perform a function.
    Example: part of user interface that checks inputs

-   A **subsystem** is a group of assemblies. Example: User interface

-   A **product** is a group of subsystems that represents a major
    consumer product. Example: Credentialing Interface or CVIEW

-   A **system** is a group of products working together, such as a
    State Safety System

-   A **system of systems** is a group of systems working together, such
    as CVISN

The system development process typically begins with requirements
definition, proceeds with top-level and detailed design, unit
development, unit test, and finally integration and testing. A "unit"
refers to the components, assemblies and subsystems of the IEEE
hierarchy. In the integration and test phase, it is assumed that the
units have been thoroughly tested and perform as expected.

Interoperability testing is one of three main tasks of integration and
testing:

-   Integrating subsystems into products and testing completed products

-   Integrating products into systems and testing completed systems

-   **Interoperability testing among products and systems**

> The scope of this document is limited to that portion of the
> integration and test phase related to interoperability testing among
> products and systems. **Pairwise interface interoperability tests**
> involve a pair of products. **End-to-end interface interoperability
> tests** involve several products. The focus of the interoperability
> tests is generally the interfaces between/among products from
> different systems, and the information flow between systems to perform
> shared functions. Reference 29 provides further guidance for CVISN
> integration and testing processes.

# Pairwise Interface Interoperability Criteria: Credentials Administration

The standardized interfaces that support credentials administration are
illustrated as heavy solid lines in Figure 3--1. States may choose to
use standardized interfaces for different (additional) connections.
Standardized interfaces between the carrier (or service provider) and
state systems are part of the CVISN Level 1 baseline. Each standardized
interface should be tested as part of interoperability testing. This
chapter addresses computer-to-computer interfaces only. Web-based
credential applications are addressed in Chapter 6.

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

Figure 3--3. Test the Level 1 Standardized Interfaces for Credentials
Administration

In this document, interoperability test criteria for five pairs of
interfaces that support credentials administration are defined:

-   Carrier Automated Transaction (CAT) -- State Credentialing
    Interface (CI) Electronic Credentialing

-   State Credentialing Interface (CI) -- State International
    Registration Plan (IRP) Registration

-   State Credentialing Interface (CI) -- State International Fuel Tax
    Agreement (IFTA) Registration

-   Carrier Automated Transaction (CAT) -- State Credentialing
    Interface (CI) IFTA Tax Filing

-   State Credentialing Interface (CI) -- State International Fuel Tax
    Agreement (IFTA) Tax Filing

## Carrier Automated Transactions (CAT) -- State Credentialing Interface (CI) Electronic Credentialing 

*(Electronic credentialing refers to: International Registration Plan
(IRP) and International Fuel Tax Agreement (IFTA) Registration)*

This section addresses the interface between the CAT and the CI. As
described in the CVISN System Design Description \[Reference 11\], the
COACH Part 3 \[Reference 36\], the COACH Part 4 \[Reference 37\], and
the MD or VA Credentials Administration Requirement Specification (CARS)
\[References 22 or 23\], this interface provides for the exchange of
credential applications, invoice information, and electronic
credentials. The interoperability test criteria listed below are stated
generically so that they apply to all credentials-related data flows
that are based on ANSI ASC X12 EDI standards. The criteria are based on
the TS 286 standard (4), the TS 286 Implementation Guide for IRP
Credentials \[Reference 14\], and the TS 286 Implementation Guide for
IFTA Credentials \[Reference 16\].

The Interoperability Test Suite Package provides a selection of test
scenarios for each type of credential (e.g., IRP, IFTA), and for various
credentialing activities (e.g., renewal, supplemental, etc.). This table
provides a cross-reference to applicable test cases by scenario and
configuration (what is tested) for the pairwise interoperability
criteria. The Notes column explains those criteria that are not part of
the interoperability test suite package. **The test cases listed in this
table are described in detail in the Interoperability Test Suite Package
Part 2: Test Cases and Procedures \[Reference 30\].** Note that the
transfers between financial institutions are not covered in this table.

Table 3--1. CAT -- CI Interface

<table>
<colgroup>
<col style="width: 9%" />
<col style="width: 41%" />
<col style="width: 5%" />
<col style="width: 5%" />
<col style="width: 1%" />
<col style="width: 1%" />
<col style="width: 1%" />
<col style="width: 1%" />
<col style="width: 1%" />
<col style="width: 1%" />
<col style="width: 1%" />
<col style="width: 1%" />
<col style="width: 3%" />
<col style="width: 3%" />
<col style="width: 1%" />
<col style="width: 1%" />
<col style="width: 1%" />
<col style="width: 1%" />
<col style="width: 7%" />
</colgroup>
<thead>
<tr class="header">
<th></th>
<th></th>
<th></th>
<th></th>
<th colspan="15">Test Cases by Scenario and Configuration</th>
</tr>
<tr class="odd">
<th></th>
<th></th>
<th></th>
<th></th>
<th colspan="10">IRP Supplemental Add Vehicle</th>
<th colspan="5">IFTA Reg. Renewal</th>
</tr>
<tr class="header">
<th></th>
<th></th>
<th></th>
<th></th>
<th colspan="10"><p>Configuration:</p>
<p>(what is tested)</p></th>
<th colspan="5"><p>Configuration:</p>
<p>(what is tested)</p></th>
</tr>
<tr class="odd">
<th>Exchange</th>
<th>Interoperability Test Criteria</th>
<th rowspan="2">State Design Check:</th>
<th rowspan="2">Notes</th>
<th colspan="4">CAT</th>
<th colspan="4">CI</th>
<th colspan="2">Interaction</th>
<th colspan="2">CAT</th>
<th colspan="2">CI</th>
<th>Interaction</th>
</tr>
<tr class="header">
<th>Direction</th>
<th></th>
<th><blockquote>
<p>1.01.01</p>
</blockquote></th>
<th><blockquote>
<p>1.01.02</p>
</blockquote></th>
<th><blockquote>
<p>1.01.03</p>
</blockquote></th>
<th><blockquote>
<p>1.01.04</p>
</blockquote></th>
<th><blockquote>
<p>1.01.05</p>
</blockquote></th>
<th><blockquote>
<p>1.01.06</p>
</blockquote></th>
<th><blockquote>
<p>1.01.07</p>
</blockquote></th>
<th><blockquote>
<p>1.01.08</p>
</blockquote></th>
<th><blockquote>
<p>1.01.09</p>
</blockquote></th>
<th><blockquote>
<p>1.01.10</p>
</blockquote></th>
<th><blockquote>
<p>1.02.01</p>
</blockquote></th>
<th><blockquote>
<p>1.02.02</p>
</blockquote></th>
<th><blockquote>
<p>1.02.03</p>
</blockquote></th>
<th><blockquote>
<p>1.02.04</p>
</blockquote></th>
<th><blockquote>
<p>1.02.05</p>
</blockquote></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>CAT to CI</td>
<td>3.1.1 The CAT sends each kind of valid credential
application/modification using ANSI ASC X12 EDI transaction set 286
(abbreviated TS 286). <em>A valid credential transaction refers to one
that has no EDI syntax errors or data application errors.</em></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CI to CAT</td>
<td>3.1.2. The CI transmits the renewal application using TS 286. (For
renewals, the state credentialing product initiates the process by
seeding an application with the current credential information - see
3.2.2).</td>
<td></td>
<td>1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CAT to CI</td>
<td>3.1.3. The CI successfully receives each kind of valid TS 286 sent
by the CAT.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td>CAT to CI</td>
<td><p>3.1.4. Each kind of valid TS 286 received by the CI from the CAT
is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td>CI to CAT</td>
<td>3.1.5 The CI acknowledges the receipt of each X12 EDI transmission
from the CAT (except a TS 997) by returning an X12 TS 997 message to the
CAT.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td>CI to CAT</td>
<td>3.1.6. The CI passes the results of credential application
processing back to the CAT via TS 286.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td>CAT to CI</td>
<td>3.1.7. The CAT acknowledges the receipt of each X12 EDI transmission
from the CI (except a TS 997) by returning an X12 TS 997 message to the
CI.</td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td>CI to CAT</td>
<td>3.1.8 If an invoice is required to specify the fees due (as is
normally the case for IRP), the fee information is sent via X12 TS
286.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CI to CAT</td>
<td>3.1.9. If errors are encountered in deciphering an incoming EDI X12
transaction, a syntax error message is sent to the CAT via X12 TS 997.
<em>Note: Only one 997 is sent, in this case a reject (see 3.1.5
above).</em></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CI to CAT</td>
<td>3.1.10. The CAT successfully receives each kind of valid TS 997 sent
by the CI.</td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="odd">
<td>CI to CAT</td>
<td><p>3.1.11. Each kind of valid TS 997 received by the CAT from the CI
is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td>CAT to CI</td>
<td>3.1.12. If errors are encountered in deciphering an incoming EDI X12
transaction, a syntax error message is sent to the CI via X12 TS 997.
<em>Note: Only one 997 is sent, in this case a reject (see 3.1.7
above).</em></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CAT to CI</td>
<td>3.1.13. The CI successfully receives each kind of valid TS 997 sent
by the CAT.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td>CAT to CI</td>
<td><p>3.1.14. Each kind of valid TS 997 received by the CI from the CAT
is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td>CI to CAT</td>
<td>3.1.15. The CAT successfully receives each kind of valid TS 286 sent
by the CI.</td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td>CI to CAT</td>
<td><p>3.1.16. Each kind of valid TS 286 received by the CAT from the CI
is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="odd">
<td>CI to CAT</td>
<td>3.1.17. If non-syntax errors are encountered in interpreting an
incoming EDI X12 TS 286 transaction, an error message is sent to the CAT
via X12 TS 286.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
</tr>
</tbody>
</table>

Notes:

1\. This criteria is not included in pairwise tests; the functions
served by this criteria are covered in end-to-end test ETE-05
\[Reference 30\].

## State Credentialing Interface (CI) -- State International Registration Plan (IRP) Registration

This section addresses the interface between the CI and the state IRP
product. As described in the CVISN System Design Description \[Reference
11\], the COACH Part 3 \[Reference 36\], the COACH Part 4 \[Reference
37\], and the MD or VA Credentials Administration Requirement
Specification (CARS) \[References 22 or 23\], this interface provides
for the exchange of credential applications, invoice information, and
electronic credentials. The criteria are based on the TS 286 standard
\[Reference 4\] and the TS 286 Implementation Guide for IRP Credentials
\[Reference 14\]. A state may choose to implement this as a legacy
system interface (non-EDI), in which case these criteria would not
apply. In future versions of this document, similar sections will be
included for other credential types/products. This table provides a
cross-reference to applicable test cases by scenario and configuration
(what is tested) for the pairwise interoperability criteria. **The test
cases listed in this table are described in detail in the
Interoperability Test Suite Package Part 2: Test Cases and Procedures
\[Reference 30\].** The Notes column in the table explains those
criteria that are either covered by end-to-end tests or are not part of
the interoperability test suite package. Note that the transfers between
financial institutions are not covered in this table.

Table 3--2. CI -- State IRP Interface

<table>
<colgroup>
<col style="width: 8%" />
<col style="width: 52%" />
<col style="width: 8%" />
<col style="width: 4%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 3%" />
<col style="width: 3%" />
</colgroup>
<thead>
<tr class="header">
<th></th>
<th></th>
<th></th>
<th></th>
<th colspan="10"><p>IRP Supplemental Add Vehicle</p>
<p>Scenario</p></th>
</tr>
<tr class="odd">
<th></th>
<th></th>
<th></th>
<th></th>
<th colspan="10">Configuration: (what is tested)</th>
</tr>
<tr class="header">
<th>Exchange</th>
<th>Interoperability Test Criteria:</th>
<th rowspan="2">State Design Check:</th>
<th>Notes</th>
<th colspan="4">CAT</th>
<th colspan="4">CI</th>
<th colspan="2">Interaction</th>
</tr>
<tr class="odd">
<th>Direction</th>
<th></th>
<th></th>
<th><blockquote>
<p>1.01.01</p>
</blockquote></th>
<th><blockquote>
<p>1.01.02</p>
</blockquote></th>
<th><blockquote>
<p>1.01.03</p>
</blockquote></th>
<th><blockquote>
<p>1.01.04</p>
</blockquote></th>
<th><blockquote>
<p>1.01.05</p>
</blockquote></th>
<th><blockquote>
<p>1.01.06</p>
</blockquote></th>
<th><blockquote>
<p>1.01.07</p>
</blockquote></th>
<th><blockquote>
<p>1.01.08</p>
</blockquote></th>
<th><blockquote>
<p>1.01.09</p>
</blockquote></th>
<th><blockquote>
<p>1.01.10</p>
</blockquote></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>CI to State IRP</td>
<td><ol type="1">
<li><p>The CI sends to the State IRP each kind of processed IRP
application input from the CAT using EDI X12 TS286.</p></li>
</ol></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>State IRP to CI</td>
<td>3.2.2. For renewals, the State IRP initiates the process by seeding
an application with the current credential information. The State IRP
transmits the initialized application to the CI using TS 286.</td>
<td></td>
<td>1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CI to State IRP</td>
<td>3.2.3. The State IRP successfully receives each valid TS286 sent by
the CI.</td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CI to State IRP</td>
<td><p>3.2.4. Each kind of valid TS 286 received by the State IRP from
the CI is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>State IRP to CI</td>
<td>3.2.5. The State IRP acknowledges the receipt of each X12 EDI
transmission from the CI (except a TS 997) by returning an X12 TS 997
message to the CI.</td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>State IRP to CI</td>
<td>3.2.6 The CI successfully receives each kind of valid TS 997 sent by
the State IRP.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>State IRP to CI</td>
<td><p>3.2.7. Each kind of valid TS 997 received by the CI from the
State IRP is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>State IRP to CI</td>
<td><ol start="8" type="1">
<li><p>The State IRP passes the results of IRP application processing
back to the CI via TS 286.</p></li>
</ol></td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CI to State IRP</td>
<td>3.2.9. The CI acknowledges the receipt of each X12 EDI transmission
from the State IRP (except a TS 997) by returning an X12 TS 997 message
to the State IRP.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CI to State IRP</td>
<td><ol start="10" type="1">
<li><p>The State IRP successfully receives each kind of valid TS 997
sent by the CI.</p></li>
</ol></td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CI to State IRP</td>
<td><p>3.2.11. Each kind of valid TS 997 received by the State IRP from
the CI is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<ol start="6" type="a">
<li><p>Codes, data formats and identifiers are set correctly in the
response, if any.</p></li>
</ol></td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>State IRP to CI</td>
<td>3.2.12. If an invoice is required to specify the fees due (as is
normally the case for IRP); the fee information is sent via X12 TS
286.</td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>State IRP to CI</td>
<td>3.2.13. If errors are encountered in deciphering an incoming EDI X12
transaction, a syntax error message is sent to the CI via X12 TS
997.</td>
<td></td>
<td>3</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CI to State IRP</td>
<td>3.2.14. If errors are encountered in deciphering an incoming EDI X12
transaction, a syntax error message is sent to the State IRP via X12 TS
997.</td>
<td></td>
<td>3</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>State IRP to CI</td>
<td>3.2.15. The CI successfully receives each valid TS 286 sent by the
State IRP.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>State IRP to CI</td>
<td><p>3.2.16. Each kind of valid TS 286 received by the CI from the
State IRP is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>State IRP to CI</td>
<td>3.2.17. If non-syntax (i.e., “application”) errors are encountered
in interpreting an incoming EDI X12 TS 286 transaction, an error message
is sent to the CI via X12 TS 286.</td>
<td></td>
<td>3</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CI to State IRP</td>
<td>3.2.18. If non-syntax (i.e., “application”) errors are encountered
in interpreting an incoming EDI X12 TS 286 transaction, an error message
is sent to the State IRP product via X12 TS 286.</td>
<td></td>
<td>3</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>

Notes:

1.  This criteria is not included in pairwise tests; the functions
    served by this criteria are covered in end-to-end test ETE-05
    \[Reference 30\].

2.  This criteria is not included in pairwise tests; the functions
    served by this criteria are covered in end-to-end tests ETE-01 and
    ETE-05 \[Reference 30\].

3.  CI-to-state IRP product error cases are not part of test suite.

## 3.3 State Credentialing Interface (CI) -- State International Fuel Tax Agreement (IFTA) Registration {#state-credentialing-interface-ci-state-international-fuel-tax-agreement-ifta-registration .unnumbered}

This section addresses the interface between the CI and the state IFTA
registration product. As described in the CVISN System Design
Description \[Reference 11\], the COACH Part 3 \[Reference 36\], the
COACH Part 4 \[Reference 37\], and the MD or VA Credentials
Administration Requirement Specification (CARS) \[References 22 or 23\],
this interface provides for the exchange of credential applications,
invoice information, and electronic credentials. The criteria are based
on the TS 286 standard \[Reference 4\] and the TS 286 Implementation
Guide for IFTA Credentials \[Reference 16\]. A state may choose to
implement this as a legacy system interface (non-EDI), in which case
these criteria would not apply. In future versions of this document,
similar sections will be included for other credential types/products.
This table provides a cross-reference to applicable test cases for the
IFTA registration scenario and configurations (what is tested) for the
pairwise interoperability criteria. **The test cases listed in this
table are described in detail in the Interoperability Test Suite Package
Part 2: Test Cases and Procedures \[Reference 30\].** The Notes column
in the table explains those criteria that are either covered by
end-to-end tests or are not part of the interoperability test suite
package. Note that the transfers between financial institutions are not
covered in this table.

Table 3--3. CI--State IFTA Registration Interface

+------+----------------------------------------+---+---+---+---+---+---+----+
|      |                                        |   |   | I |   |   |   |    |
|      |                                        |   |   | F |   |   |   |    |
|      |                                        |   |   | T |   |   |   |    |
|      |                                        |   |   | A |   |   |   |    |
|      |                                        |   |   | R |   |   |   |    |
|      |                                        |   |   | e |   |   |   |    |
|      |                                        |   |   | g |   |   |   |    |
|      |                                        |   |   | i |   |   |   |    |
|      |                                        |   |   | s |   |   |   |    |
|      |                                        |   |   | t |   |   |   |    |
|      |                                        |   |   | r |   |   |   |    |
|      |                                        |   |   | a |   |   |   |    |
|      |                                        |   |   | t |   |   |   |    |
|      |                                        |   |   | i |   |   |   |    |
|      |                                        |   |   | o |   |   |   |    |
|      |                                        |   |   | n |   |   |   |    |
|      |                                        |   |   | S |   |   |   |    |
|      |                                        |   |   | c |   |   |   |    |
|      |                                        |   |   | e |   |   |   |    |
|      |                                        |   |   | n |   |   |   |    |
|      |                                        |   |   | a |   |   |   |    |
|      |                                        |   |   | r |   |   |   |    |
|      |                                        |   |   | i |   |   |   |    |
|      |                                        |   |   | o |   |   |   |    |
+======+========================================+===+===+===+===+===+===+====+
|      |                                        |   |   | C |   |   |   |    |
|      |                                        |   |   | o |   |   |   |    |
|      |                                        |   |   | n |   |   |   |    |
|      |                                        |   |   | f |   |   |   |    |
|      |                                        |   |   | i |   |   |   |    |
|      |                                        |   |   | g |   |   |   |    |
|      |                                        |   |   | u |   |   |   |    |
|      |                                        |   |   | r |   |   |   |    |
|      |                                        |   |   | a |   |   |   |    |
|      |                                        |   |   | t |   |   |   |    |
|      |                                        |   |   | i |   |   |   |    |
|      |                                        |   |   | o |   |   |   |    |
|      |                                        |   |   | n |   |   |   |    |
|      |                                        |   |   | : |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      |                                        |   |   | ( |   |   |   |    |
|      |                                        |   |   | w |   |   |   |    |
|      |                                        |   |   | h |   |   |   |    |
|      |                                        |   |   | a |   |   |   |    |
|      |                                        |   |   | t |   |   |   |    |
|      |                                        |   |   | i |   |   |   |    |
|      |                                        |   |   | s |   |   |   |    |
|      |                                        |   |   | t |   |   |   |    |
|      |                                        |   |   | e |   |   |   |    |
|      |                                        |   |   | s |   |   |   |    |
|      |                                        |   |   | t |   |   |   |    |
|      |                                        |   |   | e |   |   |   |    |
|      |                                        |   |   | d |   |   |   |    |
|      |                                        |   |   | ) |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| Exch | Interoperability Test Criteria         | S | N | C |   | C |   | I  |
| ange |                                        | t | o | A |   | I |   | nt |
|      |                                        | a | t | T |   |   |   | er |
|      |                                        | t | e |   |   |   |   | ac |
|      |                                        | e | s |   |   |   |   | ti |
|      |                                        | D |   |   |   |   |   | on |
|      |                                        | e |   |   |   |   |   |    |
|      |                                        | s |   |   |   |   |   |    |
|      |                                        | i |   |   |   |   |   |    |
|      |                                        | g |   |   |   |   |   |    |
|      |                                        | n |   |   |   |   |   |    |
|      |                                        | C |   |   |   |   |   |    |
|      |                                        | h |   |   |   |   |   |    |
|      |                                        | e |   |   |   |   |   |    |
|      |                                        | c |   |   |   |   |   |    |
|      |                                        | k |   |   |   |   |   |    |
|      |                                        | : |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| D    |                                        |   |   | > | > | > | > | >  |
| irec |                                        |   |   |   |   |   |   |  1 |
| tion |                                        |   |   | 1 | 1 | 1 | 1 | .0 |
|      |                                        |   |   | . | . | . | . | 2. |
|      |                                        |   |   | 0 | 0 | 0 | 0 | 05 |
|      |                                        |   |   | 2 | 2 | 2 | 2 |    |
|      |                                        |   |   | . | . | . | . |    |
|      |                                        |   |   | 0 | 0 | 0 | 0 |    |
|      |                                        |   |   | 1 | 2 | 3 | 4 |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| CI   | 3.3.1. The CI sends to the State IFTA  |   |   |   |   | X |   |    |
| to   | a processed IFTA credential            |   |   |   |   |   |   |    |
| IFTA | application input from the CAT using   |   |   |   |   |   |   |    |
| Regi | TS286.                                 |   |   |   |   |   |   |    |
| stra |                                        |   |   |   |   |   |   |    |
| tion |                                        |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| IFTA | 3.3.2. For renewals, the State IFTA    |   | 1 |   |   |   |   |    |
| Regi | initiates the process by seeding an    |   |   |   |   |   |   |    |
| stra | application with the current           |   |   |   |   |   |   |    |
| tion | credential information. The State IFTA |   |   |   |   |   |   |    |
| to   | transmits the initialized application  |   |   |   |   |   |   |    |
| CI   | to the CI using TS 286.                |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| CI   | 3.3.3. The State IFTA successfully     |   | 2 |   |   |   |   |    |
| to   | receives each valid TS 286 sent by the |   |   |   |   |   |   |    |
| S    | CI.                                    |   |   |   |   |   |   |    |
| tate |                                        |   |   |   |   |   |   |    |
| IFTA |                                        |   |   |   |   |   |   |    |
| Regi |                                        |   |   |   |   |   |   |    |
| stra |                                        |   |   |   |   |   |   |    |
| tion |                                        |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| CI   | 3.3.4. Each kind of valid TS 286       |   | 2 |   |   |   |   |    |
| to   | received by the State IFTA from the CI |   |   |   |   |   |   |    |
| S    | is interpreted and handled correctly.  |   |   |   |   |   |   |    |
| tate |                                        |   |   |   |   |   |   |    |
| IFTA | a\. The sender is identified and       |   |   |   |   |   |   |    |
| Regi | recognized correctly.                  |   |   |   |   |   |   |    |
| stra |                                        |   |   |   |   |   |   |    |
| tion | b\. The relationship between this      |   |   |   |   |   |   |    |
|      | transaction and previous transactions  |   |   |   |   |   |   |    |
|      | (if any) is recognized.                |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | c\. A correct response, based on the   |   |   |   |   |   |   |    |
|      | input received, is generated, if       |   |   |   |   |   |   |    |
|      | appropriate.                           |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | d.  The relationship between the       |   |   |   |   |   |   |    |
|      |     incoming transaction and the       |   |   |   |   |   |   |    |
|      |     response transaction (if any) is   |   |   |   |   |   |   |    |
|      |     maintained.                        |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | e.  The recipient (if any) is          |   |   |   |   |   |   |    |
|      |     identified and set correctionly.   |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | f.  Codes, data formats and            |   |   |   |   |   |   |    |
|      |     identifiers are set correctly in   |   |   |   |   |   |   |    |
|      |     the response; if any.              |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| S    | 3.3.5. The State IFTA acknowledges the |   | 2 |   |   |   |   |    |
| tate | receipt of each X12 EDI transmission   |   |   |   |   |   |   |    |
| IFTA | from the CI (except a TS 997) by       |   |   |   |   |   |   |    |
| Regi | returning an X12 TS 997 message to the |   |   |   |   |   |   |    |
| stra | CI.                                    |   |   |   |   |   |   |    |
| tion |                                        |   |   |   |   |   |   |    |
| to   |                                        |   |   |   |   |   |   |    |
| CI   |                                        |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| S    | 3.3.6. The CI successfully receives    |   |   |   |   | X |   |    |
| tate | each kind of valid TS 997 sent by the  |   |   |   |   |   |   |    |
| IFTA | State IFTA.                            |   |   |   |   |   |   |    |
| Regi |                                        |   |   |   |   |   |   |    |
| stra |                                        |   |   |   |   |   |   |    |
| tion |                                        |   |   |   |   |   |   |    |
| to   |                                        |   |   |   |   |   |   |    |
| CI   |                                        |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| S    | 3.3.7. Each kind of valid TS 997       |   |   |   |   | X |   |    |
| tate | received by the CI from the State IFTA |   |   |   |   |   |   |    |
| IFTA | is interpreted and handled correctly.  |   |   |   |   |   |   |    |
| Regi |                                        |   |   |   |   |   |   |    |
| stra | a\. The sender is identified and       |   |   |   |   |   |   |    |
| tion | recognized correctly.                  |   |   |   |   |   |   |    |
| to   |                                        |   |   |   |   |   |   |    |
| CI   | b\. The relationship between this      |   |   |   |   |   |   |    |
|      | transaction and previous transactions  |   |   |   |   |   |   |    |
|      | (if any) is recognized.                |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | c\. A correct response, based on the   |   |   |   |   |   |   |    |
|      | input received, is generated, if       |   |   |   |   |   |   |    |
|      | appropriate.                           |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | d\. The relationship between the       |   |   |   |   |   |   |    |
|      | incoming transaction and the response  |   |   |   |   |   |   |    |
|      | transaction (if any) is maintained.    |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | e\. The recipient (if any) is          |   |   |   |   |   |   |    |
|      | identified and set correctly.          |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | f\. Codes, data formats and            |   |   |   |   |   |   |    |
|      | identifiers are set correctly in the   |   |   |   |   |   |   |    |
|      | response, if any.                      |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| S    | 3.3.8. The State IFTA passes the       |   | 2 |   |   |   |   |    |
| tate | results of IFTA application processing |   |   |   |   |   |   |    |
| IFTA | back to the CI via TS 286.             |   |   |   |   |   |   |    |
| Regi |                                        |   |   |   |   |   |   |    |
| stra |                                        |   |   |   |   |   |   |    |
| tion |                                        |   |   |   |   |   |   |    |
| to   |                                        |   |   |   |   |   |   |    |
| CI   |                                        |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| CI   | 3.3.9. The CI acknowledges the receipt |   |   |   |   | X |   |    |
| to   | of each X12 EDI transmission from the  |   |   |   |   |   |   |    |
| S    | State IFTA (except a TS 997) by        |   |   |   |   |   |   |    |
| tate | returning an X12 TS 997 message to the |   |   |   |   |   |   |    |
| IFTA | State IFTA.                            |   |   |   |   |   |   |    |
| Regi |                                        |   |   |   |   |   |   |    |
| stra |                                        |   |   |   |   |   |   |    |
| tion |                                        |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| CI   | 3.3.10. The State IFTA successfully    |   | 2 |   |   |   |   |    |
| to   | receives each kind of valid TS 997     |   |   |   |   |   |   |    |
| S    | sent by the CI.                        |   |   |   |   |   |   |    |
| tate |                                        |   |   |   |   |   |   |    |
| IFTA |                                        |   |   |   |   |   |   |    |
| Regi |                                        |   |   |   |   |   |   |    |
| stra |                                        |   |   |   |   |   |   |    |
| tion |                                        |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| CI   | 3.3.11. Each kind of valid TS 997      |   | 2 |   |   |   |   |    |
| to   | received by the State IFTA from the CI |   |   |   |   |   |   |    |
| S    | is interpreted and handled correctly.  |   |   |   |   |   |   |    |
| tate |                                        |   |   |   |   |   |   |    |
| IFTA | a\. The sender is identified and       |   |   |   |   |   |   |    |
| Regi | recognized correctly.                  |   |   |   |   |   |   |    |
| stra |                                        |   |   |   |   |   |   |    |
| tion | b\. The relationship between this      |   |   |   |   |   |   |    |
|      | transaction and previous transactions  |   |   |   |   |   |   |    |
|      | (if any) is recognized.                |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | c\. A correct response, based on the   |   |   |   |   |   |   |    |
|      | input received, is generated, if       |   |   |   |   |   |   |    |
|      | appropriate.                           |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | d\. The relationship between the       |   |   |   |   |   |   |    |
|      | incoming transaction and the response  |   |   |   |   |   |   |    |
|      | transaction (if any) is maintained.    |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | e\. The recipient (if any) is          |   |   |   |   |   |   |    |
|      | identified and set correctly.          |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | f\. Codes, data formats and            |   |   |   |   |   |   |    |
|      | identifiers are set correctly in the   |   |   |   |   |   |   |    |
|      | response, if any.                      |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| S    | 3.3.13. If errors are encountered in   |   | 3 |   |   |   |   |    |
| tate | deciphering an incoming EDI X12        |   |   |   |   |   |   |    |
| IFTA | transaction, a syntax error message is |   |   |   |   |   |   |    |
| Regi | sent to the CI via X12 TS 997.         |   |   |   |   |   |   |    |
| stra |                                        |   |   |   |   |   |   |    |
| tion |                                        |   |   |   |   |   |   |    |
| to   |                                        |   |   |   |   |   |   |    |
| CI   |                                        |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| CI   | 3.3.14. If errors are encountered in   |   | 3 |   |   |   |   |    |
| to   | deciphering an incoming EDI X12        |   |   |   |   |   |   |    |
| S    | transaction, a syntax error message is |   |   |   |   |   |   |    |
| tate | sent to the State IFTA via X12 TS 997. |   |   |   |   |   |   |    |
| IFTA |                                        |   |   |   |   |   |   |    |
| Regi |                                        |   |   |   |   |   |   |    |
| stra |                                        |   |   |   |   |   |   |    |
| tion |                                        |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| S    | 3.3.15. The CI successfully receives   |   |   |   |   | X |   |    |
| tate | each valid TS 286 sent by the State    |   |   |   |   |   |   |    |
| IFTA | IFTA.                                  |   |   |   |   |   |   |    |
| Regi |                                        |   |   |   |   |   |   |    |
| stra |                                        |   |   |   |   |   |   |    |
| tion |                                        |   |   |   |   |   |   |    |
| to   |                                        |   |   |   |   |   |   |    |
| CI   |                                        |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| S    | 3.3.16. Each kind of valid TS 286      |   |   |   |   | X |   |    |
| tate | received by the CI from the State IFTA |   |   |   |   |   |   |    |
| IFTA | is interpreted and handled correctly.  |   |   |   |   |   |   |    |
| Regi |                                        |   |   |   |   |   |   |    |
| stra | a\. The sender is identified and       |   |   |   |   |   |   |    |
| tion | recognized correctly.                  |   |   |   |   |   |   |    |
| to   |                                        |   |   |   |   |   |   |    |
| CI   | b\. The relationship between this      |   |   |   |   |   |   |    |
|      | transaction and previous transactions  |   |   |   |   |   |   |    |
|      | (if any) is recognized.                |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | c\. A correct response, based on the   |   |   |   |   |   |   |    |
|      | input received, is generated, if       |   |   |   |   |   |   |    |
|      | appropriate.                           |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | d\. The relationship between the       |   |   |   |   |   |   |    |
|      | incoming transaction and the response  |   |   |   |   |   |   |    |
|      | transaction (if any) is maintained.    |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | e\. The recipient (if any) is          |   |   |   |   |   |   |    |
|      | identified and set correctly.          |   |   |   |   |   |   |    |
|      |                                        |   |   |   |   |   |   |    |
|      | f\. Codes, data formats and            |   |   |   |   |   |   |    |
|      | identifiers are set correctly in the   |   |   |   |   |   |   |    |
|      | response, if any.                      |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
|      | 3.3.17. Reserved for future use.       |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+
| CI   | 3.3.18. If non-syntax errors (i.e.,    |   | 3 |   |   |   |   |    |
| to   | "application") are encountered in      |   |   |   |   |   |   |    |
| S    | interpreting an incoming EDI X12 TS    |   |   |   |   |   |   |    |
| tate | 286 transaction, an error message is   |   |   |   |   |   |   |    |
| IFTA | sent to the State IFTA via X12 TS 286. |   |   |   |   |   |   |    |
| Regi |                                        |   |   |   |   |   |   |    |
| stra |                                        |   |   |   |   |   |   |    |
| tion |                                        |   |   |   |   |   |   |    |
+------+----------------------------------------+---+---+---+---+---+---+----+

Notes:

1.  EDI renewal reminders are not part of this test suite.

2.  This criteria is not included in pairwise tests; the functions
    served by this criteria are covered in end-to-end test ETE-06
    \[Reference 30\].

3.  CI-to-state-IFTA-product error cases are not part of test suite.

## 3.4 Carrier Automated Transaction (CAT) -- State Credentialing Interface (CI) Electronic Credentialing (for IFTA Tax Filing) {#carrier-automated-transaction-cat-state-credentialing-interface-ci-electronic-credentialing-for-ifta-tax-filing .unnumbered}

As shown in Figure 3--1, the credentialing process is supported by two
sets of interfaces: between the CAT and the CI, and between the CI and
each credential processing system. This section addresses the interface
between the CAT and the CI. As described in the CVISN System Design
Description \[Reference 11\], the COACH Part 3 \[Reference 36\], the
COACH Part 4 \[Reference 37\], and the MD or VA Credentials
Administration Requirement Specification (CARS) \[References 22 or 23\],
this interface provides for the exchange of tax filings, tax rates, and
tax invoice information. The criteria listed below are stated
generically so that they apply to all credentials-related data flows
that are based on ANSI ASC X12 EDI standards. The interoperability test
criteria utilize the TS 149, 150,151, 826 and 813 standards. (TS 149,
150, and 826 are not required for CVISN Level 1 IFTA tax exchanges).
This table provides a cross-reference to applicable test cases for the
IFTA tax scenario and configurations (what is tested) for the pairwise
interoperability criteria. The Notes column in the table explains those
criteria that are either covered by end-to-end tests or are not part of
the interoperability test suite package. **The test cases listed in this
table are described in detail in the Interoperability Test Suite Package
Part 2: Test Cases and Procedures \[Reference 30\].** Note that the
transfers between financial institutions are not covered in this table.

Table 3--4. CAT -- CI Interface

<table>
<colgroup>
<col style="width: 7%" />
<col style="width: 50%" />
<col style="width: 5%" />
<col style="width: 5%" />
<col style="width: 3%" />
<col style="width: 3%" />
<col style="width: 4%" />
<col style="width: 3%" />
<col style="width: 3%" />
<col style="width: 3%" />
<col style="width: 7%" />
</colgroup>
<thead>
<tr class="header">
<th></th>
<th></th>
<th></th>
<th></th>
<th colspan="7">IFTA Tax Filing Scenario</th>
</tr>
<tr class="odd">
<th></th>
<th></th>
<th></th>
<th></th>
<th colspan="7">Configuration: (what is tested)</th>
</tr>
<tr class="header">
<th>Exchange</th>
<th>Interoperability Test Criteria</th>
<th rowspan="2">State Design Check:</th>
<th>Notes</th>
<th colspan="3">CAT</th>
<th colspan="3">CI</th>
<th>Interaction</th>
</tr>
<tr class="odd">
<th>Direction</th>
<th></th>
<th></th>
<th><blockquote>
<p>1.03.01</p>
</blockquote></th>
<th><blockquote>
<p>1.03.02</p>
</blockquote></th>
<th><blockquote>
<p>1.03.03</p>
</blockquote></th>
<th><blockquote>
<p>1.03.04</p>
</blockquote></th>
<th><blockquote>
<p>1.03.05</p>
</blockquote></th>
<th><blockquote>
<p>1.03.06</p>
</blockquote></th>
<th><blockquote>
<p>1.03.07</p>
</blockquote></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>CI to CAT</td>
<td>3.4.1. The CI sends a valid IFTA Tax Rates message using ANSI ASC
X12 EDI transaction set 150 (abbreviated TS 150).</td>
<td></td>
<td>1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CI to CAT</td>
<td>3.4.2. The CAT successfully receives each valid TS 150 sent by the
CI.</td>
<td></td>
<td>1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CI to CAT</td>
<td><p>3.4.3. Each valid TS 150 received by the CAT from the CI is
interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td>1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CAT to CI</td>
<td>3.4.4. The CAT acknowledges the receipt of each X12 EDI transmission
from the CI (except a TS 997) by returning an X12 TS 997 message to the
CI.</td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="odd">
<td>CAT to CI</td>
<td>3.4.5. The CAT sends a valid IFTA Tax Filing Information using ANSI
ASC X12 EDI transaction set 813 (abbreviated TS 813).</td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td>CAT to CI</td>
<td>3.4.6. The CI successfully receives each valid TS 813 sent by the
CAT.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td>CAT to CI</td>
<td><p>3.4.7. Each valid TS 813 received by the CI from the CAT is
interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td>CI to CAT</td>
<td>3.4.8. The CI acknowledges the receipt of each EDI transmission from
the CAT (except a TS 997) by returning a TS 997 message to the CAT.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td>CI to CAT</td>
<td>3.4.9. The CI passes the results of tax filing information
processing (rejection of tax filing, acceptance of tax filing) known as
Electronic Filing of Tax Return Data Acknowledgement using an ANSI ASC
X12 EDI transaction set 151 (abbreviated TS 151).</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td>CI to CAT</td>
<td>3.4.10. The CAT successfully receives each valid TS 151 sent by the
CI.</td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="odd">
<td>CI to CAT</td>
<td><p>3.4.11. Each kind of valid TS 151 received by the CAT from the CI
is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td>CI to CAT</td>
<td>3.4.12. If errors are encountered in deciphering an incoming EDI X12
transaction, a syntax error message is sent to the CAT via X12 TS
997.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CAT to CI</td>
<td>3.4.13. If errors are encountered in deciphering an incoming EDI X12
transaction, a syntax error message is sent to the CI via X12 TS
997.</td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CAT to CI</td>
<td>3.4.14. The CI successfully receives each valid TS 997 from the
CAT.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td>CAT to CI</td>
<td><p>3.4.15. Each kind of valid TS 997 received by the CI from the CAT
is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td>CI to CAT</td>
<td>3.4.16. The CAT successfully receives each valid TS 997 sent by the
CI.</td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="odd">
<td>CI to CAT</td>
<td><p>3.4.17. Each kind of valid TS 997 received by the CAT from the CI
is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td>CI to CAT</td>
<td>3.4.18. If non-syntax (i.e., "application") errors are encountered
in interpreting an incoming EDI X12 TS 813 transaction, a rejection of
tax filing message is sent to the CAT via X12 TS 151.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td>CAT to CI</td>
<td>3.4.19. The CAT sends a valid request for IFTA Tax Rates message
using X12 TS 150.</td>
<td></td>
<td>1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CAT to CI</td>
<td>3.4.20. The CI successfully receives each valid TS 150 sent by the
CAT.</td>
<td></td>
<td>1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CAT to CI</td>
<td><p>3.4.21. Each valid TS 150 received by the CI from the CAT is
interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td>1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CI to CAT</td>
<td>3.4.22. The CI sends a valid Tax Information Exchange message (Tax
credits) using ANSI ASC X12 EDI transaction set 826 (abbreviated TS
826).</td>
<td></td>
<td>3</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CI to CAT</td>
<td>3.4.23. The CAT successfully receives each valid TS 826 sent by the
CI.</td>
<td></td>
<td>3</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CI to CAT</td>
<td><p>3.4.24. Each valid TS 826 received by the CAT from the CI is
interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td>3</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CI to CAT</td>
<td>3.4.25. The CI sends a valid Notice of Tax Adjustment or Assessment
using ANSI ASC X12 EDI transaction set 149 (abbreviated TS 149).</td>
<td></td>
<td>3</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CI to CAT</td>
<td>3.4.26. The CAT successfully receives each valid TS 149 sent by the
CI.</td>
<td></td>
<td>3</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CI to CAT</td>
<td><p>3.4.27. Each valid TS 149 received by the CAT from the CI is
interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td>3</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>

Notes:

1.  Not required for Level 1.

2.  This CAT function is addressed in pairwise test 1.01.02.

3.  The use of the TS 826 for exchange of IFTA tax credits and the TS
    149 for notice of IFTA tax adjustment or assessment was approved in
    February 2001 by the ANSI X-12 Government Subcommittee, Task Group
    2, for use in the CVISN IFTA tax scenarios. These exchanges are not
    considered part of CVISN Level 1 requirements and are not included
    in the interoperability test suite at this time.

## 3.5 State Credentialing Interface (CI) -- State International Fuel Tax Agreement (IFTA) Tax Filing {#state-credentialing-interface-ci-state-international-fuel-tax-agreement-ifta-tax-filing .unnumbered}

As described in the CVISN System Design Description \[Reference 11\],
the COACH Part 3 \[Reference 36\], the COACH Part 4 \[Reference 37\],
and the MD or VA Credentials Administration Requirement Specification
(CARS) \[References 22 or 23\], this interface provides for the exchange
of tax filings, tax credits, and tax rates and tax filing
acknowledgements between the Credentialing Interface (CI) and the state
IFTA tax product. The criteria listed below apply to the interface
between the CI and the state IFTA tax product. A state may choose to
implement this as a legacy system interface (non-EDI), in which case
these criteria would not apply. The interoperability test criteria
utilize the TS 149, 150, 151, 826 and 813 standards. (The TS 149, 150,
and 826 are not required for CVISN Level 1 for IFTA tax exchanges.) This
table provides a cross-reference to applicable test cases for the IFTA
tax scenario and configurations (what is tested) for the pairwise
interoperability criteria. The Notes column in the table explains those
criteria that are either covered by end-to-end tests or are not part of
the interoperability test suite package. **The test cases listed in this
table are described in detail in the Interoperability Test Suite Package
Part 2: Test Cases and Procedures \[Reference 30\].** Note that the
transfers between financial institutions are not covered in this table.

Table 3--5. CI -- State IFTA Product

<table style="width:100%;">
<colgroup>
<col style="width: 10%" />
<col style="width: 55%" />
<col style="width: 6%" />
<col style="width: 6%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 7%" />
</colgroup>
<thead>
<tr class="header">
<th></th>
<th></th>
<th></th>
<th></th>
<th colspan="7"><p>IFTA Tax Filing</p>
<p>Scenario</p></th>
</tr>
<tr class="odd">
<th></th>
<th></th>
<th></th>
<th></th>
<th colspan="7">Configuration:(what is tested)</th>
</tr>
<tr class="header">
<th>Exchange</th>
<th>Interoperability Test Criteria</th>
<th rowspan="2">State Design Check:</th>
<th>Notes</th>
<th colspan="3">CAT</th>
<th colspan="3">CI</th>
<th>Interaction</th>
</tr>
<tr class="odd">
<th>Direction</th>
<th></th>
<th></th>
<th><blockquote>
<p>1.03.01</p>
</blockquote></th>
<th><blockquote>
<p>1.03.02</p>
</blockquote></th>
<th><blockquote>
<p>1.03.03</p>
</blockquote></th>
<th><blockquote>
<p>1.03.04</p>
</blockquote></th>
<th><blockquote>
<p>1.03.05</p>
</blockquote></th>
<th><blockquote>
<p>1.03.06</p>
</blockquote></th>
<th><blockquote>
<p>1.03.07</p>
</blockquote></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>CI to State IFTA Tax Filing</td>
<td>3.5.1. The CI acknowledges the receipt of each X12 EDI transmission
from the State IFTA Tax Filing (except a TS 997) by returning an X12 TS
997 message to the IFTA Tax Filing.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>State IFTA Tax Filing to CI</td>
<td>3.5.2. The State IFTA Tax Filing sends appropriate Tax Rates Tables
to the CI using ANSI ASC X12 transaction set 150 (abbreviated TS
150).</td>
<td></td>
<td>1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CI to State IFTA Tax Filing</td>
<td>3.5.3. The CI sends the Tax Filing application to the State IFTA Tax
Filing via ANSI ASC X12 EDI transaction set 813 (abbreviated TS
813).</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CI to State IFTA Tax Filing</td>
<td>3.5.4. The State IFTA Tax Filing successfully receives each valid TS
813 from the CI.</td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CI to State IFTA Tax Filing</td>
<td><p>3.5.5. Each valid TS 813 received by the State IFTA Tax Filing
from the CI is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and</p>
<p>the response transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>State IFTA Tax Filing to CI</td>
<td>3.5.6. The State IFTA Tax Filing sends results of tax filing
information processing (rejection of tax filing, acceptance of tax
filing) known as Electronic Filing of Tax Return Data Acknowledgement to
the CI using ANSI ASC X12 EDI transaction set 151 (abbreviated TS
151).</td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>State IFTA Tax Filing to CI</td>
<td>3.5.7. The State IFTA Tax Filing acknowledges receipt of each EDI
transmission from the CI (except TS 997) by returning a TS 997 message
to the CI.</td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>State IFTA Tax Filing to CI</td>
<td>3.5.8. If errors are encountered in deciphering an incoming EDI X12
transaction, a syntax error message is sent to the CI via X12 TS
997.</td>
<td></td>
<td>3</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>State IFTA Tax Filing Filing</td>
<td>3.5.9. If errors are encountered in deciphering an incoming EDI X12
transaction, a syntax error message is sent to the State IFTA via X12 TS
997.</td>
<td></td>
<td>3</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>State IFTA Tax Filing to CI</td>
<td>3.5.10. The CI successfully receives each valid TS 150 from the
State Tax Filing.</td>
<td></td>
<td>1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>State IFTA Tax Filing to CI</td>
<td><p>3.5.11. Each valid TS 150 received by the CI from the State Tax
Filing is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td>1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>State IFTA Tax Filing to CI</td>
<td>3.5.12. The CI successfully receives each valid TS 151 from the
State Tax Filing.</td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>State IFTA Tax Filing to CI</td>
<td>3.5.13. If non-syntax (i.e., "application") errors are encountered
in interpreting an incoming EDI X12 TS 813 transaction, a rejection of
tax filing message is sent to the CI via X12 TS 151.</td>
<td></td>
<td>3</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>State IFTA Tax Filing to CI</td>
<td><p>3.5.14. Each valid TS 151 received by the CI from the State Tax
Filing is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CI to State IFTA Tax Filing</td>
<td>3.5.15. The State IFTA Tax Filing successfully receives each valid
TS 997 from the CI.</td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CI to State IFTA Tax Filing</td>
<td><p>3.5.16. Each valid TS 997 received by the State IFTA Tax Filing
from the CI is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td>2</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>State IFTA Tax Filing to CI</td>
<td>3.5.17. The CI successfully receives each TS 997 from the State IFTA
Tax Filing.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>State IFTA Tax Filing to CI</td>
<td><p>3.5.18. Each valid TS 997 received by the CI from the State Tax
Filing is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CI to State IFTA Tax Filing</td>
<td>3.5.19. The CI sends a Request for Tax Rates to the State IFTA Tax
Filing using X12 TS150.</td>
<td></td>
<td>1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CI to State IFTA Tax Filing</td>
<td>3.5.20. The State IFTA Tax Filing successfully receives each valid
TS 150 from the CI.</td>
<td></td>
<td>1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CI to State IFTA Tax Filing</td>
<td><p>3.5.21. Each valid TS 150 received by the State IFTA Tax Filing
from the CI is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td>1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>State IFTA Tax Filing to CI</td>
<td>3.5.22. The State IFTA Tax Filing sends a valid Tax Information
Exchange (Tax credits) to the CI using ANSI ASC X12 transaction set 826
(abbreviated TS 826).</td>
<td></td>
<td>4</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>State IFTA Tax Filing to CI</td>
<td>3.5.23. The CI successfully receives each valid TS 826 from the
State IFTA Tax Filing.</td>
<td></td>
<td>4</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>State IFTA Tax Filing to CI</td>
<td><p>3.5.24. Each valid TS 826 received by the CI from the State IFTA
Tax Filing is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td>4</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>State IFTA Tax Filing to CI</td>
<td>3.5.25. The State IFTA Tax Filing sends a valid Notice of Tax
Adjustment or Assessment to the CI using ANSI ASC X12 transaction set
149 (abbreviated TS 149).</td>
<td></td>
<td>4</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>State IFTA Tax Filing to CI</td>
<td>3.5.26. The CI successfully receives each valid TS 149 from the
State IFTA Tax Filing.</td>
<td></td>
<td>4</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>State IFTA Tax Filing to CI</td>
<td><p>3.5.27. Each valid TS 149 received by the CI from the State IFTA
Tax Filing is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td>4</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>

Notes:

1.  Not required for Level 1.

2.  This criteria is not included in pairwise tests; the functions
    served by this criteria are covered in end-to-end test ETE- 07.

3.  CI to legacy system error cases are not part of test suite.

4.  The use of the TS 826 for exchange of IFTA tax credits and the TS
    149 for notice of IFTA tax adjustment or assessments was approved in
    February 2001 by the ANSI X-12 Government Subcommittee, Task Group 2
    for use in the CVISN IFTA tax scenarios. These exchanges are not
    considered part of CVISN Level 1 requirements and are not included
    in the interoperability test suite at this time.

# Pairwise Interface Interoperability Criteria: Electronic Screening

The standardized interfaces that support electronic screening are
illustrated as heavy solid lines in Figure 4--1. Snapshot related
exchanges are shown as heavy dotted lines, and will be addressed in
Chapter 5. States may choose to use standardized interfaces for
different (additional) connections. Standardized interfaces between the
vehicle transponder and state roadside reader are part of the CVISN
Level 1 baseline. Each standardized interface should be tested as part
of interoperability testing. The scenarios in Table 4-1 are defined
based on the type of transponder used in the test. Unlike the
credentials portion of this document, there is only one test
configuration for each of these scenarios. The item under test in each
scenario is the roadside reader and screening system.

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

Figure 4--1. Test Level 1 Standardized Interfaces for Electronic
Screening

In this document, interoperability test criteria for one pair of
interfaces that support electronic screening are defined: Vehicle
Transponder **--** Roadside Reader.

## Vehicle Transponder -- Electronic Clearance System Sensor (Roadside Reader)

As described in the CVISN System Design Description \[Reference 11\],
the COACH Part 3 \[Reference 36\], and the COACH Part 4 \[Reference
37\], this interface provides for the exchange of data identifiers and
screening messages between the roadside reader (one of the roadside
sensors) and the vehicle-mounted transponder (also called the "tag").
The criteria listed below are the minimal set that should be tested to
verify that the roadside reader and transponder can properly communicate
using the Dedicated Short Range Communications (DSRC) standards. The
test criteria reference the IEEE Standard 1455-1999 \[Reference 27\] and
ASTM Draft Standard 6 \[Reference 26\]. It is expected that the FHWA
DSRC sandwich specification \[Reference 28\], which incorporates these
two documents, will be used instead. The test criteria do not include
any error handling requirements, since the existing equipment does not
support error handling. As new equipment that meets the standards
emerges, the criteria will be updated to include error handling. This
table provides a cross-reference to applicable test cases by scenario,
where scenario is defined by transponder type. In all test cases, the
roadside screening system is under test. **The test cases listed in this
table are described in detail in the Interoperability Test Suite Package
Part 2: Test Cases and Procedures \[Reference 30\].**

Table 4--1. Transponder -- Reader Interface

<table style="width:100%;">
<colgroup>
<col style="width: 10%" />
<col style="width: 48%" />
<col style="width: 6%" />
<col style="width: 6%" />
<col style="width: 3%" />
<col style="width: 3%" />
<col style="width: 2%" />
<col style="width: 3%" />
<col style="width: 2%" />
<col style="width: 3%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 3%" />
</colgroup>
<thead>
<tr class="header">
<th rowspan="3">Exchange Direction</th>
<th rowspan="3">Interoperability Test Criteria</th>
<th rowspan="3"><p>State</p>
<p>Design</p>
<p>Check:</p></th>
<th rowspan="3">Notes</th>
<th colspan="9">Test Cases by Scenario</th>
</tr>
<tr class="odd">
<th colspan="2"><blockquote>
<p>Type II Transponder</p>
</blockquote></th>
<th colspan="2"><blockquote>
<p>Type III Transponder</p>
</blockquote></th>
<th colspan="2"><blockquote>
<p>Type IIIm Transponder w/o memory</p>
</blockquote></th>
<th colspan="3"><blockquote>
<p>Type IIIm Transponder w/ memory in use</p>
</blockquote></th>
</tr>
<tr class="header">
<th><blockquote>
<p>2.01.01</p>
</blockquote></th>
<th><blockquote>
<p>2.01.02</p>
</blockquote></th>
<th><blockquote>
<p>2.02.01</p>
</blockquote></th>
<th><blockquote>
<p>2.02.02</p>
</blockquote></th>
<th><blockquote>
<p>2.03.01</p>
</blockquote></th>
<th><blockquote>
<p>2.03.02</p>
</blockquote></th>
<th><blockquote>
<p>2.04.01</p>
</blockquote></th>
<th><blockquote>
<p>2.04.02</p>
</blockquote></th>
<th><blockquote>
<p>2.04.03</p>
</blockquote></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>Roadside Reader to Transponder</td>
<td>4.1.1. The reader commands the transponder (requests read only
memory, including transponder ID), in accordance with ASTM E17.51 (Draft
6) and IEEE Standard 1455-1999 <em>(Transponder ID only and Message
scenarios).</em></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td>Transponder to Roadside Reader</td>
<td>4.1.2. The transponder transmits a Transponder ID only or
Transponder ID and CV Electronic Screening Message to the reader, in
accordance with ASTM E17.51(Draft 6) and IEEE Standard 1455-1999
<em>(Transponder ID only and Message scenarios).</em></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td>Roadside Reader to Transponder</td>
<td>4.1.3. The reader sends messages or commands to the transponder, in
accordance with ASTM E17.51 (Draft 6) and IEEE Standard 1455-1999. The
available commands are defined by the Set User Interface Command Set,
and the messages may include any defined in the CVO Electronic Screening
Message Set. <em>This command instructs the transponder to turn the
lights on, or to turn the lights on and write the CV Electronic
Screening message into memory (if applicable for tag type).</em></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td>Transponder to Roadside Reader</td>
<td>4.1.4. Upon receipt of messages or commands from the reader, the
transponder responds in accordance with ASTM E17.51 (Draft 6) and IEEE
Standard 1455-1999. The available commands are defined by the Set User
Interface Command Set, and the messages may include any defined in the
CVO Electronic Screening Message Set. <em>The transponder loads its
memory, turns the lights on, and sounds the beep.</em></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
</tbody>
</table>

# Pairwise Interface Interoperability Criteria: Safety Information Exchange 

The standardized interfaces that support safety information exchange are
illustrated in Figure 5--1. States may choose to use standardized
interfaces for different (additional) connections. Standardized
interfaces are part of the CVISN Level 1 baseline. Each standardized
interface should be tested as part of interoperability testing.

![](media/image7.wmf)

Figure 5--4. Test Level 1 Standardized Interfaces for Safety Information
Exchange

In this document, interoperability test criteria are included for
pair-wise interfaces that support the following areas:

-   State Commercial Vehicle Information Exchange Window (CVIEW) --
    Safety and Fitness Electronic Record (SAFER) Snapshot Exchanges

-   State Roadside Operations (ASPEN) -- Safety and Fitness Electronic
    Record (SAFER) Inspection Report Exchanges

-   State Roadside Operations (ASPEN) -- Safety and Fitness Electronic
    Record (SAFER) Snapshot Exchanges

-   State Roadside Operations (ASPEN) -- State Commercial Vehicle
    Information Exchange Window (CVIEW) Inspection Report Exchanges

-   State Roadside Operations (ASPEN) -- State Commercial Vehicle
    Information Exchange Window (CVIEW) Snapshot Exchanges

-   State Roadside Operations -- State Commercial Vehicle Information
    Exchange Window (CVIEW) Snapshot Exchanges

## State Commercial Vehicle Information Exchange Window (CVIEW) -- Safety and Fitness Electronic Records (SAFER) Snapshot Exchanges

The state CVIEW interacts with SAFER to provide SAFER/CVIEW snapshots
(data views), and to receive snapshot views. In addition, CVIEW may post
data view requests and receive responses from SAFER. The
interoperability test criteria are based on the TS 285 Implementation
Guide for CV Safety and Credentials Information Exchange \[Reference
18\], the TS 824 Implementation Guide for Application Advice \[Reference
34\], and the TS 285 and TS 824 standards \[Reference 4\]. The data
exchanges listed in Table 5-1 are supported by CVIEW/SAFER versions
1.6.7 to 3. This table provides a cross-reference to applicable test
cases by scenario, where scenario is defined by CVIEW sending a snapshot
or query, or CVIEW receiving a snapshot segment update. In all test
cases, the CVIEW system is under test. The Notes column in the table
explains those criteria that are either covered by end-to-end tests or
are not part of the interoperability test suite package. **The test
cases listed in this table are described in detail in the
Interoperability Test Suite Package Part 2: Test Cases and Procedures
\[Reference 30\].**

Table 5‑3. CVIEW -- SAFER Snapshot Exchanges

<table>
<colgroup>
<col style="width: 9%" />
<col style="width: 33%" />
<col style="width: 7%" />
<col style="width: 6%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 6%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 6%" />
</colgroup>
<thead>
<tr class="header">
<th rowspan="3">Exchange Direction</th>
<th rowspan="3">Interoperability Test Criteria</th>
<th rowspan="3"><p>State</p>
<p>Design</p>
<p>Check:</p></th>
<th rowspan="3">Notes</th>
<th colspan="10">Test Cases by Scenario</th>
</tr>
<tr class="odd">
<th colspan="3"><blockquote>
<p>CVIEW Sends Vehicle Subscription Update to SAFER</p>
</blockquote></th>
<th colspan="3"><blockquote>
<p>CVIEW Receives Subscription Update for OOS Vehicle</p>
</blockquote></th>
<th><blockquote>
<p>CVIEW Receives Subscription Update for Carrier Snapshot</p>
</blockquote></th>
<th><blockquote>
<p>CVIEW Sends Carrier Subscription Update to SAFER</p>
</blockquote></th>
<th><blockquote>
<p>CVIEW Sends Query for Carrier Snapshot to SAFER</p>
</blockquote></th>
<th><blockquote>
<p>CVIEW Sends Query for Vehicle Snapshot to SAFER</p>
</blockquote></th>
</tr>
<tr class="header">
<th><blockquote>
<p>3.01.01</p>
</blockquote></th>
<th><blockquote>
<p>3.01.02</p>
</blockquote></th>
<th><blockquote>
<p>3.01.03</p>
</blockquote></th>
<th><blockquote>
<p>3.08.01</p>
</blockquote></th>
<th><blockquote>
<p>3.08.02</p>
</blockquote></th>
<th><blockquote>
<p>3.08.03</p>
</blockquote></th>
<th><blockquote>
<p>3.04.01</p>
</blockquote></th>
<th><blockquote>
<p>3.05.01</p>
</blockquote></th>
<th><blockquote>
<p>3.06.01</p>
</blockquote></th>
<th><blockquote>
<p>3.07.01</p>
</blockquote></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>CVIEW to SAFER</td>
<td>5.1.1. CVIEW and SAFER communicate with each other using available
standard communications protocol. Currently, this involves using
mailboxes and SMTP / POP3.</td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td>CVIEW to SAFER</td>
<td>5.1.2. CVIEW sends each kind of valid carrier query using ANSI ASC
X12 EDI transaction set 285 (abbreviated TS 285).</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
</tr>
<tr class="odd">
<td>CVIEW to SAFER</td>
<td>5.1.3. CVIEW sends each kind of valid vehicle query using ANSI X12
TS 285.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td>CVIEW to SAFER</td>
<td>5.1.4. When a carrier snapshot that meets SAFER’s subscription
criteria is changed, CVIEW sends the revised snapshot to SAFER via TS
285.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CVIEW to SAFER</td>
<td>5.1.5. When a vehicle snapshot that meets SAFER’s subscription
criteria is changed, CVIEW sends the revised snapshot to SAFER via TS
285.</td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>SAFER to CVIEW</td>
<td>5.1.6. CVIEW successfully receives each valid carrier TS 285 sent by
SAFER.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
</tr>
<tr class="odd">
<td>SAFER to CVIEW</td>
<td><p>5.1.7. Each kind of valid carrier TS 285 received by CVIEW from
SAFER is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
</tr>
<tr class="even">
<td>SAFER to CVIEW</td>
<td>5.1.8. CVIEW successfully receives each valid vehicle TS 285 sent by
SAFER.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="odd">
<td>SAFER to CVIEW</td>
<td><p>5.1.9. Each kind of valid vehicle TS 285 received by CVIEW from
SAFER is interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td></td>
<td rowspan="5"><p>b. The relationship between this transaction and
previous transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>d. The relationship between the incoming transaction and the response
transaction (if any) is maintained.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>CVIEW to SAFER</td>
<td>5.1.10. CVIEW reports on the application processing of each X12 EDI
TS 285 transmission from SAFER by returning an X12 TS 824 message to
SAFER.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CVIEW to SAFER</td>
<td>5.1.11. CVIEW acknowledges the receipt of each X12 EDI transaction
set from SAFER (except a TS 997) by returning an X12 TS 997 message to
SAFER.</td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td>CVIEW to SAFER</td>
<td>5.1.12. If errors are encountered in deciphering an incoming EDI X12
transaction, a syntax error message is sent to SAFER via X12 TS
997.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>SAFER to CVIEW</td>
<td>5.1.13. CVIEW successfully receives each valid TS 997 sent by
SAFER.</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>SAFER to CVIEW</td>
<td>5.1.14. Each kind of valid TS 997 received by CVIEW from SAFER is
interpreted and handled correctly.</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td>a. The sender is identified and recognized correctly.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td>b. The relationship between this transaction and previous
transactions (if any) is recognized.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td>c. A correct response, based on the input received, is generated, if
appropriate.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td>d. The relationship between the incoming transaction and the
response transaction (if any) is maintained.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td>e. The recipient (if any) is identified and set correctly.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td>f. Codes, data formats and identifiers are set correctly in the
response, if any.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>CVIEW to SAFER</td>
<td>5.1.15. If non-syntax (i.e. “application”) errors are encountered in
interpreting an incoming EDI X12 TS 285 transaction, an error message is
sent to SAFER via X12 TS 824.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>SAFER to CVIEW</td>
<td>5.1.16. CVIEW successfully receives each valid TS 824 sent by
SAFER.</td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>SAFER to CVIEW</td>
<td><p>5.1.17. Each kind of valid TS 824 received by CVIEW from SAFER is
interpreted and handled correctly.</p>
<p>a. The sender is identified and recognized correctly.</p>
<p>b. The relationship between this transaction and previous
transactions (if any) is recognized.</p>
<p>c. A correct response, based on the input received, is generated, if
appropriate.</p>
<p>e. The recipient (if any) is identified and set correctly.</p>
<p>f. Codes, data formats and identifiers are set correctly in the
response, if any.</p></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
</tr>
</tbody>
</table>

## State ASPEN -- Safety and Fitness Electronic Record (SAFER) Inspection Report Exchanges

The state roadside ASPEN interacts with SAFER to request or query for
all inspection reports relating to a particular carrier in ASPEN-Unique,
non-EDI file format. SAFER receives, processes, and sends all inspection
reports matching the query to ASPEN in ASPEN-Unique, non-EDI file
format. An enforcement officer can also conduct an inspection using
ASPEN. ASPEN can send the inspection report to SAFER. The test criteria
shown in Table 5--2 reflect the operational environment using ASPEN
16-bit systems. The data exchanges listed in Table 5-2 are supported in
SAFER versions 1.6.7 to 3 (as planned) and ASPEN versions 1.4 to 2.0.

This table provides a cross-reference to applicable test cases by
scenario, where scenario is defined by ASPEN sending an inspection
report, or ASPEN sending a request for an inspection report, to SAFER.
In all test cases, the ASPEN system is under test. **The test cases
listed in this table are described in detail in the Interoperability
Test Suite Package Part 2: Test Cases and Procedures \[Reference 30\].**

Table 5--2. ASPEN -- SAFER Inspection Report Exchanges

+-----+----------------------------------+---+---+----+----+----+----+
| Ex  | Interoperability Test Criteria   | S | N | Te |    |    |    |
| cha |                                  | t | o | st |    |    |    |
| nge |                                  | a | t | C  |    |    |    |
| Dir |                                  | t | e | as |    |    |    |
| ect |                                  | e | s | es |    |    |    |
| ion |                                  |   |   | by |    |    |    |
|     |                                  | D |   | Sc |    |    |    |
|     |                                  | e |   | en |    |    |    |
|     |                                  | s |   | ar |    |    |    |
|     |                                  | i |   | io |    |    |    |
|     |                                  | g |   |    |    |    |    |
|     |                                  | n |   |    |    |    |    |
|     |                                  |   |   |    |    |    |    |
|     |                                  | C |   |    |    |    |    |
|     |                                  | h |   |    |    |    |    |
|     |                                  | e |   |    |    |    |    |
|     |                                  | c |   |    |    |    |    |
|     |                                  | k |   |    |    |    |    |
|     |                                  | : |   |    |    |    |    |
+=====+==================================+===+===+====+====+====+====+
|     |                                  |   |   | Se |    | Se |    |
|     |                                  |   |   | nd |    | nd |    |
|     |                                  |   |   | In |    | R  |    |
|     |                                  |   |   | sp |    | eq |    |
|     |                                  |   |   | ec |    | ue |    |
|     |                                  |   |   | ti |    | st |    |
|     |                                  |   |   | on |    | f  |    |
|     |                                  |   |   | Re |    | or |    |
|     |                                  |   |   | po |    | In |    |
|     |                                  |   |   | rt |    | sp |    |
|     |                                  |   |   | to |    | ec |    |
|     |                                  |   |   | S  |    | ti |    |
|     |                                  |   |   | AF |    | on |    |
|     |                                  |   |   | ER |    | Re |    |
|     |                                  |   |   |    |    | po |    |
|     |                                  |   |   |    |    | rt |    |
+-----+----------------------------------+---+---+----+----+----+----+
|     |                                  |   |   | 3  | 3  | 3  | 3  |
|     |                                  |   |   | .0 | .0 | .1 | .1 |
|     |                                  |   |   | 9. | 9. | 4. | 4. |
|     |                                  |   |   | 01 | 02 | 01 | 02 |
+-----+----------------------------------+---+---+----+----+----+----+
| AS  | 5.2.1. ASPEN and SAFER           |   |   | X  | X  | X  | X  |
| PEN | communicate with each other      |   |   |    |    |    |    |
| to  | using available standard         |   |   |    |    |    |    |
| SA  | communications protocol. ASPEN   |   |   |    |    |    |    |
| FER | uses dial-up networking,         |   |   |    |    |    |    |
|     | utilizing Remote Access Service  |   |   |    |    |    |    |
|     | (RAS) protocol, Cellular Digital |   |   |    |    |    |    |
|     | Packet Data (CDPD), or Public    |   |   |    |    |    |    |
|     | Switched Telephone Network       |   |   |    |    |    |    |
|     | (PSTN).                          |   |   |    |    |    |    |
+-----+----------------------------------+---+---+----+----+----+----+
| AS  | 5.2.2. ASPEN sends each valid    |   |   | X  |    | X  |    |
| PEN | inspection report or request     |   |   |    |    |    |    |
| to  | using an ASPEN-Unique, non-EDI   |   |   |    |    |    |    |
| SA  | file format. Note: The SAFER     |   |   |    |    |    |    |
| FER | system retrieves the request     |   |   |    |    |    |    |
|     | from its input mailbox in the    |   |   |    |    |    |    |
|     | SAFER Data Mailbox (SDM),        |   |   |    |    |    |    |
|     | processes the request, and then  |   |   |    |    |    |    |
|     | retrieves the inspection report  |   |   |    |    |    |    |
|     | from data storage. The report is |   |   |    |    |    |    |
|     | placed in the requester's query  |   |   |    |    |    |    |
|     | mailbox in the SDM. SAFER        |   |   |    |    |    |    |
|     | maintains past inspections for a |   |   |    |    |    |    |
|     | period of 60 days. ASPEN detects |   |   |    |    |    |    |
|     | and retrieves the report for     |   |   |    |    |    |    |
|     | display on ASPEN.                |   |   |    |    |    |    |
+-----+----------------------------------+---+---+----+----+----+----+
| SA  | 5.2.3. ASPEN receives requested  |   |   |    |    | X  |    |
| FER | inspection reports from SAFER in |   |   |    |    |    |    |
| to  | ASPEN-Unique, non-EDI file       |   |   |    |    |    |    |
| AS  | format.                          |   |   |    |    |    |    |
| PEN |                                  |   |   |    |    |    |    |
+-----+----------------------------------+---+---+----+----+----+----+

## State ASPEN -- Safety and Fitness Electronic Record (SAFER) Snapshot Exchanges

The state roadside ASPEN interacts with SAFER to request carrier
snapshot data or to receive a subscription from SAFER for carrier
snapshots using ASPEN-Unique, non-EDI file format \[basically a Custom
Interface Agreement (CIA) for snapshot exchanges\]. ASPEN posts a
request to SAFER to obtain a specific carrier snapshot. SAFER fulfills a
subscription to ASPEN subscribers to provide updated carrier snapshots.
The data exchanges listed in Table 5-3 are supported in SAFER versions
1.6.7 to 3 (as planned) and ASPEN versions 1.4 to 2.0.

This table provides a cross-reference to applicable test cases by
scenario, where the scenario is defined by ASPEN requesting a carrier
snapshot from SAFER. In all test cases, the ASPEN system is under test.
The Notes column in the table explains those criteria that are either
covered by end-to-end tests or are not part of the interoperability test
suite package. **The test cases listed in this table are described in
detail in the Interoperability Test Suite Package Part 2: Test Cases and
Procedures \[Reference 30\].**

Table 5--3. State ASPEN -- SAFER Snapshot Exchanges

+-----+--------------------------------------+----+---+----+----+----+
| Ex  | Interoperability Test Criteria       | S  | N | Te |    |    |
| cha |                                      | ta | o | st |    |    |
| nge |                                      | te | t | C  |    |    |
| Dir |                                      |    | e | as |    |    |
| ect |                                      | De | s | es |    |    |
| ion |                                      | si |   | by |    |    |
|     |                                      | gn |   | Sc |    |    |
|     |                                      |    |   | en |    |    |
|     |                                      | Ch |   | ar |    |    |
|     |                                      | ec |   | io |    |    |
|     |                                      | k: |   |    |    |    |
+=====+======================================+====+===+====+====+====+
|     |                                      |    |   | A  |    |    |
|     |                                      |    |   | SP |    |    |
|     |                                      |    |   | EN |    |    |
|     |                                      |    |   | Re |    |    |
|     |                                      |    |   | qu |    |    |
|     |                                      |    |   | es |    |    |
|     |                                      |    |   | ts |    |    |
|     |                                      |    |   | C  |    |    |
|     |                                      |    |   | ar |    |    |
|     |                                      |    |   | ri |    |    |
|     |                                      |    |   | er |    |    |
|     |                                      |    |   | Sn |    |    |
|     |                                      |    |   | ap |    |    |
|     |                                      |    |   | sh |    |    |
|     |                                      |    |   | ot |    |    |
|     |                                      |    |   | fr |    |    |
|     |                                      |    |   | om |    |    |
|     |                                      |    |   | S  |    |    |
|     |                                      |    |   | AF |    |    |
|     |                                      |    |   | ER |    |    |
+-----+--------------------------------------+----+---+----+----+----+
|     |                                      |    |   | 3  | 3  | 3  |
|     |                                      |    |   | .1 | .1 | .1 |
|     |                                      |    |   | 5. | 5. | 5. |
|     |                                      |    |   | 01 | 02 | 03 |
+-----+--------------------------------------+----+---+----+----+----+
| AS  | 5.3.1. ASPEN and SAFER communicate   |    |   | X  | X  | X  |
| PEN | with each other using available      |    |   |    |    |    |
| to  | standard communications protocol.    |    |   |    |    |    |
| SA  | ASPEN uses dial-up networking,       |    |   |    |    |    |
| FER | utilizing Remote Access Service      |    |   |    |    |    |
|     | (RAS) protocol, Cellular Digital     |    |   |    |    |    |
|     | Packet Data (CDPD), or Public        |    |   |    |    |    |
|     | Switched Telephone Network (PSTN).   |    |   |    |    |    |
+-----+--------------------------------------+----+---+----+----+----+
| AS  | 5.3.2. ASPEN sends a valid request   |    |   | X  |    | X  |
| PEN | for a specific carrier snapshot to   |    |   |    |    |    |
| to  | SAFER using ASPEN-Unique, non-EDI    |    |   |    |    |    |
| SA  | file format.                         |    |   |    |    |    |
| FER |                                      |    |   |    |    |    |
+-----+--------------------------------------+----+---+----+----+----+
| SA  | 5.3.3. ASPEN successfully receives   |    |   | X  |    |    |
| FER | each valid carrier snapshot sent by  |    |   |    |    |    |
| to  | SAFER in ASPEN-Unique, non-EDI       |    |   |    |    |    |
| AS  | format.                              |    |   |    |    |    |
| PEN |                                      |    |   |    |    |    |
+-----+--------------------------------------+----+---+----+----+----+
| SA  | 5.3.4. ASPEN successfully receives   |    | 1 |    |    |    |
| FER | each valid carrier snapshot (as a    |    |   |    |    |    |
| to  | result of a subscription) sent by    |    |   |    |    |    |
| AS  | SAFER using ASPEN-Unique, non-EDI    |    |   |    |    |    |
| PEN | format.                              |    |   |    |    |    |
+-----+--------------------------------------+----+---+----+----+----+
| SA  | 5.3.5. If errors are encountered in  |    |   |    | X  |    |
| FER | deciphering a carrier snapshot       |    |   |    |    |    |
| to  | request, a syntax error message is   |    |   |    |    |    |
| AS  | sent to ASPEN in ASPEN-Unique,       |    |   |    |    |    |
| PEN | non-EDI format, and ASPEN            |    |   |    |    |    |
|     | successfully receives it.            |    |   |    |    |    |
+-----+--------------------------------------+----+---+----+----+----+
| SA  | 5.3.6. ASPEN can detect syntax or    |    |   |    |    | X  |
| FER | data errors in deciphering a         |    |   |    |    |    |
| to  | badly-formed carrier snapshot sent   |    |   |    |    |    |
| AS  | by SAFER. The ASPEN system displays  |    |   |    |    |    |
| PEN | a message to the operator.           |    |   |    |    |    |
+-----+--------------------------------------+----+---+----+----+----+

Notes:

1\. Not included in this set of Interoperability Tests.

## State ASPEN -- State Commercial Vehicle Information Exchange Window (CVIEW) Inspection Report Exchanges

The state roadside ASPEN interacts with CVIEW to request or query for
all inspection reports relating to a particular carrier in ASPEN-Unique,
non-EDI file format. CVIEW receives, processes, and sends all inspection
reports matching the query to ASPEN in ASPEN-Unique, non-EDI file
format. An enforcement officer can also conduct an inspection using
ASPEN. ASPEN can send the inspection report to CVIEW. The test criteria
shown in table 5--4 reflect the operational environment using ASPEN
32-bit systems (version 2.0). The data exchanges listed in Table 5-4
will be supported in CVIEW version 3 (as planned) and ASPEN version 2.0.

This table provides a cross-reference to applicable test cases by
scenario, where scenario is defined by ASPEN sending an inspection
report, or ASPEN sending a request for an inspection report, to CVIEW.
In all test cases, the ASPEN system is under test. The Notes column in
the table explains those criteria that are either covered by end-to-end
tests or are not part of the interoperability test suite package. **The
test cases listed in this table are described in detail in the
Interoperability Test Suite Package Part 2: Test Cases and Procedures
\[Reference 30\].**

Table 5--4. ASPEN -- CVIEW Inspection Report Exchanges

+-------+---------------------------+----+----+-----------+-----------+
| Exc   | Interoperability Test     | S  | N  | Test      |           |
| hange | Criteria                  | ta | ot | Cases by  |           |
| Dire  |                           | te | es | Scenario  |           |
| ction |                           |    |    |           |           |
|       |                           | De |    |           |           |
|       |                           | si |    |           |           |
|       |                           | gn |    |           |           |
|       |                           |    |    |           |           |
|       |                           | Ch |    |           |           |
|       |                           | ec |    |           |           |
|       |                           | k: |    |           |           |
+=======+===========================+====+====+===========+===========+
|       |                           |    |    | Send      | Send      |
|       |                           |    |    | I         | Request   |
|       |                           |    |    | nspection | for       |
|       |                           |    |    | Report to | I         |
|       |                           |    |    | CVIEW     | nspection |
|       |                           |    |    |           | Report    |
+-------+---------------------------+----+----+-----------+-----------+
|       |                           |    |    | 4.09.01   | 4.08.01   |
+-------+---------------------------+----+----+-----------+-----------+
| ASPEN | 5.4.1. ASPEN and CVIEW    |    | 1  | X         | X         |
| to    | communicate with each     |    |    |           |           |
| CVIEW | other using available     |    |    |           |           |
|       | standard communications   |    |    |           |           |
|       | protocol. ASPEN uses      |    |    |           |           |
|       | dial-up networking,       |    |    |           |           |
|       | utilizing Remote Access   |    |    |           |           |
|       | Service (RAS) protocol,   |    |    |           |           |
|       | Cellular Digital Packet   |    |    |           |           |
|       | Data (CDPD), or Public    |    |    |           |           |
|       | Switched Telephone        |    |    |           |           |
|       | Network (PSTN).           |    |    |           |           |
+-------+---------------------------+----+----+-----------+-----------+
| ASPEN | 5.4.2. ASPEN sends a      |    | 1  |           | X         |
| to    | valid request for a       |    |    |           |           |
| CVIEW | specific inspection       |    |    |           |           |
|       | report to CVIEW using     |    |    |           |           |
|       | ASPEN-Unique, non-EDI     |    |    |           |           |
|       | format.                   |    |    |           |           |
+-------+---------------------------+----+----+-----------+-----------+
| ASPEN | 5.4.3. CVIEW receives,    |    | 1  | X         | X         |
| to    | processes an incoming     |    |    |           |           |
| CVIEW | inspection report         |    |    |           |           |
|       | (forwards to SAFER) or in |    |    |           |           |
|       | the case of a request,    |    |    |           |           |
|       | receives, processes       |    |    |           |           |
|       | (i.e., forwards to SAFER  |    |    |           |           |
|       | and receives response),   |    |    |           |           |
|       | and sends all inspection  |    |    |           |           |
|       | reports matching the      |    |    |           |           |
|       | request to ASPEN in       |    |    |           |           |
|       | ASPEN-unique, non-EDI     |    |    |           |           |
|       | format.                   |    |    |           |           |
+-------+---------------------------+----+----+-----------+-----------+
| CVIEW | 5.4.4. ASPEN receives     |    | 1  |           | X         |
| to    | requested inspection      |    |    |           |           |
| ASPEN | reports from CVIEW in     |    |    |           |           |
|       | ASPEN-Unique, non-EDI     |    |    |           |           |
|       | file format.              |    |    |           |           |
+-------+---------------------------+----+----+-----------+-----------+

> Notes:
>
> 1\. The indicated tests are end-to-end tests.

## State ASPEN -- State Commercial Vehicle Information Exchange Window (CVIEW) Snapshot Exchanges

The state roadside ASPEN (version 2.0) will interact with CVIEW (version
3 as planned) to request carrier snapshot data or to receive a
subscription from CVIEW for carrier snapshots using ASPEN-Unique,
non-EDI file format \[basically a Custom Interface Agreement (CIA) for
snapshot exchanges\]. ASPEN posts a request to CVIEW to obtain a
specific carrier snapshot. CVIEW fulfills a subscription to ASPEN
subscribers to provide updated carrier snapshots. The data exchanges
listed in Table 5-5 are planned for supported in CVIEW version 3 and
ASPEN version 2.0.

This table provides a cross-reference to applicable test cases by
scenario, where scenario is defined by ASPEN sending an inspection
report, or ASPEN sending a request for an inspection report, to CVIEW.
In all test cases, the ASPEN system is under test. The Notes column in
the table explains those criteria that are either covered by end-to-end
tests or are not part of the interoperability test suite package. **The
test cases listed in this table are described in detail in the
Interoperability Test Suite Package Part 2: Test Cases and Procedures
\[Reference 30\].**

Table 5--5. State ASPEN -- CVIEW Snapshot Exchanges

+------+-------------------------------------+----+----+------+-------+
| Exch | Interoperability Test Criteria      | S  | N  | Test |       |
| ange |                                     | ta | ot | C    |       |
| D    |                                     | te | es | ases |       |
| irec |                                     |    |    | by   |       |
| tion |                                     | De |    | Scen |       |
|      |                                     | si |    | ario |       |
|      |                                     | gn |    |      |       |
|      |                                     |    |    |      |       |
|      |                                     | Ch |    |      |       |
|      |                                     | ec |    |      |       |
|      |                                     | k: |    |      |       |
+======+=====================================+====+====+======+=======+
|      |                                     |    |    | A    |       |
|      |                                     |    |    | SPEN |       |
|      |                                     |    |    | Requ |       |
|      |                                     |    |    | ests |       |
|      |                                     |    |    | Car  |       |
|      |                                     |    |    | rier |       |
|      |                                     |    |    | Snap |       |
|      |                                     |    |    | shot |       |
|      |                                     |    |    | from |       |
|      |                                     |    |    | C    |       |
|      |                                     |    |    | VIEW |       |
+------+-------------------------------------+----+----+------+-------+
|      |                                     |    |    | 3.0  | 3.    |
|      |                                     |    |    | 3.01 | 03.02 |
+------+-------------------------------------+----+----+------+-------+
| A    | 5.5.1. ASPEN and CVIEW communicate  |    |    | x    | x     |
| SPEN | with each other using available     |    |    |      |       |
| to   | standard communications protocol.   |    |    |      |       |
| C    | ASPEN uses dial-up networking,      |    |    |      |       |
| VIEW | utilizing Remote Access Service     |    |    |      |       |
|      | (RAS) protocol, Cellular Digital    |    |    |      |       |
|      | Packet Data (CDPD), or Public       |    |    |      |       |
|      | Switched Telephone Network (PSTN).  |    |    |      |       |
+------+-------------------------------------+----+----+------+-------+
| A    | 5.5.2. ASPEN sends a valid request  |    |    | x    | x     |
| SPEN | for a specific carrier snapshot to  |    |    |      |       |
| to   | CVIEW using ASPEN-unique, non-EDI   |    |    |      |       |
| C    | format.                             |    |    |      |       |
| VIEW |                                     |    |    |      |       |
+------+-------------------------------------+----+----+------+-------+
| A    | 5.5.3. CVIEW successfully receives  |    |    | x    | x     |
| SPEN | each valid carrier snapshot request |    |    |      |       |
| to   | from ASPEN.                         |    |    |      |       |
| C    |                                     |    |    |      |       |
| VIEW |                                     |    |    |      |       |
+------+-------------------------------------+----+----+------+-------+
| C    | 5.5.4. CVIEW sends each valid       |    |    | x    |       |
| VIEW | carrier snapshot as a result of a   |    |    |      |       |
| to   | query in ASPEN-unique, non-EDI      |    |    |      |       |
| A    | format to ASPEN.                    |    |    |      |       |
| SPEN |                                     |    |    |      |       |
+------+-------------------------------------+----+----+------+-------+
| C    | 5.5.5. ASPEN successfully receives  |    |    | x    |       |
| VIEW | each valid carrier snapshot sent by |    |    |      |       |
| to   | CVIEW in ASPEN-unique, non-EDI      |    |    |      |       |
| A    | format.                             |    |    |      |       |
| SPEN |                                     |    |    |      |       |
+------+-------------------------------------+----+----+------+-------+
| C    | 5.5.6. ASPEN successfully receives  |    | 1  |      |       |
| VIEW | each valid carrier snapshot (as a   |    |    |      |       |
| to   | result of a subscription) sent by   |    |    |      |       |
| A    | CVIEW using ASPEN-Unique, non-EDI   |    |    |      |       |
| SPEN | format.                             |    |    |      |       |
+------+-------------------------------------+----+----+------+-------+
| C    | 5.5.7. If errors are encountered in |    |    |      | x     |
| VIEW | deciphering a carrier snapshot      |    |    |      |       |
| to   | request, a syntax error message is  |    |    |      |       |
| A    | sent to ASPEN in ASPEN-Unique,      |    |    |      |       |
| SPEN | non-EDI format, and ASPEN           |    |    |      |       |
|      | successfully receives it.           |    |    |      |       |
+------+-------------------------------------+----+----+------+-------+
| C    | 5.5.8. If ASPEN cannot interpret    |    | 2  |      |       |
| VIEW | incoming carrier snapshot data due  |    |    |      |       |
| to   | to wrong format sent from CVIEW,    |    |    |      |       |
| A    | ASPEN displays message.             |    |    |      |       |
| SPEN |                                     |    |    |      |       |
+------+-------------------------------------+----+----+------+-------+

Notes:

1.  ASPEN subscriptions are not part of test suite procedures.

2.  ASPEN error displays are not part of test suite procedures.

## State Roadside Operations -- State Commercial Vehicle Information Exchange Window (CVIEW) Snapshot Exchanges

The generic state roadside operations (Roadside Operations system that
supports electronic screening and/or safety and credentials checks)
interacts with CVIEW (versions 1.6.7 to 2.4) to receive snapshot
segment/views. The roadside operations may post snapshot requests and
receive responses. The interoperability test criteria are based on the
TS 285 Implementation Guide for CV Safety and Credentials Information
Exchange \[Reference 18\].

This table provides a cross-reference to applicable test cases by
scenario, where scenario is defined by the roadside operations computer
requesting a vehicle snapshot from CVIEW. In all test cases, the
roadside system is under test. The Notes column in the table explains
those criteria that are either covered by end-to-end tests or are not
part of the interoperability test suite package. **The test cases listed
in this table are described in detail in the Interoperability Test Suite
Package Part 2: Test Cases and Procedures \[Reference 30\].**

Table 5--6. State Roadside Operations -- CVIEW Snapshot Exchanges

+-------+-------------------------------------+---+---+----+----+----+
| Exc   | Interoperability Test Criteria      | S | N | Te |    |    |
| hange |                                     | t | o | st |    |    |
| Dire  |                                     | a | t | C  |    |    |
| ction |                                     | t | e | as |    |    |
|       |                                     | e | s | es |    |    |
|       |                                     |   |   | by |    |    |
|       |                                     | D |   | Sc |    |    |
|       |                                     | e |   | en |    |    |
|       |                                     | s |   | ar |    |    |
|       |                                     | i |   | io |    |    |
|       |                                     | g |   |    |    |    |
|       |                                     | n |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       |                                     | C |   |    |    |    |
|       |                                     | h |   |    |    |    |
|       |                                     | e |   |    |    |    |
|       |                                     | c |   |    |    |    |
|       |                                     | k |   |    |    |    |
|       |                                     | : |   |    |    |    |
+=======+=====================================+===+===+====+====+====+
|       |                                     |   |   | Ro |    |    |
|       |                                     |   |   | ad |    |    |
|       |                                     |   |   | si |    |    |
|       |                                     |   |   | de |    |    |
|       |                                     |   |   | Re |    |    |
|       |                                     |   |   | qu |    |    |
|       |                                     |   |   | es |    |    |
|       |                                     |   |   | ts |    |    |
|       |                                     |   |   | V  |    |    |
|       |                                     |   |   | eh |    |    |
|       |                                     |   |   | ic |    |    |
|       |                                     |   |   | le |    |    |
|       |                                     |   |   | Sn |    |    |
|       |                                     |   |   | ap |    |    |
|       |                                     |   |   | sh |    |    |
|       |                                     |   |   | ot |    |    |
|       |                                     |   |   | fr |    |    |
|       |                                     |   |   | om |    |    |
|       |                                     |   |   | C  |    |    |
|       |                                     |   |   | VI |    |    |
|       |                                     |   |   | EW |    |    |
|       |                                     |   |   | u  |    |    |
|       |                                     |   |   | si |    |    |
|       |                                     |   |   | ng |    |    |
|       |                                     |   |   | V  |    |    |
|       |                                     |   |   | IN |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       |                                     |   |   | 3  | 3  | 3  |
|       |                                     |   |   | .0 | .0 | .0 |
|       |                                     |   |   | 2. | 2. | 2. |
|       |                                     |   |   | 01 | 02 | 03 |
+-------+-------------------------------------+---+---+----+----+----+
| Roa   | 5.6.1. Roadside Operations and      |   |   | X  | X  | X  |
| dside | CVIEW communicate with each other   |   |   |    |    |    |
| Opera | using available standard            |   |   |    |    |    |
| tions | communications protocol. Currently, |   |   |    |    |    |
| to    | this involves using mailboxes and   |   |   |    |    |    |
| CVIEW | SMTP / POP3. The CVIEW server has   |   |   |    |    |    |
|       | several mailboxes: two for each of  |   |   |    |    |    |
|       | its subscribers. One of the pair of |   |   |    |    |    |
|       | mailboxes per subscriber is used    |   |   |    |    |    |
|       | for subscription updates, the other |   |   |    |    |    |
|       | for query responses. There is a     |   |   |    |    |    |
|       | common mailbox where queries are    |   |   |    |    |    |
|       | posted.                             |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| Roa   | 5.6.2. Roadside Operations sends    |   | 2 |    |    |    |
| dside | each kind of valid carrier snapshot |   |   |    |    |    |
| Opera | request using ANSI ASC X12 EDI      |   |   |    |    |    |
| tions | transaction set 285 (abbreviated TS |   |   |    |    |    |
| to    | 285).                               |   |   |    |    |    |
| CVIEW |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| Roa   | 5.6.3. Roadside Operations sends    |   |   | X  | X  | X  |
| dside | each kind of valid vehicle snapshot |   |   |    |    |    |
| Opera | request using TS 285.               |   |   |    |    |    |
| tions |                                     |   |   |    |    |    |
| to    |                                     |   |   |    |    |    |
| CVIEW |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | 5.6.4. When a carrier snapshot that |   | 2 |    |    |    |
| to    | meets a state Roadside Operation's  |   |   |    |    |    |
| Roa   | subscription criteria is changed,   |   |   |    |    |    |
| dside | CVIEW sends the revised snapshot    |   |   |    |    |    |
| Opera | using TS 285 to that Roadside       |   |   |    |    |    |
| tions | Operations. If the subscription     |   |   |    |    |    |
|       | criteria specify that the updated   |   |   |    |    |    |
|       | snapshot is to be sent only if      |   |   |    |    |    |
|       | certain data items have changed,    |   |   |    |    |    |
|       | the message is sent only if one or  |   |   |    |    |    |
|       | more of those data items were       |   |   |    |    |    |
|       | altered.                            |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | 5.6.5. When a vehicle snapshot that |   | 2 |    |    |    |
| to    | meets a state Roadside Operation's  |   |   |    |    |    |
| Roa   | subscription criteria is changed,   |   |   |    |    |    |
| dside | CVIEW sends the revised snapshot    |   |   |    |    |    |
| Opera | using TS 285 to that Roadside       |   |   |    |    |    |
| tions | Operations. If the subscription     |   |   |    |    |    |
|       | criteria specify that the updated   |   |   |    |    |    |
|       | snapshot is to be sent only if      |   |   |    |    |    |
|       | certain data items have changed,    |   |   |    |    |    |
|       | the message is sent only if one or  |   |   |    |    |    |
|       | more of those data items were       |   |   |    |    |    |
|       | altered.                            |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | 5.6.6. Roadside Operations          |   | 1 |    |    |    |
| to    | successfully receives each valid    |   |   |    |    |    |
| Roa   | carrier TS 285 sent by CVIEW.       |   |   |    |    |    |
| dside |                                     |   |   |    |    |    |
| Opera |                                     |   |   |    |    |    |
| tions |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | 5.6.7. Each kind of valid carrier   |   | 1 |    |    |    |
| to    | TS 285 received by Roadside         |   |   |    |    |    |
| Roa   | Operations from CVIEW is            |   |   |    |    |    |
| dside | interpreted and handled correctly.  |   |   |    |    |    |
| Opera |                                     |   |   |    |    |    |
| tions |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | a\. The sender is identified and    |   |   |    |    |    |
|       | recognized correctly.               |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | b\. The relationship between this   |   |   |    |    |    |
|       | transaction and previous            |   |   |    |    |    |
|       | transactions (if any) is            |   |   |    |    |    |
|       | recognized.                         |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | c\. A correct response, based on    |   |   |    |    |    |
|       | the input received, is generated,   |   |   |    |    |    |
|       | if appropriate.                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | d\. The relationship between the    |   |   |    |    |    |
|       | incoming transaction and the        |   |   |    |    |    |
|       | response transaction (if any) is    |   |   |    |    |    |
|       | maintained.                         |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | e\. The recipient (if any) is       |   |   |    |    |    |
|       | identified and set correctly.       |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | f\. Codes, data formats and         |   |   |    |    |    |
|       | identifiers are set correctly in    |   |   |    |    |    |
|       | the response, if any.               |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | 5.6.8. CVIEW sends each kind of     |   | 2 |    |    |    |
| to    | valid carrier snapshot              |   |   |    |    |    |
| Roa   | view/segment, or response using TS  |   |   |    |    |    |
| dside | 285.                                |   |   |    |    |    |
| Opera |                                     |   |   |    |    |    |
| tions |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | 5\. 6.9. CVIEW sends each kind of   |   |   | X  |    |    |
| to    | valid vehicle snapshot view/segment |   |   |    |    |    |
| Roa   | or response using TS 285.           |   |   |    |    |    |
| dside |                                     |   |   |    |    |    |
| Opera |                                     |   |   |    |    |    |
| tions |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| Roa   | 5.6.10. CVIEW successfully receives |   |   | X  |    |    |
| dside | each valid carrier/vehicle query    |   |   |    |    |    |
| Opera | from Roadside Operations.           |   |   |    |    |    |
| tions |                                     |   |   |    |    |    |
| to    |                                     |   |   |    |    |    |
| CVIEW |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| Roa   | 5.6.11. Each kind of valid TS 285   |   |   | X  |    |    |
| dside | carrier/vehicle query received by   |   |   |    |    |    |
| Opera | CVIEW is interpreted and handled    |   |   |    |    |    |
| tions | correctly.                          |   |   |    |    |    |
| to    |                                     |   |   |    |    |    |
| CVIEW |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | a\. The sender is identified and    |   |   |    |    |    |
|       | recognized correctly.               |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | b\. The relationship between this   |   |   |    |    |    |
|       | transaction and previous            |   |   |    |    |    |
|       | transactions (if any) is            |   |   |    |    |    |
|       | recognized.                         |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | c\. A correct response, based on    |   |   |    |    |    |
|       | the input received, is generated,   |   |   |    |    |    |
|       | if appropriate.                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | d\. The relationship between the    |   |   |    |    |    |
|       | incoming transaction and the        |   |   |    |    |    |
|       | response transaction (if any) is    |   |   |    |    |    |
|       | maintained.                         |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | e\. The recipient (if any) is       |   |   |    |    |    |
|       | identified and set correctly.       |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | f\. Codes, data formats and         |   |   |    |    |    |
|       | identifiers are set correctly in    |   |   |    |    |    |
|       | the response, if any.               |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | 5.6.12. Roadside Operations         |   |   | X  |    | X  |
| to    | successfully receives each valid    |   |   |    |    |    |
| Roa   | vehicle TS 285 sent by CVIEW.       |   |   |    |    |    |
| dside |                                     |   |   |    |    |    |
| Opera |                                     |   |   |    |    |    |
| tions |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | 5.6.13. Each kind of valid vehicle  |   |   | X  |    | X  |
| to    | TS 285 received by Roadside         |   |   |    |    |    |
| Roa   | Operations from CVIEW is            |   |   |    |    |    |
| dside | interpreted and handled correctly.  |   |   |    |    |    |
| Opera |                                     |   |   |    |    |    |
| tions |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | a\. The sender is identified and    |   |   |    |    |    |
|       | recognized correctly.               |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | b\. The relationship between this   |   |   |    |    |    |
|       | transaction and previous            |   |   |    |    |    |
|       | transactions (if any) is            |   |   |    |    |    |
|       | recognized.                         |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | c\. A correct response, based on    |   |   |    |    |    |
|       | the input received, is generated,   |   |   |    |    |    |
|       | if appropriate.                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | d\. The relationship between the    |   |   |    |    |    |
|       | incoming transaction and the        |   |   |    |    |    |
|       | response transaction (if any) is    |   |   |    |    |    |
|       | maintained.                         |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | e\. The recipient (if any) is       |   |   |    |    |    |
|       | identified and set correctly.       |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
|       | f\. Codes, data formats and         |   |   |    |    |    |
|       | identifiers are set correctly in    |   |   |    |    |    |
|       | the response, if any.               |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| Roa   | 5.6.14. Roadside Operations         |   |   | X  |    | X  |
| dside | acknowledges the receipt of each    |   |   |    |    |    |
| Opera | X12 EDI transmission from CVIEW     |   |   |    |    |    |
| tions | (except a TS 997) by returning an   |   |   |    |    |    |
| to    | X12 TS 997 message to CVIEW.        |   |   |    |    |    |
| CVIEW |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | 5.6.15. If errors are encountered   |   | 2 |    |    |    |
| to    | in deciphering an incoming EDI X12  |   |   |    |    |    |
| Roa   | transaction, a syntax error message |   |   |    |    |    |
| dside | is sent to Roadside Operations via  |   |   |    |    |    |
| Opera | X12 TS 997.                         |   |   |    |    |    |
| tions |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| Roa   | 5.6.16. If errors are encountered   |   |   |    | X  |    |
| dside | in deciphering an incoming EDI X12  |   |   |    |    |    |
| Opera | transaction, a syntax error message |   |   |    |    |    |
| tions | is sent to CVIEW via X12 TS 997.    |   |   |    |    |    |
| to    |                                     |   |   |    |    |    |
| CVIEW |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | 5.6.17. Roadside Operations         |   |   | X  | X  | X  |
| to    | successfully receives each valid TS |   |   |    |    |    |
| Roa   | 997 sent by CVIEW.                  |   |   |    |    |    |
| dside |                                     |   |   |    |    |    |
| Opera |                                     |   |   |    |    |    |
| tions |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | 5.6.18. Each kind of valid TS 997   |   |   | X  | X  | X  |
| to    | received by Roadside Operations     |   |   |    |    |    |
| Roa   | from CVIEW is interpreted and       |   |   |    |    |    |
| dside | handled correctly.                  |   |   |    |    |    |
| Opera |                                     |   |   |    |    |    |
| tions | a\. The sender is identified and    |   |   |    |    |    |
|       | recognized correctly.               |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | b\. The relationship between this   |   |   |    |    |    |
|       | transaction and previous            |   |   |    |    |    |
|       | transactions (if any) is            |   |   |    |    |    |
|       | recognized.                         |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | c\. A correct response, based on    |   |   |    |    |    |
|       | the input received, is generated,   |   |   |    |    |    |
|       | if appropriate.                     |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | d\. The relationship between the    |   |   |    |    |    |
|       | incoming transaction and the        |   |   |    |    |    |
|       | response transaction (if any) is    |   |   |    |    |    |
|       | maintained.                         |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | e\. The recipient (if any) is       |   |   |    |    |    |
|       | identified and set correctly.       |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | f\. Codes, data formats and         |   |   |    |    |    |
|       | identifiers are set correctly in    |   |   |    |    |    |
|       | the response, if any.               |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | 5.6.19. CVIEW acknowledges the      |   |   | X  | X  | X  |
| to    | receipt of each X12 EDI             |   |   |    |    |    |
| Roa   | transmission from Roadside          |   |   |    |    |    |
| dside | Operations (except a TS 997) by     |   |   |    |    |    |
| Opera | returning an X12 TS 997 message to  |   |   |    |    |    |
| tions | Roadside Operations.                |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| Roa   | 5.6.20. CVIEW successfully receives |   |   | X  | X  | X  |
| dside | each valid TS 997 sent by Roadside  |   |   |    |    |    |
| Opera | Operations.                         |   |   |    |    |    |
| tions |                                     |   |   |    |    |    |
| to    |                                     |   |   |    |    |    |
| CVIEW |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| Roa   | 5.6.21. Each kind of valid TS 997   |   |   | X  | X  | X  |
| dside | received by CVIEW from Roadside     |   |   |    |    |    |
| Opera | Operations is interpreted and       |   |   |    |    |    |
| tions | handled correctly.                  |   |   |    |    |    |
| to    |                                     |   |   |    |    |    |
| CVIEW | a\. The sender is identified and    |   |   |    |    |    |
|       | recognized correctly.               |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | b\. The relationship between this   |   |   |    |    |    |
|       | transaction and previous            |   |   |    |    |    |
|       | transactions (if any) is            |   |   |    |    |    |
|       | recognized.                         |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | c\. A correct response, based on    |   |   |    |    |    |
|       | the input received, is generated,   |   |   |    |    |    |
|       | if appropriate.                     |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | d\. The relationship between the    |   |   |    |    |    |
|       | incoming transaction and the        |   |   |    |    |    |
|       | response transaction (if any) is    |   |   |    |    |    |
|       | maintained.                         |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | e\. The recipient (if any) is       |   |   |    |    |    |
|       | identified and set correctly.       |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | f\. Codes, data formats and         |   |   |    |    |    |
|       | identifiers are set correctly in    |   |   |    |    |    |
|       | the response, if any.               |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | 5.6.22. If non-syntax (i.e.         |   | 2 |    |    |    |
| to    | "application") errors are           |   |   |    |    |    |
| Roa   | encountered in interpreting an      |   |   |    |    |    |
| dside | incoming EDI X12 TS 285             |   |   |    |    |    |
| Opera | transaction, an error message is    |   |   |    |    |    |
| tions | sent to Roadside Operations via X12 |   |   |    |    |    |
|       | TS 824.                             |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| Roa   | 5.6.23. If non-syntax (i.e.         |   |   |    |    | X  |
| dside | "application") errors are           |   |   |    |    |    |
| Opera | encountered in interpreting an      |   |   |    |    |    |
| tions | incoming EDI X12 TS 285             |   |   |    |    |    |
| to    | transaction, an error message is    |   |   |    |    |    |
| CVIEW | sent to CVIEW via X12 TS 824.       |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | 5.6.24. Roadside Operations         |   |   | X  |    |    |
| to    | successfully receives each valid TS |   |   |    |    |    |
| Roa   | 824 sent by CVIEW.                  |   |   |    |    |    |
| dside |                                     |   |   |    |    |    |
| Opera |                                     |   |   |    |    |    |
| tions |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | 5.6.25. Each kind of valid TS 824   |   |   | X  |    |    |
| to    | received by Roadside Operations     |   |   |    |    |    |
| Roa   | from CVIEW is interpreted and       |   |   |    |    |    |
| dside | handled correctly.                  |   |   |    |    |    |
| Opera |                                     |   |   |    |    |    |
| tions | a\. The sender is identified and    |   |   |    |    |    |
|       | recognized correctly.               |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | b\. The relationship between this   |   |   |    |    |    |
|       | transaction and previous            |   |   |    |    |    |
|       | transactions (if any) is            |   |   |    |    |    |
|       | recognized.                         |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | c\. A correct response, based on    |   |   |    |    |    |
|       | the input received, is generated,   |   |   |    |    |    |
|       | if appropriate.                     |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | d\. The relationship between the    |   |   |    |    |    |
|       | incoming transaction and the        |   |   |    |    |    |
|       | response transaction (if any) is    |   |   |    |    |    |
|       | maintained.                         |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | e\. The recipient (if any) is       |   |   |    |    |    |
|       | identified and set correctly.       |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | f\. Codes, data formats and         |   |   |    |    |    |
|       | identifiers are set correctly in    |   |   |    |    |    |
|       | the response, if any.               |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| CVIEW | > 5.6.26. CVIEW reports on the      |   | 2 |    |    |    |
| to    | > application processing of each    |   |   |    |    |    |
| Roa   | > X12 EDI 285 transmission from     |   |   |    |    |    |
| dside | > Roadside Operations by returning  |   |   |    |    |    |
| Opera | > an X12 TS 824 message to Roadside |   |   |    |    |    |
| tions | > Operations. *Exception: A TS 824  |   |   |    |    |    |
|       | > is not expected for query         |   |   |    |    |    |
|       | > responses; i.e., queries that     |   |   |    |    |    |
|       | > were satisfied.*                  |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| Roa   | CVIEW successfully receives each    |   | 1 |    |    |    |
| dside | valid TS 824 sent by Roadside       |   |   |    |    |    |
| Opera | Operations.                         |   |   |    |    |    |
| tions |                                     |   |   |    |    |    |
| to    |                                     |   |   |    |    |    |
| CVIEW |                                     |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+
| Roa   | 5.6.28. Each kind of valid TS 824   |   | 1 |    |    |    |
| dside | received by CVIEW from Roadside     |   |   |    |    |    |
| Opera | Operations is interpreted and       |   |   |    |    |    |
| tions | handled correctly.                  |   |   |    |    |    |
| to    |                                     |   |   |    |    |    |
| CVIEW | a\. The sender is identified and    |   |   |    |    |    |
|       | recognized correctly.               |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | b\. The relationship between this   |   |   |    |    |    |
|       | transaction and previous            |   |   |    |    |    |
|       | transactions (if any) is            |   |   |    |    |    |
|       | recognized.                         |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | c\. A correct response, based on    |   |   |    |    |    |
|       | the input received, is generated,   |   |   |    |    |    |
|       | if appropriate.                     |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | d\. The relationship between the    |   |   |    |    |    |
|       | incoming transaction and the        |   |   |    |    |    |
|       | response transaction (if any) is    |   |   |    |    |    |
|       | maintained.                         |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | e\. The recipient (if any) is       |   |   |    |    |    |
|       | identified and set correctly.       |   |   |    |    |    |
|       |                                     |   |   |    |    |    |
|       | f\. Codes, data formats and         |   |   |    |    |    |
|       | identifiers are set correctly in    |   |   |    |    |    |
|       | the response, if any.               |   |   |    |    |    |
+-------+-------------------------------------+---+---+----+----+----+

Notes:

1\. Not included in Pairwise Interoperability Tests; function is tested
in end-to-end test ETE-03;

2\. Not included in this set of Pairwise Interoperability Tests.

# End-To-End Interface Interoperability Criteria

In this draft, interoperability test criteria are presented for
end-to-end testing. End-to-end tests demonstrate conformance to key
operational concepts across multiple systems. End-to-End tests provide
implicit verification of standards by looking at the overall results
from multiple systems working together. This contrasts with pairwise
tests that explicitly test transactions flowing across interfaces. In
summary, these test criteria will focus in the following areas:

-   Verify that standard identifiers can be recognized and snapshots
    accessed successfully

-   Verify that selected fields in snapshots are interpreted uniformly

-   Verify that required fields in credentials applications are
    interpreted uniformly

-   Verify that inspection reporting is uniform

Table 6-1 provides a cross-reference to applicable test cases by
scenario, where scenario is defined by the specific end-to-end test of
interest. Note that the exchange direction is not applicable for these
tests, and is not included in the table. Nor is the "Notes" column
included since all criteria are tested by at least one test case. **The
test cases listed in this table are described in detail in the
Interoperability Test Suite Package Part 2: Test Cases and Procedures
\[Reference 30\].**

> Table 6--1. End--to--End Interoperability Test Criteria

<table>
<colgroup>
<col style="width: 41%" />
<col style="width: 6%" />
<col style="width: 3%" />
<col style="width: 4%" />
<col style="width: 3%" />
<col style="width: 3%" />
<col style="width: 3%" />
<col style="width: 2%" />
<col style="width: 3%" />
<col style="width: 3%" />
<col style="width: 3%" />
<col style="width: 3%" />
<col style="width: 3%" />
<col style="width: 4%" />
<col style="width: 5%" />
<col style="width: 3%" />
</colgroup>
<thead>
<tr class="header">
<th rowspan="3">Interoperability Test Criteria</th>
<th rowspan="3"><p>State</p>
<p>Design</p>
<p>Check</p></th>
<th colspan="14">Test Cases by Scenario</th>
</tr>
<tr class="odd">
<th>IRP Add Vehicle</th>
<th>Web-based</th>
<th><blockquote>
<p>Vehicle Inspection</p>
</blockquote></th>
<th colspan="3"><blockquote>
<p>Screening</p>
</blockquote></th>
<th><blockquote>
<p>IRP Add Jurisdiction</p>
</blockquote></th>
<th><blockquote>
<p>Web-based</p>
</blockquote></th>
<th><blockquote>
<p>IRP Renewal</p>
</blockquote></th>
<th><blockquote>
<p>Web-based</p>
</blockquote></th>
<th><blockquote>
<p>IFTA Renewal</p>
</blockquote></th>
<th><blockquote>
<p>Web-based</p>
</blockquote></th>
<th><blockquote>
<p>IFTA Quarterly Tax Filing</p>
</blockquote></th>
<th>Web-based</th>
</tr>
<tr class="header">
<th>4.01.01</th>
<th>5.01.01</th>
<th><blockquote>
<p>4.02.01</p>
</blockquote></th>
<th><blockquote>
<p>4.03.01</p>
</blockquote></th>
<th><blockquote>
<p>4.03.02</p>
</blockquote></th>
<th><blockquote>
<p>4.03.03</p>
</blockquote></th>
<th><blockquote>
<p>4.04.01</p>
</blockquote></th>
<th><p>5.04.01</p>
<p>X</p></th>
<th><blockquote>
<p>4.05.01</p>
</blockquote></th>
<th><blockquote>
<p>5.05.01</p>
</blockquote></th>
<th><blockquote>
<p>4.06.01</p>
</blockquote></th>
<th><blockquote>
<p>5.06.01</p>
</blockquote></th>
<th>4.07.01</th>
<th>5.07.01</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>6.1.1. Each application system in the end-to-end test sequence
correctly interprets and processes key standard identifiers and required
data elements for IRP credential applications data exchange.</td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>6.1.2. Each application system in the end-to-end test sequence
correctly interprets and processes key standard identifiers and required
data elements for IRP credential applications data exchange.</td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>6.1.3. Each application system in the end-to-end test sequence
correctly interprets and processes key standard identifiers and required
data elements for IFTA credential applications data exchange.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>6.1.4. Each application system in the end-to-end test sequence
correctly interprets and processes key standard identifiers and required
data elements for IFTA tax filing data exchange.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td>6.1.5. Each application system in the end-to-end test sequence
correctly interprets and processes key standard identifiers and required
data elements for vehicle snapshots.</td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>6.1.6. Each application system in the end-to-end test sequence
correctly interprets and processes key standard identifiers and required
data elements for carrier snapshots.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td>6.1.7. Each application system in the end-to-end test sequence
correctly interprets and processes key standard identifiers and required
data elements for making a valid screening decision for the test
vehicle.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>6.1.8. The screening system makes the correct screening decision
based on proper identification of the vehicle and carrier, and correct
interpretation of key snapshot data fields.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>6.1.9. A vehicle that has been enrolled and accepted in a State
electronic screening program and that is properly equipped with a
compatible transponder, can be identified and correlated to vehicle and
carrier snapshot data at the roadside as it approaches the
weigh/inspection station.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>6.1.10. Roadside inspection results are reported correctly to SAFER
and routed via vehicle snapshot segment updates to other state CVIEWs,
and in turn to State roadside operations, where they are interpreted and
used correctly.</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>6.1.11. Every application system in the end-to-end test sequence
responds as required by providing the proper interface communications to
each subsequent system, and provides the expected exchange of data at
each step in the test.</td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
</tbody>
</table>

# References

1.  JHU/APL, *Introductory Guide to Commercial Vehicle Information
    Systems and Networks (CVISN),* (version V1.0), POR-99-7186, dated
    February 2000.

2.  JHU/APL, *Commercial Vehicle Information Systems and Networks
    (CVISN) Operational Concept Document*, (Preliminary Issue P.2),
    POR-96-6989, June 1996.

3.  JHU/APL, *Commercial Vehicle Information Systems and Networks
    (CVISN) Architecture Specification*, (Preliminary), POR-96-6985,
    February 1996.

4.  American National Standards Institute (ANSI) Accredited Standards
    Committee (ASC) X12, *Electronic Data Interchange X12 Standards*,
    Draft Version 4, Release 3, December 1999

5.  JHU/APL, *Commercial Vehicle Operations (CVO) Information Systems
    and Networks (CVISN) Data Dictionary*, (Preliminary), POR-96-6988,
    March 1996.

6.  JHU/APL, *Commercial Vehicle Information Systems and Networks
    (CVISN) Dedicated Short Range Communications (DSRC) Interface
    Requirements,* (Preliminary), POR-96-6987, April 1996.

7.  JHU/APL, *Commercial Vehicle Information Systems and Networks
    (CVISN) Electronic Data Interchange (EDI) Interface Requirements,*
    POR-96-6986, May 1996.

8.  JHU/APL, *Commercial Vehicle Information Systems and Networks
    (CVISN) Recommendations for Common Carrier, Vehicle, Driver, and
    Cargo Identifiers,* SSD/PL-99-388 dated June 1999.

9.  JHU/APL, *ITS/CVO CVISN Glossary*, POR-96-6997 V2.0, dated December
    2000.

10. JHU/APL, *ITS/CVO Program Plan*, POR-97-7071 D0.1, dated 29 May 1997

11. JHU/APL, *Commercial Vehicle Information Systems and Networks
    (CVISN) System Design Description,* POR-97-6998 V2.0, (Baseline
    Version), August 2000. \[The latest version is available on the
    JHU/APL CVISN Web site
    <http://www.jhuapl.edu/cvisn/>[\]]{.underline}

12. FHWA, *Commercial Vehicle Information Systems and Networks (CVISN)
    Model Deployment Program Request for Application*, notice in Federal
    Register July 5, 1996 (volume 61, number 130, 35300)

13. JHU/APL, *CVISN Operational and Architectural Compatibility Handbook
    (COACH) Part 1*, SSD/PL-99-0243, POR-97-7067 V2.0, dated August
    2000.

14. JHU/APL, *Electronic Data Interchange (EDI) Implementation Guide for
    Commercial Vehicle Credentials (Transaction Set 286), Volume I,
    International Registration Plan (IRP) Credential Transactions*, ANSI
    ASCX12 Version 4, Release 3, POR-96-6993 D.5, dated March 2000.

15. IEEE Std 1220-1994, *IEEE Trial-Use Standard for Application and
    Management of the Systems Engineering Process*, dated 28 February
    1995.

16. JHU/APL, *Electronic Data Interchange (EDI) Implementation Guide for
    Commercial Vehicle Credentials (Transaction Set 286), Volume III,
    International Fuel Tax Agreement (IFTA) Credential Transactions*,
    ANSI ASCX12 Version 4, Release 3, POR-97-6996 V1.0, dated March
    2001.

17. JHU/APL, *Electronic Data Interchange (EDI) Implementation Guide for
    Commercial Vehicle Credentials (Transaction Set 286), Volume IV,
    Oversize/Overweight (OS/OW) Credential Transactions*, (Draft)
    POR-97-7068 V1.0, dated March 2001.

18. JHU/APL, *Electronic Data Interchange (EDI) Implementation Guide for
    Commercial Vehicle Safety and Credentials Information Exchange
    (Transaction Set 285),* POR-96-6995 V1.0, dated March 2001.

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

20. JHU/APL, *CVISN Interoperability Test Plan (Draft)*, SSD/PL-97-0688,
    POR-97-7072 D.1, dated 9 December 1997.

21. JHU/APL, *ITS/CVO Architecture Conformance: Interoperability Testing
    Strategy (Draft)*, SSD/PL-98-0037, POR-98-7076 P.1, dated July 1999.

22. JHU/APL, *Intelligent Transportation Systems (ITS) Commercial
    Vehicle Information Systems and Networks (CVISN), State of Maryland,
    Credentials Administration Requirements Specifications (CARS),
    SSD/PL-97-0613, Draft Issue D.1, dated November 1997*.

23. JHU/APL, *Intelligent Transportation Systems (ITS) Commercial
    Vehicle Information Systems and Networks (CVISN), commonwealth of
    Virginia, Credentials Requirements Specifications (CARS),
    SSD/PL-98-0485, Version 2.0, dated September 1998.*

24. JHU/APL, *SAFER and CVIEW Carrier, Vehicle, and Driver Snapshots
    White Paper*, SSD/PL-01-0258 dated August 2001.

25. ASTM Preliminary Standard-111-98, Specification for Dedicated Short
    Range Communication (DSRC) Physical Layer using Microwave in the 920
    to 928 MHz band, dated April 1999. \[For a summary of the standard,
    see (case sensitive)
    http://www.astm.org/DATABASE.CART/PAGES/PS111.htm\]

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

27. IEEE Standard 1455-99, Standard for Message Sets for
    Vehicle/Roadside Communications, dated September 1999. \[For a
    summary of the standard, see
    http://www.its.-standards.net/Documents/FS1455.pdf\]

28. The U. S. Department of Transportation, Federal Highway
    Administration, *Proposed Rule: Dedicated Short Range Communications
    In Intelligent Transportation Systems (ITS) Commercial Vehicle
    Operations*, 23 CFR Part 945, \[FHWA Docket No. FHWA 99-5844\] RIN
    2125-AE63, published in Federal Register: December 12, 2000 (Volume
    65, Number 239)\], Page 77534-77538. Available from the Federal
    Register Online via GPO Access,
    <http://www.access.gpo.gov/su_docs/aces/aces140.html>
    \[DOCID:fr30de99-43\]

29. JHU/APL, CVISN *Guide to Integration and Test,* POR-99-7194, D.1,
    dated May 2001.

30. JHU/APL, ITS/CVO *Interoperability Test Suite Package, Part 2, Test
    Cases and Procedures,* POR-98-7123, D.2, dated November 2000.
    (scheduled to be updated in 2001)

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

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

33. JHU/APL, *ITS/CVO Architecture Conformance: Interoperability Testing
    Strategy*, POR-98-7076 P.2, dated June 1999.

34. JHU/APL, *Electronic Data Interchange (EDI) Implementation Guide for
    Application Advice (Transaction Set 824), POR-99-7203 version* D.2,
    dated March 2000.

35. JHU/APL, *CVISN Operational and Architectural Compatibility Handbook
    (COACH), Part 2 - Project Management Checklists, POR-97-7067 P2.0,
    (Preliminary Version),* September 1999. The latest version is
    available on the JHU/APL CVISN Web site
    <http://www.jhuapl.edu/cvisn/>[\]]{.underline}

36. JHU/APL, *CVISN Operational and Architectural Compatibility Handbook
    (COACH), Part 3 -- Detailed System Checklists, POR-97-7067 P1.0,*
    May 1999. [\[Note: This document is scheduled to be updated in 2000.
    The latest version will be available on the JHU/APL CVISN Web site
    [http://www.jhuapl.edu/cvisn/\]]{.underline}](http://www.jhuapl.edu/cvo/)

37. JHU/APL, *CVISN Operational and Architectural Compatibility Handbook
    (COACH), Part 4 -- Interface Specification Checklists*, *POR-97-7067
    D1.0, (Draft),* April 1999. \[Note: This document is scheduled to be
    updated in 2000. The latest version will be available on the JHU/APL
    CVISN Web site <http://www.jhuapl.edu/cvisn/>

38. JHU/APL, CVISN Guide to Top-Level Design, POR-99-7187 V1.0,
    (Baseline Version), February 2001.

39. FMCSA Code Directory, Version 004, Release 000, POR-98-7127 D.5,
    (Draft Version), March 2000.

40\. JHU/APL, *Electronic Data Interchange (EDI) Implementation Guide
for Electronic Screening Enrollment (Transaction Set 286), POR-99-7239
version* V1.0, dated March 2001.

41\. JHU/APL, *CVISN Operational and Architectural Compatibility
Handbook (COACH), Part 5 -- Interoperability Test Criteria, POR-98-7126
D.1,* July 1999. [\[Note: The latest version will be available on the
JHU/APL CVISN Web site
http://www.jhuapl.edu/cvisn/\]](../%5BNote:%20The%20latest%20version%20will%20be%20available%20on%20the%20JHU/APL%20CVISN%20Web%20site%20http://www.jhuapl.edu/cvisn/%5D)

# CVISN Change Request Form

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

# APPENDIX - CHANGE REQUESTS INCORPORATED INTO THE CURRENT VERSION

The effect of each CR incorporated into Version 1.0 of the document is
briefly described below.

-   CR 1048 - Update CVISN for Web sites and XML for Credentialing

> Table 6 -1 includes a column for Web-based tests.

-   CR1084- Update Design Template and Stakeholder View.

1.  Figure 3 -1 was updated by adding a State Web site, deleting EDI
    interface from state to IRP clearinghouse, adding MCMIS to SAFETYNET
    connection, CVIEW to SAFER EDI interface, and an Internet interface
    from carrier to state Web site and SAFER.

2.  Figure 4 -1 was updated by adding a State Web site, and roadside
    custom interface connections.

3.  Figure 5 -1 was updated by adding a State Web site, an Internet
    interface from the State to IFTA clearinghouse, CI to legacy system
    connections, a CDLIS to SAFER connection, and legacy system to
    clearinghouse connections.

-   CR 1099 - Add Web to generic CVISN configuration.

> The design templates used in Figures 3-1, 4-1, and 5-1 all have had a
> state Web site added to the state systems.

-   CR 1159 - Update DSRC references.

> Section 4.1 references the current DSRC standards.

-   CR 1164 - Clarify interface options (EDI, XML, Web, other) for
    Safety.

> Section 1 refers to alternative interfaces such as XML and flat files.

-   CR 1377 - Summarize changes incorporated in this update of COACH
    Part 5.

1.  All tables in the body of the document were reformatted to include a
    cross-reference to the interoperability tests; appendices that
    formerly provided the cross reference were deleted.

2.  Columns were added to the table for State Design Check and Notes.

3.  Section 1.4 includes additional explanation on how to use the
    tables.

4.  Tables 5.4 and 5.5 were added for ASPEN to CVIEW exchanges.

5.  Criteria were edited to be specific to sender and receiver, e.g., if
    testing the CI, the criteria should read "CI sends..." not "CAT
    receives....".

6.  In Table 5-1, criteria were deleted that were specific to testing
    SAFER in CVIEW-SAFER exchanges, and in Tables 5-2 and 5-3, criteria
    were deleted that were specific to testing SAFER in ASPEN-SAFER
    exchanges, because in these exchanges we are testing
    interoperability of CVIEW or ASPEN, not SAFER.

7.  In Table 5-6, criteria were deleted that were specific to testing
    CVIEW in ROC-CVIEW exchanges because in these exchanges we are only
    testing interoperability of the ROC, not CVIEW.

8.  In Table 5-1, the requirement for CVIEW and SAFER to acknowledge
    each EDI with a TS 997 was removed. No TS 997 positive is planned
    for SAFER.

9.  A statement was added at the end of Chapter 1 concerning
    implementation of full acknowledgement protocols. (TS 997 and TS
    824). Some states may chose not to implement the TS 997, for
    instance. The requirements assume they do.

10. Criteria for exchanging TS 150 and TS 826 were added to Table 3.5,
    CI to IFTA Tax Filing.

11. Criteria for exchanging TS 150 and TS 826 were added to Table 3.4,
    CAT to CI for IFTA Tax Filing.

12. Various editorial changes and corrections were made throughout the
    document.

-   CR 1424 - Delete interoperability test criteria to set or change
    subscription criteria via TS 285.

> Table 5 -1 no longer contains test criteria related to setting or
> changing subscription criteria via a TS 285.

-   CR 1463 - IFTA Tax Scenario EDI Corrections/Clarifications.

1.  Table 3-4 and 3-5 have been corrected to show the TS 813 as
    uni-directional from the carrier to the State;

2.  TS 813 is not used for tax filing notification;

3.  TS 149 can be used to send notice of tax adjustment to the carrier;

4.  TS 826 can be used to send tax credit information to the carrier.

-   CR 1508 - CVIEW Version 3 will not store inspection reports.

> Table 5-4 does not refer to CVIEW updating its database for an
> incoming inspection report, but rather indicates that CVIEW forwards
> the inspection reports to SAFER.

-   CR 1662 - SAFER stores inspection reports for 60 days.

> Table 5-2, item 5.2.2 was corrected to show 60-day retention of
> inspection reports.

This Page Intentionally Blank