AUTONOMY in AIRBORNE SYSTEMS -

APPLICATION to UAVs

Pierre Helie Head of Operational and Future Systems Concept Analysis

Dassault Aviation

1

Plan

Why Autonomy

Definitions related to autonomy

Autonomy considerations for UAV systems

design

Derivation process

Technology

Illustration

WHY AUTONOMY?

Why autonomy?

Autonomy has emerged naturally in airborne

systems during the past years due to :

– Development of technologies such as

• Digitalisation (processing, sensors, communications…)

• Multi function Displays

• Advances in « Artificial Intelligence »

– A need to cope with increased capacity of systems (&

complexity of missions)

– A necessity to stick with limited crew size

Autonomy will continue to develop due to

emergence of UAVs

Some example

Crew Trends in aeronautics during the last

20years

Civilian A/C : crew reduction

– Direct Operating Cost

Military A/C : limited crew (1 or 2)

– Multi role (vs specialised)

– Increased capability of systems

– More severe rules of engagement

Emergence of UAVs

– Off the scene crew Common Facts

•Human Kept in the loop

Rafale Multi Role

Super Etendard Air to Surface attack

Fighter evolutions

Air to Surface Radar

LDP Pod

Radar Warning Receiver

Multi mode Radar

•Air to Air

•Air to Surface

IRST

LDP Pod

ESM

Data Link

Still

One Pilot

Large UAV (1T+) emergence

ISR UAV : a surveillance A/C without crew on

board

– Intelligence & surveillance

– Permissive environment

– Mostly single A/C operations

UCAVs : a combat A/C without crew on board

– Strike & Recce

– Non permissive environment

– Multiple A/C operation

MALE UAV

Dassault Aviation

NEURON

UAV emergence : Common Facts

• Relaxed Air Vehicle design constraints

• Less Human Factors (HF) limitations (physical

stress, sortie duration, risks…)

• Need for communications

• Keep man in the loop of critical decisions

• Safety of flight,

• Lethality : Identification, Weapon release

Plan

WhyAutonomy

Definitions related to autonomy

Autonomy considerations for UAV systems

design

Derivation process

Technology

Illustration

DEFINITIONS RELATED TO

AUTONOMY

Definitions related to Autonomy

An Automatic System can be described as self-steering or self-regulating.

An automatic system is able to follow an externally given path/plan while

compensating for small deviations caused by external disturbances.

However, the automatic system is not able to define the path according to

some given goal or to choose the goal dictating its path.

An Autonomous System is able to achieve operational goals in

unpredictable situations without systematically requesting human

intervention. The autonomous system is able to elaborate or modify plans

complying with operational goals and adapt the goals to the actual

situation. An autonomous system is able to make a decision based on a

set of rules and/or limitations. It is able to determine what information is

important in making a decision.

The autonomous system uses automatisms to execute the plan(s)

The level of autonomy corresponds to the level of intervention of the

human

[From NIAG SG 75-2004]

novemb

re 13

12

AUTOMATIC

DIRECT

SUPPORT

IN SUPPORT

ADVISORY

AT CALL

COMMANDED

5

4

3

2

1

0

INTERRUPT

REVOKING

ACTION

ACCEPTANCE OF ADVICE

AUTHORISED ACTION

ACCEPTANCE

OF ADVICE

FULL, REQUESTING

ADVICE IF REQUIRED

OPERATOR FULL

AUTHORITY

AUTONOMOUS

ADVISED ACTION

UNLESS REVOKED

ADVICE, ACTION

IF AUTHORISED

PROVISION OF

ADVICE

ADVICE ONLY

IF REQUESTED

OPERATOR

AUTHORITY SYSTEM

AUTONOMY

OPERATOR

AUTHORITY

SYSTEM

AUTONOMY

Level Of Autonomy PACT* Definitions

MODES

OPERATOR FULL

AUTHORITY

A

S

S

I

S

T

E

D

LOA

*PACT = Pilot Authorization and Control of Tasks [R Taylor -NATO RTO HFM 078]

LOA : Level Of Autonomy

Other aspect : variability

Knowledge

Usage – User initiative e.g. speed limiter on a car (off, stand by, active)

but needs for ad’hoc displays and controls

– System initiative : critical issue with respect to criteria identification and system validation!!!

[From NIAG SG 75]

Automation & Autonomy Design challenges

Automation to relax or substitute to operator tasks

(workload, feasibility…); e.g :

– Flight control

– Assisted Target Recognition

Automation might be mandatory

– e.g. to cope with loss of communications at least to guarantee a

safe flight termination (this situation has to be regognised and the

decision made by the system)

Autonomy functions to contribute to decision process

– Awareness

– Field of solutions definition/exploration

– Select actions

Autonomy and automation are both requested for

UAVs

Plan

WhyAutonomy

Definitions related to autonomy

Autonomy considerations for UAV systems

design

Derivation process

Technology

Illustration

UAV SYSTEMS DESIGN CRITERIA

AND CONSTRAINTS

UAV System overview Main elements

Communication infrastructure

Air Segment

Control

Segment

Line Of Sight

(LOS)

Beyond Line Of Sight (BLOS)

UCS : UAV Control Segment

PCS : Payload Control Segment

UAV emergence

Main Challenges

Communication Robustness

– Insatiable demand for bandwidth

– Availability vs controlled behavior in case of loss

Interoperability of systems

Vulnerability (e.g. cyber attacks)

Inability to deal with ambiguity in the same way as

manned aircraft

– Autonomy, Man Machine cooperation

– Complex situation coverage

Response times

Legal and ethical aspects

UAS Autonomy Drivers and constraints

Ressources

Costs

Human Factors

Tasks

Technology

capability

Rules

Mission

Environment

Constraints

Regulations ROEs …

Interoperability

Drivers

UAV Systems design

[From United States Air Force Scientific Advisory Board 2010 :

Operating Next-Generation Remotely Piloted Aircraft for Irregular

Warfare»]

Missions and

Control challenges

MALE UAV Dassault Aviation Neuron

UAS Autonomy Human Factors aspects

Selection of the LOA for a system will drive the role of the operator but too the

way human will cooperate with the machine and the possible inherent risks to

this cooperation, shifting from human in the loop to human on the loop

Men and Machines Who does best?

Core human capability

+

Education & Training

Technology Enablers

Fitt’s List

Men and Machines What risks?

UAS Autonomy Ressources

Autonomy implementation will request the availability of technical ressources to

implement the new technology such a processing power and communication

capability.

Part of the ressources are the development process and associated tools that

will support the demonstration of the system properties

External Ressources The example of communication

LOS or BLOS

Constraints

– Spatial Coverage

– Throughputs

– Latences

Availability

Access time

Cost Inmarsat Data 2010

LOS : Line Of Sight

BLOS Beyond Line Of Sight

UAS Autonomy Cost considerations

Cost is key of every system acquisition through the Life Cycle Considerations

from development to operations

Autonomy of systems and in the particular case of UAVs can be perceived as

an opportunity for cost reduction

Costs

Component of Cost (Life Cycle Cost)

– Non Recurring Costs (NRC)

– Recurring Costs (RC)

– Operating and Support Costs (OSC)

Two aspects of OSC driven by Autonomy

choices

– Communications (BLOS, Availability, Throughputs)

– Personnel (Qualification & training, Numbers)

Mission Personnel

State of the art, typically :

– A mission commander

– A payload operator

– A remote pilot

Possible opportunity

– Decrease the « Cockpit » ratio

– Operator Role : Man to purpose vs man to system

– Operator Location flexibility

• On ground : Fixed or Deployable Control station

• Embedded : Fighter, Ship Mission A/Cs

( ) Fighter

UCAV

? CS

UAV ISR

CS

UCAV platform operation CS challenges

UCAV

Fighter

Flight controller

Mission controller

Systems operator UCAV OB controller

How many operators for 1 UCAV?

How many operators for several UCAVs?

Location of controler?

On ground? Airborne? Shipborne?

Deployed? Fixed?

CS

( ) CS

UAS Autonomy Interoperability considerations

Autonomous system will have to be used in operational environments where

they will have to perform beside of in cooperation with other systems featuring

different LOA

In the Aeronautical field this is/will be the case of UAV (possibly different types

and different LOA) operating with Legacy Manned Suystems

Interoperability and autonomy

Issues

– Be able to operate Autonomous systems (UAVs) in Complex

networked systems (« systems of systems »)

– Transparency wrt to level of autonomy of participants

Interoperability Integration to SoS

( ) Fighter ( ) Fighter

UCAV UCAV

? CS

UAV ISR

CS ToG

ATM C2

( ) CS ( ) CS

•Simultaneous operation of different systems featuring different level of autonomy

•Pooling/Sharing ressources such as Control Station

( ) Fighter ( ) Fighter

UCAV UCAV

UAV ISR

ToG

? CS

ATM C2

Decrease of operator number?

Different Roles for operators?

Form of Dialog?

Operator cooperation issues?

Location of CS (deployed or not)?

Ressource transparency and sharing?

Shared workspace?

Interoperability Integration to SoS : pooling & sharing illustration

CS

( ) CS ( ) CS

Autonomy and interoperability axes for solutions

Issues

– Be able to operate Autonomous systems (UAVs) in Complex

networked systems

– Transparency wrt to level of autonomy of participants

Standards

– They define interfaces

– They define a list of information and associated format

– They define exchange protocols

Example of standards that could be considered

•Link16,

•STANAG 4586

•FIPA,

•SAE Air 5665A

BML : Battle Management Language

Stanag 4586 principle

Level of Interoperability (LOI)

Level 1: Indirect receipt and/or transmission of sensor product and associated metadata, from the UAV.

Level 2: Direct receipt of sensor product data and associated metadata from the UAV.

Level 3: Control and monitoring of the UAV payload unless specified as control (C) only or monitor (M)

only.

Level 4: Control and monitoring of the UAV, unless specified as control (C) only or monitor (M) only, l

ess launch and recovery.

Level 5: Control and monitoring of UAV launch and recovery unless specified as control (C) only or

monitor (M) only.

AV

VSM

CORE

UCS

C4I

SYSTEM

CCISM

OPERATOR

DLI

CCI

HC

I

C4I

SYSTEM

CCI

LAUNCH &

RECOVERY

SYSTEMUCS

AV

VSM

CORE

UCS

C4I

SYSTEM

CCISM

OPERATOR

DLI

CCI

HC

I

C4I

SYSTEM

CCI

LAUNCH &

RECOVERY

SYSTEMUCS

Set of standardised Interfaces •DLI Data Link Interface

•CCI Contol Command Interface

•HCI Human Computer Interface

Interoperable

Control

Stations

Autonomy and interoperability

axes for solutions

Issues

– Be able to operate Autonomous systems (UAVs) in Complex

networked systems

– Transparency wrt to level of autonomy of participants

Standards

Support Dialog between man and « robots »

– Structured C2 language

– Interpretable by men and system(s)

– Example of BML (Battle Management Language)

BML : Structured C2 language

Origin

– Developped initialy for System of Systems simulation for C2

emulation, robots simulation (SISO)

– Based on C2 Data base et interfaces structures

– Natural Shift towards a real C2 language

Structuration principles : following the « 5W » rule

To be adapted to the domain of airborne systems

(Ontology)

UAS Autonomy Rules : example of ROEs

Autonomous system will have to encompass a set of rules coming from

various areas : regulations (eg see & avoid, safety, tactical, legal, ethical)

In non autonmous systems these rules are part of the operator background

knowledge

Perceived Issues

•Generation of the rules

•Validation of the rules

•Implementation of the rules

•Life Cycle of the rules

(mission, theatre, technical

standard, product life…)

ROEs : Rules of Engagement

ROEs : basic structure

Domain of the action (physical space, type

of actions…)

Forbid-Authorise

– Nature of action : fictive/simulated, warning, real

– Conditions :

• Object/person of interest : presence/position , behavior,

perceived risks (for itself, for others….)

• Ressources : requested, authorised, forbidden

• Limitations : Collateral Damage, Behavior (open, covert),

unacceptable disturbance

• Actors/authority : who decides (eg Weapon Release

authority)

Plan

Why Autonomy

Definitions related to autonomy

Autonomy considerations for UAV systems

design

Derivation process

Technology

Illustration

AUTONOMY DERIVATION

Autonomy derivation : Steps

Task analysis

– Analysis Grid for Task decomposition :

• Inspired by OODA loop

– Nature of tasks in an aerial combat system

• Mission, Survivability, Safety, Supervision

– Tasks analysis through mission phases

Assessment of

– Technology capability

– Targeted Role of operator

– Capability of operator

Targeted LOA

LOA : Level of Autonomy

Reference : OODA loop (J Boyd)

The OODA loop (for observe, orient, decide, and act) is a concept originally

applied to the combat operations process, often at the strategic level in

military operations. It is now also often applied to understand commercial

operations and learning processes. The concept was developed by military

strategist and USAF Colonel John Boyd

OODA : Nature of tasks

OODA Observe Orientate Decide Act

RAC Recognise-Act –Cycle

SA Situation Awareness

BOAS Behavior Orientated Autonomous Systems

From NIAG SG75

Tasks and MMI

Mirage 2000 (1st gen) Rafale

OODA Mission

OODA Survivability

OODA Safety

Supervise/Compromise

External OODA

(request/accept)

Generic mission Phases

Mission

Planning Taxi & Toff

Navigate to

Assigned area Mission

De brief

Approach,

Land & Taxi

Navigate to

Base

Survivability

management

Safety management

(health status, collision avoidance…)

Ingress Egress

Ressources management

(fuel, effectors, chaff, flares…)

ASSESS Engagement Phase : F2T2EA

Survivability

OODA applies

Two main loops : short and middle/long term

– Short term : mostly open loop

– Middle long term : Re plan

Detect

Threats

Assess

Risks

React

Survivability

Strategy

Select

Reaction

APPLY

STRATEGY

SHORT

TERM

MIDDLE/LONG

TERM

Safety

Basic Air vehicle control tasks

– Platform monitoring

• Health monitoring/Critical failure management

• Configuration control

– Maintain flight enveloppe

– Flight Path control

• Ground Collision Avoidance

• Mid Air Collision Avoidance (See and avoid rule)

– ATC compliance

Weapon release

Mission Phase

Mission tasks

xxx yyyy xxx xxx

Survivability tasks

xxx

Safety tasks

xxx yyy

xxx

xxx

Supervision tasks

xxx

Tasks representation by mission phase

Sequential

Sim

ulta

neous

Dash boxes represent tasks that are

identical to the task at the root

Taxi Take Off example

Mission

Planning Taxi & Toff

Navigate to

Assigned area Mission

De brief

Approach,

Land & Taxi

Navigate to

Base

Survivability

management

Safety management

(health status, collision avoidance…)

Ingress Egress

Ressources management

(fuel, effectors, chaff, flares…)

Taxi-T-Off

Mission Taxi T-Off

Survivability NA Procedure

Safety

Health Monitoring

Maintain Domain

Collision avoidance

ATC Compliance

Supervise Manage transitions

Manage transitions

Taxi-Take-Off example

Taxi to runway

Get Taxiing procedure

Get Taxiway characteristics

Detect own status

position

configuration Comply with

taxiing procedure

Detect decision points

Plan

Stop

Move on taxiway

Select Plan

Execute

Taxi to runway (details) How to run the vehicle from parking to runway threshold?

Observe

Orientate

Decide

Act

Autonomy

Field

Candidate Solutions

•Planned Path

•Follow me/Convoy

•Visual steering

•Remote Control

Taxi to runway

Get Taxiing procedure

Get Taxiway characteristics

Detect own status

position

configuration Comply with

taxiing procedure

Detect decision points

Plan

Stop

Move on taxiway

Select Plan

Execute

Taxi to runway (details) How to run the vehicle from parking to runway threshold?

Observe

Orientate

Decide

Act

Autonomy

Field

Candidate Solutions

•Planned Path

•Follow me/Convoy

•Visual steering

•Remote Control

Autonomy derivation : Steps

Task analysis

– Analysis Grid for Task decomposition :

• Inspired by OODA loop

– Nature of tasks in an aerial combat system

• Mission, Survivability, Safety, Supervision

– Tasks analysis through mission phases

Assessment of

– Technology capability

– Targeted Role of operator

– Capability of operator

Targeted LOA

LOA : Level of Autonomy

Synthesis

Example

Task Feasibility Operator

requested

role

Operator

capacity

Recommendation

Target

identification

Up to LOA5

•Technology

: ATR

•Limitations

on target

types and

environmen

tal

conditions

LOA3 :

operator

must be in

the loop in

most

situations

(ROEs)

LOA1

•Image

analysis

•Duration of

task

•Latence of

information

due to

communicati

on network

LOA3 : Assisted Target

identification with possible

variation (LOA5 by

exception down to LOA1)

•Comply with requested

role of operator

•Robustness of algorithms

and varaibility of situations

doesn’t enable full

automation

•Contributes to

communications needs

LOA : Level of Autonomy

ATR : Automatic Target Recognition

ROEs : Rules of Engagement

UCAV

? CS

Summary

Needs : System Tasks •Platform control

•Launch/Recovery

•En route

•Engagement

•Navigate •Follow flight plan

•Insert in traffic

•Engage/Re engage •DRIL

•Select target(s)

•Engage

•BDI/BDA

•Survive

•Coordinate •With leader/wingmen

•with Coop Systems

•Disseminate

•React to unplanned events

A/V Functions

CS Functions

MMI

Crew

Missions & CONOPS

Architecture

Communications

Criteria •Human Factor

•Tasks complexity

•Situation complexity

•Duration

•Response time

•Criticality •Safety

•Survivability

•Mission success

•ROEs

•Regulations

•Technical constraints •Communication

•Feasibility

•Variability of situations

•Adaptability

A/V : Air Vehicle

CS : Control Station/Segment

MMI : Man Machine Interface

ROEs : Rules of Engagement

DRIL : Detection Reconaissance Identification Localisation

BDI/BDA : Battle Damagr Indication/assessment

Plan

Why Autonomy

Definitions related to autonomy

Autonomy considerations for UAV systems

design

Derivation process

Technology

Illustration

TECHNOLOGY FOR AUTONOMY

UAS Autonomy Technology capability

Autonomous system will request new technology

These technology will have to cover different functional domains; nevertheless

generic questions will have to be adressed to assess their capability with

respect to autonomy

What questions on technologies? Capability

Probability of success (Ps) : probability that the

system will solve the problem (capability)

Probability of false alarm (Pfa) : probability that the

system will solve the problem with a wrong answer

(impact confidence)

Domain of use : Domain in which the Ps combined

with Pfa is acceptable with respect to system design

objectives

Technology Capability for UAVs : Example

Automatic Target recognition ATR

– Basic performance is defined by the probability to recognise

a type of target/object in an image

– Level of confidence is conditionned by rate of unapropriate

recognition (« false alarm »);

– Current technology level (« TRL ») cannot guarantee an

acceptable Ps and Pfa on all targets types

– If the latest, consequence is that to be « recognised » a

consolidation is needed from a third party (e.g. the operator);

third party should have appropriate level of information in

hand (e;g; significant image for an operator)

Key candidate technology with respect to OODA

O O

D A

TRL mentionned refer to UAV application

System engineering Challenges raised by autonomy implemenation

System

Engineering

Specification

Design

Integration

Validation

Verification

Qualification

Challenging Properties

• Number of situations

• Design Space

• Unpredictable

• Rule Based system

• Rules validity

• Rules update

• Safety

• Airborne

• Lethal

• Predictability

• …

Key considerations for Technology choices

Plan

Why Autonomy

Definitions related to autonomy

Autonomy considerations for UAV systems

design

Derivation process

Technology

Illustrations Maritime Surveillance

Multi vehicle autonomous aerial refuelling

Neuron (UCAV technology demonstrator)

INFORMATION PROCESSING IN

MARITIME SURVEILLANCE

Autonomy illustration

MARSUR

Effect of better « characterisation » of targets on

mission performance

– Decrease reaction time

– Focus investigations when appropriate and save mission

potential

Autonomy breakthrough

– Sensor association/fusion LOA3-4

– ATD/R (Automatic Target Detection/Reconnaissance) LOA3-4

– Behavioral properties (intention, anomaly) LOA3-4

– Sensors control : cueing and coordination LOA4-5

LOA : Level Of Autonomy

MARSUR Realistic situations

www.marinetraffic.com

AIS = Automatic Identification System

AIS Plots •Merchant : Cargo, Tankers,

•Passengers/ferry ,

•Fishing ,

•Leisure (Yachts)……

Each plot contains information •Position,

•Speed,

•Pictures…

MARSUR Illustration Investigation & Decision Process

MARSUR Illustration Investigation Decision Process

Situation Analysis

•Coherency/anomaly

•Position

•Time

•Variations

•Behaviors

•Individual

•Groups

•Predictions

•Extrapollations

•Probability

Detections Analysis

INVESTIGATION DECISION (PATH ALTERATION, RESSOURCE ALLOCATION…)

Radar

AIS ISAR

EO/IR

Situation Analysis example

www.iosb.fraunhofer.de

Interactive Analysis and Diagnosis

TECHNIQUES

•Bayesian Network

•Graph models

•Hidden Markov model

MARSUR Illustration

Ships (speed)

Detection

Planned Surveillance

Pattern

Actual Path

MARSUR Illustration

Benefit of better ID process

– Number of investigation : save mission time

available for additional surveillance capability or

enable revisit of area of high interest

– Decrease the number of operators

MULTI UCAV OPERATION

AIR TO AIR REFUELING (AAR)

Autonomy illustation

Definitions

RENDEZ VOUS

PATTERN EXAMPLE

REFUELING

AREAS

AAR Standard Procedure

AAR Simulation Development

Package of 5 UCAV

Simulated Phases – Rejoin tanker

– Enter Refuel pattern

– Execute AAR procedure (previous slide)

– Exit Refuel Pattern

– Rejoin Flight Plan

Autonomy – Basic Flying (navigation, package flight, deconfliction…):

LOA5

– State and phases transition : LOA 3

NEURON

1ST EUROPEAN UCAV

Autonomy illustration

NEURON

Human actors

Control modes

Movie

NEURON main human actors (1)

Neuron operators: in charge of aerial vehicle

systems control and trajectory definition/

control in order to :

– follow the test order agreed with the flight test

engineer

– take into account safety local rules and flight line

team safety

– respect ATC controller requests and clearances

– apply procedure in case of failure (including

decision to voluntarily crash the air vehicle)

Flight line team : in charge of ground

support operations

NEURON main human actors (2)

Test team (including the tests conductor)

…and 1st flight guests!

Ground and Test Controllers: official controllers in charge of air

traffic separation (ATC)

Safety Officer: official representative in charge of safety local rules

compliance (i.e. those concerning density of over-flown population)

Control modes

Manual Control Supervised Control

NEURON PROGRAMME

ISTRES In-flight tests

Development

SAINT CLOUD General Management R&D

Thank you for your attention

89