Understanding authorities

A summary of FlyFreely's authority system and how to manage your authorities.

There are many types of licences, endorsements, permissions and registrations that need to be documented and then checked during the Approvals process. Some might need to be made available to appropriate authorities in the field during the course of a mission. What they all have in common is that a record must be made and kept in an appropriate form. The form varies but includes:

• Documents that are required for regulatory purposes such as RePLs, REOCs, and RPA registrations.
• Documents associated with particular missions (example: special permissions or approvals).
• Acknowledgements of procedures, (example: updates to operations manuals).

Another complication is that new types of authorities may be introduced over time. Further, it can be necessary to allow some organisations to delegate the authority to issue authorisations to 3rd parties. For example, a company might delegate authority to issue authorisations to a contractor.

Authority Types

Authority types include:

• Licences and Endorsements – may be attached to Organisations and/or Pilots. Examples include RePL, REOC, NVFR. In some cases for example, NVFRs must be valid and held by both the organisation and the pilot. So, an organisation might have an NVFR endorsement but not all pilots associated with that organisation would necessarily hold NVFR endorsements. Thus not all pilots could carry out night missions.
• Permissions – attached to Organisations, most often with respect to a particular Mission. So, a permission to overfly/operate on a specified piece of land. This might be extended over a period of time, if multiple missions are to be carried out in the same location.
• Registrations – attach to Organisations, but reference specific equipment, eg RPAS registration.
• Policy requirements, for example an organisation’s fatigue policy.
• Insurance

Some authorities have expiry dates and can be renewed. Others never expire but might be revokable. Yet others, eg REOCs, expire and are not renewable – Instead a new licence must be issued.

Any mission plan should have a list of required authorisations attached.

Setting up Authorities

An Organisation operating under its own ReOC

Authorities Setup

1. Automatic authorities that require no intervention from the Planner and attach to every mission, include:
   • RePL – the authorising document will be attached to Pilot record;
   • REOC – the system checks that organisation has a valid REOC and that the CRP  will be available to approve mission or will delegate that authority. The authorising document is attached to the Organisation’s record;
   • Others, eg NVRF for a mission during the hours of darkness. The system will check that the organisation’s Area Endorsement is valid, and will only allow pilots who have the appropriate Endorsement to be selected. Appropriate authorising documents are connected to both the Organisation’s and Pilot’s record; and
   • Any authorities that have been delegated by another organisation need to describe the chain of delegation. Appropriate authorising documents are connected to the Organisation’s record.
2. Automatic authorities that require no intervention from the Planner and attach to some types of mission
   • For example, an authorisation to fly in a restricted area that has been given for a period between two dates. Appropriate authorising documents are connected to either the Organisation’s or the Pilot’s record or both.
3. Authorities that require further input,
   • A list of Authority types would be shown, allowing aPlanner to select the appropriate type; and
   • A form suitable for that particular authorisation type will be displayed and would need to be completed.
4. Summary actions for setting up Authorities:
   • Set Authorisation type
   • Set Authority entity/entities or entity chain in case of a delegated Authority
   • Set start date and expiry date (if any)
   • Link to appropriate documentation in document repository
   • Link to Mission types

Mission Planning

1. Automatic authorities are be available for inspection by the Planner but do not require the Planner to perform any action as they are added by the system, including:
   • RePL
   • REOC – system checks that organisation has a valid REOC and the CRP  will be available to approve mission or will delegate
2. Automatic authorities that require no intervention from the Planner but attach to only some types of mission should be available for inspection. For example:
   • Authorisation to fly in a restricted area that has been given for a period between two dates;
   • NVRF for a mission during the hours of darkness. The system will check that the organisation’s Endorsement is valid, and will only allow pilots who have the appropriate Endorsement to be selected
3. To add an authorities that requires further input, Planner opens the Authorities dialogue:
   • The system checks which REOC, ie own REOC or FLyFreely’s
   • The dialogue shows list of Authorities Types and Planner selects the appropriate type
     • No requirement to show completely automatic (ie system generated) authorities. These should just appear in the list of authorisations attached to a mission. On the other hand, if, for example, a REOC is not valid, will further authorities to be added? A REOC could be pending, maybe due in a few days, so will allow mission planning to continue. Of course this is flagged.
   • A dialogue suitable for that particular authorisation type is displayed.
     • Contains the steps to complete the additional procedures, ie another dialogue.
   • The dialogue is completed and saved.

Contracting Flight Operations

Mission Planning

       An example scenario

• Assume that Organisation A has a FlyFreely subscription.
• Organisation A, which does not have a REOC, contracts Organisation B to manage maintenance of assets.
• Organisation B uses RPAs to perform inspections and plans Missions using its REOC.
• Organisation B contracts Organisation C to conduct the flight operations using Organisation C’s RPAs and Personnel. Each organisation may have policies that regulate these activities and thus require Authorities.

1. Organisation B requires access to Organisation A’s policies and Organisation C’s policies
2. Organisation B requires access to Organisation C’s RPA register and Personnel register
3. Organisation A requires sight of Organisation B’s Mission details, but not the ability to change any details, including:
   1. Visibility of the Mission Planning at all stages
   2. Visibility of the outcome of the Mission upon completion
4. Organisation C requires sight of Organisation B’s Mission details, but not the ability to change any details, including:
   1. Visibility of a pending Mission, including Approval status
   2. Visibility of the outcome of the Mission upon completion
5. In the case of policy conflicts the baseline might be to take the more restrictive policy, eg a fatigue policy should apply the most restrictive version.
6. Organisation B must obtain any authorities for the Mission that are not required to be held by Organisation C, eg:
   1. Permission to conduct flight operations over private land
   2. But not an authority that must be completed by Organisation C’s personnel upon accessing the site
7. Organisation B has to have sight of Organisation C’s relevant Authorities. Eg:
   1. RePLs – ie, only Organisation C’s pilots who hold an unrevoked RePL
   2. NVFR endorsements where relevant
   3. Any other authorisations

Organisation operating under FlyFreely ReOC

Mission Planning

• Similar to Organisation operating under own ReOC above but referring to the FlyFreely Authorisations