Building a commissioning and performance testing framework for FSRUs
A structured commissioning and performance test regime is the bridge between "we've built it" and "we can charter it." Here's how to design one that satisfies both the technical reviewers and the commercial counterparties who'll eventually sign off.
The two audiences
An FSRU performance testing framework has to serve two distinct audiences simultaneously. Classification society surveyors and flag-state inspectors care about whether each system meets its design basis and operates within its safety envelope. Charterers and lenders care about whether the vessel can deliver its contractual capacity over the full range of operating conditions — send-out rate, boil-off handling, mooring station-keeping, utility consumption.
These overlap but aren't identical. A unit that passes class acceptance can still fail a charterer's guaranteed-performance clause. A unit that hits its nameplate send-out capacity on a calm day can fail when the metocean conditions approach design extremes.
Structuring by contract reference
The starting point isn't the equipment list. It's the contract — specifically, the Schedule of the Time Charter Party that defines performance warranties. On a typical modern FSRU charter, the relevant schedule enumerates:
- Guaranteed maximum and minimum send-out rates
- Boil-off gas management requirements at defined loading conditions
- Tank cooldown and warming rates for ship-to-ship and ship-to-shore transfers
- Utility consumption limits (fuel gas, electrical import, potable water)
- Mooring system performance under defined metocean scenarios
- Availability and turn-down requirements
Each of these becomes an individual performance test. Name them, number them, and track them as a coherent series. A common working convention is PF-02 through PF-19 — eighteen discrete tests, each with a defined scope, acceptance criteria, witness list, and documentation trail.
Why the numbering matters
Discrete numbered tests let you track closure in a single table. When the contract says "substantial completion requires successful completion of all Performance Tests," you need to be able to point at a single matrix that shows each test number, its status, its acceptance criteria, and any punch items. If your framework has vague groupings instead of numbered discrete tests, that matrix doesn't exist and status meetings become narrative arguments.
Acceptance criteria structure
Every test needs four things defined before it runs:
- Pre-conditions. What state must the vessel be in before the test starts? What systems must be operational, what tanks at what level, what approvals in place?
- Test procedure. The step-by-step operational sequence, including data logging cadence, excursions allowed, and conditions under which the test is to be aborted.
- Acceptance criteria. Quantitative pass/fail thresholds tied directly to contractual language. "Send-out rate ≥ 750 MMscfd sustained for four hours at 90% ambient design condition" is an acceptance criterion. "System operates as expected" is not.
- Deliverables. What document is produced at the end? Who signs it? What happens to it in the commissioning record?
Handling test failures
Tests fail. What matters is how the framework handles failure. A robust framework distinguishes between three outcomes:
- Pass. Criteria met, record closed.
- Conditional pass. Criteria met with minor punch items that don't affect functional performance. The test is considered closed for commissioning purposes, but the punch items are tracked to resolution.
- Fail. Criteria not met. Root cause investigation required. Corrective action, retest, and then reclosure. The original failure record stays in the documentation trail.
The third category is where most projects get into trouble — not because tests fail, but because the documentation of the failure gets lost in the rush to retest. Keep the original failure record visible. It matters for future surveys, insurance discussions, and the first annual survey after delivery.
Witness and sign-off architecture
Who witnesses what, and who signs off, needs to be defined before the first test runs. On a typical FSRU commissioning:
- Classification society surveyor attends tests with direct class implications (ESD functional tests, safety system functional tests, structural load tests)
- Flag state inspector attends tests tied to the certificate of class or certificate of registry
- Charterer's representative attends tests tied to contractual performance warranties
- Shipyard commissioning engineer attends all tests as the party responsible for executing the procedure
- Owner's technical representative attends all tests as the ultimate acceptance party
Getting all five in the same place at the same time is a scheduling discipline, not a technical one. The performance test programme needs to be a published schedule with notice periods defined (typically 48 hours for routine tests, 7 days for major tests requiring specific weather or tidal windows).
The single most important document
At the end of commissioning, the framework produces one document that matters more than any other: the Performance Test Completion Matrix. It's a single table showing:
- Test number and name
- Acceptance criteria (abbreviated)
- Actual performance recorded
- Status (pass / conditional pass / fail-closed)
- Date of test
- Signatory
- Reference to underlying test report
This document is what gets attached to the delivery protocol, referenced in the TCP closing conditions, and cited in any subsequent performance dispute. If it's clear and comprehensive, commissioning closure is administrative. If it's incomplete or contradictory, commissioning closure becomes a negotiation.
Build the matrix first. Build the tests to feed it.