Emissions Collection and Monitoring Plan System Project Stakeholder Update February 17, 2005

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

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

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

4. Monitoring Plan Process

5. 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!

6. 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!)

7. ECMPS Monitoring Plan Process

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

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

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

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

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

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

14. Certification/Recertification and Quality Assurance Process

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

16. 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 (currentlyRT 556) will be supplemented in order to track applicable QA tests for data validation.

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

18. Daily Quality Assurance and Hourly Emissions Process

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

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

21. Daily Calibration Validation

22. Daily Interference Validation

23. Hourly Data Issues • Redundant and unnecessary data • New data requirements

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

25. 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?

26. ECMPS Technical Architecture

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

28. Technical Architecture Requirements (cont’d): • Synchronize data between the Client Tool and the CAMD database • Leverage existing reengineered data structures and processes

29. Technical Architecture

30. 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)

31. Client Tool Two Configurations • Single Workstation • Workstation(s) and Database Server with MSDE Express or MS SQL Server

32. Client Tool Configurations

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

34. System Requirements MS SQL Database Server for Multiple Workstations • 733 MHz processor • Windows 2000/Server 2003 • 1 GB RAM • 8 GB free disk space

35. Client Tool Security • Local Client Tool database security maintained through single user • Client Tool provides access through basic user name and password security

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

37. Technical Concerns • Processing Performance • Data Retrieval Performance • Version Control • Data Synchronization • Record Locking

38. New File FormatClient Tool

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

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

41. 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 ASCII Text vs. XML Format

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

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

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

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

46. Rule ChangesProject Time Line

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

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

49. 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)

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