# Presentation: 157135

## 4  System DesignTable of Contents

- 4  System DesignTable of Contents

-  1	Executive Summary
-  2  Introduction
-  3  Objectives
-  4  System Design
-  5  Work Breakdown Structure
-  6  Organization
-  7  Work Assignments
-  8  Processes
-  9  Phases & Critical Milestones
- 10  Schedule
- 11  Resources
- 12  Products
- 13  Issues
- 14  References

- 4.1  Top-level CVIEW Design
- 4.2  Key CVIEW Design Features
- 4.3  Snapshot Data Stored in CVIEW
- 4.4  Snapshot Data Passed to the Roadside
- 4.5  High-level CVIEW Data Exchange 		Requirements

## Top-level CVIEW Design

**Information**
**Users**
- Insurer
- Mobile Unit
- Roadside
- SAFETYNET
- Shipper
- HELP
- Advantage CVO
- Carriers
- SAFER
- State Systems
- Clearinghouses
- Others...

**Indirect**
**Sources**
**SAFER**
**Multi-State Systems**
**Clearinghouses**

- Other Government
- Systems

**Commercial / Government**

**Wireline / Wireless Services**

**       ****(e.g., NLETS, AAMVAnet, VANs)**

- Financial Institutions

**Authoritative**
**Sources**
**State Systems**

***Top-level CVIEW Design***

## Key CVIEW Design Features

- Client-server data exchange with limited trusted systems, e.g., SAFER
- Snapshots for carrier, vehicle, and driver safety and credentials information exchange; exchange of partial snapshots or views are supported
- Subscriptions for the definition and proactive transmission of user-defined data
- Division of Functionality:
**Core Functionality**
**common to all CVIEW Systems**
**encompasses exchange of carrier, vehicle, and driver safety and credential information with SAFER and state legacy systems via X12 EDI 285 transactions; limited client-server communications with trusted systems, .e.g. SAFER, is supported**
**Customized State Functionality**
**custom modifications to CVIEW via Legacy System Interface (LSI) modules or modifications to the state’s legacy systems via Legacy Modifications (LM) will be required for those States with data processing requirements that are incompatible with CVIEW core functional processing capabilities **

***Key CVIEW Design Features***

## Key CVIEW Design Features (cont.)

- There are 3 kinds of snapshots: carrier, vehicle, and driver.
- The use of common identifiers allows agencies and jurisdictions to exchange information
- Identifiers, census/demographic information, safety history summary, and credential information are included in snapshots
- Limited DMV data are included in the snapshots
- (a) Vehicle apportionment data
- (b) DMV check flags may also be included.  A check flag is used to indicate a recent problem, but does not attempt to define current status.
- Each state may include special check flags to alert its roadside officers to some particular problem

***Key CVIEW Design Features (cont.)***

## Snapshot Data Stored in SAFER/CVIEW

- Notes:
- 1 = Data are current; all other data are historical;
- 2 = State may store in CVIEW or may request SAFER to store

*There are 3 kinds of snapshots: carrier (available now), vehicle, and driver;*
*The use of common identifiers allows agencies and jurisdictions to exchange information;*
*Limited DMV data are included in the snapshots*
*(a) Vehicle apportionment data*
*(b) DMV check flags may also be included.  A check flag is used to indicate a recent problem, but does not attempt to define current status.*
*Each state may include special check flags to alert its roadside officers to some particular problem.*

- 1

- 2

- 3

- 4

- 1

- 2

- 3

- 4

- 4

**Snapshot Data Stored in SAFER/CVIEW**

***Snapshots are assembled & stored to facilitate the exchange of safety & credentials Information among systems.***

## Snapshot Data Passed to the Roadside

- 1

- Notes:
- 1 = Data are current; all other data are historical;
- 2 = State may store in CVIEW or may request SAFER to store

- 1

***A subset of the snapshot data are sent to the roadside for use in electronic screening.  If more data are needed, queries to CVIEW, SAFER, or the authoritative source are issued.***

**Snapshot Data Passed to the Roadside**

## CVIEW Data Exchange Requirement Level Definitions

- Requirement Level - the compatibility requirement level assigned to this compatibility criterion by the CVISN project team.  For a state to be "compatible with CVISN," it must implement selected items in the checklists.  To distinguish those items, the CVISN project team has assigned a compatibility requirement level to each checklist item:
- (L1)	This rating indicates a **Level 1** Deployment level of CVISN compatibility.  Satisfying all of these achieves the minimal level of compatibility.  Based on the state of technology, standards, and operational demonstrations, stakeholders are encouraged to complete these items first.  In most cases, these items could be completed in a 1-2 year time frame.
- (E)	This rating indicates an **enhanced** level of CVISN compatibility.  These items may require a little longer to complete (3-4 years).
- (C)	This rating indicates a **complete** level of CVISN Compatibility.  Satisfying all these provides complete CVISN compatibility.   These items are expected to require a longer-range (5 or more years) time frame.

## High-level CVIEW Data Exchange Requirements

## High-level CVIEW Data Exchange Requirements (con’t.)

## This page Intentionally blank

**This page Intentionally blank**