# Operational Scenarios

***5. Operational Scenarios [5-1](#operational-scenarios)***

**5.1 Introduction [5-2](#introduction)**

**5.2 Safety Information Exchange Systems
[5-3](#safety-information-exchange-systems)**

5.2.1 Scope [5-4](#scope)

5.2.2 Overview [5-5](#overview)

5.2.3 Thread Diagrams [5-6](#thread-diagrams)

**5.3 Credentials Administration Systems
[5-15](#credentials-administration-systems)**

5.3.1 Scope [5-16](#scope-1)

5.3.2 Overview [5-17](#overview-1)

5.3.3 Thread Diagrams [5-19](#thread-diagrams-1)

**5.4 Electronic Screening Systems
[5-32](#electronic-screening-systems)**

5.4.1 Scope [5-33](#scope-2)

5.4.2 Overview [5-34](#overview-2)

5.4.3 Thread Diagrams [5-37](#thread-diagrams-2)

## Introduction

This chapter describes the key operational scenarios; that is, Maryland
has described how they intend that the state should interact with their
customers and with the core infrastructure systems to accomplish key
CVISN Level 1 functions. The scenarios explain the interactions between
major system elements that are required to execute key CVO activities.

The operational scenarios are illustrated by overlaying information onto
the system design template. The resulting diagram is called a
"functional thread diagram".

The CVISN Prototype consists of a number of systems interacting through
a complex set of interactions. Thread diagrams are used within the next
sections in order to introduce, at a high level, the processing to be
performed by the Maryland CVISN Prototype systems. Each section focuses
upon one of the three major capability area thrusts of the Maryland
prototype project:

-   Safety Information Exchange Systems

-   Credentials Administration Systems

-   Electronic Screening Systems

These sections take a functional view of the Maryland CVISN
configuration. A series of several "thread" diagram figures with
accompanying descriptive tables are used to illustrate the interactions
of the major components of the Prototype system..

Each thread diagram shows the information flows and the interactions
among a selection of the systems participating in the Prototype. By
illustrating typical processing scenarios that will be implemented by
the Maryland CVISN design, these thread diagrams provide a high-level
view of the processing to be performed in a capability area. They also
serve to verify that the network template defined in the previous
chapter is adequate to support the intended interactions.

The nature of a thread diagram is to present a meaningful sequence of
message exchanges and processing steps. Each sequence of related
messages and processing steps is called a *thread*. Threads are
presented for each operational scenario that is part of Maryland's CVISN
project scope. A text table accompanying each thread diagram defines the
steps in the scenario depicted by the diagram. The rows are keyed to the
numbered arrows on each diagram that represent the message transfers.

Detail is limited in a thread diagram so that a broad systems view is
possible, while still maintaining clarity.

Major data flows between the components are shown as lines with arrows
showing the direction of the data flow. By convention, in order to keep
the diagrams simple, routine reverse transactions are not shown. For
example, when any EDI transaction (e.g., a TS 286) is received by a
target system, a TS 997 EDI acknowledgment is sent back to the source
system. However, in most cases, a backward arrow for the TS 997
acknowledgment, the reverse flow, is not shown.

Each major data flow in a thread diagram is numbered for identification
and to indicate the flow sequence. Each thread diagram later in this
document is followed by a table that describes each of the numbered data
flows in the diagram. This combination provides a concise representation
of the processing to be performed for the scenario illustrated by the
thread diagram.

## Safety Information Exchange Systems 

![](media/image1.wmf)

Figure 5-1. Safety Information Exchange Systems

### Scope 

This section describes systems that are primarily involved in safety
related functions at the roadside. As shown in Figure 5‑1, these
include:

-   CV Information Exchange Window (CVIEW)

-   ASPEN

-   SAFETYNET

-   National Law Enforcement Telecommunications System (NLETS) Node

-   World Wide Web access via a Browser

This chapter describes systems and subsystems in terms of software
functionality. Diagrams and descriptions do not imply a one-to-one
relationship between software systems and hardware. Although each
software system is a separate entity, different systems may reside on a
single piece of hardware, and parts of one system may reside on
different machines.

Section 5.2.2 provides a general overview of how safety information
exchange is performed. This is a Maryland-specific version of the
material presented in the CVISN System Design Description \[Reference
36\].

Section 5.2.3 provides a series of thread diagrams to illustrate how
these systems are interconnected and interact within the Maryland
systems design.

### Overview 

![](media/image2.wmf)

Figure 5-2. Major Components of Safety Information Exchange

For safety information exchange, as shown in Figure 5-2, the design
elements include state and federal commercial vehicle credential and
safety administration-related offices, roadside check stations (fixed
and mobile), and CVISN Core Infrastructure information exchange systems.

The primary Maryland state administrative offices include the Maryland
State Police, the designated lead Motor Carrier Safety Assistance
Program (MCSAP) agency, SAFETYNET, and other enforcement activities.
Other state agencies also provide or have an interest in commercial
vehicle safety information (e.g., vehicle registration, driver
licensing, titling, permitting). These offices exist in each state or
region, and share information through various CVISN core infrastructure
systems.

The Maryland CVIEW system supports the transfer of safety and
credentials information (SAFER-style snapshots and reports) within
Maryland and with the SAFER system. The Maryland CVIEW handles
information about all carriers, vehicles, and any drivers who operate in
the state (both intrastate and interstate operators).

The CVISN core infrastructure supports the exchange of safety
information between states, and among other stakeholders. The primary
safety-related information systems and networks include the SAFER,
Commercial Driver License Information System (CDLIS), and Motor Carrier
Management Information System (MCMIS). Other information systems and
networks that support law enforcement and credentialing activities, such
as National Law Enforcement Telecommunications System (NLETS) and the
National Motor Vehicle Titling Information System (NMVTIS), are also
used to support the exchange and use of safety information.

Roadside check stations include those locations with a permanent
structure or mobile facility (including police cruisers) that house
elements of the information system (e.g., computers and communication
systems) and enforcement and safety inspection personnel.

The CVISN initiative supports the standardization of data flows to carry
summary (snapshot) and detailed (report) safety and credentials
information. These data flows will provide a consistent basis for
automating CVO information exchanges and processing, and to ensure
interoperability among existing and developing CVO information systems.
EDI X12 transaction set 285 is used to carry snapshot information. EDI
X12 transaction set 284 is used to carry CV safety report information.

The snapshots convey information about three major entities: carriers,
vehicles, and drivers. To minimize response time to requesters,
snapshots will be stored nationally in the SAFER system, and within the
state in the CVIEW system. The more detailed supersets of standardized
data flows required by the same stakeholders are known as SAFER or CVIEW
carrier, vehicle, and driver "reports."

SAFER/CVIEW snapshots are used for screening carriers, vehicles, and
drivers at mainline speeds at roadside check stations, for safety
inspections, for limited credentials checking, for insurance
applications checks, and for industry self-checks. Different subsets
(called "views") of the snapshot record available in SAFER/CVIEW for a
carrier, vehicle, or driver will support different user systems.

### Thread Diagrams 

The thread diagrams (Figures 5-3, 5-4, 5-5) shown on the next several
pages present Maryland's approach to three safety information functions:

-   Snapshot Data Collection

-   Snapshot Distribution

-   Inspection Reporting

By following the arrows in the sequence indicated by their numbering and
reading the corresponding text charts, each operational scenario can be
understood at a high level. Each thread diagram is followed by a table
that provides additional information about the data exchanged between
the systems at either end of an arrow.

The direction of an arrow indicates primary information flow. Some data
may flow in the opposite direction to verify successful transmission.
For example, EDI X12 functional acknowledgments are not shown as
separate data flows, and the triggering of each message exchange is also
not represented.

This Page Intentionally Blank

![](media/image3.wmf)

Figure 5-3. Snapshot Data Collection Thread Diagram

Table 5‑1. Snapshot Data Collection Thread Descriptions

+-----+----------------------------------------------------------------+
| 1a. | Snapshot updates are triggered by changes to snapshot data     |
|     | elements in the authoritative sources.                         |
| and |                                                                |
|     | The Maryland Intrastate Vehicle Registration system and the    |
| 1b. | Titling system send updates to the MVA Mainframe Data Base in  |
|     | custom file formats.                                           |
+-----+----------------------------------------------------------------+
| 2\. | The MVA Mainframe Data Base sends the snapshot updates to      |
|     | CVIEW in custom file format.                                   |
+-----+----------------------------------------------------------------+
| 3a. | Other sources provide snapshot segment updates directly to     |
|     | CVIEW; the data that goes to CVIEW is in a *TS 285*. These     |
| 3b. | sources are the IFTA RPC LM, the IFTA Registration system LSI, |
|     | and the IRP VISTA/RS LM.                                       |
| 3c. |                                                                |
+-----+----------------------------------------------------------------+
| 4\. | Snapshots for interstate entities are forwarded to SAFER by    |
|     | CVIEW in a *TS 285* for other jurisdictions to access.         |
+-----+----------------------------------------------------------------+
| 5\. | The SAFER carrier database is updated once per week by the     |
|     | MCMIS system. Data is exchanged according to a particular      |
|     | custom interface agreement. Specifically, the SAFER system     |
|     | accepts updates in ASCII text file format via the use of an    |
|     | LSI.                                                           |
+-----+----------------------------------------------------------------+

![](media/image4.wmf)

Figure 5-4. Interstate Snapshot Distribution Thread Diagram

Table 5‑2. Snapshot Distribution Thread Descriptions

+-----+----------------------------------------------------------------+
| 1\. | SAFER sends updated snapshots, *TS 285*s, to all subscribers.  |
|     | CVIEW is Maryland's only subscriber to SAFER.                  |
+-----+----------------------------------------------------------------+
| 2a. | CVIEW forwards the updated snapshots to the Roadside           |
|     | Operations Computer (ROC). The ROC system retrieves its        |
| 2b. | subscription update of carrier and vehicle information by      |
|     | polling its subscription mailbox on CVIEW via an operator      |
|     | issued command.                                                |
|     |                                                                |
|     | CVIEW 3.0 forwards the updated snapshots via an application    |
|     | file format to the ASPEN-32 host computers that subscribe      |
|     | within Maryland.                                               |
+-----+----------------------------------------------------------------+
| 3\. | The ROC system receives the updated snapshot and forwards the  |
|     | screening-view snapshot fragment to the screening computer via |
|     | a custom interface agreement.                                  |
+-----+----------------------------------------------------------------+

![](media/image5.wmf)

Figure 5-5. Inspection Reporting Thread Diagram

Table 5‑3. Inspection Reporting Thread Descriptions

  ------ ----------------------------------------------------------------
  1\.    An enforcement officer, using the Past Inspection Query (PIQ)
         system, issues a query to SAFER\'s input mailbox in the SAFER
         Data Mailbox (SDM), for all inspection reports relating to a
         particular carrier, in ASPEN-unique, non-EDI file format.

  2\.    SAFER retrieves the query from its input mailbox in the SDM,
         processes the request, and retrieves the inspection reports from
         data storage. The inspection reports are placed in the
         requestor\'s query mailbox in the SDM. The PIQ detects and
         processes the report for display on ASPEN (data transferred in
         ASPEN-unique, non-EDI file format).

  3\.    ASPEN sends the enforcement officer\'s inspection report to
         SAFER\'s input mailbox and SAFETYNET\'s input mailbox in the
         SDM, in ASPEN-unique, non-EDI file format.

  4a and SAFER updates the vehicle snapshot segment with inspection
  4b.    information and forwards the snapshot views to subscribers via
         their mailboxes in the SDM via *TS 285*.

  5\.    SAFETYNET retrieves the inspection report from its input mailbox
         on the SDM, still in ASPEN-unique non-EDI file format.

  6\.    The SAFETYNET staff member reviews the inspection report and
         sends it to MCMIS using existing methods.

  7\.    MCMIS receives the inspection report, updates carrier summary
         information, and computes carrier safety statistics. Weekly,
         MCMIS sends SAFER updated carrier snapshot segments in flat file
         format.

  8a and SAFER updates its stored snapshots with carrier snapshot
  8b.    segments it receives from MCMIS. SAFER forwards snapshot views
         to subscribers via their subscription mailboxes in the SDM in
         via *TS 285*.

  9\.    SAFER then forwards carrier snapshot views to ASPEN subscribers
         in non-EDI file format.
  ------ ----------------------------------------------------------------

## Credentials Administration Systems

![](media/image6.wmf)

Figure 5-6. Credentials Administration Systems

### Scope 

This section describes systems that are primarily involved in
credentials administration functions. As shown in Figure 5-6, these
include:

-   Carrier Automated Transaction (CAT) system

-   Credentialing Interface (CI) system

-   Vehicle Information System for Tax Apportionment / Registration
    System (VISTA/RS)

-   MVA Mainframe Database system

-   Oversize/Overweight - Automated Hauling Permit System (OS/OW - AHPS)
    permitting system

-   International Fuel Tax Agreement / Regional Processing Center
    (IFTA/RPC)

-   Titling system

-   Intrastate Vehicle Registration system

-   IRP Clearinghouse

-   IFTA Clearinghouse

The design elements involved with credentials administration include the
CAT system, state CI, communications system(s) that facilitates the
exchange of information between the carriers and the state, state legacy
systems associated with individual credentials, and clearinghouses in
the CVISN Core Infrastructure. Also, the Maryland CVIEW supports the
exchange of credentials-related information, via snapshots, both to
external users of credentialing information and to the other Maryland
capability areas \-- safety information and roadside electronic
screening.

This section describes systems and subsystems in terms of software
functionality. Diagrams and descriptions do not imply a one-to-one
relationship between software systems and hardware. Although each
software system is a separate entity, different systems may reside on a
single piece of hardware, and parts of one system may reside on
different machines.

Section 5.3.2 provides a general overview of how credentials
administration functions are performed. This is a Maryland-specific
version of the material presented in the CVISN System Design Description
\[Reference 36\].

Section 5.3.3 provides a series of thread diagrams to illustrate how
these systems are interconnected and interact within the Maryland
systems design.

### Overview

![](media/image7.wmf)

Figure 5-7. Major Credentials Administration Components

As shown in Figure 5-7, credentialing administration functions allow
carriers, owners, and drivers to apply for, pay for, and receive
credentials electronically. They also support states/regions in the
processing of credentials, in collecting and distributing funds, and in
storing and distributing credentials related data. The design also
establishes standard mechanisms (the snapshots) for states to provide
credentials information to enforcement officials and other authorized
stakeholders.

Normally, the elements exchange information with each other through
standardized interfaces (public - private, and infrastructure - state)
using ANSI ASC X12 EDI transactions. The elements are virtually linked
through government and commercial network services, such as AAMVANET.
Proprietary or sensitive information is protected from inadvertent
disclosure through network "firewalls", business practices, and
procedures.

A **credential** is defined to be the authority granted by the issuing
jurisdiction. Today, most credentials are issued in paper form, with
supporting records on file in the issuing jurisdiction's system. An
**electronic credential** is an electronic record of the credential.

The authoritative source for an electronic credential is the issuing
agency. The holder of the credential may be issued an electronic copy
that represents the same authority as today's paper copy.

To support base state arrangements, states must collect fees from
operators, apportion the fees collected to other states according to
pre-determined criteria, and transfer funds to those states accordingly.
To facilitate that process, the design shown here involves
**clearinghouses** to support those financial reconciliation activities.
This design centralizes the financial reconciliation required by base
state agreements. The clearinghouses could also be used to facilitate
other kinds of information exchange. For instance, the clearinghouses
could support audits, and provide a consolidated reporting database.

To be compliant with CVISN, participants must use X12 EDI transaction
sets (TS) as follows:

-   Use TS 286 to carry credential application, credential invoice,
    payment method, electronic credential information, and to report
    problems with applications

-   Use TS 813 for IFTA fuel tax filing

-   Use TS 864 to report problems with IFTA tax filing

-   Use TS 820 to initiate electronic fund transfer (EFT) process
    (payment methods are not yet designed for Maryland's system)

-   Use TS 997 to acknowledge all EDI messages

-   Use TS 285 to pass information about all credentials for a
    particular carrier, vehicle, or driver

The EDI Implementation Guides (IGs) \[References 39-44\] provide
additional details about the usage of some of these transaction sets.

### Thread Diagrams

The functional thread diagrams shown on the next several pages (Figures
5-8, 5-9, 5-10, and 5-11) present Maryland's approach to three
credentialing functions:

-   IRP Registration

-   IFTA Credentialing

-   IFTA Tax Filing

By following the arrows in the sequence indicated by their numbering and
reading the corresponding text charts, each operational scenario can be
understood at a high level. Each thread diagram is followed by a table
that provides additional information about the data exchanged between
the systems at either end of an arrow. (See Tables 5-4, 5-5, 5-6, and
5-7.)

The direction of an arrow indicates primary information flow. Some data
may flow in the opposite direction to verify successful transmission.
For example, EDI X12 functional acknowledgments are not shown as
separate data flows, and the triggering of each message exchange is also
not represented.

The \"IRP Turn & Type\" capability involves a person as the interface
between the CI and the VISTA/RS system. The operator would look at an
IRP application on a CI User Interface screen and then turn to a
VISTA/RS screen on another terminal on their desk and type in the same
information. IRP Turn & Type will be implemented in several phases. The
final phase, Phase 4, is described in Figure 5-8. For more information,
refer to the IRP Turn & Type Operational Concept Description \[Reference
66\].

As this document is being written, design changes are under
consideration that will affect how the IFTA information is transmitted
between the carrier and its eventual destination. Two changes affect the
IFTA Credentialing data flows, and another affects the IFTA Tax Filing
flows. While not yet formally approved by the Maryland Technical
Configuration Control Board, these revisions are anticipated to reflect
the ultimate system design configuration. Therefore, thread diagram
Figures 5-9, 5-10, and 5-11 reflect the design changes proposed for each
situation. The IFTA Registration capability in Maryland will be
implemented in several phases; figures 5-9 and 5-10 reflect Phases 3 and
4, respectively. For more information, refer to the IFTA Registration
Operational Concept Description \[Reference 67\].

Financial institutions are not represented in these credentialing thread
diagrams, even though payment information is discussed. Requirements for
EFTs have not yet been established. It is not yet possible to present
system design descriptions for these functional elements. Payment
information will be presented to credential agency staff on CI user
interface screens, and the staff will process payments manually or using
current automated support systems until policy has been established,
requirements analyzed, and design and development completed.

This Page Intentionally Blank

![](media/image8.wmf)

Figure 5-8. IRP Registration Supplemental Application Thread Diagram -
Turn & Type Phase 4

Table 5‑4. IRP Registration Supplemental Application Thread
Descriptions - Turn & Type Phase 4

  ------ -----------------------------------------------------------------
  1\.    Carrier enters an IRP credential application via a Carrier
         Automated Transaction (CAT) system, which submits it to the
         Credentialing Interface (CI) as a TS 286. The CI returns TS 997
         acknowledgment back to the CAT.

  2\.    The CI validates the application data, and makes a query against
         the MVA database to determine whether to grant or deny the
         credential. The MVA query and response are based on SQL.

  3\.    The application is manually entered into VISTA/RS for processing
         as a TS 286.

  4\.    The credential is processed by VISTA/RS, and a summary invoice
         notice is generated.

  5\.    The CI sends the TS 286 Modified Summary Invoice Notice to the
         Carrier, and maintains archival/audit copies of all transactions
         from VISTA/RS for carriers.

  6\.    The CI creates a snapshot segment update indicating that the
         carrier has temporary credentials and sends as a TS 285 to the MD
         CVIEW system.

  7\.    CVIEW receives the TS 285, determines that it is for an
         interstate credential, and transmits the TS 285 to SAFER,
         providing the registration data needed to generate a new
         snapshot.

  8\.    The Carrier reviews the summary invoice and the fee information,
         optionally requests a detailed invoice, and provides payment
         information to the CI in a returned TS 286 Invoice Acceptance and
         Payment Information.

  9\.    The CI validates the payment information (financial system
         interfaces are not shown). The MD MVA IRP staff updates the
         credential to permanent status in VISTA/RS.

  10\.   VISTA/RS generates cab card information.

  11\.   The CI passes the credential information to the carrier CAT. The
         cab cards may be printed at the carrier site or in the IRP
         office.

  12\.   The MD MVA IRP staff mails the credentials to the carrier.

  13\.   The CI updates the snapshot with the permanent credential
         information by sending a TS 285 to CVIEW.

  14\.   CVIEW receives the TS 285, determines that it is for an
         interstate credential, and transmits the TS 285 to SAFER,
         providing the registration data needed to generate a new
         snapshot.

  15\.   At the close of the business day Vehicle Records changes are sent
         as a batch file to the MVA Mainframe.

  16\.   Periodic updates (daily to monthly) are sent to the IRP
         Clearinghouse on IRP registration information and fee payments
         (recaps), using TS 286.

  17,    On a monthly basis, the IRP Clearinghouse reports the fee
  18,    information to all jurisdictions (pre-netting transmittal). The
  19.    IRP office approves or corrects the transmittals, and the IRP
         Clearinghouse performs the actual netting and reports
         corrected/approved vehicle and fee actions (post-netting
         transmittal). The IRP Clearinghouse reports the netting results
         (remittance netting reports). All transactions are TS 286.
  ------ -----------------------------------------------------------------

NOTE: Functional acknowledgment for all EDI messages (except TS 997) is
made by responding with a TS 997. Content errors in a received TS 286
are noted by also replying with a TS 286.

![](media/image9.wmf)

Figure 5-9. IFTA Credential Renewal Application Thread Diagram - \'Phase
3\'

Table 5‑5. IFTA Credential Renewal Application Thread Descriptions -
\'Phase 3\'

  ------ ----------------------------------------------------------------
  1\.    The carrier completes the IFTA Registration renewal application
         and submits the paper application and payment over the counter
         at one of the 20 Comptroller\'s Branch Offices in Maryland.

  2\.    The Branch Office staff enters the application, the number of
         decals requested, and the decal assignments into the Branch
         Office Carrier Automated Transaction (CAT). The CAT submits it
         to the Credentialing Interface (CI) as a TS 286 IFTA
         Registration transaction.

  3\.    If there are any errors, the CI sends an error message to the
         Branch Office CAT as a TS 286. Otherwise, the application is
         held for payment and further validation, and the CI sends a
         confirmation message to the Branch Office CAT as a TS 286.

  4\.    The Branch Office staff prints the payment voucher and the IFTA
         license on the Branch Office CAT.

  5\.    The Branch Office staff processes the payment.

  6\.    The CI translates the application transaction into an internal
         "flat file" format. This scenario presumes that an interface
         will be developed so that this file can be transferred via batch
         mode and read by the MD IFTA Registration Legacy System (LS) at
         the Annapolis Data Center (ADC).

  7\.    The Branch Office staff pulls the decals from the Branch Office
         stock and hands the decals and license to the carrier at the
         counter.

  8\.    The IFTA Registration System reads the flat file and processes
         the application. The Annapolis Office staff views the results of
         the IFTA Registration System validation and enters the status in
         the CI.

  9\.    The CI generates snapshot information and sends it as a TS 285
         Carrier Snapshot to the Maryland CVIEW.

  10\.   The Maryland CVIEW reads the TS 285 Carrier Snapshot and passes
         it to SAFER.

  11\.   SAFER passes the TS 286 to other jurisdictions\' CVIEW systems.

  12\.   Once the application is processed successfully, it is stored in
         the MD IFTA System. Periodically, the MD IFTA System creates a
         file of information reflecting IFTA credential additions and
         changes and transfers it (via FTP) to RPC. This allows RPC to
         send tax filing forms to each registered carrier.

  13\.   RPC uploads new or changed IFTA credential information as a TS
         286 to the IFTA Clearinghouse periodically.

  14\.   The IFTA Clearinghouse updates its database with registration
         information from all participating jurisdictions. It sends RPC a
         copy of information related to all licensees as a TS 286
         transaction.

  15\.   Snapshot segments are created for all Maryland carriers with new
         or changed IFTA credentials and sent to the SAFER Data Mailbox
         as TS 285 transactions.

  16\.   SAFER updates carrier snapshots with IFTA credential data and
         forwards TS 285 snapshots for carriers based in MD for IFTA
         registration to the MD CVIEW system for distribution to the MD
         roadside.

  17\.   SAFER distributes full updated snapshots as TS 285 transactions
         to CVIEW systems in other jurisdictions for distribution to
         their roadside locations.
  ------ ----------------------------------------------------------------

NOTES:

-   Phase 2 represents the CAT and CU User Interface installed in the
    Motor Fuel Tax Unit (MFTU) offices and also as a prototype at the
    Jessup Field Office. The CI generates an output file for transfer to
    the IFTA Registration Legacy System (LS), matching current
    application file format, with potentially batch mode update of the
    IFTA Registration LS.

-   Functional acknowledgment for all EDI messages (except TS 997) is
    made by responding with a TS 997. Content errors in a received TS
    286 are noted by also replying with a TS 286.

![](media/image10.wmf)

Figure 5-10. IFTA Credential Renewal Application Thread Diagram -
\'Phase 4\'

Table 5‑6. IFTA Credential Renewal Application Thread Descriptions -
\'Phase 4\'

  ------ ----------------------------------------------------------------
  1\.    The carrier completes the IFTA Registration renewal application
         and submits the paper application and payment over the counter
         at one of the 20 Comptroller\'s Branch Offices in Maryland.

  2\.    The Branch Office staff enters the taxpayer ID into the Branch
         Office CAT. The Branch Office CAT sends a TS 286 IFTA Account
         Query to the CI, requesting a copy of the account information
         (name, address, and status of the account).

  3\.    The CI translates the TS 286 IFTA Account Query transaction and
         routes the request to the MD IFTA Registration System and the
         IFTA Clearinghouse (in real-time).

  4\.    The CI routes the request to the IFTA Clearinghouse (in
         real-time).

  5\.    The MD IFTA Registration System copies the carrier account
         information and sends the information to the CI (in real-time).

  6\.    The IFTA Clearinghouse copies the carrier account information
         and sends the information to the CI (in real-time).

  7\.    The CI receives a file containing the carrier account
         information from the MD IFTA Registration System and a file
         containing the carrier account information from the IFTA
         Clearinghouse. It consolidates the information into a TS 286
         IFTA Account Query Results transaction containing the carrier
         account information or errors (bad/invalid account) to the
         Branch Office CAT. These steps occur in real-time.

  8\.    If there were no errors or if all errors have been resolved, the
         Branch Office staff enters the application, the number of decals
         requested, and the decal assignments into the Branch Office CAT.
         The Branch Office CAT validates that required fields have been
         entered, then sends a TS 286 IFTA Registration Application
         transaction to the CI.

  9\.    The CI receives the TS 286 message. If the transaction is
         successfully processed by the CI and there were no application
         errors, a flat file with the IFTA Registration application
         information is created and transferred to the IFTA Registration
         System in real-time.

  10\.   If there are any application errors, a TS 286 error message is
         sent to the Branch Office CAT. Error messages are displayed on
         the Branch Office CAT. Errors may be corrected and the
         application resubmitted

  11\.   If there were no application errors, the IFTA Registration
         System receives the flat file in real-time and processes the
         application, which includes validation and recording of the
         decal assignments. The account status is returned to the CI by
         some method.

  12\.   The account status is updated in the CI in real-time. The CI UI
         sends a TS 286 error message or TS 286 confirmation message to
         the Branch Office CAT.

  13\.   If there was no error, the Branch Office staff prints a payment
         voucher from the Branch Office CAT and hands it to the carrier
         at the counter.

  14\.   The carrier submits the payment voucher and payment to the
         Branch Office staff

  15\.   The Branch Office processes the payment, pulls the decals from
         inventory, prints the IFTA license from the Branch Office CAT,
         and hands the decals and printed license to the carrier.

  16\.   The CI automatically generates snapshot information and sends it
         as a TS 285 Carrier Snapshot to the Maryland CVIEW.

  17\.   The Maryland CVIEW reads the TS 285 Carrier Snapshot and passes
         it to SAFER, which passes it on to other jurisdictions\' CVIEW
         systems.

  18\.   Once the application is processed successfully, it is stored in
         the MD IFTA registration System. Periodically, the MD IFTA
         Registration System creates a file of information reflecting
         IFTA credential additions and changes and transfers it (via FTP)
         to RPC. This allows RPC to send tax filing forms to each
         registered carrier.

  19\.   RPC uploads new or changed IFTA credential information as a TS
         286 to the IFTA Clearinghouse periodically.

  20\.   The IFTA Clearinghouse updates its database with registration
         information from all participating jurisdictions. It sends RPC a
         copy of information related to all licensees as a TS 286
         transaction.

  21\.   Snapshot segments are created for all Maryland carriers with new
         or changed IFTA credentials and sent to the SAFER Data Mailbox
         as TS 285 transactions.

  22\.   SAFER updates carrier snapshots with IFTA credential data and
         forwards TS 285 snapshots for carriers based in MD for IFTA
         registration to the MD CVIEW system for distribution to the MD
         roadside.

  23\.   SAFER distributes full updated snapshots as TS 285 transactions
         to CVIEW systems in other jurisdictions for distribution to
         their roadside locations.
  ------ ----------------------------------------------------------------

NOTES:

-   Phase 4 represents production versions of the CAT and CU User
    Interface installed in the Motor Fuel Tax Unit (MFTU) offices and
    also at the MFTU Field Offices. The MFTU staff will be able to send
    a query on the tax payer ID from the CI to the IFTA Registration
    System and receive account status response in real-time.

-   Functional acknowledgment for all EDI messages (except TS 997) is
    made by responding with a TS 997. Content errors in a received TS
    286 are noted by also replying with a TS 286.

![](media/image11.wmf)

Figure 5-11. IFTA Tax Filing Thread Diagram

Table 5‑7. IFTA Tax Filing Thread Descriptions

  ------ ----------------------------------------------------------------
  1\.    The Maryland staff initiates the tax filing reminder process via
         the CI User Interface. The CI sends an e-mail message to all
         electronic tax filing carriers on the date specified.

  2\.    When the carrier is ready to file a tax return, a copy of tax
         rates and footnotes for the filing period, and credits on file,
         is requested from the CI via the CAT.

  3\.    The CI sends the tax rates as a TS 150 to the CAT. It sends the
         footnotes using a transaction set to be determined to the CAT.
         The CI determines if there is a credit on file; this information
         is sent to the CAT via a transaction set to be determined.

  4\.    The carrier enters IFTA tax filing information into the CAT. The
         CAT validates the information, applies credits and performs
         calculations utilizing the tax rate tables. The CAT submits the
         tax return information as a TS 813 to the CI.

  5\.    The CI checks the tax filing data. If the CI detects any content
         errors, it cancels the tax return and sends a TS 864 error
         message to the CAT. If no errors are found, the CI puts the
         return on hold, storing it for forwarding to the RPC at the end
         of the day.

  6\.    If an error message is received from the CI, the CAT displays it
         and terminates the tax filing process. Otherwise, if there is a
         balance due, the carrier prints the payment voucher and manually
         sends a check to the RPC Fleet Financial Corp. lockbox.

  7\.    The CI creates a file of tax returns nightly and transfers it to
         the RPC in RPC proprietary format. The RPC reads, processes, and
         stores the file of tax return information. If errors were found
         in a tax form, the State staff will resolve them, accessing tax
         return data on the RPC directly. Returns are put in a hold
         status awaiting payment.

  8\.    Fleet bank deposits the payment and sends a payment record in
         RPC proprietary format to the RPC.

  9\.    When the RPC receives payment records, they are matched to
         return records for the same taxpayer and filing period. If
         payment is not received within a specified time period, the
         State will bill the taxpayer from information provided by the
         RPC.

  10\.   Periodically, the RPC system performs the netting function and
         sends transmittals as a TS 826 to the IFTA Clearinghouse.

  11\.   The IFTA Clearinghouse processes transmittals from all
         participating jurisdictions and sends transmittal information
         for Maryland (and other RPC member jurisdictions) to the RPC as
         a TS 826. If errors are found in the transmittal, a TS 286
         containing a textual error description is sent to the RPC, which
         corrects the problem and resubmits.
  ------ ----------------------------------------------------------------

NOTE: Functional acknowledgment for all EDI messages (except TS 997) is
made by responding with a TS 997. Content errors in a received TS 286
are noted by also replying with a TS 286.

This Page Intentionally Blank

## Electronic Screening Systems

![](media/image12.wmf)

Figure 5-12. Electronic Screening Systems

### Scope

This section describes systems that are primarily involved in electronic
screening functions at the roadside. As shown in Figure 5-12, these
include:

-   Roadside Operations

-   Screening

-   Sensor/Driver Communications/Vehicle Transponder

This section describes systems and subsystems in terms of software
functionality. Diagrams and descriptions do not imply a one-to-one
relationship between software systems and hardware. Although each
software system is a separate entity, different systems may reside on a
single piece of hardware, and parts of one system may reside on
different machines.

Section 5.4.2 provides a general overview of how electronic screening is
performed. This is a Maryland-specific version of the material presented
in the CVISN System Design Description \[Reference 36\].

Section 5.4.3 provides a thread diagram of a typical screening event.

### Overview 

![](media/image13.wmf)

Figure 5-13. Major Components of Electronic Screening

For electronic screening, as shown in Figure 5-13, the major design
elements include vehicles, manned fixed or mobile roadside check
stations, the Maryland CVIEW system, the Maryland CV safety
administration, and various multi-state information systems.

**Vehicles** are equipped with electronic tags (transponders) that
support Dedicated Short Range Communications (DSRC) and are integrated
with an in-cab display (visual and audio) used for driver notification.
Various techniques may be used to store driver and load information on
the tag. Vehicles may interface with screening equipment at mainline or
ramp speed, and drivers are notified of bypass status via the in-cab
device.

**Fixed commercial vehicle roadside check stations** are manned
locations with a permanent structure that can house elements of the
information system (e.g., computers and communication systems). The
stations are equipped with DSRC systems for interfacing with tagged
vehicles. Manned fixed sites are likely to be co-located with a safety
inspection facility.

The Perryville, MD inspection station located on Southbound I-95 shall
be the first implementation of E-Screening in Maryland. In the site
layout there are five DSRC readers along with both ramp and mainline
weigh-in-motion (WIM) device. The five DSRC readers are: Advance reader,
Clearance reader, Compliance reader, Ramp reader and Static Scale
reader.

The advance reader's function is to read the screening message,
including the carrier and vehicle identifiers, and to send this
information to the screening computer for use in determining whether to
clear the vehicle without pulling into the station. The reader is
located far enough ahead of the clearance reader so that the mainline
screening subsystem has time to complete all necessary processing as the
vehicle approaches.

The mainline WIM and associated automatic vehicle classification (AVC)
system provide vehicle weight estimates as input to the mainline
screening decision.

At the clearance reader, a signal is transmitted to the vehicle to
convey the screening decision status to the driver. Since a
DSRC-equipped vehicle could be signaled to pull in, the clearance reader
must be deployed far enough from the roadside check facility that the
vehicle's driver will be able to react without endangering other
vehicles on the roadway.

By the time the vehicle has passed the advance and clearance reader, it
has been electronically cleared. However, it is also necessary to verify
that vehicles are not illegally bypassing a check station. Therefore, a
compliance reader and an AVC system are located on the mainline, past
the entrance ramp to the station. The AVC identifies un-tagged
commercial vehicles that have illegally passed the station. The reader
checks tagged vehicles to verify that the vehicle was cleared to bypass
the station. If a violation is detected, an indication is given to
enforcement personnel.

Vehicles entering the check facility would fall into one of the
following categories:

1.  DSRC-equipped, valid legal weight - the vehicle has been identified
    via DSRC, a valid weight has been recorded and an active screening
    decision has been made to stop the vehicle for some type of closer
    review. This may be based on specifically identified problems, or
    may be due to random selection. Closer review may be limited to a
    visual check while on the static scale, or may include an inspection
    based on the visual review, on data reported back in the screening
    process, or on random selection.

2.  DSRC-equipped, invalid or over weight - the vehicle has been
    identified via DSRC, however, either the WIM failed to properly
    register the weight or the detected weight exceeded the criteria

3.  DSRC-equipped, unrecognized - the vehicle is equipped with a
    transponder, however, the tag may either be incompatible with or not
    valid for use at the site

4.  No DSRC

Upon entering the facility ramp, vehicles will be processed by the ramp
WIM. The DSRC ramp reader would interrogate the vehicle tag to retrieve
the relevant identification data. A screening decision would be made and
the vehicle would be subsequently directed by visual lane signals.
Cleared vehicles would be signaled to return to the mainline. Vehicles
receiving a pull-in decision on the ramp would be directed to the static
scale.

The static scale reader is used to identify transponder-equipped
vehicles that are on the scale. Safety and credential data for the
vehicle would be available to the static scale operator.

**Mobile enforcement units** can be equipped with various combinations
of DSRC, automatic vehicle identification (AVI), AVC, and WIM systems.
They are typically positioned in areas where violations are known or
suspected to occur. These units are equipped with tag readers that allow
them to interface with vehicle transponders and mobile computers that
look up credential and safety records either locally or stored in the
infrastructure. It is also possible to implement a "plug in" approach
where screening equipment, such as a DSRC reader, may be installed in a
standalone cabinet in a remote location with a pull-off capability. The
mobile unit could link its on-board computer equipment to the locally
installed equipment upon arrival at the screening site, and could be set
up for screening operations in a short time. Departure preparations
would also be simpler, allowing more time on-site and permitting a more
rapid departure when necessary.

**Maryland Commercial Vehicle administration** systems support
electronic screening operations in that they provide CVO data required
for electronic screening. The results of roadside activities (vehicles
that were seen and cleared, seen and stopped, inspected, issued
citations, counted in the number of vehicles that passed the station,
etc.) are provided to the Maryland CV safety administration.

**Core infrastructure systems** such as CDLIS may be queried either
directly or indirectly to gather safety, license, and enforcement
information about the carrier, vehicle, and driver.

### Thread Diagrams

The functional thread diagrams shown on the next several pages
(Figures 5-14 and 5-15) present Maryland's approach to the electronic
screening functions:

-   Electronic Screening Roadside Operations

-   Electronic Screening Enrollment

By following the arrows in the sequence indicated by their numbering and
reading the corresponding text charts, the electronic screening
operational scenario can be understood at a high level. Table 5-8,
following the thread diagram, provides additional information about the
data exchanged between the systems at either end of an arrow.

The direction of an arrow indicates primary information flow. Some data
may flow in the opposite direction to verify successful transmission.
For example, EDI X12 functional acknowledgments are not shown as
separate data flows, and the triggering of each message exchange is also
not represented.

![](media/image14.wmf)

Figure 5-14. Electronic Screening Roadside Operations Thread Diagram

Table 5‑8. Electronic Screening Roadside Operations Thread Descriptions

+-----+----------------------------------------------------------------+
| 1\. | CVIEW updates the Roadside Operations computer with snapshots  |
|     | periodically and also proactively for such high-priority data  |
|     | as out-of-service orders. Snapshots are sent as *TS 285*       |
|     | transaction sets.                                              |
+-----+----------------------------------------------------------------+
| 2\. | The Roadside Operations computer creates a specialized set of  |
|     | data tables from the snapshot data and forwards it for         |
|     | real-time use by the Screening computers.                      |
+-----+----------------------------------------------------------------+
| 3\. | When the truck approaches the roadside site, its transponder   |
|     | sends a DSRC CMV Screening Identification message, using the   |
|     | ASTM version 6 standards and IEEE P1455 message set, to the    |
|     | advance transponder-reader, identifying the vehicle, carrier   |
|     | and transponder.                                               |
|     |                                                                |
|     | As the vehicle crosses the mainline weigh-in-motion (WIM)      |
|     | sensor, its weight per axle is sensed and the vehicle type is  |
|     | determined by the associated automatic vehicle classification  |
|     | (AVC) system.                                                  |
+-----+----------------------------------------------------------------+
| 4\. | The transponder-reader sends identifying data to the mainline  |
|     | Screening computer. The WIM sends the vehicle type and weight  |
|     | data. The screening algorithm is run and a screening decision  |
|     | is made.                                                       |
+-----+----------------------------------------------------------------+
| 5\. | The mainline Screening computer formulates a DSRC message and  |
|     | commands the clearance reader to send the appropriate message  |
|     | to the vehicle.                                                |
+-----+----------------------------------------------------------------+
| 6\. | The clearance reader passes the DSRC Set User Interface        |
|     | message to the truck's transponder, indicating red or green    |
|     | light status.                                                  |
+-----+----------------------------------------------------------------+
| 7\. | A compliance reader and an AVC system, located on the mainline |
|     | past the entrance ramp, perform further checks. The AVC        |
|     | identifies un-tagged vehicles that have illegally passed the   |
|     | station. The compliance reader checks tagged vehicles to       |
|     | verify that they were cleared to bypass the station. If a      |
|     | violation is detected, an indication is given to enforcement   |
|     | personnel.                                                     |
+-----+----------------------------------------------------------------+
| 8\. | Vehicles that have been signaled to enter the facility ramp    |
|     | will be processed by the ramp WIM. The ramp reader             |
|     | interrogates the vehicle tag.                                  |
+-----+----------------------------------------------------------------+
| 9\. | When the truck pulls onto the ramp, its transponder sends a    |
|     | DSRC CMV Screening Identification message, using the ASTM      |
|     | version 6 standards and IEEE P1455 message set, to the ramp    |
|     | transponder-reader, identifying the vehicle, carrier and       |
|     | transponder.                                                   |
|     |                                                                |
|     | As the vehicle crosses the ramp weigh-in-motion (WIM) sensor,  |
|     | its weight per axle is sensed and the vehicle type is          |
|     | determined by the associated automatic vehicle classification  |
|     | (AVC) system.                                                  |
+-----+----------------------------------------------------------------+
| 1   | The transponder-reader sends identifying data to the ramp      |
| 0\. | Screening computer. The WIM sends the vehicle type and weight  |
|     | data. The screening algorithm is run and a screening decision  |
|     | is made.                                                       |
+-----+----------------------------------------------------------------+
| 1   | The ramp Screening computer commands the overhead lane signals |
| 1\. | according to the screening decision, directing the vehicle to  |
|     | proceed to either the static scale or the bypass lane.         |
+-----+----------------------------------------------------------------+
| 1   | For those vehicles that have been pulled in on the ramp, the   |
| 2\. | static scale reader is used to identify transponder-equipped   |
|     | vehicles.                                                      |
+-----+----------------------------------------------------------------+
| 1   | The Screening computers report to the Roadside Operations      |
| 3\. | computer the vehicle information and the results of screening  |
|     | decisions.                                                     |
+-----+----------------------------------------------------------------+

![](media/image15.wmf)

Figure 5-15. Electronic Screening Enrollment Thread Diagram

Table 5‑9. Electronic Screening Enrollment Thread Descriptions

  ------ ----------------------------------------------------------------
  1\.    The carrier contacts the Electronic Screening Administrator for
         Maryland (the Enrollment Agent State) and manually submits
         applications for enrollment.

  2\.    The Electronic Screening Enrollment administrator processes the
         request and performs enrollment criteria checks and data
         verification. The carrier application is either approved or
         disapproved, based on the state\'s enrollment criteria. The
         Electronic Screening Enrollment administrator sends carrier and
         vehicle snapshot segment updates to CVIEW, via an EDI X12 *TS
         285* or XML.

  3\.    The Maryland CVIEW sends carrier and vehicle snapshot segment
         updates to the Roadside Operations system, via *TS 285*.

  4\.    The Maryland CVIEW sends carrier and vehicle snapshot segment
         updates to SAFER, via *TS 285.* These updates include the
         participation request data and Maryland acceptance decision.

  5\.    SAFER sends the carrier and vehicle snapshot segment updates to
         Additional E-Screening state CVIEWS, via *TS 285*.

  6\.    The Additional E-Screening State CVIEW forwards the carrier
         snapshot to the E-Screening Enrollment administrator, via a TS
         *285*.

  7\.    The Additional E-Screening State Enrollment administrator
         processes the request and either approves or disapproves the
         Carrier\'s participation. The E-Screening Enrollment system
         transmits the state\'s decision to CVIEW as a carrier snapshot
         segment update, via a *TS 285*.

  8\.    The Additional E-Screening State CVIEW sends carrier and vehicle
         snapshot segment updates to the Roadside Operations system, via
         a *TS 285*.

  9\.    The Additional E-Screening State CVIEW sends carrier and vehicle
         snapshot segment updates to SAFER, via a *TS 285*. These updates
         contain the acceptance decisions.

  10\.   SAFER sends the carrier and vehicle snapshot segment updates to
         the Maryland CVIEW, via a *TS 285*.

  11\.   Carrier and vehicle snapshots may be viewed by the Electronic
         Screening Enrollment administrator by performing queries against
         the Maryland CVIEW. The query responses from CVIEW will be via a
         *TS 285*.
  ------ ----------------------------------------------------------------