How emissions are calculated
WS.PEMS is a predictive emission monitoring system (PEMS). It does not measure most emissions directly. It calculates them from process measurements, such as fuel flow, temperatures, pressures and load. This page explains the path from a raw measurement to a reported number, and why each step exists.
The path at a glance
Each emission source has a pipeline. A pipeline is an ordered list of steps. The product runs the pipeline of an emission source on its schedule, normally once per minute. Each run produces one first-level data record. That record holds the value and the quality of every tag of the emission source for that time step.
Reporting then aggregates the first-level data into averaging periods. Reporting periods and emission limits explains that part.
Data in
The first step of a pipeline is a data reader. It reads the current value of each configured tag from the plant connection. An asset pipeline can read the data for several emission sources together and then run their pipelines.
When the connection is lost and every tag returns no value, the product records a lost connection. If you turn on automatic recovery for the pipeline, the product starts a batch run for the missing period when the connection returns. The batch run reads the historical values for that period and runs the same steps again.
Validation
The product checks each value before it writes the value to the first-level data record. The tag configuration controls the check:
- A low limit and a high limit. A value outside these limits is out of range.
- A mean value. Some substitution modes use it as the default value.
- A mode for bad-quality values and a mode for out-of-range values.
The modes tell the product what to do with a bad or out-of-range value. It can use the last good value, use the default value, set the value to the nearest limit, or keep the value and mark it. When the product replaces a value, it gives the value the quality "substitute value used". It also writes a warning event to the pipeline run. Thus a substituted value never looks like a measured value.
A result that is not a finite number gets the quality "no value". This prevents a calculation error from appearing as a real zero.
The model
The model step calculates the emission values from the validated inputs. Each emission source has a model configuration. The configuration connects the inputs that the model needs to the tags of the emission source. An input can come from a measured tag, a fixed value or a formula.
The product supports these model types:
| Model type | How it calculates |
|---|---|
| First-principle | Physical equations for the equipment: mass and energy balances over components such as the compressor, combustor, turbine and stack. |
| Machine learning (ONNX) | A trained model that predicts the outputs from the inputs. |
| Custom | A calculation written for one equipment type or source category, for example an engine, a gas turbine or a flare. |
| Simple | A direct calculation without reconciliation. |
First-principle models and reconciliation
A first-principle model describes the equipment as components that streams of air, fuel and exhaust gas connect. Each component obeys mass and energy balances. The model calculates the unknown values, for example the exhaust flow and the emission mass flows, from the known values and these balances.
Measurements always contain some error. Thus the measured values do not close the balances exactly. Data reconciliation corrects this. When you mark inputs for reconciliation, a numerical solver adjusts those measured values within their uncertainty until the balances agree. The solver minimizes this combined error:
minimize: Σ (balance_error_i / stddev_i)² × weight_i
+ Σ (measured_adjustment_j / uncertainty_j)²
A measurement with a small uncertainty therefore moves less than a measurement with a large uncertainty. The pipeline can also run a gross error test. This test looks for a measurement that disagrees with the balances by more than its uncertainty can explain.
If no input is marked for reconciliation, the model calculates the outputs directly and does not run the solver.
When the equipment is stopped, the model sets the calculated emission outputs to zero. It does not run the solver for that minute.
Machine learning and custom models
A machine learning model uses a trained ONNX file. The product stores a hash of the file and the date from which the file is valid. A custom model is code for one equipment type or source category. Both model types read their inputs from the same validated first-level data as a first-principle model.
Uncertainty
A pipeline can include an uncertainty step after the model step. For each configured output tag, this step combines:
- the uncertainty of each model input, weighted by the sensitivity of the output to that input,
- the uncertainty from the active calibration,
- the measurement uncertainty.
The step writes the result to the first-level data next to the output value. The step runs only when the pipeline run saves its intermediate results to the database.
Reporting applies a second, separate uncertainty treatment. There, the validated short-term average subtracts a regulatory uncertainty from each hourly value. See VSTA, the validated value.
Model integrity tests
A model integrity test checks that a model still gives the expected result. The test sends a fixed input data set through the pipeline. It compares the actual outputs with the expected outputs. Each output has a relative tolerance and an absolute floor. The product records each run as passed, failed, error or skipped, with the reason for a failure.
Aggregation
Reporting does not use the per-minute values directly. A scheduled job calculates short-term averages (STA) from the first-level data, for example for each hour. It then calculates the standardized value (SSTA), the validated value (VSTA) and the long-term averages (LTA). Reports read these stored aggregates. Reporting periods and emission limits explains each level.
Reprocessing a period
A configuration change does not change the values that the product calculated before. To recalculate a period, start a batch run for the pipeline. A batch run recalculates the first-level data for the period. You can also tell it to start the STA aggregation for the same period when it completes successfully. The product records each batch run with its period and its status.