A requirement written as “thermal camera with long detection range” guarantees incomparable bids, because every vendor will answer with the definition that flatters their product. Requirements become comparable the moment you state the condition alongside the value.
Key takeaways
- A value without its condition is not a requirement. “Long detection range” guarantees incomparable bids because every vendor answers with the definition that flatters their product.
- Compare range figures only when the sensor channel, target size, task definition and test conditions are stated. Johnson-based thermal DRI and visible-camera DORI are not interchangeable, and there is no universal conversion factor between them. Use the model-specific source document and validate the required task under your operating conditions.
- Separate must-have from nice-to-have honestly; padding the mandatory list narrows the field without improving the outcome.
- Include verification clauses and a scoring scheme, or the requirements are unenforceable after award.
On this page
The rule: never state a value without its condition
Every performance number in a thermal payload requirement should carry three parts: the value, the condition it is measured under, and the verification method. “Detection range ≥ 800 m” is gameable. “Recognition of a 0.75 m critical dimension target at ≥ 500 m under EN 62676-4:2015, verified by field trial against a calibrated target” is not.
This single discipline eliminates most of the ambiguity in payload tendering, and it costs nothing but precision in drafting.
Requirement lines you can reuse
| Requirement area | Weak wording | Wording that cannot be gamed |
|---|---|---|
| Thermal resolution | “High resolution thermal” | Native detector array ≥ 640 × 512, upscaled output not accepted |
| Sensitivity | “Low NETD” | NETD ≤ 40 mK at 25 °C, f/1.0, at operating frame rate |
| Range | “Long detection range” | Recognition of 0.75 m critical dimension ≥ 500 m per EN 62676-4:2015 |
| Frame rate | “Real-time video” | Native ≥ 25 Hz thermal, end-to-end displayed rate stated |
| Zoom | “120x hybrid zoom” | Optical zoom ≥ 20x; long-end focal length stated in mm |
| Stabilisation | “3-axis stabilised” | ≤ 0.02° RMS in flight, all three axes, stated vibration environment |
| Radiometry | “Temperature measurement” | Radiometric, ±2 °C or ±2 % accuracy, emissivity and distance settable |
| Mass | “Lightweight” | Installed mass ≤ X g including control unit, cabling and mount |
| Power | “Low power” | Peak draw ≤ X W with ranging and tracking active |
| Environmental | “Weatherproof” | IP54 minimum for full assembly including mated connectors |
| Interface | “MAVLink compatible” | MAVLink gimbal protocol v2, documentation supplied without NDA |
| Support | “Full support” | Repair turnaround ≤ X working days; spares available ≥ 5 years |
Separate must-have from nice-to-have honestly
Over-specifying is as damaging as under-specifying. A requirement list where everything is mandatory either produces no compliant bids or produces one, from the vendor whose product the list was written around — which is usually visible to everyone and undermines the process.
Split the requirement into mandatory performance, scored performance and informational. Mandatory should contain only what the mission genuinely cannot work without. Everything else belongs in scoring, where a vendor can trade strength in one area against another.
Be especially careful with mandatory numbers that no product meets. Requiring 0.01° stabilisation and sub-250 g installed mass and 40x optical zoom describes a product that does not exist, and the tender will fail on its own terms.
Verification clauses that matter
- Field trial against a calibrated target. Reserve the right to verify the two or three performance claims the mission depends on. State the target, the distance and the pass criterion in advance.
- Installed configuration test. Verify mass, power and stabilisation on the actual aircraft, not on the bench.
- Interface demonstration. Require control from the autopilot and ground software you actually use, before award.
- Documentation delivery. Protocol and integration documentation delivered at award, not after — this is the clause most often skipped and most often regretted.
- Sample report. For measurement work, require a sample deliverable produced by the payload so you can judge the output, not the specification.
Related reading
Method: how to read a spec sheet, choosing without spec noise and warranty and lifecycle clauses.
Technology: how DRI is calculated — read this before writing any range requirement.
Scoring that rewards the right things
Once mandatory requirements are minimal and precise, the scoring model decides the outcome. Two failure patterns are common: weighting everything equally, which lets a vendor win on trivia; and weighting price so heavily that support quality becomes irrelevant.
A model that works in practice puts roughly half the weight on the two or three performance parameters the mission genuinely depends on, a quarter on supportability, and the remainder on price and delivery. Supportability deserves real weight because it is where five-year cost actually lives — repair turnaround, spares commitment and firmware support period are all scoreable and all more predictive of satisfaction than a marginal difference in detection range.
State the weights in the tender documents. Vendors then optimise their bids toward what you actually value, which is the point of the exercise, and unsuccessful bidders can see why they lost.
- Mission-critical performance: ~50 % — the two or three parameters that decide whether the job is possible.
- Supportability: ~25 % — repair turnaround, spares period, firmware commitment, documentation.
- Price: ~15 % — five-year cost, not purchase price.
- Delivery and transition: ~10 % — lead time, training, integration support.
- Publish the weights. Bids improve when vendors know what is being measured.
FAQ
Why do bids come back incomparable?
Because values were stated without conditions. Detection range, minimum illumination and NETD all have several legitimate definitions, and each vendor answers with the one that suits their product. Stating the standard and the measurement condition removes the ambiguity.
Should everything be a mandatory requirement?
No. Over-specifying either eliminates all bidders or points at one product, which undermines the process. Keep mandatory requirements to what the mission truly cannot work without and score the rest.
Is a field trial worth the delay it adds?
For the two or three specifications your mission actually depends on, yes. Paper comparisons are decided by whoever writes the better datasheet; a trial against a known target at a measured distance is decided by the hardware.