Air Emissions Compliance Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does turning the permit into limit records get underestimated?

Almost every quote in this category prices the calculation engine and treats the permit as an input someone will provide. The permit is not an input. It is a document of hundreds of pages that says, for this heater, this limit applies, over this averaging period, by this method, using this monitoring, with these exemptions, reported this way, and the methods vary wildly across units in the same plant.

One unit is governed by a continuous emission monitor with data availability and substitution rules. Another uses parametric monitoring, where compliance is demonstrated by holding process parameters inside an envelope established during a stack test. Another uses published emission factors against throughput. Storage tanks use their own estimation routines. Flares are evaluated on short blocks. Leak detection and repair runs its own monitoring frequencies and repair clocks.

Turning that into structured limit records is environmental engineering work, not development work. Expect three to six weeks of your own engineers reading the permit line by line alongside the developer on a large site. It is the least glamorous part of the project and consistently the most valuable, because it routinely surfaces limits nobody was actively tracking. Sites that shortcut it end up with a system that monitors what somebody remembered in a workshop, which is exactly the failure mode they were trying to leave behind.

What goes wrong with historian data and tag mapping?

The data is excellent. That is what makes this category deceptive. AVEVA PI, Honeywell PHD, Aspen IP.21 and Wonderware hold second by second history, and the problem was never availability. It is that each calculation input has to name a specific tag, with a unit conversion, an expected range, and a defined rule for what happens when the tag is bad or missing.

Tag mapping done casually is the single biggest source of wrong numbers here. Tags get renamed during control system upgrades. An instrument is replaced and the new one writes to a different point. A tag that reported in one unit of measure starts reporting in another after a configuration change. None of that raises an error, because a missing value is not an error to arithmetic that treats it as absent.

What works: treat every tag mapping as a declared contract with an expected range and an explicit bad quality rule, then monitor the contract rather than the calculation. A tag that stops delivering, delivers outside its range, or delivers a suspiciously constant value should raise an exception on its own, before it reaches a limit evaluation. And make the default fail loud rather than fail quiet. A calculation missing an input should mark the period as indeterminate and raise it, never return zero. Sites that get this right find integration breaks in a day. Sites that do not find them in the semiannual report.

Why do the historian and control network integrations break after launch?

Reading process data is not a database connection. The historian usually sits inside a segmented control network, and moving data across that boundary is governed by your cyber security rules for good reason. That constraint is legitimate and it shapes the architecture, so a developer who assumed a direct connection discovers it in week nine and rebuilds the data path.

After launch, the breaks come from the plant side rather than the software side. A control system upgrade renames points. A distributed control system migration changes the historian's interface. Network segmentation rules tighten after a security review and the data diode or replication path needs revisiting. Historian values are also corrected retrospectively, which is normal and correct, and a monitor can be invalidated weeks later after a failed relative accuracy test audit.

Two practices carry the site through. First, design for one way data movement out of the control network from the beginning, agreed with your controls and security engineers before any code, so the architecture does not need to change when someone finally asks. Second, treat retrospective correction as a first class event rather than an exception: when a value inside a rolling window changes, every affected evaluation recomputes and the change is logged with before and after, rather than being overwritten. Systems that cannot recompute backwards are the ones that quietly disagree with the historian a year later.

What happens when exemptions and monitor quality assurance are not modelled?

This is the gap that kills adoption rather than compliance, and adoption failure is worse because it leaves you with no system and a paid invoice.

Permits contain exemptions, including for startup, shutdown and malfunction periods in many cases, and if those are not modelled explicitly as part of the evaluation record then the deviation list fills with events that were never deviations. Unit engineers investigate the first few, find nothing, and stop opening the alerts within about a month. From that point the system is generating noise while everyone relies on the spreadsheets it was meant to replace.

Monitor quality assurance is the second half of the same gap. Relative accuracy test audits, calibration checks, linearity checks and data availability all have schedules and consequences, and a missed or failed check can invalidate data that has already been consumed by rolling calculations. Systems that keep quality assurance on a separate calendar miss that dependency entirely, so invalidated data stays inside completed evaluations.

The fix on both counts is to make them part of the evaluation record. Every result should state whether an exemption applied and on what basis, and whether the monitoring underlying it was valid at the time. When a check fails, the affected evaluations are identified automatically and reworked, rather than depending on someone remembering which calculations used that monitor.

Should you build custom or configure what you already own?

If you hold a minor source permit with a handful of units and annual reporting, do not build. The calculation load fits a workbook and a calendar, and the engineering is not proportionate to your risk. We say so and lose the work.

If you are already standardised on Sphera, Intelex or Cority and using it for obligations, actions, audits and management systems, keep it. Those platforms do that job properly and replacing them adds cost without reducing exposure. Before assuming a build, take your two most awkward limits, the ones currently living in a workbook, to your vendor's implementation consultant and ask them to configure both in front of you. If they can, configure the rest and stop reading. If the answer is a services estimate, you have your answer about where the boundary sits.

The same applies in the other direction. If your actual problem is neighbours, odour, dust or noise rather than permit limits, Envirosuite is aimed at ambient monitoring and dispersion and is a serious option there. It is not a permit limit compliance engine, and buying it to solve a Title V calculation problem is a category error.

The realistic build is narrow: own the calculation and deviation engine, feed your existing suite for action management. That is a much smaller project than a replacement and it targets the part that fails.

How do hidden costs get into an emissions software quote?

Five places, and an experienced developer raises them before you ask.

• Distinct calculation methods. Cost tracks methods, not units. Twenty identical heaters share one method. Six units with six different demonstration approaches is the expensive case, and quotes priced on unit count get this backwards.
• Control network architecture. Crossing a segmented boundary under your own security rules is design work, and it is cheaper agreed up front than retrofitted.
• Leak detection and repair. Effectively a separate field application with its own monitoring frequencies, repair clocks and record keeping. Scope it explicitly or leave it out of phase one.
• Multiple sites. Each permit is a fresh limit register with fresh engineering time. Two sites is not one site with a filter.
• Consent decree obligations. Bespoke by nature and rarely expressible as a variation of a standard limit, so they need their own scoping conversation.

What keeps the number down is choosing the twenty or thirty limits where a deviation would actually hurt, usually concentrated in a handful of units, and proving the engine and historian integration there before extending.

What separates an emissions build that works from one that fails?

Working systems are transparent rather than clever. Every evaluated value is reproducible on screen: here is the limit and its version, here is the averaging window, here are the input values used, here is the arithmetic, here is whether an exemption applied. When an inspector asks how a number was derived, you show the record rather than describing a methodology. That property is also what lets an engineer trust an alert, and trust is what determines whether the system is used in month three.

Working systems version everything by effective date. Permits are renewed, modified and amended, and a limit that changed on renewal must not retroactively rewrite whether you complied last year. Every evaluation records which limit version it ran against.

Failing systems usually got the engine right and the alerting wrong. They fired on approach thresholds nobody had calibrated, sent them to a distribution list rather than a named unit engineer, and produced enough false positives in the first fortnight that the site stopped reading them. Set approach warnings deliberately, route each one to the person who can act on it, and review the alert list weekly with the environmental team for the first quarter, tuning as you go. A deviation engine nobody opens is more dangerous than no engine at all, because it creates a record showing you were told.