The Bay Area Air Quality Management District engaged IdeaBlade to build the Major Facilities Portal, a detailed emissions inventory for the largest stationary sources under the District’s jurisdiction: oil refineries and tank farms, cement plants, natural gas power stations and cogeneration facilities, and semiconductor fabrication plants.
The core of the system was the emission train — the District’s own term for a modeled process path. A train begins at a single device and connects onward to others; at each stage a pollutant is either emitted or passed along. Devices either produce or modify pollutants, or abate them. A facility comprises multiple trains and the same device often appears in more than one, so a facility is a connected graph of equipment rather than a set of independent chains.
IdeaBlade built these trains for each facility, tracing inputs — fuel oils, feedstocks, toxic chemicals — through every stage and calculating emissions at each from chemical engineering estimates of the processing work performed and the equipment involved, speciated across carbon dioxide, methane, nitrous oxide, hydrofluorocarbons and the other pollutants the District tracks. Every train yields an unabated figure and an abated figure for each pollutant. The result was a bottom-up inventory derived from the physics and chemistry of each facility’s operations rather than from the facility’s own reported totals.
The trains were editable, because facilities change: District engineers had to be able to restructure a facility’s model and see emissions recalculate against the revised train.
What we delivered
For each facility the application modeled the industrial process as an editable emission train, tracing inputs through each stage, calculating estimated emissions at every stage, and netting those estimates against the abatement devices along the train, some of which served more than one train. District engineers maintained the models directly as facilities replaced equipment and reconfigured trains.
IdeaBlade was responsible for architecture, UX and development, working alongside the District’s engineers, and performed all Azure deployments through the engagement. Requirements analysis was the District’s responsibility; QA was shared.
Technology
Angular and TypeScript on the client; ASP.NET and C# on the server; Breeze for data management; Microsoft SQL Server. Hosted on Microsoft Azure, with source control in GitHub. Emission train diagrams were rendered with vis.js, with the editing behavior over those diagrams — restructuring a train and recalculating against it — built as custom Angular components.
Complexity
Fewer than a dozen facilities were in scope, but modeling depth is the relevant measure: a large refinery carried as many as 100 emission trains, each five to ten devices deep — several hundred to roughly a thousand modeled device stages inside a single facility, each with its own inputs, equipment characteristics and calculation chain.
- Long chains of dependent calculation, where a change at one step propagates downstream.
- Abatement applied against the pollutants actually reaching each device.
- Devices shared across trains, making a facility a connected graph, so a change to one device propagated into every train it served.
- Engineer-editable topology, so the schema had to absorb arbitrary structural change without losing continuity against prior inventory years.
- Fidelity to DataBank, the earlier system whose results the new inventory had to be reconciled against.
Outcome
The emissions calculations were validated by the District’s own engineers. They reconciled against DataBank where DataBank was sound and diverged where it was not; in the District engineers’ assessment the new calculations were the more accurate of the two, because they did not carry forward known shortcomings of the system they replaced.
The application was hosted on Azure and released to a test environment upgraded weekly, so District scientists and engineers exercised working software continuously rather than reviewing it at milestones. That cadence is what made the calculation validation possible.
When the engagement ended in December 2018, the District chose to move away from bottom-up modeling toward a system built on facility-reported emissions data. The District’s principal engineer on the project expressed strong satisfaction with IdeaBlade’s work and attributed the change of direction to changed requirements rather than to the quality or progress of the software.
