The Use Of MathWorks Tools in the Unmanned Air Systems ... · The Use Of MathWorks Tools in the Unmanned Air Systems Design Process ... • Limited to R13 by Unix operating ... Simple

Nov 2012 © BAE Systems (Operations) 2012 BAE Systems Proprietary 1

The Use Of MathWorks Tools in the

Unmanned Air Systems Design Process

Alexander McCuish – Flight Control Specialist

6th Nov 2012

MILITARY AIR & INFORMATION


Introduction • MathWorks products have played an important role in the rapid prototyping of

UAS.

• Enabler for technical demonstrators allowing BAE Systems to rapidly develop a

credible UAS capability.

• Early adopters were Control Law design community

• Use spreading throughout the design process, following a pattern of adoption.

• Use of a common modelling environment allows sharing of tools, models and

functions.

• Must be managed appropriately to maximise benefit.

• Presentation will show how the use of MathWorks’ tools began with Control

Law community

• Will then show several examples of the use of MathWorks’ tools across the

design process.

• Conclude with future developments.


Early Adopters – Control Law Community late 90’s

• IT facilities • Move from Mainframe to Unix well underway.

• Software • Fortran is king! • All major design / clearance tools developed in-house. • Software tools transported to Unix directly from Mainframe – need to

maintain continuity on projects and with partners. • Graphical User interfaces developed as front end where possible to

improve efficiency.

• Process • Model-based design basic process essentially the same as today. • Functional modelling of key FCS hardware components. • Control law functional specification defined in Fortran (executable

specification).

• MatrixX selected by BAE Systems as preferred autocode tool (‘97) • Ability to create ADA autocode

• Believed to be more mature than Simulink at the time.

MATLAB was still used for R&T activities and ‘support’ tasks; plotting, visualisation, transfer between data formats, etc.

Tektronix 4014 “take me to your leader” (Photo by Jim Rees Dec 2001)


Low Cost UAS Development early 2000s

• Challenge: Rapidly develop a UAS capability

• Looking for maximum capability for minimum cost

• Clear that future would involve desk top computing along with a need to reduce

reliance on in-house software.

• Key control law design drivers

• Design process – maximise automation & flexibility.

• Flight standard code - autocode facility desirable.

• Minimise modelling overheads – single model desirable.

• Compatibility with key supplier (FCC & guidance functions)

• Key risks

• Risk of significant tool development overhead.

• Creation of required subsystem models (eg undercarriage, aero etc).

• Assurance of design integrity.

• MATLAB / Simulink selected

• Engineers involved were experienced both the in-house tools and the MATLAB /

Simulink tools.

• MATLAB / Simulink ideal for control law design.

• MatrixX development languishing –

• Substantial improvements to MATLAB/Simulink - R13 (2002)


Raven, Corax & HERTI (2003 – 2006)

• Control laws designed in a Unix environment.

• Limited to R13 by Unix operating system standard

• Minimum risk approach taken – re-implemented our

in-house tools in MATLAB / Simulink.

• Flight control laws specified as Simulink models –

compatible with guidance functions.

• Flight s/w mainly hand coded from Simulink

Specification

• Single Simulink model used for off-line and flight

simulation purposes.

• Subsystem component models created locally.


Mantis & Taranis (2007 – 2012)

• Standardised on the PC version of R2007b. • Removes compatibility issues with new releases

• Although prevents access to the latest features

• Taranis upgraded to R2010b to access ‘model

referencing’ features.

• Flight control law design tools further developed to

make better use of MATLAB / Simulink features.

• Flight control laws specified as Simulink models –

compatible with guidance functions.

• Auto-coded flight control laws have been flight tested

on a test-range.

• Use of test-vectors and test-coverage reports from

Simulink Verification and Validation toolbox improved

the control law functional test specification- easier &

quicker

• Increased software requirements for control law

design – modelling standards required to ease

autocode process.

• Subsystem component models supported and

underwritten by relevant disciplines.


Flight Control Laws Design Process (late 1990’s)

Fortran

Aerodynamic

Data Air vehicle

Non-Linear

Model FCS Hardware

Specifications

Any other

Information

i.e. propulsion data,

Undercarriage data

Trim

Linearise

Linear

Model

Control laws

Functional

definition

FCS

Software for

Aircraft / Rig

Re-coding

AND Verification

Control laws

with any

required

developments

Non-Linear

Design and

Evaluation

Linear

Design and

Evaluation

Flight

Simulator

Flight

Simulation

Evaluation


Flight Control Laws Design Process (2012)

MATLAB/Simulink

Aerodynamic

Data Air vehicle

Non-Linear

Model FCS Hardware

Specifications

Any other

Information

i.e. propulsion data,

Undercarriage data

Trim

Linearise

Linear

Model

Control laws

with any

required

developments

Non-Linear

Design and

Evaluation

Linear

Design and

Evaluation

Flight

Simulator

Flight

Simulation

Evaluation

Generate

Auto-code

Control laws

Functional

definition

Generate

Auto-code

FCS

Software for

Aircraft / Rig

Re-coding

OR Verification

Equations

of

Motion


Significance of Control Laws as Early Adopters

• Control law design and clearance

requires a full non-linear, 6 degree

of freedom model to be created.

• In turn this requires subsystem

models for

• Undercarriage

• Propulsion

• Aerodynamics

• Sensors

• Actuation

• Mass / Inertia

• Initially created locally but later

became the responsibility of the

relevant disciplines.

• Required other disciplines to

become MATLAB / Simulink literate

and engaged in the Model Based

Design methodology

Sensors

Control

Laws

Aerodynamics

Propulsion

Undercarriage

Actuators

Atmosphere Mass /

Inertia

Forces and

Moments


MATLAB / Simulink - Pattern of Adoption

Generally the adoption of MathWorks’ products

follows a similar pattern;

• Initial use to support current process and

tools e.g. data transfer, data visualisation.

• Spreads to use in early stages of lifecycle to

rapidly assess various options.

• Use extends across the lifecycle as

confidence and capability grows.

• Aided by

• Need to maintain commonality with other

disciplines.

• Pool of recent graduates more familiar with

MATLAB/Simulink than Fortran.

• Resisted by

• Inertia of legacy (qualified) toolsets.

• Investment to make the change,

• Appropriate time to make the change.

Examples of Use

• Electromechanical Actuation Modelling

• Environmental Control System Modelling

• Image Analysis – Object Detection and Recognition

• Flight Data Plotting

• Air Vehicle Concept Analysis



Electromechanical Actuator Modelling

• BAE Systems has a strong background in hydraulic

actuation.

• ElectroMechanical Actuation (EMA) offers significant

benefits but is not as well understood.

• Modelling activity undertaken to understand the design

drivers of EMA. Results used to focus vehicle level trade

study work.

• Determine the optimum way to meet the air vehicle

performance and redundancy requirements eg.

• Bandwidth.

• Load v’s rate.

• Number of motors.

• Active-active, active-standby.

• Behaviour in failure cases.

• Electrical power requirements.

• Will help set the EMA requirements for future UAS.

• Allow BAE Systems to become a better informed

customer.

Moog EMA from Mantis UAS


Environmental Control System Modelling • Concept level Environmental Control System (ECS) modelling

capability developed.

• Created in MATLAB/Simulink from first principles.

• Does not need detailed supplier information unlike most off-the-shelf

modelling packages.

• Easy to use and flexible. • Run from a customised GUI (right) allowing cases to be rapidly

executed.

• Alternative architectures can be quickly created and evaluated.

• Can accept more detailed information, when available from the

supplier.

• Assess candidate architectures and iterate to a solution.

• Initial assessment of several architectures has been carried out.

• Next phase is to characterise component performance.

• Use this information to produce Cardinal Point Specs for

components.

• Use model to inform discussions with equipment suppliers.

• Embed the ECS model within a wider, vehicle level thermal

management model (incl. fuel system, engine, airframe, etc).

• Interfacing models likely to be in different modelling environments.


Image Analysis – Object Detection and Recognition

Taken from presentation to the IET by Dr. Dave Parker BAES-FCAS-

ENG-R&D-PRES-16934, 3rd July 2012

• UAS can image large areas at high

resolution.

• Volume of data exceeds datalink limits

and the ability of human operators to

analyse.

• Reduce workload and bandwidth using

autonomous processing of sensor

imagery, to detect and recognise

objects of interest to the operator

• Seeking to take advantage of recent

advancements in object recognition in

non Aerospace and Defence industries.

• Routines created to assess candidate

3rd party algorithms against a variety of

target sets using various sensors.

• Developing a sensor and algorithm

performance prediction capability.

• Matching sensors and algorithms to

meet the required performance.


Flight Data Plotting Created to visualise and manipulate

large quantities of flight trials data.

• MATLAB routines, Java GUI front end

from MathWorks Central website - GUI

Layout Toolbox by Ben Tordoff

• Use of memory mapping to extract data.

• Data can be re-sampled and saved in

other formats incl .xls.

• Can create elaborations to combine and

convert signals eg. Smoothing, unit

conversions.

• Ability to create and store plotting

formats.

• Ability to play back data and visualise

vehicle motion.

• Visualisation adapted from a routine on

MathWorks Central website – ‘flightviz’ by

Gus Brown.

• Developed for use within the trials team

– not formally adopted.


Air Vehicle Concept Analysis

During Air Vehicle concept design

visualisation of design space is

difficult.

Air Vehicle defined in terms of

• T/W – Thrust to Weight ratio.

• W/S – Weight to Wing area ratio

(wing loading).

• Aspect Ratio – ratio of span²/ wing

area.

Constraints plotted as iso-surfaces.

A typical subset of constraints shown.

Routines created in MATLAB to plot

constraints and visualise the trade

space (volume).


Air Vehicle Concept Analysis

• Limiting constraints can be identified and

challenged.

• Solution trade space (volume) calculated.

• Optimum solution defined.

• 2D slices of the data can be taken.

• Effect of changing constraints can be quickly

assessed.

Greatly increased understanding of the

relationship between constraints and solution


Ground Control Station Development - Desktop

Work on-going to improve UAS

Ground Control Station (GCS)

functionality.

Simple generic vehicle response

model implemented in MATLAB

/Simulink /Stateflow. Our 1st use of Stateflow which

greatly simplified the design and

visualisation of control law modes

Interfaces with VAPS, display

prototyping software and

FlightGear.

Desktop sim allows displays and

functionality can be developed and

assessed together.

Rapid iteration of designs. Early

capture of bugs and problems.

MATLAB/Simulink/Stateflow

Vehicle Response Model

Input Devices

VAPS Displays

FlightGear Visuals

DESKTOP SIMULATION


Ground Control Station Development - Rig

VAPS displays ported to the GCS rig. Vehicle response

model autocoded and integrated with the full vehicle model

in the detailed synthetic environment.

Allows a full and formal assessment to be carried out in

a representative environment.

Mission System


GCS

Sensor Models

Comms Model

Synthetic

Environment

VAPS Displays

MATLAB/Simulink/Statefl

ow


Input Devices

Autocode

MathWorks Tools – Benefits to date


• MATLAB/Simulink has largely replaced the in-house tools for Control Law design

and specification

• It has reduced the need for in-house tool support and Fortran skills.

• General uptake is expanding Model Based Design to discipline areas beyond the

Control Law community, leading to the ability to share models across disciplines

• Ability to develop analysis tools rapidly with customised GUIs

• Easier to partner with suppliers as this is a common toolset in industry and

academia

• Available toolboxes have improved our design processes - but we have more to

exploit!


Future Developments

Future strategy for flight control law design & clearance:

• Implement an efficient DO-178 compliant software development process common

across all Safety Critical software.

• Process and toolset will be based around MATLAB / Simulink

• Looking to replace / retire in-house tools, where appropriate.

• Review current process and ensure best use of the MathWorks’ tools

• Our current tools are adequate, but can be improved.

• Increasing use across all disciplines

• Sharing of tools/models and functions to maximise re-use of IP

• Develop model management, coding standards and working practices to maintain

a level of control to maximise the benefits across the business.

• Coordinate activities across UAS and non-UAS projects.

• Access more toolboxes to get the maximum out of built in functionality.

The overall aim is to increase commonality of tools and

processes across all aircraft projects, leading to cost and time

savings while increasing quality.


Acknowledgements

Thanks are due to our customers and partners for their support in the projects described

during this presentation.

Thanks are also due to colleagues at BAE SYSTEMS

Gary Jukes, Matthew Lodge, Dr. David Parker, Mathew Bowers, Kieran Watt,

Peter Collingbourne.


Questions?

Documents

The Use Of MathWorks Tools in the Unmanned Air Systems ... · The Use Of MathWorks Tools in the Unmanned Air Systems Design Process ... • Limited to R13 by Unix operating ... Simple