Obtaining your Drone operations approved in the specific category is a rather complex endeavor and might cost you a highly valuable time if you have not been dealing with Specific Operational Risk Assessments (SORAs) so far. Even for more experienced aviation professionals, the SORA might be a complex methodology to use. After gathering three years of practical experience with SORAs at the Federal Office of Civil Aviation (FOCA).
Here are my 10 tips to have a high quality SORA portfolio ready for your Civil Aviation Authority (CAA) and, therefore, to save valuable time in the authorization process
1. Versioning and Document Management System
Before you write many documents, make sure to version them correctly and to have the current version data recorded on the document. Usually the documents are modified over time, and it can rapidly become a mess for you and for the competent authority to know which version applies and when.
In this context, it makes complete sense to create a Master Data List which consists in a list of all the documents belonging to your current submission with their versions, with their dates, and with one clear name for every document which is used throughout all the documents that you are submitting. The application should at least contain an application form, the SORA and your Operations Manual. Depending on your Specific Assurance and Integrity Level (SAIL), the submission will require many more pieces of information (Maintenance Manual, Human Machine Interface Evaluation etc..) which may or may not be directly integrated into your Operations Manual.
2. Definitions
Before substantiating your ground risk, air risk, mitigations, Operational Safety Objectives (OSOs) and adjacent airspaces, it might make sense to have a deeper look at the definitions and get a full understanding of the concepts below:
- VLOS, BVLOS, EVLOS, and especially what that means for the pilots and the crew.
- The flight geography, the contingency volume, and the ground risk buffer. Make sure that you understand those definitions and what they mean in the context of the SORA and how they relate to each other. You will need to define those in the context of your operations and develop associated procedures.
- The adjacent airspaces and areas and how those relate to the ground risk buffer. Some CAAs consider the adjacent airspaces as the ones just neighbouring the ground risk buffers. Others will consider all airspaces and areas where the drone could theoretically enter in the case of a fly-away at maximum cruise speed and with full autonomy. Make sure to understand this concept well and to understand its meaning for your operation.
- The difference and relation between integrity and assurance will also matter to a large extent, since a requirement always consists of those two building blocks. The integrity will tell you what is required while the assurance will tell you how you have to demonstrate it (method of proof).
3. Which Requirements are You Ready to Fulfill?
Most people think about the SORA as a methodology that applies for a very specific location. In reality, the requirements that you are able to fulfill will inform you about which ground and air risk is acceptable for your operation. It is of high importance to familiarise yourself with the concept of SAIL (Specific Assurance and Integrity Level).
The higher the SAIL, the more stringent the operational and technical requirements. In general, if you make a ground risk and air risk analysis and you end up with a SAIL IV, V, or VI, then it is time to ask yourself and the rest of the company whether you are ready to go through several years of a costly aviation certification process or whether you need to reconsider where you want to operate in order to lower your SAIL associated requirements?
4. The Adjacent Airspaces and Areas
In general, the SORA at low and medium SAILs is intended for a locally low or medium risk and you will need to demonstrate that you are able to stay in this operational volume with a local low or medium risk. Here the analysis of your adjacent airspace and areas (SORA Step 9) will be rather important to your CAA. This step is very often forgotten but is one of the most important of the entire SORA process since it will inform you and your CAA on what risk-based design requirements will apply for your operation in order to hinder fly-away and have an airworthy operation for low and medium risk operation (SAIL I to IV).
5. The Air and Ground Risk
If you want to operate at low or medium SAIL, you will want to chose a location with a low or medium air or ground risk. In order to do so, you will have to understand what sparsely populated or populated areas mean in the country where you intend to fly. You should familiarise yourself with how the local CAA understand those notions. For the air risk, the assessment is usually rather complex due to the different airspace users. Make sure to carefully look at the local airspace situation and consider every aspect in your airspace assessment (CTR, TMA, gliders, aerodromes, heliports, Helicopter Emergency Medical Service etc..). Do not forget that if you intend to fly above 500 ft AGL without mitigations, this will represent an Air Risk Class c and thus a SAIL IV !
6. The Mitigations
It seems tempting to use a mitigation (especially M1) or another to lower your SAIL. Remember that those mitigations mean an important risk reduction which has to be thoroughly substantiated. It might also not be applicable in every context. To prove your ground risk mitigations as well as your tactical mitigations performance requirements, it is convenient to use a compliance matrix. The compliance matrix is a table which includes the robustness level, the associated requirements from the SORA Annexes, as well as your compliance means and, therefore, eases the evaluation work of the CAA.
7. The Specific Assurance and Integrity Level
Understanding which requirements from the SORA apply using the Operational Safety Objectives(OSOs) Table might seem exhausting and fulfilling them might seem like a heavy burden. However, this is the main part of the SORA since it will address technical and organisational requirements such as organisational structure, maintenance, training, procedures, checklists, human errors, external systems etc..
Make sure to get professional aviation support if you do not understand a requirement or another. If you do not intend to build your drone after specific standards and would like to remain at low SAILs then you should make sure that you are able to fulfill the requirements at low SAIL, which are not always straight forward neither. To demonstrate compliance with the requirements, you might want to use a compliance matrix system for the OSOs as well.
8. Self-Declaration
I often hear that low robustness level is self-declared. However, this strongly depends on the requirement and its associated assurance robustness level. The SORA indicates by no means that low robustness level is always self-declared. If you look further into the documents (SORA Annex B or Annex E), there are plenty of low robustness level OSOs which do not have a self-declared assurance (OSO 20 or OSO 3 for instance). Furthermore a self-declaration has legal implications so make sure that you do fulfill a requirement before self-declaring it.
9. Do Not Overdocument
I have emphasized the importance of the management of the documents. I would like to emphasize that obtaining the authorisation is by no means the end of the entire process. In reality, it is just the beginning. After you get the authorisation, you will need to ensure compliance with your documentation throughout the entire operations life cycle. There will probably be audits and at some point if you have regular operations, you might experience incidents or accidents as well.
The operations should routinely take place as described in the Operational Manual (OM) and in the SORA but it makes sense to ensure that the documentation includes procedures which can easily be put in practice by the crew. Sometimes, companies would like to show professionalism by fulfilling more requirements than what is required. In practice, this however means more costs and more administrative burden to keep the documentation up to date. Keep it simple!
10. Manage Your Changes
Changes do occur and they happen frequently (locations, UAS, firmware, etc.). Keep this in mind when writing your documentation, and keep in mind that you will have to deal with those changes in a structured manner to ensure that the OM and SORA reflect your operations.
Nathanel Apter
UAS Engineer, CEO and Founder
nathanel.apter@uasolutions.ch
www.uasolutions.ch
English
