How to Map Permit Conditions to SCADA Tags
An air permit is a binder of conditions; a SCADA system is a set of monitored tags with limits and history. The work of compliance monitoring is translating the first into the second so that each condition is watched continuously and every deviation is logged. This guide gives a repeatable method for that translation, aimed at the engineer or compliance owner setting up permit monitoring. It defers to qualified personnel on interpreting the permit itself and applies to Texas and federal permits alike.
Permit Conditions to SCADA Tags in one line: To map a permit condition to a SCADA tag, read the condition to find the parameter it constrains, identify the field measurement that represents that parameter, set the condition's required range as the tag's alarm limits, and define how an excursion is logged as a candidate deviation. Repeating this for every condition turns a permit into a monitored set of tags whose history demonstrates compliance and captures deviations automatically.
Read Each Condition and Find the Parameter
Start by going through the permit condition by condition and, for each, asking what physical parameter it constrains. A condition on a control device might require a temperature to stay above a minimum; a condition on an engine might limit a runtime or require an operating parameter to stay in a band; a condition on a flare requires the flare to be operating. Each of these points at a measurable parameter, and identifying it is the first step in making the condition monitorable.
Some conditions map cleanly to a single parameter, while others require judgment about which measurement best represents compliance. A requirement that a control device be operating properly might be represented by a temperature that indicates the device is at operating condition, or by a flow, depending on the device. Making that representation choice deliberately, and documenting it, is what lets you defend that the tag genuinely reflects the condition. This mirrors how the Title V program ties conditions to monitored parameters, described in the explainer on the Title V air permit.
Work through every condition, not just the obvious ones, because a condition without a corresponding monitored parameter is a gap - a requirement no one is watching. The output of this step is a list pairing each permit condition with the parameter that represents it, which becomes the specification for the tags you will configure. Conditions that genuinely cannot be represented by a live measurement get flagged for a different compliance method, but the goal is to monitor what can be monitored.
Set the Limit and Define the Deviation Record
With each condition paired to a parameter, translate the condition's requirement into alarm limits on the corresponding tag. A minimum temperature becomes a low-limit alarm; a maximum becomes a high-limit alarm; a required band becomes a pair of limits. The tag now watches the parameter against the exact envelope the permit requires, so an excursion outside the permitted range triggers immediately rather than being discovered at a monthly review.
Then define how an excursion becomes a deviation record, because detecting an excursion is only useful if it is captured as the compliance event it represents. A deviation, in permit terms, is a departure from a condition, so an excursion of the tag outside its limit is a candidate deviation that has to be logged with its timestamp, duration, and the surrounding data. Defining this up front means deviations are recorded consistently as they happen rather than reconstructed later. The concept of a permit deviation is covered in the Title V explainer, and the general alarm discipline in the explainer on ISA-18.2 alarm management.
A cloud SCADA platform such as Merobix supports both halves because it applies limits to tags and retains the full history of values and alarms with timestamps. Setting the permit's ranges as tag limits means an excursion is detected instantly and logged as a candidate deviation, with the surrounding data preserved for the deviation record. That continuous capture is what turns the mapped permit into demonstrable compliance rather than a periodic scramble, and it feeds the reporting the permit requires.
Verify the Mapping and Keep It Current
Once tags and limits are configured, verify the mapping actually reflects the permit. Confirm that each condition has a tag, that each tag's limits match the condition's required range, and that an intentional test excursion produces the expected alarm and candidate-deviation record. This verification catches the errors that quietly defeat permit monitoring - a limit set to the wrong value, a condition with no tag, an alarm that does not log - before they cause a missed deviation.
Keep the mapping current as the permit and the facility change. When a permit is modified, its new or revised conditions have to be re-mapped to tags and limits; when equipment changes, the parameters representing a condition may change too. Treating the mapping as a living document, updated under the same change discipline as the SCADA system itself, is what keeps it from drifting out of alignment with the permit over time. This connects to the change-management discipline discussed in the guide on building a CRM plan.
The payoff of a verified, maintained mapping is that the permit becomes a monitored state rather than a periodic audit. Each condition is watched continuously, each excursion is captured as a candidate deviation, and the history holds the evidence for the permit's monitoring and deviation reports. Where the permitted source is a case-by-case NSR source, this same mapping serves its tailored conditions, as covered in the guide on how TCEQ new source review works.
Frequently Asked Questions
How do I turn an air permit condition into something SCADA can monitor?
Read the condition to find the physical parameter it constrains - a control device temperature, an engine operating parameter, a flare operating status - then identify the field measurement that represents that parameter and configure it as a tag. Set the condition's required range as the tag's alarm limits, so a minimum becomes a low-limit alarm and a band becomes a pair of limits. The tag then watches the parameter against the exact envelope the permit requires. Repeating this for every condition turns the permit into a monitored set of tags rather than a static binder.
How should a permit deviation be recorded in a monitoring system?
A deviation is a departure from a permit condition, so an excursion of a monitored tag outside its limit is a candidate deviation that should be logged automatically with its timestamp, duration, and the surrounding data. Defining this up front means deviations are captured consistently as they happen rather than reconstructed later from incomplete records. A platform that applies limits to tags and retains the full alarm and value history preserves the deviation record with the context needed to characterize it, which then feeds the monitoring and deviation reports the permit requires.
What can go wrong when mapping permit conditions to tags?
The common failures are a condition with no corresponding tag, so a requirement goes unwatched; a limit set to the wrong value, so real excursions are missed or false ones flagged; and an alarm that fires but does not log, so deviations are not captured. Verifying the mapping - confirming each condition has a tag, each limit matches the required range, and a test excursion produces the expected alarm and record - catches these before they cause a missed deviation. Keeping the mapping current as the permit and equipment change prevents it from drifting out of alignment over time.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.