An IoT gateway should not pass acceptance merely because it connected to a PLC and delivered data to the cloud once. Procurement must establish what happens after WAN loss, power failure, certificate renewal or storage pressure—and whether loss, duplicates, order and time can be explained with replayable evidence. This guide turns those capabilities into vendor-neutral RFP, FAT and SAT requirements.
IoT gateway selection: buy evidence, not a connection claim
An industrial gateway is often described as a protocol-conversion box between PLCs or sensors and higher-level systems. The purchasing boundary is wider than the hardware. Collection services, durable queues, time synchronization, certificates, configuration, monitoring, backup, recovery procedures and support together form a data-transport service.
A normal-operation demonstration is only an entry screen. Acceptance needs deliberate failures and changes. Where is data stored when the WAN is cut? At the limit, does the gateway protect old or new data? After reconnection, in what order and at what controlled rate does it replay without overwhelming the receiver? When a message is retried, where is double posting prevented? If these questions are unanswered before contract award, a production incident can easily become an argument about scope.
The core acceptance equation is:
Requirement + fault injection + observation method + pass criterion + exportable evidence = verifiable acceptance
Adjectives such as “buffered,” “highly reliable” and “secure” cannot be accepted. The test should preserve input data, disconnection and restoration times, sent and received counts, sequence gaps, duplicates, queue depth, alerts, configuration version and logs as one evidence bundle.
Scope of this guide and distinction from related articles
This article covers procurement, acceptance and operational handover of the gateway itself. Related decisions are addressed separately:
- Edge computing for factories addresses where workloads belong: close to equipment, on premises or in the cloud.
- PLC data collection addresses acquisition routes, tag volume, polling and trigger methods.
- Equipment runtime log capture addresses the semantics of running, stopped, setup and other events.
Here, those design choices are assumed to exist. The question is how to specify, break and accept the gateway that transports the resulting data.
Define a one-page data contract before procurement
Before drafting an RFP, map the data contract from source to consumer on one page. Scoring the gateway in isolation creates a familiar gap: the PLC team says it exposed the value, the network team says it restored the circuit and the cloud team says it stored everything received, yet nobody owns the missing record.
| Contract item | Buyer definition | Acceptance evidence |
|---|---|---|
| Unique key | Combination of asset, signal, event and sequence | Stored result before and after duplicate injection |
| Ordering scope | Per asset, tag, topic or another declared scope | Comparison of sent and persisted order |
| Time | Source, receive, send and persistence timestamps | All timestamps and synchronization state per record |
| Loss | Definition of a missing record and notification owner | Gap list, alert and reprocessing result |
| Duplicate | Permitted retries and ownership of double-post prevention | Result when the same key is resent |
| Storage | Capacity, retention, encryption and pressure policy | Queue depth, utilization and discard log |
| Recovery | Replay order, rate control and stop/resume rules | Recovery timeline and count reconciliation |
| Change | Procedure for tags, settings, certificates and software | Change record, approval and rollback result |
Set quantities from plant conditions, not from a catalog claim. Measure tag count, normal interval, maximum burst, record size, expected communications outage and the receiving system’s limit. Capture the shape of peaks during changeover, coordinated line starts or maintenance recovery—not only an average.
Keep source time and receive time distinct
The origin of a timestamp matters as much as the value. Source time is when the value or event is produced or observed at the source; receive time is when the gateway receives it. After a WAN outage, cloud-arrival time can make hours-old events appear to have happened at recovery.
Ask the supplier to declare who creates each timestamp, timezone, resolution, synchronization source, behavior when synchronization fails, daylight-saving treatment and response to manual clock changes. Do not copy a universal clock-skew threshold. Derive it from quality decisions, alarm correlation and traceability use. If collection continues while unsynchronized, retain a quality indicator and enough context to interpret the data.
Specify a monotonic sequence across restart behavior
A monotonically increasing sequence helps detect gaps, reversals and duplicates, but “sequence supported” is incomplete. Define its scope, whether it resets after restart, how rollover works and whether restoring an old configuration can restore an old counter.
If restart resets the sequence, combine it with a boot-generation identifier. Construct an idempotency key from deterministic elements such as equipment ID, data type, boot generation and sequence. A receive timestamp or random key created on each retry can make the same message look new and defeat deduplication.
A store-and-forward acceptance specification for WAN loss
Store-and-forward means persisting data during a communications outage and forwarding it after recovery. A tick in a feature matrix says little about fitness. Break the claim into durability, capacity, overflow, replay order, backpressure and evidence export.
Do not contract buffer capacity as “time” alone
“Several days of data” loses meaning when tag volume or interval changes. Require a calculation using:
- normal and peak record-generation rate;
- stored size including record, headers, indexes and encryption overhead;
- conservative behavior when compression performs poorly;
- space shared by the operating system, logs, updates and buffer;
- reserved flash space, media life and health indication; and
- growth caused by tag or configuration changes during an outage.
State both required duration and required records or bytes. In FAT, use bursts and values with poor compression, not only a friendly sample. Judge usable operational capacity, not the headline storage capacity.
Make overflow policy a business decision
When capacity is exhausted, the gateway can drop oldest data, reject new data, discard low-priority data first or reduce sampling. Every choice has an operational effect. Approve the policy with production, quality and maintenance rather than accepting the vendor default.
Silent discard is a failure under any policy. Require warning and critical thresholds, discard start and end time, count and scope of discarded records, remaining data and operator acknowledgement. Decide whether recovery to normal is automatic or requires approval.
Test ordered replay and backpressure together
Sending an entire backlog at maximum speed after reconnection can overload an API, broker or database and trigger more timeouts and retries. Giving all capacity to backlog can also leave live visibility behind for an extended period.
Acceptance should show how live and queued data share capacity, how receiver rejection or throttling is detected, how rate is reduced and how it returns to normal. Declare the necessary order scope. A total order across all machines is rarely required; an order per asset or event stream can be clearer to implement and verify.
| Outage/recovery test | Fault injection | How to write the pass criterion | Required evidence |
|---|---|---|---|
| Continuous outage | Disconnect WAN for the buyer-defined duration | Collection continues, durable persistence works and loss stays within the approved limit | Input, queue and output counts; gap list |
| Repeated flapping | Alternate connect and disconnect | No process crash or infinite retry due to flapping | State transitions, reconnect count, error log |
| Receiver rejection | Simulate delay or throttling | Sending obeys backpressure | Send rate, queue depth, rejection responses |
| Capacity pressure | Approach warning and hard limits | Approved warn, protect and discard behavior occurs | Capacity trend, notifications, discard record |
| Recovery replay | Restore WAN while live input continues | Replay follows declared order without overloading receiver | Order comparison, finish time, duplicate result |
MQTT QoS is not application-level exactly-once processing
MQTT 5.0 defines QoS 0, 1 and 2, session state, Session Expiry Interval, Receive Maximum and retry behavior. QoS 0 provides at-most-once delivery, QoS 1 at-least-once delivery, and QoS 2 is the protocol mechanism for once-only delivery between MQTT peers. That does not automatically mean an equipment value is processed exactly once across a data lake, MES, alarm engine and report.
A gateway may receive PUBACK before a downstream persistence failure. A transformation can be rerun. Parallel consumers can change persistence order. Specify QoS separately from application idempotency keys, deduplication, transaction boundaries and reconciliation.
MQTT fields to require in an RFP response
| Item | Required supplier response | FAT check |
|---|---|---|
| QoS | Value and rationale per topic/data class | Configuration export plus protocol/application logs |
| Session | Clean Start, session expiry and reconnect state | Unacknowledged messages after restart/disconnect |
| Flow | Receive Maximum, inflight limit and queue relationship | Concurrency and memory under receiver delay |
| Retry | Conditions, interval, limit and quarantine | Duplicates and recovery when acknowledgements disappear |
| Order | Guaranteed scope and effect of parallelism | Comparison against a known sequence |
| Persistence | State retained through service and power restart | Reconciliation after forced power loss |
Do not award points merely for “QoS 2.” Inject the same deterministic key and confirm that the final consumer does not double count it. Depending on the business process, the proper outcome may be discard, update of the same key or quarantine for review.
Draw the responsibility boundary around PLC data collection
PLC data collection must define driver, address, read interval, change detection and quality codes. Gateway acceptance asks whether the acquired result can be transported without losing those semantics. Count these states separately:
- values read from PLC or device;
- values accepted by the gateway collection service;
- values committed to durable buffer;
- values transmitted to the WAN;
- values accepted by broker or API;
- values committed at the final store; and
- values accepted, deduplicated or quarantined by business processing.
Follow the same correlation or unique key at each boundary to prove where a record disappeared. Send-success counts alone can exceed input after retries. Reconcile accepted, duplicate, quarantined and outstanding counts.
Prevent configuration changes from changing a tag’s meaning silently
Adding a tag or changing address, scale, unit or sign can alter the meaning of an existing time series. Keep version, effective time, approver, reason, affected tags and rollback procedure for every configuration. Relating the configuration version to the data makes values before and after the change explainable.
Freeze the FAT-approved configuration as a hash- or signature-verifiable artifact, then verify identity at SAT start. If site IP addresses must differ, separate environment parameters from logic and retain an approved difference report.
Turn OT security features into operational acceptance conditions
NIST SP 800-82 Rev. 3 explains that OT security must consider performance, reliability and safety and discusses architectures, segmentation and boundary protection. Gateway security therefore cannot be reduced to “encryption supported.” Accept placement, traffic direction, privilege, certificates, updates, logs and recovery together.
Least privilege and network zoning
Avoid a gateway with unrestricted reach into both the PLC network and corporate LAN. Enumerate source, destination, port and direction from the data flow, start with default deny and approve exceptions. Include operational traffic such as administration, SSH where authorized, APIs, time synchronization, certificate status checks and monitoring.
Grant service accounts only the necessary tag reads and topic writes. Avoid shared administrator accounts for routine work; define individual identity, roles, emergency access and revocation. Disable unused services, default accounts and ports, then verify the result through configuration evidence.
OPC UA certificates and security policy
The OPC UA security model addresses application and user authentication, message integrity and confidentiality, X.509 certificates, signing/encryption and auditability. Do not accept “OPC UA compatible” alone. Specify the actual SecurityPolicy, MessageSecurityMode, trust and rejected lists, private-key protection, issuer, revocation and renewal procedure.
Whether to allow self-signed certificates or use plant PKI depends on operating capability. In either case, do not trust an unknown endpoint automatically; alert before expiry; rotate with minimal approved disruption; and revoke/remove superseded certificates. During FAT, use test certificates to create expiry, untrusted issuer and private-key mismatch. During SAT, perform a production-procedure rotation and show continuous communication or the approved switchover interruption.
Put updates and vulnerability response in the support contract
Security at purchase does not establish security years later. Ask for support lifetime, notification channel, vulnerability assessment, fix policy, emergency update, rollback, signature verification and available component inventory.
Automatic updates can affect production, while indefinite deferral retains known risk. Follow the buyer’s change process: test, approve, back up, install in a maintenance window, health-check and roll back if needed. The post-update smoke test must cover collection, buffering, sending, monitoring, certificates and time synchronization—not merely boot success.
Accept power-loss recovery, cold start and backup restore
Plants face not only planned shutdowns but momentary outages, UPS transfer failure, breaker operation and storage fault. Restart after a graceful shutdown is insufficient evidence.
What to verify in a forced-power-loss test
Cut power while collection, persistence and transmission are active under the declared load. Check that filesystem, queue, configuration database and certificate store are intact. Reconcile the commit boundary just before failure, records replayed after startup and the final deduplicated count.
During cold start, network, DNS, time service, PLC and cloud may not become ready together. Delay dependencies and verify appropriate waiting and retry, without endless restart or an interactive login requirement. Monitoring must report state even during an unattended night shift.
A backup is accepted only with restore evidence
NIST SP 1339, the OT Backup Quick Start Guide, recommends integrating backup into change management, creating backups regularly, testing them and reviewing them in recovery exercises. Inventory the gateway’s OS image, application, drivers, tag configuration, rules, certificates and private keys, trust list, network and monitoring settings, and local data. Decide how each is protected.
Some private keys cannot belong in a general backup. Document reissuance and dependencies. For restore to replacement hardware, address hardware differences, license reissue, device identity, certificate names and static addresses. Acceptance needs an actual restore to an initialized equivalent device and end-to-end flow—not only a “backup successful” log.
| Recovery object | Required RFP response | SAT evidence |
|---|---|---|
| Configuration | Scope, format, encryption and versioning | Difference report after restore to clean device |
| Certificates | Private-key protection, reissue and revocation | Production PKI procedure and connection result |
| Local data | Consistency, retention and replay after restore | Count/key reconciliation before and after |
| Software | Image, dependencies and license | Running version, signature and health check |
| Procedure | Owner, privilege, storage and approval | Record that another authorized operator recovered it |
Observability and exportable evidence
A green indicator on a proprietary dashboard cannot explain an incident or acceptance result. Observe at least collection rate, send rate, queue depth, age of oldest record, discarded and retried records, connection state, certificate expiry, synchronization state, storage health, CPU/memory and service restart.
An alert should identify target, start time, impact, current value, threshold, recommended first action and correlation ID. Derive thresholds from the data contract and separate warning from critical. Alert suppression should prevent storms while preserving the first, last and suppressed-event count.
Do not lock evidence inside a supplier screen
Require FAT/SAT results, incident and audit logs, configuration and metrics in agreed formats such as CSV, JSON or standard log forwarding. Export timezone, unit, column definition, missing-value meaning, product version and configuration version. Preserve evidence needed for audit and diagnosis even after a viewer license ends.
Also verify that logs do not disclose passwords, private keys, tokens or unnecessary personal data. Define masking, authorization, transfer and deletion when a support bundle leaves the plant.
Vendor-neutral IoT gateway RFP requirements
The clauses below are a product-neutral starting point. Replace bracketed values with measured plant requirements and attach priority, response class, evidence and owner.
| ID | Requirement | Mandatory response evidence |
|---|---|---|
| DATA-01 | Assign a deterministic unique key and monotonic sequence within a declared scope | Key composition, restart/rollover rule and sample |
| TIME-01 | Distinguish source and gateway receive time and retain synchronization quality | Schema, time settings and skew-test log |
| BUF-01 | Persist the declared load through at least [duration] or [quantity] of WAN loss | Capacity calculation, media design and FAT result |
| BUF-02 | Execute the approved overflow policy at warning/hard limits and export evidence | Alerts and discard/protection log |
| REP-01 | Replay after recovery in the declared order with backpressure and approved treatment of live data | Queue trend, send rate and order comparison |
| DED-01 | Define responsibility for idempotent treatment of a resent key through the final consumer | Duplicate-injection and final-store result |
| SEC-01 | Present zoned placement, least privilege and only required communications | Data flow, rules and privilege matrix |
| CERT-01 | Define certificate issue, distribution, trust, monitoring, rotation and revocation with outage effect | Rotation-test record |
| PWR-01 | Recover automatically after forced power loss without corrupting committed data or configuration | Reconciliation before and after cut |
| BAK-01 | Restore to an equivalent device and resume collection-to-delivery operation | Restore steps, elapsed time and flow evidence |
| OBS-01 | Monitor and alert health, queue, loss, duplicate, time, certificate and capacity state | Metric catalog and alert test |
| EVD-01 | Export FAT/SAT and operational evidence in the agreed format | Actual files, schema and viewing method |
Classify responses as standard, configuration, custom development, third-party product, unavailable or future roadmap. “Can support” is not a sufficient answer. Require product version, license, settings, constraints, responsibility and additional cost. Do not score a roadmap item as a present capability.
Build reproducibility in FAT; close site differences in SAT
FAT checks requirements and test procedures early in a supplier or integration environment. SAT checks site differences with the actual PLC, network, time, PKI, receiver and operations team. FAT does not replace SAT, while discovering a specification defect for the first time at SAT is equally undesirable.
FAT preparation
Prepare replayable data containing representative tags, intervals, bursts and quality codes. Select tools that can inject WAN loss, receiver delay, invalid certificates, clock skew, storage pressure and power loss. For each test, document configuration, starting state, action, expected result, observation points, pass values, evidence filenames and retest rules.
After FAT, freeze software, OS, drivers, containers, tag configuration, rules, certificate template and monitoring as a configuration baseline. Deliver the scripts and data used. This lets the buyer reproduce the same failure against a fix or replacement device.
SAT priorities
SAT checks real PLC traffic, VLAN/firewall, DNS, NTP, proxy, plant PKI, cloud limits, power restoration and local privileges. Record every difference from FAT and leave no unapproved setting change.
Fault tests that could affect production must respect equipment safety and the production plan, using simulated signals, a test line or maintenance window. As NIST SP 800-82 emphasizes, security measures in OT must consider performance, reliability and safety. A security test must never place control or safety functions in a hazardous state.
Decide pass/fail with counts and evidence
| Test | Input/fault | Pass value | Evidence |
|---|---|---|---|
| Normal continuous | Approved representative load | Within buyer-defined loss, delay and resource limits | Input/output reconciliation and resource trend |
| WAN loss/replay | Declared outage and recovery | Within declared loss, duplicate, order and completion limits | Unique-key reconciliation and queue trend |
| Power loss | Forced cut during write | No configuration corruption; recovery follows commit boundary | Boot log and before/after counts |
| Time abnormality | Sync loss, skew and clock change | Quality indication and approved continue/stop behavior | All timestamps and sync log |
| Certificate rotation | Change old to new certificate | Reject untrusted endpoint and restore within approved interruption | Trust list, audit and connection record |
| Backup restore | Restore to clean or replacement device | Restore configuration/data and establish end-to-end flow | Difference, versions and flow result |
| Monitoring/evidence | Trigger each fault | Correct alerts and complete export | Notifications, CSV/JSON and logs |
Freeze acceptance values before RFP issue or contract signature so that candidates are compared equally. If the buyer lacks a baseline, make measurement an earlier deliverable and create a contract gate that freezes values after approval.
Thailand procurement and BOI checks
In its first-half 2026 announcement, Thailand BOI reported 132 Smart and Sustainable Industry applications valued at approximately THB 17.2 billion, covering areas including machinery upgrades, digital technology, automation and robotics. This is context for modernization interest—not evidence of approvals, realized benefit, gateway market size or ROI.
BOI Smart and Sustainable Industry material includes categories such as automation/network technology, data analytics or smart operation and digital technology. Whether a specific gateway, software, configuration, installation or support item qualifies is case-specific. Confirm activity, investment scope, expenditure and timing with BOI or a qualified adviser. Do not subtract an unconfirmed incentive from the budget or business case as a guaranteed value.
Include local operation in the RFP
Confirm Thai/English first-line triage, night-shift contact, local replacement stock and boundaries among supplier, telecom and cloud providers. Reflect site measurements for lightning exposure, momentary outage, heat, dust and panel space. Do not stop at generic environmental ratings; specify the installation location’s temperature, humidity, power, grounding, EMC and enclosure requirements.
A spare is not an instant recovery unless configuration, certificates, license and backup are available. Have the local operator perform replacement, from approval of remote support through end-to-end validation.
A practical path from procurement to handover
1. Measure the current environment
Record tags, intervals, payload, peaks, outage history, receiver capacity, synchronization and network path. Measure current loss and duplicates as the baseline.
2. Approve the data contract and responsibility boundary
Production, maintenance, quality, OT, IT and data consumers agree on unique key, sequence, time, quality, loss, duplicate, order, persistence and recovery.
3. Issue the RFP with test sheets
Provide FAT/SAT fault injection, pass values and evidence format along with functional questions. Compare constraints and alternatives before contract.
4. Freeze configuration through FAT
Reproduce normal and failure cases, manage findings and retest. Freeze the accepted version and hand over test data, scripts and evidence.
5. Verify site differences through SAT
Safely test real PLC, network, PKI, receiver and power recovery. Approve differences and have the local team execute monitoring, communication and workaround procedures.
6. Accept only after a recovery exercise
Restore backup, rotate certificates, replace with an equivalent device and export evidence. Verify that designated operators can complete the procedure, not merely that a document exists.
7. Transfer into operational KPIs and change control
Review loss, duplicates, oldest backlog, capacity, certificate expiry, synchronization and update state. Re-run affected acceptance tests as regression tests after tag or firmware changes.
Common selection failures and corrections
Accepting “connected successfully”
A short demonstration does not expose WAN loss, queue limit, restart or certificate expiry. Move fault injection and count reconciliation into acceptance and retain reusable test assets.
Treating QoS as the complete duplicate strategy
MQTT delivery and final business idempotency are different. Preserve the unique key end to end and inspect final persistence or aggregation after duplicate injection.
Saving arrival time only
The actual event time of replayed data disappears. Separate source and receive time and retain synchronization quality, configuration version and sequence.
Comparing storage capacity only
Usable space, record size, peak, sharing with logs/OS and overflow policy determine retention. Measure capacity trend with realistic load.
Trusting a backup-success log
A file is not a recovery if certificates, licenses, drivers or procedure are missing. Require restore to a clean/replacement device and end-to-end flow.
Leaving monitoring inside a supplier portal
Evidence can become inaccessible after contract termination, network failure or portal outage. Export metrics, configuration, logs and test results in an agreed format.
Conclusion: gateway value is explainability after failure
An industrial gateway does not pass because it transmitted once. Bring durable store-and-forward, monotonic sequence and idempotent deduplication, source/receive time and clock quality, capacity and overflow, ordered replay and backpressure, certificate rotation, least privilege and zoning, cold start and power-loss recovery, backup restoration, observability and evidence export into one acceptance specification. Designing RFP and FAT/SAT together replaces adjectives with reproducible proof and clarifies responsibility after handover.
Even before data volume and outage conditions are fully known, the current-state measurement can be turned into RFP clauses and FAT/SAT sheets. To develop a vendor-neutral acceptance specification around the equipment, network and receiving systems at a Thailand plant, contact TOMAS TECH.
FAQ
What does an IoT gateway do?
It receives data from PLCs and sensors and can perform protocol conversion, transformation, local persistence, upstream delivery and monitoring. Procurement should evaluate the whole service—including configuration, certificates, backup and support—not only the box.
What is the top priority when selecting an IoT gateway?
Prioritize data integrity and recovery evidence after WAN loss, receiver delay, storage pressure, power loss and certificate rotation, rather than connection count in normal conditions. Prefer candidates that reconcile deterministic keys and counts from input through final storage.
How is PLC data collection different from gateway selection?
PLC collection is mainly about how to acquire: address, tag count, interval and protocol. Gateway selection is about retaining, replaying and observing acquired data during abnormal conditions and managing the lifecycle. Connect the responsibility boundary with correlation IDs and counts.
Does MQTT QoS 2 eliminate duplicate handling?
No. QoS 2 addresses delivery between MQTT protocol peers; it does not automatically make transformation, database storage, re-execution and multiple consumers exactly once. Test a deterministic unique key and idempotent final processing.
Which timestamps should equipment data collection store?
At minimum, distinguish source time at the equipment from gateway receive time. Add send and persistence time when needed. Define timezone, synchronization source and quality, clock-change behavior and allowable skew so replayed data retains its original chronology.
Should an edge-computing factory put all processing on the gateway?
No universal placement fits every case. Separate low-latency safety/control, processes that must continue on site and cloud-scale aggregation. Once a workload is assigned to the gateway, acceptance must verify its persistence, recovery, update and monitoring behavior.
What OT security requirements apply to a gateway?
Core topics include zoning, allow-only-required communications, least privilege, individually attributable administration, certificate lifecycle, signed updates, logs, backup and restore. Test them in the actual architecture while respecting production availability and safety.
Are both FAT and SAT necessary?
They serve different purposes. FAT checks design and product capability early with replayable data and fault injection, then freezes configuration. SAT verifies differences in the actual plant’s PLC, network, PKI, power and operating team. Link critical requirements through common test IDs and evidence.
Can a BOI incentive be included in an IoT gateway budget?
Do not treat it as guaranteed before confirmation. BOI material includes automation/network technology, data analytics and digital technology categories, but activity, expenditure and timing must be confirmed for the individual project with BOI or a qualified adviser.
Sources
- NIST SP 800-82 Rev. 3, Guide to Operational Technology Security: https://csrc.nist.gov/pubs/sp/800/82/r3/final
- NIST SP 1339, OT Backup Quick Start Guide: https://csrc.nist.gov/pubs/sp/1339/final
- OASIS, MQTT Version 5.0: https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
- OPC Foundation, OPC UA Security: https://opcfoundation.org/security/
- OPC Foundation, OPC UA core specification: https://reference.opcfoundation.org/specs/OPC-10000-1/4.4.1
- Thailand BOI, investment applications press release, first half of 2026: https://www.boi.go.th/index.php?_module=news&from_page=press_releases2&language=en&page=press_releases_detail&topic_id=139075
- Thailand BOI, Smart and Sustainable Industry: https://www.boi.go.th/upload/content/Smart_and_Sustainable_Industry.pdf
Note: Standards, programs and product specifications change. Do not copy pass values, retention or recovery targets from this guide. Set them from the plant’s measurements, risk assessment and current primary sources. BOI eligibility requires project-specific confirmation.
