Two industrial companies sign Core service contracts in the same month. The first sees its drone flying three weeks later. The second waits a good few months.
The difference isn’t the equipment, the technical team or how serious the project is. It comes down to one technical detail in the authorization file: PDRA.
What a PDRA is
For certain standard types of BVLOS operation, EASA has already assessed the risk and published the result as a “predefined risk assessment”. In practice, a ready-made recipe.
If a client’s operation fits one of these scenarios exactly, the operator doesn’t have to reinvent the wheel with a full risk assessment from scratch. It fills in a table already validated by the European authority and builds the operations manual around it.
What the process looks like in practice
It all starts with finding the right scenario in the list published by EASA. For example, a scenario dedicated to linear infrastructure inspections, such as power lines.
Three steps follow:
- filling in the PDRA table, point by point;
- preparing the operations manual, which shows how each requirement is met;
- submitting the file to the civil aviation authority.
Because the template is already known and accepted, both the operator and the authority go through a far more predictable process than a SORA assessment built from scratch.
Why not every operation qualifies
Not every project fits a predefined scenario.
An area with unusual population density, or a sensor type or altitude that doesn’t appear in any of the published scenarios, means the operation has to be fully assessed using the SORA methodology.
Spotting this difference early is part of the technical analysis on any serious project.
How we handle this at DroneFlight
In the use case and ConOps analysis stage of the Entry Level package, we establish from the start whether a project can fit a PDRA scenario or needs a full SORA assessment.
The aim is for the estimated time from contract signature to first authorized flight to be realistic, not just a sales promise.