Western Backstop (WEB)

Emissions and Allowance Tracking

System (EATS) Analysis

Prepared by:

Perrin Quarles Associates, Inc.

675 Peter Jefferson Parkway, Suite 200

Charlottesville, VA 22911

July 31, 2003

Table of Contents

Page

I. Introduction ........................................................... 1

II. Overview of the System and Analysis ....................................... 1

III. Functional Areas ...................................................... 3

A. Source Inventory ................................................ 3

B. User Management ............................................... 5

C. Account Management ............................................. 6

D. Allowance Allocations (Initial and Ongoing) ............................ 7

E. Allowance Trading .............................................. 10

F. Annual Compliance Assessment .................................... 12

G. Emissions Tracking and Emissions Reporting ........................... 15

H. Program Assessment and Analysis .................................. 18

I. Public Information Needs and Requirements ............................ 19

IV. Types of Users ...................................................... 19

A. State and Tribal Users ........................................... 20

B. Industry Users ................................................. 21

C. General Account Holders ......................................... 22

D. Tracking System Administrator ..................................... 23

E. Public Users ................................................... 24

V. Technical Architecture ................................................. 24

A. Security ...................................................... 25

B. System Performance ............................................. 27

C. Maintainability ................................................. 28

D. System Outputs ................................................ 28

E. Application of Platform Selection Criteria ............................. 29

VI. Design and Development Approach ....................................... 30

A. Recommended Implementation Methodology .......................... 30

B. Timing/Schedule ................................................ 32

C. Cost Factors .................................................. 32

VII. TSA Responsibilities and Performance Criteria .............................. 33

A. TSA Responsibilities ............................................. 33

B. TSA Performance Criteria ........................................ 36
List of Figures

Page

Figure 1: Overall WEB EATS Model ......................................... 2

Figure 2: Flow Chart of Allowance Allocation Process ............................ 10

Figure 3: Flow Chart of Annual Compliance Assessment Process .................... 14

Figure 4: Use Case Diagram: State and Tribal Users ............................. 20

Figure 5: Use Case Diagram: Industry Users ................................... 21

Figure 6: Use Case Diagram: General Account Holders ........................... 22

Figure 7: Use Case Diagram: Tracking System Administrator ...................... 23

Figure 8: Use Case Diagram: Public Users .................................... 24
-1-

July 31, 2003

Western Backstop (WEB)

Emissions and Allowance Tracking System (EATS) Analysis

I. Introduction

This section of the State Implementation Plan/Tribal Implementation Plan (SIP/TIP) is an

analysis of the information management needs of the Western Backstop Emissions and

Allowance Tracking System (WEB EATS) which is a requirement for the program under 40

CFR 51.309. Section 309(d)(h)(4)(v) of the Regional Haze rule requires that "the

Implementation Plan must provide for submitting data to a centralized system for the tracking of

allowances and emissions." The purpose of this document is to describe the architectural and

system requirements necessary to support a State/Regional emissions trading program

information system. The document summarizes the overall needs and objectives of an emissions

trading system to ensure successful implementation of the program. It is intended to serve as a

roadmap to help WRAP implement the program once it has been triggered. 

II. Overview of the System and Analysis

Figure 1 contains a graphical depiction of the overall information system, including the

basic users, functionality needed for each of these user types, and a high level architecture. 

Section III describes each functional area of the application. Section IV describes the primary

user groups and how they relate to the functional areas. Section V describes the considerations

affecting the choice of technical architecture for the application. Section VI describes

recommended design and development approaches, and Section VII addresses the overall

responsibilities of the Tracking System Administrator (TSA). 

The development and deployment of this application, if needed, would most likely occur

after 2013, possibly later. It is assumed that currently available technology would not be used,

nor is it possible to project what advancements in technology would be available. For this

reason, this report does not address specific technologies, except as a reference point for better

understanding or describing capability that would be needed. The focus is on general issues

related to technology and the functional requirements for designing and implementing the

program.

The scope of the application and information system needs which are described do not

extend to several areas relating to the possible implementation of the Backstop Trading Program

envisioned by Section 309. Excluded areas include the baseline emissions inventory for

determining whether the program triggers, performing initial allowance allocations, and evaluating

and tracking early reduction credits. Also, it has been assumed that it is not necessary to

support a significant level of variation in requirements or needs from different States or tribes and

that areas in which these requirements may vary, such as enforcement activities beyond the

automatic provisions of the program, would be addressed in other systems. 
 

July 31, 2003WEB EATS Analysis

-2-

Application

Database

WEB EATS

Public

EPA

Emissions

Database

Program

Emissions

Inventory

Public Data

Industry

General

Accounts

ü Query Data

ü View Standard

Reports

ü Manage Application

and Users

ü Conduct Compliance

Assessment

ü Develop Reports

ü Coordinate Program

Implementation

ü Complete Registration

ü Transfer Allowances

ü Submit Emissions

ü View Reports

ü Add/Update General

Accounts

ü Transfer Allowances

ü View Reports

The System

Administrator

ü Allocate Allowances

ü Approve Sources

and Units

ü Approve Monitoring

ü View Reports Tribal Set-aside

States/Tribes Allocation System

Figure 1

Overall WEB EATS Model
WEB EATS Analysis

July 31, 2003

-3-

III. Functional Areas

The system to support the WEB Trading Program must contain functionality to support

implementation of the trading program in the following areas: source inventory, user

management, account management, allowance allocations, allowance trading, emissions

reporting and collection, compliance, and program assessment. At this time, the system

functionality does not include consideration of allowance transfer price data. However, there

may be a need to include this functional area in the final system design, and the overall system

design needs to allow for this possible expansion of the functional areas. Because the core

requirements for allowance transfer price tracking remain uncertain, this section does not discuss

this functional area in further detail. Each of the other areas of functionality is described below. 

In addition, core requirements relating to the areas are defined. 

A. Source Inventory

1. Description

a. Facilities and Units

The central focus of the system is the list or inventory of sources which are affected by

the program. This inventory is initially derived from the baseline emissions inventory developed

to support the development and approval of the WEB Trading Program as part of the SIP/TIP

approval process. To this initial inventory, it is expected that States and Tribes may add

sources, either during the period prior to triggering the program or after the Program Trigger

Date. Throughout, it is expected that sources will permanently cease operation or "retire." To

support the dynamic inventory, the information system must allow the addition of new sources

and track the status, including the regulatory status, of all sources identified as potential program

participants beginning with the baseline period.

To support changes in facility operation and ownership in both the pre-trigger and posttrigger period, it will be necessary to track basic changes in facility identity, including facilities

which, due to these types of changes, change "identity" or divide into two facilities. This

functionality would include tracking facility name changes. 

It is assumed that States and Tribes would be responsible for identifying all "new"

sources to the database and for making decisions and entering data about the applicability of the

program to a new source. Once a source is identified as being subject to the program, the

maintenance of these data would be the primary responsibility of the owners and operators of

affected sources through the source representative. A single, secure portal for changing these

data would be provided to authorized industry representatives.
WEB EATS Analysis

July 31, 2003

-4-

b. Source Owners 

The owners and operators of each source authorize individual(s) to represent them

regarding allowance trading, emissions reporting and all other compliance activities. The identity

of the owners and operators should be tracked to ensure that legal responsibility for compliance

can be accurately determined at any point in time during which compliance is required. The

WEB EATS should track changes in owners and operators for a source. 

c. Source Representatives 

The designated representatives appointed by the owners and operators of the source are

also tracked so that appropriate communication about program activities involving the source

and compliance is facilitated. Under the Duty to Register provisions, representatives of a source

initially must register and use consistent source identifiers with the source program data first

entered by the State or Tribe. The representative is responsible for the accuracy of submissions

and certifying source compliance. Program rules should be structured to ensure that at no time

during the operational phase of the program is an affected source unrepresented. 

d. Source and Unit Detail

Additional information about the facility and units, including fuels, controls, and other

operational information would be necessary for program implementation, particularly with

respect to emissions monitoring, and for program assessment. During the design phase for

WEB EATS development an assessment of these needs and the availability of information from

other sources (for example, a shared air program database at EPA or in a State/Tribe) should

be performed. 

2. Core Data Entities and Attributes

! Facilities. Location, source category or type, permit IDs, size, Federal and State/Tribal

cross identifiers with other data systems, program status, operational status (including

retirement status), initial on-line date (for new sources).

! Units. Relationship to facilities, type, Federal and State/Tribal cross identifiers with

other data systems, operational status (including retirement status), initial on-line date

(for new units).

! People. Type and duration of relationship of representatives to facilities, type and

duration of agent relationship to representatives, address, affiliation, security level, user

ID, passwords (or equivalent), phone numbers, email or equivalent.

! Owners/operators. Address, relationship to facilities.
WEB EATS Analysis

July 31, 2003

-5-

! Program applicability. Exemptions, opt-in or other program status information, including

year affected (or non-affected), identification of Category 1 and 2 sources, etc. Could

include permitted production capacity or other permit data.

3. Core Functional Requirements

! Populate initial facilities and units.

! Add and update facilities and units.

! Add and update owner/operator information.

! Change owner/operators for facilities.

! Add and update individual information for any person utilizing or identified in the

application.

! Change representatives for facilities.

! For on-line changes, provide to users documentation of changes in owners and

representatives to meet recordkeeping requirements. This could be email or other

electronic format.

! Track changes in facility names and program identifiers and relationship to prior entities.

! Communicate/verify facility and unit inventory changes, particularly where change

impacts regulatory status or responsibilities or triggers deadline.

! Add and update program applicability data.

B. User Management

1. Description

User security and authentication are key requirements for the WEB EATS. To support

these requirements the application must contain functionality to store user identifying information

and associate each user with the appropriate security level. A system administrator, or person

designated by the system administrator, must use tools provided in the application to review and

approve user accounts, and to access and monitor usage. 

For any on-line access and submission by an industry user, the system should require

appropriate compliance certifications and contain a record of certifications. 

2. Core Data Entities and Attributes

! People. Relationship to facilities or to representatives and their agents, address,

affiliation, type, security level, user ID, passwords (or equivalent), phone numbers, email

or equivalent.
WEB EATS Analysis

July 31, 2003

-6-

! User Access Requests. User identification (per People), information to facilitate

approval, status of request (approval, denial).

! Certification Records. Content of certification, date, user identification.

3. Core Functional Requirements

! Receive requests for user registration.

! Approve/deny requests and establish security groups.

! Provide notification of request status and assigned user ID and passwords (or

equivalent).

! Develop and apply user privileges for specific functional areas and categories of data.

! Delete or archive users.

! Revoke or modify user access privileges.

! Display appropriate certification statements for review and agreement.

C. Account Management

1. Description

In the model rule, an Allowance Tracking System account is defined as an account

"established for purposes of recording the allocation, and for holding, transferring, or deducting

allowances." The WEB EATS should contain at least four types of accounts: general,

compliance, retirement and government accounts. It must include a range of functionality to

support each type of account. 

A compliance account holds allowances which are used for compliance purposes. 

There is one compliance account for each source subject to emissions trading requirements and

the compliance account is assumed to have the identical owners and representatives as its

associated source. A compliance account should be automatically created for each new source

when a source has met the appropriate registration requirements. For specified periods,

compliance accounts or the allowances in those accounts may be subject to restrictions on

trading to facilitate annual compliance assessment. 

A general account allows anyone to hold allowances separate from the compliance and

true-up process. A representative for a facility must move allowances from a general account to

a compliance account before the true-up deadline in order to use them for current year

compliance. A general account is created upon request of any individual or entity, and like a

facility's compliance account, must have a defined owner and an individual person named as an

account representative. General accounts are populated through trading functions, described

below. The system administrator should have the ability to archive or deactivate a general

account if specified criteria are met (such as containing no allowances for a specified period of

time). For analysis purposes, the type of general account holder should be identified.
WEB EATS Analysis

July 31, 2003

-7-

A retirement account holds allowances which have been used for annual compliance to

offset emissions or which have been voluntarily removed from the market by its owners. At

least one retirement account will be identified initially; additional accounts may be necessary to

meet specific needs, if a detailed analysis of requirements indicates that separating retired

allowances would be useful for analysis or other purposes. 

A government account holds allowances which are still under the control of a State or

Tribe (or, as their agent, the Tracking System Administrator). These accounts will contain

serialized allowances to be allocated in the future. The new source set-aside, for example, is a

government account. 

2. Core Data Entities and Attributes

! Accounts. Identification number, type, restrictions, relationship to source (if any),

State/Tribe, or owner/representatives, owner type.

! People. Type and direction of relationship to accounts and representatives and their

agents, address, affiliation, security level, user ID, passwords (or equivalent), phone

numbers, email or equivalent.

! Owners/operators. Address, relationship to accounts.

3. Core Functional Requirements

! Add/create general accounts. 

! Change owner/operators for general accounts.

! Change representatives for general accounts.

! Add/create retirement, government, and compliance accounts (system admin only).

! Implement freeze on account or specific allowances within account.

! Archive or delete accounts.

! Notification of changes to user and other responsible persons.

D. Allowance Allocations (Initial and Ongoing)

1. Description

The system should support both initial and ongoing allocations of allowances from

government accounts into compliance accounts. The initial allocation for the first five year

period would be provided by States or Tribes in a format to be defined by the TSA and system

designers. It is recommended that the allocation process replicate the transfer of allowances

from account to account, thus creating an audit trail of the allowance back to its original issuing

State or Tribe. It is recommended that the system design include a standard file format for

submission of initial allowance allocations by the State or Tribe. 
WEB EATS Analysis

July 31, 2003

-8-

All allowances would be serialized according to a numbering system to be determined as

part of the system design when they are initially populated in the application. This serial number

would be a permanent attribute of each allowance and could not be changed.

Ongoing allocations, which occur every five years for all allowances, would be

supported through a process similar to the initial allocation, depending primarily on a standard

file format, containing allocations determined by the State or Tribe for the period.

The application should generate a draft and final Regional Allocation Report for each

five year allocation period. 

The application should support periodic allocations of allowances to compliance

accounts for new sources from the new source set-aside. Specialized tracking and reporting

would be needed to record the date of all requests and the status of the set-aside account. 

When this account is depleted, the tracking information would be used to prioritize allocation of

future allowances to these sources.

The application must support allocations of allowances for opt-in sources on an annual

basis. It is assumed that the State or Tribe would provide data to support opt-in source

allocation (including source identification) either on-line or in an electronic format. 

The application must support notification of all allocations to registered sources and to

the appropriate State or Tribe.

If a source representative elects a monitoring option for a unit under 1.(b) of Section I

(Monitoring, Recordkeeping and Reporting) of the model rule, the source representative would

submit a request to the State or Tribe about this election, and must provide information about

the portion of the facility's allowance allocation attributable to these units. Upon approval of the

request by the State or Tribe, the TSA (or the State or Tribe directly) would mark the

appropriate number of allowances as "non-tradeable" in the allowance account for the source

for all years already allocated. A record of the request and approval would be stored, so that

future allocations would also be marked as non-tradeable. If the special monitoring status under

Section I1.(b) is revoked or no longer applicable, the "non-tradeable" status of the allowances

would be changed by the TSA. 

2. Core Data Entities and Attributes

! Accounts. Identification number, type, restrictions, relationship to source, State/Tribe,

or owner/representatives, owner type.

! Allowances. Serial number, type, origin, year (if not indicated by serial number), nontradeable indicator.
WEB EATS Analysis

July 31, 2003

-9-

! Transactions. Transaction identifier, date, allowance range, transferor account,

transferee account, type of transaction.

! Action Log. Type of submission or request, user, source, status, etc.

3. Core Functional Requirements

! Import of allowance allocations from file provide by State or Tribe.

! Assign serial numbers to new allowances.

! Notification system to automatically inform industry users of allocations and future

responsibilities.

! Notification or report system to keep States and Tribes informed re allocation status.

! Tracking capability for new source set-aside requests.

! Allocations to compliance accounts from new-source set aside.
WEB EATS Analysis

July 31, 2003

-10-

WEB EATS 

automatically notifies 

industry users of 

allocations and future 

responsibilities

WEB EATS assigns 

serial numbers to new 

allowances

WEB EATS

automatically notifies 

States and Tribes 

regarding allocation 

status

WEB EATS imports 

allowance allocations 

from file provided by 

State or Tribe

Figure 2

Flow Chart of Allowance Allocation Process

E. Allowance Trading

1. Description

The ability to trade allowances supports the underlying principle of an emissions trading

program and the functionality to support allowance transfers is critical to the WEB EATS. 

Security of the data and transparency of the transfer record are critical to the overall program

and should be carefully evaluated. The WEB EATS must provide the TSA the ability to

maintain information on all current account holdings and an audit trail of all allowance 

transactions, including both market transactions and regulatory transactions. The current

standard for emissions trading programs established by EPA is to allow industry users to record

allowance transfers on-line in real-time. These applications support both interactive, on-line
WEB EATS Analysis

July 31, 2003

-11-

transfers and batch transfers using specified file formats to transfer larger numbers of allowances. 

For batch transfers, industry has developed software to monitor allowance ownership and

submit large volumes of allowance transfers with a minimum of user intervention. It is assumed

that the technical capability for secure system-to-system interactions will continue to improve

and that this approach will be more widely used in the future. Current allowance trading systems

also support transfers performed by the TSA based on the receipt of paper forms. It is assumed

that the reliance on paper forms will continue to diminish. Whether this functionality should be

supported in the WEB EATS should be evaluated.

During the true-up period, activity in compliance accounts is frozen to allow the TSA to

conduct the necessary compliance evaluation and allowance retirement. Two alternative

approaches should be considered. Under one approach, the WEB EATS would allow users to

submit allowance transfers for allowances involved in an ongoing compliance process, but these

transfers would be held and recorded following the completed process. All affected parties

would be informed of the status of these transfers both when submitted and when finally

recorded or denied. Under the alternative approach, allowance transfers for allowances

involved in on-going compliance would be rejected, and transfers would have to be resubmitted

(reflecting deductions carried out for compliance) after the compliance process is completed.

For on-line transfers performed interactively by the transferor, the WEB EATS should

provide access only to those accounts over which the transferor currently exercises control. 

Account access would be determined by the WEB EATS based on the user's relationships to

specific general or compliance accounts. From these accounts, the user would select the

accounts and specific allowances for the transfer. The user would then identify the account into

which the allowances should be transferred. It is assumed that eligible recipients include general

accounts, compliance accounts or a voluntary retirement account. The user would be asked to

review and verify the transfer prior to its taking affect.

The process for electronic transfers of batch transfers will be more technology

dependent. It would undoubtedly require definition of file transfer formats and security

standards to ensure authentication of the submitter and completeness and quality of the data. It

is not feasible to predict standards or available technology for this process at this time. 

The paper-based process used by the TSA would be similar to the interactive process. 

Depending on the volume of paper transfers, redundancy of data entry or additional verification

should be considered to ensure data quality and accuracy.

For all transfers (interactive, batch or paper), the WEB EATS must support a process

of communication to both the transferor and transferee so that transfers recorded are fully

disclosed to all parties and errors or other disputes between parties can be quickly identified and

resolved.
WEB EATS Analysis

July 31, 2003

-12-

The WEB EATS must support a process of either transaction reversal or transaction

error correction, or both. This functionality would be restricted to the TSA. 

In addition, the WEB EATS must support a process of review of transfers to ensure that

they are valid under the trading program rules (e.g., that they involve allowances actually held in

the transferor account) and to reject invalid transfers. The WEB EATS must support a process

of communication to the transferor concerning the acceptance or rejection of transfers.

Reports would be available to the TSA and designated State/Tribe users to review

specific transactions or overall transaction activity at any time.

2. Core Data Entities and Attributes

! Accounts. Identification number, type, relationship to source, State/Tribe, or

owner/representatives.

! Allowances. Serial number, type, origin, year (if not indicated by serial number).

! Transactions. Transaction identifier, date, allowance range, transferor account,

transferee account, type of transaction, status.

3. Core Functional Requirements

! Interactive transfer.

! Batch transfer.

! Capability to freeze compliance accounts with regard to allowances involved in ongoing

compliance assessment.

! Notification to transferor and transferee.

! Reports and summaries.

! Allowance transaction audit trail.

F. Annual Compliance Assessment

1. Description

Following each control period, the TSA must perform an assessment of annual

compliance with the basic program requirement that each affected source hold a number of

allowances equal to or exceeding the tons of SO2 emissions for the period. The compliance

module of the WEB EATS would support receipt of annual compliance notifications and

certifications by the source representative. It is expected that most representatives would

provide the certifications and designate allowances to be deducted using an on-line access

similar to the allowance transfer capability. Following receipt of the annual compliance forms,

the WEB EATS would then compare the allowances held in the compliance account and the
WEB EATS Analysis

July 31, 2003

-13-

level of emissions for the source (taking into account the year of allowances, flow control

limitations and prior exceedances) and deduct the appropriate allowances from compliance

accounts into retirement accounts. Emissions reported at the unit level would be "rolled" up to

the facility level. The process would result in a compliance report or compliance assessment

notification to source representatives, States and Tribes.

In addition, the WEB EATS would assess the need to apply flow control in the

subsequent year and determine the appropriate flow control factor. 

Finally, the WEB EATS would identify any failure to meet allowance limitations. Based

on the level of excess emissions the WEB EATS would compute the appropriate penalties, both

monetary penalties and deduction of subsequent year allowances.

2. Core Data Entities and Attributes

! Annual compliance certifications. Facilities, submitter name/ID, year, compliance

certification statements.

! Tracking. List of facilities for whom an annual compliance certification is required,

received, etc.

! Compliance Results. Penalties, deductions, status, year.

3. Core Functional Requirements

! Receive and store annual compliance certifications.

! Perform compliance assessment.

! Calculate exceedances.

! Calculate flow control applicability and ratios.

! Communicate compliance results.
WEB EATS Analysis

July 31, 2003

-14-

WEB EATS compares 

allowances held in 

compliance accounts 

and the total level of 

emissions

Source Representatives 

place appropriate amount of 

allowances to be deducted in 

compliance accounts

WEB EATS deducts 

appropriate allowances 

in compliance 

accounts

WEB EATS calculates 

total emissions per 

Source including 

rollup to Facility level

WEB EATS provides 

compliance assessment

notification to Source 

Representatives, 

States, and Tribes

WEB EATS assesses need to 

apply flow control in subsequent 

years and compute appropriate

flow control factor

WEB EATS computes 

penalties based on 

exceedances

Figure 3

Flow Chart of Annual Compliance Assessment Process
WEB EATS Analysis

July 31, 2003

-15-

G. Emissions Tracking and Emissions Reporting

1. Description

Emissions tracking and reporting for compliance purposes following the program trigger

will require a wide range of functionality and data tables. There will be a need to evaluate

carefully how and whether the functionality of the Emissions Tracking Database used for

milestone tracking inventory purposes can be utilized to support the post-trigger emissions

reporting. Also, it will be very useful to identify any potential overlap with existing emissions

reporting systems used for other national or regional trading programs. For example, EPA plans

to put into place the Emissions Collection System (ECS) and Monitoring Plan System (MPS)

sometime after 2004. Although the software itself may not be adaptable for use as the emissions

reporting module of WEB EATS, the system requirements and design should be consulted as an

additional, more detailed, roadmap in the initial stage of system design.

The following general areas of functionality would be required: 

Reporting Requirements and Tracking Information. To facilitate program

implementation, the WEB EATS would identify monitoring and reporting obligations of each

source participating in the program and track the receipt of required information. At least three

types of reporters are envisioned: 

! Part 75 reporters (submitting SO2 emissions reports directly to EPA); 

! Hourly non-Part 75 reporters; and 

! Annual reporters (not participating in trading because of monitoring limitations). 

For each of these type of reporting there are distinctly different reporting obligations and

functionality to support submissions and reported information. 

Monitoring and Emissions Information for Part 75 Units. For Part 75 affected

sources who are reporting SO2 monitoring and emissions data directly to EPA, the assumption is

that redundant submission of these data would not be required. Instead, the WEB EATS would

access or receive information from the EPA system about submissions and reported values

under Part 75. Although EPA does not share these data directly with other data systems

currently, it is anticipated that technological advances and the demand for shared data by other

emissions trading programs would make this not only viable, but routine, by the time the

program trigger occurs.

Monitoring Information for Non-Part 75 Units. For non-Part 75 units monitoring

under Section I of the model rule, the submission requirements are not spelled out in the model

rule. We recommend and assume that the program require and support the electronic
WEB EATS Analysis

July 31, 2003

-16-

submission of monitoring plans that are needed to establish an identification base for monitoring

methodologies, monitoring locations and monitoring systems. These data are needed to support

periodic reporting of hourly emissions data and to ensure that the data from monitoring systems

are certified and quality assured. Tracking capability would be needed to assist in identifying

whether required submissions (electronic and hardcopy) have been received, reviews conducted

and approvals issued. This capability would assist States and Tribes, the TSA, and source

representatives in the implementation phase of the monitoring program. 

Because monitoring plans contain important components which are either graphics or

documentation and are not easily stored as data elements, system designers should consider

including document management capability to complement the tracking of information and

sharing of data between all parties. A robust document manager could provide a submission

process and eliminate or greatly reduce submission of hard copy material. This is an area in

which technical options and standard practices may improve significantly prior to the program

trigger year.

Emissions Data for Non-Part 75 Units. For non-Part 75 sources required to monitor

SO2 emissions, the WEB EATS would support submission, processing and storage of hourly

emissions data. By current standards, the volume of and processing capability for hourly data

could be large. However, it is expected that processing power and data storage capability will

continue to expand and costs will decline. It is also expected that the submission process would

utilize the next generation of broadband access and communication, in whatever direction

technology dictates. Standardization of data reporting protocols would probably facilitate

design and implementation of data submission requirements. The shape of the WEB EATS

would be dictated to a large degree by available technology, supporting basic functionality of

receipt, tracking, checking, analysis, and communication between the regulated sources and

program management. 

Quality Assurance of Emissions Data. Underlying successful cap and trade programs

is the assumption that the emissions recorded and traded are comparable from State to State,

Tribe to Tribe and industry to industry. Clear monitoring protocols and quality emissions data

are needed to maintain the viability of the program. The monitoring and emissions data

collection process should include the appropriate level of checking, analysis to ensure accurate

and complete monitoring and reporting. Part 75 is a useful model of standards and checking

which has provided the appropriate level of market assurances about the quality of emissions. 

The designers and developers of the WEB EATS should provide comparable capability,

including calculation checks, assessment of monitoring system quality assurance compliance, and

the accuracy of missing data routines. Emissions data should be evaluated to check routinely

and periodically for anomalies and inconsistencies.

Petition Tracking. To meet SIP approval requirements, petitions for alternative

monitoring would require joint approval of the State/Tribe and the U.S. EPA. The WEB EATS

should provide a mechanism to track petitions and their approval and disapproval in a centrally
WEB EATS Analysis

July 31, 2003

-17-

accessible location for all State, Tribal and EPA program administrators. The WEB EATS

should highlight and define electronically any aspect of the petition which results in allowable

changes to reporting of monitoring or emissions data.

Annual Emission Statements for Reduced Monitoring Units. For units with reduced

monitoring requirements under Model Rule Section I1.(b), the owner or operator would submit

an annual emissions statement. The WEB EATS would track receipt of these submissions and

record the emissions value reported. Annual production data or other information may also be

required on a case-by-case basis as a condition of State or Tribe acceptance of the request

under Paragraph b. These data should also be recorded in the data system. Consideration

should be given as to whether more frequent emissions reporting than annual reporting (e.g.,

quarterly) should be required in order to facilitate data quality assurance, and the overall system

design should allow for this possibility.

2. Core Data Entities and Attributes

! Tracking. Including projected monitoring and reporting deadlines, submissions, and

approvals or other status. 

! Emissions Methodology/Reporter Type. Compliance period, Facility/Unit.

! Monitoring Locations. Units, stacks and pipes and attributes.

! Monitoring Systems Detail. Monitoring systems, formulas.

! Certification and Ongoing Quality Assurance Test Data. Test dates, overall results, test

detail data.

! Cumulative Quarterly and Annual Emissions.

! Hourly Emissions Data.

3. Core Functional Requirements

! Track deadlines, requirements and submissions.

! Communicate with users about upcoming deadlines or deficiencies.

! Receive emissions report, quarterly and annual.

! Receive original and revised monitoring plans.

! Receive monitoring system certification and quality assurance data.

! Receive quality assurance test data and perform quality assurance checks.

! Address data quality problems.

! Provide final emissions data for annual compliance.
WEB EATS Analysis

July 31, 2003

-18-

H. Program Assessment and Analysis

1. Description

Ongoing program assessment and evaluation is an explicit responsibility of the TSA and

the system design and requirements should reflect the needs for various types of assessment

including: environmental benefits, geographic impacts, market function, implementation

successes and failures, co-benefits, and SO2 control strategies. In each of these areas, the

proposed database design should be evaluated to determine whether anticipated needs will be

met. The analytical utility of the data in WEB EATS will be enhanced in some cases by ensuring

that accurate and complete links to other databases are supported and maintained. Similarly,

geographic analyses will be enhanced by having high quality and complete locational information. 

These data will facilitate the availability and use of deposition and other modeling data. 

It is important to consider the needs of users who want access to basic and repeatable

analyses and the needs of users who want access to the data to perform complex analysis or

one-time analysis. The basic user may best be served by providing standard reports designed to

provide a program overview, summary statistics or status reports on specific types of activity. 

Combined with basic filtering and sorting options, a well designed report will meet many of the

ongoing needs. More flexibility in data analysis could be provided by developing a more robust

query tool, perhaps with control over report formats and output file types. For the high end user

with more complex analytical needs or requiring use of data volumes beyond the capability of

the user interface platform, the ability to request and deliver data in standard formats should be

considered. If it is determined that the basic user needs include access to large volumes of data

in predictable summary formats or quick access to complex data, the design and development of

a data warehouse to facilitate this access should be considered.

2. Core Data Entities and Attributes

! Data warehouse. To provide easier access to aggregated data for analysis purposes.

3. Core Functional Requirements

! Generate standard reports.

! Provide data query tool.

! Provide capability for data export and delivery.

! Provide links to other information systems.
WEB EATS Analysis

July 31, 2003

-19-

I. Public Information Needs and Requirements

1. Description

To support market trading, information about market activity must be available to

market participants and the general public. This includes, in particular, information about

allowance trades and the identity of market participants, including representatives. The specific

data content would be evaluated in detail at the time of design and development. It is expected

that public access to some data, for example the tribal allocations for set-aside, would be

limited.

It should be noted that the timeliness of the data is a critical aspect; but it may be

appropriate to provide access to different types of information at different intervals. For

example, a daily update cycle for allowance trading and representative changes has been

adequate for the Federal trading programs; access to reported emissions data may be provided

quarterly or even annually. 

The ease of access for the public is also important. The current standard is to publish

data though the Web, either in a readable format such as .pdf, in a standard spreadsheet format

or through a query tool which retrieves and displays data in .html format through a browser. 

Although the technology available for public access to information in the next decade is not

easily predicted, it would be expected that similar methods of providing access would be

selected. The technical architecture and data formats should be selected based on security,

speed or performance, overall accessibility to the technology, and flexibility offered in terms of

both output and format.

2. Core Data Entities and Attributes

! Data warehouse. To provide easier access to aggregated data for analysis purposes.

3. Core Functional Requirements

! Timely public access to source inventory, account, allowance and representative

information.

! Public access to periodic emissions data.

! Data downloading or extraction.

IV. Types of Users

As depicted in Figure 1, there are five basic categories of users for the application: 

State and Tribal users; industry users; general account holders; the Tracking System

Administrator; and public users. 
WEB EATS Analysis

July 31, 2003

-20-

States and Tribes

View Reports

Allocate

Allowances to

New Sources

Allocate

Allowances to

Compliance

Accounts

Approve

Paragraph b

Monitoring Add New

Sources/Units

Approve

Petitions

Develop

Enforceable

Procedures for

Recording Data

A. State and Tribal Users

Staff members of a State or Tribe participating in the Backstop Emissions Trading

Program would be key stakeholders and users of the application. These users would have

read-only access to almost all data in the application and a variety of reports. They would

provide key data to the system using a combination of data upload or on-line capability. These

would include facility and unit and program applicability data, general allowance allocations,

allocations from new source set asides, and approvals of monitoring submissions. These users

would have no day-to-day responsibilities for the operation, management or maintenance of the

application or data. 

Figure 4

Use Case Diagram: State and Tribal Users
WEB EATS Analysis

July 31, 2003

-21-

Industry

Update Compliance

Accounts Transfer

Allowances

Change Source

Representatives

Change Source

Owners

View Reports

Update Source/Unit

Characteristics

Certify Compliance Submit Emission

Reports

Submit Monitoring

Petitions and

Monitoring Plans

B. Industry Users

Representatives of the regulated community would also be key users of the application. 

These users would have access to data relating to sources under their control, as defined by

their roles and responsibilities as source representatives. In this capacity, they would be able to

maintain source and unit information, transfer allowances in compliance or general (that they set

up) accounts to and from other accounts, and submit required emissions data and compliance

certifications. 

Figure 5

Use Case Diagram: Industry Users
WEB EATS Analysis

July 31, 2003

-22-

General Account

Holders

Add/Update

General

Accounts

Transfer

Allowances

View Reports

Change General

Account

Representative

Change

General

Account Owner

C. General Account Holders

A representative for a general account would also have access to the application to

update general account information, create new accounts, transfer allowances out of their

general accounts to other accounts and to view reports. The general account holder would have

limited (or no) access to source information, unless the holder is also a compliance account

holder or until such information is determined to be public information.

Figure 6

Use Case Diagram: General Account Holders
WEB EATS Analysis

July 31, 2003

-23-

Tracking System Administrator

Add/Update/

Delete Facilities

and Units

Add/Update/

Delete/Archive

Owners/

Operators

Add/Update/

Delete

Representatives Add/Update/

Delete Users

Perform Annual

Compliance

Assessment

Freeze/

Unfreeze

Account

Trading

Populate

Compliance

Accounts

Generate

Reports

Quality Assure

Data

Track Activities

D. Tracking System Administrator

The Tracking System Administrator (TSA) would utilize virtually all functionality

contained within the application. In appropriate circumstances the TSA would act on behalf of

State/Tribal, industry and general account users. In addition, the TSA would perform all types

of system management and maintenance activities to ensure effective operation of the

application. The TSA would approve access for all users of the application. 

Figure 7

Use Case Diagram: Tracking System Administrator
WEB EATS Analysis

July 31, 2003

-24-

Public

Query Data View Standard

Reports

Extract Data

E. Public Users

Public users have read-only access to selected data within the system. This access

would be consistent with the security requirements of the application and data. 

Figure 8

Use Case Diagram: Public Users

V. Technical Architecture

A key component of system design is the selection of a common architecture. One of

the major components of system architecture is the number of levels or layers in a system. An

application installed on a user's machine that does not communicate with any other applications

or systems is a 1-tier system. A client-server system, where one application sits on a user's

computer (client) and another, related application sits on the server is a 2-tier system. Most

Web applications are 3-tier systems, where there is a browser and Web server (client), a

business logic server and a database server. The system should be built with at least three layers

to separate the display (client), business logic, and database, so that each layer could be

modified without having to change other parts. The exact architecture would be determined at

the time of system design. 

The final decisions about system architecture should consider many factors, including

security, performance, and maintainability.
WEB EATS Analysis

July 31, 2003

-25-

A. Security

Due to the importance of data integrity and accuracy in the WEB EATS, security will be

extremely important. The security measures should be based on current best practices and

standards. The system's security can be divided into two areas: application and server level

security.

1. Application Level Security

The system's application level security consists of the protective measures designed into

the application's code. These include the logical measures to determine which users may access

which areas of the system, the manner in which session management is handled and the

protection of sensitive information, like passwords, at the application level.

! Password Encryption. The system must include a process to authenticate all authorized

users to the system. Today's system utilizes encryption to protect the vulnerable data

elements, such as user passwords. Implementation of an extremely robust encryption,

routine or its equivalent should be incorporated into the system. 

! Separate Logins. Each user should maintain a unique username and password, with the

password encrypted and stored in a secure database. Each user should be assigned a

unique ID. The technology available for security in the next decade is not easily

predicted; available alternative technology to the use of passwords should be

considered.

! Separate User Types. The access rights and restrictions should be controlled at the user

group level. Each user group would have a unique set of rights and restrictions within

the WEB EATS. Upon user login to the system, the user's specific user group security

should be verified and rights and restrictions set for the session. If the user belongs to

multiple user groups, they should be assigned the highest rights for a given section or

action among their user groups.

! Audit Trail. The system design should include specific requirements to maintain an audit

trail of data adds, updates, and deletes for critical data elements. This audit trail should

be designed to detect and resolve challenges to the data (for example, allowance

ownerships), and as an additional means of restoring data should there be a breach of

data integrity.

! Session Management. Strict session management control, in which session tokens are

properly protected and validated, is essential. When two applications are run remotely

from each other (like a browser and a server), they require session tokens to be able to

communicate about the application state. To prevent attackers from hijacking active
WEB EATS Analysis

July 31, 2003

-26-

sessions and assuming the identity of a user, session tokens need to be regularly revalidated.

2. Server Security

The system's server level security consists of the protective measures designed to

protect the server itself from inappropriate access. These include proper server maintenance

and the modifying of default system passwords.

! Server-Side Data Validation and Business Logic. To the extent possible, all business

logic and data validation should be checked and handled at the server level and not be

coded at the client or browser level. Server-side validation improves performance and

reduces the risk of a user bypassing business logic designed to prevent them from

submitting invalid data. Server-side validation includes business logic as well as basic

data type validation (i.e., length, range, data type, characters sets).

! Server Maintenance. The servers or host platform should be maintained according to

security standards. For example, many of today's current servers are patched on a

regular basis with the latest security releases as soon as they are available. Because

flaws in server software are usually well known in the hacker community, it is important

to protect the server from attackers. 

! System Passwords. The system passwords to the servers or host platform should be

modified from their defaults and changed on regular intervals. Because the default

passwords for commercial servers are commonly known, they pose a security threat

and should be changed. Also, standard security practices should be followed regarding

the regular changing of passwords.

3. Physical Data Security

Physical data security should be provided by the measures to protect the data center, a

specialized facility that hosts an application, from dangers. These dangers include theft, natural

disasters, manmade catastrophes, and accidental damage (e.g., from electrical surges, extreme

temperatures, spilled coffee, etc.). The data center that hosts the WEB EATS should maintain

strong security practices and undergo periodic audits. 

4. Backup and Recovery

The database should be backed up at least daily and the application files should be

backed up regularly. It may be advisable to back-up the allowance transaction data at a more

frequent interval, based on the frequency of use and level of recoverability deemed necessary. 

A copy of the backup files should be stored off-site from the data center to ensure minimum

downtime should a catastrophe occur.
WEB EATS Analysis

July 31, 2003

-27-

A Catastrophe Recovery Plan (CRP) should be created to enable the application to

return to service as soon as possible following a catastrophe. Most CRPs contain the following:

! Threat analysis,

! Risk assessment,

! Mitigation steps,

! Response and recovery plans,

! Damage assessment process,

! Salvage procedures, and

! Rehabilitation plans.

B. System Performance

The system's performance can be greatly improved with the intelligent application of 

best practices and procedures for performance tuning and system design. These include the

following:

1. Database Design and Query Optimization

The database should be designed with performance in mind. All database queries

should be optimized to maximize performance. Use of views and indices or similar database

functionality should be considered to maximize database performance. By limiting the results to

only those that will be utilized immediately, the system will minimize the server and network

resource load.

2. Session Variables

System design or programming technologies that overuse session variables can degrade

the performance of the system. Therefore, only information that absolutely must be maintained

to keep the session active should be stored in session variables. Following a user logout or the

expiration of a short time limit, session variables should be explicitly purged from memory.

3. Archiving Data

Data should be archived regularly to conserve database space and enhance

performance. A mechanism should be provided for retrieving the archived data for reporting

purposes. 

4. Data Volume

The data volume of the WEB EATS will be largely determined by the number of

sources and the frequency of data collection. With a planned number of sources of less than a

thousand, which may include the periodic submittal of hourly data collection, the database is
WEB EATS Analysis

July 31, 2003

-28-

projected to grow approximately 4GB per year. To ensure maximum performance, the

database should be regularly re-indexed and monitored for performance. It is recommended

that the emissions data collection component sit on a separate server from the business logic

server for performance gains.

5. Frequency of Use

The system design should take into account the number of users, the level of access, and

the volume of data provided by users for specific processes. The WEB EATS usage is

expected to be well within the normal expectation of capability for a small to moderate size

application. For emissions data submission, the volume of data may be relatively high (by

current standards) and require special design consideration.

C. Maintainability

To achieve a flexible system that evolves with program needs, the system should be

developed for maximum maintainability. If the application is based on vendor software, it should

be built upon well-known technology and platforms. If it is custom developed, it should be well

documented and based upon best programming practices and standards and developed in a

common development language. These measures will minimize time and cost to maintain the

application following implementation.

In addition, the programming team should be required to adhere to programming

standards, including code organization and documentation, to facilitate support and

enhancements after deployment.

Post-deployment modifications should be developed by a set protocol including input

from users.

D. System Outputs

The system should support various types of outputs, including data transfers, electronic

communications, like email, and connections to external systems. During the system design, the

needs of the proposed users and the archiving of data should determine exactly which system

outputs should be available.

1. Data Transfers

The periodic transfer of emissions and related data should be communicated to the

application via a standard information exchange protocol. The exact protocol and procedure

will need to be determined based on best practices and volume of data at the time of

implementation. Each data record should be error checked to verify its integrity during the

submission process.
WEB EATS Analysis

July 31, 2003

-29-

2. Electronic Communications

The application should contain functionality that notifies parties via electronic

communication upon the execution of certain actions. These actions would include, for example,

allowance transfers, freezing/unfreezing accounts, and system maintenance notices. The exact

list of actions, subsequent message media, recipients, and structures should be determined as

part of system design.

3. External System Connections

The application would be expected to provide data to external data systems such as the

Emissions Inventory System that the WRAP will be using to perform the program trigger

evaluations tracking. The system should also support connectivity with the National

Environmental Information Exchange Network and Tribal Emissions Implementation Software

Solution (TEISS). The exact methods used to connect other systems will be determined at the

time of system design. 

The application should also be able to communicate and transfer data files to and from

other EPA data and allowance tracking systems, such as the system supporting the federal SO2

emissions trading programs. 

E. Application of Platform Selection Criteria

During the preliminary phases of the system design, a significant decision will be the

selection of the technology platforms or architecture for the system. These platforms include the

Web server, business logic server, database server, and client interface. For each of these

platforms, consider these issues with the following questions in mind:

! Data volume. Will the volume of data which must be maintained, transferred and

analyzed be supported by the database and/or the application? Be sure to calculate the

data volumes over the estimated life cycle of the project keeping in mind any applicable

program specific or overarching regulatory requirements relating to government

recordkeeping. 

! Performance. What are the minimum performance requirements for basic application

tasks, such as accessing the system, updating source information, transferring

allowances? What are the minimum performance requirements for infrequent tasks,

such as annual compliance assessments, data quality analyses, or submitting hourly

emissions data? What are the performance requirements for reports?

! Relative Costs. What are the overall cost constraints? What is the acceptable ratio of 

design costs to development costs and initial deployment costs versus maintenance

costs? Research these issues for comparable systems and platforms.
WEB EATS Analysis

July 31, 2003

-30-

! Maintainability. What specific standards and assumptions should be imposed for

maintainability? 

! Connectivity. Which connectivity standards should the system support?

! Efficiency. Are there specific design choices which will impact the efficiency of program

implementation? Examine design options and platform options to maximize efficiency

benefits of the information system for the overall operation of the program. To what

extent should the efficiency benefits to regulated industry, general account holders and

the public be taken into account?

! Availability. What level of system availability is acceptable for each type of user?

VI. Design and Development Approach

The second objective of this document is to serve as a roadmap to help the States and

Tribes implement the program once it has been triggered. Outlined below is an implementation

methodology that the States and Tribes can follow to design, develop and deploy the system. In

addition, this section provides an analysis of cost and scheduling factors that should be

considered.

A. Recommended Implementation Methodology

Upon the trigger of the WEB Trading Program, detailed system requirements will need

to be assessed. The following section recommends, steps to design, develop and implement an

information system for the program. It is recommended that a workgroup be created and

assigned responsibility for this task. The workgroup should be comprised of user group

representation, program analyst(s), and technical specialist(s).

1. Requirements Verification

The first step following the need to implement the program will be to verify the

requirements of the information system. Since many of the procedural elements of the SIP/TIP

will be decided in the future, the exact functionality may have changed since the creation of this

document. Therefore, detailed requirements should be verified and incorporated into a system

analysis document. It is expected that this stage of the process will require significant

participation of all stakeholders, particularly the States and Tribes participating in the program.

2. Assessment of Current Standards and Technology

Following the verification of requirements, the workgroup should research and assess

the current standards and technologies applicable to this type of information system. Since this

application would probably not be designed until many years after this document, it was
WEB EATS Analysis

July 31, 2003

-31-

determined that the current standards would have little value and these have not been evaluated

or referenced.

3. Technical Architecture Option Evaluation

Just as the standards and technology should be evaluated, so should the possible

technical architectures, as discussed above. Most systems at the time of the creation of this

document are 3-tier, but that should certainly not limit the architecture of the WEB EATS. Also,

the suggested measures for security and maintainability may no longer be applicable, and should

thus be re-evaluated. 

4. Closeness of Fit

Based upon the system analysis requirements, standards, and architecture assessments,

the workgroup should perform a Closeness of Fit study to analyze the available products,

technologies, and platforms available. By analyzing the field of products, technologies, and

platforms available, the Closeness of Fit study should conclude with a recommended product or

set of development technologies and standards.

5. Decision

Based upon the Closeness of Fit study, the workgroup should select a product from a

vendor(s), develop a custom system, or a combination of the two.

6. Design/Customization/Development Strategy

Following the decision to either select a Commercial Off-the-Shelf (COS) product,

develop a custom application, or customize an existing application, the workgroup should select

a developer and/or TSA to design, develop and implement the system. 

The development plan should include a careful review of the schedule of program

implementation and requirements to ensure that the necessary elements of the application are in

place at the appropriate time. A staged process, with design, development, and deployment of

specific system modules, is recommended. For example, the initial phase of development would

probably focus on the source registration capability and initial allowance allocations. Later

development could include allowance transfers capability, annual compliance assessment or

overall program assessments. 

7. Development

Following agreement upon the system design, the developer or TSA should develop the

system utilizing modern development best practices and procedures. It is recommended that the
WEB EATS Analysis

July 31, 2003

-32-

developer and/or TSA work with the members of the requirements gathering workgroup to reaffirm and adjust requirements as needed.

8. Quality Assurance/Testing

Following the successful development of the system, the developer/TSA should submit

the system for rigorous testing. A test environment should be set up and a test database should

be populated with data that closely match the quantity and type of data that will be utilized

during live transactions. All phases of the system should be rigorously tested by the

developer/TSA, States and Tribes, and a select group of end-users. 

9. Deployment

Following successful quality assurance of the system, the workgroup and the

developer/TSA should agree that the system is ready to be deployed or implemented in a

production environment. Prior to production, the database will need to be populated with the

necessary baseline information including source inventory data, emissions data, users, etc. The

developer/TSA should provide training/instructions to users of the system along with appropriate

documentation. It is assumed that participating States and Tribes will work closely with the

TSA to define and implement a communication strategy to ensure compliance with all program

requirements and full use of the information management system developed to ensure its success.

B. Timing/Schedule

If there is no significant delay after program trigger in the initiation of the information

system design and development process and if a staged approach to deployment is adopted,

then an implementation schedule in which the necessary system elements are in place is

achievable. This objective should be stated at the outset of the project.

It should be noted that the use of COS or the customization of an existing system might

reduce the initial development time for the system. To fully design, develop and deploy a

custom application by today's standards might extend one to two years. Additional time might

be necessary if there were significant issues relating to functionality or process about which State

and Tribal participants could not agree. Technology trends indicate that forthcoming design and

development methodologies will likely reduce this estimate.

C. Cost Factors

Factors driving the cost of the information system include technical platform, design

complexity, data volume, security level, and the level of and approach to integration with other

data systems. The availability of and use of COS or another application as the basis for the

application would also affect costs. 
WEB EATS Analysis

July 31, 2003

-33-

1. Technical Platform

The technical platform includes the server software and business logic systems that are

required. There are a wide range of options for the level of solution required and cost. A

middle-ground solution is most likely the most suitable for the WEB EATS, one that maximizes

flexibility and maintainability.

2. Design Complexity

The level of complexity incorporated into the system design will be a large cost factor. 

Generally, the more complex systems are, the more they cost. Based on the current system

analysis, the system design appears to be moderately complex. As with any application, the

requirements phase of the project may result in relatively more or less complex requirements,

directly affecting costs.

3. Data Volume

The amount or volume of data will be a key cost driver in selecting the database server. 

If only one database is utilized for both the allowance and emissions data in WEB EATS , the

database will grow quickly and will require a high-end solution to maintain performance levels. 

It is expected that the relatively high data volume will require database optimization and regular

tuning, which will add to the maintenance costs.

4. Security Level

The level of security built into the system will certainly affect the cost. The more robust

the security model is, the more time consuming and costly to implement. The security level

detailed in Section III(A)(I) dictates a moderate level of security. 

VII. TSA Responsibilities and Performance Criteria

A. TSA Responsibilities

The Tracking System Administrator (TSA) will have responsibility for the deployment of

the site, ongoing maintenance and the day-to-day program implementation tasks associated with

the program. It seems likely that the TSA would also design and develop the information

system, but it is not necessary that both development and support should be provided by the

same organization. Regardless, the ongoing responsibilities of the TSA would include two types

of support: information system and program implementation. 
WEB EATS Analysis

July 31, 2003

-34-

1. Information System

This category of support is to ensure that the information system is properly

administered, supported and performs all required functionality.

! Data security. The TSA would assume responsibility for ensuring that the security of the

site and the data is monitored and protected on an ongoing basis. This would include

monitoring access to the site and attempted but failed access (particularly if occurring in

significant volume).

! Data integrity. The TSA would assume responsibility for ensuring that the integrity of the

data is monitored and protected on an ongoing basis. This would include ensuring that

the referential integrity of the data is maintained, a data backup plan is implemented, and 

any opportunities for data corruption are identified and addressed. 

! Data quality assessment and corrective maintenance. The TSA would develop within

the application and be responsible for performing data checks to identify duplicative

information, data omissions or other data of poor quality that are not easily prevented by

error checks or data standards. The TSA would make corrections to the data, as

necessary, and maintain documentation of changes. 

! WEB EATS enhancements. The TSA would document and evaluate any proposed

enhancements, modifications or additions to the application. Working with the

State/Tribe participants in the trading program and within established budget constraints,

the TSA would perform, test and deploy the modifications (in coordination with the

assigned programming team).

! WEB EATS documentation. The TSA would have responsibility for maintaining all

technical documentation for the WEB EATS (including enhancements and for

maintaining records relating to its ongoing operation).

! User technical support. The TSA would provide technical support to all users of the

application. This would include telephone support and responses to requests or inquiries

through other means of communications. The TSA would maintain records of all

technical support and the TSA response. Technical support needs could also be

addressed through the use of other support tools, comparable to the FAQs or online

support systems currently in use.

! Performance monitoring. The TSA would be responsible for monitoring the overall

performance and availability of the application for all types of users. This would include

identifying the causes of any disruption of service or availability and identifying any

persistent problems experienced by the user community.
WEB EATS Analysis

July 31, 2003

-35-

! Database administration. The TSA would monitor data performance and perform all

maintenance and optimization tasks affecting the performance of the database. The

TSA would maintain records of all database administration activities.

2. Program Implementation

The TSA is also expected to implement the program for the consortium of States and

Tribes participating in the program. This is necessary to ensure that the program will be

implemented consistently and cost effectively. 

! User access administration. This support would include evaluating and responding to

user access requests, password changes, and related usage issues. 

! Coordination with States and Tribes. The TSA will coordinate, as necessary, with each

State or Tribe participating in the program to ensure that the State or Tribe fulfills their

responsibilities and is aware of the need for their participation in decisions or issues. 

This includes aiding the States and Tribes in developing enforceable procedures for

recording the necessary data. For example, the TSA would obtain allocation lists,

petitions, retirement approvals, information about new sources, and reduced emissions

monitoring under Section I1.(6) of the model rule from the State or Tribe.

! Perform allowance allocations. Using the information provided by the State or Tribe,

the TSA would perform allowance transfers from government accounts to compliance

accounts. The TSA would provide a report (or electronic file) to the State or Tribe of

these actions.

! Perform allowance transfers. Using the information provided by the representative of

the account in which the allowances are held, the TSA would perform valid allowance

transfers from the account to another account. The TSA would provide notice to the

representative of these actions or of rejections or invalid transfers.

! Periodic status reports on system activity and program implementation issues. On a

regular basis (monthly, quarterly and annually), the TSA would provide to the

participating State and Tribes a summary of program activity. This report would

include, for example, a summary of allowance transfer activities, a status report on

emissions reports, or the level of public access to the database.

! Annual compliance assessment. The TSA would perform the annual compliance

assessment or true-up and would coordinate with industry, States and Tribes regarding

the results of this process. Following review or approval by the participating States and

Tribes, the TSA would finalize the compliance assessment by retiring the appropriate

number of allowances from compliance accounts. An end-of-year compliance report

would be made available.
WEB EATS Analysis

July 31, 2003

-36-

! Communication strategy development/implementation/support. Throughout the life of

the program, the TSA would work with the participating States and Tribes to maintain

and implement a communication strategy and plan. The purpose of the plan would be to

ensure full participation of affected sources in the emissions trading program and to

maximize understanding of and knowledge about the program among all interested

parties. The content of the plan would include a strategy for general guidance, day-today communications to sources about their actions (transfer confirmations, data receipts,

etc.), State/Tribal reports, communications between States and Tribes about ongoing

program issues such as monitoring approvals or petitions, participant or public meetings

and publications containing program results or environmental assessments.

! Overall program assessment. The TSA would assist the States and Tribes in designing

and conducting an assessment of the overall program operation, costs, and

environmental benefits on a periodic basis. 

! Error correction, followup and documentation. The TSA would be responsible for

correcting any data entry errors reported by users that are not within the security limits

for the user.

B. TSA Performance Criteria

To ensure adequate support for the program, it will be necessary to establish

performance criteria for the TSA. 

1. Technology Standards

For the WEB EATS and technology support, the key criteria should be based on

technology standards prevalent at the time of deployment and they should be tailored to the

technical architecture selected for the WEB EATS. The following criteria would fall into this

category and should be defined at the appropriate time. The importance of each of these factors

should also be considered during the WEB EATS system design phase and in the selection of a

technical architecture. 

! System performance (response time, number of concurrent users supported, frequency

of WEB EATS or database errors, etc).

! System availability (average downtime).

! Timeliness of public access to data.
WEB EATS Analysis

July 31, 2003

-37-

2. Contract Performance Standards

Other important criteria relating to TSA performance would be the traditional criteria

relating to overall performance with respect to basic contract terms. These would include:

! Responsiveness to customer concerns,

! Timeliness and quality of status reports,

! Overall cost, and

! Budget accuracy.
WEB EATS Analysis

July 31, 2003

-38-

References

1. Jenkins, George Henry. Information Systems Policies & Procedures Manual. Paramus,

NJ: Prentice Hall, 1997.

2. "The Ten Most Critical Web Security Vulnerabilities." The Open Web Security Project. 

13 Jan. 2003. <http://www.owasp.org/>.

3. United States Environmental Protection Agency. Clean Air Market Programs. 

Emissions & Allowance Tracking System. 

4. United States Environmental Protection Agency. State/EPA Information Management

Workgroup. Blueprint for a National Environmental Information Exchange Network. 

June 2001.