Advisory Circular (AC) No. 901-001

Subject: Remotely Piloted Aircraft Systems Safety Assurance Declaration and Pre-Validated Declaration Processes

Issuing Office: Civil Aviation, Remotely Piloted Aircraft Systems Task Force
Document No.: AC 901-001
File Classification No.: Z 5000-32
Issue No.: 01
RDIMS No.: 20531711 V1
Effective Date: 2025-04-01

Table of contents

Introduction

(1) An Advisory Circular (AC) provides information and guidance by describing considerations relevant to assisting the public in complying with the regulations and standards. An AC does not change, create, amend or permit deviations from regulatory requirements, nor does it establish minimum standards.

1.1 Purpose

(1) This AC provides information and guidance on the Declaration and the Pre-Validated Declaration (PVD) processes that apply to the safety assurance of RPAS. Specifically, this advisory circular describes who is expected to make safety assurance declarations, the expected documentation associated with a declaration, and the responsibilities of the declarant.

(2) This advisory circular does not describe specific aspects or technical requirements of CAR Standard 922. RPAS Declarants declare that a specific RPAS meets certain sections of CAR Standard 922. For more information on CAR Standard 922 and the specific technical requirements that RPAS are expected to meet, refer to Advisory Circular 922-001 Issue 2. Any questions or clarifications on this material can be directed at the Transport Canada Declaration email inbox:

TC.RPASDeclaration-DeclarationSATP.TC@tc.gc.ca

2.0 References and requirements

2.1 Reference documents

(1) It is intended that the following reference materials be used in conjunction with this document:

2.2 Cancelled documents

(1) Not applicable.

2.3 Definitions and abbreviations

(1) The following definitions are used in this document:

  • (a) Accountable Executive: is the individual appointed by the RPAS Operating Certificate holder to be responsible for operations or activities authorized under the certificate, and accountable on behalf of certificate holder for meeting the requirements of the regulations.

  • (b) Airworthy, Airworthiness: in respect of an aeronautical product, means in a fit and safe state for flight and in conformity with its type design. As RPAS products will often not have a formal type design defined, when referring to an RPAS as airworthy, airworthy means that the RPAS conforms with the intended design of the manufacturer or Declarant.

  • (c) Applicant: The person or entity who is seeking to make a Declaration or apply for a Pre-Validated Declaration for a given section of CAR Standard 922. In this document Applicant is generally used to refer to individuals or entities before they submit a safety assurance declaration to Transport Canada. Once a safety assurance declaration is made, the Applicant is referred to as the RPAS Declarant.

  • (d) Declarant, Declaring Entity: The Declarant, or Declaring Entity is the person, or organization that makes a safety assurance declaration to the Minister. Depending on the nature of the declaration, the Declarant might be the RPAS designer, or a person knowledgeable in the specifics of the design, The Declaring Entity might be a manufacturer, or the supplier of a service being declared, and the Declaring Entity would employ the Declarant who signs and takes personal responsibility for the safety assurance declaration. In all cases the Declarant takes responsibility for the fact that the RPAS being declared meets the relevant CAR 922 Standards.

  • (e) Service Difficulty: means a failure or malfunction of, or defect in, an aeronautical product. (Ref CAR 101)

  • (f) Small Remotely Piloted Aircraft (sRPA, sRPAS)

  • (g) Medium Remotely Piloted Aircraft (mRPA, mRPAS)

  • (h) Reportable Service Difficulty: means a service difficulty that affects or that, if not corrected, is likely to affect the safety of an aircraft, its occupants or any other person. (Ref CAR 101)

  • (i) Mandatory Action: means the inspection, repair or modification of a remotely piloted aircraft system that the manufacturer of the system considers necessary to prevent an unsafe or potentially unsafe condition. (ref CAR 101)

(2) The following abbreviations are used in this document:

  • (a) AC: Advisory Circular

  • (b) BVLOS: Beyond Visual Line of Sight

  • (c) C2: Command and Control

  • (d) CAR: Canadian Aviation Regulations

  • (e) CONOPS: Concept of Operations

  • (f) DAA: Detect, Avoid and Alert

  • (g) EMI: Electromagnetic Interference

  • (h) MOC: Means of Compliance

  • (i) PRS: Parachute Recovery System

  • (j) PVD: Pre-Validated Declaration

  • (k) RF: Radio Frequency

  • (l) RPA: Remotely Piloted Aircraft

  • (m) RPAS: Remotely Piloted Aircraft System

  • (n) SDR: Service Difficulty Report

  • (o) TCCA: Transport Canada Civil Aviation

  • (p) VLOS: Visual Line of Sight

3.0 Background

(1) Traditionally, airworthiness of certified aviation products is governed by CAR Part V and the Type Certification process. This process has been developed over many years to assure the reliability of traditional aviation products. During the Type Certification process, Transport Canada is directly involved in the determination of the applicable airworthiness standards and the oversight of any demonstrations of compliance to those standards. The small and medium RPAS industry, however, presents many challenges where product airworthiness is concerned. Novel technologies, and short product life cycles are generally not easily accommodated by Type Certification. Combine these aspects with the low-risk nature of RPAS operations regulated under CAR 901 and a different approach is needed to accommodate the industry while ensuring that RPAS products have been designed and manufactured with safe and reliable operations in mind.

(2) Given this, airworthiness of small and medium sized RPAS are regulated through the Declaration and Pre-Validated Declaration (PVD) processes. The key aspect of these processes is that applicants who have verified that an RPAS meets the technical requirements of CAR Standard 922 can make a formal declaration to the Minister to this effect. CAR Standard 922 contains high level safety requirements. It is expected that the applicant has (or has access to) sufficient technical expertise and technical data about the RPAS under consideration to make valid judgements regarding compliance with CAR Standard 922. It is also expected that prior to making the formal declaration, the applicant will gather all required evidence and perform all required test and analyses to demonstrate compliance with CAR Standard 922. By making a declaration the applicant becomes a Declarant, and take-on regulated responsibilities to ensure that the RPAS remains in compliance with the declared standards, and that operators are provided with enough information to operate the RPAS safely. This process mirrors the process used in other areas of aviation that are considered low-risk to the general public such as Basic and Advanced Ultralight aircraft.

(3) In the case of a Declaration, there is no requirement of direct involvement in the compliance process from Transport Canada. The applicant submits their safety assurance declaration that the RPAS under consideration meets the identified requirements of CAR Standard 922. The applicant needs to retain all evidence the RPAS meets the standard because Transport Canada reserves the right to review compliance data on request (ref CAR 901.201). If the result of this review is that, in the Minister’s opinion, the RPAS does not comply with the declared standards, TCCA can invalidate the declaration (ref CAR 901.194(4)(a)).

(4) For a Pre-Validated Declaration, however, there is a requirement for Transport Canada involvement early in the process. The key difference between the Declaration process and the Pre-Validated Declaration process is that during a PVD, the proposed Means of Compliance (MOC) must be accepted by Transport Canada before the declaration can be made. Once Transport Canada letter of acceptance is received, the applicant will make the safety assurance declaration in the same manner as described for Declaration in the section above.

4.0 Reliance on Declarations for Low Risk RPAS Operations

(1) Since Part IX of the CARs was released in 2019, Transport Canada has relied on a declaration system to administer safety assurance of small RPAS operated VLOS. A declaration is made by a party external to Transport Canada, and asserts that the particular make and model of RPAS meets the equipment performance standard described in CAR Standard 922.

(2) In contrast to traditional aviation type certification, where a party delegated by the Minister of Transportation makes the final finding that an aviation product meets the required design standard (e.g., Airworthiness Manual requirements), under the Declaration system the finding of compliance rests solely with the external party making the declaration.

(3) There are many reasons why a Declaration system was adopted for the safety assurance of small RPAS. The key reasons are:

  • (a) The low risk to aircraft and people on the ground of small RPAS operations, particularly VLOS and low-risk BVLOS operations.

  • (b) The new and novel nature of RPAS technology combined with their low cost (relative to traditional aviation) means that designs and technology iterate much faster than traditional aviation.

  • (c) The time required for traditional type certification is not only longer than the iterative design cycle of most RPAS platforms, but traditional type cert projects often last longer than the design service life of many smaller RPAS.

  • (d) The number of small RPAS and small RPAS manufacturers, the time and effort that would be required to address each RPAS design with traditional type certification processes is impractical.

(4) Entities making safety assurance declarations to Transport Canada are reminded that when they declare compliance to Transport Canada, they are taking responsibility for the declared RPAS meeting the applicable sections of CAR Standard 922. If it is shown later that the declared RPAS does not meet the safety assurance standard, the Declarant may be subject to penalties. Declaring entities also have responsibilities related to continuing airworthiness and continued product safety as outlined in CAR Part IX. Declarants need to provide manuals, maintenance schedules, and product support to ensure their product continues to meet the safety assurance requirements to which they have declared. Declarants that also have associated letters of acceptance from TCCA (i.e., Holders of Pre-Validated Declarations) are also required to provide annual reports to Transport Canada on the operational status of their declared RPAS.

(5) Under the low-risk BVLOS regulatory framework, Transport Canada continues to rely on safety assurance Declarations to identify the capabilities of small and medium RPAS. For BVLOS operations in unpopulated areas, the safety assurance framework continues to require a safety assurance declaration for the RPAS products. For BVLOS operations in sparsely populated areas, Transport Canada is implementing Pre-Validated Declarations to assess the approach to compliance.

(6) The primary difference between a Declaration and a Pre-Validated Declaration is that a pre-Validated Declaration requires an application and acceptance of the applicant’s means of compliance to CAR Standard 922. The use of the word acceptance in this case means that Transport Canada will issue a letter to the applicant, confirming that, if the applicant adheres in totality to the means of compliance described in their application, their RPAS will comply with the applicable standards. Once the letter of acceptance is issued, the applicant is free to conduct their tests and/or analyses in accordance with the accepted means of compliance, and eventually submit a safety assurance declaration to TC. Applicants should be aware that there is a two year time limit between the issuance of the letter of acceptance and making their associated declaration (ref 901.194(3)). If the declaration is not made within this timeframe, a new Pre-Validated Declaration Application will need to be made.

5.0 Declaration and PVD Process

The Declaration and PVD Processes are shown in the flowchart below.

Figure 1 - Declaration and PVD Process Overview

5.1 Declaration Process

(1) TCCA involvement in the Declaration process is limited to acknowledging applicant declarations, and surveillance of declaration holders. Because of this, the declarant has flexibility in the process prior to the act of declaration. However, declarants should develop and follow processes to ensure that compliance evidence is collected, retained, and is up to date in a systematic way and that they completely understand and document any limitations of their declared system.

(2) In some cases, a declarant may wish to make a declaration against an existing RPAS design or product. While it is often simpler to design an RPAS with a CAR standard in mind, it is also possible for existing designs to comply with CAR Standard 922. In this case it is the responsibility of the declarant to ensure that the products’ design aligns with the technical requirements in the declaration. Often this will accomplished be through tests and analysis on the existing design to show that it complies with the identified CAR 922 standards.

(3) The first step in a declaration is to determine if making a declaration is even required. Given the Notional CONOPS (e.g., < 25 kg aircraft designed for VLOS operations in Controlled Airspace), the declarant must determine which CAR Standard 922 sections apply. Refer to AC 922-001 Issue 02 for guidance on each technical requirement in the standard.

(4) Once the required set of CAR 922 standards are identified, the declarant must determine how their RPAS will address each element of the technical requirements. The declarant is expected to be the technical subject matter expert on the specific RPAS for which they are declaring, therefore it is the declarant who decides how each technical requirement is best addressed. In cases where a declarant is the manufacturer of only a small part of the RPAS (i.e. a parachute manufacturer), it should be noted that the declaration is still for the complete RPAS (i.e. the RPAS, with the parachute installed, meets CAR Standard 922.XX). Declarants are expected to know enough about the other component systems that make up the RPAS to be able to state with confidence that the system as a whole meets the declared standard. Transport Canada does retain the right to review the means of compliance and substantiating data for any declaration made (ref CAR 901.201). If an RPAS is found by the Minister not to comply with the declared sections of CAR Standard 922, the Minister will invalidate the declaration for that RPAS. When a Declaration is invalidated all Canadian Registered owners of this product immediately lose operational privileges in the Advanced or Complex category (VLOS or BVLOS respectively), and the RPAS may only be operated in the Basic category (ref CAR 901.53). In the event the Minister invalidates a declaration, the Declarant will need to work with the Minister to bring their product back into compliance to re-establish these privileges for Canadian registered RPAS. The declarant should consider that their means of compliance must not only meet their own judgment, but declarants should be prepared and confident that their MOC will stand up to a review by Transport Canada.

(5) Once the MOC to CAR Standard 922 is established, the declarant may proceed with any design/redesign and manufacturing processes required to result in a compliant RPAS. The decision to declare to a CAR standard should be made early enough in the RPAS design process that the technical requirements can be fully integrated into the RPAS design and verification process. In other cases, either when an RPAS exists, or when a modification is made to an existing design, there may be redesign work required to integrate new systems into the RPAS in order to comply with required CAR Standard 922 provisions.

(6) It’s expected that means of compliance to CAR Standard 922 will require some level of testing on an operational RPAS configuration. Therefore, once the compliant RPAS has been built, declarants are responsible for conducting any testing they deem necessary to complete their demonstration of compliance to CAR Standard 922. In general it’s expected that analysis, bench tests, or other engineering evaluations as well as integrated flight demonstrations will be completed to support the declaration. Flight demonstrations can be conducted in controlled, lower-risk environments such that the specific declaration being sought is not required.

(7) Once the design has been completed and the declarant has satisfied themselves that their RPAS complies with the relevant sections of CAR Standard 922, the declarant needs to generate the manuals and other documentation required by CAR 901.200. These documents are intended to be made available to all users of the RPAS and must include all information needed to ensure safe operation of the RPAS. This includes any operating limitations (e.g., speed and altitude limitations for safe parachute deployment), and environmental limitations (e.g., wind, precipitation limitations), and operator behaviors (e.g., use) which may affect the safety of the operation

(8) The Declarant has ongoing responsibilities under CAR 901.195 to notify the Minister in the event they become aware of any reason why the RPAS no longer meets Declared CAR 922 standards. This notification should indicate whether or not the deficiency is temporary (i.e. a bug that will be fixed by a software update) or permanent (i.e. the declarant wishes to permanently invalidate their declaration).

5.2 Pre-Validated Declaration Process

(1) Similar to a standard Declaration, the first step in a PVD is for the applicant to generate a notional CONOPS to determine which CAR Standard 922 sections apply. Ideally, this should be done before the RPAS design is finalized, allowing requirements from the CAR standard to be incorporated directly into the RPAS design process. However, in some cases it may be possible to demonstrate that an existing RPAS design meets the requirements of the standard, or that it meets the design with minor updates or modifications.

(2) The second step is to determine how the RPAS design will satisfy the CAR Standard requirements. These MOC will be specific to the CAR Standard requirements. Note that the proposed MOC is one of the deliverables with the PVD application, so the applicant is wise to review guidance contained in CAR Standard 922 AC to determine if any accepted industry standards or methodologies are compatible with their particular RPAS.

(3) The applicant will generate all the deliverables required by CAR 901.196 to support the PVD Application. Refer to Section 6.0 for details about each deliverable.

(4) The applicant will make a PVD application to TCCA. Upon receipt of the application, the supporting documents, and the PVD fee, TCCA will review the application. If the application is found to be acceptable, TCCA will issue a letter of acceptance to the applicant. This letter of acceptance is TCCA’s agreement that if the applicant completes the testing/analysis and other tasks described in the application, the result will be an RPAS that meets the intent of CAR Standard 922.

(5) If the application is reviewed by TCCA and found not to be acceptable, TCCA will contact the applicant and indicate any deficiencies found and changes are required to the application.

(6) Once the applicant has a letter of acceptance in hand, they can complete their RPAS design work (if not already completed), keeping in mind their accepted MOC. The MOC will often drive design decisions that need to be integrated into the RPAS prior to commercial production.

(7) The applicant should conduct the tests and other MOC that were described in the PVD application to verify that the final design configuration meets the requirements of CAR Standard 922. During the design and verification steps, if the applicant discovers issues which require them to deviate from the approved MOCs they will need to update the MOC listed in their application and notify TCCA of the change to the accepted plan.

(8) Once all MoC have been completed, the applicant is free to make a declaration to TCCA that their RPAS meets CAR Standard 922 and that they have completed all the agreed MoC that were listed in their PVD application.

(9) The applicant will develop the documentation required to meet their CAR 901.200 responsibilities. These documents include maintenance programs, mandatory actions, and operating manuals that are required by the operator for continued safe operation of the RPAS.

(10) The Declarant has ongoing responsibilities under CAR 901.195 to notify the Minister in the event they become aware of any reason why the RPAS no longer meets Declared CAR 922 standards. This notification should indicate whether or not the deficiency is temporary (i.e. a bug that will be fixed by a software update) or permanent (i.e. the declarant wishes to permanently invalidate their declaration).

(11) The PVD Declarant maintains their declaration by performing their Annual Reporting and Service Difficulty Investigations responsibilities as described in CAR 901.198 and 901.199 respectively. Refer Section 8.0 for more information on the Annual Reporting process and to Section 10.0 for more information on investigation of Service Difficulties.

5.3 Types of Declaring Entities

There is a lot of flexibility over who is allowed to make safety assurance declarations for RPAS. At the most basic level, the declaring entity simply needs to possess sufficient knowledge of the RPAS design and capabilities to be comfortable making the declaration to TC (and taking on the associated responsibilities) that the RPAS meets the CAR Standard 922 requirement. This section describes a few of the types of entities that are expected to make declarations, and some of the responsibilities expected of each.

(1) When the entity is a designer/manufacturer of an RPAS:

The most common type of declaring entity is the designer/manufacturer of an RPAS. An example of an RPAS designer/manufacturer would be a company that designs, builds and sells an RPAS model (or several different models) to RPAS operators. This is the entity that would typically have full control over the RPAS design (and component suppliers), and possess complete knowledge of the RPAS systems along with how they are integrated together. They also have full control and knowledge over the quality assurance and continuous improvement processes for the construction of the RPAS.

(2) When the entity is a modifier or makes accessories for an RPAS

The second most common type of declaring entity is expected to be organizations that design modification or upgrade kits for RPAS. These kits could include equipment such as parachutes, DAA systems, upgraded C2, or specific payloads. This type of entity is expected to know enough technical details about the underlying RPAS to be confident that when the RPAS is modified or upgraded with their accessory, the declared system complies with CAR 922. In some cases, this may involve collaboration with manufacturers and declarants of other parts of the RPAS to ensure all parts of the RPAS are compatible. In other cases, the declarant may be able to do enough engineering analyses and/or tests to ensure that their accessory or modification work correctly when installed on the RPAS.

(3) When the entity is a Service Provider for RPAS operations

BVLOS operations require declarations for various functions critical to the operation, and it’s envisioned compliance with some standards (most commonly 922.09 C2, and 922.10 DAA) will provide opportunities to deliver this functionality using a service provider model. In this model, an RPAS operator would subscribe to an external entity (i.e., a C2 Link Service Provider, or a DAA Service Provider) to provide a capability required for the operation. In these cases, the declaring entity is likely not the manufacturer of major portions of the RPAS, but will need to have the technical capability to make a declaration that each RPAS that makes use of their service meets the applicable CAR Standard.

In this case, the declaring entity should demonstrate that their service meets the applicable CAR Standard Requirements when used with specific RPAS models, specific classes of RPAS, RPAS which meet a specific performance profile, or specific RPAS when operated with limitations. The declarant will need to evaluate and retain evidence that the scope of their declaration meets the declared standard and the service integrates with the specified RPAS. An entity could test their service with only one model of RPAS – and then only make their declaration for a single model. Alternatively, an entity may verify that their service meets the standard over a whole range of RPAS models (i.e., DAA service is compatible with all multirotor aircraft that meet a certain aircraft maneuverability performance level), if they wish to allow a wide range of aircraft makes and models to make use of the specified service.

(4) Other possible Declaring Entities

An entity with suitable engineering/test expertise which evaluates a third party RPAS, reviews, and verifies it meets the applicable CAR 922 standards (following the appropriate MOCs), and then declares the RPAS capable of operating safely per their documented limits

(5) Foreign RPAS Manufacturers

Being a Canadian entity is not a requirement to be a Declarant. Foreign manufacturers will need to fulfill the same requirements as a domestic manufacturer with respect to providing declaration documentation when requested by TCCA, being available to address SDRs, completion of an annual report on their RPAS operation.

6.0 Pre-Validated Declaration Application Document Requirements

6.1 Introduction

(1) The list of documents required for a Pre-Validated Declaration are identified in CAR 901.196. While these regulatory requirements are specific to the Pre-Validated Declaration process only, it is recommended that entities making any Declaration for the safety assurance of an RPAS develop these documents or their equivalent to substantiate their declaration. These documents or their equivalent may be requested during a surveillance audit of a safety assurance declaration performed under 901.201.

6.2 Applicant Name and Contact Information (ref 901.196(a))

(1) A fundamental part of the Declaration process is the identification and contact information of the person making the declaration. By making a declaration, the declarant takes on certain responsibilities which include being reachable by the Minister for the purposes of surveillance of the declaration.

(2) Declarations are always tied to the “person making the declaration” even when the declaration is made on behalf of a corporation. It is recognized that duties and responsibilities of the people within an organization change, and as such, it is the responsibility of the organization to ensure that if the person responsible for the declaration changes, Transport Canada must be provided with updated contact information. Declarants have the option of providing an email alias (i.e. declaration_info@drone_company.com) so that they can redirect email related to declarations within the organization as needed. In this case, the organization must always ensure that there is a person responsible for each declaration made and that this person can be reached by Transport Canada via whatever contact information is provided.

(3) Declarants are warned that, if a request is made by the Minister under CAR 901.201, and no response is received, this can lead to the Declaration being invalidated by the Minister, and the RPAS being removed from the list of aircraft with accepted Declarations. It is the declarant’s responsibility to ensure that any methods of contact provided with the declaration (e-mail/phone/mail) are actively monitored so that requests for data can be answered in a timely fashion.

6.3 Concept of Operations (ref 901.196(b))

(1) Document Description

The Notional CONOPS document is a formal description of the operations that the applicant expects to perform with their RPAS. In general, the notional CONOPS should include, at a minimum:

  • A technical description of the RPAS

  • A list of operations that the RPAS is intended to perform

  • A list of any operational rules or limitations that might affect the operational risk.

After reading the Notional CONOPS the reader should understand the main technical features of the RPAS and how they work together to meet the relevant sections of CAR Standard 922. It should also be clear to the reader what operations within the Part IX regulatory framework will be allowed (e.g., VLOS in Controlled Airspace, BVLOS in rural/uncontrolled airspace), and which will be prohibited. The operational limitations on the RPAS are important as they will affect the assumptions considered during the design and demonstration of compliance. These operational limitations (and the technical means through which they are enforced) will generally lead to operating rules and limitations passed onto the operator through the operations and maintenances manuals and into operational training programs.

The Notional CONOPS serves as a top-level document that should be referred to by all other documents in the application. All assumptions used in the other documents related to RPAS operations should flow from the Notional CONOPS.

For additional information on writing an RPAS CONOPS and what information should be included, refer to AC 903-001 Remotely Piloted Aircraft Systems Operational Risk Assessment.

6.4 Declaration Plan (ref 901.196(c))

(1) Document Description

The Pre-Validated Declaration Plan, is the key document that describes what sections of Standard 922 a declaration will be made for, and exactly how the declarant plans to demonstrate that the RPAS meets the standard. It is based on the Notional CONOPS document and serves as a road map for how an applicant will show compliance with each standard in 922 required for the proposed operation.

The Pre-Validated Declaration Plan would be expected to contain the following elements:

  • The applicant needs to identify what 922 standards they plan to comply with, and these standards need to align correctly with the standards required by the operational framework under the regulations (i.e. Operations Over People needs to meet CAR Standard 922.06) as well as the proposed operations listed in the CONOPS.

  • The applicant needs to identify their proposed means of compliance with each required section of CAR Standard 922. The applicant is encouraged to refer to industry consensus standards wherever possible.

  • The Pre-Validated Declaration plan must provide enough detail that a reviewer can understand the proposed MoC and their applicability to the CAR Standard. The reviewer will assess the appropriateness of the MoC to the standard based on the submitted CONOPS.

  • The level of detail should be such that the reviewer can assess that the means of compliance meets the spirit of the standard, covers the scope of the CONOPS for the function, and that if completed in its totality, the means of compliance will result in RPAS functionality that complies with the relevant section of CAR Standard 922.

  • Provide enough detail that the reviewer can assess the technical capability of the applicant to perform the proposed MoC. The effort and complexity required by the MoC should align with the contents of the Description of Technical Capability (refer to Section 6.6 below).

When reviewing a Pre-Validated Declaration plan, the reviewer will be assessing that the standards selected are appropriate for the Notional CONOPS, and that the proposed MoC will result in the RPAS design possessing adequate robustness for the risk of the operation. The reviewer will also be assessing the technical capability of the applicant; that the applicant understands their proposed means of compliance, and has the technical ability to accomplish the required testing and analysis.

6.5 Referenced Standards (ref 901.196(d))

(1) Document Description

Transport Canada will publish a list of standards that we find acceptable for each section of CAR Standard 922. It is expected that in most cases, applicants will use these industry consensus standards and Means of Compliance. However, in order to provide flexibility for designs that include new/novel technology, and to allow for innovation on the part of industry, applicants are free to propose any approach to show compliance with CAR Standard 922 provided it takes into account the entirety of the regulatory requirements for their concept of operations. Applicants must supply copies to TCCA of standards used to demonstrate compliance with their application.

Applicants must supply a copy of the relevant standard with their application. Alternatively, the contents of the proposed means of compliance could be incorporated into the detailed contents of a PVD plan.

The intent of sharing the referenced standard with TCCA is to allow the TCCA reviewer to educate themselves on the nature of the standard and to judge its appropriateness for the application in question. In cases where the referenced standard has use and distribution limitations attached to it, applicants should discuss these limitations with TCCA.

6.6 Description of Applicant Technical Capability (901.196(e))

(1) Document Description

This document is required in a PVD application to allow the reviewer to assess the technical competence of the applicant. Making a Declaration of compliance to CAR Standard 922, especially for a complex RPAS requires a certain level of technical understanding and ability. Applicants for a Pre-Validated Declaration must demonstrate that they have the technical expertise required to perform the testing outlined in the PVD plan, as well as the experience and infrastructure to manufacture and support their product. In some cases the applicant may also need to demonstrate that they are able to support any 3rd party licensing (i.e. for maintenance, repair or other support), or distribution of their products.

Applicants should use this document to describe their expertise in the fields of RPAS, aviation products, safety critical product development and system design and test. Examples of what might be included in this document is:

  1. A description of the organizations past experience especially in fields applicable to RPAS or aviation design, test and manufacturing.

  2. A description of the key competencies of the personnel who will be associated with the design, test, and manufacturing of the subject RPAS.

  3. Any industry accreditations possessed by the organization that might be relevant to the declaration.

(2) The level of technical capability required will depend on the details and complexity of the declaration. Applicants should ensure that this documentation is written with the other parts of the application in mind, and applicants should use this document to demonstrate that they are capable of doing all the verification and validation activities described in the other parts of the PVD application.

6.7 Plan for Manufacturing (ref 901.196(f))

(1) Document Description

The manufacturing plan demonstrates that the applicant has the capability of manufacturing RPAS such that each RPAS produced is a faithful reproduction of the design, and therefore complies with the declared standards.

At a minimum, the plan must include a description of:

  • manufacturing processes,

  • quality control procedures,

  • plan for controlling the quality and conformity of supplier parts, and

  • plan for configuration management of all aspects of RPAS production (Hardware and Software).

The manufacturing plan should also highlight the technical capability of the applicant to manufacturer the proposed RPAS at the scale and quantities expected.

6.8 Plan for Service Activation and Service Support Plan (ref 901.196(g))

(1) Document Description

In some cases, a pre-validated declaration will be made for a service that is provided to RPAS operators. One example of this is DAA as a service, where an entity provides air traffic information available to RPAS operators for the purpose of collision avoidance. Another example of this would be C2 as a service, where the service supplier provides command and control connectivity to RPAS operators over infrastructure shared with other RPAS operators. Declaration applications for services such as these need to show there is a process to develop, install, and confirm installed performance for infrastructure required to support the service (i.e. radio towers, radar stations, etc.), as well as a plan to verify operators subscribing to the service are activating the service correctly.

Once an operator subscribes and is actively participating in an RPAS service, it’s expected the service provider will have a plan for monitoring the level of service provided and investigating any SDR that users of the service may produce. The Plan for Service Activation and Support needs to describe how the continuity and integrity of the service is ensured.

6.9 Plan for Product Support (ref 901.196(h))

(1) Document Description

RPAS involved in operations that require Pre-Validated Declarations are generally conducting higher risk operations than those that only require Declarations. For this reason, it is important that the entity making the declaration play an active role in the safe operation of their declared RPAS models, through the collection of operating information and the monitoring and correction of technical issues.

The applicant is required to demonstrate that they have a plan for supporting their product once operators have purchased and are utilizing the equipment. This product support plan will describe how the applicant plans to fulfill their service difficulty (Section 10.0), and continuing airworthiness responsibilities. In cases where there are relatively few units planned to be built, or when the manufacturer is also the operator of the RPAS, this plan may be relatively simple. In other cases, where the expected volume of RPAS is much higher, and the expected operators are numerous and diverse, a more complex or integrated system may be required to address product support responsibilities.

Some of the key questions that should be answered by the Plan for Product Support are:

  • (a) How will the applicant maintain contact with operators that use their system?

  • (b) What service standard will the applicant maintain with their operators? How quickly will operator reports be acknowledged by the applicant, and addressed if needed?

  • (c) How will the applicant maintain a record of how many of their systems are currently operating?

  • (d) How will the applicant track the approximate number of flying hours their systems experience per year?

  • (e) How will an operator contact the applicant if the operator experiences a safety issue with the RPAS?

  • (f) What guidance will the applicant give to operators to help them identify reportable issues?

  • (g) How will the applicant contact operators if a design flaw is discovered that requires operators to perform a mandatory action on the RPAS?

  • (h) How long does the applicant expect to provide service and updates to this product?

  • (i) How will the applicant support modifications and repairs that operators may need to make to the product?

Many of the technologies and designs found in RPAS are novel, and often do not have a service history that can be relied upon to predict future operations. This can result in unexpected problems or service difficulties during operation. The plan for product support describes how the applicant will track, evaluate and resolve these unexpected problems. The intent is to ensure that any issues that could affect safety that were not caught during the design and testing of the RPAS can be found and addressed after the RPAS is in service.

7.0 Responsibilities

7.1 Responsibilities of all Declaration Holders

(1) Declarant

  • (a) Having made a safety assurance declaration, declarants have ongoing responsibilities that ensure that their RPAS declaration remains valid, and their RPAS continues to comply with the applicable sections of CAR Standard 922.

  • (b) If there are any procedures or operating limitations needed to ensure that the RPAS remains compliant to the applicable sections of CAR Standard 922, the declarant must make this information available to operators of the declared RPAS (ref CAR 901.78). At a minimum this information must include maintenance programs, a list of mandatory actions, and RPAS operating manuals.

    • (i) A maintenance program includes information about any actions that the declarant requires the operator to carry out that meet the CAR definition of maintenance (ref CAR 101.01: Maintenance means the overhaul, repair, required inspection or modification of an aeronautical product, or the removal of a component from or its installation on an aeronautical product.) The maintenance program should include enough information that the operator or authorized third-party can correctly carry out the required tasks. Some simple tasks (ensuring fasteners are tight, some software updates, replacement of some parts) might be performed by the operator by following declarant instructions. Other more complex task might require that the operator return all or parts of the RPAS to the declarant (or declarant designated facilities) for overhaul or other complex maintenance tasks.

    • (ii) Mandatory Actions are defined as any action that needs to be done to ensure continued compliance with CAR Standard 922. These actions could be known to the declarant at the time of making the declaration, or they could be developed at a later date to address service difficulties that the RPAS encountered in the field (refer to service difficulty reporting below). Some mandatory actions might overlap the maintenance program tasks described above (i.e. “re-torque propeller fasteners every 10 hours of flying time”, “repack parachute every 12 months”). Other mandatory actions might take the form of procedures or operational limitations on the RPAS (i.e. “initiate self-test of system prior to each flight”, or “no flight in known icing”). Mandatory actions should be carefully written with the intended operator in mind. The declarant must ensure that there is enough detail in the mandatory action that the operator can accomplish the mandatory action successfully. If there is any doubt that the operator can successfully perform the mandatory action, then the declarant should consider having the operator send the RPAS either back to the manufacturer, or to an authorized third party who is able to correctly execute the mandatory action (i.e. “Return the RPAS for overhaul”).

    • (iii) RPAS Operating Manuals are a critical part of the documentation provided by the declarant to the operator of the RPAS. The minimum requirements for an Operating Manual are listed in CAR 901.78(c). From the operating manual, the operator should be able to fully understand any aspect of the system they need to safely operate the RPAS in a manner that maintains compliance with CAR Standard 922.

  • (c) If a declarant becomes aware any reason why their RPAS no longer meets the declared CAR 922 standard, the declarant is required to inform Transport Canada as soon as possible. This discovery could be due to a reported service difficulty, some change to the design, or simply the fact that the declarant does not want to continue to support the RPAS design in question. This notification can be sent to <TC.RPASDeclaration-DeclarationSATP.TC@tc.gc.ca>, and will result in the RPAS in question being removed from the active Declaration list.

  • (d) The declarant must keep any documentation or other records used to substantiate their declaration and make these available to the Minister on request (ref 901.79). This documentation may include system requirements, industry standards, test procedures and reports, and engineering analysis. TCCA will occasionally perform surveillance of declarations, by sending a request for this documentation to the declarant. Failure to produce this documentation may result in invalidation of the Declaration.

  • (e) Declarants should be aware that the CAR Standard 922 might not be the only regulatory requirement needed before an RPAS can legally be operated in Canada. Depending on the particular RPAS and operation, declarants may need to consider other Canadian regulatory frameworks that could include (but are not limited to):

    • (i) Radio Frequency Spectrum licensing: Ensure that any RF links operate on frequencies allocated for their use in Canada, and where applicable that appropriate licenses and permissions are sought from Industry, Science, and Economic Development Canada.

    • (ii) Transportation of Dangerous goods regulations are followed.

    • (iii) Where the product is manufactured outside of Canada, any international trade and importation regulations are respected.

    • (iv) Any other rules related to the importation/sale/operation of a product in Canada that might be applicable.

(2) Operators

  • (a) Operators of RPAS with associated safety assurance declarations have responsibilities under CAR Part IX Div III and Div IV which include ensuring that their RPAS has an active an appropriate safety assurance declaration prior to operation in a category that requires this declaration (Ref CAR 901.69). Beyond this, operators must follow all manufacturer instructions (Ref 901.31), ensure that all mandatory actions are completed, and that all systems required by CAR Part IX are installed and serviceable (ref CAR 901.29).

  • (b) Because of these operator responsibilities, it is important that declarants clearly state in operating instructions and mandatory actions if there are any tasks or procedures that might differ depending on the type of operation that is performed (i.e. when not operating over people it might be acceptable to remove a parachute until to increase payload and/or flight time). It is the responsibility of the declarant to provide the operator with all information necessary to allow for safe operation of the RPAS.

7.2 Responsibilities Specific to Pre-Validated Declarations

The holder of a Pre-Validated Declaration and the operator of the subject RPAS have additional responsibilities beyond other safety assurance Declaration holders and operators to ensure the safety of the operation, and continued compliance with CAR Standard 922. The sections below describe these additional responsibilities.

(1) Declarant

  • (a) The declarant will be required to establish a service difficulty system to support the operations of their RPAS in the field and investigate issues that might invalidate their PVD (ref CAR 901.197 and 901.108). This monitoring could simply be the manufacturer making themselves available to operators to consult if there is a problem. A regulatory requirement exists that requires PVD holders to analyze each SDR received (ref. CAR 901.198), and if a problem is found that invalidates their declaration in some way the manufacturer would be required to develop a mandatory action that addresses the service difficulty.

  • (b) The declarant is required to submit an annual report to transport Canada (rev CAR 901.199). This report will include a summary of any service difficulties experienced by the RPAS during the previous year.

  • (c) Submission of the annual report effectively renews the PVD for the next calendar year. A failure to provide an annual report before the required date will invalidate the applicable PVD, however, the PVD would be reinstated following the submission of a late annual report. Declarants should be aware that operators are dependent on the submission of an annual report to ensure the continuance of operations in PVD environments. If a manufacturer fails to submit an annual report, the PVD will be marked as inactive by TC and registered owners of this RPAS will lose any operational privileges that are based on the PVD.

(2) Operator

  • (a) Declarations generally assumed that the RPAS is operated as intended and following all operating instructions provided by the manufacturer as well as the declarant. As discussed above, it is important that declaration holders provide operators with all procedures and instructions required to ensure the RPAS is operated safely and correctly. Conversely, operators are also responsible for following all operating manual instructions and inspection requirements set forth by the declarant (CAR 901.31). Failure to do so may invalidate the privileges bestowed on the operator by the pre-validated declaration.

  • (b) An operator who is using a PVD RPAS is required to inform the manufacturer if they have a problem with their RPAS that affects safety (ref CAR 901.51). To facilitate this, the holder of a PVD is required to provide a contact point that can be used if a service difficulty occurs (ref CAR 901.197). It’s also expected that declaration holders will provide guidance to operators regarding what might constitute a reportable problem with the RPAS. It is the responsibility of the operator to understand how the declarant receives SDRs and to ensure that, in the event a service difficulty occurs, the appropriate reporting channels are used.

8.0 Annual Reports

8.1 Overview

(1) To retain an active Pre-Validated Declaration for a particular RPAS make and model, the entity who has made the declaration is required to submit an annual report to Transport Canada that provides information on the operation and safety performance of that RPAS over the previous calendar year. The annual report is a concept adapted from traditional aviation and is intended to provide confidence that RPAS operating under pre-validated declarations are doing so safely, and reliably. TC will also use the data in these reports as part of routine reviews of the CAR Standard 922 requirements to evaluate the effectiveness of compliance with broader aviation safety objectives.

8.2 Who Submits Annual Reports

(1) Annual reports need to be submitted by any declaring entity with an active pre-validated declaration. Often, the person responsible for submission will be the same person who made the formal declaration of compliance to Transport Canada. In cases where a larger organization has made the declaration, the submission of the annual report may be delegated to a specific member of the organization. In general, the person or group responsible for submitting the annual report should be identified in the plan for product support that was submitted during the application phase of the PVD.

8.3 When is the Annual Report Submitted

(1) Annual reports are due on the anniversary of the day that the subject declaration was submitted. Annual reports will be accepted by Transport Canada starting 30 calendar days before this anniversary. As will be discussed below, if the anniversary of the declaration passes, and no annual report has been received, the applicable pre-validated declaration becomes invalid. If an annual report is submitted late, the pre-validated declaration will be reinstated immediately, but the anniversary is unchanged (the next annual report will still be due on the anniversary that the initial declaration was made. In the event the declaration was made during a leap year on February 29th, the following years declaration will be due February 28th.

8.4 What does the Annual Report Contain?

(1) An annual report consists of answering the following questions:

  • What system does this PVD apply to?

  • How many aircraft / systems are currently operating in Canada?

  • Approximately how many flight hours / operational hours have been accumulated in the past year?

  • How many Reportable Service Difficulties were reported this calendar year?

  • Did any Reportable Service Difficulties result in mandatory actions? If yes, describe the difficulty, and the resolution.

(2) The annual report needs to identify the exact system for which the report applies. This needs to match the system name and part number that is referenced on the applicable pre-validated declaration.

(3) The declaring entity needs to provide an estimation of the number of hours their fleet has collectively accumulated in Canada in the last year. The exact method by which this number is counted or estimated is left to the declaring entity. For a more sophisticated RPAS or a declaring entity that is closely associated with a specific operator, it might be easy to determine the exact number of hours flown in the preceding year. Other declaring entities might need to make assumptions about the number of operations that owners of their systems perform and extrapolate to estimate the number of hours flown by the fleet.

(4) The declaring entity needs to indicate the number of SDRs they have received from their operators. While each service difficulty received by the declarant must be investigated and assessed (ref CAR 901.198), it is understood that not all service difficulties will affect declared compliance with CAR Standard 922.

(5) The annual report must include a summary of any service difficulties that resulted in mandatory actions. The summary should include enough information about the difficulty and the resulting mandatory action that a reader can understand what problem was experienced by the operator, how the failure affected compliance with CAR Standard 922, and how the mandatory action ensures the RPAS remains fully complaint with the declaration.

8.5 Submission of Annual Reports

(1) TCCA provides a template to assist in the completion of Annual reports. This template can be completed by the declarant and then emailed to the TCCA declarations inbox at

TC.RPASDeclaration-DeclarationSATP.TC@tc.gc.ca

8.6 Due Date for Annual Reports

(1) Annual reports are due on the anniversary of the associated declaration. Reasonable allowance is made for annual reports to be made slightly earlier to accommodate certain calendar conflicts (weekends, holidays, etc.). The annual report should not be submitted more than 30 calendar days before the anniversary date of the associated declaration.

8.7 If an Annual Report is Not Submitted

(1) The key difference between a Declaration and a Pre-Validated Declaration is that a PVD is supported by the Letter of Acceptance and the submittal the annual reports. Failure to submit the annual report does not in itself invalidate the declaration made by the declarant, however, it does invalidate one of the key substantiating elements of the PVD. Therefore, if an annual report is missed, the Pre-Validated Declaration will become a Declaration. This may result in the loss of operational privileges for the associated RPAS.

(2) Upon receipt of an annual report that was submitted late, the PVD status of the declaration will be reinstated as unless there are extenuating circumstances (surveillance is in process, there are known issues with the RPAS, etc.). Operational privileges provided by the PVD will also restart upon receipt of the annual report.

9.0 Modifications to Declared RPAS Systems

9.1 Overview

(1) Given the varied and often unique nature of RPAS operations, there are many times that an RPAS may need to be modified to complete a particular operation. An RPAS modification is any change to the RPAS beyond simple repairs specified by the manufacturer. This includes, but is not limited to, structural, electrical (including software), or mechanical changes. Modifications can be temporary, or permanent.

(2) Operators must use their judgement when deciding if a particular action constitutes a modification. Some modifications might follow procedures provided by the manufacturer in their operating instructions. Other modifications might be made by the operator with little or no guidance provided by the manufacturer. Whether or not manufacturer approval or instructions are required for a modification depends on the operation that is being performed, and the type of safety assurance declarations that have been made against the RPAS in question.

9.2 Rules for modifying RPAS with associated Declarations

(1) When modifying an RPAS that has an associated safety assurance Declaration, there are a few questions for the modifier to consider. First, does the intended operation make use of the declared capabilities of the RPAS. For example, if intended operation is VLOS with a small RPA that will not take place in controlled airspace or near/over people (i.e. a Basic Operation), a modifier does not need to consider whether their modification affects the status of the declaration. Fundamentally, the operator is still required to consider whether or not their modification constitutes reckless or negligent operation (per CAR 900.06).

On the other hand, if a small RPA VLOS operation includes operation in controlled airspace, near or over people, that operation does require that the RPAS used have active safety assurance declarations against it. CAR 901.70 requires that the modifier be able to demonstrate that their modification does not affect the status of the safety assurance declaration. This demonstration requires that modifiers have an understanding of how their RPAS complies with the relevant sections of Standard 922. They must also consider how their modification might affect any aspects of the RPAS that are required to meet the safety standard. If an RPA uses a parachute to meet 922.06 (Operations over people), then the modification must be done in such a way that operation of the parachute when integrated into the RPAS continues to meet the requirements. This will generally include analysis and even testing of the RPAS with the modification in place to ensure that the RPAS remains within compliance. RPAS modifications should be tested (in a Basic Operational Environment, CAR Part IX Div IV) to ensure that the RPAS performance is unaffected before an operation needing a safety assurance Declaration is performed.

(2) Manufacturers and other declaring entities should consider the common modifications that operators may wish to perform on the subject RPAS. If there are considerations or limitations that operators and modifiers should be aware of prior to making modifications, these must be communicated in the operating manual for the RPAS. Examples may include sensors that must remain unobstructed, or mass / electrical limitations to be respected. Any RPAS sub-systems (i.e. parachutes, actuators, motors) that need specific clearance areas to operate correctly should be defined in the manufacturer documentation. RPAS modifiers are still required to follow manufacturer supplied operating instructions. Therefore, if there are any modifications to an RPAS that are prohibited, these limitations should be described in the RPAS operating manual.

9.3 Rules for modifying RPAS with associated Pre-Validated Declarations

(1) Operations that require pre-validated declarations are higher risk than operations that only require safety assurance declarations. For this reason, modifications to RPAS that are conducting these operations need to be approved by the entity responsible for the pre-validated declaration in question. Operators or modifiers must consult the RPAS documentation to determine the scope of acceptable modifications and follow any procedures provided by the declaring entity when modifying these RPAS. If a particular modification is not covered by existing documentation from the declaring entity, the modifier may decide to reach out to the declaring entity to have their modification approved. In situations where this is impossible, another option for the modifier is to become a declaring entity themselves and seek their own pre-validated declaration for the modified RPAS. My taking the role of declarant, the modifier takes on the responsibility not only for their modification, but for the fact that the entire RPAS meets the declared standards. The modifier also takes on all the responsibilities of a declarant, including the production of manuals, establishing a service difficulty reporting system, and making annual reports to Transport Canada on the status of the RPAS.

(2) Manufacturers and declaring entities who are making pre-validated declarations should consider carefully what modifications they want to allow their operators to make. There is a trade-off to be made between allowing operators flexibility, and simplifying the test and analysis that is required to demonstrate that an RPAS complies with CAR Standard 922. A declaring entity who wants to offer more flexibility to end users should be aware that they have the responsibility to demonstrate that the RPAS complies with the declared standards even after any of the allowed modifications are made. In contrast, declaring entities may choose to allow minimal or no modifications to their RPAS. Depending on the particulars of the RPAS this may greatly simplify the required tests and analysis needed to demonstrate compliance to CAR Standard 922.

(3) When the operation in question does not require a pre-validated declaration be in place, modifications are allowed based on operator/modifier judgement. As an example, a Medium RPAS that has a pre-validated declaration for operations near or over people (ref CAR 901.69(f) and (g)), may be modified outside of what is allowed by the declaring entity, provided that after the modification, the RPA is only operated away from people (ref CAR 901.69(e)). Any modifications that are not specifically allowed by the manufacturer would need to be removed from the RPAS prior to any VLOS operation near or over people.

9.4 RPAS Design Changes that may impact the PVD Application

(1) In the discussion above on modifications, it’s assumed that the modifications are limited in scope, not by the declaration holder, and not made to the entire fleet associated with the Declaration or Pre-Validated Declaration. In cases where the declaration holder is making design changes to their RPAS, the declarant needs to consider whether the design change affects any of the information submitted in the PVD application is changed. If the design change does not affect any part of the PVD application documentation, then a new PVD application will not be required. It is the responsibility for the declarant that any applicable tests, or evaluations that they committed to during the PVD application phase are performed on the updated make and model to ensure continued compliance with the declared standard.

(2) The key test in determining if a design change requires a new PVD application is to determine if any aspect of the PVD application needs to change. For example minor hardware or software changes that can be validated using the MOC identified in the PVD application would generally not require a new PVD application. In contrast, modifications involving extensive changes that would invalidate the assumptions made in the Notional CONOPS or change the proposed means of compliance would require a new PVD application and review. In cases where the declarant is unsure if a modification would necessitate a new PVD application, the declarant is invited to consult with TCCA to assess the situation.

9.5 Modification Impact Analysis

(1) General. It is recommended that PVD holders have a process for analyzing the impact of any modifications they make to their associated system or service. Documenting and retaining analysis as well as any supporting verification such as test results, is necessary as this is compliance data that Transport Canada reserves the right to review on request (ref CAR 901.XX).

The analysis should first determine if the impact of the modification will result in a modified system that requires a new PVD to be made.

If it does not, then the analysis should show that the modification does not impact the existing PVD for the system and include any supporting verification performed. This verification may range from an engineering analysis through to ground and flight-testing dependent on the extent and complexity of the modification.

Given the variety of RPAS and services, concepts of operations and requirements that may be part of a declaration a prescriptive impact assessment cannot be provided. The following sections provide guidance for analyzing impact and conducting verification that a PVD holder can use to develop a process specific to their system and organization.

(2) Determining Modification Impact. Modifications may fall into one of two categories: (1) modifications which affect the declared capabilities of the RPAS, and (2) modifications which do not affect the declared capabilities of the RPAS. The contents of a declaration for an RPAS are outlined in CAR 901.194(2). This declaration is based on the application for which an acceptance letter has been received per CAR 901.196. This application and declaration form the baseline of the PVD that any modification must be assessed against. The main elements of this baseline are summarized below.

  • (a) Concept of operations

    • (i) Technical description of the system and its elements, including principal design features and specifications.

    • (ii) Standard 922 requirements the system meets.

    • (iii) Configurable elements the system is comprised of.

    • (iv) Operations the system is intended to conduct/support.

    • (v) Operating limitations.

    • (vi) Operational procedures including any required integration and testing.

    • (vii) Instructions for the servicing and maintenance of the system.

  • (b) Declaration Plan

    • (i) Means used to demonstrate compliance to the Standard 922 requirements, including methods (analysis and tests etc.) and industry standards used.

  • (c) Statement of Technical capability

    • (i) Technical capability to design, build, test as well as support manufacture and in-service operation of the system.

  • (d) Plan for Product support

    • (i) Capability to support the system in service including plan for which elements can be operator maintained/modified and which require return.

    • (ii) Analyzing and acting on service difficulties reported by operators.

  • (e) Manufacturing capability (if applicable)

    • (i) Manufacturing processes, quality control, configuration management and sub-contractor management.

  • (f) Plan for Service commissioning (if applicable)

    • (i) Procedures and tests for service activation and functional verification.

(3) When analyzing impacts, the first determination should be whether the modification will require a new PVD. This will be primarily focused on whether the modification will result in a significant impact to the Concept of Operations but can include other elements of the declaration. Guidelines for assessing this are provided below:

  • (a) Fundamental changes to the system.

    • (i) The system type, design and construction has been significantly changed. e.g. Modifying from a fixed-wing to a hybrid aircraft.

    • (ii) The operations supported have significantly changed including procedures and limitations. e.g. Going from VLOS to BVLOS operations.

  • (b) Technical requirements from Standard 922 that the system was declared as meeting.

    • (i) Removal or modification of elements or functionality that were needed to meet the technical requirements. e.g. changing to a less reliable motor such that the system no longer meets the Safety and Reliability requirement.

  • (c) Substantially changing the way, the system meets a technical requirement.

    • (i) e.g. Complete redesign of the control station user interface.

  • (d) Technical requirements from Standard 922 that the system was not declared as meeting.

    • (i) Addition of elements or functionality intended to provide a capability covered by Standard 922. e.g. Adding a DAA system to an RPAS that was not declared for requirement 922.10

  • (e) Other areas that form part of the declaration.

    • (i) Impacts to or exceeding the technical capability, ability to support, manufacture etc. e.g. Modifying the system to add technology for which the holder has no declared technical capability to design or ability to support.

(4) A significant impact to any of the aspects of the RPAS described above, will generally result in the need for a new PVD.

(5) Modification Impact Analysis. The majority of analyses conducted by PVD holders will be focused on showing that the modification has not significantly changed their declaration and the necessary verification to support it. A modification impact analyses should include the following elements –

  • (a) Detailed description of the change

  • (b) Assessment of impacts on the declared baseline:

    • (i) Concept of operations – Detailing all areas of the con-ops impacted by the change including configuration, performance, operational capability/functionality and ability to meet requirements. Of particular importance are any safety related impacts to areas such as:

      • (A) System safety assessments and potential new failure conditions.

      • (B) Changes to the operation of the system.

      • (C) Changes to the environmental envelope of the system.

    • (ii) Compliance – Determining what verification will be needed to ensure compliance is being maintained.

  • (c) Technical capability – Determining if the applicable skill sets are available for the design and implementation of the modification.

  • (d) Product support – Determining impacts to the support of the system in the field.

  • (e) Manufacturing capability (if applicable) – Impacts to areas such as manufacturing processes, maintaining new configurations, new suppliers etc.

  • (f) Service commissioning (if applicable) – Any impacts to the commissioning of the service including changes to procedures, tests etc.

  • (g) Other areas of consideration

    • (i) Secondary impacts – Determine if there are any potential secondary impacts as a result of the modification.

    • (ii) e.g. Potential EMI impacts as a result of additional wiring or a new transmitter

  • (h) Cumulative changes - Previous changes should be considered in the assessment to prevent the impact of cumulative modifications resulting in undesirable behavior or issues. e.g. A significant number of small modifications to the RPAS structure may result in an impact to the environmental envelope that the system can operate in.

(6) Verification of the modification. As part of the modification impact analysis there will be some form of verification required. A conservative approach would be to repeat the means of compliance used for the original PVD. However, it is recognized this may not be required for relatively simple changes.

The verification serves to confirm both that the added change or function is working as intended and that there have been no unintended impacts on the rest of the system. The analysis should identify the areas, components, and functionality where verification should be performed to ensure there are no unintended impacts. For all impacted requirements the means of compliance used for the declaration should be used as a reference for the verification needed.

The general guideline is that the rigor of the verification should be driven by:

  • Modifications that impact safety related components and/or functionality.

  • The extent and size of the modification (number of components and/or functionalities impacted).

The verification methods referenced in the means of compliance will typically vary. Examples of methods are provided below:

  • Inspection or Review – Examination of specifications, drawings, design documents, hardware, software code etc.

  • Service Experience – Where a component or sub-system has been used successfully on a similar system.

  • Technical Analysis – This can vary from simple engineering calculations to more complex mathematical modelling and computer simulation.

  • Testing or Demonstration – This can vary from a simple functional demonstration of the modified system to more rigorous testing where data is collected for subsequent analysis. This can take place in different environments from lab tests of individual components, hardware in the loop testing in simulated environments to ground or flight testing of the complete system.

The level of rigor for the verification can vary from a relatively straightforward review of a component specification to a lengthy flight test program. In some cases, the modification may use a variety of these verification methods to cover various aspects of the modification.

Some examples of this may be:

  • For a simple component such as a bolt or fastener the verification could be a simple inspection of the component specification sheet to ensure it has the same dimensions, weight, tensile strength etc.

  • For a more complex modification such as the addition of a sensor payload the verification could use multiple methods. Service experience to show the sensor had been successfully used on similar platforms. A technical analysis to show there was sufficient power and link bandwidth to support it’s use. Simulation to show it should not significantly impact the flight characteristics of the system. A flight test to demonstrate the functionality and collect data to verify there are no impacts on the handling characteristics.

(7) Software considerations. While the guidelines for modification impact analysis can be used, they are not intended for relatively minor bug fixes.

For software updates that involve functions where development using an industry standard is required (e.g. Standard 922 requirement 922.08) and declared under the PVD, the test and verification methodologies from that standard should be used.

(8) Modification Management. Configuration management (Section 6.7) will be impacted by modifications and declarants should incorporate this in their processes. This should also include areas like internal impact analysis review and authorization by the declarants technical resources.

If intended as a user implemented modification, then instructions should be developed. These instructions should include functional checks to ensure that the modification has been implemented correctly. Note that these functional checks do not necessarily need the same rigor as the original verification.

10.0 Service Difficulty Reporting and Mandatory Actions

10.1 Overview

(1) It is expected that all RPAS will eventually experience some kind of service difficulty during operation. The goal of Service Difficulty Reporting and Mandatory Actions is to minimize the hazard associated with these service difficulties and the chance of repeated service difficulties. It’s recommended that all RPAS manufacturers have some means of monitoring that their products are operating as expected throughout their service live. For declarants of pre-validated declarations however, it is a regulatory requirement to investigate any service difficulties reported to you (ref CAR 901.198).

(2) Service Difficulty and Reportable Service Difficulty, as used here are terms defined in CAR 101. A Service Difficulty is any failure, malfunction, or defect in an aeronautical product. A Service Difficulty only becomes a Reportable Service Difficulty when its occurrence is likely to affect the safety of an aircraft, its occupants, or any other person. For the purposes of Part IX, a Service Difficulty becomes a Reportable Service Difficulty if it results in unexpected damage to the RPAS, injuries to people, or creates a risk of collision with another aircraft (ref CAR901.49).

(3) When the operator of an RPAS that is referred to by a Pre-Validated Declaration has a Reportable Service Difficulty, they are required to report it to the holder of that Pre-Validated Declaration (ref CAR 901.51). Any time an RPAS with a PVD has a failure or malfunction that the operator believes could result in injury, damage to the aircraft, to any configurable element of the RPAS system, or to another aircraft, the operator will report this incident to the holder of the Pre-Validated Declaration.

(4) The Pre-Validated Declaration holder has a responsibility to investigate all SDRs that it receives (ref CAR 901.198). The focus of this investigation, initially, is to determine if the RPAS continues to comply with the technical requirements of the Declarations. It is acknowledged that not all Service Difficulties are a result of a problem with the RPAS itself, and therefore not all Service Difficulties will require a technical fix on the part of the PVD holder. However, if the SDR investigation determines that the Service Difficulty is a result of or could result in the RPAS no longer meeting the technical requirements of the Declaration to CAR Standard 922, the PVD holder must develop a mandatory action to address the situation.

(5) If the results of the SDR Investigations show that a mandatory action is required, the PVD holder must develop the instructions to perform as well as any supporting artifacts required to carry out the mandatory action. Supporting artifacts might include firmware updates for the RPAS, new mechanical or electrical components or updated procedures or operating limitations. The PVD holder is responsible for distributing the mandatory action instructions and supporting artifacts to all operators of the RPAS.

(6) Even if the investigation into the SDR determines that compliance with CAR Standard 922 is unaffected, (i.e. the SDR resulted from operator error), declarants are still strongly encouraged to consider if some improvement to the RPAS or documentation could prevent future occurrences of similar events.

(7) The method that the PVD holders use to communicate mandatory actions to users of the RPAS is left up to the PVD holder. Distribution of mandatory actions will vary greatly depending on the size of an RPAS fleet, the number of operators, and the relationship between the declaration holder and those operators. Part of the PVD application includes a plan for Service Difficulty Reporting and support and it is expected that the PVD holder will follow the process outlined during their PVD application for contacting operators of their product as required to communicate the required information to satisfy their CAR 901.200(b) responsibilities.

(8) The CAR 901.200 responsibilities of declarants do not end when the operator takes over care and control of the RPAS, but extend throughout the service life of the declared model of RPAS. So long as the declaration is active, any updated instructions, procedures, maintenance, and mandatory actions that are required to maintain compliance with the declared CAR standard must be communicated to operators. This ensures that safety and airworthiness of the RPAS is maintained throughout its service life by providing operators with the tools and information required to operate the RPAS safely.

(9) Holders of Pre-Validated Declarations are required to document the results of their SDR investigations and keep these results in case they are requested by the Minister for review (Ref CAR 901.201). In addition, any investigations that resulted in mandatory actions must be reported in the soonest annual report related to the RPAS in question (ref CAR 901.199(2)(d)).

11.0 Other Best Practices for Declarants

11.1 RPAS Model Naming Conventions

(1) All declarations require the declarant to identify the applicable RPAS, and this is generally done with a make and model name selected by the declarant. The make and model name should be specific enough that a clear association can be made between the declaration and the applicable RPAS. Care should be taken to avoid reusing RPAS model names as this can lead to confusion among operators who need to know what declarations apply to a particular RPAS.

(2) In some cases, declarants may elect to identify their RPAS in their declaration using a part number assigned to the RPAS by their internal engineering document structure. This is acceptable however, the declarant needs to ensure that operators of their RPAS are provided with clear information indicating what declaration(s) apply to what models of RPAS.

(3) Care should be taken to ensure that the make and model clearly distinguishes the declared RPAS from other RPAS. For declarations that involve specific configurable elements (i.e. parachute installations), the make and model should include all details required to identify the necessary components of the RPAS (i.e “ABC MultiRotor 9000 equipped with a XYZ Model 2 PRS”).

11.2 Continuity of Contact Information

(1) A major responsibility of declarants is providing substantiation information to the Minister when requested. The Minister may elect to contact declarants at any time and will use the email address provided by the applicant to make these requests. Failure to respond to these email requests may result in invalidation of the declaration and the subsequent loss of operational privileges. For this reason, it is important that the contact information be correct and up to date.

(2) It is understood that for some declarants, the individual responsible for the declaration may change from time to time (i.e. a new director of engineering is appointed). When this is a concern, declarants may elect to provide a generic inbox (i.e. airworthiness@company.com) rather than contact information for a specific individual.

12.0 Information management

(1) Not applicable

13.0 Document history

(1) Not applicable

14.0 Contact office

For more information, please contact:

Transport Canada RPAS Task Force, Engineering (AARV)
4th Floor, Place de Ville, Tower C
330 Sparks Street, Ottawa, ON, K1A 0N8

E-mail address: TC.RPASInfo-InfoSATP.TC@tc.gc.ca

Suggestions for amendment to this document are invited, and should be submitted via the contact information above. Any questions related to the Declaration or Pre-Validated Declaration processes can be addressed to the Declarations inbox: TC.RPASDeclaration-DeclarationSATP.TC@tc.gc.ca

Document approved by

 

Ryan Coates
Director, RPAS Task Force

Appendix A – Recognized industry consensus standards

Documentation

ASTM F2908-18 Standard Specification for Unmanned Aircraft Flight Manual (UFM) for an Unmanned Aircraft System (UAS)

ASTM F2909-14 Standard Practice for Maintenance and Continued Airworthiness of Small Unmanned Aircraft Systems (sUAS)

Electrical Systems

UL 3030 Standard for Unmanned Aircraft Systems

ASTM F2639-15 Standard Practice for Design, Alteration, and Certification of Aircraft Electrical Wiring Systems

ASTM F2490-05(2013) Standard Guide for Aircraft Electrical Load and Power Source Capacity Analysis

SAE AS 4805-2007, Solid State Power Controller, General Standard For

SAE AS 50881F, Wiring Aerospace Vehicle

Equipment

ASTM F3322-18 - Parachutes

ASTM F3002-14a Standard Specification for Design of the Command and Control System for Small Unmanned Aircraft Systems (sUAS)

ASTM F3005-14a Standard Specification for Batteries for Use in Small Unmanned Aircraft Systems (UAS)

SAE AS 8033, Nickel Cadmium Vented Rechargeable Aircraft Batteries (Non-Sealed, Maintainable Type)

SAE J3042-2015, Measuring Properties of Li-Battery Electrolyte

SAE J3021-2014, Recommended Practice for Determining Material Properties of Li-Battery Cathode Active Materials

SAE ARP 5724, Aerospace - Testing of Electromechanical Actuators, General Guidelines For

TSO-C213-Unmanned Aircraft Systems Control and Non-Payload Communications Terrestrial Link System Radios

Human Factors Evaluation

ISO 9241-210

MIL-STD-46855A

Aeronautical design standard performance specification handling qualities requirements for military rotorcraft ADS-33E-PRF

Display Guidance: AC23.1311-1C

Software

ASTM F3201-16 Standard Practice for Ensuring Dependability of Software Used in Unmanned Aircraft Systems (UAS)

ASTM F3269-17 Standard Practice for Methods to Safely Bound Flight Behavior of Unmanned Aircraft Systems Containing Complex Functions

RTCA DO-178C

Safety Assessment

AC 23.1309-1E

JARUS AMC RPAS.1309, Safety Assessment of Remotely Piloted Aircraft Systems

SAE ARP 4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment

SAE ARP 4754a – Guidelines for Development of Civil Aircraft and Systems

ASTM F3309/F3309M - Standard Practice for Simplified Safety Assessment of Systems and Equipment in Small Aircraft

ASTM F3230 – Standard Practice for Safety Assessment of Systems and Equipment in Small Aircraft

Aircraft F3389/F3389M-20 Standard Test Method for Assessing the Safety of Small Unmanned Aircraft Impacts - Method A for RPA MTOW <1 kg, Method B for RPA MTOW <4 kg and Method C for others using the thresholds identified in Appendix C of this document.

Design Specifications

ASTM F3298-19 Standard Practice for Design, Construction, and Verification of Fixed-Wing Unmanned Aircraft Systems (UAS)

EU CE Designations, Appendices 2-5

JARUS CS-LUAS, Recommendations for Certification Specification for Light Unmanned Aeroplane Systems

JARUS CS-LURS, Certification Specification for Light Unmanned Rotorcraft Systems

STANAG 4703 Light UAV System Airworthiness Requirement for NATO UAV Systems

TCCA SI 623-001 Issue 02 Appendix C

ICAO Doc 10019 - Manual on Remotely Piloted Aircraft Systems (RPAS)

Note: Satisfying the standards that have been developed for large systems and/or traditionally piloted aircraft is one acceptable means of compliance but not mandatory for the operation of small RPAS.

  • (1) The manufacturer may consider using parachutes in case of emergency conditions; ASTM provides standard in regards to parachutes refer to appendix A of this AC.

AC 901-001 - Remotely Piloted Aircraft Systems Safety Assurance Declaration and Pre-Validated Declaration Processes (PDF, 470 KB)

 
Date modified: