EUROCAE ED 272
MINIMUM AVIATION SYSTEMS PERFORMANCE STANDARDS FOR REMOTE PILOT STATIONS CONDUCTING IFR OPERATIONS IN CONTROLLED AIRSPACE
|Publication Date:||1 August 2020|
SCOPE OF THE DOCUMENT
Context and scope
The market demand for RPAS is permanently growing for years because they are no longer used only for military purposes but also for commercial and civil applications, among which, agriculture & forestry, civil protection & disaster management, surveillance of sea or urban areas, filming. Therefore, integrating RPAS into nonsegregated airspaces, for both civil and military operators, is going to be a must.
On the other hand, a full integration of the RPAS into non-segregated airspace requires the implementation of several RPAS capabilities enabling them to operate safely also in case of occurrences that prevent the Remote Pilot (RP) to control the Remotely Piloted Aircraft (RPA) (e.g. loss of the data-link).
The principles of basic automated functions are largely solved today. However, large RPAS operations are currently restricted to segregated areas, thus making them complex and expensive. This situation will continue until a complete set of standards, procedures, policies, performance specifications, human factors considerations and enabling technologies supporting the safe integration of RPAS is developed and validated.
The intention of this document is to provide a common set of operational, safety, performance and interoperability requirements that enables the standardisation of RPS solutions within EASA's Certified Category, with focus on ATI for IFR operation in controlled airspace.
The reference platform used along this document to define IFR operations is a fixedwing RPAS with conventional take-off and landing capabilities. Nevertheless, this does not preclude the use of parts of this document to other kinds of platforms provided that the corresponding requirements are applicable (e.g. for enroute operation of Vertical Take-off and Landing (VTOL) systems).
Further material derived from this document should contribute in the future to generate a complete RPS standard that can be used as acceptable means of compliance to support the overall RPAS Type Certification process, or even dedicated RPS Type Certification if considered by the certifying authorities. The possibility to obtain a Type Certificate, ETSO or similar for a RPS design (e.g. as it is today obtained for an aircraft engine) will significantly simplify subsequent integrations with different RPASs, with the corresponding savings in the overall certification process.
It has to be noted that in some cases, requirements needed to achieve ATI could partially overlap with the ones provided in existing airworthiness certification standards. That is for example the case for flight and navigation displays and commands: they are required to allow the RP to perform ATCo requests, but at the same time they are also required to ensure airworthiness. Whenever this happens along the document, a reference to corresponding airworthiness standards requirements is also included for traceability.
RPS standardisation aspects with respect to ATI are classified in two major topics: RPS capabilities and interoperability with CNS/ATM systems.
The following overall RPS capabilities are addressed:
• Situational awareness: it displays to the RP the required information to understand the current RPAS status as well as the airspace situation surrounding the RPA. This information includes RPA flight parameters, RPA navigation parameters, RPAS systems status, active flight plan route(s), surrounding traffic and weather information, among others.
• Flight controls and commands: the means to exercise control in the RPS have to be designed in a way to ensure that all potentially required procedures for navigation (e.g. ATC vectoring, diversion to alternate airports, go-arounds…) and systems management (e.g. electric and hydraulic systems of the RPA and RPS, C2-link) can be performed in all nominal and degraded modes. An important assumption of this document is that direct flight control (i.e. "throttle and stick") is not required to achieve these objectives, and that all IFR operations in controlled airspace can be performed by means of high-level commands. This type of control corresponds to Category B - autopilot control of ICAO Manual on RPAS (Ref. [ID.4]). This assumption is detailed in the OSED section of this document.
• Flight planning: this capability comprises the preparation of flight plans, the upload and activation of these flight plans into the RPA systems and in-flight modification of the active flight plans. RPAS flight planning has to consider additional flight plan elements compared to manned aircraft, as contingency and emergency procedures that must be defined in advance e.g. to deal with link loss situations. Performance Based Navigation (PBN) features are required to ensure mid-term support of IFR operations, and future SESAR capabilities like trajectory-based navigation and SWIM connectivity must be also considered.
• RP-ATCo communications, including voice and Controller-Pilot Data Link Communications (CPDLC).
• Voice and data recording for accident/incident investigation purposes
Regarding interoperability, a key aspect in RPAS is the physical interface to support RP-ATCo communications. The current nominal approach is to use radio communications to allow transparent use of existing CNS/ATM infrastructure. But this solution requires using the RPA as a relay between the RPS and the CNS/ATM system, which drives to significant drawbacks: increased communication delays, additional bandwidth consumption in the C2 link and loss of RP-ATCo communications when the C2 link is lost. A direct interface between CNS/ATM and the RPS will solve the issues mentioned. More detailed discussions concerning the communication relay issues and potential solutions are detailed in ANNEX D of this document. The goal of this annex is to propose a preliminary set of requirements that could be the basis to standardise a direct RPS-CNS/ATM interface in the future.
RPAS are mainly mission oriented, where RPA typically transits to a mission area, executes some mission tasks, and flies back to the operating base (exceptions could exist, as e.g. cargo missions). Therefore, most RPAS (and in consequence RPS) will have to integrate mission capabilities in addition to safe flight and ATI capabilities. Due to the heterogeneous types of missions that RPAS can perform, mission aspects are considered out of the scope of this document, except for the cases in which they can have an impact on ATI capabilities.
The RPS provides the following main logical interfaces:
• With the RPA(s) under control, via the C2 Link. Note that the C2 Link can be composed of one or more RLOS and/or BRLOS physical links.
• With the RP, based on information displays and control devices.
• With CNS/ATM, based on direct connections or using the RPA as a relay. This interface is used to exchange voice and data. Data includes at least CPDLC messages and flight plan information, but in the future could also cover any additional information supported by SWIM.
• With external data providers for support data as maps, terrain elevation models, aeronautical databases, or weather information/forecast
• With the final customer, for mission-related functions. The customer will depend on the type of missions the RPAS is designed to fulfil (e.g. C4I Centre for military missions).
• With the maintenance crew for maintenance related operations
Note that this document does not intend to establish requirements or assumptions on the minimum flight crew required to perform safe IFR operations, as this is left to system designers. The term "Remote Pilot" or "RP" is used along this document in a generic way, irrespectively of the actual number of crew members required to perform the corresponding duties.
The customer interface is out of the scope of this document, as it is mission specific. The interface with the maintenance crew is also considered out of the scope, as it is very dependent on the specific implementation details.
RPS functional architecture
Being the RPS an integral part of the RPAS, it is not possible to perform a stand-alone functional architecture without establishing assumptions on the overall RPAS functional breakdown and allocation between the RPA, C2 Link and RPS systems. The aim of this section is to describe the assumed RPAS functional breakdown, which tries to be as generic and implementation-agnos
The requirements identified in this document are only applicable if the assumed RPAS functional breakdown is valid for the target system under study. Different functional architectures could invalidate some of the requirements proposed. Thus, the designer should use these MASPS requirements where appropriate and applicable. They may not be appropriate for all architectures and concepts of operation.
The RPAS functional architecture and breakdown to lower level systems is depicted in FIGURE 2. Data flows between functions are also shown by means of directional relationship arrows. Functions are described hereafter:
• Manage navigation database (RPS): flight planning relies on navigation databases in accordance with up-to-date Aeronautical Information Publication (AIP). This function provides the means for importing, storing and using this information to support the definition of the flight plan routes and to feed navigation displays during flight.
• Prepare/update flight plan (RPS): it provides means to the RP to prepare new flight plans and to modify active flight plans in accordance with IFR and with the specific characteristics of the RPA, for further upload into the RPA on-board systems. Navigation database is used as reference information. Other support information from external providers could be also considered (e.g. weather data, terrain models, maps). Optionally this function can also support submission of the flight plan to the CNS/ATM System for approval, before actual flight execution. The flight plan preparation function can be provided by the RPS or delegated to an external flight planning tool.
• Validate and upload flight plan (RPS)1: this function ensures that the flight plan provided by the "Prepare/update flight plan" function is safe and contains no errors, and uploads it to the RPA via C2 Link on RP request.
• Receive and validate flight plan (RPA)1: the RPA counterpart of the "Validate and upload flight plan" function. It receives a new flight plan from the RPS via C2 Links, and checks its validity before delivering it to the "Execute flight plan" function for activation.
• Execute flight plan (RPA): manages the execution of the flight plan on-board, like routes activation and waypoint sequencing, either automatically or based on RP commands received from the RPS.
• Perform flight guidance (RPA): determines the desired path from the RPA's current location to the target designated by the "Execute flight plan" function or RP semi-automatic commands, as well as desired changes in heading, speed and altitude for following that path.
• Perform flight control (RPA): manages the actuator's control loops needed to execute flight guidance requests or semi-automatic command targets from the RP whilst maintaining the RPA within the safe and stable flight envelope.
• Command RPA flight (RPS): provides the HMI to receive input commands from the RP and converts them into the proper messages to be transmitted to the RPA. Depending on their type, commands can be processed by the "Execute flight plan" function (e.g. change of active route), "Perform flight guidance" function (e.g. fly to given coordinates) or by the "Perform flight control" function (e.g. target heading or altitude).
• Display navigation data (RPS): it provides awareness about the current navigation parameters to the RP, like RPA position and relative position of other elements such as flight waypoints or navigation fixes. The information is mainly received from the "Execute flight plan" and "Perform flight guidance" functions at the RPA, and from the "Manage navigation database" and "Prepare/update flight plan" at the RPS.
• Display primary flight data (RPS): it provides awareness about current flight parameters to the RP, as received from the "Perform flight control" function at the RPA.
• Manage flight support camera (RPS): it displays the support camera signal to the RP and provides commands to configure the related available settings (e.g. FoV, camera modes).
• Generate flight support video signal (RPA): it generates the flight support camera video signal and distributes it to the RPS via C2 Link.
• Configure flight support camera (RPA): it configures the available camera settings either automatically or in accordance with RP commands received from the RPS.
• Manage DAA system (RPS): this function displays to the RP the information generated by the rest of the DAA functions (traffic tracks, alerts, proposed avoidance manoeuvres, Remain Well Clear (RWC) guidance) and provides the DAA commands required to accept or reject avoidance manoeuvres proposed.
• Generate RWC guidance (RPS)2: this function generates RWC guidance and related alerts based on the traffic tracks provided by the "Detect traffic" function when RWC margins are close to be exceeded.
• Detect traffic (RPA): this function uses RPA on-board sensors to detect traffic surrounding the RPA. This information is sent to the "Manage DAA System" function at the RPS for display and to the "Generate, initiate and abort avoidance manoeuvre" function at the RPA to support generation of the corresponding avoidance manoeuvres where applicable. Note that by the time of writing this MASPS, obstacles and weather detection and avoidance standards for RPAS are not yet developed, and therefore these capabilities are excluded from the scope of the document.
• Generate, initiate and abort avoidance manoeuvre (RPA): it identifies risks based on the detections from the "Detect traffic" function, and generates the required avoidance manoeuvres to avoid them. It also initiates and aborts the corresponding avoidance manoeuvre based on RP inputs from the RPS and/or automatic behaviour rules.
• Display C2 link status (RPS): this function displays to the RP the current C2 link status based on information reported from the "Assess C2 link status" function at the C2 Link System.
• Estimate RPA position in C2 link loss (RPS): this function provides an estimation of the RPA position during C2 link loss, based on last known RPA status, last active flight plan and a representative RPA performance model.
• Assess C2 link status (C2 Link): it gathers C2 link relevant data to assess self-status for reporting to the RPS and to support the "Perform C2 link control" function.
• Command C2 link (RPS): it provides commands to the RP for configuration of the C2 link. Commands are forwarded to the "Perform C2 link control" function at the C2 Link System for execution.
• Perform C2 link control (C2 Link): this function implements the low level control required to maintain positive C2 link during operation (e.g. modem control, antenna steering, monitoring of detailed RF parameters to generate high-level aggregated status, data flows prioritisation and segregation).
• Generate and execute automation proposals (RPA): this RPA function is part of the overall Automation and Emergency Recovery (A&ER) function described in the A&ER OSED (ref. [RD.9]). It generates and executes automation proposals based on internal and external events. Proposals can require RP confirmation, be automatically executed after a timeout period without RP reaction, or even be executed immediately in case of C2 link loss or time-critical, imminent safety hazards.
• Manage automation proposals (RPS): this RPA function is part of the overall A&ER function described in the A&ER OSED (ref. [RD.9]). It displays automation proposals generated by the RPA to the RP, and provides means to the RP to accept, reject or modify the proposed behaviours. It also provides indications in case proposals are automatically triggered by the RPA.
• Manage system alerts (RPS): This function displays to the RP all RPAS alerts, including the RPA, the C2 link and the RPS, in an organised way classified by their criticality, and provides additional attention getters where applicable. It also provides required controls to the RP for alerts management, like browsing related checklists, alerts acknowledgment or suppression of attention getters.
• Manage RPA systems (RPS): this function provides status displays, configuration commands and related alerts to the RP for the on-board support systems required for IFR operations, like lights, SSR transponder and ADS(-B) equipment.
• Monitor navigation systems (RPA): this function monitors the status and performance of the on-board navigation systems and reports it to the RPS.
• Provide surveillance data (RPA): it provides RPA own position and related information to the CNS/ATM system to support surveillance functions via SSR and ADS-B transponders. It also provides status information and receives configuration commands to/from the "Manage RPA systems" function at the RPS to enable the related HMI.
• Provide voice and CPDLC communications (RPS): it provides bi-directional voice and CPDLC communications between the RP and other actors involved in the areas of flight of the RPA. These may include other pilots from manned or unmanned aircraft or the ATC. The communication can be established either via RPA relay or as an alternative, via direct RPS-CNS/ATM connection.
• Relay voice and CPDLC data (RPA): this function relays voice and CPDLC communications received from the RPS to the on-board radio and data link equipment to ensure effective communications within RPA range despite of RPS location.
• Record voice and data (RPS): it records the following data to support incident and accident investigations:
o voice communications between the flight crew members, where applicable
o voice communications between the RP and the ATCo.
o Flight data (status and commands) exchanged with the RPA
• Record voice and data (RPA): it records the following data to support incident and accident investigations:
o voice communications between the RP and the ATCo, where applicable (i.e. when using RPA as relay)
o Flight data generated by the RPA systems
o Commands received from the RPS
A detailed description of the RPS functions and their intended use within the RPS operational context is detailed in the Operational Services and Environment Definition (OSED) and the Operational Performance Assessment (OPA) annexes of the document (ANNEX A and ANNEX B respectively).
RPS physical architecture
RPAs are very heterogeneous and go from very simple, lightweight consumer drones to large Medium Altitude Long Endurance (MALE) and High Altitude Long Endurance (HALE) systems. This broad scope of RPA categories is also propagated to the RPS. Light RPAs might require a simple RPS solution, whereas MALE and HALE RPAs could integrate more complex RPS architectures with several consoles and sometimes, even several stations distributed along different locations. The following main categories of RPS can be considered:
• Portable RPS: mainly designed for micro and mini UAVs and/or VLOS control, the portable RPS integrates computing resources and user displays and controls in a single device that can be transported and operated by just one RP. Typical implementations use tablets or laptop computers. Depending on the data link characteristics, the ground data link terminal(s) could be integrated in the main RPS body or deployed as a separate element.
• Multi-console RPS: RPS's in this category are designed to control medium and large RPAs, such as tactical and MALE platforms. Related operations typically require several crew members, therefore this kind of RPS provides several consoles, each one composed by a set of displays and controls. Multi-console RPS's can be designed to be deployable (i.e. installed in a container or similar structure which allows rapid deployment to the operations area) or permanently installed in existing facilities like an operations centre. Ground data link terminal(s) could be installed in the main RPS housing (e.g. with antennae mounted on the roof of the RPS container) or deployed separately.
• Multi-element RPS: this type of RPS is used when for operational or functional reasons more than one RPS is necessary to perform the flight. The RPS is composed by a combination of stations distributed along different geographical locations. The term "element" is used to refer to an individual station along this document. Each element is similar in terms of architecture, and contains basically the same building blocks than a multi-console RPS. A typical use case in this category is a RPS composed of 2 elements, where a first element is deployed close to the aerodrome to control take-off and landing in RLOS, and a second element is installed permanently in an operations centre to control the rest of the flight phases in BRLOS, thus requiring handover capability between elements.
RPS architectures in EASA's Certified Category are expected to be based on software-intensive systems combining a mixture of manned aircraft avionics technologies for flight critical functions and commercial IT technologies for mission functions.
FIGURE 3 shows a block definition diagram with a generic high level RPS physical architecture that could match any of the categories described above. The aim of this architecture is not to provide requirements or guidance in the design of RPS systems but to complement the context information with a more detailed description on what a typical RPS implementation could look like. Formal requirements are provided later in the document (in sections 3 and 4), and try to be as implementation-agnos
Compliance with certification requirements, and more specifically with safety assurance (i.e. SAE ARP4761, SAE ARP4754A, RTCA DO-178C, RTCA DO-278 and RTCA DO-254, as duly tailored to UAS specific character), will normally lead to segregation strategies for achieving a proper isolation of most critical functions in terms of DAL into a subset of system components with well-defined boundaries and interfaces. The architecture described considers these aspects and proposes segregation between critical components (whose failure conditions are classified as Major or higher) and non-critical components (whose failure conditions are classified as Minor or Non-Safety Effect). Critical components are expected to be avionics-grade equipment, rated as DAL C and above. Non-critical components are expected to be standard IT equipment fulfilling DAL D as maximum. In general terms, flight functions and monitoring of RPAS flight systems will be allocated to the critical components, and mission functions to the non-critical components. Support functions like flight planning could be also implemented by the non-critical components. In that case additional validation mechanisms might be required in the critical components before using data generated by non-critical components.
It has to be noted that RPS designers could decide to limit segregation at software level. In those cases, only critical equipment fulfilling the highest required DAL will be needed. The architecture described also allows this possibility.
Note that DAL allocations are given in this section as an example only. They should be the result of a safety assessment made at overall RPAS level and considering the expected operations.
The architecture allows 1 to n RPS elements as major blocks of the RPS. Each RPS element shares the same internal structure, although different combinations of components are possible for a given RPS element (e.g. different number of consoles). The different components of a RPS element are described hereafter.
Housing: The RPS housing includes the structural and ancillary parts required to provide an adequate work environment to the crew and equipment, including support services such as power distribution. The complete housing block or some of its subsystems can be considered as optional in case the RPS element is installed in existing facilities such as an office building. In that case, these services are not considered within the RPS system perimeter and they are managed as external interfaces.
The following subsystems are part of housing:
• Structure: structural parts of the RPS element as the external container, equipment racks or console chassis.
• Electrical system: power input and distribution for electronical equipment of the RPS element. It can include battery backup means or alternate power inputs in case of main power failure.
• Environmental Control System: heating and cooling system to maintain adequate environmental conditions within the RPS element. The Environmental Control System can also provide some degree of redundancy in case of deployed operation in extreme environmental conditions.
• Other auxiliary systems: e.g. illumination, lightning protection, fire protection or access control, among others.
Core: The Core subsystem includes shared computing resources, network infrastructure, ground data link equipment and any other devices required to support the functions of the crew consoles. Depending on the different system needs and characteristics, part of the ground data link equipment, especially antennae, can be installed on the main RPS element body (i.e., container) or in a separate location (i.e. on the roof of existing facilities).
The Core subsystem includes the following components:
• C2 Link Manager: this subsystem includes all the ground equipment required to provide the C2 connection between the RPS element and the RPA. It has to be taken into account that, in order to meet the target reliability requirements or to support RLOS and BRLOS operations, the RPAS C2 Link could actually consist of several physical data links. The C2 Link Manager is typically composed by a set of data link terminals for the different data links provided, and a processing unit responsible for managing the different data links and for routing the C2 messagery to/from the RPA.
• ATN Gateway: once the existing CNS/ATM infrastructure would allow it, this subsystem will be responsible for managing data and voice exchanges with the CNS/ATM via direct RPS-ATM network connection. The ATN Gateway will normally use a dedicated data link for accessing the ATM network. This subsystem will not manage voice or CPDLC communications relayed via the RPA, as these flows are embedded in the C2 Link data exchanges.
• Network infrastructure: it provides the network hardware required to support the internal communications between the different computers of the RPS element, like Ethernet switches or routers. The number and topology of the networks within the RPS element can vary in order to meet the corresponding reliability and segregation requirements.
• Processing/Data server(s): depending on each specific implementation, one or more data and/or processing servers could be required to provide support the main C2 functions. Services covered by this equipment may include voice and data recording, shared data repositories like maps or aeronautical databases, or centralised functions to support the consoles HMI in client-server software architectures.
• Voice Radio(s): voice radio(s) could be provided to support voice communications between crew members in the RPS element and other actors like ATM entities in RLOS with the RPS or the RPA ground crew. In case a voice intercom subsystem is also provided (see next point), voice radio(s) will be connected to it to allow using radio voice channels in all the RPS element consoles.
• Voice Intercom: if required for operation, a voice intercom can be provided to allow voice communications between the RPS crew members, in the same or even in different RPS elements (via the Inter-element Gateway). It also provides voice communications with the CNS/ATM by means of the ATN Gateway or the voice radios.
• Inter-element Gateway: this subsystem provides the means to establish data connections between the RPS elements. These connections are required to share the common data needed to coordinate the mission between the elements (e.g. flight plan, handover parameters) and to allow communications between the crew members (e.g. voice, chat).
RPA Specific Module: The RPA-Specific Module (RSM) subsystem encapsulates functions which are specific for a given RPA type. Several RSMs could be included within the same RPS to support different types of RPAs. RSM functions could just cover messagery translation or even add additional C2 functions which are RPAspecific. Depending on the implementation, this subsystem could be purely implemented with software or also include additional hardware elements like servers or control devices. It can be also segregated into critical and non-critical RSM subsystems depending on the DALs allocated to the different RSM functions.
Console: Each RPS element can have 1 to n consoles, depending on the required size of the remote crew to perform the intended missions, but also due to redundancy aspects (e.g. having a backup console).
The main function of the consoles is to provide the C2 HMI to the crew, including displays and controls.
Each console is composed by the following subsystems:
• Critical C2 HMI: implements the most critical C2 functions from the safety point of view, focused on RPA flight and health monitoring of RPAS flight systems. Expected classification is DAL C or higher, thus relying on avionics grade equipment. This subsystem is based on a set of one or more processors running the critical C2 software, that manages one or several displays (i.e. LCD screens) and one or several input devices (e.g. buttons, knobs, keypads, cursor controllers, touch screens…).
• Non-critical C2 HMI: implements the rest of the C2 functions, focused on mission capabilities. Some flight support functions like flight planning could be also provided by this subsystem. Expected classification is DAL D or lower. As for the critical C2 HMI, this subsystem is based on a set of one or more processors running non-critical C2 software, connected to one or several displays (i.e. LCD screens) and one or several input devices like keyboard, mouse/trackball or others
• Voice Intercom HMI: provides audio input and output devices (e.g. headset or a combination of speaker and microphone) and related selectors to activate/deactivate audio channels and push-to-talk controls.
1 Several design options are possible for flight plan validation: fully allocated to the RPS, fully allocated to the RPA, partial validation in both sides (e.g. RPS validation could rely on navigation databases not available in the RPA and take benefit of HMI interactions with the RP, whereas the RPA could use more up-to-date and detailed information from on-board systems), or even duplicated validation in both sides (e.g. for safety reasons to avoid single point of failure). This document assumes that at least a part of the validation will occur in the RPS. If a specific implementation fully allocates the validation to the RPA, the corresponding validation requirements in this document must be ignored.
2 "Generate RWC guidance" function can be allocated to the RPA or the RPS, but as overall RWC operation is designed to always have the RP in the loop (i.e. no autonomous activation of manoeuvres like in the case of collision avoidance during C2 link loss), it is assumed that most implementations will allocate the function to the RPS, and therefore this is the allocation assumed in the document.