The term ‘technical’ in this context includes technology and engineering in addition to technical procedures and the like.  Aviation is a very technical sector and the distributed and increasingly automated nature of RPAS brings even more technical considerations.  This section of the website covers many of the main technical areas where RPAS require particular attention.

Automation and Artifical Intelligence

Autopilots have been used in manned, particularly commercial, aviation for a long time.  They are extensively used in RPAS, with human pilot supervision.  As with manned aviation, automation is being applied to many aspects of RPAS.  Automation specifically to ‘mitigate’ the removal of the pilot from the aircraft is an area which is of major interest.

As with all automation, careful consideration must be given to striking the best balance between automatic function and human control.  There is probably no one right answer in this domain and the optimum balance has to be determined on a case by case base, dependent on many factors.  One example might be in respect to Detect and Avoid where, under most situations, it might be desirable for a human pilot to approve the best ‘avoid response’.  But at the last minute, inside the latency performance of the communications and decision loop between remote pilot and RPA, the automatic system on board the RPA might be the only option to avoid a collision.

The safety certification of automation and especially artifical intelligence poses challenges.  More content of this subject is given in the Automation/AI page.


For remote pilot to be able to exercise responsibility for a RPA and to interact with Air Traffic Management (ATM), reliable, robust and secure communications are essential.  Typically such communications can be by regular radio frequencies such as VHF, with or without radio relays, by using satellite communications, by using non-radio frequency communications (eg modulated lasers) or using any combination of these.  More content of this subject is given in the Communications pages.


Not having human life on board an RPA makes a big difference to safety and risk considerations.  Manned aviation safety has evolved over the last hundred years or so with the main focus on preserving human life on board the aircraft.  This meant that any risk of incident, either with other air users or with terrain or bad weather had to be mitigated to the required extent - to an acceptable level of risk.  This means not only that the airworthiness of the aircraft has to be to a very high standard but also that the risk to other airspace users and people on the earth’s surface is very low.  The majority of manned aircraft, once they have received safety certification, are authorised to fly in most environments, such as over centres of population.

Since there is no risk to human life on board an unmanned RPA, the risk assessment focuses on the risk to other airspace users and those on the surface.  The risk in remote areas with negligible air traffic and terrestial population density is therefore hugely lower than in the proximity of a major commercial aviation hub in a densely populated area.  The operational risk for an unmanned RPA is a function of the RPAS and, crucially, the operational environment (which includes many factors).  This enables optimising RPAS for specific operational scenarios delivering not only the required level of safety but also economic efficiency.  The greater the operational risk, the greater the safety mitigation required from the RPAS.

The widely variable requirement for airworthiness, depending on operational risk in any given case, and the need to address airworthiness on a full system basis (eg communications, remote pilot station) pose challenges.  An additional consideration is that manned airworthiness certification typically leads to a type certificate for a given specification of aircraft, which may endure for many years.  With rapid technological development and system change in the RPAS sector, the costs involved with a ‘traditional’ approach to airworthiness certification seem to be unacceptable.  More content on these challenging issues is given in the Airworthiness page.

Remote Pilot Station (RPS)

For RPAS the RPS is, effectively, the RPA’s cockpit.  It is from here that the remote pilot exercises the responsibility for safe navigation and has control of the RPA.  There are many factors to be considered such as the ergonomics and ‘human machine interface’ with which the remote pilot has to work.  These are typically markedly different across current RPAS, which poses challenges for remote pilot training and licensing.

Depending on the threat assessment, the RPS has to provide acceptable security for the RPA’s ‘cockpit’ and remote pilot.

Work is underway to address the way airworthiness certification should treat RPS.

There are a range of options for one RPS to control multiple RPAs and for the handover of control of an RPS from one RPS to another.

More content is given in the Remote Pilot Station page.

Detect and Avoid (D&A)

In controlled airspace it is the primary responsibility of Air Traffic Control (ATC) to ensure the safe separation of aircraft.  In airspace without ATC services, it is the responsibility of the pilot to ensure separation.  But even in controlled airspace, if a pilot indentifies and impending conflict, the pilot is authorised to take avoidance action even if it does not conform to the required Standards and Recommended Practices (SARPs).  Therefore ultimately the manned aviation pilot is responsible for avoiding air-to-air collisions.

The challenge is to meet the D&A requirements with RPAS.  The presence of other automated collision avoidance systems (which are widespread in commercial aviation) complicates matters, since any RPAS capability must be ‘compatible’ with them.

More content is given in the Detect & Avoid page.

UAS Traffic Management (UTM)

Most current manned aviation Air Traffic Management (ATM) and ATC involves voice dialogue between ATC and the pilot in the aircraft.  This is no longer the case with RPAS.  Current ATC takes place on common radio frequencies, so that all pilots in an ATC area can hear and participate in all relevant ATC communications.  There is a need for RPAS to integrate with this environment.  There is a trend towards digital ATC services for all aviation which will not require voice communications and this probably will help to reduce this challenge.

Routine manned aviation altitude limits and classes of airspace differ in different states.  Typically below a certain altitude and in some remote locations, ATC service are not available.  Most (especially small) RPA are required by most states to operate below the minimum altitude permitted for others types of aviation (apart from take off and landing locations).  Many small RPAS are specifically designed to work at low altitudes because that is most suitable for their applications (eg delivery, high structure inspection, real estate photography).  While this might be less of a problem in remote areas, with the huge increase in the use of small RPAS (cf ‘drones’) both for recreational use and aerail work, there is a growing need for UTM.  A good deal of work is underway in this area, especially with the interest in ‘Urban Air Mobiliy’ (UAM).  More content is given in the UAS Traffic Management page.

Human Factors (HF)

There are many issues to be addressed in terms of HF with respect of RPAS.  These include:  how to optimise the pilot’s ability to exercise responsibility for a RPA and to have an appropriate level of both external and internal situation awareness:  how to provide a more consistent set of human machine interface (HMI) options so that remote pilots can move between different RPAS without extensive re-training; what should be the physical/health requirements for remote pilots acroos the wide range of markedly dufferent RPAS types;  what are the psychological and behavioural considerations of being a remote pilot and what should flight duty cyles be for remote pilots?  More content is given in the Human Factors page.


Because of the distributed nature of an RPAS, the reliance on communications, electronics and software for automation and the like there are many security issues to be considered, depending on the nature and magnitude of perceived threats.  Existing methodologies for security assessment appear to be valid although the nature of any threats and configurations of RPAS may be different from manned aviation.  A typical appraoch to security assessment might involve: personnel security and back ground checks (probably very similar to those across the aviation and other sectors); physical security of key system components including the remote pilot station (RPS); communications security to protect the key flight control (and other relevant) data links and electronic security and software integrity.  More content is given in the Security page.


Payloads can be considered somewhat independent from the RPAS in that the main focus is to deliver safe, economically efficient RPAS which are fit for task.  This is analagous to a bus being fit to tavel on public roads whether or not it is carrying passengers.  Therefore any RPA and RPAS must be capable of carrying the required payload(s) safely and efficiently.  Equally, any payload should not detract from the safety of the RPAS to an unacceptable degree (ie the need to stay within safety target tolerances).  Issues such as damaging payload substances/liquids, communications interference or other disruptive electonic emissions and over-heating can all endanger safe RPA navigation.

While the payload operation may be controlled from a RPS some systems architectures/configurations involve a separate control station for the payload, which is very likely to require additional communications with the RPS.

With some small RPAS, the payload communications may share the flight control communications in a multiplex arrangement.  This has implications for communications integrity and security, in addition to airworthiness.  More content can be found in the Payloads page.


Arising from several perceived needs, there is a call for the capability for the remote identification of any individual RPA.  Examples include: law-enforcers wish to be able to identify any operator who is breaking regulations; private individuals may wish to know who might be invading their privacy; accident investigators need to establish ownership and airports may want to know who is flying in their airspace.  Traditional aircraft identification has included identity information physically attached to the airframe and side numbers clearly displayed on the exterior of the aircraft, in addition to each aircraft having a ‘callsign’ to identify it to ATC.

While indentity plates, numbers and callsigns may be applicable to RPA there is a call for the ability to identify a RPA remotely, when it is impossible to inspect an identification plate, see a number on a very small aircraft and without communications to the remote pilot.

There is an assumption that this can be achieved by electronic means or e-Identification and several options are being explored.  Coded light signals are also being explored.  More content can be found in the Identification page.


There are concerns, especially with the rapid growth of the small RPAS market, that RPA might be flown to places they are not permitted to fly.  Hence there is a call for technology to make unauthorised overflight impossible.  At the moment there are procedures which make provisions, such as in the form of NOTAMs (Notice to Airmen), but they require people to know about them and then to act in accordance with them.  Many small 'consumer’ RPAS users might be unaware of them or might choose to ignore them.  Criminals and other malfeasants would ignore them.

Since most RPAS use autopilot systems, the concept of geo-fencing proposes programming into each autopilot or navigation system the areas where flight is technically impossible.  More content is provided in the Geo-fencing page.

© Adfingo 2022