ECMPS Support

A number of emissions submission remain to be received for the 2008Q4 submission period. If you are trying to submit your 2008Q4 emissions data today, you have qualified as an Eleventh Hour Submitter. No matter. Here are some tips to help you try to get that emissions data in before midnight.

1. Submit What you Can: Unlike ETS-FTP, you can submit your data in parts. If you have the monitoring plan evaluating without critical errors, go ahead and get the monitoring plan data submitted to the EPA Host System. There is no reason to wait until all of your other data are ready to submit before you do any of the submissions. (The same goes for your QA tests. If they are ready to submit, go ahead and get them submitted.)


2. Use All of the Resources Available: If you submit a technical support request today, it is unlikely that it will get answered today. You should go ahead and send in the request for technical support, but your expectation should be that it will not be addressed until after today. There are a number of other people who are ahead of you in line and priority will go to them simply because they got in ahead of you. What can you do? Use all of the resources on the ECMPS Support Web site. These include, but are not limited to:
   
   
   
   • Known Issues
   • ECMPS Support Blog
   • ECMPS Tutorials
   • Frequently Asked Questions
   • Reporting Instructions


3. Do Not Stress Over Errors Which Do Not Prevent Submission: Obviously, the goal is to submit the emissions data without critical errors. However, the only errors which prevent you from submitting your data without critical errors are critical level one errors. Critical level two, non-critical, and informational errors do not prevent you from submitting without critical errors. If you do not have critical level one errors, you are ready to submit. The other errors and informational messages can be dealt with later.


4. Submit with Critical Errors: If you cannot get an evaluation without critical level one errors, use the submit with critical errors option in the Submit Module. Your data will be submitted to the EPA Host System, and you will meet the regulatory deadline for submission. However, you will need to address the evaluation errors and submit without critical errors as soon as possible after the submission period. Data submitted with critical errors are not added to the official EPA Host System database. The data submitted with critical errors are stored simply as XML files.


5. Communicate With The EPA: If you are running into particular technical problems, let your EPA Analyst(s) know by sending them an email or calling them.


6. Email Your XML Files: If you not able to even import your data into the Client Tool, you can email your data to Laurie DeSantis. Note, this is a worst case scenario. This will meet the regulatory deadline, but you will be required to submit data without critical errors as soon as possible after the submission period.Also, if you zip up your files, be sure to rename the file extension to something that is not ".ZIP". Attachments with that extension are not delivered by the EPA mail server for security reasons. So change the extension to something like ".ZTP" in order to have your attachments sent.

Recently, there have been a number of questions about year-to-date (YTD) summary values. These are the data which are reported in Year to Date Total in the Summary Value Data section of the emissions data XML.

The question which is being asked is what to do in the event that the reported Year To Date Total does not match the EPA value calculated during the emissions evaluation. If it is discovered that the problem is that earlier report summary value data were incorrect, there may be a fairly simple solution.

First, some background information is in order. For each quarter, sources are to submit Current Reporting Period Total and Year to Date Total data for every relevant parameter. These are both in the Summary Value Data part of the emissions data XML. During the emissions evaluation, the Client Tool calculates the EPA calculated value for both of these data based on the reported hourly data. If the reported Current Reporting Period Total and Year to Date Total are within the acceptable tolerance of the calculated values, the emissions data pass the evaluation checks related to summary values and are permitted to be submitted to the EPA Host System. (The tolerances can be viewed in the Cross Checks Table document which can be accessed from here.)

The reported values which are submitted to the EPA Host System become the EPA accepted values. Subsequent quarters will use these EPA accepted values for checking the reported Year to Date values. These EPA accepted values can be viewed in the Emission Summary Report in the Emissions module of the Client Tool.

Now back to the questions which some sources are asking. In some cases sources are finding that they may have been incorrectly calculating quarterly and YTD summary values throughout the previous quarters in the year. When they get to 2008Q4, the YTD summary value that EPA calculates through the Client Tool is different enough from the reported value that an evaluation error is given.

The solution could be to resubmit previous quarters with the corrected summary value data. However, that may not be necessary. Instead, sources can simply modify the 2008Q4 emissions data to report the correct YTD value. What is the correct YTD value to report? It would be summing up all of the EPA accepted summary values from previous quarters in the year and adding the reported 2008Q4 summary value.

Ideally, this could be done through the DAHS. Practically, it may require editing the emissions XML file by hand. Sources should work with their DAHS vendor to determine the best way to do this.

Now, if it turns out that problem was not simply a rounding issue or small deviations from the tolerance in each quarter then it may be necessary for a source to resubmit previous quarters' emissions data. Any questions about this should be directed to technical support.

As providers of technical support for ECMPS, we know that stakeholders are working hard to submit their data through the Client Tool to the EPA Host System. As of this morning, a little under 50% of the expected emissions files which are expected to be submitted for this reporting period have been received. (You can can see the current percentage of emissions files submitted on the ECMPS Support Web site home page.) That means that approximately 900 emissions files will need to be submitted in the next week.

Although most of the sources currently are working to resolve problems and get the data submitted, experience has shown that some stakeholders procrastinate and wait until the eleventh hour to try to finish the job. In order to encourage stakeholders to submit data earlier rather than later, CAMD will be sending out automatically-generated emails to sources who have yet to submit their emissions data for the current, and in some cases, the preceding reporting period. In this first month of sending these reminder emails, the emails will be sent today and then again early on Monday, January 26th. The emails will be sent to representatives and agents who have responsibility for submitting emissions data.

For those of you who are already working to get your data in before the January 30th deadline, you do not need a reminder. For everyone else, the reminder is for you in order that you do not wait until the last minute. The longer you wait to get started, the more likely you might have trouble getting your technical support questions answered very quickly because the technical support question queue could be quite long on the last few days of the reporting period.

The EPA Host System will not be available on Saturday, January 24, 2009 from 8:00 AM until 5:00 PM EST. The EPA Host System downtime is part of an EPA-wide scheduled maintenance outage.

Labels: Scheduled Outage

In the previous Brief History Lesson, there was a discussion on Test History. Test History relates to QA and certification data. In part 2 of the Brief History Lesson, we will talk about emissions data history.

Similar to test data, all of the emissions data are not synchronized to the Client Tool during either the initial synchronization which takes place at the end of the installation or any subsequent synchronizations which occur when you log in to the EPA Host System. Instead, similar to test data, the essential emissions data necessary for performing evaluations are synced to the Client Tool. These data have various names including operating supplemental data, but the data can be considered the emissions summary history data because the data are a history of the emissions summary data.

The data which are part of the emissions summary history data include:

• Number of operating hours
• Number of operating days
• Operating time
• Heat Input
• SO2 mass
• CO2 mass
• NOx rate
• NOx mass

When the data are moved from the legacy system to ECMPS, the emissions summary history data are moved over from every quarter from 2003 to the present. In addition, the yearly totals for these data are loaded in ECMPS (or ozone season totals for ozone season reporters).

During the initial synchronization of data which takes place at the end of the installation, all of that emissions summary history data are synced from the EPA Host System to the Client Tool database. These data can be viewed in the Emissions Summary Report which is one of the reports in the Emissions Data module in the Client Tool.


The emissions summary history data are updated for new quarters after the data have been submitted to the EPA Host System. That is because the emissions summary history data are considered the EPA accepted values. When year-to-date values are calculated during an emissions evaluation, the Client Tool uses these EPA accepted values from previous quarters to calculate a year-to-date value which is compared to the reported year-to-date value.

Most people do not get excited when the words "Test" and "History" are mentioned in the same sentence. It may conjure up images of sweating through a world history test in high school as you struggled to remember some obscure date that you "memorized" ten minutes before class began.

In ECMPS, the words "Test" and "History" should not cause any anxiety. Instead, they should remind you that the Client Tool is designed as an evaluation and submission tool. To function efficiently, the Client Tool tries to keep to a minimum the necessary data which are used to perform evaluations and to submit data. That is where Test History comes into the picture.

Test history is exactly that. It is a history of the QA tests associated with a particular monitoring plan configuration. The data in the test history report are either data submitted through the legacy systems, data submitted through ECMPS, or data which need to submit the data. The test history for any configuration can be viewed in the Test History report which is found in the QA and Certification Data module of the Client Tool.

When you view that report, you will notice that the Test History Report only includes a relatively small portion of the data which are part of a test. For instance, for a linearity test, each of the individual injection records is not included in the report. Instead, the test history only includes the essential information which the Client Tool needs for performing evaluations. The figure below shows an example of the information included in the test history report.


The test history information included for this linearity test include:

• Monitoring location (unit, stack, or pipe)
• Test number
• Component ID
• Component type
• Begin date and hour
• End date and hour
• Span scale
• Reason for the test
• Test result

The last column is the Submission Availability Code (SAC) which is not part of reported data, but indicates the status of the data. If the SAC is "Submitted to EPA Host System", the test has already been submitted to the EPA, and it cannot be submitted again unless permission is granted to resubmit. In the case where permission has been granted to resubmit, the SAC would be "Resubmission Required" or "Permission to Resubmit Granted".

The test history is actually generated when the test is evaluated in the Client Tool. That is why you can view the test history of a test which has yet to be submitted. In that case, the SAC would be blank. Once the test has been submitted, the SAC would change to "Submitted to EPA Host System".

The Cross-Media Electronic Reporting Regulation (CROMERR) is the regulation which stipulates how electronic reporting must be performed for entities which report data to the EPA. Affected entities include regulated entities which must data the EPA for regulatory purposes. This means that CROMERR affects ECMPS stakeholders.

Beginning in March, ECMPS stakeholders will be affected by CROMERR in their use of both the CAMD Business System (CBS) and the ECMPS Client Tool. ECMPS stakeholders will be affected in their used of CBS because several parts of CBS will be redesigned to comply with CROMERR. Regarding the Client Tool, CROMERR will affect the use of the Client Tool in two ways:

1. Beginning with the next release of the Client Tool (scheduled for March 17th), users must have completed a Subscriber Agreement in order to be able to log in to the EPA Host System.


2. In order to be able to submit data through the Client Tool, users must have selected five challenge questions and provided the answers to those challenge questions.
   
   During the submission of data, users will be asked to answer a challenge question in order to verify their identity. The challenge question is similar to questions asked on banking Web sites or other secure Web sites. (E.g., What is your mother's maiden name? or In what city were you born?)

ECMPS Stakeholders need to take the following steps:

1. Complete a subscriber agreement and send it via mail to the EPA. The Subscriber Agreement Form can be downloaded from here. Simply print it out, read and sign the form, and send it to the address on the form.


2. After CBS is updated (scheduled for March 6th), stakeholders will need to log in to CBS and select challenge questions as well as provide answers for those questions.

Stakeholders should bear in mind that once CROMERR is implemented in March, they will not be able to use CBS or submit data through the Client Tool until they have submitted a subscriber agreement and selected challenge questions.

For more information about CROMERR, click here.

Any questions about CROMERR and completing the Subscriber Agreement Form should be directed to Karen VanSickle at EPA (vansickle.karen@epa.gov).

Labels: CROMERR

The latest installment in the library of tutorials is actually an update of a tutorial that has been out for some time.

The Evaluate tutorial is now available with updates to reflect the ECMPS Client Tool interface changes which were made to the Evaluate module in version 3 of the Client Tool.

The tutorial provides the same basic foundation which it previously did. The purpose of the tutorial is to explain how to evaluate your data prior to submitting it to the EPA.

This tutorial, like all of the others, is an interactive, audiovisual presentation which can be viewed in an Internet browser. Also, like the other tutorials, it is designed to provide practical instruction in a format which can be viewed in 10 minutes or less.

To see the complete list of ECMPS tutorials, click here.

Labels: Tutorial

The CTP Registration period ended on January 2, 2009. However, that does not mean the CTP has ended. Instead, the CTP is still around to assist ECMPS stakeholders in making the transition from the legacy systems (MDC and ETS-FTP) to ECMPS. Anyone who registered for the CTP before the deadline can continue to use the CTP both online and offline. In other words, the Test EPA Host System will continue to be available for CTP users.

Similarly, if you have registered to use the CTP, but you have yet to download and install the CTP, you can still do so by accessing the download pages on the ECMPS Support Web site. The current version of the CTP is version 4 which is identical in its functionality to the current production version of the Client Tool. The only difference between the production version and the CTP is that the CTP only works with test data and the Test EPA Host System.

The plans are for the CTP and CTP support to continue to be available until March 1, 2009. Shortly after that, the next version of the Client Tool for production will be released and all sources who have yet to switch to ECMPS for official data submissions will be able to make the transition at that point.

Labels: Industry Testing

It has been called to our attention that the EPA telephone number which is listed on the "About ECMPS Client Tool" screen available from the Help menu in the Client Tool is incorrect. Please do not call this telephone number because it reaches an individual EPA employee rather than a technical support telephone number.

For Technical Support contact information click here.

One of the more frequently asked questions we receive at ECMPS Support is related to retrieving data. Specifically, users ask questions that in some way are related to the Retrieve module in the Client Tool.

This post is made in an effort to clear up some of the confusion about the Retrieve Module. The most important thing to take away from this post is that you most likely should never need to use the Retrieve Module.

Let's cover some basics about the Retrieve Module. The Retrieve Module is used to retrieve data from the EPA Host System to the local Client Tool database. All of the data which are retrieved are official data which have been submitted to the EPA through the legacy systems (MDC and ETS-FTP) or through the ECMPS Client Tool. The Retrieve Module interface allows users to select whether to retrieve monitoring plan, QA, or emissions data.

The most fundamental thing to remember about the Retrieve Module is that it should very rarely be used. It is available when absolutely necessary, but that will not be very often. In fact, most users may never need to use the Retrieve Module.

There are three primary reasons for NOT retrieving data.

1. All of the historical data which you need for evaluating and submitting new data is already in the Client Tool. After you complete the initial synchronization which occurs at the end of the installation, your Client Tool database will contain all of the data which you need to begin submitting data. After that point, the Client Tool will keep you up-to-date with any data you need through the synchronizations that take place during logging in to the EPA Host System.


2. If you retrieve historical data, you will have to evaluate that data which may result in evaluation errors. There are a variety of reasons for these evaluation errors including new requirements or stricter tolerances. However, because these data have already been submitted to the EPA, it is not necessary to evaluate the previously submitted data. In other words, the moment you retrieve historical data, you are making it subject to the current set of evaluation checks, which unless you need to do for resubmission purposes, is most likely going to result in frustration and unnecessary work.


3. Retrieving data which you do not need will simply fill up your database with unnecessary data. As your database fills up, you may notice a decrease in performance.

Is there ever a reason to retrieve data? The most likely reason that a user would retrieve data is for purposes of resubmission. For example, if some piece of data was not correctly reported for a historical QA test, the test could be retrieved, the data corrected, and the test resubmitted to the EPA Host System. (Note that resubmission for QA test data requires permission from the EPA.)

The bottom line is that the vast majority of users should NOT be using the Retrieve Module.