# Presentation: 936817

## Emissions Collection and Monitoring Plan System Project

***Emissions Collection and Monitoring Plan System Project***
***Stakeholder Update***
***February 17, 2005***
***Washington, DC***
***By Clean Air Markets Division***

## Meeting Objective

- Review the project scope
- Discuss changes to the monitoring and emissions process
- Discuss the technical architecture need to support the new process
- Discuss the desktop application and new file format

## ECMPS Project Scope

- Create a single tool for ALL users
- Allow industry users to run checks on desktop prior to submission
- Provide feedback when data is checked and submitted
- Provide user with greater flexibility to maintain, check and submit data
- Take advantage of newer technology

## Monitoring Plan Process

## Current Monitoring Plan Issues

- MP records must be included with every submission
- Common errors occur when
- The submitter does not properly close out old information, or
- The MP is inadvertently changed by a mistake in a submission or resubmission of QA or Hourly data
- EPA’s MDC-CAMD Database must interpret differences as changes and decisions must be made about how to import those changes - Sometimes even the best possible assumptions are not correct!

## Monitoring Plan Issues (cont’d)

- The current format and process often lead to data artifacts in the CAMD database which lead to error feedback in the QA and Hourly data audit process
- The user’s desktop version of MDC often provides different results if their MDC database does not match the CAMD database - (Synchronization is needed!)

## ECMPS Monitoring Plan Process

## Monitoring Plan Process: Key Change #1

- MP data cannot be imported into the client tool from the existing format (the ASCII text EDR format will be obsolete)
- CAMD will convert the current MP data (as stored in MDC CAMD) into the new format and store it in the new CAMD database
- Industry users will use the client tool to retrieve, _verify_, and modify (as appropriate) their data

## Monitoring Plan Process: Key Change #2

- The client tool will allow the user to:
- Create a new monitoring plan
- Edit an existing monitoring plan
- Import monitoring plan data from your DAHS or other tools
- Check the monitoring plan
- Submit monitoring plan data to CAMD
- Export monitoring plan in XML format

## Monitoring Plan Process: Key Change #3

- Methodology records will be linked to the relevant unit/stack/pipe (location of the actual systems) rather than always using the unit ID
- New codes are proposed to do this

## Monitoring Plan Process: Key Change #4

- Component type codes will be simplified to identify only the parameter monitored
- Range and moisture basis will be added as new fields in the component data

## Monitoring Plan Process: Key Change #5

- Start/End date and hour will be added to track the component/system relationship
- New components will require a new component ID

## Monitoring Plan Process: Key Change #6 

- For dual range systems, a new field is proposed to identify where the DAHS switches from recording from the low range to the high range
- This is critical to be able to check the linearity and daily cal status with greater certainty for dual range configurations

## Certification/Recertification and Quality Assurance Process

## Certification and QA Test Process:Submission

- Component-level tests will only need to be reported once
- The client tool will support creating, editing, importing, evaluating and submitting all test data
- Test data must be imported/entered into the client tool and submitted prior to the hourly data that is validated by the test

## Certification and QA Test Process: Evaluation

- The client tool will recalculate all test results and submit those results to the CAMD database
- Only extension and exemption information that can’t be calculated or tracked will be required to be reported
- The information collected for monitoring system recertification, maintenance, or other events (currently** **RT 556) will be supplemented in order to track applicable QA tests for data validation.

## Certification and QA Test Process:Tracking

- The client tool will provide initial certification status and tracking information.
- The client tool will provide a mechanism for submitting Test Notices to CAMD, State, and Local agencies.
- The client tool will provide an up-to-date QA test timeline with projections for future test deadlines.

## Daily Quality Assurance and Hourly Emissions Process

## Daily QA Data Process

- Enhance the QA process for the Daily quality assurance tests -  Daily Calibration and Daily Interference
- Redesign Daily QA data (Current RT 230 and RT 623) to allow QA of submitted data
- Redesign data validation procedures for daily QA tests

## Daily Calibration Data Proposal

- Combine all zero/low and high level injection data for a single daily cal into one data set
- Remove instrument span (since it is redundant with the monitoring plan data)
- Remove System ID to eliminate duplicate reporting for components in more than one system

## Daily Calibration Validation

## Daily Interference Validation

## Hourly Data Issues

- Redundant and unnecessary data
- New data requirements

## Proposals to Consolidate Redundant Hourly Data

- Remove F-factor from NOx Rate data; Add additional F-factor fields to operational data
- Consolidate load range info in operational data
- All load range bin information will be in operational data with added optional field for common stack sources
- Remove multiple fuel flag from oil and gas flow data
- Remove NOX and Heat Input methodology fields from NOX Mass data and replace with flag for unmonitored bypass stack

## Other Redundant Hourly Data Areas Under Review

- CO2 concentration/CO2 diluent data
- Eliminate current RT 202, use CO2 diluent concentration data and modified O2 diluent concentration data (add calculated CO2 data from O2 diluent)?
- Remove requirements to report both adjusted and unadjusted hourly data?
- Remove formula ID fields from hourly records?

## ECMPS Technical Architecture

## Technical Architecture

- Requirements:
- Replace the use of the mainframe
- Provide a Client Tool that interacts with the CAMD database
- Maintain a Client Tool database for local data storage and processing

## Technical Architecture

- Requirements (cont’d):
- Synchronize data between the Client Tool and the CAMD database
- Leverage existing reengineered data structures and processes

## Technical Architecture

## Technical Architecture

- Visual Basic .NET (Client Tool, Business Logic, and Server-Side Processes)
- MS SQL Server (Client Tool database)
- Oracle (CAMD database)
- ColdFusion MX (Web services on CAMD Web Server)

## Client Tool

- Two Configurations
- Single Workstation
- Workstation(s) and Database Server with MSDE Express or MS SQL Server

## Client Tool Configurations

## System Requirements

- Single Workstation with Client Tool and MSDE Express Database
- 300 MHz processor
- Windows 2000/XP Pro
- 512 MB RAM
- 7 GB free disk space

## System Requirements

- MS SQL Database Server for Multiple Workstations
- 733 MHz processor
- Windows 2000/Server 2003
- 1 GB RAM
- 8 GB free disk space

## Client Tool Security

- Local Client Tool database security maintained through single user
- Client Tool provides access through basic user name and password security

## Access to CAMD Database

- Users registered with the CAMD Business System will have access to their data
- CAMD Business System users will be able to designate agents to perform specific tasks

## Technical Concerns

- Processing Performance
- Data Retrieval Performance
- Version Control
- Data Synchronization
- Record Locking

## New File FormatClient Tool

## Limitations of the Current File Format

- ACSII text file format does not work well in a database environment
- Dependent on record types and column lengths
- Difficult to incorporate new program data with different reporting requirements
- Running out of record types

## Advantages of XML Format

- Loads more easily into a database
- Not constrained by record type
- Field lengths no longer an issue
- Allows for easy transfer of data between EPA and user
- EPA accepted standard

## ASCII Text vs. XML Format

- ASCII Text Format
- Strict file construction
- Record Types
- Column lengths
- Reserved fields
- Based on pollutant

- XML File Format
- Flexible file construction
- Programming tags
- Data fits between tags
- No reserved fields
- Based on date and hour

## Example XML File

- <?xml version="1.0"?>
- <MonitoringPlan xmlns="http://www.epa.gov/airmarkt/xml/MonitoringPlan.xsd">
- <Facility>
- 	<ORISPL>000003</ORISPL>
- 	<FacilityName>BARRY</FacilityName>
- 	<NAICSCode>4911</NAICSCode>
- 	<SourceCategory>ELECTRIC UTILITY</SourceCategory>
- 	<FacilityState>AL</FacilityState>
- 	<CountyCode>097</CountyCode>
- </Facility>
- <Unit>
- 	<UnitID>6B</UnitID>
-  	<UnitType>CC</UnitType>
-  	<MaximumHourlyHeatInputCapacity>2127.0</MaximumHourlyHeatInputCapacity>
-  	<CommercialOperationDate>2000-03-21</CommercialOperationDate>
-  	<UnitRetirementDate>2000-03-21</UnitRetirementDate>
-  	<StackExitHeightAboveGroundLevel>121</StackExitHeightAboveGroundLevel>
-  	<GroundLevelElevationAboveSeaLevel>25</GroundLevelElevationAboveSeaLevel>
-  	<InsideCrossSectionalAreaAtFlueExit>216</InsideCrossSectionalAreaAtFlueExit>
-  	<InsideCrossSectionalAreaAtFlowMonitorLocation>0</InsideCrossSectionalAreaAtFlowMonitorLocation>
-  	<NonLoadBasedUnitIdentifier>0</NonLoadBasedUnitIdentifier>
-  </Unit>
- </MonitoringPlan>

## New Client Tool

- Create one application to check, store, maintain and submit data
- Replaces ETS-FTP, ETS Mainframe, MDC Hourly, MDC-QR, MDC-FTP
- Incorporates new and some existing functionality
- Interacts with CAMD Business System

## Client Tool Functionality

- Step-by-step instructions
- Support loading data in XML format
- Support batch import, checking and submission
- Create or revise the monitoring plan
- Create electronic test data
- Automated software and data check updates

## Client Tool Functionality (cont’d)

- Create hourly data for a Low Mass Emissions unit
- Contains reporting and tracking functionality
- Notifies user of new data checking criteria and other program-related information
- Maintain User ID and Password
- Enforce security rules

## Rule ChangesProject Time Line

## Rule Changes for ECMPS

- Revisions to the record keeping and reporting requirements (Subparts F & G)
- Synchronize the initial monitoring plan deadline with the initial certification test notice (21 days prior to testing)
- Reorganize the data requirements in a manner that reflects the proposed data structure
- Monitoring plans updates are done as needed and do not have to be resubmitted with each quarterly emissions report
- Changes reflect the proposed process changes

## Rule Changes for ECMPS

- Other process changes include:
- Defining a (optional) procedure for using “long-term cold storage” as described in §75.4 as means to suspend reporting for units that plan to shutdown for at least 2 years.
- Add requirement for reporting of a maximum low range value for duel range configurations.

## Other Rule Changes...

- EMB may propose changes such as:
- Simplify the Ozone Season QA requirements
- Update incorporated references in §75.6
- Add an F-factor method determination procedure  to Appendix F for non-traditional fuels (reduce need for petitions)
- Specify that substitute data can be applied on a “step-wise” basis (note change to Policy Question 15.5)

## ECMPS Time Line

- Development Time Line
- 2004 – 2005: Define requirements and develop
- 2006: Test the process (Beta Testers)
- 2007: Implement the new process
- Rule Change Time Line
- Publish Direct Final & Proposed Rule in November 2005
- Final Rule Published by October 1, 2006
- Final Rule effective as of January 1, 2007

## Open Forum for Discussion

- How should EPA manage the test period?
- How should EPA communicate changes in checks and the process?
- Other questions