In brief
An RFQ for a medium-voltage grid simulator is a translation exercise: your test matrix, rendered as requirements a vendor can price and you can verify. The working skeleton has seven sections — device and application context, electrical envelope, event and disturbance requirements, interfaces and automation, safety and facility constraints, evidence and acceptance, commercial terms — plus one discipline that improves every section: attach conditions to every number you demand, and require conditions on every number you receive.
Key takeaways
- The RFQ's real function is risk transfer: everything specified verifiably becomes the vendor's problem to deliver; everything vague remains yours to discover.
- Lead with context, not just parameters — vendors configuring megawatt platforms per programme quote better against a described test mission than against a bare number table.
- Specify envelopes, not points: current-versus-voltage, overload with duration, edges at load — the derated corners are where campaigns live and quotes diverge.
- Acceptance is a specification: FAT/SAT protocols, evidence formats and witness rights written into the RFQ cost nothing and buy everything later.
- Expect and design for iteration — the best quotes follow a requirements dialogue, and a vendor who asks sharp questions about your matrix is showing you their engineering.
What an RFQ is actually for
Procurement folklore treats the RFQ as a price-discovery form. For configured megawatt equipment it is something more consequential: the document that decides, months in advance, which risks are the vendor’s and which are yours. A requirement stated verifiably — an edge speed at your load, an overload with its duration, a protection behaviour with its evidence — obliges the quote to price it and the factory acceptance test to prove it; a requirement left implicit (“suitable for ride-through testing”) is priced optimistically, interpreted charitably, and discovered expensively at commissioning. So the drafting mindset this guide assumes: you are not requesting a quotation, you are drafting the technical annex of the eventual contract, and every sentence should survive being read aloud at a FAT with lawyers present. The raw material already exists if you have followed this series: a clause-to-test matrix and the ten-specification gate review contain every technical fact the RFQ needs — the work here is organising them so a vendor can answer precisely and competing answers can be compared honestly.
The seven-section skeleton
The sections form a traceability chain: the device mission determines electrical and event requirements; those determine interfaces, safety and facility scope; and every capability terminates in acceptance evidence. Give each requirement a stable ID so questions, deviations, prices and FAT/SAT records point to the same sentence.
Figure 1. Traceability from test mission to priced requirement and acceptance evidence. This is an RFQ aid, not a supplier hardware architecture.
-
Section 1 — Device and application context
Open with the mission, not the numbers: what device classes will be tested (present and honestly foreseen), against which standards and codes, in what kind of programme (development, compliance, production). Configured platforms are engineered against missions; a vendor who knows the matrix quotes the machine it needs, flags the requirements it questions, and sometimes saves you from your own spreadsheet. Include the growth horizon explicitly — the congenital specifications of the selection guide are bought once — and state what is out of scope, which disciplines quotes as effectively as what is in.
-
Section 2 — Electrical envelope
The constitution, specified as envelopes with conditions: connection and output voltage classes; apparent-power requirement derived per the sizing guide's arithmetic, including the reactive envelope and the current-versus-voltage curve across your derated operating points; quadrant capability with the regeneration question stated (where must absorbed energy go, and what does the facility feed see); frequency range and the RoCoF ramp ceiling; overload requirements as magnitude-duration-current-limit triples. Every figure carries its condition — "at my full load," "sustained for," "at half nominal voltage" — because unconditioned requirements collect unconditioned promises.
-
Section 3 — Event and disturbance requirements
The fidelity section, drawn straight from the matrix: ride-through profile families with required edge classes and recovery-trajectory control; per-phase independence (angle resolution, relative-angle range, single-phase-to-earth continuity where needed); harmonic and inter-harmonic injection (order, per-component amplitude and phase control, delivered spectral accuracy at load); unbalance and point-on-wave requirements; waveform-replay capability (COMTRADE) where field-record regression matters. Reference the standards clauses each capability serves — it lets the vendor map capability to obligation and exposes gaps early.
-
Section 4 — Interfaces and automation
The toolchain the methodology guides showed compounds: control and monitoring interfaces your laboratory can integrate (LAN/RS485-class, with the command surface documented), sequence programming with logged execution, synchronised capture and export formats, and the timebase-synchronisation provisions your evidence discipline requires. State your controller environment and data pipeline so integration is quoted, not assumed.
-
Section 5 — Safety, grounding and facility constraints
The section vendors most need and RFQs most omit: your earthing scheme and required grounding configurability; the protection philosophy and the device-fault behaviour you require (limit-and-continue versus trip, with evidence); interlock and access integration with your laboratory's safety system; and the facility facts — available feed, cooling, floor loading, door and crane constraints, per the planning guide — that determine whether the quoted machine can physically arrive and run. Equipment-safety expectations (the designed-to-meet-versus-certified distinction of the safety guide) are stated here, honestly, in both directions.
-
Section 6 — Evidence and acceptance
The section that pays for itself: required FAT and SAT scope with witness rights; the protocol-agreement process (protocols in writing before the factory date); evidence formats for acceptance and for service (waveforms, logs, calibration traceability per the evidence guide); documentation, training and spares expectations; and the acceptance criteria that convert delivery into completion. A vendor's response to this section — enthusiasm versus evasion — is among the most predictive signals the whole process produces.
-
Section 7 — Commercial terms
Delivery and milestone structure aligned to your facility programme's critical path; warranty and support model (response expectations, remote diagnostics, local presence); spares philosophy; and the change-control mechanism for the requirement evolution that a configured project will experience. Price format matters: itemised against the sections above, so comparison and negotiation happen on engineering, not on totals.
The questions to require answered — in the RFQ itself
| Domain | Question to require answered |
|---|---|
| Architecture | At my voltage, what stands between your power stages and my device's terminals, with its measured frequency response? |
| Envelope | Provide the output current-versus-voltage envelope, and every overload figure as magnitude, duration and current-limit behaviour. |
| Dynamics | Provide a measured full-load voltage transition at my voltage class, and state point-on-wave control capability. |
| Asymmetry | How is per-phase independence implemented, what cross-coupling exists during asymmetric events, and is single-phase-to-earth continuity supported? |
| Power quality | State the conditions behind every accuracy and distortion figure, and the delivered quality into a representative nonlinear load. |
| Regeneration | At full absorption, where does the energy go, at what measured efficiency, and what does my facility feed supply? |
| Protection | Walk through a device-side short circuit at full power: limiting behaviour, restart procedure, and the evidence the event leaves. |
| Evidence | Show the sequence a compliance profile becomes, the log it leaves, and the acceptance-file formats delivered. |
| Failure modes | Define system behaviour on control-link loss, controller failure and network partition — and how each is verified at commissioning. |
Copyable RFQ requirements table
Use one row per requirement and keep its ID through quotation, contract and acceptance.
| ID | RFQ section | Buyer input to complete | Supplier response and evidence required |
|---|---|---|---|
| CTX-01 | Device and application | DUTs, standards and clauses, modes, growth horizon and exclusions. | Assumptions, supported scope, deviations and missing inputs. |
| ELEC-01 | Electrical envelope | Voltage classes; MVA, P-Q and I-V envelopes; frequency, RoCoF and overload triples. | Guaranteed curves with load, voltage, duration and cooling conditions. |
| EVT-01 | Events and disturbances | Sags, swells, interruptions, phase jumps, unbalance, harmonics and recovery trajectories. | Loaded-terminal performance, resolution, repeatability, sequence limits and evidence. |
| AUTO-01 | Interfaces and automation | Controller, protocols, commands, timebase, triggers and record formats. | Interface specification, command coverage, synchronisation and responsibility split. |
| SAFE-01 | Safety and facility | Earthing, protection, interlocks, feed, cooling, floor, route and lifting limits. | Single-line diagram, fault behaviour, utility demands, dimensions and prerequisites. |
| ACC-01 | Evidence and acceptance | FAT/SAT cases, pass criteria, witness rights, repetitions and file formats. | Protocol dates, methods, instruments, evidence index and retest responsibility. |
| COMM-01 | Commercial | Milestones, warranty, support, spares and change control. | Itemised scope, options, exclusions, schedule assumptions and lifecycle costs. |
Use C (complies), D (deviation), O (option) or I (buyer input). Every C needs a quotation, drawing or test-record reference. Freeze the register as a contract annex.
Bid-comparison scorecard
Apply pass/fail gates first: mandatory voltage, safety or evidence failures cannot be averaged away. Set weights before opening offers, score 0 to 5, then calculate (score / 5) × weight.
| Domain | Weight | What earns a high score |
|---|---|---|
| Electrical envelope | 25 | Guaranteed curves at required operating corners. |
| Event fidelity | 20 | Loaded-terminal evidence and stated sequence limits. |
| Safety and facility fit | 15 | Coherent design and quantified site demands. |
| Evidence and acceptance | 15 | Specific methods, raw data and retest process. |
| Automation and integration | 10 | Documented commands, synchronisation and responsibility boundary. |
| Delivery and support | 10 | Defensible schedule, support, training and spares. |
| Whole-life commercial value | 5 | Transparent scope, options, exclusions and lifecycle costs. |
Record each score’s evidence; track deviations separately with an owner and disposition.
FAT/SAT acceptance example
This clause is illustrative, not an MVGS specification. Replace every bracketed value from the project’s test matrix before issue.
AC-EVT-03 — loaded voltage dip. At
[V_nom],[frequency]and[S_test], transition from1.0 puto[V_dip]within[t_edge], hold for[t_hold], then follow[recovery trajectory]. Run[n]repetitions at[point on wave]without unintended protection action. Pass when DUT-terminal voltage meets[amplitude/time tolerances]and the raw waveforms, sequence log, protection states, timebase and calibration references are delivered under AC-EVT-03.
| Stage | Method | Required record |
|---|---|---|
| FAT | Run every repetition at the agreed load using the approved protocol. | Raw results, logs, configuration, calibration, witness sign-off and exception dispositions. |
| SAT | Repeat the nominated subset with final utilities, earthing, interlocks and interfaces. | Site results, safety and interface checks, open-item closure and signed record. |
This separates capability proof from installation proof. Device-specific programmes still need their own matrix; the full-power medium-voltage SST guide lists the other-port, protection and pre-connection checks for an SST bench.
The classic RFQ mistakes
Five patterns account for most procurement grief, and all five are cheap to avoid at drafting time. Peak-number specification: demanding headline figures without durations, loads or voltages — which collects headline answers and defers the real comparison to commissioning; the conditions-attached rule is the entire cure. Spec-sheet transplant: copying another project’s (or a favoured vendor’s) specification wholesale, importing requirements your matrix never exercises and omitting ones it does — the selection guide’s start-from-the-matrix procedure exists precisely against this. Silent facility assumptions: omitting feed, cooling, access and earthing facts, so every vendor quotes a different imaginary building; section 5 exists to make the building real. Acceptance as afterthought: leaving FAT/SAT scope, evidence formats and witness rights to “standard terms,” which means the vendor’s terms; section 6 costs a page and governs the project’s most contentious month. And over-specification: demanding capability beyond the honest matrix “to be safe,” which prices capability you will not exercise and can push otherwise-fit platforms out of the comparison — the honest sections of this knowledge centre are, collectively, a catalogue of where less machine is right, and the RFQ is where that honesty becomes savings.
What the RFQ cannot do
Honesty section. A strong RFQ structures the dialogue; it does not replace it. Configured megawatt platforms are engineered per programme, and the best outcomes follow iteration — a requirements-review conversation, a revised annex, sometimes a visit to the facility — so build the process for one round of refinement rather than treating clarifying questions as vendor weakness; the sharpness of those questions is your best free preview of the engineering you would be buying. Paper answers, however well-conditioned, are verified at FAT — the acceptance section is what converts the questionnaire’s promises into measured facts, which is why it belongs in the RFQ and the contract, not in the commissioning improvisation. And for device-specific programmes — the medium-voltage SST bench being the worked example this series carries — the general skeleton here composes with the application guide’s specific requirements list; the two documents are designed to be stapled together.
Product fit
Where the MVGS fits
An RFQ built on this skeleton gives an MVGS configuration review the inputs needed to map the test matrix to a project-specific electrical envelope. The released product data describes a configurable direct-medium-voltage, four-quadrant regenerative platform, but ratings, event performance, interfaces, facility requirements and evidence deliverables must be confirmed for the quoted configuration. FAT/SAT scope, protocol timing, witness rights and file formats should be agreed in writing at quote stage rather than assumed from product-family literature.
FAQ
Frequently asked questions
How detailed should a first-pass RFQ be?
Complete in structure, honest about maturity: all seven sections present, with firm requirements stated firmly and open questions marked as open — vendors quote better against a document that distinguishes "must" from "under study" than against false precision. Expect one refinement round; the skeleton's job is making that round converge instead of wander.
Should the RFQ name target standards or just parameters?
Both, linked: name the standards and clauses your programme serves, and state the derived parameters with conditions. The linkage lets vendors map capability to obligation, exposes gaps neither side noticed, and future-proofs the document — when an edition revises, the clause reference shows exactly which requirements to revisit.
How do I compare quotes that answer differently?
Through the questionnaire: mandatory questions with conditions attached normalise the answers, and an itemised price format maps cost to capability. Where a vendor's answer lacks conditions, request them before scoring — and weight the acceptance section's response heavily, because enthusiasm for being measured predicts project behaviour better than any single specification.
What belongs in the RFQ versus the contract?
The RFQ's technical annex, questionnaire answers and acceptance protocols should flow into the contract essentially unchanged — that continuity is the point of drafting them verifiably. Purely commercial mechanics (payment schedules, liabilities) are contract territory; but FAT/SAT scope, evidence formats and verified failure-mode behaviour belong in both, because they are engineering requirements wearing legal clothes.
Keep exploring
Related technical resources
Related articles
Selection and Planning
How to Choose a Grid Simulator: 10 Specs That Matter
Voltage class, real vs apparent power, quadrants, edge speed, per-phase independence, harmonics, frequency range, grounding, protection, automation — the ten specifications that decide fitness, and the questions that expose them.
Read article
Grid Simulator Fundamentals
What Is a Grid Simulator? A Plain-English Guide
A grid simulator is a programmable AC source that reproduces grid behaviour — sags, swells, harmonics, ride-through events — for lab testing. What it does, who needs one, and how to spec it.
Read article
Application Test Guides
Grid Code Compliance Testing: 1547, UL 1741, 4777.2
The standards landscape for grid-connected equipment — IEEE 1547/1547.1, UL 1741, IEC 62116, AS/NZS 4777.2 and AEMO requirements — what a campaign contains, and why capability is never certification.
Read article