How to Support an API 2350 Program with SCADA Data
SCADA can strengthen an overfill program with trends, alarm history, and test records - but only if it supplements the independent safety layer rather than quietly replacing it. This how-to walks the ways monitoring supports an API 2350 program and the line you must not cross, for the controls or process-safety engineer wiring tank data into a dashboard. The independence rules and final sign-off remain with your site safety procedures.
SCADA for API 2350 Programs in one line: To support an API 2350 program with SCADA, use monitoring for the things it does well - trending tank levels and fill rates, recording alarm and acknowledgment history, and logging proof tests - while keeping the overfill safety path independent of the inventory gauging you display. SCADA improves visibility and evidence; it must not become the single sensor that both fills the tank and is supposed to stop it.
Use SCADA for Trends and Fill-Rate Awareness
Start with the low-risk, high-value use: visibility. Trending tank level and computed fill rate gives operators the situational awareness to plan a controlled stop long before a level of concern is reached, which is exactly the intent behind the planning levels in API 2350 levels of concern. A rising trend with a known rate is far more actionable than a single number.
Convert level to volume with the tank strapping table so operators see remaining ullage in real units, and derive the time-to-full from the current fill rate. This turns raw level into the response-time picture the program is built around, without touching the safety layer.
Capture Alarm and Acknowledgment Records
SCADA is excellent at evidence. Every overfill-related alarm, who acknowledged it, and when, becomes a record the program can show an auditor or an SPCC plan review. This closes the loop the program cares about: not just that an alarm fired, but that a human responded. A notification acknowledgment loop is the mechanism that captures it.
Use the same history to tune. If a planning-level alarm chronically fires during normal operations, it is mis-set and training operators to ignore it - the alarm-fatigue failure mode the program must avoid. The record is how you find and fix those, keeping the meaningful alarms trusted.
Log Proof Tests, Do Not Replace Them
Proof-testing the independent high-level path is a program requirement, and SCADA is a good place to schedule, prompt, and record those tests. Logging when the independent high-level alarm was last proven, and the result, keeps the maintenance evidence current and visible.
Here is the line you do not cross: the SCADA-displayed inventory measurement must not also be the safety trip. The overfill path stays independent - a separate sensor and, for higher categories, an automatic high-high level shutdown - so a fault or a spoofed value in the monitored inventory tag cannot silently disable protection. Monitoring watches; the independent layer protects.
Verifying the Result
Confirm two things before you call the integration done. First, that the independent overfill path still functions with the SCADA link removed - pull the network and prove the high-level trip still fires. If it does not, you have coupled monitoring to safety, which is the exact failure the program forbids.
Second, that the records are actually being captured and are retrievable. Trigger a test alarm, acknowledge it, and confirm the event and its acknowledgment appear in the history with a timestamp. Evidence that cannot be retrieved is not evidence, and an auditor will ask to see it.
Common Mistakes
The signature mistake is using the inventory gauge as the overfill trip to save a sensor. That collapses the independence the whole program depends on - one instrument fault or one bad value now both misreports level and fails to protect. Keep the layers separate no matter how good the gauge is.
The second is treating a busy alarm list as thorough monitoring. Chronic nuisance alarms at planning levels erode response to the real high-level event. Tune from the alarm history so the alarms that fire are the ones that mean act now.
Frequently Asked Questions
Can SCADA replace an independent overfill sensor?
No. The overfill safety path must stay independent of the inventory gauging that SCADA displays, so a fault or bad value in the monitored tag cannot disable protection. SCADA supplements the program with trends, records, and test logging; it does not become the safety trip.
How does SCADA help an API 2350 audit?
It captures the evidence auditors ask for: level trends, alarm and acknowledgment history, and proof-test records for the independent high-level path. That shows not only that alarms fired but that they were responded to and that protection was tested.
How do I prove the overfill path is still independent?
Remove the SCADA link and confirm the independent high-level trip still fires. If the trip depends on the monitored inventory value, you have coupled monitoring to safety, which defeats the program's independence requirement.
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.