Integrating real-time dew point calculations into a pipeline SCADA system sounds straightforward in principle — take gas composition from the GC, calculate CHDP, display the result. In practice, however, the integration involves navigating a complex mix of legacy protocols, real-time data flow requirements, and EOS calculation performance constraints.
This guide walks through the practical steps of implementing real-time dew point calculation in SCADA, covering both legacy TCP-based architectures and modern REST API approaches.
Step 1: Understand Your Data Source — The Process Gas Chromatograph
The foundation of any calculation-based dew point monitoring system is the process gas chromatograph (GC). The GC provides the mole fraction composition of the gas stream — typically every 3–15 minutes — which is the primary input to the EOS dew point calculation.
Key considerations for your GC data source:
- Component range: For accurate CHDP calculation, you need composition data through at least C6+ (hexane-plus). A GC analyzing only C1–C5 will underestimate CHDP for rich gas streams. If your GC only provides a C5+ lumped fraction, the calculation can still be performed but with reduced accuracy.
- Data format: Process GCs typically report composition via Modbus RTU/TCP, OPC-DA, or OPC-UA. Your SCADA historian or DCS will have this data already — you need to route it to your calculation service.
- Update frequency: Most GCs update every 3–15 minutes (one analysis cycle). Your CHDP display in SCADA should update on the same cadence. Between updates, the last-calculated value should be held with an appropriate staleness indicator.
- GC validation: Composition values that don’t sum to 100% (within tolerance) or contain obviously erroneous component fractions should trigger a calculation hold and alarm. Garbage in, garbage out applies with particular force to dew point calculations.
Step 2: Choose Your Integration Architecture
There are two primary integration patterns for real-time dew point calculation in SCADA:
Pattern A: TCP Windows Service (Legacy-Compatible)
In this architecture, a calculation engine runs as a Windows Service on a server within the control network (or the SCADA server itself). The SCADA software calls the calculation service via a proprietary or standard TCP protocol, passing gas composition and receiving CHDP, water dew point, and phase envelope results.
When to use: Legacy SCADA systems (e.g., older versions of Wonderware, iFix, Citect, or proprietary pipeline SCADA) that do not support HTTP/REST calls natively. The TCP service runs on the same server or network segment as the SCADA, with no internet connectivity required.
Advantages: Zero changes to control logic required; integrates with existing Modbus or proprietary TCP call mechanisms; low latency on the local network; no firewall or network architecture changes needed.
Pattern B: REST API (Modern Architecture)
In this architecture, the calculation engine is accessed via a standard HTTP/REST API, typically with a Swagger/OpenAPI specification. The SCADA, DCS, or a middleware layer (e.g., a Node.js or Python data pipeline) makes HTTP POST requests with gas composition data and receives JSON responses with calculated dew point values.
When to use: Modern SCADA platforms (OSIsoft PI, Ignition, OPC-UA-based systems), cloud-connected monitoring dashboards, or any system where REST integration is easier than raw TCP socket programming.
Advantages: Standard, well-documented integration; easy to test with tools like Postman or curl; naturally suits microservice architectures and cloud deployments; Swagger documentation enables auto-generation of client code.
Step 3: Map Your SCADA Tags to Calculation Inputs
For a 24-component EOS calculation (as used by DPCloud), you need the following input data from your SCADA historian or DCS:
- Methane (C1), Ethane (C2), Propane (C3), i-Butane (iC4), n-Butane (nC4)
- i-Pentane (iC5), n-Pentane (nC5), Hexane (C6), Heptane (C7), Octane (C8), Nonane (C9)
- Decane (C10), Undecane (C11), Dodecane (C12)
- Nitrogen (N2), CO₂, H₂S, Hydrogen (H2), Helium (He), Argon (Ar), Oxygen (O2)
- Benzene, Toluene, Water (if applicable)
Most process GCs report only a subset of these components (e.g., C1–C6+, N2, CO₂). Unmeasured components can be set to zero or estimated based on historical averages. The calculation engine should handle sparse compositions gracefully — normalizing the provided mole fractions to sum to 1.0.
Step 4: Implement the Calculation Call
REST API Example (DPCloud)
POST /DewPoint/PhaseEnvelope HTTP/1.1
Host: developer.kycis.com
Accept: */*
X-Api-Key: <your-api-key>
Content-Type: application/json
{
"Pressure": 400,
"Watercut": 6,
"Fractions": {
"N2": 0.1799,
"C1": 83.8201,
"C2": 9,
"C3": 5,
"i-C4": 2
}
}
Response:
{
"success": "success",
"type": "PhaseEnvelope",
"timeUTC": "2026-04-23T16:35:29Z",
"timeElapsed": "2 ms",
"condition": {
"pressure": { "pressure": 400, "unit": "psig" },
"watercut": { "watercut": 6, "unit": "lb/MMCf" },
"fractions": { "N2": 0.1799, "C1": 83.8201, "C2": 9, "C3": 5, "i-C4": 2 }
},
"result": {
"phaseEnvelopPoints": [
{ "pressure": -7.3, "temperature": -124.32, "phase": "Dew" },
{ "pressure": 132.3, "temperature": -37.90, "phase": "Dew" },
{ "pressure": 867.1, "temperature": 10.49, "phase": "Dew" },
{ "pressure": 1210.3, "temperature": -17.97, "phase": "Dew" },
{ "pressure": 1138.1, "temperature": -40.77, "phase": "Critical" },
{ "pressure": 867.1, "temperature": -75.59, "phase": "Bubble" },
{ "pressure": 132.3, "temperature": -184.17, "phase": "Bubble" }
/* ~48 points total; additional points omitted for brevity */
],
"specialPoints": {
"criticalPressure": 1138.13,
"criticalTemperature": -40.77,
"cricondenbar": 1210.27,
"cricondentherm": 10.63
},
"temperatureUnit": "F",
"pressureUnit": "psig"
}
}The response delivers what a SCADA integration actually needs: the full hydrocarbon phase envelope as a list of (pressure, temperature, phase) points, plus the four specialPoints — critical pressure and temperature, cricondenbar, and cricondentherm. Pressures are reported in psig and temperatures in °F. For a simple hydrocarbon dew point alarm, interpolate the Dew-phase points at your operating pressure, or read cricondentherm directly as the worst-case dew point across the envelope.
Step 5: Configure SCADA Alarming
Once the calculated CHDP value is available as a SCADA tag, configure alarms based on your gas quality specifications and operational requirements:
- Hi-Hi alarm (specification limit): CHDP > contract specification (e.g., 32°F). This triggers commercial notification and potential flow curtailment.
- Hi alarm (approach warning): CHDP > specification − 5°F (e.g., 27°F). Early warning to investigate composition trends.
- Calculation staleness alarm: Last successful calculation > 20 minutes ago (GC or calculation service issue).
- Calculation failure alarm: Calculation service not responding or returning error codes.
Store the calculated CHDP values in your historian (OSIsoft PI, eDNA, Aveva) with the same timestamp as the source GC composition update. This creates an auditable record of CHDP compliance over time — essential for tariff dispute resolution.
Step 6: Handle Edge Cases
Robust SCADA integrations need to handle the inevitable edge cases:
- GC in maintenance mode: When the GC is taken offline for maintenance, the composition data goes stale. The SCADA should flag CHDP as “calculated from historical data” and trigger a maintenance mode indicator.
- GC normalization failure: If GC component fractions don’t sum to 100% (±0.5%), hold the previous valid CHDP and raise a data quality alarm.
- Calculation service unavailability: Implement retry logic and a fallback to the last-known-good CHDP with a staleness indicator. The SCADA should never display zero or null for a live measurement point without an explicit “calculation unavailable” status.
- Composition outside EOS training range: Very lean gas (>99% methane) or very rich gas with exotic component fractions may produce phase envelope convergence issues. A well-implemented calculation service will return a diagnostic code indicating convergence failure.
Practical Integration with DPCloud
DPCloud is specifically designed for this integration scenario. It provides:
- Dual interface: Both a TCP Windows Service (for legacy SCADA) and a REST API with Swagger documentation (for modern platforms) — choose the interface that fits your architecture, or use both simultaneously.
- High performance: 490 requests/second sustained throughput with 132ms peak latency, capable of serving calculation requests from dozens of measurement points simultaneously.
- Zero-infrastructure deployment: Self-contained x64 Windows Service with no external dependencies — runs on an existing SCADA server without additional software installations.
- 30-day trial: Full-featured trial license for integration testing before production deployment.
Frequently Asked Questions
Do I need a dedicated server for the dew point calculation service?
No. DPCloud runs as a Windows Service on any x64 Windows machine — including existing SCADA servers. At 490 RPS capacity, it will consume negligible CPU resources on any modern server when serving a typical site with 1–20 GC measurement points updating every 3–15 minutes.
Can the calculation service run in a DMZ or isolated network?
Yes. DPCloud requires no internet connectivity after installation. License validation uses a local RSA-signed .lic file. The service can run entirely within an air-gapped control network.
What SCADA platforms are compatible?
Any SCADA platform that can make TCP socket connections or HTTP POST requests. This includes Wonderware (AVEVA System Platform), iFix, Citect, Ignition (Inductive Automation), OSIsoft PI AF, and custom C#/.NET, Python, or Node.js middleware. The REST API follows the OpenAPI standard, making client code generation straightforward in any language.
Conclusion
Real-time dew point calculation integration in SCADA is a well-defined engineering problem with proven solutions. The key steps — establishing a reliable GC data feed, choosing the right integration pattern, mapping composition tags, implementing alarming, and handling edge cases — can be completed in a few days with the right calculation service.
If you’re evaluating options for your integration project, request a DPCloud trial license to test the full integration with your SCADA infrastructure at no cost.
Related: Sub-150 ms Dew Point Calculations: How DPCloud Combines Speed With Numerical Robustness — the engine-side counterpart to this integration article, covering phase-envelope continuation, the Hebden-type trust-region used inside TPD stability checks, and the K6 load-test numbers behind the latency budget.