# Presentation: 357858

## Wisconsin’s Top Level Design

- CVISN Design Workshop
- May 30 – June 1, 2001
- New Orleans, LA

## Wisconsin CVISN Objectives

- Provide efficient application, processing and delivery of motor carrier credentials (e.g. registration, tax payments, permits, etc.)
- Increase the efficiency and effectiveness of CVO enforcement
- Enhance safety of commercial vehicle operations

## Wisconsin Features

- Staggered IRP registration schedule built around IFTA activities
- No state HazMat program
- Deployment of statewide directory for interaction between citizens and state
- OSOW Permit Unit staff handle many functions that are performed by engineers in other states.

**Notes:**
Directory: Each individual is assigned roles that allow various activities.  The same login for applying for a permit could also allow registration for a campground site or an inquiry as to the status of an income tax return.
OSOW: An example would be imposing a condition of "slow vehicle to 5 mph" as an amelioration of weight impact on a bridge where passage over requires no dynamic loading.

## Key Strengths

- Organizational factors
- Experience in CVISN-related activities
- Underlying technology infrastructure

## Organizational Factors

- Single-agency umbrella for CVO regulation and enforcement
- DOT Technology Management Council
- Flexible procurement practices
- CVO Business Plan used to guide activities – proven valid over time

**Notes:**
WisDOT: Almost everyone is under the same roof.
TMC: Consists of representatives from all divisions who review project proposals and prioritize them based on departmental value and resource availability.
Procurement: Many items such as professional services, personal computers, and standard software packages are available from pre-approved lists.
CVO Business Plan: just updated this month.

## Challenges: Organizational

- Legislature privacy concerns
- Biennial budget process timing
- Securing state matching funds
- DOT Technology Management Council project prioritization
- Proposed Department of Electronic Government
- Multi-vendor environment

**Notes:**
State of Wisconsin laws exist to ensure that government is open and that the public has a right to access appropriate records and information possessed by state government. At the same time, there are exceptions to the public's right to access public records provided by both state and federal laws. These exceptions include the privacy of individuals.
The state Records Privacy Act allows individuals to opt out of having their personal information released in bulk to third parties, such as telemarketers and direct-mail firms.
"The fishing season brought the number of opt-outs with the DNR to 484,904," said Sen. Jon Erpenbach (D-Middleton), one of the law's sponsors. "The message is loud and clear. The State of Wisconsin should not rerelease personal information for mass-marketing purposes."
The law allows access to personal information from license applications, but only in batches of 10 or fewer, preserving access to information but making it impractical for marketing firms to get it wholesale.

## CVISN-Related Experience

- MOOSE – _M_CSAP _O_ut _O_f _S_ervice _E_nforcement
- Deployed between WI and MN
- Snapshots used to determine red-light
- License plate reader
- Data sharing between states
- Standardized data and report formats
- Timing of data – critical issue

**Notes:**
Jim Newton will be presenting the algorithm used to determine an out of service violation in a Birds Of A Feather presentation.

## CVISN-Related Experience

- MCES – _M_otor _C_arrier _E_nforcement _S_ystem
- Collects information from every contact that State Patrol has with carrier and vehicle
- Beginning of SAFER-like functionality within the state
- Operational since 1987 – 14 years of data
- Available real-time at SWEF

## CVISN-Related Experience

- OOPPS – _O_versize / _O_verweight _P_ermit _P_rocessing _S_ystem
- On-line application for annual permits
- Limited self-issuance of single-trip permits using table-driven routing
- Will expand to include on-line renewal of annual permits, automated routing engine, and electronic payment acceptance

## CVISN-Related Experience

- Expertise in various information systems technologies that will be useful for CVISN deployment
- IBM VisualAge for Java
- JavaBeans and Enterprise JavaBeans
- IBM DB2
- Oracle
- IBM WebSphere

## Technology Infrastructure

- Statewide wideband network
- Single state mainframe data center
- Agencies have their own separate LANS
- Every Safety and Weight Enforcement Facility (SWEF) has had access to most state and federal systems since 1987

## Technology Infrastructure

- Mobile Data Computers (MDC)
- Operational since 1997
- Deployed in entire fleet including Motor Carrier Enforcement vehicles and 90+ individual law enforcement agencies
- Dual Web sites – WisDOT and vendor (The Polk Company)

## Challenges: Technological

- Electronic funds transfer and credit card acceptance a work in progress
- Timing of XML alternative availability affects WisDOT and Polk development plans and strategies
- Multi-vendor environment
- Connectivity to Clearinghouses
- Data scrubbing for routing engine

**Notes:**
Connectivity to Clearinghouses
IFTA Clearinghouse – communication is via dial-up modem.
IRP Clearinghouse – must go through AAMVANET.
Multi-vendor Environment
Changes to accommodate CVISN requirements requires coordination of work efforts from multiple vendors.
Data Scrubbing for Routing Engine
Highway databases weren’t constructed with routing requirements in mind. Data will have to be cleansed to be useful.

##   Wisconsin Top Level Design - 4/19/2001

**Wisconsin State Roadside Systems**

**Wisconsin Commercial Vehicle Administration Systems**

**Carrier Systems**

**Credentialing **
**System **
**(e.g., CAT)**

**CVISN **
**Core Infrastructure**
**Systems**
** ****(National/Regional)**

**MCMIS**

**IFTA**
**Clearinghouse**

**IRP**
**Clearinghouse**

**NMVTIS**

**SAFER**

**NCIC / NLETS**

**Compliance **
**Review **
**(e.g., CAPRI)**

**Service Providers**

**Internet Tools**
**(e.g. Browser)**

**Other Carrier**
**Systems**

**Transponder**

**Carrier Commercial**
**Vehicle**

**CI **

**Licensing &**
**Insurance**

**     ****CDLIS**

**DOT**
**Web Site **(12)

**DOJ **(14)
**Crime Files**

**Note: Each LSI also contains a**
**messaging interface component**

**Driver **(2)
** ****Licensing**

**DMV **(7)
**Revenue**

**Intrastate**
**Veh Reg**

**Titling**

**Authority &**
**Insurance**

**SSRS**

**IRP**

**IFTA**

**SafetyNet2000**

**MCES**

**Message**
**Interface**

**DOJ**
**Msg Switch**

**PrePass**
**   ****Screening**

**MCES **
**Client **

**ISS**

- L
- S
- I

- M
- I

- L
- S
- I

- M
- I

- L
- S
- I

- M
- I

- M
- I

- L
- S
- I

- L
- S
- I

- M
- I

- L
- S
- I

- L
- S
- I

- L
- S
- I

- M
- I

- M
- I

- M
- I

**OSOW**

- L
- S
- I

- M
- I

- M
- I

- M
- I

**CVIEW**

- M
- I

- L
- S
- I

- (1)

- (1)

- (3)

- (4)

- (5)

- (8)

-  (9)

-  (10)

- (11)

- (13)

- (8)

- (15)

- (16)

- (17)

- (18)

**PrePass**
**Service Center**

- (19)

- (20)

**Service Provider**
**Web Site **(21)

## Top Level Design Principles

- Messaging/Queuing approach to application integration
- Minimize interfaces to external systems
- Snapshot updates will be done on transactional basis
- Minimize Legacy Applications Changes
- Communication among state legacy systems use existing syntax

**Notes:**
Adaptability
Flexibility
Maintainability

## Key Top Level Design Features

- Messaging Interface
- CVIEW
- PrePass with integrated WIM
- ASPEN Equivalent
- Carrier Access

**Notes:**
Flexibility

## Messaging Interface (MI)

- Communications among state systems handled via the MI
- Routes transactions between legacy applications, CVIEW, CI & Roadside
- Employs scripts associated with specific transaction types
- Provides application connectivity across different hardware/software environments

**Notes:**
Adaptability
Flexibility
Operational scenarios will better explain message interface flows.

## CVIEW

- CVO Snapshot summary database for both interstate and intrastate carriers
- Interface to the SAFER system
- Bi-directional distribution hub between roadside systems and SAFER
- Interface to PrePass PreView for periodic SnapShot updates

## PrePass with Integrated WIM

- Combination of PrePass and mainline WIM for screening
- PrePass roadside screening computer updated every 80 minutes
- CVIEW provides periodic Snapshot updates to PrePass PreView
- Message boards signal pull in/bypass at Menomonie SWEF
- Uniform roadside architecture proposal – Jim Newton

**Notes:**
Adaptability

## Typical PrePass Roadside Screening Configuration Single Lane Scale 5/21/2001 

- Advance
- location
-  reads Truck
- Transponder ID

- ICN Signals
- bypass or pull in
- Decision to truck
- transponder

- 1000 ft

- 4000 ft

- Gore
- point

- WIM
- scale

- Scale house

- Static
- Scale
- lane

- Inspection/
- Observation
- lane

- Static
- scale

- Compliance
- reader

- WIM
- scale

## ASPEN Equivalent

- Builds on current MCES functionality
- Replaces current 3270 configurations at SWEFs with MCES Client
- Client Provides SWEF access to Snapshots via CVIEW, state source systems and DOJ switch
- Hope to ultimately link Client to PrePass screening computer

**Notes:**
Adaptability

## Carrier Access

- Accommodates web and computer to computer access
- Transactional web access available to limited number of carriers for OSOW today
- Piloting Polk COVERSnet web access to IFTA
- Computer to computer access for carriers underway

**Notes:**
Flexibility

## Wisconsin Top Level Physical Design - 4/19/2001

- DOA  Data Center - DOT portfolio

- DOT / DSP (Roadside) LAN

- Authority
- &
- Insurance

- Carrier Systems

- SAFER

- CDLIS

- Licensing  &
- Insurance

**Driver **
**Licensing**

- IRP
- Clearinghouse

- IFTA
- Clearinghouse

- Internet Tools

- MCES
- Client

- ISS

- Firewall

- Intrastate
- Veh Reg

- Titling

- MCES

- DMV
- Revenue

**IRP**
**Clone**

- DOJ Msg
- Switch
- Interface

- SSRS

- OSOW
- Data Base

- CVIEW

- CI

- OSOW
- Application

- DOT
- Web Site

**MadMan **
**OC3**
**Ring**

- Firewall

**BadgerNet**
**OC3**
**Ring**

** ****(2)**

- DOT LAN’s - HFSTB

- (1)

-  DOJ

- Crime
- Files

- Message
- Switch

-      MCMIS

- NCIC
- NLETS

- CVISN Core
- Systems

- Firewall

- T1’s
- to all
- State Agency
- & law enfor.
- remote sites
- (4)

- T1
-   (5)

-  ** ****Internet**

- (6)

-    DOT / DSP AS/400

- MDC
- Controller

**DSP**
**Microwave**
**network**

- (7)

- (8)

- (10)

- (11)

- (12)
- Oracle
- IRP / IFTA

- SafetyNet2000
- (13)

**Internet**

**(9)**

**(3)**

**(17)**

**(14)**

**(16)**

- (18)
- PrePass
- Screening

**Msg Interface**

**Msg Interface**

**(15)**

**  ****(15)**

- Credential
- System

- PrePass
- Service Center

- Service
- Provider
- Web Site

## Top Level Physical Design

- Mapping of applications to data centers and roadside
- Network infrastructure
- Middleware plumbing
- Directory services

## Application System Mapping

- DOA OS/390 Mainframe hosts most of portfolio
- DOT LANs (HPUX/Oracle & NT)
- DOT AS/400 (mobile data computer controller)
- DOT NT workstation at SWEFs
- DOJ Unix message switch

## Network Infrastructure

- BadgerNet and MadMan connectivity
- BadgerNet network topology
- Protocols
- Mobile data computers

##  MadMan

- ATM ring connecting Madison metro area state government HQ locations
- Connection to other agency HQ’s
- Connection to BadgerNet
- Connection to Internet (Napnet)
- Each agency has its own firewall
- OC3 speed (155mb)

**Notes:**
Reliability

## BadgerNet

- OC3 SONET backbone ring
- 19 ATM switches provide access to ring
- Access links from remote locations to ring T1 (1.544mb) minimum speed
- BadgerNet Backbone & MadMan are ATM
- Access links are Frame Relay
- Presence in 1800 locations

**Notes:**
Flexibility

## BadgerNet Network Topology

**Notes:**
Dependability

## Protocols

- All BadgerNet connections are IP
- IP Internet connections to Core,Carrier & vendor systems
- Exceptions are NCIC/NLETS and CDLIS
- NCIC/NLETS private T1 running IP
- CDLIS 256kb Frame Relay running encapsulated SNA over IP

## Mobile Data Computers (MDC)

- State Patrol Microwave system provides statewide wireless backbone
- Proprietary MDC protocol
- Upgrade to IP planned, however........
- Cellular pilot underway as an interim solution
- No CDPD in Wisconsin, cellular coverage sparse in northern areas

**Notes:**
Susceptability

## Middleware Plumbing

- Will employ IBM MQSeries
- Middleware that the Messaging Interface (MI) will be built on
- Provides cross platform connectivity between applications
- Supports hardware platforms ranging from Palms to OS/390
- Supports application environments such as CICS, Websphere, Oracle, etc

**Notes:**
Flexibility
Maintainability
Expandability

## Directory Services

- Statewide directory services facility in limited production
- Built on Novell eDirectory (LDAP)
- Single ID and authentication credentials
- Allows self registration & maintenance by business partners
- OSOW first production application using the directory

## SWEF Of The Future

**Notes:**
Includes inspection facilities, additional parking area, driver area open 24 hours a day.

## New Component Summary

- Credential Interface
- Sole interface for transactions between the state and carriers / carrier agents
- Receives transactions
- Sends acknowledgements and products
- Performs basic editing
- EDI and XML translations

**Notes:**
The Credential Interface (CI) will be the sole state interface point for EDI transactions from carriers and carrier agents.
Its principal function is to receive transactions from the carriers or agents, send acknowledgements and products back to the carrier or agent, and provide basic editing for application completeness.
It will also provide EDI (eventually XML) translations to and from internal state system formats.
Communication among legacy systems internal to the state will continue to use the syntax native to the legacy system.
The exception is for vendor-supplied applications such as IRP and IFTA that will use EDI, as well as external interfaces to carrier systems and federal systems.

## New Component Summary

- Message Interface
- Closely integrated with Credential Interface
- Additional functionality includes
- Receive and store transactions arriving from carriers and agents
- Assemble “information packages”
- Send acknowledgements and products
- Route updated status to CVIEW
- Route snapshots from CVIEW to roadside
- Route selected Snapshots to PrePass Service Center

**Notes:**
The Messaging Interface (MI) is closely integrated with the CI and provides messaging and queuing services. Conceptually, the Messaging Interface would have scripts associated with specific application transaction types that would enable it to:
Receive and store transactions arriving from carriers and carrier agents
Spawn transactions to other systems to gather status information needed by a credentialing system to process an incoming transaction
Assemble “information packages” (the incoming carrier application transaction, and required status information) and forward to appropriate credentialing system
Send acknowledgements and credentialing system products back to carrier or carrier agent
Route credentialing system updated status to CVIEW
Return detailed credential information in response to an enforcement query from the MCES client
Route Snapshots from CVIEW to roadside systems
Route selected Snapshots to PrePass Service Center CVIEW equivalent (PreVIEW) periodically

## New Component Summary

- CVIEW
- Wisconsin CVIEW
- Built using APL or vendor CVIEW
- Single interface point with SAFER
- Summary information database
- Interstate
- Intrastate

**Notes:**
The CVIEW will be the interface point between the state and the federal SAFER system.
State credentialing & safety legacy systems will provide status updates to CVIEW via the Messaging Interface.
We will NOT have roadside or credentialing systems communicating directly with federal core systems such as SAFER.
CVIEW will serve as the motor carrier summary information database for both inter and intra state carriers.

## New Component Summary

- MCES Client
- ROC functionality
- Retrieves snapshot data from CVIEW
- Provides roadside access to state systems
- ASPEN equivalent
- Automated inspection reporting

**Notes:**
The MCES Client provides the functions associated with the Roadside Operations Computer (ROC), i.e. interface to CVIEW to get snapshot data
Provides roadside access to state source systems.
It also, in conjunction with MCES, provides the ASPEN equivalent automated inspection reporting function. 

## New Component Summary

- PrePass and integrated WIM
- Voluntary program
- Electronic clearance
- Mainline Weigh-In-Motion
- Separate screening computer
- PreVIEW connection to CVIEW
- Future connection to MCES

**Notes:**
The PrePass system allows checking motor carrier credentials and weight at highway speeds without stopping the vehicles at inspection stations.
As the truck passes over automatic sensors built into the highway, the sensors weigh the vehicle and transmit data to a roadside computer, which verifies that state-required credentials are in order.
The PrePass Screening Computer is a new component to be added. This is supplied as part of the PrePass program.
The Screening Computer is used to make the screening decision (pull in or bypass) based on sensor inputs and the snapshot screening criteria.
We expect the MCES Client will ultimately connect to the PrePass Screening Computer to obtain the VIN #’s for vehicles receiving a pull in signal. The MCES Client will use these VIN #’s to query state source systems for detail information to be made available to the roadside inspector, without needing to manually key the inquiries.

## System Change Summary

- Migration of MCES Client from 3270 terminals to LAN-based workstations
- LSIs and LMs for all legacy applications
- Network Connections

## CVISN Level 1 ComplianceSafety Information Exchange

| ASPEN (or equivalent) at all major inspection sites. | We have implemented our MCES (ASPEN equivalent) at all sites |
| --- | --- |
| Connection to the Safety and Fitness Electronic Record (SAFER) system to provide exchange of interstate carrier and vehicle snapshots among states.
 | We will connect to SAFER via our CVIEW |

## CVISN Level 1 ComplianceSafety Information Exchange

| Implementation of the Commercial Vehicle Information Exchange Window (CVIEW) (or equivalent) system for exchange of intrastate and interstate snapshots within state and connection to SAFER for exchange of interstate snapshots. | We will implement a Wisconsin CVIEW for snapshot exchange within the state and connect it to SAFER |
| --- | --- |

## CVISN Level 1 ComplianceCredentials Administration

| Automated processing (i.e., carrier application, state application processing, credential issuance, and tax filing) of at least IRP and IFTA credentials; ready to extend to other credentials [intrastate, titling, oversize/overweight (OS/OW), carrier registration, and hazardous material (HAZMAT)].
Note: processing does not  necessarily include e-payment. | We will be deploying Polk’s COVERSnet application to provide automated processing of IRP and IFTA credentials. 
OS/OW deployment is progressing, with limited self-issuance of permits now in production. |
| --- | --- |

## CVISN Level 1 ComplianceCredentials Administration

| Connection to IRP and IFTA Clearinghouses. | We are connected to the IFTA Clearinghouse and we intend to join the IRP Clearinghouse |
| --- | --- |
| At least 10 percent of the transaction volume handled electronically; ready to bring on more carriers as carriers sign up; ready to extend to branch offices where applicable. | We expect to meet this volume. We are working with Polk to add EDI capabilities. |

## CVISN Level 1 ComplianceElectronic Screening

| Implemented at a minimum of one fixed or mobile inspection site.
Ready to replicate at other sites. | We have a preliminary agreement with PrePass to implement their screening and clearance system at our Hudson and Menomonie SWEFs |
| --- | --- |

## Phases & Builds

**Notes:**
Explain the color coding on this slide so people can follow along without being too confused.
BTW, we had a LOT of concern from our Steering Committee members about placing dates on the phase chart.  We’d like to hear from other states as to their experiences in this regard and how they handled it.

## Safety Projects

## CVIEW

**Notes:**
CVIEW Build 1: Complete development of a local CVIEW using existing software available from JHU/APL or other vendor.
CVIEW Build 2: Implement connectivity between CVIEW and SAFER.
CVIEW Build 3: Add intrastate information to CVIEW.

## USDOT Number

**Notes:**
USDOT# Build 1: Implement modifications to add the USDOT# to intrastate data files and allow entry and maintenance.

## Credentials Projects

## OSOW

**Notes:**
OSOW Build 1: Limited self-issuance of Single Trip permits, using a table based route restriction evaluation routine. Online application for Annual Multiple Trip permits.
OSOW Build 2: Online renewals of Annual Multiple Trip permits. Automated faxing of self-issued permits. Online inquiry of permit application status. Routing system decision.
OSOW Build 3: Credit card acceptance. Limited self-issuance of Annual Multiple Trip permits.
OSOW Build 4: Automated Routing. Expand self-issuance of Single Trip permits.

## Electronic Credentialing

**Notes:**
Electronic Credentialing Build 1: Provide electronic access to COVERSft, Polk software used to process IFTA transactions. Initially will allow a carrier to submit their fuel tax returns.
Electronic Credentialing Build 2: Provide electronic access to COVERS, Polk software used to process IRP transactions. Initially will allow a carrier to apply for supplements.
Electronic Credentialing Build 3: Add increased functionality to electronic access to both the COVERS and COVERSft applications, including the ability to accept electronic payments.

## IRP Clearinghouse

**Notes:**
IRP Clearinghouse Build 1: Join the IRP Clearinghouse and implement connections between the Polk COVERS application and the Clearinghouse.

## Screening Projects

## PrePass

**Notes:**
PrePass Build 1: Implement a PrePass facility at the Hudson SWEF.
PrePass Build 2: Implement snapshot-based PrePass screening.
PrePass Build 3: Implement a PrePass facility at the Menomonie SWEF.

## MCES

**Notes:**
MCES Build 1: Migrate the current MCES Client from the existing 3270 environment to a LAN-based workstation environment.
MCES Build 2: Connect the MCES client to CVIEW.

## Project Planning

**Notes:**
Project Planning: This is the initial CVISN project planning and consists of the planning and design activities that we are doing as part of the CVISN workshop series.

## CI/MI

**Notes:**
CI/MI Build 1: Introduce IBM MQSeries as the underlying technical infrastructure component for this messaging and queuing application.
CI/MI Build 2: Complete development of a prototype application to link this messaging interface with a small number of other systems.
CI/MI Build 3: Expand the prototype application to include links with other systems.

## Phase 6 and Beyond

**Notes:**
New systems identified and initiated.
Full system interoperability testing - first opportunity for full system interoperability tests.
Interoperability tests performed in each of earlier phases where applicable.

## Accept and Process IRP Renewal Applications  4/17/2001

**Wisconsin**
**Roadside Systems**

**Carrier Systems**

**Credentialing **
**System **
**(e.g., CAT)**

**CVISN **
**Core Infrastructure**
**Systems**
** ****(National/Regional)**

**NCIC / NLETS**

**IRP**
**Clearinghouse**

**IFTA**
**Clearinghouse**

**NMVTIS**

**MCMIS**

**SAFER**

**Compliance **
**Review **
**(e.g., CAPRI)**

**Service Providers**

**Internet Tools**
**(e.g. Browser)**

**Other Carrier**
**Systems**

**Transponder**

**Carrier Commercial**
**Vehicle**

**CI/MI**

**Licensing &**
**Insurance**

**     ****CDLIS**

**DOT**
**Web Site**

**IRP**

**L**
**S**
**I**

- A,E,F,H,J

- B,C,G,I,L

- D,K,N

- M

**MCES **
**Client**

**M**
**I**

- O

**PrePass**
**Screening**

**Service Provider**
**Web Site**

**PrePass**
**Service Center**

**Wisconsin Commercial Vehicle Administrative Systems**

**M**
**I**

**CVIEW**

**M**
**I**

**Notes:**
Key Points:
Multiple inputs (CAT, internal and external Web)
CI/MI responsible for communications between carrier/agency and WisDOT
CI/MI gathers the necessary information for transmittal to our IRP system
IRP system assembles snapshot information and sends it to CI/MI for transmittal to SAFER and PreVIEW via CVIEW
Products and acknowledgements are sent back to a carrier/agent browser as e-mail attachments. If connecting through a CAT, CI/MI will queue responses until the carrier establishes a connection

## Issue New Oversize/Overweight Permit  4/19/2001 

**Wisconsin **
**Roadside Systems**

**Carrier Systems**

**Credentialing **
**System **
**(e.g., CAT)**

**CVISN **
**Core Infrastructure**
**Systems**
** ****(National/Regional)**

**NCIC / NLETS**

**IRP**
**Clearinghouse**

**IFTA**
**Clearinghouse**

**NMVTIS**

**MCMIS**

**SAFER**

**Compliance **
**Review **
**(e.g., CAPRI)**

**Service Providers**

**Internet Tools**
**(e.g. Browser)**

**Other Carrier**
**Systems**

**Transponder**

**Carrier Commercial**
**Vehicle**

**CI/MI**

**Licensing &**
**Insurance**

**     ****CDLIS**

**DOT**
**Web Site**

**DMV Revenue**

**MCES **
**Client**

**M**
**I**

**PrePass**
**Screening**

**OSOW**

**L**
**S**
**I**

- G

- C,D,G,H

- B,C,D,E,F,G

- A,E,F

**Service Provider**
**Web Site**

**PrePass**
**Service Center**

**Wisconsin Commercial Vehicle Administrative Systems**

**M**
**I**

**M**
**I**

**CVIEW**

**Notes:**
Key Points:
Multiple inputs
CI/MI responsible for communications between carrier/agency and WisDOT
In this scenario, CVIEW is used as a credentialing data warehouse to determine whether credentials are in order before a permit may be issued
Snapshot information assembled and sent to CI/MI for transmittal to SAFER and PreVIEW via CVIEW
Products and acknowledgements are sent back to a carrier/agent browser as e-mail attachments. If connecting through a CAT, CI/MI will queue responses until the carrier establishes a connection

## Screen Vehicles / Record Inspections & Report to SAFER 4/23/2001

**Wisconsin **
**Roadside Systems**

**Carrier Systems**

**Credentialing **
**System **
**(e.g., CAT)**

**CVISN **
**Core Infrastructure**
**Systems**
** ****(National/Regional)**

**NCIC / NLETS**

**IRP**
**Clearinghouse**

**IFTA**
**Clearinghouse**

**NMVTIS**

**MCMIS**

**SAFER**

**Compliance **
**Review **
**(e.g., CAPRI)**

**Service Providers**

**Internet Tools**
**(e.g. Browser)**

**Other Carrier**
**Systems**

**Transponder**

**Carrier Commercial**
**Vehicle**

**Licensing &**
**Insurance**

**     ****CDLIS**

**CVIEW**

**MCES **
**Client**

**PrePass**
**Screening**

**CI/MI**

**MCES**

**DOJ Msg **
**Switch**

- A,B

- E

**Wisconsin Commercial Vehicle**
**      ****Administration Systems **

**L**
**S**
**I**

- H,K

- J

-  C

- F,G

- D

- L

**PrePass**
**Service Center**

**SAFETYNET2000**

- I

- M

**M**
**I**

**M**
**I**

**M**
**I**

**L**
**S**
**I**

**M**
**I**

**Notes:**
Key Points:
PrePass & mainline WIM used for screening and clearance
VIN passed to MCES Client when pull-in signal is sent – future capability
Inspection information goes immediately to SAFER
Inspection information sent to SAFETYNET 2000 for cleansing and transmission to SAFER with updated information

## Key Issues

- CVIEW and SAFER
- Interface Specifications
- EDI vs. XML – we will attempt to decouple and defer development of these pieces
- Polk COVERSnet software – standards used and available functions
- Electronic funds transfer and credit card acceptance

## Key Issues

- State Requirements
- State privacy concerns and conflict with open records – debate in legislature
- Biennial budget process – money
- Technology Management Council prioritizes projects – resources
- Ability to read non-PrePass transponders would be dependent upon money and resources
- Conflict between modal and non-modal divisions

**Notes:**
State of Wisconsin laws exist to ensure that government is open and that the public has a right to access appropriate records and information possessed by state government. At the same time, there are exceptions to the public's right to access public records provided by both state and federal laws. These exceptions include the privacy of individuals.
Timing of money can be a problem, plus there is an identified $761 million hole in budget.
Traditional road building vs. DMV – not a very powerful division.

## Key Issues

- PrePass connections to state systems
- National ITS Architecture vs. CVISN Architecture
- Funding requirements
- Uniform Roadside Architecture

## Uniform Roadside Architecture

-  Thirty minute presentation Friday morning at 8:00
-  Bring comments and questions

## Uniform Roadside ArchitectureNational CVISN Data Landscape (4 States Only)

- LA IFTA
- System

- LA IRP
- Registration
- System

- WI IFTA
- System

- WI IRP
- Registration
- System

- WI MCSAP
- Inspection
- System

- LA Roadside

- MS Roadside

- MS MCSAP
- Inspection
- System

- MS IRP
- Registration
- System

- MS IFTA
- System

- FL Roadside

- FL IRP
- Registration
- System

- FL IFTA
- System

**Goal:  CVISN data moves from every legacy system to every roadside automatically, on time, and in a usable format.**

- WI Roadside

## Uniform Roadside ArchitectureAbsence of Any Architecture

- MS MCSAP
- Inspection
- System

- LA IFTA
- System

- WI Snapshot
- Database

- LA IRP
- Registration
- System

- WI IFTA
- System

- WI IRP
- Registration
- System

- WI MCSAP
- Inspection
- System

- WI Roadside

- LA Snapshot
- Database

- LA Roadside

- MS Snapshot
- Database

- MS Roadside

- MS IRP
- Registration
- System

- MS IFTA
- System

- FL Roadside

- FL IRP
- Registration
- System

- FL Snapshot
- Database

- FL IFTA
- System

**Complexity is out of control**

## Uniform Roadside ArchitecureCVISN Level 1 Architecture

- SAFER

- WI CVIEW

- WI Roadside

- WI MCSAP
- Inspection
- System

- WI IFTA
- System

- WI IRP
- System

- LA CVIEW

- LA Roadside

- LA IFTA
- System

- LA IRP
- System

**Complexity is isolated and manageable**
**Legacy systems are plug-and-play**
**States are plug-and-play**

- Flow of
- standardized
- snapshots

- SAFER
- Databases

## Uniform Roadside ArchitectureTypical Two Vendor Roadside

- WIM
- Sensors

- ASPEN
- equivalent

- PrePass
- Database

- PrePass
- Random

- TID (from truck)

- Combine

- Lane
- Arrows

- VIN
- (eventually)

- To truck receiver

- PrePass Computer

- IRD
- Display

- WIM result
- (red/green)

- Snapshot
- History
- (PIQ)

- WIM
- Random

- Combine

- IRD Computer

- Vehicle
- Detector
- Loops

- PrePass
- Display

- Combo result
- (red/green)

- Combine

- ROC
- Screening Computer

- Combo result
- (red/green)

- PrePass result
- (red/green)

- WIM details

- Combo result
- (red/green)

- Combo result
- (red/green) +
- WIM
- details

- Combo result
- (red/green) +
- WIM details

- State
- CVIEW

- New MCSAP
- Inspection

- ROC
- Display

**Re-emergence of complexity**
**Synchronization between vendors required**
**     ****for both evaluation and notification**
**Multiple displays/keyboards in scale house**
**Maintainability and extensibility concerns **

## Uniform Roadside ArchitectureOpen Architecture

- Vehicle detector loops

- Unified
- Display

- ROC
- Screening
- Computer

- TID (vehicle, possibly driver)

- Standard messages

- To truck receiver

- Proprietary
- Details

- Standard messages

- Any
- Sensor

- Vendor’s
- Device
- Computer

- Notifier
- Device
- Computer

- To lane signals

- Databases:
- Snapshot,
- Summary,
- Parameters,
- Event log

- To VMS

- Standard messages

- Proprietary
- Details
- (Driver sees standard messages.)

- Operator
- commands
- (e.g., random %)

- State
- CVIEW

- ASPEN
- equivalent

- Axle weights

**Complexity is isolated and manageable**
**Devices are plug-and-play**
**ROC tracks vehicles and matches events**
**Driver does not receive conflicting messages**
**ROC routes messages between devices**
**ROC protects sensitive data**
**Maintainable and extensible (possibly to other ITS venues)**

- Devices are like Legacy Systems
- Device computers are like CVIEWs
- ROC is like SAFER

## Uniform Roadside ArchitectureIs It Worth Pursuing?

- Is URA appealing from a technical point of view?
- What impact would adoption of URA have on stakeholders?
- Which forums would be appropriate for considering URA and developing specific standards?
- 	ITS America?
- 	AASHTO?
- 	CVISN level two requirements?
- 	Other?
- Thirty minute presentation Friday morning at 8:00
- Bring comments and questions