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
------- |