**ECMPS Project Stakeholder Meeting**

**February 17, 2005, 9:00 a.m. - 5:00 p.m.**

**Washington, DC**

**FINAL MEETING NOTES**

On February 17, 2005, the Clean Air Markets Division (CAMD) hosted an
ECMPS Project Stakeholder Meeting. The meeting was scheduled from 9 a.m.
until 5 p.m. with an hour break for lunch. Martin Husk, Matt Boze,
Travis Johnson, and Mani Oliva of CAMD and David Ward of PQA gave
presentations at the meeting. Also in attendance were Janice Wagner, Rey
Forte, Laurie DeSantis, and Craig Hillock from CAMD and Angela Saunders
and Rebecca Lim of PQA. The list of attendees is included in a separate
attachment. The meeting, which was scheduled to last until 5:00 p.m.,
concluded early at 3:30 p.m.

**Note that there are many issues, concerns and questions listed
throughout the meeting notes. The majority of these are answered under
the Questions and Answers section of the ECMPS web site at
http://www.epa.gov/airmarkets/business/ecmps/ecmps.html.**

**I. Meeting Overview**

Martin began the meeting by welcoming the sources and vendors to the
ECMPS Project Stakeholder Meeting. The agenda for the meeting is
included as Attachment A and the presentation and handouts available at
the meeting are included in separate attachments.

**II. Meeting Objective**

> A. Martin discussed the objectives of the meeting:
>
> ! Review the project scope
>
> ! Discuss changes to the monitoring and emissions processes
>
> ! Discuss the technical architecture needed to support the new process
>
> ! Discuss the desktop application and new file format

-   Discuss rule and reporting changes needed to support the ECMPS
    process

B. Martin described the project scope for the ECMPS Client Tool:

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

**III. ECMPS Monitoring Plan Process**

Matt Boze gave the presentation on the ECMPS Monitoring Plan process. He
began by describing the current Monitoring Plan process and noted some
of the issues with the current system.

Matt also discussed some of the key changes to the Monitoring Plan
process with the ECMPS Client Tool.

> \(1\) MP data cannot be imported into the client tool from the
> existing ASCII text EDR format. 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.
>
> \(2\) The client tool will allow the user to create a new monitoring
> plan, edit an existing monitoring plan, import monitoring plan data
> from their DAHS or other tools, check the monitoring plan, submit
> monitoring plan data to CAMD, and export monitoring plan in XML
> format.
>
> \(3\) Methodology records will be linked to the relevant
> unit/stack/pipe rather than always using the unit ID. There are new
> codes which have been proposed to do this.
>
> \(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.
>
> \(5\) Start/End date and hour will be added to track the
> component/system relationship. New components will require a new
> component ID.
>
> \(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.

**A**. **Monitoring Plan Questions/Concerns**

> QUESTION: It sounds like there is a problem with the EPA Monitoring
> Plan being different from the utility\'s Monitoring Plan. Will there
> be version control under ECMPS? Will there be a way to compare the
> sources Monitoring Plans to what is in EPA=s database? How will we
> know which Monitoring Plan the EPA has?
>
> CONCERN: The end user wants the capability to look at historical as
> well as submitted data. They want this capability available within the
> client tool. Additionally, there should be the capability to fix and
> update the history.
>
> CONCERN: In order to make improvements to the existing process,
> sources will
>
> no longer use the existing EDR. The goal is to have a single
> transition with only one tool. Changing the formats in the EDR would
> be a huge undertaking.
>
> CONCERN: It was noted that contrary to what was presented at the May
> 2004 Stakeholder Meeting, the Monitoring Plan data will be in XML
> without a tool to convert from EDR to XML format. This will mean more
> work for the utilities since they don\'t actually use the EPA tool to
> manipulate the data, instead they use the DAHS or other application.
> So the timeline for converting to the new tool will be affected.

Martin responded by stating that at the meeting last May 2004, the group
was beginning to define requirements. It turned out to be infeasible to
preserve the EDR format due to the amount of changes to the data. Many
sources would rather move straight to the new XML version rather than
having an intermediary \"EDR version 3.0.\"

> QUESTION: Is there a tool to convert ASCII hourly data to XML?

Martin replied that what comes out of the DAHS will be in XML format.

> CONCERN: How will this affect the non-traditional sources who are
> subject to NO~x~ Budget? These organizations typically have fewer
> resources and will require more help with the process.
>
> CONCERN: There is a concern that sources will lose control of the
> Monitoring Plan.

The goal of the trading programs is to measure SO~2~, NO~x~, CO~2~, and
Heat Input. All sources will benefit from the change to XML, as the XML
format allows the creation of unit/configuration specific tags that only
need be adopted by the affected source. In the past, any change to
reporting requirements were adopted and programmed for by all sources.
It was determined that re-engineering the monitoring and emissions
processes was a best way to accommodate the diverse community which CAMD
regulates.

> ISSUE: The Client Tool will take care of housekeeping including
> keeping the EPA records up to date and evaluating data. The tool will
> be smart but will still have to make assumptions. Instead of being
> automatic, it will need some user input; otherwise, it will have to
> make assumptions about what the user is trying to do.
>
> QUESTION: What is the EPA\'s progress on the XML schema development?

Martin stated that the XML schema will be released in phases. There will
be a release at the end of March of the DRAFT Monitoring Plan XML schema
and a release in at the end of June of the remaining FINAL XML schema,
XML tags, and XML specifications.

**IV. ECMPS Certification and QA Test Process**

Travis Johnson presented a summary of the certification and quality
assurance process.

**A. Submission Process**

Travis noted advantages to the submission process with the Client Tool:

> ! The 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.
>
> QUESTION: What do you do if the linearity test is done on the last day
> of the quarter?
>
> QUESTION: What if you did not get the linearity test done, would the
> source still get a grace period?
>
> QUESTION: What about submitting conditional data (equivalent of RT
> 556) at the end of the quarter?

The source would have the choice to report the event either when the
event occurred or at the end of the quarter. The Client Tool will have
functionality to do it both ways. You will not have to do early quality
assurance or early event reporting, only before the emissions data since
the emissions data won\'t make sense if the most current quality
assurance data are not submitted first.

You can use the Client Tool to submit a change and then not have to
submit again at the end of the quarter. The objective is to get away
from having to submit quality assurance tests multiple times.

> QUESTION: Are we getting away from emailing out for certification
> application? Will it have to be emailed?

In the new process, once you submit a Certification Application through
the Client Tool, it will be effective for quality assurance data. There
will not be a separate email submission.

> CONCERN: Sources are really responsive to data submitted as a complete
> package. There is a legal responsibility to submit a complete package
> of data each quarter.

Part of the rule revisions, that will be discussed later in the meeting,
include providing flexibility for sources that want to submit their
monitoring plan changes and quality assurance test data when it is ready
to be submitted, rather than wait until the end of the quarter. Again,
this is not a requirement, but a feature of the new process. All of the
data may be submitted at one time during the submission period.

> **B. Evaluation Process**

Travis described the evaluation process with the Client Tool:

> ! The client tool will recalculate all test results and submit those
> results to the CAMD database.
>
> ! Only extension and exemption information that cannot 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.
>
> QUESTION: Will the Client Tool recalculate test results and submit
> EPA\'s data?

Travis responded that the tool will use RATA and Bias test data to
calculate data and inform the source if there is a discrepancy between
the recalculation and the calculated value. Although there is only one
way to do the calculation, there can be differences in the values.

> QUESTION: Will the results from the quality assurance test be used as
> the EPA\'s results?

Yes. The current system accepts what is being sent as long as it is
within a specified tolerance. The Client Tool inform the source what it
is calculating and give the user the option either to replace the value
with the recalculation or to reimport the data from the DAHS.

> QUESTION: Will CAMD share the tolerance checks and critical errors?

Martin replied that CAMD is developing a catalog of checks which is
close to being complete. The Monitoring Plan checks should be
catalogued, along with the type and level of severity of the checks by
the May 2nd stakeholder meeting. He noted that the majority of the
checks for the new Client Tool will be the same as existing checks.

> QUESTION: If you fail a check, will you be prevented from submitting?
> What are the fundamental requirements based on the regulations?

The Client Tool will check more efficiently and check things that we
can\'t check now. The checking that prevents submission of data will not
be different than it is now.

> CONCERN: Since checks are not always perfect the first time they are
> done, sources are looking for a way to get more involved with the
> check process. Will sources have the opportunity to participate in the
> check process?
>
> ISSUE: The next Stakeholder Meeting will be held on May 3, 2005. It
> was noted that there are three groups who have a conflict with this
> meeting. The Stakeholder Meeting was subsequently changed to May 2,
> 2005.
>
> QUESTION: What type of outreach is planned for non-members of EPRI?
>
> QUESTION: Will the tool manage nuances for ozone?

Travis responded that the tool will be able to account for ozone season.

**C. Tracking**

Travis discussed the tracking which will be available in the Client
Tool:

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

**V. Daily Quality Assurance Data Process**

> Mani Oliva presented the daily quality assurance 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.

**VI. Hourly Emissions Data**

Mani Oliva presented the hourly emissions data process. He noted that
redundant and unnecessary data and new data requirements were issues
with the hourly data.

As part of the effort to consolidate redundant hourly data, the
following have been proposed:

> ! Remove F‑factor from NO~x~ Rate data; add additional F‑factor fields
> to operational data.
>
> ! Consolidate load range information 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 NO~x~ and Heat Input methodology fields from NO~x~ Mass data
> and replace with flag for unmonitored bypass stack.

**VII. Technical Architecture**

David Ward of Perrin Quarles Associates, Inc. presented an overview of
the ECMPS technical architecture.

**A. Requirements**

The requirements for the ECMPS Client Tool include the following:

> ! 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.
>
> ! Synchronize data between the Client Tool and the CAMD database.
>
> ! Leverage existing reengineered data structures and processes.

**B. Configuration**

David discussed the Client Tool configuration which will include two
servers, a web server, and an Oracle database server.

The configuration will also include:

> ! Microsoft .NET (Client Tool, Business Logic, and Server‑Side
> Processes).
>
> ! MS SQL Server (Client Tool database).
>
> ! Oracle (CAMD database).
>
> ! Microsoft .NET (Web Services on CAMD Web Server).

For the Client database, the free version of Microsoft SQL Server will
be used. It has a limit of 4 GB of data. The complete Microsoft SQL
Server tool will be required for those systems which will exceed the 4
GB data limit. There will be two possible configurations: (1) a single
workstation or (2) workstation(s) and Database Server with MSDE Express
or MS SQL Server. David also described the minimum system requirements
for each of the possible configurations.

**C. Technical Concerns**

David briefly noted the following technical concerns with the Client
Tool:

> ! Processing Performance
>
> ! Data Retrieval Performance
>
> ! Version Control
>
> ! Data Synchronization
>
> ! Record Locking
>
> QUESTION: Please clarify how the Client Tool will alert the user if
> the Client data does not match what is on the Host system.

To answer this question, David provided an example of three agents who
are able to submit changes to Monitoring Plan and Emissions data. If
agent A changes the data at the EPA, then Agent B goes to submit, the
Client Tool will inform Agent B of any changes made by Agent A.

> QUESTION: How long does certification last?

CONCERN: What about CROMERR?

The Client Tool will have to meet the requirements of CROMERR.

> QUESTION: Since the Client Tool is unique to the user, is there
> anything that would have to be recovered if there were problems with
> the Client system?

EPA=s answer was No.

> QUESTION: Will security logs be maintained locally? If a change was
> made, will there be a log of by whom and when data were changed?

Yes, the log will identify the user id who made the change and the date
and time the change was made.

> QUESTION: Could the application use the same login as the Windows
> login?

CAMD does not anticipate that the Client Tool login will use the Windows
login since there will be occasions when the Windows login is not known.
The login must be authenticated through the CAMD business system.

> QUESTION: What are the financial implications with the data?

If you use a server side database client tool which will connect to SQL
Server data, you could put it on a separate server and potentially lock
out all other users.

> CONCERN: There was a concern about record locking and the fact that
> the Client Tool will have to notify you that data have changed and
> give you the opportunity to download in order to update your data. The
> download would have to provide a comparison between the Host and
> Client data and allow you to replace the data.
>
> QUESTION: How is the timeline for the Client Tool release affected by
> the release schedule for Microsoft SQL Server Express?

David responded that delays in the release of Microsoft SQL Server
should not impact the timeline for the ECMPS Client Tool.

> CONCERN: There was a concern how automatic updates to the Client Tool
> would be affected by company firewalls.

There will be two types of updates: (1) data updates which will require
you to login to the EPA and (2) software updates, which will allow you
to go directly to the FTP site and start installation rather than having
to login.

> CONCERN: You will need to get the latest version of the Client Tool
> before submission. It was noted that sources would rather not have
> updates take place during peak submission times.

Martin added that CAMD is looking at the best way to inform users of a
new version of the Client Tool. He also said that they will figure out
the best time to initiate new checks.

> CONCERN: There was a concern that releases and updates be coordinated
> so there is no conflict with the source\'s Information Technology
> department. Since many IT departments have been locking down updates,
> one or two updates a year should be okay; however, ten updates per
> year will not be acceptable.

Martin noted there will be cases where the source\'s Information
Technology department will have to go to the FTP site to make the
upgrade. CAMD will provide help with that and also minimize the number
of updates. They are also looking at trying to make it easier to
download, perhaps by putting the download on a site where the FTP
address is known (a public versus a private area).

QUESTION: What if a source does not have broadband?

Currently it is recommended that the user have high speed internet
service and likely that a 56 K modem will not work. There is an attempt
to fit 99% of the users. Exceptions are allowed. For example, 8% of the
files arrive through email because those sources cannot use SecuRemote.
Martin stated that specific concerns will be addressed individually.

David added that there have not been any benchmarks set on the data
using 56K modems but that there will be a lot of traffic back and forth
which probably precludes the use of the 56K modem. In any case,
SecuRemote will no longer be required.

QUESTION: Why is there an increase in data file size?

The XML is a large file, even with compression.

> CONCERN: With the regulations requiring new standards, which must be
> met above and beyond. Martin stated the goal is to have one
> authentication and certification for everything within the Federal
> Government. This does make the process more complicated.
>
> QUESTION: Will the tables for the Client Tool database be published?

The tool will not provide the capability to do queries but the tables
will be available to run queries on it.

QUESTION: Will there be the option to export errors.

David noted that there will be no interaction between the Client Tool
and other applications. Although the format has not been set, there will
be an error report.

> QUESTION: Can vendors tie into the Client Tool and have DAHS run
> checks?

This is not in the scope of the process. It would require customization
for each DAHS vendor. David commented that for error reporting, the
errors will go into a table but an interface will not be provided. The
process will not change, you will still have to bring the file into the
tool.

> QUESTION: We want the Client Tool to monitor a directory and process
> any file that shows up there.

This is also not in the scope.

**VIII. New File Format**

Martin discussed the limitations of the EDR ASCII 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.

He described the advantages to the 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.

He also compared the two formats directly.

  ----------------------------------- -----------------------------------
  **ASCII Text Format**               **XML File Format**

  Strict file construction            Flexible file construction

  Record Types                        Programming tags

  Column lengths                      Data fits between tags

  Reserved fields                     No reserved fields

  Based on pollutant                  Based on date and hour
  ----------------------------------- -----------------------------------

> QUESTION: Will there be changes to the precision on data types with
> rounding problems? Could changes be implemented now.

Martin responded that there is no plan to change the precision currently
specified in the EDRs.

QUESTION: Are you soliciting comments about the precision?

Martin stated that they are happy to take suggestions and he will
attempt to address concerns but it is not guaranteed.

**IX. Client Tool**

Martin described the benefits of the new Client Tool which will create
one application to check, store, maintain and submit data. It will
replace ETS‑FTP, ETS Mainframe, MDC Hourly, MDC‑QR, MDC‑FTP and
incorporate new and some existing functionality. The tool will also
interact with CAMD Business System.

Functionality of the new tool will include:

> ! 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.
>
> ! 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.
>
> CONCERN: Big utilities have seemingly unlimited resources, the concern
> is that the burden will be placed on those with no resources. If the
> timeline is short, these smaller sources will be dependent on vendors
> to help them make the transition.
>
> CONCERN: There are concerns about meeting the timeline based on what
> is being said about the conversion to XML format. In addition to being
> ready with new software, it will be difficult for DAHS vendors to
> implement the changes in so many locations in a short time.

Martin emphasized that if there are truly issues with the timeline, then
CAMD will need their help to shift the timeline. CAMD will need
documentation to support a timeline change.

> QUESTION: Will the process of submitting a revised Monitoring Plan be
> the same as it is for emissions or will it be more like using the CAMD
> Business System (CBS)?

The process will be the same as it for submitting emissions data.

**X. Rule Changes**

> Matt discussed proposed rule changes:
>
> ! 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.

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.

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).
>
> ISSUE: You mentioned a new field in the span record (for dual range
> analyzers) to identify the value at which the DAHS switches from using
> the low scale to using the high scale. Note that there is another
> transition point at which the DAHS switches from using the high scale
> to the low scale.

**XI. Development Timeline**

> Martin described the proposed timeline for the Client Tool.

  ----------------------------------- -----------------------------------
  **Timeframe**                       **Action**

  2004 - 2005                         Development

  2006                                Beta Test

                                      Usability

  2007                                Implement New Process
  ----------------------------------- -----------------------------------

The XML schema will be out by June 2004. Beta testing will begin in
2006. The plan is to allow a full year for Beta Testing.

> CONCERN: A DAHS vendor commented that a June release of the XML schema
> would be the latest possible date to allow vendors to develop new
> software. Even that may be problematic because of the budget cycles
> for both vendors and sources.

Janice noted that it takes a great deal to change the timeline. CAMD
operates on a two year budget cycle. There has already been a full year
delay. She will need something in writing to take back to the Office of
Management and Budget stating that sources cannot meet the milestones.

> CONCERN: Sources will need a flat file to XML conversion in order to
> meet the timeline.

Matt responded that there are changes to the system which the current
EDR can\'t support, so it would not be possible to convert a current EDR
file to create a complete XML file.

> ISSUE: Will beta testers have to submit files both through the new
> beta process and through the existing beta process?

CAMD is looking into whether accepting beta submissions as the\"real\"
data could be practically and legally done.

> CONCERN: There is a concern about the impact on the timeline if
> milestones were not met.

Matt added that if the milestones are not met, then we will have to
figure out how to proceed but that CAMD has to work within the stated
timeline and goals. Martin mentioned that if there are concerns about
the timeline, CAMD needs something in writing from the sources.

> QUESTION: What formal documentation is needed by CAMD from sources?

A letter or email should be addressed to Janice Wagner or Paula Branch.
This documentation needs to be mailed fairly soon since the submittal
process is due in July 2005. It would need to be received in the next
few weeks. Janice and Martin do not have the authority to extend the
deadline.

> QUESTION: For previous major EDR format changes, CAMD supported a
> year-long transition period which the new format was optional. Could
> this approach be used for ECMPS.

The year of testing is supposed to serve as the period of transition.
Laurie suggested that CAMD will look into a transition period.

[Rule Change Timeline]{.underline}

Propose Rule Change November 2005

Publish Rule Change 2006

Effective 2007

> QUESTION: What about pending regulations? If the mercury program is
> implemented, will the new data be included in the same quarterly file

Yes, all the data will be incorporated into the same file. This will
place another burden on the reporting software. Reporting requirements
for mercury are still unknown.

> COMMENT: Perhaps it would make sense to implement in phases. For
> example, all coal-fired units could be required to meet the new
> requirements first.

**XII. Open Discussion**

Martin concluded the meeting with an open discussion. He emphasized that
comments should be sent to Janice Wagner or Paula Branch as soon as
possible and indicated this meeting would not be the only opportunity to
provide feedback.

> QUESTION: Is there a contact for questions related to Information
> Technology?

David Ward of PQA will be the contact for IT related questions. Martin
added that he would send contact email to the sources. He also stated
that he would post on the CAMD website the presentation materials and
handouts. He asked if sources who had responded with feedback if it was
okay to distribute their comments to the group.

The next meeting will be the CEM meeting in May in Savannah, Georgia.
There are plans to hold a follow-up in late summer/early fall and a
final meeting at the end of the year.

> QUESTION: What are the user acceptance criteria for the Client Tool?
> Will sources have input into the look and implementation of the tool?

Martin responded that CAMD will accept comments and suggestions and will
incorporate what is possible but the sources will not be getting into
the look and feel of the application.

> QUESTION: Will there be a demo version of the Client Tool so users can
> become accustomed to the new tool?
>
> There will be a period when sources can use it and still use the old
> application (beta testing).
>
> QUESTION: How many hours of quarterly data will the Client Tool
> accept?

The size limit of the free version of Microsoft SQL Server is 4 GB of
data. The answer will depend on the checks, units, etc.

> QUESTION: What will the EPA receive to indicate that all checks have
> been performed?

Checking results will come with the data submission.

> QUESTION: There are currently raw files for the quarterly reports,
> will this still be available through the Client Tool?

The Data and Maps website will provide historical data.

> QUESTION: What about test companies that provide test data to their
> clients in EDR format. Will they now have to produce XML?
>
> QUESTION: Currently there is the capability to download of the EDR as
> a part of customer support. Will there be the ability to pull other
> customer\'s data?

This functionality will also be accessible through Data and Maps which
will be available to the public almost immediately, much sooner than the
current process where sources have to wait days/weeks for the posted
EDR. You will have the ability to download from the website to a CSV
file. EPA will consider providing that data in XML format also.

**XIII. Follow-up**

Martin thanked the sources for their time and restated that the
presentation materials and handouts will be available next week.

March 21, 2005

**Attachment A**

**ECMPS Project Stakeholder Meeting**

**Room 1153**

**EPA East Building, Washington, DC**

**February 17, 2005**

**9:00 a.m. to 5:00 p.m.**

**AGENDA**

**[Agenda Item]{.underline}** **[Time]{.underline}**

1\. Introduction 9:00 - 9:10 a.m.

2\. Meeting Objective 9:10 - 9:15 a.m.

3\. Overview of ECMPS process 9:15 - 9:20 a.m.

4\. Submission Process Changes 9:20 - 10:30 a.m.

> ! Monitoring Plan changes
>
> ! Initial certification and recertification changes

***Break*** 10:30 - 10:45 a.m.

Submission Process (cont'd) 10:45 -- 12:00 p.m.

Submission Process Changes (cont\'d)

! Daily Quality Assurance data process

> ! Hourly emissions data

***Lunch*** 12:00 - 1:15 p.m.

5\. Technical Architecture 1:15 - 2:00 p.m.

6\. New File Format and Client Tool 2:00 - 2:45 p.m.

***Break*** 2:45 - 3:00 p.m.

7\. Rule Changes and Project Time Line 3:00 - 3:45 p.m.

8\. Open Forum for Discussion and Recommendations 3:45 - 4:45 p.m.

9\. Action Items and Follow-up 4:45 - 5:00 p.m.

**APPENDIX B**

**List of Meeting Attendees**

> **[First Name]{.underline} [Last Name]{.underline}
> [Company]{.underline}**
>
> John Arnold MSI/Mechanical Systems, Inc.
>
> Tim Aucion UNC Cogeneration Systems
>
> Paul Baiotto CiSCO
>
> Malcolm Barnes Tennessee Valley Authority (TVA)
>
> Kevin Batchelder CiSCO
>
> James Batug PPL Generation, LLC
>
> Luke Beachler Reliant Energy
>
> Dan Beardsley NRG Norwalk Harbor
>
> Philip Betts Alabama Power Company
>
> Mike Bilello Oglethorpe Power Corporation
>
> Brent Bodine AES Greenidge, LLC
>
> Craig Bressan Duke Energy
>
> Greer Briggs Tampa Electric Company
>
> Mark Briggs Panda Brandywine L.P.
>
> Ken Burg South Bay Power Plant
>
> Matt Caldwell VIM Technologies, Inc.
>
> Tom Carlyle Cinergy
>
> Orlando Cartagena NRG
>
> Wayne Cartwright Cartwright Associates
>
> Tony Catanese Reliant Energy
>
> Tad Chenet Entergy Services, Inc.
>
> Suzanne Clevenger Allegheny Energy
>
> Thomas Cornelius Alabama Power Company
>
> Stania Cortright PSEG Fossil
>
> Christine DiGregorio FPL Energy
>
> Stewart Dover Lafayette Utilities System
>
> John Downs Oklahoma Gas & Electric
>
> Mike Escarcega Reliant Energy
>
> Deanna Estrada American Electric Power
>
> Tim Evans FirstEnergy
>
> Ray Fain Environmental Systems Corporation
>
> Tracy Faix Dominion
>
> Lynn Farley UNC Cogeneration Systems
>
> Lauren Freeman Hunton & Williams
>
> Janice Fry The Ohio State University
>
> John Gilmer Teledyne Monitor Labs, Inc.
>
> Phil Glisson Georgia Power
>
> Sean Gregory Epsilon Associates
>
> Aida Guloy Calpine Midwest Region
>
> Scott Harrison Teledyne Monitor Labs, Inc.
>
> Shawn Hussong Oklahoma Gas & Electric
>
> Chris Jacobsen Tenaska, Inc.
>
> Deanna Johnson Alliant Energy
>
> Jon Konings We Energies
>
> Ronald Kremann Lakeland Electric
>
> David Langseder Conectiv Energy
>
> Scott Lawton NRG Somerset Operations
>
> Katie Lindblom GE Energy
>
> Darrell Long Honeywell XCEED
>
> Monica Lopes North American Energy Services
>
> Cynde Luthran GE Energy
>
> **[First Name]{.underline} [Last Name]{.underline}
> [Company]{.underline}**
>
> Richard Marshall Spectrum Systems Inc.
>
> Rick McIlwain VIM Technologies, Inc.
>
> Ann McIver Citizens Thermal Energy
>
> Steve McLain Panda Brandywine L.P.
>
> Kim Mireles TXU
>
> Ed Much Constellation Energy
>
> Rudolf Muenster VIM Technologies, Inc.
>
> David Naegele American Electric Power
>
> Chris Nikitopoulos Keyspan Energy
>
> Stephen Norfleet RMB
>
> Laurie Pence Tampa Electric Company
>
> Brian Pleuss Alcoa - Warrick Power Plant
>
> Anthony Pocengal Dominion
>
> Leo Quinn Public Service Company of New Hampshire
>
> Matt Radigan VIM Technologies, Inc.
>
> Cameron Ritchie Duke Power Co.
>
> David Ruger Honeywell XCEED
>
> Chuck Ryan Air Quality Services, LLC
>
> Rick Savoie Consumers Energy Company
>
> Kimberly Scarborough Exelon Generation Company, LLC
>
> Steve Schmitt Air Quality Services, LLC
>
> Kevin Schuette Ameren Services
>
> Mike Scott Tennessee Valley Authority (TVA)
>
> Rod Seagle Salt River Project
>
> Orvella Shipman Alliant Energy
>
> Kevin Shumaker Reliant Energy
>
> Mike Siefert City of Vero Beach
>
> Blanton Smith Reliant Energy
>
> David Smith Old Dominion Electric Cooperative
>
> Steven Smokey Great River Energy
>
> Robert Spooner NRG Middletown Operations
>
> Dana Stephens Tri-State Generation and Transmission
>
> Jim Stevens City of Vero Beach
>
> Donna Thrasher Citizens Thermal Energy
>
> Michael Waslin Merck & Co.
>
> Wendell Watson Dynegy Midwest Generation, Inc.
>
> Bill Wemhoff National Rural Electric Cooperative Association
>
> Ted Wenning Tampa Electric Company
>
> Ed Wentling GE Energy
>
> Heidi Whidden Calpine Corporation
>
> Cindy Whitaker Environmental Systems Corporation
>
> Wayne Whitehead Cottonwood Energy
>
> David Williams Calpine Corporation
>
> Scott Wilson NRG Norwalk Harbor
>
> Melissa Wise Alabama Electric Cooperative, Inc.
>
> Randy Wooten Duke Power Co.
>
> Kevin Worley Xcel Energy