UAS.SPEC.030 Application for an operational authorisation

APPLICATION FORM FOR AN OPERATIONAL AUTHORISATION The UAS operator should submit an application for an operational authorisation according to the following form. The application and all the documentation referred to or attached to the application should be stored for at least 2 years after the expiry of the related operational authorisation or submission of application in case of refusal. The UAS operator should ensure the protection of the stored data from unauthorised access, damage, alteration, and theft. The declaration may be complemented by the description of the procedures to ensure that all operations are in compliance with Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, as required by point UAS.SPEC.050 (1)(a)(iv) of the UAS Regulation.

EASA Form 208 Instructions for filling in the application form If the application relates to an amendment to an existing operational authorisation, indicate the number of the operational authorisation and fill out in red the fields that are amended compared to the last operational authorisation. Section 1

1.1 UAS operator registration number in accordance with Article 14 of the UAS Regulation.

1.2 UAS operator’s name as declared during the registration process.

1.3 Contact details of the person responsible for the operation, in charge to answer possible operational questions raised by the competent authority. Section 2

2.2 Date on which the UAS operator expects to end the operation. The UAS operator may ask for an unlimited duration; in this case, indicate ‘Unlimited’.

2.3 Select one of the three options. If the SORA is used, indicate the edition date as defined in AMC1 Article 11. In case a PDRA is used, indicate the number and its edition date as defined in the applicable AMC to Article 11. In case a risk assessment methodology is used other than the SORA, provide its reference. In this last case, the UAS operator should demonstrate that the methodology complies with Article 11 of the UAS Regulation. In case a PDRA is used, then section 4 of this form is not required to be completed.

2.7 If the UAS flight manual provided by the UAS designer indicates that it is designed with a level of automation that reduces the remote pilot’s workload allowing one remote pilot (RP) to control multiple UA simultaneously, then specify the number of UA that one remote pilot is permitted to control (e.g. in case one RP is able to control simultaneously five UA, indicate RP:UA 1:5). This number should not exceed the limit defined in the UAS flight manual. Additionally, the UAS operator may decide to have a pool of remote pilots controlling multiple UA simultaneously. In this case, clear procedures should be developed to define who is the pilot-in-command, responsible during each phase of the flight (e.g. in case three RPs are permitted to control simultaneously ten UA, indicate RP:UA 3:10).

2.8 Indicate the OM’s identification and revision number.

2.9 Indicate the compliance matrix file identification and revision number (e.g. the compliance matrix defined in Chapter A.4 of Annex A to AMC1 Article 11 (SORA). This document should be attached to the application. Section 3 This section may be replicated for all authorised UAS models to be used under this operational authorisation.

3.2 Model of the UAS as defined by the design organisation in the UAS flight manual.

3.3 Fixed-wing UA includes configurations such as aeroplanes, kites, gliders, etc.). Rotorcraft-helicopter UA includes all vertical-lift configurations having up to 2 rotors. Rotorcraft-gyroplane UA is a special configuration with unpowered rotor. VTOL-capable aircraft (VCA) UA includes vertical-lift configurations with 3 or more rotors and fixed-wing UA capable of vertically taking off and landing. Lighter-than-air configurations include configurations such as airships, hot-air balloons, etc.

3.4 Indicate the maximum dimensions of the UA in metres (refer to definition I.141 ‘UA characteristic dimension’ in Annex I of AMC1 Article 11 (SORA)).

3.5 Indicate the maximum value of the UA take-off mass (TOM), expressed in kg, at which the UA may be operated. All flights should be conducted without exceeding the specified TOM. The TOM may be different from (however, not exceeding) the MTOM defined by the UAS design organisation in the UAS flight manual.

3.6 Maximum operational airspeed, expressed in m/s and kt in parentheses, that the remote pilot will not exceed during the operation. This should always be lower than the maximum defined in the UAS flight manual.

3.7 Indicate the type of C2 link to be used during the operation (e.g. radio link, LTE/5G, satellite, etc.).

3.8 indicate the size in km to be considered for the adjacent ground area starting from the limits of the ground risk buffer, using the instructions defined in Section S.4.8.4 of AMC1 Article 11 (SORA).

3.11 This field is mandatory if the UA is registered according to Article 14(7) of Implementing Regulation (EU) 2019/947. If the UA is not registered, the NAA may indicate the unique serial number (SN) of the UA defined by the design organisation according to standard ANSI/CTA-2063-A-2019, Small Unmanned Aerial Systems Serial Numbers, 2019. In case of privately built UAS or UAS not equipped with a unique SN, insert the unique SN of the remote identification system. For UAS operations classified in SAIL V or higher, the serial numbers of all UAS should be provided and any change to them would require the competent authority’s prior approval. For UAS operations classified up to SAIL IV, a change to the serial number does not require a prior approval from the competent authority.

3.12 Include the EASA TC number, or the UAS design verification report (DVR) number issued by EASA, if applicable.

3.13 If a UAS with an EASA TC is required by the competent authority, the UAS should have a certificate of airworthiness (CofA).

3.14 If a UAS with an EASA TC is required by the competent authority, the UAS should have a noise certificate.

3.15 Multiple options are possible. Direct remote ID developed according to EN 4709-002. In order to compile Section 4, please refer to AMC1 Article 11 (SORA). Section 4 Step #1.1: The identification of the location(s) should contain the full operational volume and ground risk buffer (the red line in Figure 1; refer to Annex A to AMC1 Article 11 for guidance and examples on the calculation of the operational volume and ground risk buffer). Depending on the initial ground and air risk classification determined using the SORA process and on the application of mitigations, the location(s) may be ‘generic’ or ‘precise’ (refer to GM2 UAS.SPEC.030(2)). [Figure or form omitted from this preview — available in the Avioverse workspace library.] Figure 1 — Operational area and ground risk buffer — Please, refer to GM2 UAS.SPEC.030(2) for guidance on the conditions to apply for ‘generic’ versus ‘precise’ locations. — If location-specific: please, provide a list with the geo-coordinates for each location including the operational volume (flight geography and contingency volume), the ground risk buffer and the air risk buffer (if available) as a separate file using either ‘.txt’, ‘.kmz’ or ‘.kml’. — If location-independent: please, provide a reference to the documented process for the determination of volumes and buffers and the assessment of the local conditions and their compliance limitations. An example of a geographical file (e.g. ‘.kmz’ or ‘.kml’) may be provided to show a typical operational volume, ground risk buffer and the air risk buffer (if available). Step #1.2: Insert, for example, transport, inspection, filming, testing, etc. Step #1.3: Please, provide a list with this information if location-specific with multiple locations. Step #4.1: For information on the airspace classification, refer to Article 2 and to points SERA.6001 and SERA.6005 of Regulation (EU) No 923/2012. Step #9.1: List the OSOs and the level of robustness you intend to comply with. The level of robustness should as a minimum reflect the one defined in Table 14 of Section S.4.9.3 of AMC1 Article 11 considering the SAIL listed in point ‘Step #7.1’ of this form. SECTION 5 Free-text field for the addition of any relevant remark. Note: The signature and stamp may be provided in electronic form.

SIGNIFICANT CHANGES TO THE OPERATIONAL AUTHORISATION

(a)Any non-editorial change that affects the operational authorisation, or affects any associated documentation that is submitted to demonstrate compliance with the requirements established for the authorisation, should be considered to be a significant change.

(b)With regard to the information and documentation associated with the authorisation, changes should be considered to be significant when they involve, for example:

(1)changes in the operations that affect the assumptions of the risk assessment;

(2)changes that relate to the management system of the UAS operator (including changes of key personnel), its ownership or its principal place of business;

(3)non-editorial changes that affect the operational risk assessment report;

(4)non-editorial changes that affect the policies and procedures of the UAS operator; and

(5)non-editorial changes that affect the OM (when required).

APPLICATION FORM FOR AN OPERATIONAL AUTHORISATION Depending on the level of the risk of the operation, the technical characteristics of the UAS may play an important role in mitigating the risk. In that case, the UAS operator may provide additional information to the NAA on the characteristics of the UAS to be operated. The NAA will, in any case, ask for additional data when needed. As an example regarding how to structure the additional information, the UAS operator may supplement the application for the authorisation with the additional elements shown below. Elements from the example may be added or removed as required.

(1)PAINT Describe any painted elements that are visible (marks) and significant (colour, shape, etc.).

(2)LIGHTS Describe the lights, including their colours and locations.

(3)PROPULSION Mark the type of propulsion used, indicating (in the space provided) the manufacturer and model, and detailing relevant information such as the number of motors/engines, the configuration, etc. Powerplant design diagrams may be attached if necessary.

(4)CONTROL AND/OR POSITIONING SYSTEM As a general instruction for this section, in addition to the description and information deemed necessary to define these systems, provide any certification and rating for the systems, such as those related to electromagnetic compatibility or any other European directive satisfied by the equipment installed on the aircraft, for consideration during the specific risk assessment conducted using the specific operations risk assessment (SORA) or any other risk assessment methodology that is followed to evaluate and authorise operations.

(5)FLIGHT CONTROLLER Indicate the manufacturer and model of the flight controller. Describe the relevant aspects affecting flight safety.

(6)FLIGHT TERMINATION SYSTEM Describe and include the technical characteristics of the system, its modes of operation, system activation and any certification and rating for the components, as well as proof of its electromagnetic compatibility for consideration during the SORA or any other risk assessment methodology that is followed to evaluate and authorise operations.

(7)FLIGHT MODES Describe the flight modes (i.e. manual, artificial stability with controller, automatic, autonomous). For each flight mode, describe the variable that controls the aircraft: increments in position, speed control, attitude control, type of altitude control (which sensor is used for this purpose), etc.

(8)GROUND CONTROL STATION For ‘encrypted’ links, describe the encryption system used, if any.

(9)PAYLOAD Describe each of the different payload configurations that affect the mission or that, without changing it, impact the weight and balance, the electrical charge or the flight dynamics. Include all relevant technical details. If needed, you may use other documents that provide the specified details.

(10)OPERATION LIMITS Describe in this section the maximum operating height, the maximum airspeed (including Vmax ascent, Vmax descent and Vmax horizontal), and, in addition, the meteorological limit conditions in which the UAS can operate (e.g. rain, maximum wind, etc.)

(11)SAFETY SYSTEMS/SAFETY NETS AND AWARENESS Describe the systems or equipment installed on the aircraft to mitigate potential operational safety risks, whether included in the form or not.

‘GENERIC’ VERSUS ‘PRECISE’ OPERATIONAL AUTHORISATION According to Article 12 of the UAS Regulation, a competent authority may decide to grant a ‘generic’ operational authorisation, i.e. an operational authorisation that is applicable to an indefinite number of flights taking place in locations generically identified, during the period of validity of the operational authorisation. (Contrary to the ‘generic’ operational authorisation, an operational authorisation that is limited to the number of flights and/or to known locations identified by geographical coordinates will be called ‘precise’ operational authorisation.) CONDITIONS FOR ISSUING A ‘GENERIC’ OPERATIONAL AUTHORISATION A ‘generic’ operational authorisation does not contain any precise location (geographical coordinates) but applies to all locations that meet the approved conditions/limitations (e.g. density of population of the operational and adjacent area, class of airspace of the operational and adjacent area, maximum height, etc.). The UAS operator is responsible for checking that each flight they conduct: meets the mitigations and operational safety objectives derived from the SORA and the requirements listed in the operational authorisation; and takes place in an area whose characteristics and local conditions are consistent with the GRC and ARC classification of the SORA as approved by the NAA. The UAS operator should anyhow check whether their MS has published a geographical zone in the area of operation according to Article 15 of the UAS Regulation, requiring a flight authorisation (e.g. this may be the case for the areas covered by U-Space). A flight authorisation should not be confused with an operational authorisation. The criteria to determine whether a UAS operator is eligible for a ‘generic’ operational authorisation are the following:

1.The limitations regarding the operational scenario, the operational volume and the buffers defined by the operational authorisation are expressed in such a way that it is simple for the UAS operator to ensure compliance with those limitations. It will usually be easier for the UAS operator to ensure compliance when the conditions are unambiguous and not open to interpretation. This is the case, for instance, when: a controlled ground area is required, or the density of population is very low; the operation takes place in segregated airspace. In this regard, ‘generic’ operational authorisations may be relevant for operations conducted according to PDRA-Sxx, since the conditions are similar to the ones of the declarative STS and it is relatively easy for the UAS operator to ensure compliance with those conditions. As a rule of thumb, a ‘precise’ operational authorisation rather than a ‘generic’ one may be more appropriate when the iGRC ≥ 4 or the iARC ≥ ARC-c.

2.The strategic mitigation measures, if any, are not open to interpretation or difficult to implement. The use of some strategic measure mitigation (M1 for GRC or Step 5 for ARC) often prompt debate between the UAS operator and the NAA regarding the relevance/validity of the data sources (density of population, density/type of traffic in given airspace, etc.), and the efficiency of the proposed strategic mitigation measures. Furthermore, some of these measures are difficult to implement and it is not always possible for the NAA to simply trust the capacity of the UAS operator to do so. For instance, the following examples show measures that are difficult to implement / open to interpretation: achieving a local reduction of the density of population; ensuring the absence of uninvolved persons in very large, controlled ground areas, or reserving large, controlled ground areas in densely populated environments; starting an operation in airspace that requires a new protocol with the ANSP/ATSP, etc. Note: In the future, qualified service for strategic deconfliction (U-space) may be a valid mitigation measure for a ‘generic’ operational authorisation.

3.The NAA has assessed the capacity of the UAS operator to identify/assess the local conditions The UAS operator should have a diligent and documented process to identify/assess the local conditions and their compliance to the limitations given by the authorisation (in the operations manual (OM)). The UAS operator should train its personnel to assess the operational volume, buffers and mitigations in order to prepare for the next operations. The UAS operator should also document and record the assessment of locations (e.g. in mission files), so that adherence to this process can be verified by the NAA on a regular basis. For simple operations where Criteria 1 and 2 are met, the NAA may decide to issue the ‘generic’ operational authorisation first and assess the robustness of the procedures through continuous oversight. For complex operations where Criteria 1 and 2 are not met, then the third criterion is paramount. While the NAA may be confident enough to directly issue a ‘generic’ operational authorisation, it may also decide to add some restrictions for the locations that are valid for the first one (or more) operations. The UAS operator should provide evidence to the NAA that the process defined in Criterion 3 has been followed, and the area and local conditions identified by the UAS operator comply with the authorisation. The NAA will review the evidence (as for a ‘precise’ authorisation) and confirm in written to the operator that their analysis is satisfactory. Once the NAA has enough evidence or confidence that the UAS operator is able to complete the assessments on its own, the restrictions on the location may be withdrawn. Eventually, a LUC may be appropriate to demonstrate this capacity (see below). DIFFERENCES BETWEEN A ‘GENERIC’ OPERATIONAL AUTHORISATION AND A LUC An operational authorisation where the locations are generically identified may to some extent be traced to some privileges granted to a LUC holder: the UAS operator can schedule new flights without receiving a new operational authorisation for each of them. However, a LUC offers more flexibility than a generic operational authorisation by allowing a UAS operator to have different level of privileges, including the possibility to start new types of operations or use previously non-validated types of UASs. On the other hand, a ‘generic’ operational authorisation does not require the UAS operator to formally implement a management system. Such a management system would be disproportionate for low-risk operations (such as PDRA-Sxx) (see Criterion 2). However, the more requirements are derived from the SORA and the conditions of the operational authorisations are difficult to check and to comply with, the more robust and reliable the processes and the organisation of the UAS operator need to be to ensure the absence of deviation. Eventually, a LUC becomes necessary when the risk of deviation from these procedures is high and when deviating from the validated conditions greatly increases the risk of the operation. The LUC management system will be needed to ensure compliance with the procedures of the UAS operator through an independent process. In this regard, a LUC may be more relevant than a ‘generic’ operational authorisation in the following cases: for SAIL ≥ 4 operations (due to OSO#1 ‘Ensure the UAS operator is competent and/or proven’ with a ‘high’ level of robustness); or for SAIL ≥ 3 operations, when strategic ground risk mitigation (M1) or strategic air risk mitigation (Step 5) is applied, to make sure that the applicant exhibits the right safety culture to perform a location risk assessment.

OPERATIONS MANUAL For all operations classified in the ‘specific’ category, the UAS operator should develop an OM structured according to Chapter A.3 of Annex A of AMC1 Article 11. The OM should be submitted to the competent authority for operations classified in SAIL III and higher. For operations classified in SAIL I or II, please refer to AMC1 Article 12(2)(a).

OPERATIONAL PROCEDURES WITH ‘MEDIUM’ AND ‘HIGH’ LEVEL OF ROBUSTNESS

1.Scope of this AMC

1.1 This AMC addresses the criteria for the ‘medium’ and ‘high’ level of robustness of the operational procedures that are required under the OSO #08: Operational procedures are defined, validated and adhered to. These criteria may be used to also address the criteria for the ‘medium’ and ‘high’ level of robustness of the operational procedures required in other sections of the SORA (e.g the mitigations for the ground risk defined in Annex B to AMC1 Article 11 or for the air risk defined in Annex D to Article 11.

2.Criteria for the level of integrity

2.1. Criterion #1: Procedure definition

2.1.1. Annex E to AMC1 Article 11 provides the minimum elements that the operational procedures need to appropriately cover for the UAS operations.

2.1.2. Chapter A.3 of Annex A to AMC1 Article 11 provides an example of an operations manual structure and a table referencing each OM chapter with the OSOs the requirements refer to.

2.2. Criterion #2: Consideration of potential human error Operational procedures should be developed to minimise human errors:

(a)each of the tasks and the complete sequence of the tasks of a procedure should be intuitive, unambiguous, and clearly defined;

(b)the tasks should be clearly assigned to the relevant roles and persons, ensuring a balanced workload; and

(c)the procedures should adequately address fatigue and stress, considering, among other aspects, the following: duty times, regular breaks, rest periods, the applicable health and safety requirements in the operational environment, handover/takeover procedures, responsibilities, and workload.

2.3 Criterion #3: Emergency response plan (ERP) For more information regarding the ERP procedure, the UAS operator should refer to AMC3 UAS.SPEC.030(3)(e).

3.Criteria for the level of assurance

3.1. The purpose of the validation process described in this AMC is to confirm whether the proposed operational procedures are complete and adequate to ensure the safe conduct of the intended UAS operations.

3.2. The validation process should include the following:

(a)a review of the completeness of the procedures to ensure that:

(1)all elements that are indicated in points 2.1.1 and 2.1.2 have been addressed; and

(2)all relevant references have been considered, including but not limited to:

(i)the applicable regulations;

(ii)the requirements from the competent authority and/or other relevant authorities or entities;

(iii)the local requirements and conditions;

(iv)the available recommended practices for the intended type of UAS operations;

(v)the instructions from the UAS designer and of any other UAS equipment designer, if applicable;

(vi)the instructions and requirements from externally provided services that support the UAS operations, if applicable;

(vii)the results from previous experience, including tests and/or simulations as those indicated in point (c) and (d); and

(viii)consensus-based voluntary industry standards;

(b)an expert judgement to assess the adequacy of the procedures based on:

(1)the objective(s) of each procedure;

(2)relevant key performance parameters/indicators and/or benchmarking of options, if applicable;

(3)an assessment of the procedures’ complexity in accordance with point 2.2; and

(4)an assessment of the effect of human factors on procedures in accordance with point 2.2;

(c)a proof of the adequacy of the procedures through tests or practical exercise for phases of the UAS operation other than the UA flight, which involve the UAS and/or any external system that supports the operation;

(d)a proof of the adequacy of the contingency and emergency procedures through:

(1)dedicated flight tests conducted in an area with reduced air and ground risk and/or representative subsystems tests; or

(2)simulation, provided it is proven valid for the intended purpose with positive results; or

(3)any other means acceptable to the competent authority that issues the authorisation;

(e)if the option in point (d)(3) is selected, a substantiation of the suitability of those means for proving the adequacy of the procedures;

(f)a record of proof of the adequacy of the procedures, including at least:

(1)the UAS operator’s name and registration number;

(2)the date(s) and place(s) of tests or simulations;

(3)identification of the means used, e.g. for tests or simulations that use actual UASs: the type category, the name of the UAS designer, and the model and serial number of each UA used;

(4)a description of tests or simulations conducted, including their purpose, the expected results (including key performance parameters/indicators, where relevant), how they were conducted, the results obtained, and conclusions; and

(5)the signature of the person that is appointed by the UAS operator to conduct the tests or simulations;

(g)for UAS operations that require a ‘high’ level of assurance, the procedures and the dedicated flight tests, simulations, or other means acceptable to the competent authority, which are indicated in point 3.2, validated by the competent authority that issues the authorisation or by an entity that is recognised by that competent authority.

3.3. The following conditions apply to the dedicated flight tests that are indicated in point 3.2(d)(1):

(a)the configuration of the UAS hardware and software should be identified;

(b)the UAS operator should conduct the dedicated flight tests;

(c)if no simulations as the ones indicated in point 3.2(d)(2) are conducted, the dedicated flight tests should cover all the relevant aspects of the contingency and emergency procedures;

(d)for UAS operations that require a ‘high’ level of assurance, the dedicated flight tests that are performed to validate the procedures and checklists should cover the complete flight envelope or proven to be conservative;

(e)the UAS operator should conduct as many flight tests as agreed with the competent authority to prove the adequacy of the proposed procedures;

(f)the dedicated flight tests should be conducted in a safe environment (reducing the ground and air risks to the greatest extent possible), while ensuring the representativeness of the tests’ results for the intended UAS operations; and

(g)the UAS operator should record the flight tests as part of the information to be recorded as per point UAS.SPEC.050(1)(g), e.g. in a logbook, as indicated in AMC1 UAS.SPEC.050(1)(g); such a record should include any potential issues identified.

3.4. The UAS operator should reduce the complexity of the procedures as much as possible.

3.4.1. The verification of the complexity of the procedures may include:

(a)an expert judgement, as indicated in point 3.3(b); and

(b)a proof of the adequacy of the procedures, as indicated in point 3.3(c) and (d).

3.4.2. The UAS operator may adopt a method for the evaluation of the complexity of the procedures applied by the relevant personnel, i.e. the remote pilot and/or other personnel in charge of duties essential to the UAS operation. That method should be adequate for the evaluation of the workload that is required by the task(s) of each procedure. For example, a suitable method for evaluating the workload of the remote pilot and/or other personnel in charge of duties essential to the UAS operation may be the ‘Bedford Workload Scale’, which was conceived as a qualitative and relatively simple methodology for rating the pilots’ workload that is associated with the design of an aircraft’s human–machine interface (HMI). However, this methodology is deemed to be adequately generic to be also applicable to the tasks associated with the operational procedures to be conducted by remote pilots and/or other personnel in charge of duties essential to the UAS operation. Figure 1 depicts the Bedford Workload Scale adapted to operational procedures for UAS operations: ‘pilot’ is replaced by ‘remote crew member’ (i.e. the remote pilot or other personnel in charge of duties essential to the UAS operation), and ‘pilot decision’ is replaced by ‘remote crew member performs a procedure task’. A procedure may include one or more tasks.

[Figure or form omitted from this preview — available in the Avioverse workspace library.] Figure 1 — Bedford Workload Scale adapted to operational procedures for UAS operations

EMERGENCY RESPONSE PLAN (ERP)

1.Scope of this AMC

1.1 This AMC defines the content of an ERP as well as the methodology for its validation. It may be used to meet Criterion #4 of OSO #8 (ERP) of Annex E to AMC1 Article 11.

1.2 The risk assessment, as required by Article 11 of the UAS Regulation, should address the safety risks that are associated with the loss of control of a UAS operation, which may result in:

(a)fatal injuries to third parties on the ground;

(b)injuries to third parties in the air; or

(c)damage to critical infrastructure. Note: As per Section S.2.3.2 of AMC1 Article 11, the loss of control of a UAS operation corresponds to situations where the contingency procedures would not have achieved the desired effect.

1.3. Therefore, in line with the risk assessment applied, the scope of this AMC is limited to addressing the response to emergency situations that are caused by the UAS operation, as well as the potential consequences that are indicated in point 1.2. However, the response to such emergency situations should not be limited to the potential risk/harm only to third parties but also to the UAS operator’s personnel.

1.4. This AMC does not address emergency situations other than those referred to in point 1.3. However, the UAS operator may be required to address such situations as part of the operational authorisation.

2.Purpose of the ERP

2.1. The UAS operator should, in cooperation with other stakeholders, if applicable, develop, coordinate, and maintain an ERP that ensures orderly and safe transition from normal operation to emergency and return to normal operation. The ERP should include the actions to be taken by the UAS operator or specified individuals in an emergency, and indicate the size, nature, and complexity of the activities to be performed by the UAS operator or the specified individuals.

2.2. As for emergency procedures, an ERP is implemented by the UAS operator to address emergency situations. However, an ERP is specifically developed to:

(a)limit any escalating effect of the emergency situation;

(b)meet the conditions to alert the relevant authorities and entities.

2.3. The ERP should contain all the necessary information about the role of the relevant personnel in an emergency and about their response to it.

3.Effectiveness of the ERP

3.1. For the ERP to be effective, it should:

(a)be appropriate to the size, nature, and complexity of the UAS operation;

(b)be readily accessible by all relevant personnel and by other entities, where applicable;

(c)include procedures and checklists relevant to different or specific emergency situations;

(d)clearly define the roles and responsibilities of the relevant personnel;

(e)have quick-reference contact details of the relevant personnel;

(f)be regularly tested through practical exercises involving the relevant personnel; and

(g)be periodically reviewed and updated, when necessary, to maintain its effectiveness.

4.Emergency situations, response activation, procedures, and checklists

4.1. The ERP should define the criteria for identifying emergency situations, and for identifying the main emergency situations that are likely to increase the level of harm (escalating effect) if no action is taken.

4.2. The identified emergency situations should at least include those where one or more UA are operated by the UAS operator and have the potential to:

(a)harm one or more persons;

(b)hit a ground vehicle, building, or facility where there are one or more persons who might be injured as a consequence of the UA impact;

(c)harm critical infrastructure;

(d)start a fire that might propagate;

(e)release dangerous substances;

(f)hit an aircraft that carries people and/or whose crash might lead to one or more of the situations listed in (a) to (e); and

(g)cause the UA to leave the operational volume and fly beyond the limits of:

(1)the ground risk buffer; and/or

(2)the air risk buffer (if existing), or enter adjacent airspace where there is a risk of collision with manned aircraft.

4.3. The ERP should establish the criteria for the activation of the respective emergency response procedures to address the identified emergency situations.

4.4. The ERP should consider the following principles for prioritising the actions to respond to an emergency situation:

(a)alert the relevant personnel and entities;

(b)protect the life of those affected or in danger;

(c)give first aid while awaiting the arrival of the emergency services, provided the personnel employed by the UAS operator is qualified for that purpose;

(d)ensure the safety of the emergency responders;

(e)address secondary effects and put in place actions to reduce them (e.g. if the UA crashes on a road, warn the other drivers in the traffic or redirect them accordingly in order to avoid having cars colliding with the crashed UAS);

(f)keep the emergency situation under control or contained;

(g)protect property;

(h)restore the normal situation as soon as practicable;

(i)record the emergency situation and the response to it, and preserve evidence for further investigation;

(j)remove damaged items, unless needed untouched for investigation purposes, and restore the location of the emergency;

(k)debrief the relevant personnel;

(l)prepare any required post-emergency report or notification; and

(m)evaluate the effectiveness of the ERP and update it, if required.

4.5. As a minimum, the ERP should include procedures for:

(a)an orderly transition from the normal phase to the emergency response phase;

(b)the assignment of emergency responsibilities and roles (see point 5);

(c)coordinated action and interaction with other entities to respond to the emergency situation; and

(d)return to normal operation as soon as practicable.

4.6. The ERP should include a procedure for recording the information on the emergency situation and on the subsequent response. That procedure should also cover how to gather information from a third party that reports an emergency situation caused by a UA of the UAS operator.

4.7. The ERP should include procedures for handling hazardous materials in an emergency situation, if applicable.

4.8. The ERP should include checklists that:

(a)are suitable for the identified emergency situations, as per point 4.1;

(b)clearly indicate the sequence of actions and the personnel responsible to carry out those actions; and

(c)provide the contact details of key stakeholders, as per point 5.4.

4.9. The content of the ERP should be kept up to date and reflect all organisational or operational changes that may affect it.

5.Roles, responsibilities, and key points of contact

5.1. The UAS operator should nominate an emergency response manager (ERM) who has the overall responsibility for the emergency response.

5.2. If the UAS operator is not a one-person entity and/or manages external personnel in an emergency response, the UAS operator should establish an emergency response team (ERT) that:

(a)is led by the ERM;

(b)includes a core ERT that comprises persons with a role that implies being directly involved in responding to an emergency situation; and

(c)includes, if applicable, a support ERT that comprises ERT members who support the core ERT in responding to the emergency situation.

5.3. The ERP should provide a clear delineation of the responsibilities in an emergency response, including the duties of the remote pilot(s) and of any other personnel in charge of duties essential to the UAS operation.

5.4. The ERP should establish a contact list(s) of key staff, relevant authorities, and entities involved in an emergency response, including:

(a)the full names, roles, responsibilities, and contact details of the ERM and, if applicable, of the ERT members, including their replacement if the nominated persons are unavailable; and

(b)the full names, roles, responsibilities, and contact details of the relevant authorities and entities outside the UAS operator to be contacted in case of emergency; in addition, the single European emergency call number ‘112’ should be indicated as an emergency contact number for UAS operations that are conducted in any of the EASA Member States and in any other State where that number is used.

5.5. The ERP should indicate the person(s) responsible for the emergency response means (refer to point 6.2) and their contact details. The responsible person(s) should ensure that those means are available and usable when needed.

5.6. To ensure a prompt response, the ERM and other ERT members, if applicable, should have direct access to:

(a)the emergency response checklists that are indicated in point 4.8; and

(b)if not included in the checklists referred to in (a), the contact list(s) indicated in point 5.4.

6.Emergency response means

6.1. The ERP should indicate the means to be used by the UAS operator to respond to an emergency, which may include one or more of the following:

(a)facilities, infrastructure, and equipment;

(b)extinguishing means, e.g. fire extinguishers, fireproof portable electronic device (PED) bags;

(c)personal protective equipment, e.g. protective clothing, high-visibility clothing, helmets, goggles, gloves;

(d)medical means, including first-aid kits;

(e)communication means, e.g. phones (landline and mobile), walkie-talkies, aviation radios, internet; and

(f)others.

6.2. The person(s) in charge of the emergency response means should have an updated record of the available means that are indicated in point 6.1, including their number and status (e.g. expiry date of perishable means).

7.ERP validation

7.1. If the UAS operator is a one-person entity and does not manage external personnel in an emergency response, the UAS operator should at least ensure that:

(a)the procedures that are indicated in point 4 cover all the identified emergency situations and that the necessary actions are reflected in the corresponding checklist(s);

(b)the contact details in the list(s) indicated in point 5.4 are up to date; and

(c)the availability of the emergency response means that are indicated in point 6 is checked before conducting any UAS operation, in particular that the communication means to alert the relevant contacts (see point (b)) are operational.

7.2. If the UAS operator is not a one-person entity and/or manages external personnel in an emergency response, in addition to complying with point 7.1, the UAS operator should conduct a tabletop exercise that:

(a)is established in accordance with the criteria that are indicated in the ERP to be considered representative;

(b)is consistent with the ERP training syllabus;

(c)includes sessions where one or more scenarios of the identified emergency situations are discussed by the exercise participants, which should include the relevant ERT members for each of the sessions; all aspects of the ERP should be covered once all sessions of the tabletop exercise have been completed;

(d)is guided by the ERM or any other person designated by the UAS operator to act as a facilitator;

(e)may include the participation of third parties that are identified in the ERP; the participation conditions for those third parties should be indicated in the ERP; and

(f)is performed with the periodicity that is indicated in the ERP. However, if the UAS operator is a one-person entity and does not manage external personnel in an emergency response, a tabletop exercise may not be appropriate as the participation of third parties is not required. In such case, the conditions of point 7.1 are deemed sufficient and proportionate to the level of simplicity of the operator and, in principle, of the UAS operations. For UAS operators with a more complex structure as well as for complex UAS operations, the tabletop exercises may need to be complemented with partial emergency exercises and/or full-scale exercises, including the corresponding drills.

7.3. After following the procedures that are described in the ERP in a real emergency situation, the UAS operator should conduct an analysis of the way the emergency was managed and verify the effectiveness of the ERP.

8.ERP training

8.1. The UAS operator should provide relevant personnel, and in particular ERT members, with ERP training.

8.2. The UAS operator should develop a training syllabus that covers all the elements of the ERP.

8.3. The UAS operator should compile and keep up to date a record of the ERP training that is completed by the relevant personnel.

8.4. The competent authority that issues the authorisation or an entity that is designated by that competent authority should verify the competencies of the relevant personnel.