United States Air and Radiation EPA420-P-02-006
Environmental Protection October 2002
Agency
vxEPA Draft Design and
Implementation Plan for
EPA's Multi-Scale Motor
Vehicle and Equipment
Emission System (MOVES)
> Printed on Recycled Paper
-------
EPA420-P-02-006
October 2002
for
John Koupal, Mitch Cumberworth, Harvey Michaels, Megan Beardsley, David Brzezinski
Assessment and Standards Division
Office of Transportation and Air Quality
U.S. Environmental Protection Agency
NOTICE
This technical report does not necessarily represent final EPA. decisions or positions,
It is intended to present technical analysis of issues using data that are currently available.
The purpose in the release of such reports is to facilitate the exchange of
technical, information and to inform the public of technical developments which
may form the basis for a final EPA decision, position, or regulatory action.
-------
Table of Contents
Table of Contents i
List of Tables ii
List of Figures ii
1. Introduction 1
2. Use Cases 4
3. Overview of MOVES Design 7
3.1. Design Principles 8
3.2. Core Model and Implementations 11
4. Software Design Layers 12
4.1. Control 1: System Specifications 12
4.2. Control 2: Run Specification 13
4.3. Control 3: Monte Carlo Controller 13
4.4. Control 4: Master Loop 14
4.5. Application 1 and Database 1 14
4.6. Utilities 16
4.7. Database 2 16
4.8. Application 2 and Database 3 16
5. Data Flow Design 17
5.1. The Core Model and Output Processing 18
5.2. The Master Generator Loop, Internal Emission Control Strategies, and Data
Generators 21
5.3. The User Interface 25
6. MOVES Databases 29
6.1. Input Databases 29
6.2. Execution Databases 31
6.3. Output Database 31
7. Mathematical Formulation and Data Inputs 33
7.1. On-Road Implementation 35
7.2. Off-Road Implementation 55
8. Software Implementation 57
8.1. Software Development Methods Chosen for MOVES 58
8.2. Software Development Tools Selected for MOVES 58
8.3. Distributed Processing 60
References 60
Appendix A. MOVES GUI Details (separate document)
Appendix B. MOVES output Database Design (separate document)
-------
List of Tables
Table 2-1. MOVES Use Cases 5
Table 3-1. MOVES Emission Processes 7
Table 3-2. Total Activity Basis by Process 9
Table 3-3. Example Source and Operating Mode Bin 10
Table 4-1: MOVES Software Design Layers 12
Table 7-1: Implementations Proposed for MOVES 34
Table 7-2: Proposed MOVES On-Road Vehicle Classification Scheme 37
Table 7-3: Overview of Total Activity Generator (TAG) Steps 39
Table 7-4: Operating Mode Parameters By Emission Process 51
Table 7-5: Proposed VSP Bin Definitions 52
Table 7-6: Overview of Operating Mode Distribution Generation For VSP 53
Table 7-7: Level of Disaggregation for Soak Time and Time Since Start 55
List of Figures
Figure 5-1. Data Flow Design: MOVES Core Model 18
Figure 5-2. Data Flow Diagram: MOVES Master Generator Loop, Internal Emission Control
Strategies, and Data Generators 23
Figure 5-3. Data Flow Diagram: MOVES User Interface 26
Figure 6-1. MOVES Output Database Design 32
11
-------
1. Introduction
The Clean Air Act requires EPA to develop and regularly update emission factors for all
emission sources. Pursuant to this charge, EPA's Office of Transportation and Air Quality
(OTAQ) has developed a number of emission and emission factor estimation tools for mobile
sources, including MOBILE (for highway vehicles) and NONROAD (for off-road mobile source
pollutants). EPA is proposing to update these tools with the Multi-Scale Motor Vehicle and
Equipment Emission System (MOVES), which is intended to include and improve upon the
capability of these tools and, eventually, to replace them with a single, comprehensive modeling
system.
The National Research Council (NRC) published a thorough review of EPA's mobile
source modeling program in 2000.l The NRC provided several recommendations for improving
EPA's mobile source modeling tools, including (a) the development of a modeling system more
capable of supporting smaller-scale analyses; (b) improved characterization of emissions from
high-emitting vehicles, heavy-duty vehicles, and off-road sources; (c) improved characterization
of particulate matter and toxic emissions; (d) improved model evaluation and uncertainty
assessments; and (e) a long-term planning effort coordinated with other governmental entities
engaged in emissions modeling.
A particular focus of the NRC report was the need to provide emission factors and tools
that will allow the estimation of emissions at finer analysis scales. Historically, EPA's mobile
source emission estimation tools and underlying emission factors have been focused on the
estimation of mobile source emissions based on average operating characteristics over broad
geographical areas. Examples of this scale of analysis are the development of SIP inventories for
urban nonattainment areas and the estimation of nationwide emissions to assess overall trends.
In recent years, however, analysis needs have expanded in response to statutory requirements that
demand the development of finer-scale modeling approaches to support more localized emission
assessments. Examples include "hot-spot" analyses for transportation conformity and evaluation
of the impact of specific changes in transportation systems (e.g., signalization and lane additions)
on emissions.
We have adopted most of the NRC's recommendations as our objectives in designing
MOVES. The MOVES design objectives include:
applicability to a wide range of spatial and temporal scales,
inclusion of all mobile sources and all pollutants,
addressing model validation and the calculation of uncertainty,
ease of updating the model,
quality assurance,
ability to interface with other models, and
ease of use.
These objectives have shaped our development plan for MOVES, as detailed in the rest of this
paper.
1
-------
We have begun and will continue to develop MOVES with extensive coordination and
outreach. A cross-agency team representing OTAQ, the Office of Air Quality Planning and
Standards (OAQPS), the Office of Research and Development (ORD), and Regional EPA offices
produced an issue paper containing an initial proposal for the model in April 2001.2 Since then,
we have coordinated with states, metropolitan planning organizations, the U.S. Department of
Transportation, consultants, academics, and the "FACA Modeling Workgroup", which is the
Modeling Workgroup of the Mobile Source Technical Review Subcommittee (MSTRS) of the
Clean Air Act Scientific Advisory Committee (CAAS AC), a committee of experts from
government, industry, and academia established under the Federal Advisory Committee Act
(FACA). This continuing coordination will enable MOVES to benefit from advances in mobile
source emission modeling and to meet the needs of the user and stakeholder community.
This report presents the proposed MOVES design and implementation plan and includes
our analysis of "use cases," the design and implementation plan proposed to meet these use
cases, specific mathematical formulations and data input requirements to implement this design,
and software choices which are proposed to implement the design. The MOVES design is
centered on the three primary components of mobile source emission modeling: characterizing
the fleet, characterizing the fleet's activity, and characterizing the emissions associated with that
activity. Detailed design aspects for the fleet and activity components are presented in this
document, primarily in the mathematical formulations presented in Section 7. The
characterization of emissions is discussed only generally in this document, with our detailed
proposal for this element to be published as a separate report by the end of 2002.
The current implementation schedule for MOVES is to first release a greenhouse gas
implementation for on-road sources in 2003, termed MOVES GHG. The first iteration of
MOVES GHG would support development of national inventories and projections at the county-
level for Fuel Consumption, CO2, N2O, and CH4, by Fall 2003. A second iteration would add
future projections, policy evaluation capabilities, and the ability to account for "life-cycle" (i.e.,
well-to-pump) effects in the estimate of emissions, by the end of 2003. A third iteration would
add local inventory (roadway link/traffic zone) analysis capability by mid-2004.
MOVES GHG will serve important needs within EPA and in the model user community.
A comprehensive model that allows bottom-up estimation of greenhouse gas emissions from on-
road sources is currently not available and Intergovernmental Panel on Climate Change
guidelines recommend the development of such a model.3 It will also give the broader user
community an opportunity to work with MOVES while the full-scale version of the model is
developed. Choosing a greenhouse gas model as the first implementation of MOVES allows us
to start with a small scope relative to all of the considerations that go into modeling of ozone-
precursor and criteria pollutants. For example, the model will not need to address evaporative
emissions or implement finer scale emission analysis.
The next phase in implementing MOVES, planned for Fall 2005, would add HC, CO,
NOx, SO2, PM, NH3, and air toxics for on-road sources and would allow the estimation of
emissions at all analysis scales. This implementation would replace the current MOBILE6
-------
model. The time between MOVES GHG and the full MOVES implementation would be focused
on the development of emission algorithms for these pollutants, since the software aspects of the
model will have been significantly developed for the greenhouse gas implementation.
In order to manage the scope of the project, new estimates of off-road emissions would
not be integrated into MOVES until after the on-road implementations were developed. Prior to
the development of new estimates for off-road emissions, we are considering integrating the
NONROAD model into the MOVES framework in conjunction with the on-road releases. This
would allow the estimation of emissions from all mobile sources within one modeling system, an
important objective of MOVES.
-------
2. Use Cases
The preparation of use cases is a necessary first step in software design and follows from
a basic assessment of model needs. In developing a design for MOVES, we first assessed the
many ways in which the model would be used, informed by the NRC report and interviews with
subject-matter experts. With the help of a contractor (MCNC), we interviewed expert users for
each use case. In addition to this formal interviewing process, we also consulted closely with
researchers and users within EPA's Office or Research and Development (ORD) and Office of
Air Quality Planning and Standards (OAQPS), as well as with the FACA Modeling Workgroup,
comprised of experts from industry, academia, government, and consulting firms. From this
assessment we developed a list of essential use cases, which explore, at a high level and
independent of particular programming languages and hardware, how users need to or would like
to use the software.
The result of this analysis was a list of fundamental use cases which have driven the
MOVES design. Table 2-1 lists the use cases together with the subject matter experts
interviewed on these areas.
In addition to these broad model purposes, through consultation with model users we also
addressed use cases from the perspective of user interaction:
A powerful and versatile GUI and a batch, command-line interface.
Flexibility of input and output formats.
Multiple options for output processing
Ease of comparison of results from multiple model runs
Ease of transition from MOBILE/NONRO AD to MOVES
These reflect overarching design considerations that have been considered in the development of
a design which serves the broad purposes listed in Table 2-1.
An important, but difficult-to-define, aspect of use cases is performance specification.
All users would like the software to run as quickly as possible. County-level national inventories
currently take weeks to run and process, including time-saving short cuts such as representing all
U.S. counties by 175 representative counties and representing a month by a single day.
Similarly, air quality simulations require hourly emissions values for thousands of grid cells over
several to tens of days, so current mobile source modeling efforts require similar approximations
to be able to complete execution within weeks. Because national inventories and gridded air
quality simulations are major undertakings, inventory preparation requiring a few weeks is
acceptable. A time requirement longer than roughly a month would not be acceptable. In current
practice, compromises and approximations such as previously described are used to assure timely
results. While model execution times of weeks are acceptable for these demanding applications,
shorter times and less approximation are always desirable. The ability to quickly evaluate
alternative control scenarios (say, in an hour to a day) would aid in the development of rule
makings and control strategies.
-------
Table 2-1. MOVES Use Cases
Use Cases
Experts Consulted
National inventory development for EPA reports and
regulations
National Emissions Inventory (NEI)
Inventory of U.S. Greenhouse Gas Sources
and Sinks
International Reporting
Regulatory analyses
Alison Pollack, Environ Corporation
Greg Stella, EPA/OAQPS
Local inventory development
SIP development
Conformity
NEI input
Trading programs
Kip Billings, Wasatch Front Regional
Council (Salt Lake MPO)
Mike Keenan, New York State
Department of Environmental
Conservation
Mohammed Khan, Md. Dept. of Env.
Mark Janssen, LADCO
Alison Pollack, Environ Corporation
Hot-spot and project level analysis
PM and CO Conformity
Toxic exposure analysis
Harold Nudelman, New York City
Department of Environmental Protection
Alan Huber, EPA/ORD
Model interaction
Air Quality Pre-Processors
Travel Models
1. Travel Demand Models
2. Microscopic Models
3. TRANSIMS
Dispersion Models
Mark Janssen, LADCO
Rob Ireson, Consultant
Rick Dowling, Consultant
Matt Earth, UC Riverside
Fred Ducca, US DOT
Bruce Spear, US DOT
Greg Stella, EPA/OAQPS
Alan Huber, EPA/ORD
Policy evaluation
Cleaner vehicles and equipment
Cleaner fuels
Less travel and equipment use
Reducing in-use emissions
Modifying vehicle and equipment operation
Alison Pollack, Environ Corporation
David Korotney, EPA/OTAQ
Ken Adler, EPA/OTAQ
Roger Gorham, EPA/OTAQ
Model Analysis
Validation
Uncertainty analysis
Sensitivity
Alison Pollack, Environ Corporation
Mark Janssen, LADCO
Model updates and expansion
-------
We intend to develop MOVES in an iterative fashion. The earliest releases of the model
will focus on the most important use cases, as reflected in our implementation plan discussed
previously. In keeping with our iterative paradigm of software development, we do not consider
the use case issue closed. We feel that we have obtained a good overview, but we expect
refinements, additions, and, perhaps, removals as we proceed with model development.
-------
3. Overview of MOVES Design
The MOVES design is modular, general purpose, data driven, easy-to-use, and high
performance. All emission scales and processes are incorporated into a flexible framework of
time spans and locations. The MOVES design provides several means of modeling the effects of
emission controls. MOVES emission rates and activity information are derived from databases,
easily updated as needed.
Understanding MOVES requires learning some new terms or new definitions for existing
terms. The term source is used to encompass both on-road vehicles and off-road equipment
pieces. A source use type is a specific class of on-road vehicles or off-road equipment defined by
unique activity patterns. Source bins are a subset of use types: subcategories that differentiate
emission levels within a use type, covering categorizations such as weight class, fuel type,
technology, standard, horsepower range, etc. Total activity is defined for a given use type as the
product of the population of that use type and the per-source activity by time and location. We
subdivide total activity into categories that differentiate emissions, known as operating mode
bins; the intersection of source bins and operating mode bins results in a unique source and
operating mode bin. By emission rates, we mean the most disaggregated rates the model
produces internally by source and operating mode bins. By emission factors, we mean emission
rates aggregated in various ways over source and/or operating mode bin and normalized by some
activity basis, such as mass of pollutant per time or per mile.
An emission process is a unique emissions pathway. The proposed emission processes for
MOVES are shown in Table 3-1. These processes are being defined the same as in MOBILE6
and NONROAD, except that resting loss emissions would now include estimates of offgassing,
or hydrocarbons escaping from car materials such as upholstery.
Table 3-1. MOVES Emission Processes
Combustion Products
Running Exhaust
Start Exhaust
Crankcase
Hydrocarbon Evaporation
Diurnal
Hot Soak
Resting Loss
Running Loss
Refueling
Other
Brake Wear
Tire Wear
These emission processes are generally associated with different source bins and
operating modes and they may also produce different pollutants. Therefore, each emission
process is generally handled separately from the others, using common data when appropriate.
From a design perspective, this separation creates several submodels within the model. For
example, running exhaust emissions are affected by a different set of fleet and activity
characteristics than are diurnal evaporative emissions.
-------
Three basic analysis scales are defined for MOVES, following from the NRC report and
the April 2001 issue paper. Macroscale analyses are appropriate for developing large-scale (e.g.,
national) inventories, for which the basic spatial unit would be the county. Mesoscale analyses
are appropriate for generating local inventories at a finer level of spatial and temporal resolution.
For on-road vehicles, mesoscale analyses would use as spatial units roadway links and traffic
analysis zones or would use vehicle trips consistent with output from standard travel demand
models. Microscale analyses allow the estimation of emissions for specific corridors and/or
intersections, which is appropriate for assessing the impact of transportation control measures
and for performing project-level analyses. For off-road equipment, the appropriate spatial and
activity units for mesoscale and microscale analyses have not been fully delineated, but would
likely be sub-county units of some sort for mesoscale and specific locations for microscale.
3.1. Design Principles
The proposed MOVES design has been developed to address each of the use cases listed
in Table 2-1. This section provides an overview of the general design for the MOVES model
and the rationale for these design decisions.
We have established two fundamental design principles, which have guided the
development of the MOVES design, as follows:
The model design needs to be flexible enough to accommodate the calculation of
emissions from a wide variety of emission sources (e.g., on-road and off-road), over
multiple scales, and multiple emission processes using a similar design framework.
The model must be developed in a modular way to allow ease of update.
These two principles have led to a design that provides a generic framework for addressing the
first principle and is implemented in a modular and transparent fashion to address the second
principle.
To address the first principle, a generic framework has been developed which provides
significant flexibility for applying the model across emission source, scale, and process. The
basic concept of this generic framework is the following: for a given time, location, use type and
emission process, total emissions can be calculated by the following four steps:
1. Calculate the Total Activity, expressed in units of the activity basis (explained in
following section) for the given emission process.
2. Distribute the total activity into Source and Operating Mode Bins, which are
defined as having unique emissions for that emission process.
3. Calculate an Emission Rate2 which characterizes emissions for a given process,
source bin, and operating mode bin and which accounts for additional effects such as
fuel and meteorology.
4. Aggregate emission rates across these modes using the source bin and operating
mode distribution from Step 2.
-------
These steps are characterized mathematically as follows:
Number of Bins
,,7yPe = TotalActivityu,ayPeX
n=\
In this equation, bin refers to source and operating mode bin. Each of these elements is
elaborated below.
3.1.1. Total Activity
For a given use type, time, and location, total activity is the product of population and
per-source activity. How activity is defined will depend on the emission process being modeled.
For most processes, we propose to characterize total activity by source-time; i.e., source hours
operating (SHO) or source hours parked (SHP). Source-time is the product of the population of
vehicles/equipment and the analysis time span. Source-time is an attractive way of
characterizing activity, because it is common to all emission processes and operating modes. For
on-road sources, source-time is more broadly applicable than the more conventional Source
Miles Traveled (VMT), since diurnal or idle emissions are produced when a source is not
moving. For non-transportation equipment, such as bulldozers and cranes, SHO and SHP can be
applied as with on-road sources, while VMT cannot. It is important to note, however, that this
use of source-time mainly applies to the calculation of emissions within MOVES and does not
preclude the use of VMT to express the activity of on-highway sources, since SHO and VMT are
easily inter-convertible if average speed is known. The model design accepts a wide variety of
inputs, including VMT, and produces a wide variety of outputs, including emission factors in
grams/mile. Section 7 on mathematical formulation provides more detail on this approach.
Some processes have total activity for which non-time based activities are more directly
estimated. Specifically, start exhaust will use number of starts per time and location as the total
activity basis, and source refueling will use gallons of fuel burned. The total activity basis
proposed for each process is shown in Table 3-2.
Table 3-2. Total Activity Basis by Process
Emission Process
Running Exhaust, Brake Wear, Tire Wear, Running Loss,
Crankcase
Start Exhaust
Diurnal, Hot Soak
Resting Loss
Refueling
Total Activity Basis
Source Hours Operating (SHO)
Number of Starts
Source Hours Parked (SHP)
Source Hours (SH)
Gallons of Fuel Used
-------
3.1.2. Source and Operating Mode Bins
MOVES differs from the previous MOBILE series of models in that it is explicitly
designed to use the same set of emission rates at a very large scale (such as national-level
inventories) and at a very small scale (such as intersection modeling). It also combines into a
single modeling framework the ability to generate (1) emissions for a wide range of pollutants
and processes and (2) emissions from both on-road and off-road vehicles and equipment.
To handle this diversity of use, and to enable ease of updates, we propose that MOVES
store emission rates as average emissions within discrete source and operating mode bins. Each
discrete bin will be dictated by factors that are found to result in unique emissions, based on
subcharacteristics of the use type and operating modes. Parameters which define source bins
could be based on fuel type, accumulated use (which accounts for deterioration), source weight
(on-road), horsepower range (off-road), technology types, and standard levels. The concept of
source bin is similar to methods used to distinguish emission rates in MOBILE or NONROAD.
One key difference to note is that accounting for vehicle mileage using the bin concept is a
departure from the traditional use of a continuous deterioration rate correction factor. This new
approach to addressing vehicle mileage has been employed in UC Riverside's Comprehensive
Modal Emission Model.4
Examples of source and operating mode bins are shown in Table 3-3. A broader range of
the on-road use types and source bins are presented in Section 7.
Table 3-3. Example Source and Operating Mode Bin
Use Type
Passenger Car
Type of Bin
Source Bin
Operating
Mode Bin
Bin Parameters
Fuel Type
Mileage
Technology
Standard
Emitter Category
Power Bin
Example
Gasoline
High
Fuel Injection/3 -Way Catalyst
Tier 1
Normal
Vehicle Specific Power =13 to 16 kW/ton
To facilitate the calculation of model uncertainty, we propose that each source and
operating mode bin would contain a mean value and either the distribution of uncertainty around
the mean or the variability of the entire sample used to generate the mean. This approach will
allow the calculation of uncertainty in model prediction using either propagation of error or
Monte-Carlo analysis techniques. This will be discussed in more detail in a separate report
detailing the proposed emission analysis method for MOVES.
10
-------
3.2. Core Model and Implementations
Two basic components of the MOVES design have evolved from the generic framework:
the core model and implementations. The core model would perform the four-step calculation
outlined in the previous section for the times and locations being modeled, resulting in outputs of
emission factors and total emissions. At the heart of the core model is the emission calculation
function, a large part of this function being a direct database lookup of emission rates by source
and operating mode bin.
We refer to the "implementations" as the body of applications, controls, and utilities that
would use the core model to address many of the use cases presented in Table 2-1. For example,
macroscale inventory generation would operate the core model in conjunction with a database of
fleet and activity information and front-end applications, which produce necessary core model
inputs from these data. Uncertainty analysis using Monte Carlo simulation would require a
module that would iterate the core model many times, while populating the input parameters with
random samples from the distributions of their means and, then, analyze the combined outputs to
produce uncertainty estimates.
Fundamental to the implementations is the concept of "data generators," which would
convert data from a multitude of sources to the standard input form acceptable to the core model.
For each emission process, the core model would be developed to use a standard input form for
total activity and operating mode distributions regardless of analysis scale or the ultimate source
of that information. It is envisioned that we would develop data generators for MOVES to
support essential use cases, while parties other than EPA, using standard interfaces in MOVES,
would develop other generators.
The rest of this document provides more detail about the core model and implementations
that make up the MOVES design. Sections 4, 5, and 6 offer specific perspectives of the design:
software design layers, data flow design, and database design. Section 7 looks at specific
mathematical formulations and data inputs for the proposed MOVES implementations. Section 8
offers information about the specific software tools and techniques involved in creating and
operating MOVES.
11
-------
4. Software Design Layers
The MOVES Software Design Layers are shown in Table 4-1 and provide a view of
MOVES software structure. The layered structure is described in more detail in the subsequent
text.
Table 4-1: MOVES Software Design Layers
Layer
Control 1
Control 2
Control 3
Control 4
Application 1
Database 1
Utilities
Database 2
Application 2
Database 3
Components
System Specifications
Run Specification
Monte Carlo Controller
Master Loop
Input
Data Manager
Data Importers
Control Strategies
Data Generators
Input Databases
Execution Location
Database
Emission Rate Database
Core
Core Model
Execution Emission
Rate Database
Output
Output Aggregator
OLAP Reporter
Exporters
Output Database
Examples: Visualization Tools, DBMS Tools, Data Browser, API, MIMS utilities
Archived runs: runs specs and output databases for later comparisons
Data Crank
Supporting Data for Data Crank
4.1. Control 1: System Specifications
The system specifications describe the operating environment for one or more MOVES
runs. These include a specification of whether or not distributed processing (distributing the
model execution over multiple computers, discussed in Section 8.3) is being used and, if so,
identification of computers involved in distributed processing and directories for shared files.
12
-------
4.2. Control 2: Run Specification
The Run Specification, or Run Spec, is the next highest control and specification layer in
MOVES. It is both a set of user inputs that define a model run and a piece of code that produces
the inputs and initiates lower levels of control. It is usually produced and modified with a
graphical user interface (GUI), as explained in Section 5.3. The User Interface.
The Run Spec defines the situation that MOVES will model, including pollutants,
emission processes, location and time period, source use types, and emission control strategies.
It also allows the user to define the scale of the analysis and to identify alternate sources for input
data. It defines the level of detail to be included in the MOVES output and allows the user to
specify if a Monte Carlo uncertainty analysis is desired. The Run Spec initiates the Monte Carlo
Controller and Master Loop (Control Layers 3 and 4).
The Run Spec data will be stored as a binary file. The input portion of the Run Spec may
be edited with a graphical user interface, as mentioned above, or it may be created or edited in
extensible markup language (XML) by an external program. The GUI will make the model
relatively easy to use, even for beginning modelers, while the XML option will allow
sophisticated users to batch process multiple runs and to link MOVES into a broader system of
transportation and air quality models.
4.3. Control 3: Monte Carlo Controller
An important element of MOVES will be the quantification, where possible, of model
uncertainty. As described in Section 3.1.2, we propose to characterize emission rates as
distributions. One way to implement the calculation of uncertainty would be through the use of
Monte Carlo analysis. This would require the development of a utility in MOVES that would
apply Monte Carlo analysis to generate emission-based uncertainty estimates of model results.
The Run Spec would allow the user to choose a Monte Carlo analysis and to specify the number
of iterations and simulations per iteration. The Monte Carlo Controller would then run the model
through the required numbers of repeat emission estimates, selecting appropriate emission rates
from the emission rate distribution.
In the future, this approach could be extended to estimate other sources of uncertainty in
the model results. Probability distributions for activity estimates, meteorology, and other
parameters may be added later if information is available. The importance of these other factors,
especially activity, in emissions estimates argues for their eventual inclusion in model output
uncertainty calculations.
One disadvantage of using a Monte Carlo approach to calculate uncertainty is that we
expect Monte Carlo runs to take a significant amount of processing time. Since we expect these
runs to be performed primarily for diagnostic and assessment purposes, they will be relatively
infrequent and generally performed only by users with relatively sophisticated computing
resources. Consequently, the processing time will be acceptable.
13
-------
Other approaches to estimating uncertainty include non-numerical methods involving
properties of the mean and variance, transformation of variables, and Taylor series expansions.5
These methods have the advantage of not requiring large numbers of iterations. They have the
disadvantage of being only approximate, especially in cases where the uncertainty or is large, the
distributions are unusual, or the supporting data are limited.
If a non-numerical method of error propagation were employed, the Monte Carlo
controller would not be required in MOVES, and the calculation of uncertainty would take
significantly less time. The feasibility of each approach is being considered as part of the
emission analysis evaluation.
4.4. Control 4: Master Loop
MOVES users will often desire results for multiple times, locations, and emission
processes. And, even when consolidated reporting is desired, more precise results can generally
be obtained by calculating results from smaller areas, time periods, and sub-processes and, then,
summing them. Thus, a basic function of MOVES will be looping over all the times, locations,
and processes defined in the Run Spec. The Master Loop code will control this looping in the
underlying application layers of the model.
4.5. Application 1 and Database 1
Two basic components of the MOVES design that have evolved from the generic
framework are the core model and the implementations, as explained in Section 3.3. The core
model is to be as generic as possible. It will accept inputs of (a) total activity, (b) source bin
distributions, (c) operating mode distributions, (d) meteorological information, and (e) fuel
information. It will look up emission rates from a database. It will output emission factors and
total emissions.
The implementations will incorporate the core model, as well as pre- and post-processors
that handle inputs and outputs. This enhanced system will allow the generic core model to
perform various specified use cases.
The following describes in more detail the input, core, and output functions, as well as the
data on which each function acts.
4.5.1. Input
MOVES users will come to the model with a wide range of inputs, ranging from none
(defaults only) to detailed information on meteorology, fuel composition, source activity, source
populations, etc. In general, both default data and user data will be stored in Input Databases in
specified database formats. To maximize flexibility in the use of MOVES, a major task for the
MOVES model is selecting and /or generating the appropriate core model inputs from the user
inputs and model defaults.
14
-------
The Data Manager has primary responsibility for sorting through the available user
inputs and default values to choose the appropriate values for the time/location/process indicated
by the Run Spec and Master Loop. These are fed into the Execution Location Database. The
Data Manager may also replace MOVES default emission rates from the Emission Rate
Database with user inputs. These are stored in the Execution Emission Rate Database.
The Data Manager works only with data in very specific MOVES input formats. In many
cases it will be the user's responsibility to develop inputs in the correct format. However, to
accommodate specific use cases, we plan to develop a set of Importers that will translate data
from other well-defined formats into acceptable MOVES inputs. Other parties could develop
additional importers as desired.
Many MOVES use cases involve modeling the world with and without various emissions
control strategies. In some cases, such as an entirely new idea for emissions control, these
control strategies and their effects will be defined entirely by the user in the user inputs. We refer
to these as External Control Strategies. However, some control strategies are quite common and-
-to meet the need for ease of useMOVES will have some Internal Control Strategies. That is,
MOVES will include processors that use user data on control strategy parameters to modify data
in the Execution Location Database (ELD) and the Execution Emission Rate Database (EERD)
to account for these programs. When complete, MOVES will include four basic types of internal
control strategies: fuel programs, emission standards, inspection/maintenance programs, and
controls of fleet population and activity.
Generally, the inputs commonly available will not exactly match that needed by the core
model. In some cases, this data will need to be filtered to select only the information needed by
the core model for a specific run. In other cases, the data will need to be grown in time, allocated
in space or time, or otherwise adjusted to provide the level of detail needed by the core model.
These processes will take place in Generators specific to the kind of data being processed.
Separate generators will exist for meteorological data, fuel data, operating modes, technology and
standards and total activity.
4.5.2. Core Model
The core model is designed to provide estimates of total emissions, as well as emission
factors. The core model will look up appropriate emission rates for each source and operating
mode bin and apply corrections to account for conditions not in the database: for example,
adjustments to account for local fuel and meteorological conditions.
The core model will use structured query language (SQL) to define the relevant source
and operating mode combinations (bins) to apply the emission rates and appropriate correction
factors. With distributed processing, the SQL look-ups and calculations may be performed on
remote computers.
15
-------
4.5.3. Output
The Output Aggregator sums emissions across bins into larger groupings that can be
stored in an Output Database. The Output Database is in a form to be manipulated by the
relational database software in the model into the specific data format requested in the Run Spec.
The output table(s) may then be further processed by the user with an Online Analytical
Processing (OLAP) tool.
For specific implementations of the model, we also will develop Exporters that process
the MOVES output into the formats needed for common post-processors such as the EPA's
SMOKE model.
4.6. Utilities
We expect that much of the processing required at the Application 1 layer will make use
of utility software including visualization tools, Database Management Software (DBMS) tools,
data browsers, and utilities from EPA's Multimedia Integrated Modeling System (MIMS).
4.7. Database 2
Many of the MOVES use cases require comparisons between runs of the model under
different conditions. To facilitate this, MOVES will create a database of archived runs, linking
the inputs defined in the Runs Specs and the output stored in the output database.
4.8. Application 2 and Database 3
An important use case for MOVES is frequent and easy updating. As data becomes
available and as resources permit, we will need to update default data. This function will be
outside of MOVES, but is important to consider in the design of the system. We plan to develop
a standard algorithm for updating defaults to reflect new data, and to automate them as much as
possible. We call this set of standard algorithms the Data Crank. One application of the Data
Crank under consideration is the use of a physically-based emission model, which would be
updated with raw emission data and used to populate the bins in the Emission Rate Database.
Systematic storage of underlying data, through the Mobile Source Observation Database
(MSOD) and other tools, will also be an important part of the MOVES system.
16
-------
5. Data Flow Design
The MOVES design is modular, general purpose, data driven, easy-to-use, and high
performance. The core model design applies to all emission scales and processes and
incorporates a flexible framework of time spans and locations. It is also designed to facilitate
rapid execution, given the many combinations it must process. This core model (which may be
used directly by providing Core Model Input Data to the Input Data Manager) is preceded by
several processing stages which make it progressively more easy to use. These components
provide a graphical interface and means of accepting a variety of input data in the forms actually
available to users. The MOVES design provides several means of modeling the effects of
emission controls. MOVES emission rates and activity information are derived from databases
during model execution. These databases may be updated as new information becomes available
to users and to developers of the model.
This section presents the MOVES software design in terms of its data flow. It extends
the discussion of the software design layers in Section 4 by going into greater detail regarding
MOVES data and processing elements and the order in which these elements are executed. We
break this discussion into three sections: Core Model, Implementations, and User Interface. The
first two were defined in Section 3. The data and process flow diagrams discussed in this section
focus on the Application 1 and Database 1 software layers presented in Section 4, while also
including Control Layer elements, such as the Run Specification. The design presented here
applies to all modeling scales and all emission processes.
Data flow diagram sections are explained, beginning with one for the core model, which
produces emission results in a generic format. Subsequent diagram sections show the earlier
processing stages usually necessary to prepare data for the core model.
Some relatively standard conventions used in these diagrams are:
Parallelogram symbols represent data in a directly accessible form; e.g., in memory.
Cylinders represent databases.
Rectangles open on the right side represent relatively simple data storage elements.
Round-cornered rectangles represent processes that operate on data, generally
producing further data.
Square boxes represent external interfaces to the system.
Solid line arrows represent data flow.
Dashed line arrows represent control flow (if separate from data flow).
Some special conventions used in these diagrams are:
Diagram elements shaded gray are produced by previous processing stages.
17
-------
Diagram elements with a gray shadow may have different versions for different
emission processes (tailpipe running exhaust, start, HC diurnal evaporation, etc.).
The "RTC" notation on a data flow arrow means that the process producing the data
flow "runs to completion" before any of the data is processed by the subsequent step.
5.1. The Core Model and Output Processing
A data flow diagram for the Core MOVES Model is shown in Figure 5-1. It is the most
generic part of MOVES. Because much of the core model will be implemented with a Relational
Database Management System (RDBMS) in a fashion which supports distributed processing, this
diagram is more a conceptual representation than a literal one.
Emission Rate
Calculation
Including
"Adjustments"
Figure 5-1. Data Flow Design: MOVES Core Model
18
-------
5.1.1. Core Model Input Data
Input data for the core model is represented by the five parallelograms on the left hand
side of Figure 5-1. Because of the volume of information involved, at any one time during
program execution, data being processed may include only a portion of the times, emission
processes, and locations being modeled, as determined in a flexible manner by the Master
Generator Loop (described later in this section). This Core Model Input Data includes:
Fuel parameter information for the available supply of fuel by time, location, and kind
of fuel (e.g., gasoline, diesel, natural gas, etc.).
Meteorology information (temperature, humidity, solar load, etc.) by time and
location.
Total Activity by source use type, time, location, and (for some processes) roadway
type. The activity basis can depend on the emission process, as presented in Table 3-
2.
Operating mode distributions by source use type, time, location, and (for some
processes) roadway type. These distributions subdivide total activity by operating
mode. The activity basis and set of modes used may depend upon the emission
process; e.g., modes for exhaust running emissions are likely to be vehicle specific
power bins, while for hot soak emissions they are likely to be soak time bins.
Source bins distributions for each source use type. These allow the core model to
separate the Total Activity of each use type into the source bins necessary to estimate
emissions. These distributions vary by model year and, thus, the age of the source,
but are assumed not to vary by location and not to vary otherwise with time.
One way to use MOVES is to simply input into the model this Core Model Input Data,
along with corresponding emission rate information (which corresponds to default emission rate
information built into MOVES). This method would provide ultimate flexibility to the user for
modeling any case for which the required input data was available, from parking lots to entire
nations. However, we envision that most users will not use MOVES in this way, because the
data requirements are so high; hence, the concept of "implementations" has been developed
based on input of more commonly available data, as discussed in Section 7.
Our goal is to keep the core model as general purpose as possible. Core model
procedures must know which activity basis and set of operating modes apply to their emission
process, but they do not need to know what the different kinds of sources, kinds of fuel,
technology types, locations, operating modes, etc., represent. An operating mode might be a
source power bin or soak time prior to start. Some processes; e.g., crankcase emissions, may
not need operating modes at all.
The core model, beginning with the Total Activity Allocator, is designed to be
implemented primarily in relational database management software in a potentially distributed
fashion. This means that the Total Activity Allocator, Source and Operating Mode Bins, and
Emission Rate Calculator are logical entities whose physical implementation may assume a
19
-------
different form. The Source and Operating Mode Bins, for example, may never actually be
physically produced, but the results will be the same as if they were.
5.1.2. Total Activity Allocator
The Total Activity Allocator applies the Source Bin Distributions and the Operating Mode
Distributions (which do not interact with each other) to the Total Activity Information to produce
very detailed "Activity by Source and Operating Mode Bins," within a given source use type.
5.1.3. Emission Rate Calculator
The Emission Rate Calculator is a logically separate process, which removes Source and
Operating Mode Bins from their pool as it determines emission results for them. The Emission
Rate Calculator has access to a large database of emission rates, information about the
meteorology and fuel supply applicable to the times and locations being modeled, and relevant
correction factors. Different versions of the calculator may be used for each emission process.
The Emission Rate Calculator will first look up a base emission rate from a large
database of such factors. Assuming uncertainty analysis is not being done, the mean of the
emission rate distribution will be used. If uncertainly analysis is being done, then a pseudo-
random sample from the emission rate distribution will be generated (Monte Carlo approach) or
error propagation equations applied to the uncertainty on the mean (error propagation approach).
Adjustments specific to each emission process may then be applied to these basic rates,
also in a probabilistic fashion if uncertainty estimates are being generated. Calculation of
running exhaust emissions, for example, are likely to include adjustments for temperature, air
conditioning use (which in turn will depend on weather conditions), and fuel properties.
5.1.4. Execution Emission Rate Database
The Execution Emission Rate Database contains base emission rates for different
pollutants, as produced by different emission processes, by source and operating mode bin. It
also contains correction factors (or coefficients necessary to calculate correction factors) for
factors requiring these corrections, such as fuel or meteorology. The version of this database
used in the core model has been adjusted to reflect User Input Data and the effects of any Internal
Control Strategies (which will be described later). It has also been reduced in size, when
possible, to contain only the rates needed to fulfill the needs of a particular modeling run.
5.1.5. Calculated Results Queue
Result output is produced by the core model in the form of a single generic table format
that contains emission rate and mass information distinguished by pollutant, emission process,
location (a link being the most detailed location), time (an hour normally being the smallest unit
of time, though 15 minute periods are allowed at microscale), roadway type (for highway
20
-------
vehicles), kind of highway vehicle/ nonroad equipment, power class (of nonroad equipment), and
model year.
5.1.6. Output Processing/Aggregation
Output produced by the core model must generally be aggregated: first, because portions
of the output may have been produced piecemeal by different processes and computers and,
second, because the user may not desire the full extent of disaggregation produced by the
Emission Rate Calculator. MOVES allows the user to aggregate link and zone level results to
counties, states, or the entire modeling domain. It allows results to be aggregated in time up to
the hour, day, month, season, or year. It also allows distinctions by emission process, kinds of
vehicles/equipment, model year, roadway type (of highway vehicle activity) and power class (of
nonroad equipment) to each be included or removed from the results. As more of these
distinctions are removed, the more manageably sized the result data will be.
5.1.7. On-Line Analytical Processing (OLAP) Reporting Utility
MOVES will include an OLAP reporting utility program, which the user may employ
after the core process has been completed, to produce a variety of reports. Such an utility allows
the user to specify a hierarchy of fields that define a set of categories, subcategories, sub-sub
categories, etc. whose sums are calculated and reported. Specific reporting utilities will likely be
developed to produce output in the format necessary for input into air quality pre-processing
models. These format-specific utilities are also referred to as "Exporters."
5.2. The Master Generator Loop, Internal Emission Control Strategies, and
Data Generators
The MOVES core model described previously is incomplete relative to many use cases.
For example:
It implies that the model run can be executed in a piecemeal fashion, but contains no
mechanism for doing this.
The generic input data it requires is not in a form that would be easy for many users,
except in a microscale situation, to provide.
It contains no internal provisions for modeling the effect of emission control
programs or strategies (e.g., source inspection/maintenance), unless the user can
determine outside the core model how the strategies he or she wishes to model would
affect the core model input data.
Because of this, "implementations" (discussed in Section 3.2) will be developed to drive
the core model for specific use cases. Implementations will take the form of front-end
components, which perform preliminary processing stages and higher layer control components,
performed immediately prior to execution of the core model. The front-end components are the
Master Generator Loop (which controls looping of the core model); Data Generators (which
provide data needed by the core model based on default or user-supplied input data); and Internal
21
-------
Emission Control Strategies (which enable the user to select and modify emission control
strategies the user wishes to model). These steps produce the Core Model Input Data and
Execution Emission Rate Database required by the core model. Figure 5-2 shows the design
components involved in this stage.
5.2.1. Master Generator Loop
The Master Generator Loop is the mechanism that manages execution of the core model
in a piecemeal fashion to accomplish the overall model run specified by the user. It controls
execution of all the processes executed in this processing stage (i.e., the Control Strategies and
Data Generators), as well as the core model itself. The MOVES design provides for this to be
done in a very flexible fashion. All these processes will be instances of classes (i.e., objects)
which implement an interface enabling them to "sign up" with the Master Generator Loop to be
executed at any of a number of Master Loop Levels. At the topmost level, a process, such as a
fuel control strategy which changes fuel properties the same way across the entire modeling
domain, can sign up to be executed once for the entire run. Alternatively, a process can sign up
to be executed once per location, once per emission process per location, or once per time period
for each emission process per location. At the lowest Master Generator Looping Level, a
process can sign up to be executed for each hour for each emission process at each detailed
location. Within each level, control strategy processes will be executed before generators, with
the core model running last. (The core model will probably not be allowed to sign up at a level
higher than any of the other processes do.)
A process can sign up at a high level if the amount of data it produces is relatively small.
In this case, it can take advantage of efficiencies that result from processing a large part of the
run together. If, however, the amount of data produced prohibits this, a process should sign up
at a lower level. This allows for processing efficiency and data storage tradeoffs to be made in a
flexible fashion.
5.2.2. Execution Location Database
The Execution Location Database provides, along with the Execution Emission Rate
Database described earlier, the input data for the processing steps shown in Figure 5-2. These
execution databases are created by still earlier processing stages (to be described later) and exist
only for the duration of a MOVES model run. The Execution Location Database is capable of
storing the Core Model Input Data. It is also capable, however, of storing data more readily
available to model users for use by the Data Generators to derive core model data. For example,
unweathered fuel Reid Vapor Pressure (RVP) might be stored in the execution location, whereas
the core model requires weathered RVP information. Another notable example is that the
Execution Location Database will contain vehicle activity information in terms of vehicle miles
22
-------
RunSpec
Master
Generator
Loop
To All Processes
on this Page
Controls Execution
of all "Generators"
and Internal
Control Strategies
Fuel Data
Generator
Meteorology
Data
Generator
M eteorology
Data
Optional
Execution
Location
Database
I
I Fuel Control |
I Strategy I
Source Bin
Control Strategy
(affects Source
characteristics)
Source
Maintenance
(aka I/M)
Control Strategy
f
j
Source
Population and
Usage
(e.g. VMT)
Control Strategy
(Specific to
model
implementation
and generator)
Operating Mode
Distribution
Generators
(vary by scale and
process)
(pollutant-aware)
Source Bin
Distribution
Generators
Execution
Em ission
Rate Database \
Total Activity
Generators
(Vary by scale and
process)
Operating
Mode
Distributions
Source Bin
Distributions
Total
Activity
Fuel, Source Manufacturing, and
Maintenance Control Strategies generally
usable with all stages of user input data.
Im plem entation-
Specific
Outputs
Figure 5-2. Data Flow Diagram: MOVES Master Generator Loop, Internal Emission Control Strategies, and Data Generators
23
-------
traveled (VMT), which is then converted to source hours operating (SHO) by a Data Generator.
All data inputs detailed in Section 7 would be stored in the Execution Location Database.
5.2.3. Data Generators
Data Generators derive Core Model Input Data from information in the Execution
Location Database. They implement the mathematical formulations, described in Section 7, as
required for different versions of MOVES. Each of the five types of Core Model Input Data has a
distinct generator. As indicated in the diagram, some types of generators may have different
versions for different emission processes, and different implementations or releases of MOVES
may include different Data Generators. (Object inheritance will be very useful in this area of the
design.) Each generator is responsible for signing up with the Master Loop at an appropriate
level and, when executed, for supplying the Core Model Input Data for the corresponding portion
of the run. In the simplest case, if Core Model Input Data is already available in the Execution
Location Database, all a Generator needs to do is to select out of the database the data needed for
this portion of the run. In the more usual case, however, the Generators must process data from a
portion of the Execution Location Database to produce the Core Model Input Data. This process
is described in Section 7, Mathematical Formulations and Data Inputs.
5.2.4. Internal Emission Control Strategies
Prior to executing the Data Generators for each portion of the model run, another set of
processes can be executed to take into account the effects of various Emission Control Strategies,
whose detailed characteristics are built into the model. Different implementations of MOVES
will contain a different and, generally, expanding set of these internal control strategies. These
will be needed in MOVES both to represent programs actually in existence; e.g., an I/M program
being operated in a particular state, and to represent hypothetical measures being evaluated. In
the first instance, the default situation would be to include the control strategy, unless the user
removed it. In the second instance, the default would be not to include the control strategy, unless
the user added it.
All internal Emission Control Strategies have a scope which specifies a set of use types,
calendar years, and locations to which it applies. The MOVES design envisions that there will
be four kinds of internal Emission Control Strategies:
Fuel Control Strategies: This kind of strategy modifies the parameters of the fuel
available at certain times and locations in some fashion, within a given fuel type. For
example, this strategy would be used to specify that the gasoline in a given location
was RFG rather than conventional gasoline. The effects of such a strategy are taken
into account as modifications to the Fuel Data Input to the core model via the Fuel
Data Generator.
Source Bin Control Strategies: This kind of strategy results in actions that modify
the source bin distribution, which focus on specific vehicle and equipment attributes.
24
-------
The effects of such a strategy are taken into account as modifications to the Source
Bin Distribution Input to the core model via the Source Bin Distribution Generator.
Examples of this would be the creation of a new emission standard, which would also
require supplying emission rates for the new standard in the Execution Emission Rate
Database. Other examples of these control strategies include increased penetration of
advanced fuel technology or shifts in on-road vehicle weight to improve fuel
economy. If emitter category becomes a source bin parameter, it is possible that I/M
could be included in this family of control strategies, since it would fundamentally
redistribute vehicles across the emitter bins.
Source Maintenance (e.g., Vehicle Inspection/ Maintenance) Control Strategies:
Modeling of I/M in MOVES will depend on the method of characterizing high
emitters in the model, to be discussed in more detail in a separate document. The two
primary options for this are (a) characterizing the spread of emitters in the fleet as a
single distribution in the Emission Rate Database or (b) defining discrete source bins
to represent emitter classes such as "high" and "normal." If the first approach were
used, modeling of I/M would modify emission rate distributions in the Execution
Emission Rate Database to reflect the effects of Control Strategies that modify the
frequency or the manner that vehicles and equipment are repaired. If modeled as
discrete bin categories, I/M would be modeled as an extension of the Source Bin
Control Strategies.
Source Population and Usage Control Strategies: This kind of strategy modifies
either the number of vehicles and equipment in existence and/or the amount and
nature of operation that these vehicles and equipment experience. This group of
control strategies is defined as such because it would modify inputs to the Total
Activity Generator, which (as discussed in Section 7) works with population by age
and activity of this population, and/or the Operation Mode Distribution Generator.
A wide variety of strategies fall into this category; e.g., a vehicle scrappage program,
a program which encourages carpooling, a program which optimizes traffic signal
timing so that vehicles accelerate less frequently, etc. The effects of this type of
control program will be taken into account by modifying the Operating Mode
Distribution and Total Activity Information in the Execution Location Database,
which is used by Operating Mode Distribution Generators and Total Activity
Generators. Because this kind of control strategy will modify preliminary data used
to calculate the Core Model Input Data, not just information which is directly passed
to the core model, this kind of control strategy will not be available to the user who
wishes to supply Core Model Input Data directly.
5.3. The User Interface
The MOVES model described so far, even with its Control Strategies and Data
Generators is still incomplete. In particular:
It contains no mechanism for the user to indicate which results (e.g., time periods,
pollutants, etc.) are of interest and should be modeled.
25
-------
The Execution Location Database it requires, though easier for a user to provide than
the Core Model Input Data, is still not in a form that would be easy for users to
provide in many cases.
One aspect of this is that no mechanism has been provided for users to combine their
input data with default information in the MOVES model.
These capabilities are addressed by preliminary processing stages and higher layer control
components described in this final section of the MOVES data flow and shown in Figure 5-3.
These stages supply the Execution Databases required by the rest of the MOVES model.
Saved
RunSpec Files I
RunSpec GUI
User
\ \ / >
\ V
v
ir^
I
RunSpec
I Master Loop I
External
Control
Strategies
(optional)
Figure 5-3. Data Flow Diagram: MOVES User Interface
5.3.1. The Run Specification and Graphical User Interface (GUI)
MOVES will have a graphical user interface (GUI) by which the user specifies various
parameters for the model run desired. These parameters include the locations and time periods to
model, the vehicle classes and nonroad equipment types of interest, the pollutants, the control
strategies to include, output format options, etc. This set of information is collectively called a
26
-------
Run Specification or Run Spec. This GUI is described in detail in Appendix A, so the
description here will be brief and concentrate on how it participates in the MOVES data flow.
The MOVES Run Spec GUI will allow the user to specify a model beginning with a
default Run Spec or allow the user to modify Run Spec object files saved previously. (It also
allows the user to save created Run Specs for future use.) It has available a set of Internal
Control Strategies and knows how to locate the MOVES User Input Data, to be discussed later in
this section. It produces or retrieves a complete Run Spec before allowing the user to transfer
control to the Master Generator Loop described previously, which runs the Input Data Manager
described later in this section.
5.3.2. Default Databases
The MOVES model will contain databases of default information pertaining to the
modeling domain as a whole (the National Default Database), particular counties of the U.S. (the
County Database), and emission rates (the Emission Rate Database). These default databases
are read by the Input Data Manager in the process of producing the Execution Location Database,
but they are never modified by running the model. These three logical databases are all stored as
a single relational database schema, which contains all of the information needed to model the
counties of the United States at the macroscale with default information.
5.3.3. User Input Database
Users of MOVES may supply their version of any of the information in the default
databases. Indeed they are required to do this to some extent if they wish to model locations
other than the states and counties of the United States or if they wish to run the model at the
mesoscale or microscale.
MOBILE and NONROAD both allow the user to provide input through external files
which conform to a specific format. The User Input Database of MOVES continues this
approach. MOVES will accept input data as relational database tables of a specific database
software and schema. The User Input Database is stored in a single relational database, which is
an extension of the schema of the default databases. Tables that can be used to submit alternative
information for everything in the default database schema are included in the User Input
Database. Additional tables are included in the User Input Database for the user to supply Core
Model Input Data directly. The User Input Database, therefore, has a data structure similar to the
Execution Location Database and the Execution Emission Rate Database.
5.3.4. Input Data Manager
The Input Data Manager is run once to completion near the beginning of every MOVES
model run. Its job is to produce Execution Location and Execution Emission Rate Databases for
the model run which:
Contain only the subset of information needed to satisfy the Run Spec
27
-------
Override Default Database information with User Input Data to the extent it has been
supplied.
5.3.5. Data Importers
The User Input Data, while generally easier to provide than the core model input data,
still must be provided in a specific database and schema native to MOVES (e.g., macroscale
highway running activity information can be in terms of vehicle miles traveled and average
speeds rather than vehicle hours operating in vehicle specific power bins). Specific Data
Importers may be written, however, by EPA and others, to convert input data from other forms to
the database and schema required for MOVES input. For example, EPA will write an Importer to
accommodate the data input to MOBILE6. Other importers could accept data from specific
travel demand models. Importers normally will accept data in XML or other ASCII text
formats. Importers will be run by the user to produce MOVES User Input Data prior to running
MOVES itself.
5.3.6. External Control Strategies
External Control Strategies are a special kind of Importer which can be used to model the
effects of control measures by supplying MOVES User Input Data that captures their effects.
They provide an additional means to model the effects of various emission control measures that
are not built into MOVES via the internal control strategies discussed in Section 5.2.4. Processes
which implement External Emission Control Strategies are similar to Data Importers except that
they may read (but not directly alter) MOVES Default Database information. Instead they
produce MOVES User Input data, which the Input Data Manager uses to override MOVES
Default Database information. External Control Strategies are not planned for the initial
implementations of MOVES, though they could be added later as needed by EPA and others.
28
-------
6. MOVES Databases
To calculate mobile source emissions at all three scales, MOVES will need to store and
process huge amounts of information. Unlike the MOBILE model, which stores data externally
in flat text files and internally in Fortran block data modules, MOVES will store data in
relational databases. This will allow MOVES to store data efficiently and to take advantage of
standard Structured Query Language (SQL) to access and process the data.
Previous sections of this report have described the role of the databases in the context of
the software design layers and the data flow. This section focuses on the information that the
databases contain. Some of the databases are temporary, existing only for the duration of a
MOVES model run. Others are permanent sets of default values that can be used for all runs of a
given MOVES implementation.
MOVES uses three basic categories of databases, detailed in this section. Input databases
include default databases supplied by MOVES and user-supplied databases. Execution databases
are temporary databases created by MOVES during execution. The output database contains
MOVES output aggregated per user instructions.
6.1. Input Databases
Input databases include all information needed to calculate emission inventories and
extensive default information. This information comprises the following:
Total Activity Information: How much activity (e.g., source hours operating, source
hours parked, etc.) occurs for sources of different types (i.e. types which matter for
activity) and ages. The MOVES design considers source age to be an activity
discriminator and allows distributions of such source activity discriminating
characteristics to vary by time and location. Each emission process may have its own
activity basis and information.
Operating Mode Distributions: How much of this activity occurs in each of various
operating modes. Each emission process is allowed to have its own operating modes
which may be as simple as "operating" vs. "not operating" or more complex such as
source-specific-power (VSP) bins. The MOVES design allows these operating mode
distributions to vary by time and location and by type of roadway.
Source Bin Distributions: How is source activity distributed among sources having
different characteristics; i.e., characteristics that matter for emissions but not for
activity? Such characteristics might include the emission standard to which the source
was built, its type of fuel injection, catalyst type, etc. MOVES may also treat fuel
type and source weight or engine displacement (within some classification
constraints), as being characteristics of this type. The MOVES design allows such
distributions to vary by type of source and model year, but not by time or location. As
always each emission process may have its own activity basis and information.
29
-------
Meteorology Data: Information such as temperature, humidity, etc. that influence
emission rates by time and location. MOVES does not plan to include effects of
meteorology on activity.
Fuel Data: Information about the fuel parameters of different kinds of fuel (gasoline,
diesel, etc.) associated with times and locations. Fuel characteristics are considered
by the model to influence emission rates.
Emission Rate Information: Emission rates and statistical distribution information
for the various pollutants and emission processes and kinds and model years of
sources (including technology and standards discriminators) for each operating mode.
Both mean emission rate and emission rate distribution information is needed in
order to generate estimates of uncertainty. These rates are not a function of time or
location.
Finally the default databases include all information needed by all implemented
Generators to derive total activity, source bin, meteorology, fuel and operating mode information
in the form required for the core model, as detailed in Section 7. This implies very significant
elaborations to the default database. In particular, the macroscale implementation will include
extensive default input information.
Conceptually the default input information is stored in several separate but related
databases as follows:
Emission Rate Database: Because of its size, unique structure, and major role in the
model, default emission rate information is considered its own database.
National Default Database: Those portions of the default database (other than
emission rates) which do not depend upon locations or counties are considered to
constitute a "National Default Database" or "Domain Default Database."
County Default Database: Those portions of the default database (other than
emission rates) which depend upon county are considered the "County Default
Database."
In addition, the user may provide User Input Databases, directly or indirectly via Data
Importers, for particular run(s) of the MOVES model. Their structure is the same as the
corresponding Default Databases. Providing this information is optional at the macroscale if the
user wishes to model the states and counties of the United States using default information. It is
required for mesoscale or microscale modeling. It may be used to:
Replace or override any of the information in the default databases.
Supply the same kinds of information as the default database for geographic locations
other than the states and counties of the U.S.; e.g., grid cells or smaller scale
geographic units such as traffic analysis zones or roadway links.
30
-------
6.2. Execution Databases
During execution of the MOVES model several databases will be created on a temporary
basis. These are shown in the data flow diagram (Figure 5-3) as the Execution Location
Database and the Execution Emission Rate Database. They have the same structure as the
default and user input databases already described. These databases need not concern the end
user. Their role is to facilitate efficient execution of the model. They store information which:
Resolves differences between the user input and default data.
Contain only information needed for a particular run of the model; e.g., only the
source types, pollutants, locations, etc for which the user has requested that emission
estimates be calculated.
Facilitate the storage of intermediate results.
6.3. Output Database
MOVES will produce its core model output in the form of a simple database, as shown in
Figure 6-1.
The MOVES Run table contains one record pertaining to the entire run of the model.
Such as the time of the run, a reference to the Run Spec used, unit scaling factors, etc.
The MOVES Output table may contain many records, each reporting an individual
emission factor and/or mass emission result for one pollutant. The level of aggregation of this
table is governed by user input parameters in the run specification. In its most detailed form, it
can contain hourly result records for each of the most detailed locations being modeled for each
SCC code and power class (for nonroad) or source use type, fuel type, and roadway type (for
highway vehicles) for each model year and emission process and pollutant. At the most
disaggregate level the output of the MOVES output table would be comparable to the database
output from MOBILE6. More detail may be found in Appendix B: MOVES Output Database
Design.
It is up to the user how long these output databases are preserved and, in the initial
implementations of MOVES, for managing their storage and retrieval. The database format
facilitates aggregating or summarizing the results of individual runs, as well as combining or
comparing the results of multiple runs. Initial implementations of MOVES will include a
general purpose OLAP reporting tool for aggregating and totaling results and displaying them in
a flexible category hierarchy, as well as "exporters" such as a specific tool to convert the generic
MOVES output into a form suitable for input to SMOKE. Later use case implementations of
MOVES are likely to include additional tools to facilitate the storage, retrieval, and comparison
of MOVES run results for particular purposes.
31
-------
MOVES Run
MOVESRunID: INTEGER
timeStepHours: REAL
timeUnits: VARCHAR(S)
clistanceUnits: VARCHARC5)
massUnits: VARCHAR(5)
runSpecFileName: VARCHAR(255'i
runDateTime: DATETIME
HCExpressAs: CHAR(6)
scale: CHAR(5)
MOVESOutput
MOVESOutputRowlD: INTEGER
MOVESRunID: INTEGER
monteCarloSimulationNumber: SMALLINT(4)
monteCarloRunNumber: SMALLINT(4)
outputTime: DATETIME
statelD: INTEGER
locationID: INTEGER
zonelD: INTEGER
linkID: INTEGER
pollutantID: INTEGER
modelYear: SMALLINT(4)
fuelTypelD: INTEGER
processID: INTEGER
onOrOffRoad:CHAR(1)
roadTypelD: INTEGER
sourceCategorylD: INTEGER
sourceTypelD: INTEGER
segment: TINYINT(2)
SCC:CHAR(10)
HPCIass: TINYINT(3)
emissionMassPei'Time: REAL
emissionMassPerDistance: REAL
emissionMass: REAL
Figure 6-1. MOVES Output Database Design
32
-------
7. Mathematical Formulation and Data Inputs
As discussed in Section 3, we are proposing that meeting the use cases presented in Table
2-1 will require specific "front-end" implementations be developed. These implementations will
provide the necessary information to the core model using a large body of default data and best
practice methods currently employed in developing mobile source emission inventory estimates.
In order to go from generally available information to input needed by the core model, MOVES
will employ data generators, which are necessary specifically for the calculation of total activity
and the distribution of operating modes. The nature of the MOVES framework is such that the
majority of mathematical calculation will occur within the generators, specifically the Total
Activity and Operating Mode Distribution Generators, which are linked to specific MOVES
implementations. This section presents the proposed mathematical formulations for specific
MOVES implementations.
We propose to develop total activity and operating mode generators for the following
implementations:
Macroscale on-road inventory development at two levels: the national level or a user-
defined domain level
Mesoscale on-road inventory development at the user-defined domain level
Microscale on-road analysis in conjunction with CAL3QHC at the user-defined
domain level
Macroscale off-road inventory development at the national level
We also believe that the advanced transportation model TRANSEVIS could be linked to
MOVES through the development of specific generators. We do not propose to take on the
development of these generators, but would support this development with developers of
TRANSIMS.
As stated in Section 3, a primary objective of the MOVES design is to develop a generic
framework that can apply to different analysis scales and emission processes. To maintain this
design objective a generic approach to addressing the three analysis scales is required. The core
model design is based on the idea of time and location, without regard to what the times and
locations are; this is the generic feature of the core model. What primarily defines the
difference between macroscale, mesoscale, and microscale are the definitions of time and
location prior to implementation by the core model.
Location is defined by two elements: the "Domain," which is the entire area being
modeled, and "Zones," which are subdivisions of the domain. MOVES will be flexible enough
to work with any definition of domains and zones, as long as the user can supply necessary
information to support that definition. Typical Domain/Zone combinations could be
Nation/County, Region/Grid Cell, or County/Traffic Analysis Zone. For certain on-road
emission processes, a third location element is also required: "Links," which can either be
33
-------
assigned to a Domain or a Zone. Links are defined more concretely depending on the scale
being modeled, but the core model will fundamentally apply the concept of links across all
scales.
An overview of the primary implementations are shown in Table 7-1, which highlights
the definitions of domain., zone and link for each implementation.
Table 7-1: Implementations Proposed for MOVES
Implementation
On-Road
Macroscale
Inventory (National
Default)
On-Road
Macroscale
Inventory (Domain-
Specific)
On-Road Mesoscale
Inventory
On-Road
Microscale Analysis
w/ CAL3QHC
Description
Produces
county-level
inventory for
entire nation.
Produces
inventory for
user-defined
domain
Produces
inventory for
user-defined
domain at
link/zone level
Produces
necessary
emission
factor inputs
for microscale
analysis using
CAL3QHC
Use Cases
Applications
National Inventory
Development
Policy Evaluation
AQ Pre-Processor
Interaction
Local Inventory
Development
(e.g.,
SIP/Conformily
analysis)
Policy Evaluation
AQ Pre-Processor
Interaction
Local Inventory
Development
Policy Evaluation
Travel Demand
Model Interaction
Hot Spot Analysis
Dispersion Model
Interaction
Domain
U.Splus
territories
User-defined;
likely
examples are
counties,
MSA,
nonattainment
areas, states
User-defined;
likely
examples are
counties,
MSA,
nonattainment
areas, states
CAL3QHC
analysis area
Zone
Locations
Counties
User-defined;
likely
examples are
grid cells, zip
codes, census
blocks
User-defined;
likely example
is
Transportation
Analysis
Zones (TAZ)
N/A
Link
Locations
HPMS
Roadway
Types
HPMS
Roadway
Type
User-defined
on-Network
links
Off-network
HPMS road
way types
Idle and non-
idle links as
defined in
CAL3QHC
input file
34
-------
Table 7-1: Implementations Proposed for MOVES
Implementation
Off-road
Macroscale
Inventory (National)
Description
Produces
county-level
off-road
inventory for
entire nation.
Use Cases
Applications
National & Local
Inventory
Development
Policy Evaluation
AQ Pre-Processor
Interaction
Domain
U.Splus
territories
Zone
Locations
Counties
Link
Locations
N/A
The total activity and operating mode generators will require significant mathematical
processing and input data to convert from standardly available input data (e.g., VMT data) to the
inputs necessary by the core model. Indeed, given the simplicity of the core model structure, the
generator steps represent the most significant mathematical formulation elements of MOVES.
The remainder of this section focuses on walking through the proposed mathematical formulation
for the total activity and operating mode generators for the specific implementations supported by
MOVES.
7.1. On-Road Implementation
For the on-road implementations, the generator functions depend heavily on how vehicles
are grouped. We describe vehicle categorization in MOVES before going into the total activity
and operating mode generators.
7.1.1. MOVES Vehicle Types
In MOBILE6, a single definition of vehicle groupings was developed and each was
assumed to have the same emission rate and activity patterns. One shortcoming of this
approach is that categories which are important for distinguishing unique emission rates (e.g.,
vehicle weight class) may not be the best category descriptions in terms of activity or may not
match available fleet and activity data. Therefore, we are proposing to approach vehicle
categorization in MOVES from the viewpoint of both activity and emissions, which will enable
MOVES to take into account what is important for activity separately from what is important for
distinguishing unique emission rates.
In terms of emissions, the parameters used to define source bins are based on factors
determined to explain variability in emission production, such as fuel type, emission standard,
technology type, vehicle weight, and engine size. In terms of activity, the MOBILE6 approach
would be to also characterize activity according to these bin parameters; e.g., all trucks of a given
fuel type and weight are similar in terms of usage patterns. This approach does not account for
the difference in use patterns for vehicles which may fall within a given emission bin, for
example a short-haul delivery truck and a garbage truck. Instead, for MOVES we are proposing
a shift from characterizing vehicle activity based on emission-based parameters to characterizing
vehicles by how they are used.
35
-------
For characterizing activity, we are proposing MOVES categories known as use types,
which are more closely aligned with vehicle use patterns. Use types will be defined by unique
activity patterns. The link between use types and the emission-based source bins will be made by
the source bin distributions, to enable the core model to take total activity from the use types and
distribute it across the bins defined by unique emission rates. The important distinction between
use types and source bin parameters is that activity is assumed to be constant across the source
bin parameters. For example, under this approach diesel and gasoline passenger cars would be
assumed to accrue mileage at the same average rate and travel at the same average speed for a
given roadway type.
For on-road vehicles, we propose that MOVES use types be subsets of Highway
Performance Monitoring System (HPMS) vehicle classes, which are important to retain in the
MOVES design because VMT data is provided from the Federal Highway Administration
(FHWA) by these classes. The VMT data provided by HPMS form the basis of macroscale on-
road activity estimates in the total activity generator for all emission processes, and, hence, drive
the structure of activity generation in MOVES.
Table 7-2 shows a breakdown of the HPMS vehicle classes, the proposed MOVES use
types, and examples of source bin parameters. The use types shown in Table 7-2 are initial
proposals which will likely need to be refined based on analysis of classification schemes in
available data sources, most notably national registrations databases and the Vehicle In-Use
Survey (VIUS), published by the U.S Census Bureau. A subset of source use type which will be
accounted for in MOVES, but is not shown in Table 7-2, is source age, because activity does
vary by age. Specifically, older vehicles accrue fewer annual miles than newer vehicles, an
activity characteristic that is modeled in MOBILE6.
36
-------
Table 7-2: Proposed MOVES On-Road Vehicle Classification Scheme
Activity Classifications
HPMS Class
Passenger
Cars
Other 2-axle /
4-tire Vehicles
Single Unit
Trucks
Buses
Combination
Trucks
Motorcycles
Use Type
Passenger
Cars
Passenger
Trucks
(Pickup,
Minivan,
SUV)
Work Trucks
Service
Trucks
Local Delivery
Trucks
Short-Haul
Delivery
Trucks
Motorhomes
Interstate
Buses
Urban Buses
School Buses
Long-Haul
Delivery
Trucks
Motorcycles
Emission Classifications Examples (Source Bins)
Weight
Range
(pounds)
<4000
>4000
<4000
<6000
< 10,000
<6000
< 10,000
< 14,000
<14,000
<16,000
<19,500
<26,000
<33,000
<60,000
< 33,000
< 60,000
> 60,000
Fuel
Types
Gas,
Diesel,
CNG,
LPG,
M85,
E85,
EV,
HEV,
FCV
Gas,
Diesel
Gas,
Diesel,
CNG,
LPG,
M85,
E85,
EV,
HEV,
FCV
Diesel
Gas,
EV
Standard
Groups
Pre-
control,
Tier 0,
Tier 1,
NLEV,
Tier 2
Gas: Pre-
control,
1987,
1988,
1991,
1998,
2004,
2007
Diesel:
Pre-
control,
1985,
1988,
1990,
1 C\C\ 1
1991,
1998,
2004,
2007
Techno-
logies
No catalyst
Oxidation
catalyst
3 -way
catalyst
Carbureted
Fuel
injection
EGR
secondary
air
Mileage
Range
Low
Medium
High
Emitter
Class
Normal
High
37
-------
7.1.2. Total Activity Generator
The macroscale on-road inventory implementations (national default and domain-
specific) use estimates of vehicle miles traveled (VMT) as a starting point for generating total
activity for most emission processes. This approach recognizes that emission production in a
given location depends on the activity in that location, which may not be captured by what is
registered in that location. This is particularly true of heavy-duty vehicles, for which the
registered fleet and the on-road fleet can be quite different for a given location.
The basic process of total activity generation is the same for the national default and
domain-specific implementations. The primary difference is that for the national case, total
activity will be generated for the entire country (the default domain) and allocated to the county
level (default zone location) using default geographic allocation factors. For the domain-specific
case, total activity will be generated for the modeling domain based on user-supplied VMT data,
which would override activity calculated from the default geographic allocation factors. If the
user wishes, domain-level emissions could be allocated to the zone level (e.g. to facilitate
calculation of emissions by grid cell) with user-supplied geographic allocation factors.
The steps necessary to produce total activity for these levels are detailed step-by-step in
this section. First it is necessary to define several terms and acronyms found in the mathematical
formulation. FIPMS Vehicle Types and MOVES Use Types are listed in Table 7-2. The
National Default Database (NDB) contains default fleet and activity information, which will be
applied across the entire modeling domain unless overridden by user-supplied data. The
Location Default Database (LDB) contains default location-specific information, which will be
applied at the location level and can also be overridden by user-supplied data.
The first set of steps for total activity generation is to allocate VMT to use type according
to the fleet and mileage accrual rates. This requires estimating the makeup of the fleet in a
known base year (calendar year 2002 is proposed as the base year for MOVES GHG, the first
release of MOVES), growing and scrapping the fleet to the desired analysis year, calculating the
proportion of aggregate VMT traveled by use type and age in the analysis year (known as the
"travel fraction"), and applying this to an estimate of aggregate VMT in the analysis year. Years
prior to 2002 would be treated as base years as well, in that the databases will contain data from
these years for performing the necessary calculations. The growth steps will only apply to years
after the latest base year, beginning in 2003 in the case of MOVES GHG.
The mesoscale level of analysis proposed to be supported by MOVES requires that the
user supply sufficient information to calculate bottom-up emissions at the link/zone level for
running exhaust, start, brake wear, and tire wear processes. The most likely source of this
information would be output from a traditional travel demand model. All other processes are
handled using macroscale allocation approach down to the zone level, including off-network
emissions for running exhaust and brake and tire wear processes. All fleet inputs are applicable
across the entire modeling domain. The user must define the modeling domain, the road network
(i.e., which roadways will be modeled as individual links), and analysis zones. More
disaggregated approaches to the mesoscale model, such as the MEASURE framework developed
38
-------
by Georgia Tech and EPA's Office of Research and Development, could be run in MOVES with
direct interface with the core model, but would not be supported as a specific implementation of
MOVES.
The microscale level of analysis proposed to be supported by MOVES is based on
necessary input for the dispersion model CAL3QHC, which is EPA's recommended model for
intersection analysis,7 applicable primarily to CO, PM and air toxics. Through the CAL3QHC
input file, the user would supply sufficient information to calculate emission rates for running
exhaust, brake wear, and tire wear at the link and intersection level. Other processes would need
to be modeled through direct interface with the core model. All fleet inputs are applicable across
the entire modeling domain. The user must define the modeling domain and the road network
(i.e., which roadways will be modeled as individual links) through the CAL3QHC input file.
Table 7-3 lists all of the steps necessary for total activity generation at the macroscale,
mesoscale, and microscale levels. Each of these steps is detailed in following text. All steps
apply across each of the three scales, unless the mesoscale/microscale cases are specifically
separated out.
Table 7-3: Overview of Total Activity Generator (TAG) Steps
Step
TAG-1
TAG-2
TAG-3
TAG-4
TAG-5
TAG-6
TAG-7
TAG-8
Calculate Base Year Vehicle
Population
Grow Vehicle Population to
Analysis Year
Calculate Analysis Year Travel
Fraction
Calculate Analysis Year VMT
Allocate Analysis Year VMT By
Roadway Type, Use Type, Age
Temporally Allocate Annual
VMT to Hour by Roadway Type,
Use Type, Age
Convert to Total Activity Basis
By Process
Allocate Total Activity Basis By
Zone Location
Description
Establish base-year vehicle population in
modeling domain by use type, age
If analysis year is in future, establish
analysis year population through growth and
scrappage
Calculation travel fraction across domain as
function of age mix and annual miles
traveled, by use type and age
If analysis year is in future, establish
analysis year aggregate VMT across domain
from base year VMT and growth
Allocate aggregate VMT to roadway type,
use type and age
Allocate annual VMT to hourly VMT
Convert to total activity basis at domain
level: SHO, SHP, Starts, etc.
Allocate total activity to zone locations
using geographic allocation factors
Vary by Scale?
No
No
No
Yes
Yes
Yes
Yes
No
39
-------
Following the overall steps outlined above, the macroscale generator will be able to
provide total activity data at the level needed by the core model: by emission process, time (one-
hour increments), location (roadway "link" and zone), use type, and age.
TAG-1: Calculate Base Year Vehicle Population
Vehicle population by use type and age would be generated from national databases such
as those compiled by R.L. Polk company and/or the HPMS system and from the Vehicle In-Use
Survey (VIUS). User-supplied data could be developed from local registration databases,
Inspection/Maintenance programs, and/or roadside surveillance programs such as remote
sensing. Calendar year variation applies to years prior to the base year, for which historical data
will be used directly in the calculation of emissions for those years. For example, MOVES
GHG. 1 will produce emissions for historical calendar years 1990 through 2001, with the base
year being 2002.
Calculation
Possible Sources
Can Vary By
Base Year Population *
NDB, User
Calendar Year, Use Type
Age Distribution
NDB, User
Calendar Year, Use Type, Age
TAG-2: Grow Vehicle Population from Base Year to Analysis Year
The growth step is only necessary when the year being modeled is later than the base
year. Starting with the base year vehicle population, the population must be grown to the analysis
year using a year-by-year process. MOVES will allow for a dynamic registration process,
meaning that age distributions will vary from year to year due to fluctuations in new sales. The
calculation for this step depends on whether the age being modeled is zero, which must account
for new sales, or non-zero.
For age zero vehicles, new sales are allowed to vary by year and will be expressed as a
function of previous year sales (which are the same as the population of age zero vehicles in the
previous calendar year, calculated from TAG-1). Sales rates will vary by use type and calendar
year, which will provide the flexibility to input alternate sales penetrations for various use types
(such as passenger cars and passenger trucks). National default growth rates will be developed
based on historical trends and economic projections. User-supplied local data could be
developed based on local trends and projections.
Survival rates the probability that vehicles will remain on the road, i.e. not be scrapped.
Likely sources for national default levels are scrappage rates such as those published by Oak
Ridge National Laboratory. Migration rates reflect the relative change of vehicle population due
to vehicles entering or leaving the modeling domain. At the national default level it would likely
be assumed that the migration rate is zero. Local rates could be developed from local
registration records.
40
-------
Age Zero (New Vehicles)
Calculation
Possible Sources
Can Vary By
Age Zero Vehicle
Population In
Previous Calendar
Year*
TAG-1
Calendar Year,
Use Type
Sales Rate *
NDB, User
Calendar Year,
Use Type
Survival Rate *
NDB, User
Use Type, Age
(fixed)
Migration Rate
NDB, User
Use Type, Age
(fixed)
Other Years
Calculation
Possible Sources
Can Vary By
Vehicle Population In
Previous Calendar
Year*
TAG-1
Calendar Year, Use
Type, Age
Survival Rate *
NDB, User
Use Type, Age
Migration Rate
NDB, User
Use Type, Age
To enable the dynamic registration feature, these steps would be repeated in every year until the
analysis year was reached.
TAG-3: Calculate Analysis Year Travel Fraction
The travel fraction is defined as the proportion of VMT traveled by a given use type and
age. This depends on the age distribution as well as per-vehicle annual mileage accumulation
rates (MAR) by age. For future analysis years, the age distribution is calculated by dividing the
population by use type and age (calculated in the previous step) by total population summed over
use type and age. For historical years, the age distribution is already contained in the default or
user-supplied database. The age distribution is then multiplied by the relative MAR in each year
and divided by the product of these terms over all years to produce the travel fraction. The
relative MAR is the relative per-vehicle mileage accumulation by use type and age across each
FtPMS class, compared to a fixed use type / age combination We propose to use the same
relative MAR for all years under the assumption that the relative level of travel for an average
vehicle of a given use type will remain constant across all ages.
Calculation
(Vehicle Population /
Total Vehicle Population
Within Mapped HPMS
Vehicle Class) *
Relative MAR / Sumproduct
(Previous terms, over all ages)
Possible Sources
TAG-2
TAG-2 summed by use type
& age within HPMS class
NDB, User
Can Vary By
Calendar Year, Use
Type, Age
Calendar Year, HPMS
Vehicle Class (Table 7-2)
Use Type, Age
41
-------
TAG-4: Calculate Analysis Year VMT
For the base year and historic years at the macroscale level, VMT will be stored directly
in the database (national VMT for the default case, user-supplied VMT for the domain-specific
case), so a growth step is not required. Future years require the projection of VMT growth. It is
important to note that under the proposed approach, VMT growth is treated as an external
variable, rather than being calculated internally. Steps TAG-1 through TAG-3 are undertaken to
develop the travel fractions necessary to allocate aggregate VMT generated in this step by use
type and age.
Historic and base year VMT will be provided by HPMS estimates. Specifically, the
FHWA report Highway Statistics (Table VM-1) would provide default national information by
HPMS Class. Domain-specific estimates input by the user would be derived from HPMS or
aggregated travel model input.
Overall VMT growth for the entire modeling domain is applied to base year VMT by
HPMS vehicle class. Default VMT growth would be on the national level and would likely be
developed on a calendar year basis, taking into consideration historical trends, economic
projections, and current estimates of VMT growth. User-supplied local data should consider the
same factors for the local domain being modeled. VMT growth is expressed here as linear
growth, i.e. a percentage increase (which can vary by year) relative to VMT in the base year.
Evaluation of policies or scenarios affecting aggregate VMT growth would be employed
with user input at this stage. The user would enter, by calendar year, aggregate VMT growth
rates on a domain-wide level as part of the Source Usage Control Strategy.
Macroscale TAG-4
Calculation
Possible Sources
Can Vary By
Base Year VMT
NDB, User
HPMS Vehicle
Class
1+ [(Projected annual
linear VMT growth) *
NDB, User
Calendar Year, HPMS
Vehicle Class
(Analysis Year - Base
Year)]
Calculated
The primary difference between macroscale and the meso/microscale is that, for the latter,
estimates of VMT are generated from link-level activity estimates. For on-network travel (the
network represented by links), VMT estimates for these scales are calculated on a link-basis from
user input of and link length from travel demand models, CAL3QHC and/or auxiliary sources
such as TIGER. Volume is defined as the number of vehicles traveling over a link during the
analysis time period.
42
-------
Mesoscale/Microscale On-Network TAG-4
Calculation
Possible Sources
Can Vary By
Analysis Period Volume *
User
Roadway Link
Link Length *
User
Roadway Link
Off network VMT for mesoscale is handled in much the same way as macroscale VMT.
The user would be required to input base year off-network VMT, likely from HPMS estimates,
and provide growth estimates to allow the calculation of analysis year off-network VMT.
Mesoscale Off-Network TAG-4
Calculation
Possible Sources
Can Vary By
Base Year Off-Network
VMT
User
HPMS Vehicle Class
1+ [(Projected annual
linear VMT growth) *
User
Calendar Year, HPMS
Vehicle Class
(Analysis Year -
Base Year)]
Calculated
TAG-5: Allocate Analysis Year VMT By Roadway Type, Use Type, Age
At the macroscale level, this step allocates aggregate VMT in the analysis year (calculated
in the previous step) to roadway type, use type, and age based on analysis year travel fractions
and roadway allocation factors. The new input for this step is roadway allocation factor, which
allocates aggregate VMT to the 12 HPMS roadway types. It is assumed that roadway allocations
in the analysis year are the same as the base year. National default roadway allocation factors
would be derived directly from national summaries of HPMS VMT data, as summarized in Table
VM-2 of FHWA's Highway Statistics report. User-supplied information at the local level could
be derived from state or county-level HPMS data.
The allocation to roadway type at the domain level is necessary at this stage because the
conversion to SHO from VMT in later steps relies on average speed, which varies by roadway
type. Variations in roadway allocation at the location level can be addressed through the
development of geographic allocation factors in step TAG-8, which vary by roadway type as
well.
Macroscale TAG-5
Calculation
Possible Sources
Can Vary By
Analysis Year
VMT *
TAG-4
Calendar Year,
HPMS Class
Roadway Allocation *
NDB, User
HPMS Roadway
Type, Use Type
Analysis Year Travel Fractions
TAG-3
Calendar Year, Use Type, Age
43
-------
The allocation of on-network VMT at the Mesoscale/Microscale levels would be
calculated by applying the domain level travel fractions at the link level.
Mesoscale/Microscale On-Network TAG-5
Calculation
Possible Sources
Can Vary By
Analysis Year VMT *
TAG-4
Roadway Link
Analysis Year Travel Fractions
TAG-3
Calendar Year, Use Type, Age
The allocation of off-network VMT at the Mesoscale levels would be calculated by
applying the domain level travel fractions to the off-network VMT.
Mesoscale Off-Network TAG-5
Calculation
Possible Sources
Can Vary By
Analysis Year VMT *
TAG-4
Calendar Year, HPMS
Class
Analysis Year Travel Fractions
TAG-3
Calendar Year, Use Type, Age
TAG-6: Temporally Allocate Annual VMT to Hour by Roadway Type, Use Type, Age
Step TAG-5 produced aggregate annual VMT estimates. Step TAG-6 then allocates this
down to the hourly level, the basic unit of time for macroscale and mesoscale analysis. This
requires a series of temporal allocation factors: year to month, month to day, and day to hour.
These will require an awareness of the calendar to reflect idiosyncrasies such as variation in days
per month. Monthly allocation factors will take into account differences due to season and
length of the month and will need to take into account leap years. National defaults have been
developed for EPA's National Emission Inventory (NEI). Daily allocation factors will be
developed for each day in the week, would take into account differences such as weekday versus
weekend travel, which will vary by vehicle class and roadway type. Daily allocations will
depend on the month, since a given month has a different number of days. Hourly allocation
will account for hourly differences within a day, which will depend on the day of the week,
vehicle class, and roadway type.
National defaults for monthly allocation factors have been developed for the NEI, which
we propose to use for MOVES as well. Default daily allocation factors would need to be
developed based on HPMS VMT estimates. Hourly allocation factors have been developed from
driving survey data as part of MOBILE6, and we propose to use these as the default for MOVES
as well.
44
-------
Macroscale TAG-6
Calculation
Possible Sources
Can Vary By
Analysis Year VMT *
TAG-5
Calendar Year,
Roadway Type, Use
Type, Age
Monthly Allocation
Factor *
NDB, User
Month, Use Type,
Calendar Year
(Leap Year / Non-
Leap Year)
Daily Allocation
Factor *
NDB, User
Month, Day of
Week, Use
Type, Roadway
Type
Hourly Allocation
Factor
NDB, User
Day of Week,
Hour, Roadway
Type, Use Type
The primary difference in temporal allocation between mesoscale and macroscale is that
the mesoscale activity from travel demand models is typically expressed over periods less than a
day, such as am peak, pm peak, and off-peak. Thus the hourly allocation factors would reflect a
period shorter than one day, although they could be derived from the national default daily-to-
hourly allocation factors.
Mesoscale TAG-6
Calculation
Analysis Period VMT *
Hourly Allocation Factor
Possible Sources
TAG-5
NDB,U
Can Vary By
Network/Off-Network, Roadway
Link, Use Type, Age
Month, Day of Week, Use Type, Network/Off-
Network, Roadway Link
TAG-7: Convert to Total Activity Basis By Process
The next series of steps relates to producing total activity for each of the processes based
on VMT. The total activity to be calculated includes: (a) source hours, (b) source hours
operating, (c) source hours parked, (d) number of starts, and (e) gallons refueled. This
conversion is performed at the domain level primarily to maintain consistency between the
different activities. The method outlined in this step assumes that the modeling domain is a
"closed box", in which all operation and parking occur. In particular this assumption greatly
simplifies the calculation of source hours parked, since source hours and source hours operating
are known. The "closed box" approach is more applicable to large modeling domains than
specific locations, hence the generation of total activity at the domain level.
Total Source Hours
Total source hours (SH) is a necessary input in the computation of Source Hours Parked
(SHP), the activity basis for diurnal, hot soak, and resting loss. Total source hours in the
modeling domain for the hour being analyzed amounts to the vehicle population in the domain
for that hour, split by use type and age, which was calculated under a previous step. The key
assumption in this approach is that all vehicles which exist within a modeling domain are
reflected in the VMT estimates, which were used to generate the population. In other words, all
vehicles which produce emissions drive at some point within a year.
45
-------
Calculation
Possible Sources
Can Vary By
Analysis Year Vehicle Population:
TAG-2
Calendar Year, Use Type, Age
IHour
Source Hours Operating
Source Hours Operating (SHO) is proposed as the activity basis for running exhaust,
crankcase, running loss, brake wear, and tire wear processes. SHO is calculated by dividing
VMT on a given roadway type, use type, age, and hour by the average speed, which could vary
by day of week, hour, use type, and roadway type. National defaults for average speed would be
developed by instrumented vehicle surveys or speed studies. User-supplied data could come
from similar sources at the local level.
Macroscale On-Road SHO
Calculation
Possible Sources
Can Vary By
Analysis Year VMT /
TAG-6
Calendar Year, Roadway Type, Use
Type, Age, Month, Day, Hour
Average Speed
NDB, User
Day of Week, Hour, Use Type,
Roadway Type
The primary difference with the mesoscale/microscale is that average speed will be
provided by the user at the link level, based on input from a travel demand model and/or post-
processing.
Mesoscale/Microscale On-Road SHO
Calculation
Possible Sources
Can Vary By
Hourly VMT /
TAG-6
Roadway Link, Use Type, Age, Hour
Average Speed
User
Roadway Link, Use Type, Hour,
Mesoscale off-network SHO is generated by dividing off-network VMT by the average
off-network speed, by use type and hour.
Mesoscale Off-Network On-Road SHO
Calculation
Possible Sources
Can Vary By
Hourly VMT /
TAG-6
Calendar Year, Use Type, Age, Hour
Average Speed
NDB, User
Use Type, Hour
An emerging concern in the on-road vehicle inventory is extended idling, primarily from
heavy-duty vehicles, for which hoteling (overnight idle) is common. Extended idle is not
reflected in the on-road VMT estimates used to generate on-road SHO and must be accounted for
46
-------
separately. MOVES will explicitly account for extended idling activity through the estimation of
extended idle SHO, which will be treated within the model as a 13th roadway type (allowing it to
fit into the allocation scheme discussed in the next section). We are proposing to do this by
developing an "Idle SHO Factor" which is expressed as "Idle SHO per On-Road SHO." We
propose that this factor is best applied at the daily level, rather than the hourly level, since
extended idle is more likely to happen in a daily cycle.
Extended Idle SHO
Calculation
Possible Sources
Can Vary By
Daily On-Road SHO *
TAG-7 On-Road SHO Summed By
Day
Calendar Year, Use Type, Age,
Hour
Idle SHO Factor (Idle SHO / On-
Road SHO)
NDB, User
Use Type, Hour
Total SHO is calculated as the sum of On-Road SHO and Extended Idle SHO.
Source Hours Parked
Source Hours Parked (SHP) is proposed as the activity basis for evaporative emission
processes, specifically diurnal, resting loss, and hot soak. As proposed, SHP would be calculated
as the difference between Source Hours and Source Hours Operating. The primary benefit of this
is that it will ensure a direct link between activity basis for exhaust and evaporative emissions.
Because roadway type is not relevant to evaporative emissions, source hours operating would be
summed across roadway type to reflect the operation in the entire modeling domain.
Calculation
Possible Sources
Can Vary By
Source Hours -
TAG-7 SH
Calendar Year, Use Type, Age,
Hour
Total Source Hours Operating
TAG-7 Total SHO
Calendar Year, Use Type, Age, Month,
Day, Hour
Number of Starts
Number of starts is the activity basis for one process: start exhaust. To ensure
consistency across exhaust emission processes, we are proposing to link the number of starts to
source hours operating by developing a "Starts per SHO" factor, which would vary by day of
week, hour, and use type. Whether the SHO for this factor is based on the total SHO or only on-
road SHO will need to be determined. This factor is not assumed to vary by age; but linking
starts to SHO ensures that the variation in travel by vehicle age is reflected in the number of
starts as well. National default levels for this factor would be derived from driving survey data,
such as that used in the development of start per mile estimates in MOBILE6. User-supplied
local estimates could be derived from driving survey data as well.
47
-------
Calculation
Possible Sources
Can Vary By
SHO*
TAG-7
Calendar Year, Use Type, Month,
Day, Hour
Starts Per SHO
NDB, User
Day of Week, Hour, Use Type
Gallons Refueled
Gallons of fuel used (and, hence, refueled) is the activity basis for the refueling emission
process. This is directly tied to VMT using an average miles per gallon estimate by vehicle class
and age. VMT would be aggregated by day and roadway type.
Calculation
Possible Sources
Can Vary By
Daily VMT *
TAG-6
Use Type, Age, Month, Day
Gallons Per Mile
NDB, User
Use Type, Age
TAG-8: Allocate Total Activity to Zone Location
Once total activity has been calculated for the modeling domain, geographic allocation is
necessary to estimate activity within each zone location. This will require the development of
geographic allocation factors for each zone location and activity basis. For the default level,
allocation factors will be developed to allow allocation from the national level to the county
level, and stored in the default county database (CDB). For domain-specific modeling, these
factors would be supplied by the user to allow allocation from the domain to the user-defined
zone level.
Source Hours Operating (Macroscale Only)
The allocation of domain-level total activity to the zone location level is a critical step for
SHO macroscale emission estimation. It will require allocation factors to be developed for each
zone location and emission process. Allocation factors for all emission processes will vary by
zone location and calendar year, which will allow them to account for location-specific
differences in growth.
SHO allocation factors will also vary by roadway type. This will enable location-specific
adjustments to be made to the roadway allocations previously. At the national level, default
allocation factors could be developed using a similar process employed in the development of
county & roadway level VMT estimates in the NEI, which relied on roadway length data.
Allocation factors would also allow for locality-specific growth, for which defaults could likely
be developed from census population growth estimates. Because extended idle will be treated as
an additional "roadway type", specific geographic allocations can be tailored to where
concentrations of extended idle are more likely (e.g., truck stops).
48
-------
Allocation factors would only be necessary for domain-level modeling if zone locations
smaller than the modeling domain were desired. One example of this might be the modeling of
grid cells within a modeling domain for input into emission processors like SMOKE.
Calculation
Possible Sources
Can Vary By
SHO*
TAG-7
Calendar Year, Use Type, Age,
Month, Day, Hour
SHO Geographic Allocation Factor
CDB, User
Calendar Year, Zone Location, Roadway
Type
Source Hours Parked
Allocation factors for SHP are independent from those for SHO, a significant shift from
the MOBILE modeling framework (which links evaporative emissions to miles traveled). This
change in approach for MOVES enables a decoupling of where vehicles travel and where they
park, which may vary greatly depending on whether one is considering an interstate in a rural
county or a urban area with heavy commuter influx. Whereas SHP depends on SHO at the
domain level, at the zone location level SHP will not depend on miles traveled or SHO in that
zone. This will allow SHP to be determined by variables which are more pertinent to vehicle
parking, such as number of parking spaces, office space, number of residences, etc. National
default allocations could be developed using these types of surrogates, from census data at the
county level.
Calculation
SHP:
SHP Geographic Allocation Factor
Possible Sources
TAG-7
CDB, User
Can Vary By
Source Hours
Calendar Year, Use Type, Age, Month,
Day, Hour
Calendar Year, Zone Location, Hour
For a given location, Source Hours is simply the sum of SHO and SHP within each zone
location; no allocation factor is necessary.
Calculation
Possible Sources
Can Vary By
SHO +
TAG-7
Calendar Year, Use Type, Age, Month,
Day, Hour, Zone Location
SHP
TAG-7
Calendar Year, Use Type, Age,
Month, Day, Hour, Zone Location
Number of Starts (Macroscale Only)
49
-------
Start allocation factors, as with SHP, are independent from SHO. This allows more
flexibility than MOBILE6, which links starts to miles traveled. The MOBILE6 approach
assumes that starts happen in proportion to where miles are traveled. By separating the allocation
factors, starts can be estimated at the local level based on parameters more directly related to
starts (which are generally the same as SHP), such as parking spaces and residential density.
National default allocations could be developed using these types of surrogates, from census data
at the county level.
Calculation
Possible Sources
Can Vary By
Number of Starts *
TAG-7
Calendar Year, Use Type, Month, Day,
Hour
Start Geographic Allocation Factor
CDB, User
Calendar Year
Gallons Refueled
Refueling allocation factors are also independent from SHO. This allows more flexibility
from MOBILE6, which links refueling to miles traveled. The MOBILE approach assumes that
refueling happens when miles are traveled. By separating the allocation factors, refueling can be
estimated at the local level based on parameters more directly related to refueling, primarily the
concentration of refueling stations. National default allocations could be developed using gas
station density. Allowing allocation factors to vary by hour will allow flexibility in assessing
programs such as Ozone Action Days, which encourage shifts in source refueling to evening
hours.
Calculation
Gallons of Fuel Refueled *
Refueling Geographic Allocation
Factor
Possible Sources
TAG-7
CDB, User
Calendar Year, Hour
Can Vary By
Calendar Year, Use Type, Month, Day
7.1.3. Operating Mode Distribution Generator
For on-road emissions, the second generator requiring significant mathematical
processing to calculate core model input is the Operating Mode Distribution Generator (OMDG).
The output of this generator is the distribution of operating modes as defined for each emission
process, for those emission processes which will break total activity into modes. A significant
design feature of MOVES is that the same operating mode distribution generation process can be
applied to each of the analysis scales.
Operating modes are defined as breakdowns of total activity necessary to reflect
differences in emission rates. The Emission Rate Database will contain emission rates broken
down by operating mode bin. Table 7-4 shows our proposed operating mode parameters for
50
-------
emission processes requiring further activity breakdown. Emission processes not listed will not
require the breakdown of total activity into modes.
A central feature of MOVES is that the design has been developed such that the same
definition of operating modes and the same operating mode-based emission rates will be applied
at all three analysis scales of the model. The Operating Mode Distribution Generator and
processes within the generator will function independent of scale.
Table 7-4: Operating Mode Parameters By Emission Process
Emission Process
Running Exhaust, Brake Wear, Tire Wear
Start Exhaust, Hot Soak
Diurnal
Running Loss
Operating Mode
Parameter(s)
Average Speed and Vehicle Specific
Power (VSP)
Soak Time
Tank Pressure
Time Since Start
Distributions for soak time and time since start will be stored directly in the Execution
Location Database; default values will be developed primarily from driving surveys. User-
supplied information from local surveys can be input to replace these defaults. For these modes,
the OMDG will simply transfer the distributions from the Execution Location Database to the
core model.
Vehicle Specific Power and Tank Pressure will require mathematical processing within
the OMDG to go from generally available input data to the distribution of modes according to the
parameters specified in Table 7-4. The step-by-step processes proposed for calculating operating
mode distributions for these parameters are discussed in the following.
7.1.3.1. Veh icle Specific Power
Vehicle Specific Power, or VSP, is generally defined as power per unit mass of the
source. The calculation of absolute power generally centers on the forces a vehicle must
overcome when operating on the road, including: acceleration, the force of gravity due to positive
road grade, tire rolling resistance, and aerodynamic drag. Normalizing this power by mass to
calculate VSP allows for this metric to be estimated based only on the instantaneous speed of the
vehicle and road grade, if assumptions for the coefficients of rolling resistance and drag are made
and no wind speed is assumed, as discussed by Jimenez.8 The basic concept of VSP has been
applied in numerous studies in different forms and has shown to be a useful metric for
characterizing vehicle emissions. As discussed by Jimenez, similar metrics have included
"Positive Kinetic Energy" (PKE) proposed by Watson et al.,9 and "Specific Power" employed in
studies such as EPA's FTP Revision Study10 and the development of MOBILE6 driving cycles,11
which were based on the product of speed and acceleration without consideration for road load
effects.
51
-------
We are proposing that MOVES use Vehicle Specific Power (VSP) to characterize
"modal" emission rates. The primary benefit of this metric is that it combines into a single
parameter numerous physical factors influential to vehicle fuel consumption and emissions:
vehicle speed, acceleration, road grade, and road load parameters such as aerodynamic drag and
rolling resistance. By normalizing the vehicle weight, we can directly calculate VSP knowing
only the driving pattern of a vehicle and road grade, if assumptions are made for road load
coefficients. An in-depth evaluation of the merits of using VSP will be presented in a separate
document detailing the MOVES emission analysis plan.
The implementation of VSP will take the form of bins defined by ranges of VSP. An
initial proposal for the definition of these bins has been developed for EPA by North Carolina
State University under contract to evaluate the VSP binning approach.12 These are shown in
Table 7-5. More detail on the development of these bins can be found in the report.
Table 7-5: Proposed VSP Bin Definitions
VSP Bin
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Definition (VSP in kW/Metric Ton)
VSP<-2
-2<=VSP<0
0<=VSP<1
1<=VSP<4
4<=VSP<7
7<=VSP<10
10<=VSP<13
13<=VSP<16
16<=VSP<19
19<=VSP<23
23<=VSP<28
28<=VSP<33
33<=VSP<39
39<=VSP
Further work by EPA, to be presented in a separate document, has determined that model
accuracy can be improved by using these VSP bin definitions in conjunction with average cycle
speed; from this finding we are proposing that operating mode bin definitions for the running
exhaust emission process be first subdivided by average cycle speed (for example: less than 20
mph, between 20 and 40 mph, and greater than 40 mph), then by the VSP bins shown in Table 7-
5. The operating mode distribution generator will produce the distribution of time spent in each
of these bins for a given roadway link. Default driving cycles will be used to calculate these
distributions within MOVES. We are proposing to base the calculation of average cycle speed
52
-------
and VSP bin distributions in MOVES on the MOBILE6 framework for facility-specific driving
patterns. MOBILE6 uses driving cycles to reflect varying Levels of Service by aggregated
facility type: freeway, arterial, and local roads. MOVES would extend these cycles to represent
travel on the 12 HPMS roadway types. With this approach, the user would interface with
MOVES at the level of average speed and facility type, which maintains consistency with the
MOBILE6 input structure. These driving cycles (expressed as second-by-second vehicle speed)
can be converted to VSP in each second, along with input factors such as road grade, rolling
resistance, and wind speed. We can then determine the distribution of time falling in the average
speed and VSP bins. This distribution would then be passed to the core model. The specific
steps for accomplishing this within the operating mode distribution generator are shown in Table
7-6:
Table 7-6: Overview of Operating Mode Distribution Generation For VSP
Step
OMDG-1
OMDG-2
OMDG-3
Determine Distribution of Driving Cycles
Calculate Second-By-Second VSP
Calculate VSP Bin Distribution
Vary by Scale?
No
No
No
OMDG-1: Determine Distribution of Driving Cycles by Use Type, Roadway Type
For the given roadway link being analyzed, the initial inputs to the OMDG will be
average speed (or speed distribution) by vehicle use type and HPMS roadway type. National
defaults will be available for macroscale analysis, likely derived either from the roadway-specific
speeds used in the NEI or those derived as defaults for MOBILE6. Users can supply local
information on average speeds from sources such as speed studies or transportation models.
The MOVES Execution Location Database (ELD) will store driving cycles that represent
fixed average speeds on specific roadway types. As mentioned, the national defaults will be
available to all analysis scales based on the facility-specific driving patterns developed for
MOBILE6. These will be stored as second-by-second speed trajectories. Users can input
alternate second-by-second speed trajectories by average speed and HPMS roadway type from
sources such as instrumented vehicles or output from transportation models.
Under this step the average speed or speed distribution will be mapped to the driving
cycles stored in the ELD, using a "bracketing" approach. The determination of "bracket" speeds
on a given roadway link would take the average speed and find the next highest and next lowest
speeds for which driving patterns are stored, by the roadway type being modeled. Weights
would then be applied to the "bracketed" driving cycles to match the average speed being
modeled. If a speed distribution was supplied, this process would be repeated for each individual
speed point and the overall driving cycle mix reweighted to match the input speed distribution.
53
-------
Because it is proposed that average cycle speed bins will be used in conjunction VSP bins
to further refine model, this process would be repeated within each average speed bin.
OMDG-2: Calculate Second-By-Second VSP For Relevant Driving Cycles
For each driving cycle mapped in the previous step, Vehicle Specific Power would be
calculated on a second-by-second basis using the following equation:
VSP = v * (a*(l+e) + g*grade + g*CR) + 2p*CD*A*v3/m
where:
v: is vehicle speed (assuming no headwind) in m/s
a: is vehicle acceleration in m/s2
e: is mass factor accounting for the rotational masses
g: is acceleration due to gravity
grade: is road grade
CR: is rolling resistance
p: is air density
CD: is aerodynamic drag coefficient
A: is the frontal area
m: is vehicle mass
Speed and acceleration in each second would be supplied directly from the drive cycle
used in the calculation. Default values of the other variables would be stored in Execution
Location Database, with the opportunity for users to supply custom information. The default
value for grade would be zero; we propose that users could enter grade information by roadway
link for mesoscale or microscale analysis only. Defaults for vehicle-related parameters such as
rolling resistance, drag coefficient, frontal area, and vehicle mass would be available by vehicle
use type category and could be replaced by user-supplied input.
OMDG-3: Calculate VSP Bin Distribution
For each driving cycle, second-by-second VSP calculations from the previous step would
then be binned, according to the definitions in Table 7-5, by calculating the frequency of VSP
occurrences in each bin. Within each average speed bin the overall VSP distribution for a given
roadway link and use type would then be calculated by multiplying the VSP bin distributions
from each relevant driving cycle with the distribution of each driving cycle calculated in Step 1.
These VSP bin distributions would be multiplied by the average speed bin distribution to
generate the the final operating mode distribution across average speed/VSP bins. The extended
idle roadway type will, by definition, have 100 percent operation in VSP Bin 3, which includes
idle operating. The resulting VSP bin distribution by use type and roadway link would be
forwarded to the core model.
54
-------
7.1.3.2. Tank Pressure
We propose using tank pressure as the basic parameter for distinguishing diurnal
emission rates. Diurnal emissions are generally caused by an increase in tank pressure due to
temperature rise. Hence, a simple division of tank pressure modes could be increasing pressure,
stable pressure, or decreasing pressure.
7.1.3.3. Soak Time and Time Since Start
As mentioned, Soak Time and Time Since Start will not require calculations within the
OMDG. The level of disaggregation is shown in Table 7-7 for each related process.
Table 7-7: Level of Disaggregation for Soak Time and Time Since Start
Non-Calculated Operating Mode Parameter(s)
Soak Time
Time Since Start
Can Vary By
Use Type, Day of Week, Hour
Use Type, Day of Week, Hour
7.2. Off-Road Implementation
The fundamental underpinnings of the core model apply to off-road sources as well as on-
road sources: all sources have total activity, a distribution of that activity into specific modes,
and emission associated with those modes. The differences between on-road and off-road
sources will be handled through unique total activity and operating mode distribution generators.
We are proposing, as an initial step, that these front-end generators be developed specifically to
support macroscale analysis of off-road sources (including commercial marine, aircraft, and
locomotives), at the same two sublevels applied for on-road. The national default level would
function similar to the current NONROAD model, producing county-level emissions for the
entire country. The domain level would allow users to model specific areas, but would require
the input of domain-specific inputs for calculating total activity. Finer scale analyses of
nonroad would be possible with direct interaction of the core model if the user had fleet and
activity data for the area being modeled.
7.2.1. Total Activity Generation
Because the development of an off-road implementation will follow that of an on-road
implementation, at this stage we are merely presenting options for how total activity would be
accounted for with off-road sources. For starters, we propose that off-road emissions be
modeled in a more aggregate way than on-road emissions in several ways. First, the emission
processes presented in Table 3-1 for on-road would likely be reduced to (a) exhaust, (b)
crankcase, (c) diurnal, (d) resting loss, (e) running loss, and (f) refueling. The total activity basis
for each process defined in Table 3-2 would remain the same, reflecting the broad applicability of
the core model design. A primary reason for adopting the time-based activity approach is, in
fact, to accommodate off-road emissions.
55
-------
Three options we are aware of for generating total activity for off-road emissions are as
follows:
Population Method: Continue the approach currently used in NONROAD, which is
based on estimates of equipment population and per-vehicle hours operating from
survey data. The total activity generator would take these inputs, apply growth and
scrappage as necessary, and multiply analysis year population and per-vehicle hours
to generate Vehicle Hours Operating across the modeling domain, by source class.
Other activity basis (e.g., SHP) would be linked to population and SHO.
Surrogate Method: Develop relationships between surrogate inputs, such as tillable
acres, housing starts, etc., and total activity for specific source classes. The total
activity generator would take these surrogates as input and apply these relationships to
generate SHO across the modeling domain. Other activity basis (e.g., SHP) would be
linked to SHO.
Density Method: Develop estimates of activity (SHO) density for specific source
classes and land use types. The total activity generator would take these density
estimates and extrapolate them to the modeling domain based on domain size and
land-use mix. Other activity basis (e.g., SHP) would be linked to SHO or would have
unique activity density estimates.
Each of these three methods would generate total activity across the entire modeling
domain. The total activity generator would then allocate to specific locations (county or user-
defined, such as grid) using geographic allocation factors stored within the Execution Location
Database. The current NONROAD model uses this approach.
7.2.2. Off-Road Operating Mode Distribution Generation
We propose the application of operating modes for off-road be at a more aggregate level
than for on-road. Primarily, we are proposing not to break SHO into modal (power-based) bins.
The level of disaggregation is likely less necessary for off-road than for on-road. At the far
extreme, it may be viable for a first iteration to not split total activity into operating modes at all
(as done in the current NONROAD model), which would mean that an OMDG was not needed
for the off-road implementation. An in-between option would be to consider very coarse
operating modes, such as idle and non-idle.
56
-------
8. Software Implementation
MOVES will be executed using specific software tools and techniques. In this section,
we explain our key decisions and requirements in choosing a specific programming language and
database. We also briefly describe our work on a distributed processing system, which will
increase the speed of doing many runs and be easy for users to implement.
To actually guide the selection of software development methods and tools, it is desirable
to focus on the specific requirements that have been discussed. From these we know that the
software methods and tools chosen to develop MOVES should:
Be state of the art.
Encourage, via conventions and standards related to the tools, good design and
programming practices and documentation.
Promote an object-oriented approach to software design and development.
Operate on, and produce model products that operate on, current and future EPA
desktop computers that are Intel style PCs using the Windows software operating
system.
Produce model products which are easily ported to other platforms, (e.g., Linux and
Unix-based systems)
Produce products that do not require the end user to purchase software licenses
beyond a software operating system.
Facilitate development of graphical user interfaces in addition to more traditional
ASCII text file input/output.
Facilitate, or at least be compatible with, use of MEVIS, a modeling framework being
developed by EPA/ORD.
Execute in an acceptable amount of time. We know from the current MOBILE and
NONROAD models that MOVES is intended to replace, and from the use cases
intended for MOVES, that model execution time performance is an important
consideration.
Employ standard methods and tools. It is always a good idea that the methods and
tools chosen be widely used in the industry and have a promising future. (Though it
is often difficult to see very far ahead.) There isn't anything so demanding or
specialized about the MOVES software requirements that one would expect unusual
methods or approaches to be needed.
Because MOVES represents a significant and long term departure from current
EPA/OTAQ models, it is not of high importance, as it would be for many projects, that the
methods and tools chosen be ones with which EPA/OTAQ and its contractors are currently
familiar.
57
-------
8.1. Software Development Methods Chosen for MOVES
The scope of intended use cases for MOVES is sufficiently broad that a framework for
MOVES and its implementations should be explicitly designed, and these designs documented,
in some detail. On the other hand MOVES is not so complex that a highly elaborate or formal
design approach is needed. Indeed, this is not desirable since detailed requirements are apt to
evolve throughout the project and cannot be fully known at the outset.
This consideration has lead us to an approach which attempts to blend the best aspects of
traditional, structured software development with those of a newer approach called "extreme
programming." This new approach is adapted to the reality that software requirements cannot be
known in advance and are often discovered by repeated iterations of development and testing in
which the end user is directly involved. For more information on this approach the reader is
referred to Extreme Programming Explained by Beck.13 Automated testing is an aspect of
extreme programming which we intend to use for MOVES, writing tests concurrently with the
software, and maintaining a suite of tests that can be run at any time to verify that the software
has not been "broken" by subsequent changes.
Perhaps of most general significance, we have adopted the practice of iterative software
design and development. This means that the usual development life cycle of design,
programming, and testingleading to eventual product release and usewill be repeated many
times, allowing EPA to gain expertise and for MOVES to develop incrementally. This will allow
us to work closely with customers, for requirements to change, to get rapid feedback, and to
produce frequent internal and external product versions.
Additional detail regarding the coding standards being adopted for MOVES and plans for
software documentation, version control, and testing will be documented in the Quality
Assurance Program Plan for the project.
8.2. Software Development Tools Selected for MOVES
Of the many software tools used in this project, we felt two areas needed some discussion
about what we choose and why: programming language and Database Management Software
(DBMS).
8.2.1. Programming Language
While Fortran has been used for past and current EPA/OTAQ models and is still an
excellent language for mathematical computations, it is not strong with regard to object
orientation, is not particularly platform independent, and is certainly not a good choice for
graphical interfaces. So our requirements really narrow the choice of reasonable language
alternatives for MOVES to either Java or C++.
We have made a preliminary decision to program MOVES with the Java programming
language as defined by SUN's Java System Development Kit (SDK). It is a state-of-the-art,
58
-------
widely used, object-oriented, programming language, which has enjoyed considerable success
over the last several years and appears to have a promising future, independent of the fate of any
particular company. With its "write once, run anywhere" philosophy, it offers the highest degree
of platform independence of any language available. Java comes with a set of associated tools,
such as Javadoc, which lead to relatively uniform coding and documentation practices. Java is
the native programming language of MJJVIS and so using Java maximizes our ability to take
advantage of MJJVIS. (An initial example of this is that we have made a preliminary decision to
adopt the MJJVIS Java Programming Standard as the basis of the MOVES programming
standard.) Sun's implementation of Java is the most widely used and clearly the most
committed to remaining industry standard.
Java is ideal with respect to all of the MOVES software requirements except execution
speed performance. Because it is a partially compiled and partially interpreted language, its
execution time performance will never be as rapid as fully compiled languages such as Fortran or
C++. On the other hand we don't know exactly where MOVES performance bottlenecks will
occur or how much of a problem they might be. Also Java performance has improved and is
likely to continue to improve with future versions. We realize that it may eventually be
necessary, if portions of MOVES written in Java prove to be performance bottlenecks, to convert
them to another programming language, such as C++.
The SDK includes Javadoc, a utility program that produces HTML-based software
documentation from comments embedded in the Java programming code. The MOVES project
has incorporated Javadoc commenting conventions in its coding standard and intends to use
Javadoc as its principal software documentation tool.
8.2.2. Database Management Software (DBMS)
As described earlier in this document, MOVES is data driven, meaning that its emission
rates are primarily determined by looking them up in a database. Input and output data are also
in databases. Furthermore, it is a fundamental objective of MOVES that it be able to incorporate
new vehicle population, vehicle activity, and emission measurement data easily. Given the
complexity of such data, and the limited input/output capability of the Java and C++
programming languages, there is a strong requirement that MOVES include relational database
management software (RDBMS) for the loading, storage, and (especially) retrieval of
information. For this RDBMS to be state-of-the-art, platform independent, and in widespread use
further dictates that it allow the use of SQL (Structured Query Language) for database operations.
We investigated the two principal open-source RDBMS in widespread use, MySQL and
PostgreSQL. PostgreSQL requires an additional, separate product to implement as a server on
Windows-based systems and, so, is not available in a form that would allow the entire MOVES
model to run on the EPA desktop platform. MySQL is written in C++ and, so, is reasonably
platform-independent. Executable versions are also available for a variety of Windows and Unix
platforms. While lacking some high-end features, run time performance has been given major
consideration in MySQL, so it might be able to compensate for the relatively slow performance
59
-------
of Java programs. MySQL, therefore, appears to meet all of our relevant software requirements
and is the tool we have selected.
8.3. Distributed Processing
Distributed processing is a method used to speed model execution by dividing up a
lengthy calculation and distributing separate portions of it to multiple computers or computing
systems. The multiple separate results are then collected together into a final, collated result. In
MOVES, a run for a single time and location is expected to execute quickly. There are, however,
important use cases for which thousands of time-location runs are required. Examples include
generating national annual inventories at the county level, preparing inputs for gridded air quality
models, and assessing uncertainty using Monte Carlo methods. Such lengthy calculations take
weeks to run using MOBILE and NONROAD, and are anticipated to take similarly long periods
using MOVES. Fortunately, the calculation for any time-location combination is completely
independent of all the other time-location combinations, making it straightforward to divide these
calculations between many computers.
Two methods under consideration for distributed processing in MOVES are grid
computing and Beowulf clusters. Grid computing requires only a network of computers with
access to a shared hard drive. An example would be a typical office network with many desktop
computers with access to a common folder on a hard drive on a server computer. A Beowulf
cluster requires Beowulf software and a dedicated group of machines that are all connected
together on their own network. There is a master machine which distributes software and data to
worker machines. The workers run the calculations and return the data to the master. Much
software to run Beowulf clusters is free, and many organizations have set them up to handle
various intensive computing tasks.
Because both of these methods for distributed processing are widely used, we plan to
program MOVES to be able to use either one or both of them together. Our general scheme is
for there to be a Master MOVES, which would reside on analysts' desktop machines and would
set up and initiate the run, collect and collate the results, and produce final output. The Master
would also divide up the calculation and distribute it to Worker MOVES via a shared hard drive
on a server. The workers would perform the calculations and return the results to the shared
drive. This basic scenario would work with both the grid computing and Beowulf clusters,
although small differences would exist between the Beowulf workers and the grid computing
workers.
References
1 National Research Council. 2000. Modeling Mobile Source Emissions. National Academy
Press; Washington, D.C.
2 U.S. EPA. April 2001. EPA 's New Generation Mobile Source Emssions Model: Initial
60
-------
Proposal and Issues. EPA420-R-01-007. Office of Air and Radiation, Ann Arbor, MI.
3 Houghton, J.T.; Meira Filho, L.G.; Lim, B.; Treanton, K.; Mamaty, L; Bonduki, Y.;
Griggs, D.J.; Callendar, B.A.; editors. 1996. Revised 1996IPCC Guidelines for National
Greenhouse Gas Inventories Reference Manual. Intergovernmental Panel on Climate Change
(http://www.ipcc.ch/pub/guide.htm).
4 Barm, M.; An, F.; Younglove, T.; Scora, G.; Levine, C. April 2000. Development of a
Comprehensive Modal Emissions Model: Final Report. Prepared for National Cooperative
Highway Research Program under NCHRP Project 25-11.
5 Cullen, Alison C.; Frey, H. Christopher. 1999. Probabilistic Techniques in Exposure
Assessment. A Handbook for Dealing with Variability and Uncertainty in Models and Inputs.
Plenum Press, New York.
6 Bachman , William H. August 1998. A GIS-Based Modal Model of Automobile Exhaust
Emissions.EPA-6QQ/R-98-Q97. Prepared by School of Civil and Environmental Engineering,
Center for Geographic Information Systems, Georgia Institute of Technology, Atlanta, Georgia
30332, under EPA Cooperative Agreement CR823020.
7 U.S. EPA. September, 1995. User's Guide to CAL3QHC Version 2.0: A Modeling
Methodology for Predicting Pollutant Concentrations Near Roadway Intersections. EPA-454/R-
92-006. Office of Air and Radiation, Research Triangle Park, NC.
8 Jimenez-Palacios, J. February 1999. Understanding and Quantifying Motor Vehicle
Emissions and Vehicle Specific Power with TILDAS Remote Sensing, MIT Doctoral Thesis.
9 Watson, H.C.; Milkins, E.E.; Preston, M.O.; Chittleborough, C.; Alimoradian, B. 1983.
Predicting Fuel Consumption and Emissions Transferring Chassis Dynamometer Results to
Real World Driving Conditions, SAE Technical Paper Series, 830435.
10 U.S. EPA. May 1993. Federal Test Procedure Review Project. EPA420-R-93-007.
Office of Air and Radiation.
11 Carlson, T.R.; Austin, T.C. October 1996. Development of Speed Correction Cycles.
Prepared for EPA by Sierra Research, Inc.
12 Frey, H. Christopher; Unal, Alper; Chen, Jianjun; Li, Song; and Xuan, Chaoting. August
31, 2002. Methodology for Developing Modal Emission Rates for EPA 's Multi-scale mOtor
Vehicle & equipment Emission System. Prepared for OTAQ, U.S. EPA by Department of Civil
Engineering, North Carolina State University, Raleigh, NC.
13 Beck, Kent 2000. Extreme Programming Explained. Addison-Wesley, New York.
61
-------
Appendix A to Draft Design and Implementation
Plan for EPA's Multi-Scale Motor Vehicle and
Equipment Emission System (MOVES)
EPA MOVES
RunSpec GUI Details
September 23, 2002
Revision 3
Cimulus, Inc.
US EPA
1. Introduction
This document describes the MOVES Design Team's detailed design of the GUI used to setup a MOVES
Run Specification ("RunSpec"). Like other aspects of this model, the GUI design is iterative and likely to
change as the model is developed.
1. Introduction 1
2. RunSpec UI Overview 2
3. Description 3
4. Scale 4
5. Macroscale Geographic Bounds 4
6. Mesoscale Geographic Bounds 5
7. Time Spans 6
8. On Road Vehicle Equipment 7
9. Off Road Vehicle Equipment 7
10. Off Road SCC Vehicle Equipment 8
11. Road Type 8
12. Pollutants and Processes 9
13. Internal Control Strategies 11
14. Manage Input Data Sets 12
15. Uncertainty 12
16. Geographic Output Detail 13
17. Output Emissions Breakdown 14
18. General Output 15
19. Additional Outputs 16
20. Other UI Notes 16
21. Revision History 16
MOVES RunSpec GUI Details Rev.3 US EPA Page A-l
-------
2. RunSpec Ul Overview
Ctrl+N
Ctrl+O
I Save Ctrl+S
5ave As...
There will exist a top-level menu that will contain a section for the RunSpec. The options will be typical of
those used when manipulating documents: New, Open, Close, Save, and Save As. These will allow
RunSpec objects to be created, loaded from disk, and saved to disk.
When editing a RunSpec object, the RunSpec UI will appear, typified by the display shown below. It is
likely that this UI will be shown below the top-level menus just as documents are shown in other standard
programs such as Excel, Word, and WordPerfect.
MOVES RunSpec GUI Details Rev.3
US EPA
Page A-2
-------
The UI shown above is conceptually split into two halves: the navigation list (in green on the left) and the
detail panel on the right. Selecting an item from the navigation list will place that item's detailed UI into
the right hand side. The detail panels are shown in the following sections. For example, the above graphic
depicts the selection of the "General" subsection within the "Output" section.
The RunSpec navigation list depicts a tree-like structure of areas of the RunSpec's information. Some
sections, such as "Control Strategies" and "Output", contain subsections. These sections are shown with an
icon (Lll) that allows the list of subsections to expanded or collapsed.
RunSpec navigation list items are shown with an icon that indicates the completeness of the RunSpec in
that section, as shown in the table below:
Icon Meaning
Needs additional user supplied data.
Filled in sufficiently to run.
Default data present, but otherwise filled in sufficiently to run.
I Tree close/expand
Note the icons shown on the sample UI are not necessarily indicative of which sections/subsections will
have default data available.
3. Description
Description:
This is the description of the RunSpec,
Every RunSpec can have a description, which is a free form block of user-supplied text. This text can be
up to 5000 characters in length.
The default description is blank and the model can be run without a description.
MOVES RunSpec GUI Details Rev.3
US EPA
Page A-3
-------
4. Scale
Scale;
$> iMacroscale - simulation of county level and higher structures !
ฎ Mesoscale - simulation of links and_zgnes_(ajb^cgurity level structures)
Input Database: | _ฃj
4ฎ Microscale - simulation of small, highly detailed structures
Input Database: | _^J
The user must choose a scale at which the model will operate. In fact, the selection of scale determines
which geographic panel will be presented and may affect availability of other panels as well.
When the user selects "Mesoscale", the "Input Database" controls for it are enabled. In order to use
mesoscale, the user must provide a database with the links and zones that they may want to use. The
geography panel(s) will let the user select the subset of those in the database, but the database must be
provided.
Microscale operates similarly to Mesoscale with regard to the need for the user to supply input data that, in
turn, provides bounds for geography (and perhaps time span) selections.
There is no default scale and the model cannot be run without a scale selection.
5. Macroscale Geographic Bounds
Region:
f Nation
r State
(" iCounty j
States:
Counties:
Selections:
Select All Add Select All Add
Delete
When using the model at the Macroscale level, the geographic selection must yield a list of county-state
combinations. This can be quickly accomplished by selecting "Nation", in which case the additional
controls shown on this screen, including the Selections, will be hidden.
Selecting "State" will present the user with the list of states but will hide the Counties controls. The user
can then highlight and Add individual states one at a time or can select all States at once.
Selecting "County" will present the user with the list of states (without its "Select All" and "Add" buttons)
as well as the list of Counties (with its "Select All" and "Add" buttons). The user can then select a State to
see the list of Counties within and Add them individually or in large groups using the County's Select All
button.
There is no default selection for this panel and the model cannot be run without a selection on this panel.
MOVES RunSpec GUI Details Rev.3
US EPA
Page A-4
-------
6. Mesoscale Geographic Bounds
Region;
f* County
f* jZone/Linki
States;
Counties;
Zone;
Zone Links;
Selections;
Add Select All Add Select/
Add
County Links;
Select All Add
Delete
When operating the model at the Mesoscale level, the geographic selection must yield a list of links and
zones along with their respective counties. This can be accomplished quickly by selecting "County", in
which case the Zone, Zone Links, and County Links controls will be hidden and the user can Add all the
zones and links within individual counties. Note that lack of a "Select All" button for Counties because it
is believed that Mesoscale runs will not be performed over all zones and links within a State.
Selecting "Zone/Link" will show the controls as depicted above, except for the "Add" Counties button, and
allow the user full control over which links and zones will be included. Note that both Zones and Links are
contained within Counties but not all Links are contained within Zones. This necessitates the two list
approach shown above in which the user can select a county then links within the county without first
selecting a zone.
The list of states, counties, zones, and links will be drawn from the user's data provided when they selected
the scale.
There is no default selection for this panel and the model cannot be run without a selection on this panel.
MOVES RunSpec GUI Details Rev.3
US EPA
Page A-5
-------
7. Time Spans
Year: j
Month; |
Day: |
Hour; j
1 Time Zone: |
i I")! irahnn
3 |
jj
_d
jj
^^JJ
Selections;
i r
2002-Jan-1 00:00,Locals days
Add
Delete
A single RunSpec can specify one or more time spans to be modeled. Each time span has a starting time
and a duration. No two time spans can overlap in any fashion.
The starting time of each individual time span can be absolute (that is, relative to GMT) or determined from
the local time of the location it is applied to. The "Local" time zone is the default time zone. The start
time's resolution is hourly for Macroscale and Mesoscale. That is, the start time is specified as the start of
a single hour on the clock. Thus, a start time of 2002/Jan/Ol 15:54 is not possible. Microscale allows start
times at YA hour increments and would list the hours as "00:00", "00:15", "00:30", etc. rather than display
yet another dropdown list.
The duration of each individual time span is set as an integral number of hours, days, months, or years from
the start. Thus, a duration of 0.5 years is not possible but 6 months is allowed. Internally, the model will
choose a temporal looping method that is compatible with the durations and output detail selected.
Additionally, Microscale models will be allowed to choose a duration of YA hour increments.
The "Add" button will give an error message if an attempt is made to add a time span that overlaps the
existing selections.
In the above panel, the user sets the start and duration then uses the "Add" button. Selecting an existing
time span in the "Selections" list enables the "ซ" and "Delete" buttons but does not otherwise affect the
Start and Duration controls.
The "ซ" button populates the Start and Duration controls with a copy of the information contained in the
current selection. Subsequently changing the Start/Duration controls then using Add does not, however,
modify the existing selection. This feature is intended to be used by those wishing to model a single month
within several years so that they may vary the year with each "Add" operation.
There is no default selection for this panel and the model cannot be run without a selection on this panel.
MOVES RunSpec GUI Details Rev.3
US EPA
Page A-6
-------
8. On Road Vehicle Equipment
Fuels; r Vehicle Category 8t Type
Select All
Selections;
Category;
MOVES Type;
Select All
Select All
Delete
Add Fuel/Vehicle Category & Type Combinations
This panel allows the user to select which, if any, on road vehicles are to be modeled. The user must select
from two distinct dimensions ("Fuels" and "Vehicle Category & Type") then choose to model their cross
product.
Within the "Vehicle Category & Type" dimension, there is a hierarchy of "Category" and "MOVES Type".
Choosing the cross product of a Fuel and a single Category is modeled identically to choosing the cross
product of a Fuel and all the MOVES Types within the Category.
The default selection on this panel is to choose everything and the model can be run without a selection on
this panel as long as some vehicle type has been selected on one of the Vehicles panels.
9. Off Road Vehicle Equipment
Fuels;
Segments;
Selections:
Select All
Select All
Delete
Add Fuel/Segment Combinations
This panel allows the user to select which, if any, off road vehicles are to be modeled. The user must select
from two distinct dimensions ("Fuels" and "Segments") then choose to model their cross product.
It is expected that the selections on this panel will overlap somewhat with those on the "Off Road SCC
Vehicle Equipment" panel (see next section). Internally, the model will combine the selections on this
panel and the other vehicle panels to arrive at the unique set of vehicles to be modeled.
The default selection on this panel is to choose nothing and the model can be run without a selection on this
panel as long as some vehicle type has been selected on one of the Vehicles panels.
MOVES RunSpec GUI Details Rev.3
US EPA
Page A-7
-------
10. Off Road SCC Vehicle Equipment
Partial SCC; |f
Selections:
##### Some Description
##### Another Description
Select All
##### Some Description
##### Another Description
Delete
This panel allows the user to select which, if any, off road vehicles are to be modeled. The user must input
a partially or fully complete SCC code for off road sources then select one or more fully complete SCC
codes.
Due to the extensive nature of the full SCC listing, the list of SCC codes will only show those matching the
user's partial search and will not initially be populated with the entire SCC code list.
Both of the displayed SCC code lists will show the SCC code and its description.
It is expected that the selections on this panel will overlap somewhat with those on the "Off Road Vehicle
Equipment" panel (see previous section). Internally, the model will combine the selections on this panel
and the other vehicle panels to arrive at the unique set of vehicles to be modeled.
The default selection on this panel is to choose nothing and the model can be run without a selection on this
panel as long as some vehicle type has been selected on one of the Vehicles panels.
11. Road Type
HPMS Road Types;
Selected Road Types;
abc
def
ghi
jW
mno
qrs
hiv
SeleotAllJ
jj
3
d
Add
abc
def
ghi
jld
mno
qrs
hiv
d
3
d
Delete
This panel is available if the user has selected any on road vehicles to be modeled. All controls are
disabled otherwise.
The list of HPMS Road Types is taken from a master list of roadway types in the database and is not
filtered to only those roadway types actually present in the geographical range selected.
The default selection on this panel is to choose all roadway types and the model cannot be run without a
selection on this panel if there are on road vehicle types selected.
MOVES RunSpec GUI Details Rev.3
US EPA
Page A-8
-------
12. Pollutants and Processes
Exhaust Y
Evaporative v
Brake
Wear v
Tire
Wear Y
|0ione >
HC >
CO >
NOx >
[Greenhouse >
C02 >
CH4 >
Carbon Equiv. >
|Aerosols >
Tire Particles >
Brake Particles >
Lead Particles >
Elemental Carbon >
Organic Carbon >
Sulphate >
Gaseous S02 >
Gaseous NH3 >
|Toxics >
Benzene >
Formaldahyde >
V
0
Ef
0
0
0
0
0
0
0
0
0
0
0
0
V
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Y
0
0
Y
0
0
0
Y
0
0
Y
0
0
HCi
PM Size:
[Select AIM
Clear
microns
Note that this panel is illustrative, rather than comprehensive. As MOVES is developed, the exact choice
of pollutants and processes may change.
This panel, while complex in general appearance, is used denote which processes and pollutants the user
wishes to have calculated. It shows the relationship between process and pollutant and allows the user to
perform single selections (via 0) as well as group selections (via ^ and V).
When any paniculate aerosol is selected, the PM size controls will be enabled. The user can select 2.5
micron, 10 micron, or "Other" and then provide a custom micron size. The PM size selected applies to all
particulates selected.
When HC is selected, the HC controls will be enabled. The user must select a method to express
hydrocarbons as from the list: NMHC, NMOG, THC, VOC, ROG, and TOG.
MOVES RunSpec GUI Details Rev.3
US EPA
Page A-9
-------
When selecting an entire row (^) or an entire column (V), the likely algorithm to be implemented will
examine the row or column and determine if there is a mixture of selected (0) and unselected items (D).
If there is no mixture, then all checkboxes in the row/column will be inverted (selecting those that
were unselected and unselecting those that were selected). This allows entire rows/columns to be
toggled quickly.
If there is a mixture, then unselect all selections outside of the row/column. This allows
intersections of rows/columns to be made quickly.
Thus, clicking "Exhaust V" will select the entire columns for "Running" and "Starting". Then, selecting
"Greenhouse ^" will reduce the selection to only the intersection of Exhaust and Greenhouse.
Note that the above display is only meant to illustrate the desired UI principle. It is not meant to be
scientifically accurate or complete. It is also expected that the grids will scroll both vertically and
horizontally to accommodate larger listings of processes and pollutants.
MOVES RunSpec GUI Details Rev.3 US EPA Page A-10
-------
13. Internal Control Strategies
Cqnfftjl
Details j Geography | Time j Vehicles
Save.,.
Delete
New...
I Load.,.!
"Internal Control Strategies" are actually objects stored within the RunSpec. As objects, they have
individual values for member variables and belong to a class.
The finite set of classes supported by the model are listed on the RunSpec navigation list. The user picks
one of these classes and is then presented with the above panel which shows the Control Strategy objects of
that class that are actually loaded into the current RunSpec.
When the user selects an object, a class-specific UI is shown in the "Details" tab with object-specific
values. Object-specific values are also shown in the tabs "Geography", "Time", and "Vehicles" which are
common to all classes of Control Strategies. The UI for these common tabs is currently unspecified but
should take the form of equivalent panels elsewhere in this GUI.
The user can save individual objects to disk with the Save button.
The user can remove an object from the RunSpec using the Delete button.
The user can instantiate an object of the current Control Strategy class using the New button.
The user can load a previously saved Control Strategy object of any supported class by using the Load
button.
By using the Save and Load features, users can create control strategies that are used by many RunSpecs
but without the risk of changing data for use in one RunSpec and having an unexpected change occur in
another, as would happen if the objects were external to the RunSpec.
MOVES RunSpec GUI Details Rev.3
US EPA
PageA-11
-------
14. Manage Input Data Sets
Server: I Selections;
Database; | ~
Description; |
Create Database,.,
Servl/Dbl /Michigan Weather
5ervl/Dbl/CA Weather
Add Move Up Move Down Delete
This panel is used to specify additional databases to be read by the model during execution. These
databases must adhere to the MOVES schema and use the DBMS used by MOVES.
Users can create a new database on an existing local or remote server by using the "Create Database"
button.
The data in these databases will "overlay", that is augment or fully/partially replace, data from the MOVES
default data for the duration of the model run. Thus, the order in which these databases are applied to the
default data is important. The "Move Up" and "Move Down" buttons are used to modify the order in
which a particular database selection is used. Databases at the bottom of the list are applied last.
Technically, the input databases on the Scale panel are input data sets, but they are required for user input
whereas contents of databases listed on this panel are not read by the UI but only during model execution.
The input databases on the Scale panel are always read first followed by the selections on this panel.
The "Add" button validates that the combination of server and database is unique within the selections.
There are no default selections for this panel and the model can be run without any selections on this panel.
15. Uncertainty
W Estimate Uncertainty
Number of Runs per Simulation: |5
Number of Simulations: J25
^\ Warning: Based on your inputs, the
execution time is likely to be 125 times
the single run time,
This panel is only an example of how we might present an iterative, Monte Carlo-type method of
estimating uncertainty. We may also implement alternative, non-numerical methods of error propagation.
The "Estimate Uncertainty" checkbox defaults to unchecked/Off. When unchecked, all other controls on
this panel are disabled.
A warning icon and wording is shown to the user whenever their selections would run the model more than
1 time. Due to time variances of computing hardware, no time estimate for completion will be given.
The model can be run without enabling uncertainty.
MOVES RunSpec GUI Details Rev.3 US EPA Page A-12
-------
16. Geographic Output Detail
("" Nation
f [State !
f* County
<~ Road Type
("" Link 8t Zone
This panel sets the level of geographic detail used for the "Location" dimension of the output data. The
number of output records generated is directly related to the level of detail chosen on this panel. For
instance, should a user select "County", then the database will contain an aggregated record for each county
(among other output dimensions of course) and information about the portions that Road Types contributed
to the county total will not be available. However, it is expected that choosing "County" will still allow
reporting to be aggregated to the State and National levels.
For Macroscale operation, the "Link & Zone" option is disabled.
For Macroscale operation, the default on this panel is "County". For Mesoscale operation, the default is
"Link & Zone". The model cannot be run without a selection on this panel.
MOVES RunSpec GUI Details Rev.3 US EPA Page A-13
-------
17. Output Emissions Breakdown
Always
fr IIFlie
W Location
P? Pollutant
"All
W Model Year
I Fuel Type
If" Emission Process
W Distinguish Particulates
W On Road/Off Road
un Koad
|~ Road Type
I" Category
W MOVES Vehicle Type
rscc
F" Segment
W iscc i
W HP Class
This panel allows the user to specify additional dimensions to the output data. The output data will always
contain dimensions for time, location, and pollutant. The granularity of the time dimension is set on the
"General Output" panel as the "Output Timestep". The location dimension is set on the "Geographic
Output Detail" panel. The pollutant dimension is implicit and is not otherwise set.
The dimensions that apply to both on road and off road sources are Model Year, Fuel Type, and Emission
Process. Technically, "Distinguish Particulates" is not a dimension but rather causes the particulates
pollutants to be reported as separate pollutants rather than as a single aggregate paniculate count. Any
combination of the "All" dimensions may be selected.
Should the user decide to distinguish on road sources from off road sources, additional options become
available. On road allows Road Type, Category, MOVES Vehicle Type, and SCC to be selected. Off
Road allows Segment, SCC, and HP class. Each of these two groups has internal interdependencies
between the allowed dimensions:
If On Road SCC is used, no other On Road option may be used.
Zero or one of On Road Category and On Road MOVES Vehicle Type may be used. Thus,
checking On Road's Category would disable On Road's MOVES Vehicle Type and vice versa.
Zero or one of Off Road Segment and Off Road SCC may be used.
Off Road HP Class is independent of the other Off Road options.
If any On Road or Off Road option is selected, the On Road/Off Road option is automatically
implied.
However, selecting the On Road/Off Road option does not imply that any On Road or Off Road
options must be selected.
The default on this panel is to use the implied "Time", "Location" and "Pollutant" dimensions. The model
can be run without user selections on this panel since there are always implied output dimensions.
MOVES RunSpec GUI Details Rev.3
US EPA
Page A-14
-------
18. General Output
r Output Database
Server: | Database: j
/f\ Data is already in this database, Create Database,
Output Timestep: JMonth
r- Output
r~ Time Factors (mass/time)
F" Distance Factors (mass/distance)
W Emissions (mass/time step)
Time Units: | ^
Distance Units: ~
Mass Units: j j[}
This panel is conceptually the final panel completed prior to running the model.
The user must specify the server and database into which the results should be placed. There is a local
default server shown but no default database selected. A warning is shown if the database already contains
rows within the output tables. The "Create Database" button is used for creating new databases and is
likely identical to that used on the Manage Input Data Sets panel.
The Output Timestep is the "time" dimension of the output data. The setting for this value directly affects
the number of output rows in the database. The options available for the Output Timestep are potentially:
Hour, Day, Month, Season, and Year. Note that Season is intentionally available here but not in the Time
Span panel. The UI will examine all of the selected time spans and find the shortest duration. That
duration and those shorter will be shown in this panel. Thus, if the user selected two time spans both with a
monthly duration, then the list shown would be Month, Day, and Hour. If the user selected two time spans,
one with a yearly duration and one with a daily duration, the list shown would only be Day and Hour.
There is no default Output Timestep.
Various factors and values are available for each pollutant. The user can elect to have emission rates as a
function of time output for each pollutant. The user can also elect to output emission rates as a function of
distance (i.e. VMT related) output for each pollutant. Finally, the user can elect to simply get the total mass
of pollutant output within each Output Timestep.
Choosing any of the Output factors or values requires the user to select appropriate units for their output.
The units lists will be disabled if not required by the user's selections. Both common English and Metric
units are available, thus making output in Tons per Kilometer possible (but not advisable) along with the
more common Grams per Mile. Since it is only a rate, the Time Units list will include Year, Month, Week,
Day, Hour, and Second regardless of the Output Timestep or time span durations.
The user must select at least one of the Output factors or values, with the Emissions (mass/time step) option
being selected by default.
The user must make appropriate selections in all areas of this panel, as the model cannot run without this
information.
MOVES RunSpec GUI Details Rev.3 US EPA Page A-15
-------
19. Additional Outputs
P EAFE'Daba]
In addition to outputs for pollutants, MOVES can provide internal data used in its calculations. This panel
is used to select which of those internal data sets should be provided. A wide variety of additional outputs
could be included on this panel, for example, VMT, source populations, future year source use type
distributions, etc.
20. Other Ul Notes
Throughout the UI, list boxes are used extensively. These list boxes are to support a feature that allows the
user to give focus to the list box then start typing text with the list box automatically moving/scrolling the
displayed items to that which matches the user's typed text. The textual matching will not be case sensitive
and the internally accumulated text will be reset upon a non-typing action (i.e. mouse usage or loss of input
focus). This feature is used in lieu of providing an explicit "Search" feature on the various panels.
Buttons are used along with list boxes on most panels of the UI, typified by the "Select All", "Delete", and
"Add" buttons. It is expected that these buttons will be enabled/disabled based upon selection in their
associated list box. For example, a "Delete" button will be disabled until a selection is made in its list box.
Prior to starting a model run that involves uncertainty, the user will be presented with a popup window that
again warns the user of the potentially extremely long execution time. This will be a restatement of the
warning on the Uncertainty panel. The user will have the option of continuing and starting the run or to
abort the run. Should they abort the run, the UI will navigate the user to the Uncertainty panel.
Though not shown here, it is expected that during a model run, the user will be shown a progress indicator
and be allowed to pause, resume, and cancel the run. It is also likely the user will require the ability to halt
a run at a checkpoint then resume it from there at a later date and even with a different mix of distributed
computers contributing to the execution.
21. Revision History
Changes from Revision 2 to Revision 3:
In the "RunSpec UI Overview" section, updated the main screen image
o Added the "Additional Outputs" item under "Output"
o Added the scroll bar to the navigation panel
o Replaced the default screen with the EPA logo and the progress bar
In the "Macroscale Geographic Bounds" section, replaced "50 States", "49 States", and "47
States" with "Nation"
In the "Pollutants and Processes" section, updated the image with a transposed grid and revised
wording to reflect this
Added the "Additional Outputs" section
Changes from initial version to Revision 2:
Added descriptions to every screen.
Changes throughout the user interface, impacting nearly every screen, per MOVES Design Team
meetings.
Added section "19. Other UI Notes"
MOVES RunSpec GUI Details Rev.3 US EPA Page A-16
-------
Appendix B to Draft Design and Implementation
Plan for EPA's Multi-Scale Motor Vehicle and
Equipment Emission System (MOVES)
MOVES Output
Database Design
August 29, 2002
ASD, EPA
-------
Table of Contents
1. 'Entity' section 3
Entity Table 3
2. 'Column' section 4
Column Table 4
Table(s) of "distanceUnits" Column 7
Table(s) of "emissionMass" Column 7
Table(s) of "emissionMassPerDistance" Column 7
Table(s) of "emissionMassPerTime" Column 7
Table(s) of "fuelTypelD" Column 7
Table(s) of "HCExpressAs" Column 8
Table(s) of "HPCIass" Column 8
Table(s) of "linkID" Column 8
Table(s) of "locationID" Column 8
Table(s) of "massllnits" Column 8
Table(s) of "modelYear" Column 8
Table(s) of "monteCarloRunNumber" Column 8
Table(s) of "monteCarloSimulationNumber" Column 8
Table(s) of "MOVESOutputRowlD" Column 9
Table(s) of "MOVESRunID" Column 9
Table(s) of "MOVESRunID" Column 9
Table(s) of "onOrOffRoad" Column 9
Table(s) of "outputTime" Column 9
Table(s) of "pollutantID" Column 9
Table(s) of "processID" Column 9
Table(s) of "roadTypelD" Column 9
Table(s) of "runDateTime" Column 9
Table(s) of "runSpecFileName" Column 10
Table(s) of "scale" Column 10
Table(s) of "SCC" Column 10
Table(s) of "segment" Column 10
Table(s) of "sourceCategorylD" Column 10
Table(s) of "sourceTypelD" Column 10
Table(s) of "statelD" Column 10
Table(s) of "timeStepHours" Column 10
Table(s) of "timeUnits" Column 11
Table(s) of "zonelD" Column 11
-------
Entity
1. 'Entity' section"!. 'Entity' section"!. 'Entity' section 1. 'Entity' section 1. 'Entity' sectionl. 'Entity'
sectionEntity TableEntity TableEntity TableEntity TableEntity TableEntity TableEntity
Name
Movesoutput
Movesrun
Definition
MOVESOutput table. Stores one row for
each combination
of dimension field values, which includes
pollutant. (As opposed to NMIM that stores
all
pollutant values in each row, effectively
removing pollutant name as an OLAP
dimension.)
Stores information about the execution
of the run, including time step hours and
mass/distance/
time units for the numbers in MOVESOutput.
-------
Column
2. 'Column' section2. 'Column' section2. 'Column' section2. 'Column' section2. 'Column'
section2. 'Column' sectionColumn TableColumn TableColumn TableColumn TableColumn
TableColumn TableColumn
Name
distanceUnits
emissionMass
emissionMassPerDis
tance
emissionMassPerTim
e
fuelTypelD
HCExpressAs
HPCIass
linkID
locationID
Datatype
VARCHAR(5)
REAL
REAL
REAL
INTEGER
CHAR(6)
TINYINT(3)
INTEGER
INTEGER
Null Option
NULL
NULL
NULL
NULL
NOT NULL
NULL
NOT NULL
NOT NULL
NOT NULL
Comment
distanceUnits is the
standard textual
abbreviation for
the distance unit. Ex:
"mi", "km"
The emission* columns
are the actual values
produced,
not dimensions to the
data. These will be
NULL if the user chose
not to generate them.
The emission* columns
are the actual values
produced,
not dimensions to the
data. These will be
NULL if the user chose
not to generate them.
The emission* columns
are the actual values
produced,
not dimensions to the
data. These will be
NULL if the user chose
not to generate them.
statelD, locationID,
zonelD, and linkID can
all be default
in the case where the
user selected "Nation"
as the geographic
granularity for the
output.
linkID and/or zonelD
will be default
otherwise if "County"
level granularity was
selected depending
upon scale.
statelD, locationID,
zonelD, and linkID can
all be default
IsPK
No
No
No
No
No
No
No
No
No
IsFK
No
No
No
No
No
No
No
No
No
-------
2. 'Column' section2. 'Column' section2. 'Column' section2. 'Column' section2. 'Column'
section2. 'Column' sectionColumn TableColumn TableColumn TableColumn TableColumn
TableColumn TableColumn
Name
massUnits
modelYear
monteCarloRunNu
mber
monteCarloSimulati
onNumber
MOVESOutputRowl
D
MOVESRunID
MOVESRunID
onOrOffRoad
outputTime
pollutantID
processID
roadTypelD
Datatype
VARCHAR(5)
SMALLINT(4)
SMALLINT(4)
SMALLINT(4)
INTEGER
INTEGER
INTEGER
CHAR(1)
DATETIME
INTEGER
INTEGER
INTEGER
Null Option
NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
Comment
in the case where the
user selected "Nation"
as the geographic
granularity for the
output.
locationID will be
default otherwise if
"State" level
granularity was
selected.
massUnits is the
standard textual
abbreviation for the
max unit. Ex: "g", "kg",
"ton"
Unigue number
automatically
seguentially
assigned to each
MOVESOutput
instance as it is
entered into this
database. Number
has no other
significance.
Run id, implemented
as auto increment
integer in MySQL.
Run id, implemented
as auto increment
integer in MySQL.
onOrOffRoad can be
"N"for NONRoad, or
"O" ("oh") for OnRoad,
and " " (space) for
both. The default
value is the first one in
the enumeration
(index = 1)
roadTypelD is not
redundant with linkID
in the cases where
IsPK
No
No
No
No
Yes
Yes
No
No
No
No
No
No
IsFK
No
No
No
No
No
No
Yes
No
No
No
No
No
-------
2. 'Column' section2. 'Column' section2. 'Column' section2. 'Column' section2. 'Column'
section2. 'Column' sectionColumn TableColumn TableColumn TableColumn TableColumn
TableColumn TableColumn
Name
runDateTime
runSpecFileName
scale
sec
segment
sourceCategorylD
sourceTypelD
statelD
timeStepHours
timeUnits
Datatype
DATETIME
VARCHAR(255)
CHAR(5)
CHAR(10)
TINYINT(2)
INTEGER
INTEGER
INTEGER
REAL
VARCHAR(5)
Null Option
NOT NULL
NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NULL
Comment
the user wants road
type as a dimension
but does not want
geographic detail to
the link/zone
(or perhaps even to
the County) level.
runSpecFileName can
be null if the user has
not saved
their runspec prior to
launching the
simulation, scale
ENUM("MACRO","MES
0","MICRO") NOT NULL
SCC holds both
On Road and OffRoad
SCC codes and may
be
all Os (zeroes) to
represent "all" SCC
codes at once.
statelD, locationID,
zonelD, and linkID can
all be default
in the case where the
user selected "Nation"
as the geographic
granularity for the
output.
timeStepHours is the
number of hours in the
selected time step.
For example, if the
user wanted seasonal
timesteps, the hours
would be
365.25days/year *
24hours/day / 4
seasons/year.
timeUnits is the
standard textual
abbreviation for the
the time unit. Ex:
"sec", "hour", "min",
IsPK
No
No
No
No
No
No
No
No
No
No
IsFK
No
No
No
No
No
No
No
No
No
No
-------
2. 'Column' section2. 'Column' section2. 'Column' section2. 'Column' section2. 'Column'
section2. 'Column' sectionColumn TableColumn TableColumn TableColumn TableColumn
TableColumn TableColumn
Name
zonelD
Datatype
INTEGER
Null Option
NOT NULL
Comment
"day", "mon"
statelD, locationID,
zonelD, and linkID can
all be default
in the case where the
user selected "Nation"
as the geographic
granularity for the
output.
linkID and/or zonelD
will be default
otherwise if "County"
level granularity was
selected depending
upon scale.
IsPK
No
IsFK
No
Table(s) of "distanceUnits" ColumnTable(s) of "distanceUnits" ColumnTable(s) of
"distanceUnits" ColumnTable(s) of "distanceUnits" ColumnTable(s) of "distanceUnits"
ColumnTable(s) of "distanceUnits" ColumnTable(s) of "distanceUnits" Column
Name
MOVESRun
Table(s) of "emissionMass" ColumnTable(s) of "emissionMass" ColumnTable(s) of
"emissionMass" ColumnTable(s) of "emissionMass" ColumnTable(s) of "emissionMass"
ColumnTable(s) of "emissionMass" ColumnTable(s) of "emissionMass" Column
Name
MOVESOutput
Table(s) of "emissionMassPerDistance" ColumnTable(s) of "emissionMassPerDistance"
ColumnTable(s) of "emissionMassPerDistance" ColumnTable(s) of "emissionMassPerDistance"
ColumnTable(s) of "emissionMassPerDistance" ColumnTable(s) of "emissionMassPerDistance"
ColumnTable(s) of "emissionMassPerDistance" Column
Name
MOVESOutput
Table(s) of "emissionMassPerTime" ColumnTable(s) of "emissionMassPerTime" ColumnTable(s)
of "emissionMassPerTime" ColumnTable(s) of "emissionMassPerTime" ColumnTable(s) of
"emissionMassPerTime" ColumnTable(s) of "emissionMassPerTime" ColumnTable(s) of
"emissionMassPerTime" Column
Name
MOVESOutput
Table(s) of "fuelTypelD" ColumnTable(s) of "fuelTypelD" ColumnTable(s) of "fuelTypelD"
ColumnTable(s) of "fuelTypelD" ColumnTable(s) of "fuelTypelD" ColumnTable(s) of
"fuelTypelD" ColumnTable(s) of "fuelTypelD" Column
Name
MOVESOutput
-------
Table(s) of "HCExpressAs" ColumnTable(s) of "HCExpressAs" ColumnTable(s) of "HCExpressAs"
ColumnTable(s) of "HCExpressAs" ColumnTable(s) of "HCExpressAs" ColumnTable(s) of
"HCExpressAs" ColumnTable(s) of "HCExpressAs" Column
Name
MOVESRun
Table(s) of "HPCIass" ColumnTable(s) of "HPCIass" ColumnTable(s) of "HPCIass"
ColumnTable(s) of "HPCIass" ColumnTable(s) of "HPCIass" ColumnTable(s) of "HPCIass"
ColumnTable(s) of "HPCIass" Column
Name
MOVESOutput
Table(s) of "linkID" ColumnTable(s) of "linkID" ColumnTable(s) of "linkID" ColumnTable(s) of
"linkID" ColumnTable(s) of "linkID" ColumnTable(s) of "linkID" ColumnTable(s) of "linkID"
Column
Name
MOVESOutput
Table(s) of "locationID" ColumnTable(s) of "locationID" ColumnTable(s) of "locationID"
ColumnTable(s) of "locationID" ColumnTable(s) of "locationID" ColumnTable(s) of "locationID"
ColumnTable(s) of "locationID" Column
Name
MOVESOutput
Table(s) of "massUnits" ColumnTable(s) of "massUnits" ColumnTable(s) of "massUnits"
ColumnTable(s) of "massUnits" ColumnTable(s) of "massUnits" ColumnTable(s) of "massUnits"
ColumnTable(s) of "massUnits" Column
Name
MOVESRun
Table(s) of "modelYear" ColumnTable(s) of "modelYear" ColumnTable(s) of "modelYear"
ColumnTable(s) of "modelYear" ColumnTable(s) of "modelYear" ColumnTable(s) of
"modelYear" ColumnTable(s) of "modelYear" Column
Name
MOVESOutput
Table(s) of "monteCarloRunNumber" ColumnTable(s) of "monteCarloRunNumber"
ColumnTable(s) of "monteCarloRunNumber" ColumnTable(s) of "monteCarloRunNumber"
ColumnTable(s) of "monteCarloRunNumber" ColumnTable(s) of "monteCarloRunNumber"
ColumnTable(s) of "monteCarloRunNumber" Column
Name
MOVESOutput
Table(s) of "monteCarloSimulationNumber" ColumnTable(s) of
"monteCarloSimulationNumber" ColumnTable(s) of "monteCarloSimulationNumber"
ColumnTable(s) of "monteCarloSimulationNumber" ColumnTable(s) of
"monteCarloSimulationNumber" ColumnTable(s) of "monteCarloSimulationNumber"
ColumnTable(s) of "monteCarloSimulationNumber" Column
Name
MOVESOutput
-------
Table(s) of "MOVESOutputRowlD" ColumnTable(s) of "MOVESOutputRowlD" Column2Table(s)
of "MOVESOutputRowlD" ColumnTable(s) of "MOVESOutputRowlD" ColumnTable(s) of
"MOVESOutputRowlD" ColumnTable(s) of "MOVESOutputRowlD" ColumnTable(s) of
"MOVESOutputRowlD" Column
Name
MOVESOutput
Table(s) of "MOVESRunID" ColumnTable(s) of "MOVESRunID" ColumnTable(s) of
"MOVESRunID" ColumnTable(s) of "MOVESRunID" ColumnTable(s) of "MOVESRunID"
ColumnTable(s) of "MOVESRunID" ColumnTable(s) of "MOVESRunID" Column
Name
MOVESRun
Table(s) of "MOVESRunID" ColumnTable(s) of "MOVESRunID" ColumnTable(s) of
"MOVESRunID" ColumnTable(s) of "MOVESRunID" ColumnTable(s) of "MOVESRunID"
ColumnTable(s) of "MOVESRunID" ColumnTable(s) of "MOVESRunID" Column
Name
MOVESOutput
Table(s) of "onOrOffRoad" ColumnTable(s) of "onOrOffRoad" ColumnTable(s) of
"onOrOffRoad" ColumnTable(s) of "onOrOffRoad" ColumnTable(s) of "onOrOffRoad"
ColumnTable(s) of "onOrOffRoad" ColumnTable(s) of "onOrOffRoad" Column
Name
MOVESOutput
Table(s) of "outputTime" ColumnTable(s) of "outputTime" ColumnTable(s) of "outputTime"
ColumnTable(s) of "outputTime" ColumnTable(s) of "outputTime" ColumnTable(s) of
"outputTime" ColumnTable(s) of "outputTime" Column
Name
MOVESOutput
Table(s) of "pollutantID" ColumnTable(s) of "pollutantID" ColumnTable(s) of "pollutantID"
ColumnTabie(s) of "pollutantID" ColumnTable(s) of "pollutantID" ColumnTabie(s) of
"pollutantID" ColumnTable(s) of "pollutantID" Column
Name
MOVESOutput
Table(s) of "processID" ColumnTable(s) of "processID" ColumnTable(s) of "processID"
ColumnTabie(s) of "processID" ColumnTable(s) of "processID" ColumnTable(s) of "processID"
ColumnTable(s) of "processID" Column
Name
MOVESOutput
Table(s) of "roadTypelD" ColumnTable(s) of "roadTypelD" ColumnTable(s) of "roadTypelD"
ColumnTable(s) of "roadTypelD" ColumnTable(s) of "roadTypelD" ColumnTable(s) of
"roadTypelD" ColumnTable(s) of "roadTypelD" Column
Name
MOVESOutput
Table(s) of "runDateTime" ColumnTable(s) of "runDateTime" ColumnTable(s) of "runDateTime"
ColumnTable(s) of "runDateTime" ColumnTable(s) of "runDateTime" ColumnTable(s) of
"runDateTime" ColumnTable(s) of "runDateTime" Column
-------
Name
MOVESRun
Table(s) of "runSpecFileName" ColumnTable(s) of "runSpecFileName" ColumnTable(s) of
"runSpecFileName" ColumnTable(s) of "runSpecFileName" ColumnTable(s) of
"runSpecFileName" ColumnTable(s) of "runSpecFileName" ColumnTable(s) of
"runSpecFileName" Column
Name
MOVESRun
Table(s) of "scale" ColumnTable(s) of "scale" ColumnTable(s) of "scale" ColumnTable(s) of
"scale" ColumnTable(s) of "scale" ColumnTable(s) of "scale" ColumnTable(s) of "scale"
Column
Name
MOVESRun
Table(s) of "SCC" ColumnTable(s) of "SCC" ColumnTable(s) of "SCC" ColumnTable(s) of "SCC"
ColumnTable(s) of "SCC" ColumnTable(s) of "SCC" ColumnTable(s) of "SCC" Column
Name
MOVESOutput
Table(s) of "segment" ColumnTable(s) of "segment" ColumnTable(s) of "segment"
ColumnTable(s) of "segment" ColumnTable(s) of "segment" ColumnTable(s) of "segment"
Coli imnTahlefs'l of "senment" Column
ColumnTable(s) of "segment" Column
Name
MOVESOutput
Table(s) of "sourceCategorylD" ColumnTable(s) of "sourceCategorylD" Column2Table(s) of
"sourceCategorylD" ColumnTable(s) of "sourceCategorylD" ColumnTable(s) of
"sourceCategorylD" ColumnTable(s) of "sourceCategorylD" ColumnTable(s) of
"sourceCategorylD" Column
Name
MOVESOutput
Table(s) of "sourceTypelD" ColumnTable(s) of "sourceTypelD" ColumnTable(s) of
"sourceTypelD" ColumnTable(s) of "sourceTypelD" ColumnTable(s) of "sourceTypelD"
ColumnTable(s) of "sourceTypelD" ColumnTable(s) of "sourceTypelD" Column
Name
MOVESOutput
Table(s) of "statelD" ColumnTable(s) of "statelD" ColumnTable(s) of "statelD" ColumnTable(s)
of "statelD" ColumnTable(s) of "statelD" ColumnTable(s) of "statelD" ColumnTable(s) of
"statelD" Column
Name
MOVESOutput
Table(s) of "timeStepHours" ColumnTable(s) of "timeStepHours" ColumnTable(s) of
"timeStepHours" ColumnTable(s) of "timeStepHours" ColumnTable(s) of "timeStepHours"
ColumnTable(s) of "timeStepHours" ColumnTable(s) of "timeStepHours" Column
Name
MOVESRun
w
-------
Table(s) of "timeUnits" ColumnTable(s) of "timeUnits" ColumnTable(s) of "timeUnits"
ColumnTable(s) of "timeUnits" ColumnTable(s) of "timeUnits" ColumnTable(s) of "timeUnits"
ColumnTable(s) of "timeUnits" Column
Name
MOVESRun
Table(s) of "zonelD" ColumnTable(s) of "zonelD" ColumnTable(s) of "zonelD" ColumnTable(s)
of "zonelD" ColumnTable(s) of "zonelD" ColumnTable(s) of "zonelD" ColumnTable(s) of
"zonelD" Column
Name
MOVESOutput
11
------- |