Short answer: a PLC or DCS can technically calculate corrected volume or energy. In billing-grade measurement the real question is not whether the calculation can be done, but whether the result and the chain that produced it can be demonstrated to the contracting parties, the network operator or the legal metrology authority. A dedicated flow computer brings much of that evidence with it: a library of standard calculations, parameter protection, an event log, archives, software identification and, in some cases, a conformity certificate. In a PLC/DCS-based solution the same functions have to be designed, documented and approved within the project.
Saying a PLC can never be used is therefore wrong. It can be used when the measurement is outside legal metrological control and the contract allows it, or when the competent body accepts a PLC-based calculator with the required functions demonstrated. When the metering point is under legal control and the applicable regulation calls for an approved volume conversion device or calculator, the scope of that approval decides, not engineering preference.
Why being able to calculate is not enough
A billing figure only means something together with the records behind it. OIML R 140, which covers measuring systems for gaseous fuel, defines the calculator by its function rather than by a device type: the part of the measuring system that receives signals from the flow measuring device, transforms them and stores the results in memory until they are used. The same Recommendation notes that the term conversion device also covers the conversion function inside a calculator. The requirements therefore follow the function, wherever it runs, not the name on the box.
R 140 defines the audit trail as the set of records that allows a complete examination of measured variables, parameter settings and calculation results; it may include volume at metering conditions, pressure, temperature, calorific value, the conversion equation and its parameters, base volume and energy, calibration data and alarm logs. That is exactly what gets asked in a dispute: which parameters, which software version, which configuration changed by whom and when, and how fault periods were flagged.
First, establish the status of the measurement
Where a PLC/DCS fits, by measurement status
Measurement status | Who decides | Calculation in a PLC/DCS |
Process monitoring, control, internal allocation | Plant quality and engineering rules | A normal option; verification and record depth follow the operator's needs. |
Contractual custody transfer (outside legal control) | Contracting parties, network operator specification if any | Possible if the parties accept it; calculation verification, event log, archives and change management should be written into the contract. |
Measurement under legal metrological control | National legislation, competent or notified body | Only within the relevant approval or an arrangement accepted by the national authority; in most cases an approved conversion device or calculator is preferred. |
In the European Union, Article 3 of the Measuring Instruments Directive (MID, 2014/32/EU) lets Member States prescribe the use of measuring instruments for measuring tasks, so whether the MID applies to a given metering point depends on national rules. Elsewhere, national legislation answers the same question. If the status is unclear, clarify contract and regulator requirements in writing before design starts.
Technical criteria that change the decision
· Implementing and verifying the standard calculation: : which edition of the AGA, ISO or API method was coded, test records against reference values, numerical precision and cycle time. R 140 requires the conversion factor to be recalculated at intervals not exceeding 30 s.
· Protecting non-measured data: : base conditions, gas composition and meter factor must be present in the calculator before measurement, must be viewable, and any change must require breaking a seal or updating the audit trail.
· Intervention log and authorization: : for parameters not protected by a mechanical seal, R 140 calls for authorized access by a changeable code or hardware key and for every intervention between two verifications to be recorded with date and person, traceable for at least 2 years.
· Archives and fault behavior: : stored values must not be alterable without breaking seals; when memory is full, deletion must follow recording order and need a special manual operation. If the calculator halts, key values must be retained and remain accessible for at least 6 months.
· Software identification: : MID Annex I requires metrologically critical software to be identified and secured, with evidence of intervention kept. For a modifiable PLC program this means a version identifier, a checksum and a controlled change process.
· Out-of-range operation: : MID MI-002 requires an electronic volume conversion device to detect operation outside its stated operating range and stop integrating the converted quantity; that period may be totalized separately.
· Time and communication: : alignment of hourly and daily records with the contract day, a single time source, logging of clock corrections, and protection of the link between field devices and the calculator.
Function – Record – Responsibility matrix
The matrix below can serve as a checklist in a specification or review meeting. The flow computer column summarizes common practice; each device's documentation and approval scope must still be checked.
Function – Record – Responsibility matrix
Function | Typical flow computer provision | To be demonstrated if done in a PLC/DCS | Approval / responsibility |
Standard calculation (AGA, ISO, API) | Ready methods in the vendor library, selected by configuration | Edition of the coded method, test report against reference values, precision, cycle time, boundary cases | Integrator prepares; contracting parties, or notified body under legal control, accept |
Non-measured data (base conditions, composition, meter factor) | Parameter menu behind a seal or authorization | Display/printout; no change possible without breaking a seal or creating a record | Operator; verifying body |
Parameter changes and authorization | Access levels, hardware security switch | Per-person authorization, changeable code, online editing of the PLC program blocked | Operator and integrator; national authority under legal control |
Event and alarm log | Internal, non-erasable event and alarm log | Input failures, out-of-range operation and communication loss logged non-erasably and linked to measurement data | Operator; parties in a dispute |
Hourly/daily archive and retention | Periodic and batch reports in non-volatile memory | Archive by contract hour, retention period, sequential deletion, no later alteration | Contracting parties; applicable legislation |
Fault and halt behavior | Separate fault totalizer; last values retained on halt | Valid totalizing stopped, fault quantity kept apart, data retention tested on halt | Vendor/integrator designs; shown at verification |
Software identification and change | Fixed firmware version; may be named in an approval certificate | Version identifier, checksum, change procedure; changes to an approved type notified | Software owner and approval holder; notified body |
Sealing / write protection | Physical sealing point, security switch | Sealable switch or cabinet, electronic seal equivalent, evidence of intervention retained | Verifying body; operator |
Type approval / conformity | Certificate may exist for defined functions and configuration; read its scope | Separate conformity assessment for a PLC-based calculator, or documented provisions accepted by the authority | Applicant (vendor/integrator); notified body or national authority |
Time synchronization | Internal clock; network synchronization option | Single time source, clock-correction log, contract-day rule | Operator; contract |
Communication and data integrity | Result produced in the device; SCADA holds a copy | Field link security, integrity check of transferred data, which record the invoice uses | Integrator and operator; contract |
Why the responsibility boundary matters
With a dedicated flow computer the vendor largely owns the calculation software and protection functions, while the project owns configuration and installation. In a PLC/DCS solution the calculation program, record structure and protection logic are project-specific software owned by the integrator or operator. For type approval, R 140 asks for a description of electronic seals and a software flow chart, and the certificate states, where applicable, the version of the metrological part of the evaluated software; changes to an approved type are notified to the approving body. For a PLC whose program is updated frequently, who carries that burden should be written down from the start.
The WELMEC software guide for the MID (Guide 7.2, advisory) defines built-for-purpose instruments, whose software environment is invariable and which have no means of programming in their embedded state, as type P; if those conditions are not fully met, the system is treated as type U (universal device) and stronger software-integrity measures are expected. The notified body decides how a programmable PLC is assessed, but the distinction shows clearly that modifiability raises the burden of proof.
When is a PLC/DCS a reasonable choice?
· For measurements that are not billing-grade, such as process monitoring, energy management and in-plant allocation.
· For check metering and deviation alarms alongside the custody transfer measurement.
· For moving flow computer results, archives and alarms into SCADA/DCS, and for surrounding functions such as station control and valve operation.
· When the contracting parties explicitly accept the PLC calculation and the evidence in the matrix above (calculation tests, event log, archives, software identification, sealing) is documented.
· When the competent body accepts a PLC-based calculator through conformity assessment or documented provisions.
Unsuitable conditions and limits
· If regulation or the network specification requires an approved volume conversion device or calculator, a PLC calculation outside that approval cannot serve as the billing value.
· If the PLC program can be edited online, no version identifier is kept and changes are not logged, the system cannot be defended in a dispute.
· SCADA history is usually a sampled and compressed copy; unless the contract says otherwise, it does not replace the billing archive.
· A flow computer is not a complete answer either: approval of the calculator does not show conformity of the meter, transmitters, installation or the whole measuring system. Approvals are often tied to a specific configuration, and the certificate's currency and the directive and standard editions it relies on should be checked.
· This article does not replace country-specific legal metrology procedures or contract terms; confirm with the relevant authority and parties.
Example scenario: a dispute at a PLC-calculated station
Example scenario (fictional): at an industrial plant's gas inlet station, pressure and temperature correction is done in a PLC and invoices are prepared from daily totals in SCADA. When the gap to the supplier's volume conversion device grows, the parties want to compare records. The first questions are: which method and composition did the PLC use for compressibility, who last changed the composition and when, did totalizing stop during a transmitter failure, and does the SCADA copy match the PLC archive? If these cannot be answered from records, the measurement stays disputed even if the calculation itself was right.
Data to request for a quotation or review
· Measurement status: process, contractual custody transfer or legal metrological control; relevant contract clauses and network/regulator specification.
· Fluid (natural gas, liquid hydrocarbon, LPG, etc.), quantity to be reported (base volume, mass, energy) and the required calculation method.
· Meter type and signal, pressure/temperature and, where needed, the composition or density source; number of meter runs.
· Existing PLC/DCS/SCADA architecture, protocols to be used and which record the invoice will be based on.
· Archive intervals (hourly, daily, batch), retention period, contract-day start time and time source.
· For existing sites: sample archives and event logs, parameter list, software version and any dispute records.
Related pages
· flow computer solutions for fiscal and custody transfer metering: The flow computer's role in the measurement chain and selection criteria.
· flow computer product page: Technical features of a multi-stream flow computer platform.
· custody transfer natural gas metering stations: The gas measuring system the calculator sits in.
· custody transfer truck loading skids: Sealing, records and audit trail expectations on the liquid side.
· process data for an RMS/PRMS station RFQ: Compiling measurement and calculation data at the gas station quotation stage.