EPA-905/2-79-006
DATA PROCESSING PROCEDURES AND EQUIPMENT
     FOR THE WISCONSIN INSPECTION AND
           MAINTENANCE PROGRAM

                   Final Report
                Contract No. 68-02-2887
                Work Assignment No. 8
                    January 1980
        GCA/TECHNOLOGY DIVISION
                 BEDFORD, MASSACHUSETTS 01730

-------
                                         EPA-905/2-79-006
U.S. ENVIRONMENTAL PROTECTION AGENCY
              REGION  V
          CHICAGO, ILLINOIS
       Contract  No.  68-02-2887
          Task Order No.  8
         EPA  Project  Officer
            Carlton Nash
   DATA PROCESSING PROCEDURES AND
EQUIPMENT FOR  THE  WISCONSIN INSPECTION
       AND MAINTENANCE PROGRAM


            Final  Report
            January 1980
             Prepared by
         Frederick M.  Sellars
         1 Michael  W.  Kozenko
       Donjinic  Caracciolo Jr.
            GCA CORPORATION
        GCA/TECHNOLOGY DIVISION
        Bedford,   Massachusetts
                            U.S. Environmental Protection Agency
                            Region 5, Library (P142J)
                            77 West Jackson Boulevard, 12th Floof
                            Chicago, IL  60604-3590

-------
                                 DISCLAIMER
     This Final Report was furnished to the U.S. Environmental Protection
Agency by GCA Corporation, GCA/Technology Division, Bedford, Massachusetts,
01730, in fulfillment of Contract No. 68-02-2887, Task Order No. 8.  The
opinions, findings, and conclusions expressed are those of the authors and
not necessarily those of the Environmental Protection Agency or of cooperat-
ing agencies.   Mention of company or product names is not to be considered
as an endorsement by the Environmental Protection Agency.

-------
                                  ABSTRACT
     The Wisconsin Department of Transportation (WDOT) and Department of
Natural Resources (WDNR) are currently involved in planning for the imple-
mentation of a motor vehicle emissions inspection and maintenance program.
Once operational, the program will be generating a considerable amount of
data.  Tn addition to the obvious problem of handling and analyzing this
data, any system developed must be easily integrated with existing computer
systems in WDOT and WDNR.

     This document defines the computer hardware specifications for emission
testing installations so that needed data can be readily collected, stored,
and transferred to WDOT systems.  In addition, the required software systems
and specifications that will enable manipulation and analysis of data either
on the selected I/M contractor's central computer or the State's system are
identified.   Finally, a model data processing portion of an I/M Request for
Proposals (RFP) is provided.
                                     iii

-------
                                  CONTENTS
Abstract	
Figures	    vi
Tables	    vi

   1.  Introduction	      1
   2.  Summary	      4
            Data Processing Requirements  	      4
            Hardware Requirements	      5
            Software Requirements	    11
            Software Development Costs  	    14
            RFP Considerations	    14
   3.  Data Processing Requirements	    15
            Analysis Requirements	    15
            Input Requirements	    21
   4.  Data Processing Hardware Requirements  	    42
            Processors	    43
            Peripheral Interfaces	    44
            Communications Interface  	    44
            Mass Data Storage Devices	    45
            Magnetic Tape Unit	    45
            CRT Display/Data Entry Terminals  	    45
            Emissions Measurement Subsystems  (EMS)  	    46
            Teleprinters and Line Printers	    48
            State Computer Facilities	    49
   5.  Data Processing Software Requirements  	    50
            Software Required	    50
            Contractor-Developed Software	    53
            State-Developed Software  	    54
            Software Development Costs  	    56
   6.  RFP Considerations	    58
            Model Data Processing Portion of  a Request  for Proposals  for
              a Motor Vehicle Emissions Inspection  Program  	    59
            Definitions	    72
References
74

-------
                                   FIGURES


Number                                                                   Page

  ]     Conceptual layout of a loaded-mode emissions inspection
       lane	     23

  2     Generalized data processing flow plan	     25

  3     State of Arizona vehicle inspection report, obverse side ...     32

  4     State of Arizona vehicle inspection report, reverse side ...     33

  5     Facility computer data links 	     41
                                   TABLES
Number

  1    Operator-Entered or System-Generated Data for each Inspection
       File	      6

  2    Inspection Report Data Provided to the State 	      7

  3    Proposed Vehicle Inspection Report Requirements  	     34

  4    Proposed Dynamometer Loadings as a Function of Vehicle Curb
       Weight and Engine Displacement 	     37

  5    Response Time for Various Processing Modes   	     53
                                     vi

-------
                                  SECTION 1

                                INTRODUCTION
     The 1977 Amendments to the Clean Air Act require that all areas of the
U. S. attain the National Ambient Air Quality Standards (NAAQS) for carbon
monoxide (CO) and photochemical oxidants (Ox) by 31 December 1982.  Each
state containing an area currently in violation of the NAAQS was required to
submit a revision of its State Implementation Plan (SIP) during January 1979,
demonstrating compliance by 31 December 1982.  Recognizing that all states
could not demonstrate compliance by 1982, provisions were made for extending
the compliance date to 31 December 1987.  To be granted an extension, the
SIP revisions must have Included (among other things) a specific schedule
for the implementation of a motor vehicle emissions inspection and maintenance
(I/M) program for those nonattainment areas with urbanized populations greater
than 200,000.  Failure to submit an acceptable I/M implementation schedule
could result in the imposition of sanctions including refusal to grant in-
dustrial permits and loss of certain transportation funding aids.

     Seven counties of southeast Wisconsin are not expected to be in compliance
with the NAAQS for CO and/or Ox.  Therefore, an ad hoc legislative committee,
working with the Wisconsin Departments of Transportation (WDOT) and Natural
Resources (WDNR), had drafted legislation (A.B. 500) requiring these agencies
to design, implement and conduct an I/M program in the required areas.  WDOT
and WDNR are currently planning for the required I/M program.  Once opera-
tional, the program will be generating a considerable amount of data.  In
addition to the obvious problem of handling and analyzing this data, any
system developed must enable data transfer to the existing computer system
now utilized by WDOT and WDNR.

     The objective of the effort undertaken in connection with this project,
was to define the data processing requirements and computer hardware speci-
fications for emission testing installations so that needed data can be
readily collected, stored, and transferred to WDOT and WDNR systems.  In
addition, required software systems and specifications were defined to enable
manipulation and analysis of data either on the selected I/M contractor's
central computer, the State's system, or by an independent data processing
subcont rac tor.

     The principal objective in defining any data processing plan is to
maximize the quantity and quality of necessary information, while minimizing
the cost.  With regard to Wisconsin's proposed I/M program, the ideal data
processing system will gather and store enough data to enable the State
to:

-------
     •    Administer the program

     •    Evaluate its effectiveness
     •    Monitor the performance of the contractor(s)

     •    Monitor the practices of the repair industry

     In fulfilling this objective, the State must,  of course, keep the cost
of the program as low as possible, but do so without sacrificing accuracy,
program effectiveness, consumer protection, etc.

     The specific data items collected and analyses performed must be defined
through a careful analysis of a series of trade-offs.  While a few states have
undertaken these analyses, giving Wisconsin the advantage of their experiences,
the ideal solution is quite state specific.  In other words, what may have
been deemed well worth a few additional cents per test  in one state, may
clearly be a waste of money in another state.  For example, portions of
California and Arizona have centralized, contractor-run I/M test lanes.  Both
are very much interested in identification of repair shops that are not
successfully repairing vehicles.  Unlike Arizona, California has state
licensing of repair shops.  California has determined that the importance of
monitoring repair shops is great enough to justify coding of repair informa-
tion directly onto the data file for all vehicles seeking reinspection
following failure of the initial test and receiving repairs.  Arizona, on
the other hand, requires the information be filled out on the back of the
initial inspection form but not entered into the computer.  Arizona then
periodically selects a small random sample of repair reports and codes and
analyzes them.  While the Arizona approach involves keypunching costs, the
California approach necessitates storage of twice as much information per
vehicle on computer tape  (about 250 bytes of information per test in Califor-
nia, only 120 bytes of information per test in Arizona).  Additionally, the
inspector who enters the data at the inspection lane in California must enter
more data, spend more time, and risk more errors than the Arizona counterpart.

     This report has attempted  to present the trade-offs Wisconsin faces in
defining the I/M program data processing plan and, when appropriate, provides
our recommendations.  It remains the state's responsibility, however, to deter-
mine what information It feels necessary to have and what price it is willing
to pay  for this Information.

     This report consists of six principal sections  including this introduc-
tion.   Section 2 presents a brief summary of the entire report.  A definition
of the  data processing requirements in terms of the  specific data items that
should  be collected,  the  statistical analyses that will be  required to ad-
minister the program, and the analyses necessary to monitor  the program
effectiveness are provided  in Section  3.  Also included in  Section  3, is a
discussion of the central computer  system now being  utilized by WDOT and
WUNR, and the data  input  requirements.  Data processing flow plans are
provided for data collection, storage, transfer, and analysis.  Section 4
discusses data processing hardware  requirements in terms of  equipment needed,
availability, cost,  and performance specifications.  An analysis of the data

-------
processing software requirements is provided in Section 5.  Section 6 pro-
vides a discussion of considerations regarding data processing procedures
in drafting the Request for Proposals (RFP).

-------
                                  SECTION 2

                                   SUMMARY
     The objective of the effort undertaken for this project was to define
the data processing procedures and equipment required for successful opera-
tion of Wisconsin's motor vehicle emissions inspection/maintenance program.

DATA PROCESSING REQUIREMENTS

     The principal objective of any data processing plan is to secure the
maximum quality and quantity of information while minimizing the cost.  The
ideal I/M data processing system will collect and store sufficient data to
enable the State to:

     •    Administer the program
     •    Evaluate its effectiveness
     •    Monitor the performance of the contractor(s)
     •    Monitor the effectiveness of the repair industry

     To define the data collection requirements it was first necessary to
identify the following analyses which must be performed by the State to
fulfill the above defined objectives:

     •    Data editing and correction
     •    Facility operation information (volume, failure rates, etc.)
     •    Emission standards evaluation
     •    Overall program evaluation
     •    Repair industry evaluation

Following definition of the analysis requirements, it was possible to deter-
mine the data input requirements.  Data in this category includes both
operator-entered and system-generated data.  The determining factors regard-
ing the necessity of a particular data element are listed as follows:

     •    Is the item necessary for conducting the inspection?

     •    Is the item necessary for the vehicle inspection report?

-------
     •    Is the item necessary for administrative recordkeeping?

     •    Is the item necessary for performance of the statistical
          analyses?

An analysis was made of the inspection scenario, report requirements, record-
keeping demands, and statistical analysis requirements.  The resulting data
elements are provided in Table 1.

     The data elements which will be necessary to include on the data tape
provided to WDOT by the contractor were defined.  This list is provided
in Table 2.

     An analysis of the Hill Farm's Regional Computer was undertaken to
determine the format requirements of the data tapes transferred to WDOT by the
contractor.  The Hill Farms system consists of an Amdahl 470 V/6 mainframe which
presents no problems in accepting tapes that most minicomputer systems are
capable of generating.  The tape requirements are outlined below.

     •    Parity — Odd, 9-track tapes

     •    Density - can easily handle 800 or 1600 BPI tapes

     •    Character Code — extended binary-coded decimal interchange
                           code (EBCDIC)

     9     Data  should be labeled as specified by  the Hill Farms
           Regional  Computing Center

     •    One inspection report per record

     •    Data  should be blocked (approximately 10 records per block)

HARDWARE REQUIREMENTS

     The general types of  computer hardware  required for the  I/M program
data processing include:

     •     Central  processor

     •     Magnetic  tape unit
     •     Communications interfaces  (modems)

     •     Remote processors
     •     Flexible diskette  storage

     •     Peripheral interfaces

-------
TABLE 1.  OPERATOR-ENTERED OR SYSTEM-GENERATED DATA FOR EACH INSPECTION FILE
Data item
Queue number
Test or retest (number)
License number
Inspection mode (auto, semiauto)
Vehicle indentif ication number
Model year
Vehicle make
Vehicle style
Vehicle classification3
Mileage
Emission standards
Emissions measurements
Pass /Fail /Waiver
Analyzer I.D.
Date, time
Serial number of report
Serial number of previous report
Station and lane number
Inspector number


Test modes performed
Inspection abort, reason
CO + C02 sum/std/decision
Special case code
Contractor management data


Source
S.G.
O.K.
O.E.
O.E.
O.E.
O.E.
O.E.
O.E.
O.E.
O.E.
S.G.
S.G.
S.G.
S.G.
S.G.
S.G.
O.E.
S.G.
S.G.
or
O.E.
O.E.
O.E.
S.G.
O.E.
S.G.
or
O.E.
Purpose
T
R.Q.I.A
R,E,I
R.T.Q.A
R,E,I,A
T,R,Q,I,A,E
R,E,Q,I,A
R,E,Q,I,A
T,R,Q,I,A
R,Q,I,A
T,R,Q,I,A,E
T,R,Q,I,A,E
T,R,E,Q,I,A
R,Q,I
R,E,I,A
R,E,Q,I
R,Q,I,A
R,Q,I,A
R,Q,I,A


T,R,Q,A
T,R,Q,A
T,R,Q,A
T.R,E,Q,I,A



Remains on State's
file
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes


Yes
Yes
Yes
Yes
No (unless
given to
public)
Key:   S.G. = System generated
       O.E. = Operator entered
          T - Test performance
          R = Recordkeeping
          E - Enforcement
          Q • Quality assurance
          I » Inspection report
          A - Statistical  analyses
alncludes number of cylinders and  weight  class.

-------
                       TABLE 2.  INSPECTION REPORT DATA PROVIDED TO THE STATE
Data item
Test or retest(s)
Inspection mode (manual, automatic,
semiautomatic
License number
Vehicle Identification Number (VIN)
Model Year
Vehicle make

Vehicle style
Vehicle classification
Mileage^
Emission standards:
high cruise CO
high cruise HC
low cruise CO
low cruise HC
idle CO
idle HC
Emissions measurements:
high cruise CO
high cruise HC
low cruise CO
low cruise HC
idle CO
idle HC


Size
(bytes)
2
1
6
13
2
5

4
1
3

4
4
4
4
4
4

4
4
4
4
4
4


Data item
Pass/Fail :
high cruise CO
high cruise HC
low cruise CO
low cruise HC
idle CO

idle HC

Analyzer i.d.
Date : day /month/year
Time: hour /minute
Serial number of report
Serial number of previous report
Station number
Lane number
Inspector number
Test modes performed
Inspection abort/reason
CO + C02 sum (measured)
CO + C02 sum (standard)
CO + C02 sum (valid/not valid)



Special case i.d. and code
Waiver yes/no
TOTAL
Size
(bytes)

1
1
1
1
1



3
6
4
7
7
2
1
3
1
2
2
2
1



2
1
135
 1  for  test  or  retest  identification, 1 for numbering  additional  retest(s)




 thousands only
'for  retest

-------
     •    CRT display/data entry terminals
     •    Teleprinters, report printers
     •    High-speed (line) printer

The general specifications of suitable equipment for each type of hardware
are outlined below.

Central and Facility Processors

     •    Minicomputer central processing units

     •    16-bit word length

     •    24-32 kilowords of memory (24 for facility processors, 32 for
          the central processor)

     •    Metallic oxide semiconductor (MOS) memory

     •    RS-232C interfacing with peripherals

     The facility Processors should be capable of performing the following:

     •    Control progress of vehicles through the test lane

     •    Process vehicle identification data

     •    Accept emission measurement data

     •    Correlate vehicle data and select failure standards

     •    Compare measured values to limits separately for each
          input

     •    Output test data for report printout

     •    Output test data onto bulk storage devices

     The Central Processor should be capable of performing the following:

     •    Communication with each facility  processor

     •    Data collection and data entry for inspection information

     •    Data validation and compilation for periodic submission  to
          the Department of Transportation

     •    Data analysis and summarization for network operation
          management

     •    Data management  reporting

-------
     •    Network software maintenance
     •    Preparation of magnetic tape file of inspection data for sub-
          mission to the Department of Transportation on a periodic basis
Communication Interfaces
     •    Normal voice grade telephone line communication modems
     •    RS-232C interfaces
     •    Asynchronous, full-duplex (bidirectional) communication
     •    1200 baud
     •    Automatic "dial-up" from headquarters computer
     •    Automatic answer at facility computers
Mass Data Storage Devices
     •    Flexible magnetic disk (diskette or floppy disk)
     •    250,000 byte storage
     •    RS-232C interface
Magnetic Tape Unit
     •    9-track, ^-inch industry standard tapes
     •    800 or 1600 bpi
     •    EBCDIC character code
CRT Display/Data Entry Terminals
     •    Cathode Ray Tube (CRT) display
     •    Standard keyboard
     •    Full-duplex communication
     •    ASCII character code
     •    RS-232C interface
     •    12-inch (diagonal)  screen
     •    64 displayable characters,  at least 0.19 inch high by
          0.125 inch wide
     •    5x7 dot matrix characters
     •    80 characters per line

-------
     •    12 lines displayable on full screen

     •    Nondestructive cursor

     •    Fields protection

     •    Tab to unprotected field

Teleprinters and Report Printers

     •    Inspection report printer should use 8*5- by 11-inch report
          size forms (one original and two copies)

     •    ASCII transmission code

     •    RS-232C interface

     •    80 characters per line

     •    30 characters per second (300 baud)

     •    64 character set, (0.19 by 0.11 inch)

     •    7x7 dot matrix characters

High-Speed Printer

     •    ~300 lines per minute

     •    132 columns per line

     •    RS-232C interface

Exhaust Measurement Subsystems (EMS)

     The EMS should be capable of controlling either automatically  (in
conjunction with the System Controller) or manually all emissions measure-
ment and test control functions.  The EMS should contain its own control
processor, the EMSCP, which should meet the following specifications:

     •    8-bit microprocessor

     •    Interfaced with, but functionally independent of the System
          Controller

     •    Capable of outputting results through the Inspection Report
          Printer during System Controller downtime.

The EMS should also contain a Control Pendant, which consists of a  small
keyboard device enabling the inspector to start, stop, and control  the test
process.  A Test Display Panel is used in conjunction with the Control Pendant
to prompt the inspector with instructions and display test information such as
road speed, operation mode, etc.

                                     10

-------
Equipment Costs

     Estimates were obtained for suitable equipment meeting the above speci-
fications, these estimates are outlined below:

     Facility System Controllers           $ 7,000 -  9,000 each
       -  communications interface         $ 6,000 -  7,000
     Headquarters Control Processor        $13,000 -  up
       -  communications interface         $ 6,000 -  7,000
     Modems                                $   800 -  1,000 each
     Flexible disk units                   $ 3,500 -  4,500 each
     Magnetic tape unit                    $ 8,000 - 18,000
     CRT Terminals                         $ 1,500 -  2,000 each
     EMS's                                 Contractor fabricated
     Teleprinters and inspection report
       printers                            $   900 -  1,600 each
     Line printer                          $ 6,000 -  up
     Graphics CRT                          $ 3,500 -  7,500

SOFTWARE REQUIREMENTS

     The software requirements were divided into three major categories:

     •    SYSTEM software

     •    Data transfer software

     •    Analysis software

SYSTEM Software

     SYSTEM software consists of all programs necessary to enable the SYSTEM
(all hardware and software used in the inspection process) to fulfill the
following functions:

     •    Prompt for, accept, and verify vehicle identification data
          from the Vehicle Identification Terminals  (VIT)

     •    Coordinate the emissions inspection through the EMS

     •    Correlate vehicle emissions data, select appropriate standards
          and dynamometer loadings, make pass/fail determinations

     •    Output test data for report printout and to bulk storage

     •    Perform and keep records of emissions analyzer calibration
          checks as well as all other SYSTEM maintenance data

Related  to the SYSTEM software is the EMS software, which consists of pro-
grams necessary to enable the EMS to perform the following:
                                     11

-------
     •    Prompt and cue the inspector during the inspection

     •    Convert raw analog measurements into digital format

     •    Perform all necessary calculations

     •    Monitor and correct dynamometer loadings,  instrument
          drift, etc.

     •    Collect and analyze emissions, make pass/fail determinations

     •    Display appropriate information during the inspection (road
          speed, horsepower load, mode of test, test complete, warning
          messages, etc)

The SYSTEM and EMS software should consists of real-time application programs
written in an Assembly or Macro-level language.  Assembly is the preferred
language for real-time applications as it can be much more efficient than
higher level languages such as FORTRAN or PL/I.

Data Transfer Software

     Software in this category consist of all programs necessary to enable
transfer of data from facility computers to the central computer system.
This software controls the modems and telecommunication links and like the
SYSTEM and EMS software, should be programmed in an Assembly-level language.

Data Analysis Software

     Two subcategories of software exist under this heading, that developed
by the contractor  (recordkeeping, reporting, etc) and that used by the
State (program evaluation, cutpoint selection, etc).  These "batch-processing"
programs can be written in higher level languages such as FORTRAN or PL/I.

General Software Requirements

     All software  should be developed under the general programming approach
known as "Structured Programming."  Structured programming involves breaking
the program "problem" into smaller, more manageable components.  This involves
a technique known  as modularization which essentially means the program will
consist of a number of independent modules  (or subroutines).  A program
developed under this technique will achieve four basic goals  (listed in
order of importance):

     •    Reliability — Does the program consistantly give dependable
          results  that are accurate?

     •    Modiflability - Can the program be modified easily to
          respond  to changing standards, requirements or devices?
                                     12

-------
     •    Understandabllity — Since the State will likely reserve the
          option to purchase the SYSTEM, including all software, will
          the State programmers be able to understand the program
          logic well enough to use, update, and modify it?

     •    Efficiency — Does the program operate as efficiently and
          Inexpensively as possible?

Software Documentation

     Although there is some overlap between them, four general types of
documentation were defined:

     •    Design documentation

     •    Construction documentation

     •    User documentation
     •    Maintenance documentation

     Design documentation is a "blueprint" for developing the data processing
system.  This would constitute the overall plan for designing and implementing
the software and should be a proposal requirement.  Construction documentation
includes precise formats, data layouts, algorithms, program names, etc. and
should be developed concurrently with the software.  This type of documen-
tation should be a contractor requirement for the regular progress meetings
with the State during software development.  User documentation includes
user's manuals and operator's guides concerning all functions of the system
and how to use them.  Maintenance documentation consists of complete descrip-
tions of the system in its final format including information on the limita-
tions of the system, procedures to be followed in updating or modifying the
system, and complete listings of all program statements for all developed
software.

State Developed Software

     The State will be required to develop software enabling performance of
the program analyses described previously.  There are three options open
to the State in fulfilling this requirement:

     •    Develop specific software "in-house"

     •    U.se preexisting software packages

     •    Obtain the services of a software firm to develop software
          and/or conduct the analyses.

     The preferred solution would be in-house development of software,
provided that the State programming staff has sufficient time and expertise.
Some existing software packages may be  suitable for the statistical appli-
cations required.  If an analysis is to be performed on a one or two time
                                    13

-------
basis, use of preexisting packages is encouraged.   If a particular set of
analyses will be performed periodically, however,  application-specific
programs should be developed as they can be made more efficient and therefore,
cheaper to run.  This is because most software packages are designed to handle
a number of different situations, whereas a program developed for a specific
application can eliminate a lot of unnecessary capability.

     Another alternative would be to hire a "software house" to develop the
application-specific programs needed.  If the State's in-house staff lacks
the time and/or expertise to develop the required  software, contracting the
work out is the most logical alternative.

SOFTWARE DEVELOPMENT COSTS

     Software development costs were estimated based on discussions with
software houses, experiences of other states, and  an analysis by the GCA
data processing staff.  Based on these sources the following estimates were
developed:
                                Man-hours
                       Man-hours
    Contractor's software
    Contractor's documentation
State's software
State's documentation
A standard $30 per hour figure was used to translate hours into a dollar cost,
equalling $135,000 for the contractor and $36,000 for the state.

RFP CONSIDERATIONS

     The quality of proposals submitted is somewhat directly proportional
to the quality of RFP issued by the State.  It is important that the RFP
be free from ambiguities and outlined in very specific terms the functional
requirements of the program.  There is a risk, on the other hand, of
developing an RFP that is too specific.  While the bidders must be made
well aware of what must be accomplished, the RFP should be left somewhat
open concerning how it is accomplished.  By being overly specific, the
bidders could be prohibited, or at least discouraged, from proposing what
could be a higher quality or more cost effective system than that specified
within the RFP.  A model data processing portion of an I/M RFP is provided
in Section 6.
                                     14

-------
                                    SECTION  3

                         DATA PROCESSING REQUIREMENTS


     Ae discussed  in Section 1,  the  primary objective of any data gathering
and processing system  is to maximize  the quality and quantity of information
obtained, while minimizing the cost.   In order  to meet  this objective  in  de-
fining the data processing requirements for Wisconsin's proposed I/M program,
it is important that all essential  data is  collected and retained, but no
duplication of data exists.  For example, the State may, at some point want to
determine if temperature variation  within the test lane is affecting test
results.  It would then be necessary  to keep a  record of the lane temperature.
Only one log of temperatures need be  kept for each facility, however.  Recording
temperature on each inspection record  would be  an unnecessary duplication of
effort.

     In order to define the specific  data elements that should be collected
and stored, it is  first necessary to  determine  how this data is to be utilized.
The data generated, gathered, and stored from the I/M program will be used for
two primary purposes;  first, to perform analyses to administer the program,
and second, to evaluate the program's  effectiveness and the performances  of
the I/M contractor, subcontractors, and the repair industry.  Related to  identi-
fication of these required data elements is the issue of the division of  analysis
responsibilities between the contractorCs) and  the state.

ANALYSIS REQUIREMENTS

     There are a number of analyses that should be performed periodically to
properly administer and evaluate the program.   Some of these analyses can be
regularly provided by  the I/M contractor,  some are more appropriate for the
State to undertake, some may be best handled by an outside data processing con-
tractor.   The important administrative and evaluative analyses are defined
below,  along with rationale for conducting them and our recommendations con-
cerning where the responsibility for each should lie.  The software require-
ments for these analyses are discussed in greater detail in Section 5.

Data Editing

     One  of the most important sets of analyses involves verification and
correction,  if necessary,  of all collected data.  The importance of edit  checks
cannot  be overemphasized as all decisions  and actions based on other analyses
arr dependent on the accuracy of the data  used.  Without reasonably accurate
data,  all other program analyses become meaningless.    Discussions with individ-
uals currently involved in I/M data processing indicated that most data errors


                                      15

-------
occur during the initial entry at the inspection facility.   This seems logical
since the inspector who enters the data at the "rapid throughput" inspection
lane is performing under strict time constraints as the cost effectiveness of
centralized programs is quite time dependent.

     In a previous analysis,1 it was determined that even a 1-minute increase
in throughput time would result in a 29 percent increase in the "breakeven"
fee charged to the motorist.   While some quality assurance procedures should
be performed during data entry, the time dependence of the centralized approach
to 1/M will limit the extent  of edit checking  at the data entry point itself.
As a result, additional data  processing of computerized edit checks will be
required.  There are two principal edit procedures that should be included in
the editing sequence:  identification of errors and their correction, each
of which is described below.

Identification of "Bad" Records—
     The first step toward correction of errors is, quite logically, their
identification.  Data collected from the I/M program will exist in two formats,
numeric and alphanumeric.  The procedure used  in the identification of errors
will, of course, be dependent on the data format.   Data in numeric format can
be compared against reasonable upper and lower limits to detect possible errors.
Pollutant concentrations exceeding the maximum measurement range of the emis-
sion analyzer, for example, may be assumed incorrect.  Similarly, a numeric
entry can also be verified by other means dependent on the specific variable
in question.  The number of cylinders in an engine is, in most instances, an
even number.  Odd numbers for this parameter,  though not errors in all instances,
can be identified and their validity checked individually.

     Alphanumeric fields must be validated by  comparing the field against an
array of possible "correct" entries.  The manufacturer, for example, can be
checked against a list of all manufacturers.  This will uncover misspelling
or improper entries, for example, FOOD for FORD or OMNI instead of DODGE.

Error Correction—
     After identification of  an error, a decision as to what action to take
must be made.  In some instances, the error will be such that the intended
entry will be obvious, the misspelling for FORD, for example, or the entry of
a model name common to only one manufacturer in place of the manufacturer code.
In other instances different  data within the same record can be used; say, for
instance, the manufacturer code was not identifiable but the VIN was properly
entered and recognizable.  In yet other instances, the error will be such
that the correct entry cannot be determined.  These records should simply be
excluded from analyses dependent on that particular field.

     The responsibilities for error correction should be divided as follows.
The contractor should be responsible for providing limit checks and checks for
missing data, etc. , at the time of the inspection.  The state should retain
responsibility for data verification (i.e., matching VIN to registration
numbers, etc.)
                                      16

-------
Facility Operation Information

     Analyses in this category include basic administrative recordkeeping tasks
concerning the actual operation of the inspection facilities.  The State will
want to keep track of statistics on the number of vehicles handled, how many
passed/failed, etc.  These analyses are described in detail below.

Volume Information—
     Analyses should be made periodically on the inspection volumes at each
facility.  Additionally, the volumes should be broken down by day of the week/
month and the time of day.  Information gained from these analyses will be
helpful in assessing the operating hours of each individual facility for
seasonal adjustment and in determining the effectiveness of the public infor-
mation program's advertising of hours.  If one facility is handling considerably
more vehicles per month than a nearby facility, perhaps the location of the
less-utilized facility should be advertised more.  If registrations are staggered
on a monthly basis, the end of each month will likely be bringing greater demand
for inspection.  Analyses regarding inspection demand as a function of day of
the month can be utilized to determine both the extent of the problem as well
as the effectiveness of the solutions (public information, etc.).  The inspec-
tions should also be categorized as initial inspections, reinspections, second
or subsequent reinspections, special tests, idle-mode-only tests, and refused
inspections for safety reasons or no registration.

Failure Rates—
    ,The inspection results should be categorized and summed.  Statistics such
as failure rates should be broken down by facility and lane and be analyzed
periodically for consistency, or to determine seasonal effects.  Failure rates
should also be broken down by pollutant, vehicle type, make, model, engine
configuration, year of manufacture, etc. to determine possible inspection re-
quirement biases for or against a particular type of vehicle and to determine
if the selected cutpoints are appropriate.

     The same analyses of the distribution and nature of failures should be
performed for reinspections as well to evaluate the success of the repair
industry and effectiveness of the diagnostic information provided.  Before and
after reinspection, pollutant concentrations should be compared to detect
whether or not motorists are seeking repairs at all.  Analyses should also be
made regarding how many vehicles would have failed the cruise portions of the
inspection, particularly for retests.  This will give an indication as to
whether the repair shops are fixing vehicles completely or just readjusting
them to pass the idle test.

     Many of the analyses in this category can be performed by the I/M contrac-
tor, who should be required to submit monthly (or biweekly) reports on facility
operations.  The contractor's report should be limited to the following volume
information.
                                     17

-------
     •    Total number of inspections

          —    How many were initial inspections?

          —    How many were reinspections?

     •    Pass/Fail rates
          —    For initial inspections

          —    For reinspections

     •    Number of inspections refused

          —    Safety reasons
          —    No registration

          —    Other reasons

     •    Number of exemptions and waivers issued

     •    Equipment calibration information

The report should, of course, be backed up with data tapes  containing all of
the test records to verify the report information,  and to enable the State to
perform the remaining analyses discussed under this category.

Outpoint Evaluation

     Theoretically, the existence of an I/M  program will gradually improve the
condition of the inspectable fleet.  Since failure  rates are set to fulfill
a number of criteria beyond emission reduction considerations  (public accept-
ance, etc.), the emission level outpoints can periodically  (usually on an
annual basis) be adjusted to gain further emissions reductions  while maintain-
ing approximately the same failure rate.  The procedure to  accomplish this
adjustment is relatively straightforward. Raw test scores  from initial in-
spections are rank ordered from the greatest concentration  to  the lowest and
the cutpoint is defined as the percentile value equivalent  to  the desired
failure rate.  This analysis must be performed for  both CO  and  HC concentra-
tions for as many vehicle classes as there are standards.  According to the
current draft emissions inspection rules, this would entail at  least 9 classi-
fications based on model year, number of cylinders, and vehicle type.  Addi-
tionally, the process would have to be repeated for high cruise (approximately
50 mph), low cruise (approximately 30 mph),  and idle standards.

     After derivation of the cutpoints, the  rank ordering used  in their calcu-
lation should be broken out by manufacturer  and model to verify that the
standards are not biased for or against any  specific vehicle make or model.

     The responsibility for these analyses should  be assumed by the State,
although assistance could be obtained from the I/M contractor.
                                    18

-------
 Program Evaluation

     WDOT and WDNR will likely be asked to periodically report to the  State
 Legislature on the status and effectiveness of the program.  WDOT will prob-
 ably be requested to report on the status of the contractor's operations and
 the emission reduction effectiveness of the I/M program which is the differ-
 ence, over time, of the average tailpipe pollutant concentrations for  each
 inspection class.

     Additionally, this data can be integrated with air quality data collected
 by WDNR, to determine if the program is actually meeting its objectives.

     Program evaluation should clearly be the State's responsibility, however,
 assistance can be sought from the I/M contractor.

 Repair Industry Evaluation

     A number of analyses regarding the repair industry will be useful as a
 measure of the effectiveness of mechanic's training programs as well as for
 consumer protection purposes.  The State will certainly want to keep track of
 how much money motorists are spending on repairs.  Repair information  from
 motorists applying for retests should be evaluated, and average and median
 ropair costs calculated.  Statistics such as how many repair cost waivers were
 issued can be used to assess the appropriateness of the repair cost ceiling.

     The market distribution of repair work should also be evaluated to deter-
 mine where repairs are being performed (garages, dealers, tune-up specialists,
 etc.).  This information is helpful in determining where and to whom mechanics
 training should be focused.  Similarly, reinspection failures should be examined
 to identify what shops are doing poor repair work; "bad" shops can then be
 encouraged to participate in training classes.   Repair information can be
 compared to inspection results to determine the appropriateness of the repair
 work performed.  Analyses such as these will also enable identification of
 unscrupulous mechanics who perform inappropriate or excessive repairs.   The
 repairs performed can also be compared to repair costs to identify shops that
 are overcharging.

     Emission reductions from test to retest can be analyzed to determine the
 effectiveness of the repairs.  This information can also be compared between
 shops that have had mechanics attend training programs and shops that have
 not, to evaluate the training programs.  This data, along with reinspection
 success rates, can be used to encourage more mechanics to seek training.

     Repair industry evaluations should be the State's responsibility,  although
 these analyses could be contracted out to an independent data processing firm.

     Currently, the draft inspection rules mandate that the inspection  report
provide space for the following:

     •    Itemization of the repairs performed

     •    Cost of repairs (or cost estimate of  repairs required
          if such repairs will exceed the maximum specified re-
          pair cost)
                                     19

-------
     •    Name and address of the business firm (or person)
          making the repairs

     •    Signature of person certifying repairs

In addition, to be considered for a waiver due to excessive  repair cost,  the
following information must also be recorded:

     •    Idle emissions concentration of HC  and CO upon completion
          of repair if an NDIR analyzer is used

     •    Serial number or identification number of emission analyzer
          if used by the individual in measuring the emission concentrations
          concentrations

     •    For vehicles greater than 10 years  old, or requiring
          repairs that will exceed the maximum repair costs, evidence
          of receiving a "low emission tuneup," as defined in the
          proposed rules, will be a waiver prerequisite.

     One question that arises here is whether this data should be routinely
entered into a computer file when the vehicle arrives for reinspection, or will
it be sufficient to simply keep the inspection form and periodically select a
random sample, code the information, and then analyze the data?  Two states'
approaches to this problem were briefly discussed in Section 1.  California
codes this information upon reinspection at the test facility; Arizona uses
the random sample approach.  The justification for coding all of the repair
information in California, and thus, greatly  increasing the  size of each in-
spection report file, is that unlike Arizona, California has formal licensing
of repair shops.  This information would be very helpful in  determining which
mechanics are unsuccessful at correcting problems, and which shops are reporting
emission levels quite different than those measured at the inspection facility.
This extra information, of course, comes at an extra cost.  The repair infor-
mation described above will affect data processing costs in  four areas:

     1.   Data storage costs
     2.   Data processing costs
     3.   Data transmission costs
     4.   Data entry time.

     By coding all repair information at the  inspection facility each inspection
data file will nearly double in size.  As a result, the cost of storing data will
increase since more tape space will be required.  Processing the data will be
more costly as the larger record size will occupy more disk  and memory space
during analysis.  The data transmission time  (time required  to transfer data
from each inspection facility to the contractor's central computer) will also
increase.  The additional cost to the consumer will not be significant as a
result of the increases in these three areas.  Increases in  the fourth area,
however, will be significantly more costly.  As previously mentioned, the time
requirements of each task in a centralized I/M facility are  very crucial.  A


                                     20

-------
1-minute increase in throughput time would result in an approximate fee in-
crease of 29 percent.  The exact throughput time increase will depend on the
failure rate, thus, the number of times the inspector will be required to enter
repair information.  A 1-minute increase would not be unreasonable to expect.
An alternative approach would be to add another inspector to each test lane.
The additional inspector could drive the vehicle to the second position while
the first inspector begins entering information on tthe next vehicle.  One
additional inspector per test lane would add at least another 10 percent to
the inspection fee.*  Unlike California, Wisconsin does not have formal li-
censing of mechanics and repair establishments.  Further, the Wisconsin I/M
Task Force has indicated that it is reluctant to endorse further State regu-
lation of the repair industry; therefore, a repair shop certification program
is currently not being considered.2  As a result, the random sample approach
used in Arizona may be adequate for Wisconsin.  It should be noted that the
Arizona approach has been effective at identifying poor repair industry
practices.

Other Analyses

     It is reasonable to assume that the State will wish to perform additional
analyses when situations arise.  For example, routine analyses of repair and
retest data may  indicate that some motorists have not sought repairs at all.
An analysis of the time span between initial test and retest can easily be
undertaken to determine the frequency of motorists trying to "beat the system."
Periodically, the State may wish to take advantage of the "captive audience"
provided by mandatory inspections for surveys or questionnaires.  Simple re-
sponse questions can be coded on the form to relate opinions about the program
to the success of the motorist in passing inspection, age of the vehicle, etc.
To allow  for these extra analyses, without subsequent software modification,
input records should contain some reserved space to accommodate additional data,
should it become necessary.  This is discussed in greater detail in the fol-
lowing subsection on Input Requirements.

INPUT REQUIREMENTS

     Data items  included in this category consist of both inspector-entered
items and system-generated items.  In order to minimize the inspection time,
as much data as  possible should be system generated.  This includes both items
that are  totally independent of the inspection process (date, time, lane
number, etc.) and  items derived from inspector-entered data (cutpoints based
on vehicle model year and class).  Certain input or generated data items are
necessary only during the inspection process and should not be permanently
transferred  to computer tape; for example, a queuing number may be assigned
to each vehicle  to identify it during the inspection process.  This is an
important variable since in a six-lane facility as many as 18 vehicles may
be undergoing inspection at the same time.  After completion of the test,
however,  the queuing number is of little  importance and should be deleted from
the permanent inspection report file.
 it
 Based on cost assumptions utilized  in reference 2,
                                     21

-------
     The determining factors regarding the necessity of a particular data input
item are listed below:

     •    Is the item necessary for conducting the
          inspection?

     •    Is the item necessary for the vehicle inspection
          report?

     •    Is the item necessary for administrative recordkeeping?

     •    Is the item necessary for performance of the statistical
          analyses?

In addition to State-required items, the contractor may desire certain infor-
mation for management purposes.  For example, the time differential between
logon and logoff for each test by lane would be useful to check the efficiency
of certain inspector "teams" to see what combinations are most effective.  This
data is probably of little importance to the State, so, it should not be in-
cluded in the final tape file of each inspection report.  The tape that is
finally turned over to the State, then, will be a subset of all information
collected.  The contractor should be free to collect as much management infor-
mation as necessary and turn over to the State only the information the State
wants.  However, any information that is provided to the public should be
supplied to the State as well.  These issues are discussed in greater detail
in Section 5, RFP Considerations.

Emission Inspection Scenario

     Since data entry, generation and alteration can occur at several points
during the inspection process, a brief review of the actual inspection scenario
is presented here for reference.  As shown in Figure 1, a loaded-mode emissions
testing lane consists of three positions.  Each of the three positions has
essentially one principal function:  data entry, emissions testing, results
reporting, respectively.

Position 1—
     Most of the data entry occurs at the first position.  Upon arrival at the
facility, the vehicle owner presents registration information to an inspector
who enters the appropriate data items into the computer.  The computer creates
a unique file for this vehicle and, based on the entered data determines whether
the vehicle should be subjected to all three testing modes (high cruise, low
cruise, and idle) or  if elimination of one or more of these tests is appropriate.
The computer then determines what standards the vehicle must meet, selects the
proper dynamometer loadings to apply, and signals the inspector to move the
vehicle to position 2.
                                     22

-------
                                                                 SYSTEM
                                                               COMPUTER
NJ
U>
                             CRT
                        POSITION 1

                       • Data entry

                       > Visual  inspection
                                                                  ANALYZER
                                                              '  jDYNAMOMETER
                                                                                                  CRT/PRINTER
 POSITION 2

• Loaded mod* emission
 
-------
Position 2—
     The actual emission inspection occurs at this position.   If the vehicle
is subject to the high cruise test, the computer instructs the operator to
increase the driving speed to approximately 50 mph* (on the dynamometer).   When
the vehicle has reached a stable speed within a specified tolerance, the analyzer
will be instructed by the computer to begin sampling.   For quality assurance
purposes,  several samples are taken, the number of which is predetermined.
After collection and measurement of the samples, an average is calculated  and
the result stored.  The computer then instructs the inspector to change speed
to approximately 30 mph and the process is repeated.  After completion of  the
low cruise test the vehicle is tested at idle.  When the three tests have  been
completed, the computer determines whether the vehicle has passed or failed
each portion for both CO and HC.  The computer then informs the inspector  that
the test is complete and to move the vehicle to position 3.

Position 3—
     At the third position, the vehicle inspection report is  printed out.   The
computer,  at this time, finalizes the inspection file  and stores it on disk.
The final report file is "protected," prohibiting any  alteration to its contents.

     A generalized data flow plan for the inspection process  is provided in
Figure 2.

Data Items

     To determine the data input requirements, an examination must be made into
the specific demands for each of the categories listed previously; conducting
the inspection, the inspection report, recordkeeping,  and analysis requirements.
Since considerable overlap will exist among these categories, the first classi-
fication presented here will be the vehicle inspection report, which includes
the most items.
                                                                           /
Vehicle Inspection Report

     In the draft of proposed rules for the inspection process, specifications
for the vehicle inspection report information are provided.  These requirements
are summarized in Table 3.  Items A through G in Table 3 are inspector-entered
data, items H through N can be generated by the computer system, item 0,
inspector number, can either be entered or generated depending on how frequently
inspectors change positions.

     The vehicle inspection report is generated by the computer and printed at
the third position of the inspection lane, where an inspector can briefly  ex-
plain the results to the vehicle owner.  An example of a typical report, from
Arizona, is provided in Figures 3 and 4.  This report  form will differ somewhat
*
 The actual speed and horsepower loading will vary depending on the vehicle
 classification (weight and number of cylinders), as determined by the com-
 puter.  For simplification the high cruise will be referred to as 50 mph,
 the low cruise as 30 mph.                          N

                                     24

-------
           VEHICLE REGISTRATION DATA ENTRY SUBSYSTEM
                       C
START
          OPERATOR INITIATES  'LOGON1 PROCEDURE FOR
          VEHICLE.  SYSTEM GENERATES:  (l) DATE (2)  TIME
          (3)  LANE NO.  (
-------
 ALL REGISTRATION DATA ENTERED J
>
SYSTEM
ANY Fl
PRI
ELDS
f
NTS MESSAGE
ARE TO BE
ASKING
CHANGED
IF
              ANY
         FIELDS TO BE
           CHANGED?
                 YES
OPERATOR ENTERS FIELD CODE NUMBER
                                      PRINT
                                   INFORMATIVE
                                     MESSAGE
                 YES
SYSTEM REQUESTS ENTRY INTO FIELD.
EDIT CHECKS FIELD FOR VALID DATA
AS ABOVE.   LOOP PROTECTION
INCLUDED.
     Figure  2  (continued)
                                              468-2
              26

-------
ENTER RESULTS OF VISUAL SAFETY IN-
SPECTION (PASSED, FAILED)
        ENTER FAILURE CODE(S)
       STORE REGISTRATION DATA
               LOGOFF
SYSTEM DETERMINES EMISSION
STANDARDS FOR VEHICLE
(DETERMINED BY YEAR,  NO.
OF CYLINDERS, WEIGHT CLASS)
                                                     LOGOFF
                                                               46B-3
                        Figure  2  (continued)
                                 27

-------
               EMISSIONS MEASUREMENT SUBSYSTEM
                           OPERATOR
                     ENTERS TEST TYPE FOR
                            VEHICLE
                                              WEIGHT <  2000 LB

                                                C
FULL TEST
(DEFAULT)
                         50 MPH ± TOL
                           ATTAINED?
  PURGE
SAMPLING
  LINES
                    COLLECT EXHAUST SAMPLE
                         50 MPH ± TOL
                         TILL ATTAINED?
                           SAMPLING
                       PERIOD COMPLETE?
                     DETERMINE IF VEHICLE
                        PASSES OR FAILS
                    STORE 50 MPH TEST DATA
                                                             468-4
                     Figure  2  (continued)
                               28

-------
                        30 MPH ± TOL
                          ATTAINED?
  PURGE
SAMPLING
  LINES
         NO
COLLECT EXHAUST SAMPLE
    30 MPH ± TOL
   STILL ATTAINED?
                          SAMPLING
                      PERIOD COMPLETE?
                   STORE 30 MPH TEST DATA
                            NO
                    DETERMINE  IF VEHICLE
                       PASSES  OR FAILS
                                                            468-5
                     Figure  2  (continued)
                              29

-------
                      ZERO MPH ATTAINED?
  PURGE
SAMPLING
  LINES
           NO
COLLECT EXHAUST SAMPLE
       ZERO MPH
    STILL ATTAINED?
                           SAMPLING
                      PERIOD COMPLETE?
                    DETERMINE IF VEHICLE
                    EMISSIONS IN COMPLIANCE
                    PURGE  SAMPLING  LINES
                                                            468-6
                     Figure 2 (continued)
                             30

-------
    TEST  REPORT SUBSYSTEM
PRINT VEHICLE TEST REPORT,
INDICATING COMPLIANCE STATUS
WRITE VEHICLE TEST RECORD
TO BULK STORAGE
      c
STOP
   Figure 2 (continued)
                                          468-7
            31

-------
          VEHICLE  INSPECTION REPORT
                                 STATE OF ARIZONA               0000000
                  OFFICIAL VEHICULAR INSPECTION STATION
             CERTIFICATE BELOW  NEEDED FOR REGISTRATION
                (CANNOT  BE  REPLACED IF  LOST OR STOLEN)
        Your vehicle's test results are shown below. If your vehicle uses gasoline fuel, the exhaust
        omissions wew tested for hydrocarbons (HC) and carbon monoxide (CO); pass or fail in the
        "Final Result" .space is based on results of the idle portion of the test. If it uses diesel fuel, it
        was tostod for smoke omissions If the "Final Result" space shows your vehicle failed, you
        are entitled to one frtm rotest after repairs or adjustments have been made. To get  tho free
        retost. you must return within 60 days with this report*, signed on the reverse side, signifying
        that emission-related repairs or adjustments have been made.
        'NOTICE: The fro* reteat period does not change your registration deadline. An $8 late
        registration fee Is charged II registration Is processed otter deadline.
                          For registration Instructions, see below.
                   STATION NO.
                                     TUT MODE
                                               TEST NO.
                                                         OAT1
                                    VEHICLE INFORMATION
                              LOADED TEST EMISSION RESULTS

                                  HIGH CRUISE             LOW CflUISf
                     '. r A ii
                    'it ANllAHO
                     PASS/FAIL EMISSION RESULTS

                               101 f          DIESEL SMOKE

                        IN HTMi
                                                              f FINAL HL.SULT  N
               81*16
              !; I AMDAHL)

               list
              MlAlmil,
            ron OFFICIAL USE ONIY
       ARIZONA VEHICULAR EMISSION INSPECTION CERTIFICATE



             "PIATC  '    "     VIN     	  ~Yi AH"  ~ MAM


       Tho abovi* vohlclo was mnmion in'tpni tod at st;ilion
       on                 mid

       ftlondardn us ttsttthlKhed by rngul.iiiijn
                                          tin- emission
       Thlfi cortlfu alo 'miy only be mod fur icqiilr.ition purpot-os whrn

       nlthnr  thn  word  Cf)MPI lANf.f  or
       WAIVf H Ii pilnliKl in lino him k  	
                                    I
       tf thti woid TFrST nppenrs, soo InspfM.tion repotl supplwrnont

       THIS CERTIHCATlf CANNOT UE REPLACED IF LOST OR

       81 OlEN AND IS VOID WHEN ALTERED.     0000000
 ,IF Hit- WORD COMPLIANCE OH WAIVcH
 JAPFcARS IN 1HF BI(IF_OIO(,K ON  THF.

iCERTIFICATE.  T'EA'R" AfoNC  THE
 PERFORATED LINES AND TAKE IT OH MAIL
 JIT WITH YOUR REGISTRATION CARD TO

 THE COUNTY ASSESSOR KEEP TOP PART

 [CONTAINING THE TEST RESULTS UNTIL

 SYOU RECEIVE I ICtNSE TAGS
I^IF  THC WORD TEST  APPLARS. THb
 VEHICLE DESCRIBED HAS F All ED THE
lilNSPFCTION AND  Mllof FJtr  HFPAIHED
IACCORDING TO iNGTHucnoMS IN THE
((.INSPECTION HEI'CIRI SUPPLEMENT
Figure  3.   State  of  Arizona  vehicle inspection report,  obverse  side,
                                          32

-------
                                  DIAGNOSTIC INFORMATION
    [HAL:   t A RVimiC^BO OH DIRTY Atfl C I FANf II Wtl.1 CAUflE HK1H CO
          9 MALFUNCTIONING CHOKt Wll 1 ( AUIlt HIGH CO
          J OltCONNiCTfO OH INOf'tHATIvr EMISSIONS CONTROl  DFVirfcH MAY CAUSt HIGH CO AN[J/OH
           IN LATI MOOIL CAR'I
                                                                                        tldllHC PAIIIIC IRAni
                                              1 'H VflABlfc tfty V13 VJ»
                                              iMPHOPffi CAHBimr T OH IDl F !
                                                                                          ADJUblMFNI
                                             I ARDIIMf lOFt MAIN SYI.TFM MALFUNCTION
                                             A I.OMHINATION OF MAI MJN( I IONINO CARBURETOR MAIN SYSTFM AND A MAI ADJUSTFO
                                              I'HUBABI 1 CAU'il '. AMfc
CO - CAB tO N MONOXIOI
         If EM I Bll UN niAUINQ 13
t  MKIHAf itURONTV.OR
t  HKWAitpi.rANBi.WWV!
i  HlON AT IQWCMUISIONLY OH
'J  HtOH AT MIOH CM lift*. ONI Y, OM
9, Mtqn AT LOW AND HIOH cnuiBf
1  HtriH AT KX« AND HIGH CRUOf DM
*  HM.H AT tOtt. ^QW ANp_HlpM CnuiSl
HC - HVMOCAMON
         I* IMISSION nCAOlNO It}
1  MIOH AT iDtToBlTTm" "
a  HIOH AT IDtt AND LOW'.HUKil            ^  I X(,( SHIVt i Y HIUH CO AT IIJl I  CAN (,Al>J>l_ MODf HA1 Ft Y HIGH MC AI IIJI t
                                   1  IN1FFIMITTI NT KiNII KIN MlSI IHI I'l POSSIBLE BU 1 NOT PHnOAUM

                                     AOJUSII It IMPHOPlHl V
                                   f-  UflOSjStY ADVANCFf) HASIC IUNM ION riMINO
                                   n  VACUUM i FAKS INIO inf  INTAKE MANIFOLD CAUSING A LI AN MIX Mint AND SUB
                                     SI (JUENT Mr^tFlIlt IN '.OMF Cv) INOEM'J
                                   /  CQyfltS'i'VN LljAK IMHyU«iH ONE OH MI l£ VAl VFS
  MIOH AT LOW CHUIfle ONI V OR            IGNITION MISRflt I'Nni H HIQHl M COMF'IIESSION PREH-SUHr OF puwfri off HA I ION OUE
  MtOH AT HIGH CWUISr ONI Y OH            TO A FAILUME OF AN KINItlON SYSTFM COMPONhNI
  HtdH AT I OW AND HIOH CflUtSC (Jfl
  HIQH AT IDLI AND HIOH CnillBL OR
  yi?iL*T '^i L°vv AN|> MI(IM cni "Ht
IF YOUR VIHICLE FAILS THE INITIAL EMISSIONS INSPECTION,  YOU MUST HAVE IT REPAIRED  AND
•ITHIR  PASS  REIN8PCCTION  OR  QUALIFY FOR A  WAIVER AS SPECIFIED IN THE  INSPECTION
REPORT SUPPLEMENT. IN EITHER CASE, TO QUALIFY  FOR  A REINSPECTION OR BE GRANTED
A WAIVER, REPAIR INFORMATION MUST BE PROVIDED BELOW:

                    TO BE FILLED OUT BY REPAIR FACILITY  OR VEHICLE OWNER
 P»r*on or Fdt lottklnq    . _ _        .„ .  ,       _  ..
               It «n NOIB >nilyl«r WM
               uted durli>o  the repilri
               r«oofrj tn« following
                                                                                       TOTAl HTPAIR COST
                                                                                       ANAl YZFH Rt'O NO
                                                                            %
                         Inlllal nnnrlltig           „     ppm
                         Final Heading                  pprn  _
I HEREBY CERTIFY THAT THE REPAIRS REQUIRED PER THE INSTRUCTIONS  CONTAINED IN THE
INSPECTION REPORT SUPPLEMENT WERE PERFORMED ON THIS VEHICLE: AND IF THE VEHICLE FAILS
RBINSPECTION, A WAIVER 18 REQUESTED.

NAMI:
                       IMPORTANT

           INSPECTORS  ARE  PROHIBITED  BY
           REGULATION  FROM  MAKING ANY
           RECOMMENDATIONS OR ESTIMATES
           RELATIVE TO REPAIRS.

           FOR  REPAIR INSTRUCTIONS  REFER
           TO   THE  INSPECTION  REPORT
           SUPPLEMENT.

           FOR  REGISTRATION  INFORMATION
           SEE REVERSE SIDE

           HP! H1U1/ M V I
                                       D  I  HEREBY  REQUEST  THE  SPECIAL  WAIVER WITHOUT
                                           REINSPECTION AS DESCRIBED  UNDER "CO FAILURES
                                           ONLY"  IN  '[HE  INSPECTION REPORT  SUPPLEMENT
                                           (FOLLOW INSTRUCTIONS CAREFULLY IF  REQUESTING
                                           THIS WAIVER	DO NOT MAIL THIS REQUEST WITH
                                           REGISTRATION FEES TO COUNTY ASSESSOR )
                                       PLEASE PRINT
                                       Nainn

                                       Stieot Acldross

                                      , Uly, State. Zip

                                       Signature
Figure 4.    State  of  Arizona vehicle  inspection  report,  reverse  side,
                                                       33

-------
from the Wisconsin form.  Arizona's report form,  for example,  has a detachable
compliance certificate in the lower left corner.   This compliance certificate
must be presented upon obtaining or renewing motor vehicle registration.
Wisconsin will be utilizing a slightly different  approach to proof of compliance.
Rather than issuing certificates of compliance, the inspectors will "stamp" the
inspection application forms at the inspection lane.

                    TABLE 3.  PROPOSED VEHICLE INSPECTION
                              REPORT REQUIREMENTS

              Item                 Description
                A   License plate number.

                B   Vehicle identification number.

                C   Model year of vehicle.

                D   Make of vehicle.

                E   Style of vehicle.

                F   Vehicle classification.

                G   Mileage.

                H   Emissions standards.

                I   Emissions Measurements.

                J   Statement of pass/fail, comply/noncomply,
                      or waiver, if applicable.

                K   Serial number or identification number
                      of emissions analyzer used in making
                      the test.

                L   Date and time of inspection.

                M   Serial number of report.

                N   Inspection number by station and lane.

                0   Inspector number.


     One  important  item not appearing on the proposed report list concerns
 whether the  inspection is an original test or a retest.  This information will
 be  important  in conducting statistical analyses on emission reductions from
 the original  test to the retest.  Additionally, according to the draft legis-
 lation, vehicles requiring mandatory inspection are entitled to one free re-
 test without  charge, provided:


                                     34

-------
     •    The motorist returns within 30 consecutive calendar
          days of the initial inspection.

     •    The specified emission-related repairs and adjustments
          have been made.

     •    The vehicle is accompanied by the initial inspection
          report with the specified repair information filled out.

Unless there is an indication on the inspection report as to whether the test
was an initial inspection or a reinspection, motorists could fail retests, fill
out this form, and qualify for additional retests at no charge.  This possibility
will be avoided if the inspection report identifies the test as a retest or
initial test.

Conducting the Inspection

     There are certain operator-entered or system-generated data elements not
included on the inspection report necessary for properly conducting the inspec-
tion.  First, as previously mentioned, as many as 18 vehicles may be undergoing
Inspection at the same time (in a six-lane facility).  While each of these
vehicles will have unique license or VIN numbers, an easier solution would be
for the system to generate a "queuing number" to identify the vehicle during
the inspection, tieing all inspection information to the proper vehicle.  Since
as many as six inspectors may be entering registration data simultaneously on
vehicles in the first position of their respective lanes, identification of
vehicles may have to occur before the VIN is entered; therefore, a queuing
number should be assigned to each vehicle at "Logon," and prior to entry or
generation of any other data.

     In some instances, the idle mode test may be performed in lieu of the
loaded mode test.  For these cases, the inspector must enter an idle-mode-only
code which notifies the system to forego the high and low cruise portions of
the test.  The draft rules have made provisions for eliminating the cruise
portions of the examination in the following instances:

     •    The vehicle has a tire or a driving wheel with less
          than 2/32-inch tread with metal protuberances, or
          with obviously low tire pressure (as determined by
          superficial visual inspection) or any other condition
          that in the opinion of the vehicular emissions inspector
          precludes loaded testing for reason of safety to personnel,
          equipment, or vehicle.

     •    The vehicle is driven by a person who, because of physical
          incapacity, is unable to yield the driver's set to the
          emissions inspector.

     •    The vehicle is driven by a person who refuses to yield
          the driver's seat to the emissions inspector.
                                      35

-------
     •    The vehicle is equipped with constant four-wheel
          drive

     It should also be noted that one other condition enables elimination of
one or both cruise tests.

     •    The vehicle is unable to be tested according to
          the dynamometer loading table because of the
          vehicle's inability to attain the speeds specified.

It is unlikely that the inspector will be able to determine this during data
entry.  Provisions must be made, then, to enable the inspector to change the
"test mode" field after the initial data entry.  This can be accomplished by
allowing data entry at the second position of the inspection lane, where the
vehicle will undergo the actual emissions measurement portion of the inspection.

     There are certain conditions that permit inspectors to refuse to perform
the emissions test.  The draft rules have identified four such conditions:

     1.   The vehicle's exhaust system has an obvious leakage
          or other condition that could affect the validity of
          the exhaust sample readings as determined by the
          stations vehicular emissions inspector.

     2.   The vehicle is smoking, and in the judgment of the
          vehicular emissions inspector, the vehicle is incapable
          of passing the exhaust emission inspection.

     3.   Gasoline or oil leaks are apparent and deemed a safety
          hazard.

     4.   The vehicle is carrying,  loaded with, or towing a
          trailer* loaded with explosives or any other hazardous
          material not used as fuel for the vehicle.

It is likely that discovery of these items will occur after the initial data
entry.  A provision must be made to allow the inspector to cancel the test.
The inspection file should not be deleted,  however.   Rather, a code should be
entered identifying the reason for inspection refusal.

     To enable proper selection of emission standards for each vehicle, two
items are needed:   model year and number of cylinders.  Model year is input as
item C in Table 3.  Item F., vehicle classification, should include the number
of cylinders.  Though not required to select emission standards, two additional
variables should be identifiable by item F, vehicle curb weight an engine dis-
placement.  The items are necessary to enable the system to select the proper
*
 Though not necessarily a safety hazard in all instances, trailers could be a
 nuisance in a test lane.  Wisconsin should consider not permitting any trailers
 in the facility.

                                      36

-------
dynamometer loadings for the cruise portions of the test, as shown in Table 4.
As also shown in Table 4, no displacement information is required for vehicles
with curb weights greater than 2,000 Ib.

          TABLE 4.  PROPOSED DYNAMOMETER LOADINGS AS A FUNCTION OF
                    VEHICLE CURB WEIGHT AND ENGINE DISPLACEMENT

            , ,  ,     ,    .  ,     High cruise mode   Low cruise mode
          Vehicle curb weight     °	   	
               (pounds)           hp       mph        hp     mph
Less than 2000
2000 - 2800
2801 - 3800
Greater than 3800
Idle test only
11.8-13.6 36-38
20.8-23.7 44-46
26.8-30.0 48-50
Idle test only
2.8-4.1 22-25
6.4-8.4 29-32
8.4-10.8 32-35
     Since the dynamometer loadings are divided into eight specific categories,
it is actually only necessary to identify the loading class rather than the
variables this class is dependent on, curb weight and engine displacement.

     In addition to collecting and storing HC and CO levels on each vehicle,
the C02 level must also be collected, despite the fact that no standard exists
for CO?.  The C02 level must be added to the measured CO level to validate the
inspection.  As indicated in the proposed rules, "the test will not be con-
sidered valid if the exhaust gas is diluted to such an extent that the sum of
the carbon monoxide and carbon dioxide concentrations recorded for the idle
speed reading from an exhaust gas outlet is 8 percent or less, and on 1975 and
later vehicles with air injection systems 7 percent or less."  A total of three
additional data items must therefore be collected:  C02 level, the system cal-
culated sum of CO and C02, and the system-generated valid/not valid decision.

Statistical Analyses and Administrative Recordkeeping

     There are a few additional items not previously accounted for that may be
important for analysis and recordkeeping.  The importance of differentiating
initial inspections from reinspections has been previously discussed.  For
recordkeeping purposes it becomes important, in the case of retests, to also
determine how many retests were undertaken by a specific vehicle.  If the State
uncovers considerable "ping-ponging" of vehicles from the inspection lane to
the repair industry and back, it may indicate that the repair process is not
being adequately explained to the motorists at the inspection facility.

     For each vehicle a record will be kept on both the emission levels measured
and the standards used to determine if the vehicle passes or fails.  For quality
assurance purposes, the standards used should periodically be checked to make
sure they are appropriate for the vehicle inspected.  To accomplish this, the
standards are compared with the criteria determining them (model year, number
of cylinders).  In some instances, this information will be misleading as the
proper standards will not be those generally assigned to the model year and
number of cylinders appearing on the inspection report.  For example, a 1968
motor vehicle which has had an engine replacement may have had a 1970 engine


                                      37

-------
installed.  The standards should be based on the engine.  However, the vehicle
should be recorded as the model year corresponding to the VIN for registration
recordkeeping.  In these cases, the vehicle's model year should be recorded but
a code should be recorded indicating that different standards were applied and
why.

     Some vehicles will not fit into any of the emission standards classifica-
tions, but will be tested according to the most appropriate classification for
which standards have been derived.  Two such examples have been mentioned in
the proposed rules.

     •    All rotary piston engines shall be treated in the
          same manner as four-stroke engines with four
          cylinders or less.

     •    All turbine engines shall be treated as four-stroke
          engines having more than four cylinders.

Identification of these cases is important for two reasons.  When emissions
level cutpoints are determined, these vehicles should probably be eliminated
from the analyses.  After cutpoints are determined, previous test results should
be compared with the new cutpoints to determine if they are still appropriate
for these vehicles.

     In summary, when a vehicle does not match the classification description
associated with the standards it is treated against, a notification should be
made enabling identification of this occurrence and the reason for it.
Elaborate descriptions need not be entered for this purpose, rather a "flag"
enabling quick determination of a special case should be activated and a code
indicating the general reason should be recorded, (e.g., replaced engine,
turbine vehicle, rotary piston, etc.)

     A summary listing of the input requirements for operator-entered or
system-generated data is provided in Table 1.  Only computer file data is pre-
sented in Table 1.  As previously mentioned, repair information, if required,
should be recorded on the initial test report and should include:

     •    Itemization of the repairs performed

     •    Cost of repairs or cost of estimated repairs
          required if such repairs exceed the maximum
          specified repair cost

     •    Name and address of the business firm or person
          making the repairs or the estimate

     •    Signature of person certifying repairs or the
          estimate

Other data the contractor should supply include information on equipment
calibration.  Specifically, the time of each calibration check, the results,


                                      38

-------
and what adjustments were made.  The equipment calibration process should be
performed periodically by the computer system.  A frequency of 1-hour is
reasonable for a centralized lane.  Calibration checks should include  analyzer
zero and span calibration checks.  These functions can actually be performed
using microprocessors within the analyzer itself.  In fact, equipping the
analyzer with its own "microcomputer" can reduce much of the burden on the
facility's minicomputer.  In the California system, for example, the analyzer's
microprocessors perform the following function:

     •    Analyzer zero/span check

     •    Exhaust gas sample purge after each test

     •    Health check of analyzers/sample system
          blockage

     •    Exhaust gas dilution limits

     •    Analyze test results, select state standards

     •    Forwards data to system controller and printers

One advantage of delegating the above task responsibilities to the emission
analyzer is that in the event of a computer malfunction, operations at the
inspection facility can continue.  When a facility's minicomputer is "down,"
semiautomatic operation is put into effect.  The analyzer system can forward
data directly to the printer in this instance.  A copy of the inspection report
can be kept at the lane, and this data can be entered into the computer at a
later time.  If both the computer and the analyzers are "down," the inspections
will have to be performed manually.  Under manual operation, a backup (garage
level) analyzer is used for emission measurement and all data is recorded
manually.  Automatic, semiautomatic, and manual operation is discussed in
greater detail in Section 4.

     The data files from each inspection should be included on a magnetic tape
and all information filed should be included with the contractors periodic
reports.  Items from Table 1 that were identified as being provided to the
State, will be the contents of this tape.  Further definition of these items
is provided in Table 2.

Data Transfer

     Data files for each inspection can be temporarily stored at the facility's
minicomputer on floppy disk.  The minicomputer should be equipped for bidirec-
tional telecommunications to the contractor's central (headquarters) computer.
The telecommunications link should be set for automatic transfer of a day's
data each evening (during off-hours).   This enables each individual facility
to remain independent and relatively unaffected by outages in the network
telecommunications systems.   The telecommunications operations are controlled
by the central headquarters computer.   The data processing telecommunications
                                     39

-------
links are depicted in Figure 5.  At the end of each report period, the con-
tractor will, along with the periodic report, submit to the State a magnetic
tape containing all of the information in Table 2 for every inspection per-
formed during that month.  The format and parity of the data tapes are de-
pendent on the State's computer.

     WDOT utilizes the State of Wisconsin's Hill Farms Regional Computing
Center.  Since 1977, the Hill Farms Center has been using an Amdahl 470 V/6
Model II CPU.  The Amdahl system is very similar to an IBM system and is
compatible with most minicomputer-generated tapes.  The tape requirements are
outlined below:

     •    Parity — Odd, 9-track tapes

     •    Density - 800 or 1600 bpi tapes

     •    Character Code — Extended binary coded decimal
          interchange code (EBCDIC)

     •    Data should be labeled

     •    One inspection report per record

     •    Data should be blocked (approximately 10 records
          per block)
                                      40

-------
                                       FACILITY - HEADQUARTERS COMPUTER
                                       TELECOMMUNICATIONS
                                 MODEM
 CONTROL
TELEPRINTER
                          SYSTEM  CONTROLLER

                             PROGRAM  PROCESSOR
                            24 K -WORD MEMORY
                                  FLOPPY DISK
                                                             (BULK  STORAGE)
                           INSPECTION  LANES
                              INPUT/OUTPUT
                 VEHICLE
               IDENTIFICATION
                TERMINALS
  EMISSIONS
MEASUREMENT
 SUBSYSTEMS
FEST  REPORT
 PRINTERS
                                                                             468-9
                    Figure 5.  Facility computer data links.

-------
                                   SECTION 4

                     DATA PROCESSING HARDWARE REQUIREMENTS


     The ultimate success of Wisconsin's automated Inspection and Maintenance
program will rest on the adequacy and success with which the contractor inter-
prets and accomplishes the data processing functions of the program.   Central
to this concern is the contractor's system hardware specifications and "hands
on" experience with any proposed equipment.  The general types of computer
hardware devices that will be required for the Wisconsin program are:

     •    Central processor

     •    Magnetic tape unit

     •    Communications interfaces (modems)

     •    Remote processors
     •    Flexible diskette storage

     •    Peripheral interfaces

     •    CRT display/data entry terminals

     •    Teleprinters, report printers

     •    High-speed printer

The specification of exact make and model configurations will be a central item
in the contractor's response to the data collection and processing requirements
of the program.  In this report, however, only general hardware specifications
will be discussed as an aid to Wisconsin in evaluating the proposed configura-
tions in responses to the subject RFP.

     The central processor, magnetic tape unit, a control terminal, the high-
speed printer, interfaces, and one modem will be located at the contractor's
headquarters office.  This central system will "dial up" the remote inspection
facilities each night and receive from their processors the vehicle inspection
data that was collected during their normal operations that day.  Each remote
site will consist of a processor, modem, control terminal, and a flexible
diskette storage unit; along with interfaces, a CRT data entry terminal, an
emissions measurement subsystem (EMS), and a teleprinter for each operating
inspection lane as illustrated in Figure 5.
                                     42

-------
PROCESSORS

     The processors used should be minicomputer central processing units (CPU)
which consist of arithmetic and decision circuitry, for computations and execut-
ing programs; and a memory section for the storage of program instructions and
intermediate test results and computations.  The processor should have a 16-bit
word length to ensure sufficient accuracy in computations and possess at least
24 and 32 kilowords of memory for facility and central processors, respectively.
Most currently available minicomputers use MOS (metallic oxide semiconductor)
memory due to its fast cycle time, low power requirements, and inherent relia-
bility.  The exact memory specified by the contractor must be of sufficient
capacity to support the necessary programming to control the maximum number of
vehicles undergoing testing at the site in question.  The processors specified
should be equipped with power-fail "save" capabilities, preferably a limited
battery backup system.  This battery backup will supply power to the processor
during power outages to ensure that at least the tests in progress can be
completed and processed before switchover to manual operations becomes necessary.

     The CPU is in effect the "brain" of the system and directly controls all
data collection, validation, storage, and inspection report preparation through
an operating system program called the System controller.  At each inspection
facility the processor, when programmed as described in Section 5, will perform
the following functions:

     •    Control progress of vehicle through the test lane

     •    Process vehicle identification data

     •    Accept emission measurement data from EMS

     •    Correlate vehicle data and select failure standards

     •    Compare measured values to limits separately for each
          individual input

     •    Output test data for report printout

     •    Output test data for storage on bulk storage devices
          (diskettes)

     The processor at the contractor's headquarters must be capable of performing
the following functions:

     •    Communication with each inspection facility processor
          through communications interface

     •    Data collection and data entry for inspection data

     •    Data validation and compilation for periodic submission
          of data to the Department of Transportation

-------
     •    Data analysis and summarization for network operating
          management

     •    Data management reporting

     •    Network software maintenance

     •    Preparation of magnetic tape file of inspection data for peri-
          odic submission to the Department of Transportation

     The prices of minicomputer central processing units vary greatly depending
upon machine cycle time, memory capacity, and the number and required speeds of
the input/output and peripheral communications channels.  A minicomputer pro-
cessor of relatively low speed with 32 kilowords of memory, such as may be
specified for the inspection facility System controller, will cost from $7,000
to $9,000.  The communication interfaces necessary to drive 24 peripheral
channels will add another $6,000 to $7,000 to this cost, however.  A faster
minicomputer processor, as might be suggested for the contractor's headquarters
central computer, will start at $13,000 for a 32-kiloword memory.  Again, however,
the $6,000 to $7,000 for peripheral channels has to be added to this cost.

PERIPHERAL INTERFACES

     The processors at both the contractor's headquarters and at all inspection
facilities should be interfaced with their respective  peripheral (input/output
and storage) devices using an industry standard interface designated RS-232C.
Both RS-232C and 20 mA current loop interfaces are available, but the RS-232C
is used almost exclusively for data transfer rates of greater than 300 baud.

     Use of this standard interface will allow for the future upgrading of
various devices in the systems or their conversion to devices produced by not
otherwise compatible manufacturers.  This upgrading or conversion capability
will be valuable in the event that operational problems are encountered with
any of the specified hardware devices.  For example, a specified terminal may
be unable to withstand the temperature extremes encountered in the inspection
lane and may have to be replaced by a more rugged unit.

COMMUNICATIONS INTERFACES

     The processor at the headquarters will be used to collect data from the
inspection facilities over normal voice-grade telephone lines using communica-
tions interfaces called modems.   These modems imprint binary (machine code)
data onto a carrier wave and then transmit the data over telephone lines, where
another modem receives the signal and decodes the binary data.  Modems should
interface with their respective processors using RS232C interfaces as previously
described.  The modem specified for the headquarters computer should have an
automatic "dial up" function to call the telephone numbers of the inspection
facilities at the designated times, and the modems at the inspection facilities
should have auto-answer capability.   To keep long distance telephone costs
to a minimum,  the modems specified should be capable of asynchronous,  full-
duplex, or bidirectional communication at a rate of 1200 baud (approximately
120 characters per second).   In lots of 25 or more for end-users the cost of
a 1200-baud modem will be about $800 to $1,000.


                                     44

-------
MASS DATA STORAGE DEVICES

     The online mass data storage device used by the processors should be a
flexible magnetic disk (diskette or floppy disk).  These are relatively small,
reliable devices that store data on a sheet of flexible plastic magnetic storage
media.  The average capacity for available flexible disk units is about 250,000
bytes (or 250,000 characters).  This is of sufficient size for even large six-
lane inspection stations.  Costs of flexible disk units can range from $3,500
to $4,500.

     The flexible diskette units should be interfaced with the processor using
an industry standard RS-232C interface and, when operating, will act as:

     •    A storage medium for initial system loading of
          the operating system software

     •    A storage medium for ongoing significant-event
          logging, Inspection facility maintenance data,
          and emissions equipment calibration data repre-
          senting ongoing inspection lane test activity

     •    A storage medium for daily storage of inspection
          and repair data that must be eventually forwarded
          to the Wisconsin Department of Transportation via
          the Contractor's Headquarters Computer

     •    A storage medium for online utility file data
          required to conduct the inspection process.

MAGNETIC TAPE UNIT

     The contractor's headquarters computer facility must have incorporated a
magnetic tape unit.  This unit will be used to create magnetic tapes of all
inspection data collected each day when the central processor receives it from
the inspection facilities.  These tapes will then be periodically submitted to
the Department of Transportation for further data validation, statistical
processing, and long-term inspection data storage.  The magnetic tape device
should be capable of creating 800 or 1,600 bpi nine-track tapes.  If possible,
the tapes should be labeled tapes coded in EBCDIC (preferably) or ASCII.  Costs
for magnetic tape drives can range from $8,000 to $18,000, depending upon tape
speed and subsystem control needed.

CRT DISPLAY/DATA ENTRY TERMINALS

     Hardware devices specified as the Vehicle Identification Terminals should
be Cathode Ray Tube (CRT) display terminals with keyboards.  These will be
installed at the first position in each inspection lane as an input device
for the entering of vehicle identification information.  The CRT terminal
specified should be capable of full-duplex (bidirectional) communication with
the system control processor using standard ASCII code at a minimum of 1,200
baud.  For compatibility or conversion purposes the CRT should be connected via
a standard RS-232C interface.

                                      45

-------
     For ease of display visibility by the inspector during varying light
conditions, the CRT screen should possess the following minimum display
characteristics:

     •    12-inch (diagonal) screen minimum

     •    64 displayable characters, at least 0.19
          inch high by 0.125 inch wide

     •    5x7 clot matrix characters

     •    80 characters per line

     •    12 lines on full screen minimum

     •    Nondestructive cursor

To minimize the inspector training necessary, the data entry keyboard should
be a standard ASCII Keyboard similar to an ordinary typewriter.  To protect
sensitive data on the display screen during data entry operations,  the system
control program should be capable of making the CRT skip over protected data
fields.  The cursor should be capable of movement through the use of clear,
tab, and home functions that can be performed without erasing the contents
of the screen.

     The price of CRT display terminals ranges from $1,500 to $2,000.

EMISSIONS MEASUREMENT SUBSYSTEMS (EMS)

     The EMS should be specified capable of controlling, either automatically in
conjunction with the System Controller, or semiautomatically, all emissions mea-
surement and test control functions.  The EMS should consist of an NDIR exhaust
gas sampling device, a sample conditioner, a programmable microprocessing device,
and a control pendant.  During normal automated operations the EMS  should be
controlled by the System Controller.  During equipment or power failures, the
EMS will function manually but should be capable of controlling the inspection
report teleprinters.  Obviously, one EMS will be required for each lane.

     The EMS Control Processor (EMSCP) should be a programmable 8-bit micro-
processor device to control the operation of the exhaust emissions  analyzers.
The EMSCP will communicate with the facility's System Controller during normal
automatic mode, but it should be a functionally independent modular component
of the SYSTEM.  The System Controller will pass to the EMSCP various data items
such as the vehicle queue number and its related emissions standards.  After
the test is completed, the EMSCP will transmit emission values, etc. back to
the System Controller for output on the inspection test report teleprinter.
During System Controller downtime, however, the EMSCP should be capable of
running the emissions test and outputting the results through the report
teleprinter without going through the System Controller.
                                     46

-------
     The EMSCP should be programmed to perform the following:

     •    Prompt and cue inspector during emissions measurement

     •    Convert raw analog measurement and status data
          to digital information

     •    Perform necessary calculations

     •    Correct measured instrument values including
          dynamometer speed and horsepower

     •    Compare results to the State's emissions standards

     •    Display emission values

     •    Transmit data to the System Controller, or the
          Inspections Report Printer during System Controller
          downtime.

     The test control pendant will be required to serve as an interface between
the inspector and the EMS.  The pendant should consist of a standard computer-
type keyboard enabling operator intervention during the automatic testing pro-
cedure.  For example, the pendant should be capable of "interrupting" the EMS
and/or the System Controller with at least the following commands:

     •    Start test

     •    Abort test

     •    Restart test

     •    Delete one or more modes of the test

     •    Select mode

     •    Control dynamometer wheel lift

     The test display panel (TOP) will be used in conjunction with the control
pendant to provide the man-machine (inspector-EMS) interface during the emis-
sion test procedure.  The TOP will prompt the inspector with various instruc-
tions and display the test progress.   In the event of any problem, the inspector
can then intervene in the automatic test procedure using the control pendant
as described above.    Numerous informational displays can be produced by the
display panal such as:

     •    Measured road speed

     •    Indicated  corrected horsepower applied  to the
          vehicles driving wheels

     •    Mode of operation — high cruise,  low cruise,
          or idle
                                     47

-------
     •    An indication that the vehicle's  road  speed  is
          not within the appropriate tolerance during  the
          high cruise and low cruise modes

     •    An indication that the EMS controller  has  determined
          that all the prerequisites for a  valid emission  test
          have been satisfied and the emission inspection  is
          progressing properly

     •    An indication that the test sequence is complete

     •    An indication that the EMS is in  semiautomatic mode
          (not communicating with the System Controller)

     •    An indication that a message has  been  printed on the
          control teleprinter

     •    Idle RPM out-of-tolerance

     •    Exhaust gas sample dilution warning

TELEPRINTERS AND LINE PRINTERS

     Teleprinters should be specified in the roles of  inspection report printers
and control teleprinters where hard copy (paper) output is desired at the in-
spection facility.  The inspection report teleprinter  will be used to print
the inspection test results and other appropriate information.  The report
teleprinter should generate inspection reports on 8-1/2 by 11 inch report forms
(one original and two copies) of the contractor's design.   The control tele-
printer will act as an operator console to  communicate with,  and print messages
from, the System Control program operating  in the processor.

     The inspection report teleprinter and  control teleprinter should be inter-
faced with the processor using standard RS-232C  interfaces and should communicate
using industry standard ASCII transmission  code.  The  teleprinters should be
capable of printing a minimum of 80 characters per line at a  speed of 30 charac-
ters per second (300 baud).

     For ease of reading and to avoid the necessity for confusing abbreviations
in the output, the teleprinters should possess the following  display
characteristics:

     •    Minimum of 64 ASCII displayable characters

     •    Minimum character size 0.19 inch  high by 0.11 inch  wide

     •    Minimum 7x7 matrix characters (if applicable)

     For the purpose of outputting large reports or listings  from the central
computer at the contractor's headquarters,  a line printer may be specified.
These devices print at relatively high speed (usually  300 lines/minute) and can
produce listings up to 132 columns across.   For compatibility they also should
be connected via an RS-232C interface.


                                      48

-------
     The cost of a teleprinter will be approximately $900 to $1,600, and the
cost of a line printer begins at $6,000 and up, dependent upon lines per
minute speed.

STATE COMPUTER FACILITIES

     The 9-track, 800 or 1600 bpi magnetic tapes of inspection test results pro-
duced by the Contractor's headquarters computer will be periodically submitted
to the Wisconsin DOT for further analyses.  These data tapes will be used as
input to various statistical analysis programs executed on the State's Amdahl
470 V/6 Model II located at the Hill Farms Regional Computing Center.  The
State will therefore not be required to purchase any data processing equip-
ment for the purpose of analyzing its inspection results data base.

     While no hardware will be required by the State, an interest was expressed
in having a graphics CRT display terminal located at the DOT office.  Program
execution could then be initiated at the DOT and results displayed in the form
of diagrams and plots on the CRT.  This would entail the purchase, by the DOT,
of a graphics CRT display terminal along with the necessary interfaces and
telecommunications.   CRT graphics terminals cost between $4,000 and $7,500
(average about $5,000) depending upon the memory capacity of the terminal.
Communication interfaces discussed previously would cost an additional $900.
                                      49

-------
                                  SECTION 5
                    DATA PROCESSING SOFTWARE REQUIREMENTS
SOFTWARE REQUIRED
     The software requirements for Wisconsin's I/M program can be divided into
three major categories.
     •    SYSTEM software
     •    Data transfer software
     •    Analysis software
SYSTEM Software
     Software In this category consists of essentially all programs necessary
for the System Controller to enable the SYSTEM to:
     •    Prompt for, accept, and verify vehicle identification data
          from the Vehicle Identification Terminals (VIT)
     •    Coordinate the emissions inspection through the Emissions
          Measurement Subsystems (EMS)
     •    Correlate vehicle emissions data, select appropriate standards
          and dynamometer loadings, make pass/fail determinations
     •    Output test data for report printout and to bulk storage
     •    Perform and keep records of emissions analyzer calibration
          checks as well as all other SYSTEM maintenance data
     Related to the SYSTEM software is the EMS software.  As discussed in
Section A, the EMS will be controlled by an independent  (micro) processor,
the- F.MSCP.  EMSCP software consists of all programs necessary to enable the
EMS to perform the following:
     •    Prompt and cue the inspector during the inspection
     •    Convert raw analog measurements into digital format
     •    Perform all necessary calculations
     •    Monitor and correct dynamometer loadings, instrument drift, etc.
     •    Collect and analyze emissions, make pass/fail  determinations
     •    Display appropriate information during inspection (road speed,
          horsepower load, mode of test, test complete, warning messages, etc.)

                                     50

-------
     Both the SYSTEM software and EMS software are classified as "real-time."
By real-time we mean an information system in which inputs are immediately
available enabling control of the process that generates these inputs.  In
I/M lane operation, as in most real-time situations, "online" processing is
required.  By online, we mean that the input goes directly to the System Con-
troller at the time when it originates.  This is opposed to the approach
where data is gathered over some period of time and processed in "batches."
In an online system, the data is processed at the time it originates.  The
concepts of real-time and online processing are often erroneously used inter-
changeably.  Online is a physical concept indicating that a device (such as
the dynamometer, emission analyzer, sample collector, sample conditioner,
VIT, report printer, etc.) is connected directly to the computer (in this
case the System Controller or the EMS control processor).  Real-time, on the
other hand, is a dynamic relationship involving the availability of informa-
tion in time to affect future inputs.3

     The SYSTEM and EMS software, like most real-time application software,
should be written in an Assembly language.  Assembly language is very close
to actual machine or binary language, thereby involving a minimal amount of
translation time.  Assembly is the preferred language for real-time applica-
tions as it can be much more efficient than higher level languages such as
FORTRAN or COBOL.

     The State should require the contractor to utilize the general program-
ming approach known as "Structured Programming."  Structured Programming re-
fers to a programming methodology or a set of procedures for creating programs,
E.W. Dijkstra of the Netherlands is credited with the popularization of the
term "Structured Programming."  In the Dijkstra interpretation,4"8 Structured
Programming is not an algorithm nor a set of rules to be followed, rather it
is an approach to be utilized in developing programs.  Structured Programming
involves a technique called "contructive programming" which in essence means
constructing a program that is guaranteed to be correct rather than designing
and coding a program first and then trying to determine why it won't work.
A program created in this manner will contain two structural features and two
procedural features, which are briefly outlined below.  (For a more compre-
hensive explanation, see references 4 through 8.)

     The first structural feature of this approach involves a strict adher-
ence to the use of rigid sequencing statements in programming.  This involves
Heverly limiting the use of GO TO statements thereby eliminating difficulty
in following the "flow" of a program.

     The second structural feature of this approach is to reduce the complex-
ity of a program to small manageable proportions.4'9  This means the use of
subroutines is encouraged.  This is related to the first procedural corollary
of Structured Programming which involves "the use of hierarchy to develop
programs in a stepwise manner, pushing details into ever lower and simpler
subroutines."  This involves "modularization" of a program or dividing a
program into many independent modules (or subroutines) and incorporating a
single design decision into each module.10  In this way any change in a
design decision will usually involve changing only one subroutine within the
entire system.

                                     51

-------
     The  final procedural feature of structured programming is more subtle
and difficult to define.  Essentially, Dijkstra suggests the following pro-
cedure  for constructing "correct" programs:  "explicitly state the conditions
which must hold if we are to prove an algorithm performs correctly; then, write
a program that makes the conditions come true."9

     A  Structured Program will achieve the following basic goals (listed in
order of  importance):

     •    Reliability - Does the program consistently give dependable
          results that are accurate?

     •    Modiflability - Can the program be modified easily to respond
          to changing standards, requirements, or desires?

     •    Understandability - Since the State will likely reserve the
          option to purchase the SYSTEM, including all software, will
          the State programmers be able to understand the program logic
          well enough to use, update, and modify it?

     •    Efficiency - Does the program operate as efficiently and inex-
          pensively as possible?

     In responding to the RFP, bidders will not, for obvious reasons, be able
to provide the software for the SYSTEM and EMS.  They should be required,
however, to propose an overall plan for the design and implementation of all
software.  In evaluating software plans, consideration should be given to
proposals that point out that the software will be developed using "Structured
Programming," "constructive programming," or "modular programming."  The State
should be cautious in considering proposals suggesting dissimilar programming
approaches or proposals that call for real-time programs in other than Assembly
or macro-level languages.

Djata_ Transfer

     Transfer of data from individual facility system controllers to the
headquarters computer does not require a processing system as rigorous as
real-time.  Rather, this function can be achieved using queued processing.
In queued processing, transactions are processed according to a particular
scheduling algorithm (e.g., "first come, first served," or a priority ranking).
The Important criteria of the data transfer software is successful relaying
of bulk storage data from each facility to the headquarters computer.  This
software controls the modems and telecommunications links and is, like real-
time software, generally programmed in an Assembly-level language.  Like all
software developed in connection with the I/M program, the structured or
modular programming approach should be employed.

Data Analyses

Two subcategories of software exist under the analysis heading:  those devel-
oped by the contractor (recordkeeping, reporting, etc.) and those developed
by or for the State (program evaluation, cutpoint selection, etc.).  Since
immediate response is not necessary for these analyses, they fit into the
                                    52

-------
batch process1ng category.   A system In which processing is performed in a
batch mode differs from real-time, online, or queued processing in the follow-
ing areas:
     •    First, a request  for information is made through the data
          processing center with the time delay inherent in this
          procedure.
     •    Second, processing of the request will have to await comple-
          tion of job(s) already being processed.
     •    Third, the information report must be physically delivered
          from the data processing center to the person who made the
          request, unless the requestor has an on-line printer.

     The major differences  between real-time, queued, and batch processing
involves response time.  This is shown in Table 5.

            TABLE 5.  RESPONSE TIME FOR VARIOUS PROCESSING MODES11
  Processing mode   Magnitude of response time          Example
Batch
Queued
Online
Real time
Minutes-hours
Minutes
Seconds
Microseconds
Simple billing systems
Document retrieval system
Reservation or banking
system
Process control
     As is the case for other software categories, batch software should also
be written using structured or modular programming.  Unlike real-time or
queued programming, batch programs can be written in higher level languages
(e.g., FORTRAN, PL/I, etc.).  Again, the particular language or strategy used
is of considerably less importance than the program's ability to fulfill the
four goals generally met by Structured Programming:  reliability, modifiabil-
ity, understandability, and efficiency.

CONTRACTOR-DEVELOPED SOFTWARE

     As previously mentioned, bidders should be required to submit an overall
plan for the design and implementation of all software.  The plans should con-
tain an Implementation schedule pointing out when the major events (designing,
coding, testing, etc.) will begin and end.  The proposals should also include
a plan describing how the bidder proposes to assure close cooperation with
WDOT during the development process.  The State should require regular pro-
gress meetings between the contractor, WDOT, and staff programmers, engineers,
and analysts (from Hill Farms Computing Center).
                                     53

-------
Software Documentation

     Following development of the software, the contractor should be required
to provide complete documentation of all software.  Documentation involves
more than a simple listing of all program steps.  Although there is some obvi-
ous overlap between them, the following general types of documentation can be
identified:9

     •    Design documentation
     •    Construction documentation

     •    User documentation

     •    Maintenance documentation

     Design documentation consists of a description of the concepts a system
is built on and its overall structure.  This type of documentation is a
"blueprint" for developing the system.  This would constitute the overall
plan for designing and implementating the software and, thus, can be a re-
quirement of the proposals.

     As the software is developed, construction documentation can be provided.
This would include precise formats, data layouts, algorithms, etc.  Another
important function of this type of documentation is to provide information
about the current development status, program names, etc.  This type of docu-
mentation should be a contractor requirement for the regular progress meetings.

     User documentation restates and expands upon the functional specifica-
tions the system is supposed to fulfill.  This category would include user's
manuals and operator's guides which present precise information on the func-
tions of the system and how to use them.

     Maintenance documentation should consist of complete descriptions of the
system itself in its final format.  This type of documentation should include
information on limitations of the system, procedures to be followed in updat-
ing or modifying the system, and listings of all program statements for all
developed software.

STATE-DEVELOPED SOFTWARE

     The State will be required to develop software enabling performance of
the program evaluations described in Section 3.   There are three options
open to the State in fulfilling this requirement.

     1.   Develop specific software "in house"

     2.   Use preexisting software packages

     3.   Obtain the services of a software firm to develop software
          and/or conduct the analyses

     The first option is the preferred solution provided that sufficient re-
sources are available to undertake this type of task.  By completing the
development "in house," the State is assured of the highest degree of interface

                                     54

-------
between WDOT, WDNR, and the computer programming staff that undertakes the
project.  No RFP would have to be developed, proposals evaluated, or contracts
drawn as would be the case if an independent firm were hired.  The second
alternative, use of preexisting data analysis packages, may be feasible on a
one- or two-time basis, however, for analyses that will be performed period-
ically, it is generally much more efficient to develop a program for that
specific application.  Preexisting packages run the following risks:
     i.   The algorithm may solve the wrong problem.

     2.   The algorithm may solve only a portion of the problem.

     3.   The algorithm may solve a more complex problem than necessary.

     An example of the above three risks can be demonstrated as follows:
Say, for instance, an algorithm is needed to find the roots of a quadratic
equation.  The consequences of the first risk (solution of the wrong problem)
would be similar to trying to use the best algorithm for solving a linear equa-
tion.  While it may be a good algorithm, it is of no use for the intended appli-
cation.  The second example (solving only a portion of the problem)  would be
like using an algorithm to find only the real roots of a quadratic equation,
when in fact, the actual problem may have been to find all of the roots.  The
last example could be using an algorithm to find the roots of a quadratic equa-
tion when only the roots of a linear equation are needed.   Certainly an algo-
rithm to find the roots of a quadratic equation could be used to find the roots
of a linear equation; however, this is a much more elaborate algorithm than
necessary,  and will likely be less efficient and more costly than an algorithm
designed specifically for the intended application.  In using predeveloped
program packages, the third situation would most often exist.  Packages are
usually designed for general applications,  thus containing excess capability
at the cost of efficiency.  When the cost of developing a  specific program is
weighed against the cost of running a perhaps less efficient (due to excess
capabilities) preexisting program,  the determining factor  will generally be how
frequently the program is to be run.   It will almost always be more  cost effec-
tive to develop specific software when the algorithm called for is to be used
many times.  However, for analyses that will be performed  only a limited number
of times,  a preexisting package can be extremely worthwhile.   There  are a number
of sources for preexisting algorithms.3

     •    A professional organization publication.   (For example,  each
          month algorithms for solving various problems are published
          in the Communications of  the ACM.   Once each year an index
          of algorithms that  appeared during the preceding  year is
          published in the same source.)

     •    A computer manufacturer's  library  of internally  developed
          programs.   (Computer manufacturers often develop  libraries
          of programs for solving various problems.   For example,  IBM
          has a set of programs for  solving  mathematical and  statis-
          tical problems that  it  calls  the  Scientific  Subroutine
          Package.   The cost  of these programs varies  widely.)
                                     55

-------
     •    A computer manufacturer's library of user-contributed
          programs.  (As a service to its customers,  many computer
          manufacturers maintain a library of programs submitted
          by users.  These are usually available to their customers
          at little or no cost.)

     •    Another state which has an I/M program.

     •    A standard package from a software house.  (A software
          house is a business which exists to develop programs
          for the solution of a particular class of problems.
          The programs they develop are their products to sell.)

     The last source, a software house, can also be contracted to develop
application-specific programs, which would be a similar solution to in-house
development except involving the extra costs of contracting, and the software
house's overhead and profit.  If the State's in-house staff lacks the time and/
or expertise to develop the analysis software, contracting out the work is the
most logical alternative.  Additionally, software houses may be more efficient
in developing programs due to experience, expertise,  etc. and could actually
be cheaper than in-house development despite profit and contracting costs.
This is dependent on the experience, efficiency, and expertise of the State's
data processing staff.

SOFTWARE DEVELOPMENT COSTS

     The costs for development of software are dependent on the following:

     •    The skill, experience, and efficiency of the
          programming team.

     •    The length of time required to develop the
          program.

     •    The hourly rate associated with the programming
          team.

     More specifically related to the software requirements for a centralized
I/M program are the following factors:

     •    Will the contractor develop the software in-house
          or subcontract the work out?

     •    Does the contractor (or subcontractor) have directly
          applicable experience in I/M software development?

     •    What hardware configuration will the contractor propose?

The number and degree of cost variables prohibit the presentation of a precise
cost for this element.  Alternatively, an estimate was developed based on
experiences of other states involved in I/M, discussions with representatives
of software houses, and an analysis by members of the GCA data processing staff
Based on these sources, the following estimates were developed.

                                     56

-------
Contractor's Software—
     For development and installation of real-time programs, data transfer
programs, report making, and data handling programs an estimate of 3,500 man-
hours was developed.  In addition, it is estimated that approximately 1,000
man-hours will be required for developing documentation and progress
reporting:

     Contractor's software             3,500 man-hours

     Contractor's documentation        1,000 man-hours
         Total                         4,500 man-hours

To translate hours into a dollar cost, a standard hourly charge of $30 was
assumed.  The total estimated cost for development of the contractor's soft-
ware, then, equates to approximately $135,000.

State's Software—
     For developing and/or modifying statistical and recordkeeping programs
an estimate of 1,000 man-hours was developed.  For developing documentation
an additional 200 man-hours is estimated:

     State's software                  1,000 man-hours

     State's documentation               200 man-hours
                                       1,200 man-hours

Using the same $30 per hour rate, this translates to a total cost of $36,000
for the State's software.
                                     57

-------
                                   SECTION 6

                              RFP CONSIDERATIONS
     In establishing a contractor-operated I/M program, it is important to obtain
as many good quality proposals as possible.  The quality of the proposals sub-
mitted is somewhat directly proportional to the quality of the RFP issued by
the State.  If the RFP is vague or ambiguous, bidders will be forced to try to
"read the minds" of the State officials.  This could eliminate highly qualified
contenders from consideration simply because they could not interpret the State's
desires.   It is important, then, that the RFP be very specific about the func-
tional requirements of the data collection, handling, and processing system.
The bidders should be well aware of the State's expectations concerning what
data should be collected, generated, stored, and supplied to the State.  They
should know the minimum acceptable specifications for data gathering and pro-
cessing equipment as well as what software they will be required to produce.

     Thero is a risk, on the other hand, of developing an RFP that is too
specific.  While the bidders must be made well aware of what they must do, the
RFP should be left somewhat open concerning how it is accomplished.  By being
too specific concerning how data is collected, stored, and processed, the bidders
could be  prohibited from proposing what could be a higher quality or more cost-
effective data handling system than that specified in the RFP.  Additionally,
if the RFP is overly specific, the technical portions of the proposals received
will be too similar to enable evaluation of the technical problem solving
capabilities of the prospective contractors.

     The  State should solicit proposals from as many potential contractors as
possible.  Some concern has been raised that the number of interested and quali-
fied firms is very limited.  Much of this concern stems from the fact that to
date, only one firm, Hamilton Test Systems, is operating motor vehicle emissions
inspection programs.  The U.S. EPA Emission Control Technology Division held an
information seminar in May 1979 for prospective contractors and subcontractors.
At this seminar a total of 23 firms expressed interest in becoming prime con-
tractors  and 15 others indicated a desire to become subcontractors in one or
more of the following areas.

     •    Instrument procurement and maintenance

     •    Data analysis

     •    Systems design, engineering or evaluation

     •    Emission testing operations
     •    Public relations and information


                                     58

-------
     •    Data processing
     •    Building and construction of facilities

Based on this information, Wisconsin should not encounter a lack of responses
to the RFP.

     The remainder of this section consists of a model data processing section
of an RFP for Wisconsin's I/M program.  The rationale for the various functional
requirements and specifications are presented in Sections 4 and 5.   This portion
of the RFP is divided into three sections, Functional Requirements, Equipment
Specifications, and General Requirements.  These three sections are prefaced
by a general introduction which could appear within the overall introduction
to the RFP or at the beginning of the data processing portion.  Definitions
of key terms are provided following the RFP.

MODEL DATA PROCESSING PORTION OF A REQUEST FOR PROPOSALS
FOR A MOTOR VEHICLE EMISSIONS INSPECTION PROGRAM

Preface

     The contractor shall design, acquire sites for, construct, equip, and
operate a network of motor vehicle emissions inspection facilities  within the
specified areas of the State of Wisconsin.  Within each of the inspections
facilities the contractor shall provide and install an inspection SYSTEM, a
description of which shall be included in the proposal.  The SYSTEM shall be
capable of performing loaded-mode (key mode) testing in accordance  with the
inspection procedures specified in Section  of this RFP.

     The specifications provided within this RFP represent the State's desired
configuration for the inspection SYSTEM.  The contractor is free to deviate
from the specific assemblies, methods, procedures, and logic, and to arrange
the equipment physically in any manner, provided the functional requirements
defined below are satisfied.  Wherever the contractor deviates from the config-
urations provided within the RFP, however, he shall provide a comprehensive
description of the deviation, justification for the deviation, and  rationale
as to why the proposed SYSTEM will be of higher quality or be more  cost effec-
tive than that specified in the RFP.  The Contractor shall also be  prepared
to demonstrate (if required) that the functional requirements of the SYSTEM
are fulfilled despite deviation from the RFP.

Functional Requirements

     The SYSTEM shall be capable of measuring hydrocarbons (HC) carbon dioxide
(C02)* and carbon monoxide  (CO) emissions from light-duty and medium-duty ve-
hicles (GVW <8,001 Ib) , excepting those vehicles exempted by draft  legislation
or WDNR administrative rules, that will be subject to steady-state, loaded-mode
*
 Although no standards for C02 will exist, this concentration is necessary to
 verify valid emissions measurements as specified in Trans   .09(1), Emission
 Testing Criteria.
                                     59

-------
testing on chassis dynamometers at high cruise, low cruise, and at idle as
will be defined by the motor vehicle emissions inspection rules.

     Vehicle testing measurements, data entry, data processing, and data output
shall be capable of simultaneous and independent occurrence in all lanes of
any given facility and shall have no effect on the testing of any other vehicle
within that or any other lane.

     The SYSTEM shall be capable of receiving inputs from outside the SYSTEM
via data entry devices and measurement devices incorporated within the SYSTEM.
The proposal shall present a description of the information types, data entry
devices, measuring devices, and the ranges and characteristics of data input.

     The proposal shall describe a method of vehicle registration data entry,
which will allow the SYSTEM to match test results with the vehicle in question.
It  is the State's desire that the inspectors enter and verify registration data
using a standard typewriter formatted keyboard and alpha-numeric Cathode Ray
Tube (CRT) for a Vehicle Identification Terminal (VIT); and that the inspectors
be  trained CRT operators.  Verification of the data shall occur as follows:

     •    Keyboard entered data shall be retransmitted by
          the SYSTEM to the VIT.

     •    Data shall be limit checked on a field by field
          basis immediately following entry of each field.
          Data found to be in error will cause the VIT to
          backspace its cursor and command the inspector
          to reenter that  field.

     •    When the inspector  signals that he has completed
          entry of all  items  (ESCAPE logoff),  the SYSTEM shall
          verify  that all  entry fields have been filled.   If
          not, the logoff  shall be overriden,  the cursor returned
          to the  unfilled  field,  and the inspector prompted  to
          enter the required  data.

     At  all  times during the  inspection process, the  inspector  will  be able
 to  terminate any  or all portions  of  the test  (e.g., eliminate  one  or more
 cruise  portions for reasons specified  in the  draft rules).   The SYSTEM must
 be  able  to  accept commands indicating  whether  the vehicle  is  to be retested,
 excluded from  one or more  portions  of  the  test, or excluded  from all further
 testing.   If the  vehicle is  to  be retested, any data  gathered  during the  re-
 test  shall  replace  data from  the  original  file.*   If  the  test  is terminated,
 a test  report  shall be  generated  furnishing  the following  information:
  This is for the case of immediate retesting due to an error or malfunction.
  This should not be confused with retesting of  failed vehicles  following
  repair.
                                      60

-------
     •    Test serial number

     •    Date and time of test

     •    VIN

     •    Vehicle make

     •    License plate number

     •    Reason(s) for termination

     Vehicles refused inspection for safety reasons as specified in the draft
Transportation Administrative Rules will also receive the above information with
reason(s) for safety rejection replacing reason(s) for termination.  In the case
of a safety rejection, this data will be placed in the test data bulk storage
file.  In the case of termination for other reasons, no record of the test need
be stored.

     For each steady-state, loaded-mode condition specified in the draft Trans-
portation Administrative Rules, the SYSTEM shall receive data from the Emissions
Measurement Subsystem (EMS).  This data shall be measured and averaged in such a
way as to assure that each derived measurement is a valid representation of the
true desired measurement.  The proposal shall include a scheme to ensure the
validity of the emissions measurements including:  the number of samples to be
collected for each mode of the test, the sampling rate, the averaging technique,
and a general description of all software to be used.

     The bidder shall propose a testing algorithm for the SYSTEM, including
verification checks of the data (CO plus CC>2, idle speed, etc.) as specified
in the draft Transportation Administrative Rules, and pass/fail determination
based on standards developed by the Wisconsin Department of Natural Resources.

     All vehicle test data shall be stored in a test data bulk storage file
for later transcription and delivery to the State.  The test data bulk storage
file shall include all information included on the test report issued to the
public and shall consist of, but not be limited to, the following:

     •    Test or retest(s)

     •    Inspection mode (manual, automatic, semiautomatic)
     0    License number

     •    Vehicle Identification Number (VIN)

     •    Model year

     •    Vehicle make
     •    Vehicle style

     •    Vehicle class

     •    Mileage (thousands)

     •    Emission standards:

          -    High cruise CO

          -    High cruise HC
                                      61

-------
     —    Low cruise CO
     —    Low cruise HC
          Tdle CO
          Idle HC
•    Emission measurements:
     -    High cruise CO
     -    High cruise HC
     —    Low cruise CO
     —    Low cruise HC
          Idle CO
          Idle HC
•    Pass/Fail:
     -    High cruise CO
     —    High cruise HC
     —    Low cruise CO
     —    Low cruise HC
          Idle CO
          Idle HC
•    Analyzer ID
•    Date:  day/month/year
•    Time:  hour/minute
•    Serial number of report
•    Serial number of previous report (retests only)
•    Station number
e    Lane number
•    Inspector number
•    Test modes performed
•    Inspection abort/reason
•    CO and C02 sum  (measured)
•    CO and C02 sum  (standard)
•    CO and C02 sum  result (valid/not valid)
•    Special case ID and code
•    Waiver indication
                                 62

-------
     The SYSTEM should be capable of printing legible inspection reports
automatically upon completion of the inspection.   The inspection report must
consist of,  but is not limited to, the following:

     •    License plate number

     •    Vehicle identification number

     •    Model year of vehicle

     •    Make of vehicle

     •    Style of vehicle

     •    Vehicle classification

     •    Mileage

     •    Emissions standards

     •    Emissions measurements

     •    Statement of pass/fail, comply/noncomply,
          or waiver, if applicable

     •    Serial number or identification number of
          emissions analyzer used in making test

     •    Date and time of inspection

     •    Serial number of report

     •    Inspection number by station and lane

     •    Inspector number

     •    Identification of test or retest

     •    Prior test report number (in the case of
          a retest)

     The Report Form shall also provide space for the following:

     •    Itemization of the repairs performed

     •    Cost of repairs or cost of estimated repairs required
          if such repairs exceed the maximum specified repair
          cost
                                      63

-------
     •    Name and address of the business firm or person
          making the repairs

     •    Signature of person certifying repairs

The Inspection Report format, which shall comply with all requirements within
the draft Transportation Administrative Rules, shall be included in the proposal.

     The SYSTEM shall be capable of either manual and/or automatic gas analyzer
span and zero drift checks.  If either span and/or zero drift exceeds tolerances
prescribed by the Department of Transporation, the analyzer must be calibrated
prior to performance of additional tests.  If both span and zero drift are
within tolerances, the measured amount of drift shall be used to correct all
other gas measurements until the next span and zero drift check.

     System maintenance data shall be maintained on a data bulk storage device
and the contractor shall make such records available for inspection by the State
representative.  The maintenance records to be stored shall include:

     •    Number of tests on each lane since last dynamometer
          calibration, maintenance, etc.

     •    Number of tests on each lane since last EMS maintenance
          or calibration

     •    EMS analyzer and dynamometer cross check and calibration
          data

     •    Daily log of significant operator transactions with the
          System Controller

     •    Daily log of aborted tests  including time of day and
          reason

The contractor shall propose a format for maintenance data storage and log
printout.

     The SYSTEM shall accept and act  upon various operator commands and inquires
entered via  the Control Teleprinter.  The system  functions and  capabilities,
which shall  be specified  in  the proposal, as a minimum, shall:

     •    Allow the operator to set the date and  time.

     •    Allow selection of the number of vehicle tests between
          automatic span  and zero drift checks.

     •    Print daily logs  stored  in  the maintenance
          data bulk  storage  file.

     •    Print vehicle inspection data  from  the  vehicle
          data bulk  storage  file.


                                     64

-------
Equipment Specification^

     The following equipment configuration represents  the State's desired system.
The contractor is free to propose alternative configurations provided that the
functional requirements are met.   Wherever the proposal deviates from the State's
desired configuration, the contractor must demonstrate that the function re-
quirements are met.

     The SYSTEM equipment* shall  be configured as follows:

     •    The System Controller shall be responsible for data
          entry and validation, data processing,  data  management,
          and report printing.  The System Controller  shall control
          all of the Emissions Measurement Subsystems  (EMS), Vehicle
          Identification Terminals (VIT), Bulk Data Storage Devices,
          the Control Teleprinter, and Report Printers within a
          facility.

          The System Controller shall have real-time control of the
          SYSTEM.  The System Controller shall be a stored program
          device consisting of a  program processor and adequate memory
          for program and data storage.

          The System Controller shall perform the following functions:

          —    Accept vehicle identification data from Vehicle
               Identification Terminals.

          —    Accept emission measurement data from Emission
               Measurement Subsystem.

          —    Correlate vehicle  data and select  failure standards.

          —    Compare measured values to limits  separately for
               each individual input.

          —    Output test data for report printout.

          —    Record maintenance records on data bulk storage
               devices.

          —    Output test data for storage on bulk storage
               devices.
 Only data handling and processing equipment are discussed here.   Wisconsin's
 RFP should contain specifications for other SYSTEM equipment as  well (e.g.,
 sample conditioners, gas analyzers, dynamometers, exhaust venting systems,
 etc.).
                                     65

-------
     The System Controller  shall  have  as  a minimum 24
     kilowords of 16-bit  word  length memory,  and  a real-
     time clock interface to support a real-time  operating
     system.   The System  Controller may utilize Core or
     semiconductor memory.   (Proposals specifying semi-
     conductor memory must  include battery backup provisions
     to maintain memory for a  minimum  of  5 minutes in  the event
     of external power loss.)   The CPU memory must be  of
     sufficient size to support the real-time operating  system,
     all program modules, and  sufficient  space required  to
     process  the maximum  possible number  of  vehicles being
     tested at the same time.

     The System Controller  shall  be equipped with a modem to
     interface with the contractor's headquarters computer.
     The modem shall meet the  following minimum specifications:

     —    1200 baud digital telecommunications interface

     —    Auto-answer capability

•    The System Bulk Data Storage Device  shall consist of flexible
     magnetic disk (diskette or floppy disk) and  shall be controlled
     by the System Controller.  The System Bulk Storage  Device shall
     fulfill  the following  functions:

     -    A storage medium  for logging of events, facility
          maintenance data, and equipment calibration  data.

     —    A storage medium  for initial loading of the
          operating system  software.

     —    A storage medium for daily storage of inspection
          data which must be eventually forwarded to the
          Wisconsin Department of Transportation via the
          contractor's headquarters computer.

     —    A storage medium for online  storage of  data  re-
          quired to conduct the inspection process.

•    The Emission Measurement Subsystem shall perform  all emissions
     measurement and test control functions.  The EMS  consist of
     NDIR exhaust gas analysis equipment  as  specified  in draft
     rules, an exhaust gas sampling device,  and a control pendant.
     Tht- EMS shall control and monitor dynamometer loadings.   The
     EMS shall be controlled by the System Controller; in the event
     of System Controller  failures, the EMS  shall control the report
     printer(s).  One EMS  shall be required per  lane.
                                66

-------
     •    The EMS Control Processor (EMSCP) shall be a
          functionally independent modular component of the
          SYSTEM.  The EMSCP shall perform the following
          functions:

          —    Prompt and cue inspector during measurement.

          —    Convert raw analog measurement and status data
               to digital information.

          —    Perform necessary calculations.

          —    Correct measured instrument values including
               dynamometer speed and horsepower.

          —    Compare results to the State's emissions
               standards.

          —    Display emission values.

          —    Transmit data to the System Controller,  or
               the Inspections Report Printer during System
               Controller downtime.

Peripheral Equipment—
     The Vehicle Identification Terminal (VIT) shall be a Cathode  Ray Tube
(CRT) Terminal and keyboard.  The VIT shall meet  the following minimum
specifications:

     •    General characteristics

          —    Standard ASCII transmission keyboard
          —    Cursor control
          —    Clear, return, and tab functions

     •    Display functions

          —    Selected fields protection (System Controller  or EMS
               may "protect" certain data fields)

          —    Tab to unprotected fields

          —    Overstrike editing

          —    Cursor wraparound
                                    67

-------
     •    Two-way communication with System Controller

          —    Standard ASCII transmission code

          -    Full duplex,  RS-232C interface

          —    1000 baud minimum speed

     •    Display characteristics

          —    12-inch (diagonal) screen minimum

          —    64 displayable characters, at least 0.19 inch
               high by 0.125 inch wide

          —    5x7 dot matrix characters per line

          —    80 characters per line

          —    12 lines on full screen minimum

          —    Nondestructive cursor

     The Test Control Pendant shall serve as the interface between the inspector
and the EMS.   The Pendant shall consist of a computer type keyboard capable of
entering the  following commands into the EMS and/or the System Controller.

     •    Start test

     •    Abort test

     •    Restart test

     •    Delete one or more modes of the test

     •    Select mode

     •    Control dynamometer wheel lift

     The Test Display Panel  (TOP) shall assist the inspector in performing the
test.  The TDP shall prompt  the inspector with, but not limited to, the following
instructions  and display information.

     •    The measured road  speed.

     •    The horsepower applied to the vehicles driving
          wh e e1s .

     •    The mode of operation — high cruise, low cruise,
          or  idle.

     •    An  indication that the vehicle's road speed is not
          within the appropriate tolerance during the high
          cruise and/or low cruise modes.
                                      68

-------
     •    An indication that the EMS controller has determined
          that all the prerequisites for a valid emission test
          have been satisfied and the emission inspection is
          progressing properly.

     •    An indication that the test sequence is complete.

     4    An indication that the EMS is in semiautomatic mode
          (not communicating with the System Controller).

     •    An indication that a message has been printed on the
          control teleprinter.

     •    Exhaust gas sample dilutions.

     The Inspection Report Printer (IRP) shall print the inspection test results
and appropriate information.  The printer shall generate inspection reports on
8-1/2 by 11 inch report forms of the contractor's design but approved by the
State.  The Inspection Report Printer shall provide the following functions:

     •    Display characteristics

          —    Minimum of 64 ASCII displayable characters

          —    Minimum character size 0.19 inch high by
               0.11 inch wide

          —    Minimum 7x7 dot matrix characters (if
               applicable)

          —    Minimum 80 characters per line

          —    Minimum 30 characters per second print
               speed

          —    Capability of one original and two addi-
               tional copies

          —    ASCII transmission code

               RS-232C interface

The vehicle inspection report shall provide the information specified in
the draft rules.

     The Control Teleprinter shall provide operator communication with and
print messages from the System Controller.  The control Teleprinter shall
meet the following minimum specifications:
                                      69

-------
     •    Standard 64 ASCII  transmission character set

     •    Teletype format keyboard
     •    Thermal or impact  single copy printout

     •    Full Duplex mode
     •    30 characters per  second minimum print  speed

     •    80 characters minimum line length

Peripheral Equipment Interface—
     All SYSTEM peripheral equipment,  the EMS,  and the IRP shall interface with
the SYSTEM through industry  standard RS-232C interfacing.

Headquarters Computer System—
     The Contractor's Headquarters Computer System (HCS) must be capable of
supporting the following functions:

     •    Data collection and data entry for inspection
          and repair data.

     •    Data validation and compilation for monthly
          submission of  data to the Department of
          Transportation.

     •    Data analysis and  summarization for network
          operating management.

     •    Data management reporting.

     •    Network software maintenance.

The Headquarters Computer System (HCS) must be compatible  with the facility
System Controllers and shall be capable of supporting the  network information
processing and network communications capabilities required.  The HCS must be
capable of producing magnetic 1/2 inch wide, industry standard 9-track tapes
at 800 or 1600 bpi  in EBCDIC code (must be translated from ASCII).

     The contractor may propose any configuration for the Headquarter's com-
puter, but the computer should have as a minimum a System Teleprinter, online
interactive terminal(s), and a high-speed line printer, or any other configura-
tion enabling the contractor to generate the operating reports and data tapes
required for submission to the Department of Transportation.

     The HCS shall  provide for communication interface with the facility
System Controllers.  This shall be accomplished with  the following:
                                     70

-------
     •    1200 baud, asynchronous communication modem

     •    Automatic call-up function

     •    Bidirectional communication capability with
          all test facilities

General Design Requirements

     The SYSTEM shall be designed and constructed so as to comply with all
applicable OSHA requirements.

     All electrical systems and their installation shall comply with the
National Electric Code and any and all applicable State and/or local electrical
codes .

     Mechanical and electrical interchangeability shall exist between like
assemblies, components, and their replacement parts.

     Batteries shall not be incorporated in the design of any equipment (except
that batteries may be used to maintain semiconductor memory during power outages),

     Electronic enclosures shall provide dust-protective housing of sheltered
equipment.  Ventilating air flow shall be filtered.  The enclosures shall pro-
vide complete dust-protective housing of equipment.  Electronics Industries
Association (EIA) standards for enclosures shall be applied.

     Performance of equipment shall be protected from degradation by the
presence of interference signals which may be present at any facility.  It
shall be the contractor's responsibility to determine the degree of interference
control rcjquired at each site.  Equipment shall be prevented from generating
interference signals which will affect proper operation of any equipment in the
facility.

     Except as otherwise specified, equipment to be housed within the building
core equipment room shall be capable of operation as specified within an ambient
temperature range of 5° to 30°C.  Equipment to be operated in the inspection
lanes shall be capable of operating as specified within an ambient temperature
range of 0° to 45° C.

     All equipment shall be capable of operating as specified when exposed to
a relative humidity of 10 to 90 percent (noncondensing) for both continuous
and intermittent periods.

SYSTEM Software —
     The SYSTEM software shall consist of all necessary programs for the System
Controller which shall cause the SYSTEM to correctly perform all of the functions
specified  herein.

     All applications software written for use on the SYSTEM shall be prepared
using the  general programming approach known as "Structured Programming," to
achieve the basic goals listed below in order of importance:

                                     71

-------
     1.   Reliability
     2.   Modifiability
     3.   Understandability

     4.   Efficiency

     The proposal must address and include a proposed schedule for the software
development process, including monthly meetings with the Department of Trans-
portation during the design and development stages.  Bidders should be aware
that the selected contractor will eventually be required to provide full docu-
mentation of all software utilized in the vehicle inspection and data manage-
ment processes, including master block diagrams of the complete SYSTEM and
pneumatic and electrical schematics of the SYSTEM.

DEFINITIONS

     The RFI' should contain a section of definitions of the key and technical
terms used in the text.  The following terms were used in the model data pro-
cessing portion of the RFP.  In the final RFP, only one definitions section,
covering the entire RFP, should be included.

     Control Teleprinter
          Teletype device used to enter commands into or
          receive information from the System Controller.
     CRT
          Cathode Ray Tube, T.V. screen device associated
          with a computer terminal.
     EMS
          Emissions Measurement Subsystem of the SYSTEM
          including all equipment necessary to draw a gas
          sample, condition and analyze it, and transmit
          data to the SYSTEM.

     EMSCP
          Emissions Measurement Subsystem Control Processor.
          (Micro) processor controlling all functions of the
          EMS.

     Headquarters Computer

          Central computer system which receives, processes,
          and stores data from each individual facility computer.

     IRP

          Inspection report printer.
                                      72

-------
Modem

     Device enabling telecommunication between
     computer systems.

NDTR

     Nondispersive infrared gas analysis device.

SYSTEM

     All equipment hardware, peripheral hardware, and
     software used in the inspection process.

System Bulk Data Storage Device

     Magnetic disk, diskette, floppy disk, or other
     device used for bulk storage of vehicle inspection
     and SYSTEM maintenance data.

System Controller

     (Mini) computer used to control all SYSTEM functions
     and equipment.

Test Display Panel

     Device used to prompt inspector during the emissions
     test and display pertinent information to assist in
     test performance.

Test Control Pendant

     A data entry keyboard used to control the performance
     of the emissions test.
VTN
V1T
     Vehicle Identification Number;  a unique 13-character
     set of alpha-numeric characters used to identify a
     vehicle.
     Vehicle Identification Terminal.   CRT terminal used to
     enter vehicle registration information into the System
     Controller.
                                73

-------
                                 REFERENTS
 1.   Midurski,  T.P.,  L.A.  Coda,  P.O.  Phillips, N.K.  Roy,  P.M.  Sellars,  and
     T.P.  Synder.   Evaluation  of Motor  Vehicle Emissions  Inspection  and
     Maintenance Programs  in Wisconsin  — Phase II.   Prepared  for  U.S.
     Environmental  Protection  Agency  under  Contract  No,  68-02-2607,  Work
     Assignment No.  16.  GCA Corporation, GCA/Technology  Division, Bedford,
     Massachusetts.   EPA-905/2-78-003.   September  1978.

 2.   Midurski,  T.P.,  L.A.  Coda,  R.O.  Phillips, N.K.  Roy,  P.M.  Sellars,
     T.P.  Synder, and D.L.  Vlasak.  Evaluation of  Motor  Vehicle Emissions
     Inspection and  Maintenance  Programs in Wisconsin —  Phase III.   Prepared
     for U.S.  Environmental Protection  Agency under  Contract  No.  68-02-2607,
     Work  Assignment  No. 20.   GCA Corporation, GCA/Technology Division, Bedford,
     Massachusetts.   EPA-905/2-78-004.   November  1978.

 3.   Walker,  Terry  M.  Introduction to  Computer Science:   An  Interdisciplinary
     Approach.   Allyn and  Bacon,  Inc.  Boston, Massachusetts.   1972.   530  pp.

 4.   Dijkstra,  E,W.   Complexity  Controlled  by Hierarchical Ordering  of
     Function and Variability.  In Naur and Randell.   1968.

 5.   Dijkstra,  E.W.   Solution  of a Problem  in Concurrent  Programming Control.
     CACM  8,9:569.   1969.

 6.   Dijkstra,  E.W.   Structured  Programming.  In Buxton  and Randell.   1969.

 7.   Dijkstra,  E.W.   Notes on  Structured Programming. In Structured Pro-
     gramming.   O.J.  Dahl,  E.W.  Dijkstra, and C.A.R.  Hoare.   Academic Press.
     London.   1972.

 8.   Dijkstra,  E.W.   The Humble  Programmer. CACM  15,10:859-866.   1972.

 9.   Freeman,  P.  Software Systems Principles.  Science  Research  Associates.
     Chicago,  Illinois.   1975.  663 pp.

10.   Parnas,  D.L.   1972.   On the Criteria to be Used in  Decomposing  Systems
     into  Modules.   CACM  15,12:1053-1058.

11.   GoLlieb,  C.C.,  and A.  Borodin.  Social Issues in Computing.   Academic
     Press.   New York.   1973.  284 pp.
                                     74

-------
TECHNICAL REPORT DATA
(I'leasi- read ImUruclions on the reverse before completing}
1 HI I'OH I NO 2.
EPA-905/2- 79-006
J n r LF AND suorn LF
Data Processing Procedures and Equipment for the
Wisconsin Inspection and Maintenance Program
? AUFMonis)
Frederick M. Sellars Dominic Caracciolo Jr.
Michael W. Kozenko
9 PEHI-ORMING ORGANISATION NAME AND ADDRESS
GCA Corporation
GCA/Technology Division
Burlington Road
Bedford, MA 01730
1?. SPONSORING AOtNCY NAML AND ADDRESS
U.S. Environmental Protection Agency
Region V Office
Chicago, Illinois
3. RECIPIENT'S ACCESSION" NO.
5. REPORT DATE
6. PERFORMING ORGANIZATION CODE
8. PERFORMING ORGANIZATION REPORT NO.
GCA-TR-79-75-G
10. PROGRAM ELEMENT NO.
11. CONTRACT/GRANT NO.
68-02-2887, Task Order No.. 8
13. TYPE OF REPORT AND PERIOD COVERED
14. SPONSORING AGENCY CODE
10. SUPPLEMCNTARY NOTES
       The Wisconsin  Department of Transportation (WDOT)  and Department of Natural
  Resources (WDNR)  are currently involved in planning for the implementation of a
  motor vehicle  emissions  inspection and maintenance program.   Once operational,  the
  program will be  generating a considerable amount of data.   In addition to the obvious
  problem of handling and  analyzing this data,  any system developed must be easily
  integrated with  existing computer systems in  WDOT and WDNR.

       This document  defines the computer hardware specifications for emission testing
  installations  so  that needed data can  be readily collected,  stored, and transferred
  to WDOT systems.  In addition,  the required software systems and specifications that
  will  enable manipulation and analysis  of data either on the selected I/M contractor's
  central computer  or the  State's  system are identified.   Finally, a model data
  processing portion  of an I/M Request for Proposals (RFP) is provided.
". KEY WORDS AND DOCUMENT ANALYSIS
.1 DIHCHIPTORS
Automobile engines
Exhaust detection
Exhaust emissions
11 IJl', I HIHU riON STA Ft MF- NT
Unlimited distribution
b. IDENTIFIERS/OPEN ENDED TERMS
Inspection and Mainte-
nance
Data Management
Computer Requirements
19. SECURITY CLASS (This Report)
UNCLASSIFIED
20 SECURITY CLASS (This page)
UNCLASSIFIED
c. COSATI I'icld/CJroup

21. NO. OF PAGES
80
22. PRICE
EPA Form 2220-1 (9-73)
                                           75

-------