Reliability, maintenance and the real cost of a drone

The purchase is the beginning of the cost

A drone becomes useful when an organisation can repeatedly obtain the required result from it. Buying the vehicle is only part of that ability. People, training, consumables, repairs, software, communications, data handling and supporting equipment can all determine whether it is available when needed.

This is why a unit price can be a poor basis for comparison. One offer may cover a bare vehicle; another may include control stations, payloads, spares and training. Dividing a package value by the number of aircraft can create an apparent price that does not represent what another customer would pay for an equivalent capability.

Follow the whole operating cycle

The cycle matters across domains. Aircraft need preparation and checks; ground robots need maintenance of their moving parts; underwater systems require handling and attention to seals and exposure. The details differ, but all depend on support that a specification sheet may barely mention.

It is also important to define the result being counted. An hour powered on is not necessarily an hour collecting acceptable data. A survey may need repeating because of poor observations, a missing position reference or an unusable file. Useful output includes quality and completion, not simply activity.

What availability actually tells you

Availability asks whether equipment can be used when required. It is influenced by failures and by how long it takes to diagnose and resolve them. A comparatively rare fault can be disruptive if a replacement part or qualified technician takes weeks to obtain. Frequent minor work can also reduce output if it consumes the same people needed for operations.

GAO's 2022 review of 49 military aircraft types describes the relationship between mission-capable rates, maintenance challenges and parts support [1]. It is historical fleet-level evidence, not a current readiness estimate for all drones. Its relevance is the demonstrated need to look beyond aircraft performance to the organisation that sustains it.

Worked example: two fictional inspection systems

Suppose System A costs 20,000 units of currency and System B costs 28,000. Those invented purchase prices alone favour A. Over an equally defined evaluation period, however, A's complete cost is 40,000 for 100 accepted inspections, while B's is 45,000 for 150 accepted inspections. That gives 400 and 300 per accepted inspection respectively.

The example is deliberately simple and is not a market price estimate. It shows why the denominator matters. A lower acquisition cost can coexist with a higher cost per useful result. Change the workload, support assumptions or acceptance criteria and the ranking could change again.

The same calculation should not be used to conceal quality differences. If one inspection standard is easier, the outputs are not equivalent. The first requirement for a useful comparison is a common definition of success.

Software is a continuing support obligation

Software requires maintenance alongside hardware. Versions must remain compatible across the vehicle, payload and control station; faults need correction; updates need assessment and records. Access rights, subscriptions and supplier support arrangements can affect whether the owner remains able to use equipment already purchased.

GAO's 2019 work on software sustainment found difficulties in capturing and reporting those costs [2]. This is a historical example of an accounting problem, not evidence that every current drone programme has the same deficiency. It nevertheless explains why omitting software from a lifetime-cost estimate can leave a material gap.

Repairability and modularity are related, but different

A removable component may be easy to replace without being inexpensive or readily available. Repairability also depends on diagnosis, documentation, tools, qualified personnel and the supply of accepted replacements. A modular design is useful when that supporting chain exists.

Similarly, a supplier's demonstration of a rapid swap may omit the time required to identify the fault, obtain the part and verify the repair. An honest turnaround measure defines its start and end. Otherwise two apparently similar maintenance figures may describe very different processes.

What a support package should make understandable

• The equipment, software and services included in the price, and the period covered.
• Who performs routine work and specialist repairs, with the required training and tools.
• How spare parts, consumables and replacement energy stores are supplied.
• Which data can be exported and which functions depend on continuing licences or services.
• How availability, completed work and unsuccessful attempts are recorded.

These are comparison questions, not a universal procurement template. Different users and systems require different support arrangements. The value lies in exposing assumptions before treating unlike packages as equivalent.

Is the cheapest vehicle the most economical capability?

Sometimes, but the purchase price cannot establish that. A modest system that is easy to support may be the best fit for a limited task. A more expensive system may justify its cost by delivering better output or reducing repeat work. The assessment should use the same task, period and quality standard for each.

What makes a convincing trial?

Repeated work by the intended users is more informative than a single polished demonstration. Record accepted results, interruptions, maintenance and the support actually provided. A drone's practical value emerges over that cycle, when performance claims meet ordinary operating demands.

Suggest a correction to this entry