The ECMPS Client Tool Preview (CTP) testing session is in full swing. Each week more stakeholders are signing up to begin working with test copies of their data in order to prepare for the eventual transition to ECMPS. Along with the testing, we continue to receive a steady stream of technical support questions. Here are a couple of those questions from the mailbag.

Missing Old Probe Information

Question
If we changed out our probes, discarded the old ones, and do not have any data related to the old probes, how will get past the errors that state the probe data does not cover the entire evaluation period?

Answer
The only way to clear the error is to have an active probe component defined for the entire period that the monitoring system has been in use since January 1st of 2003. To define a valid probe component all you need is a Component ID, Manufacturer Name, and Serial Number. The purpose of having the manufacturer and serial number information is so that electronically represented components can be identified in the field. It would be much better if you can find the information, but if the probe components are not longer in use it, is less important to have the actual data.

I would suggest adding the old probes with a manufacturer and serial number of "Unknown". Then add the the new probes with the known manufacturer and serial number information. The old probes should be ended on the correct date and hour in the system component record, and the new probes should be begin on the correct date and hour in the system component record.

For more information about adding a probe component, view the tutorial, "ECMPS Monitoring Plan Corrections, Part 2: Adding a Probe" on the Tutorials page.

QA/Cert Data Baseline

Question
Do I need to retrieve the QA/Cert data from the EPA Host System initially to have some "base line" of previously submitted data, or can I just start by adding the QA/Cert data from this quarter going forward?

Answer
During the initial synchronization, the ECMPS Client Tool retrieves what is termed Test History data. These data are the essential QA/Cert data which the Client Tool needs from all previously submitted QA/Cert data. The Test History data are a subset of all of the previously submitted QA/Cert data. The Client Tool needs these data in order to perform the data evaluations in the Client Tool which require data from previously submitted QA/Cert data. For example, the bias adjustment factor (BAF). You can view these data through the Test History Report which is found in the QA/Cert Module of the Client Tool. The data which are retrieved in the initial synchronization are all of the previously submitted QA/Cert data from 2003 to the present. Going forward the Test History data will automatically be in your Client Tool because it is generated in the Client Tool every time an evaluation is run on new QA/Cert data.

If you would like to view all of the details of the previously submitted tests, use the Retrieve module to retrieve all of the data (e.g. run data, summary data) for any of the QA/Cert data which have been previously submitted.

For more information about the initial synchronization, view the previous post on initial synchronization. (This post does not use the term Test History data because it had not been adopted at that time, but Test History data is part of supplementary data.)

Labels: Communication, Mailbag, Synchronization

Recently, a stakeholder asked the question of how to set up ECMPS to allow multiple users to work with the same data. He was concerned about how to limit the ability of users to submit data through ECMPS. A FAQ which addresses these questions was added to the General section.

How can I set up a system to allow multiple users to work with the same data?

There are two ways to set up a multiple user system for the ECMPS Client Tool. The first is to use a shared network local ECMPS database. Each user would connect to the shared network database through each user's copy of the Client Tool. Thus, any changes made by one user would automatically be available for any other user who connected to the same shared database. Through the CAMD Business System, users could be assigned rights that would allow them to retrieve, view, and edit the data, but would prevent them from submitting the data.

The second multiple user system utilizes ECMPS Client Tools with their own local ECMPS database. Each person who has been granted access to Unit X at Facility Y will be able to synchronize the data associated with Unit X at Facility Y through his copy of the Client Tool. In other words, everyone will synchronize through the EPA Host System. As in the first scenario, rights can be assigned that prevent submission of data but provide users the ability to do everything else. A business process scenario might look like this:

1. The user at the plant logs on to Client Tool which automatically synchronizes his local ECMPS database with any changes submitted from the corporate office.


2. The user at the plant imports in to his Client Tool the XML file to be reported. Then the user at the plant evaluates the newly imported data. This process is repeated until the data evaluates without any critical errors.


3. The user at the plant sends the XML file to the corporate office.


4. The user at the corporate office imports in to his Client Tool the XML file and evaluates it. After verifying that the data does not have any critical errors, the data is submitted to EPA through the Client Tool.


5. The next time the user at the plant logs on to the Client Tool, the data that was submitted will be automatically retrieved from the EPA Host System and added to his Client Tool database.

In this scenario, the user at the plant would not have rights to submit the data, but he could retrieve and synchronize any data to which he has been assigned access rights through the CAMD Business System.

Labels: Database, FAQ, Synchronization

Through Beta testing, we have found another known issue related to evaluation checks. This issue is related to changes made to the Begin Date for a primary unit fuel record. The problem results in a monitoring plan evaluation error of MONLOC-104-A.

The following scenario produces the error. The Begin Date for a primary unit fuel record is changed, and the monitoring plan is submitted to the EPA Host System. The issue is that the EPA Host System does not correctly process the data by updating the Begin Date in the existing primary unit fuel record. Instead, it interprets the submitted data to be a new unit fuel record, and a new unit fuel record is added to the EPA Host System database. If another tester synchronizes data with the EPA Host System or the original tester retrieves the monitoring plan data through the Retrieve Module, an additional unit fuel record will be included in the data retrieved from the EPA Host System. A subsequent evaluation of the data will produce the evaluation error MONLOC-104-A which states, "You have defined overlapping primary fuel types for the current period for Unit ID [X]".

The problem is related to the processing of the data on the EPA Host System and not the evaluation check in the Client Tool. As soon as this has been corrected on the EPA Host System, a post will be added to the Blog to note the correction of this known issue.

Labels: Known Issues for Beta B, Known Issues for Beta B Checks, Synchronization

A number of Beta testers have requested more information on synchronization. And, some Beta testers have asked specifically about getting a copy of the presentation on synchronization which was made at the Stakeholder meeting on May 8, 2007 in Phoenix, AZ. The presentation is good place to start for understanding synchronization. If, after viewing the PowerPoint presentation, you still have questions, please contact us.

The presentation has been posted on the Web site. To get a copy, go the Documents page and click on the link "Presentation on Synchronization" under the Additional Documentation section or simply click here.

To view the presentation, you must have Microsoft PowerPoint.

Labels: Synchronization