Sanjay Garg

Glenn Research Center, Cleveland, Ohio

Implementation Challenges for

Multivariable Control

What You Did Not Learn in School!

NASA/TM—2008-215027

January 2008

AIAA– 2007–6334
NASA STI Program . . . in Profi le

Since its founding, NASA has been dedicated to the 

advancement of aeronautics and space science. The 

NASA Scientifi c and Technical Information (STI) 

program plays a key part in helping NASA maintain 

this important role.

The NASA STI Program operates under the auspices 

of the Agency Chief Information Offi cer. It collects, 

organizes, provides for archiving, and disseminates 

NASA’s STI. The NASA STI program provides access 

to the NASA Aeronautics and Space Database and 

its public interface, the NASA Technical Reports 

Server, thus providing one of the largest collections 

of aeronautical and space science STI in the world. 

Results are published in both non-NASA channels 

and by NASA in the NASA STI Report Series, which 

includes the following report types:

• TECHNICAL PUBLICATION. Reports of 

completed research or a major signifi cant phase 

of research that present the results of NASA 

programs and include extensive data or theoretical 

analysis. Includes compilations of signifi cant 

scientifi c and technical data and information 

deemed to be of continuing reference value. 

NASA counterpart of peer-reviewed formal 

professional papers but has less stringent 

limitations on manuscript length and extent of 

graphic presentations.

• TECHNICAL MEMORANDUM. Scientifi c 

and technical fi ndings that are preliminary or 

of specialized interest, e.g., quick release 

reports, working papers, and bibliographies that 

contain minimal annotation. Does not contain 

extensive analysis.

• CONTRACTOR REPORT. Scientifi c and 

technical fi ndings by NASA-sponsored 

contractors and grantees.

• CONFERENCE PUBLICATION. Collected 

papers from scientifi c and technical 

conferences, symposia, seminars, or other 

meetings sponsored or cosponsored by NASA.

• SPECIAL PUBLICATION. Scientifi c, 

technical, or historical information from 

NASA programs, projects, and missions, often 

concerned with subjects having substantial 

public interest.

• TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientifi c and 

technical material pertinent to NASA’s mission.

Specialized services also include creating custom 

thesauri, building customized databases, organizing 

and publishing research results.

For more information about the NASA STI 

program, see the following:

• Access the NASA STI program home page at 

http://www.sti.nasa.gov

• E-mail your question via the Internet to help@

sti.nasa.gov

• Fax your question to the NASA STI Help Desk 

at 301–621–0134

• Telephone the NASA STI Help Desk at

 301–621–0390

• Write to:

 NASA Center for AeroSpace Information (CASI)

 7115 Standard Drive

 Hanover, MD 21076–1320
Sanjay Garg

Glenn Research Center, Cleveland, Ohio

Implementation Challenges for

Multivariable Control

What You Did Not Learn in School!

NASA/TM—2008-215027

January 2008

AIAA– 2007–6334

National Aeronautics and

Space Administration

Glenn Research Center

Cleveland, Ohio 44135

Prepared for the

Guidance, Navigation and Control Conference

sponsored by the American Institute of Aeronautics and Astronautics

Hilton Head, South Carolina, August 20–23, 2007
Available from

NASA Center for Aerospace Information

7115 Standard Drive

Hanover, MD 21076–1320

National Technical Information Service

5285 Port Royal Road

Springfi eld, VA 22161

Available electronically at http://gltrs.grc.nasa.gov

Level of Review: This material has been technically reviewed by technical management. 
at Lewis Field

Glenn Research Center

Implementation Challenges for 

Multivariable Control

What You Did Not Learn in School!

Sanjay Garg

National Aeronautics and Space Administration

Glenn Research Center

Cleveland, Ohio 44135

Abstract

Multivariable control allows controller designs that can provide decoupled command tracking and 

robust performance in the presence of modeling uncertainties. Although the last two decades have 

seen extensive development of multivariable control theory and example applications to complex 

systems in software/hardware simulations, there are no “production” flying systems – aircraft or 

spacecraft, that use multivariable control. This is because of the tremendous challenges associated 

with implementation of such multivariable control designs. Unfortunately, the curriculum in schools 

does not provide sufficient time to be able to provide an exposure to the students in such 

implementation challenges. The objective of this paper is to share the lessons learned by a 

practitioner of multivariable control in the process of applying some of the modern control theory to 

the Integrated Flight Propulsion Control (IFPC) design for an advanced Short Take-Off Vertical 

Landing (STOVL) aircraft simulation.

NASA/TM—2008-215027 1
at Lewis Field

Glenn Research Center

Overview

• Control design problem and typical 

mathematical formulation

• Unique nature of multivariable control (MVC)

• Benefits and Capabilities of MVC 

• Challenges and barriers to using MVC in real 

systems (with reference to STOVL IFPC Design)

– Right problem formulation

– Major implementation issues

– Making changes on-the-fly

• Conclusion

Overview

The paper, which is based on a lecture on the topic as part of the NASA NESC (NASA Engineering 

and Safety Center) course on Satellite Attitude Control Systems, covers the following topics: i) 

Unique nature of “Multivariable Control (MVC)”; ii) Benefits and Capabilities of Multivariable 

Control; iii) Challenges and barriers of using multivariable control designs in real flight systems. The 

paper starts by describing what is meant by Multivariable Control and provides a brief comparison of 

“Classical” versus “Modern” methods of control law design. The motivation for using Multivariable 

Control is then discussed in terms of robustness and performance benefits of various synthesis 

approaches (e.g., LQG/LTR (Linear Quadratic Gaussian/Loop Transfer Recovery), H-infinity etc.). 

A practitioner’s perspective is provided on when to use Multivariable Control – and more 

importantly when not to! Some of the challenges associated with formulating the problem right 

within the limitations and flexibilities of the multivariable control synthesis techniques are then 

discussed with a focus on 3 areas: Control effector blending, addressing nonlinearities, and controller 

stability. Insight is provided into two major issues with implementing multivariable control: Gain 

Scheduling, and Integrator Wind up Protection. Finally, the issue of having to make amendments 

based on problems encountered during testing and/or operation is discussed.

The above challenges and barriers are discussed with reference to the author’s experience with the 

STOVL IFPC design and its evaluation on a fixed-base piloted simulation. Tools and techniques for 

overcoming some of the barriers are also presented with illustrative examples from the STOVL IFPC 

design study. The hope is that this paper will provide a basis for students of multivariable control 

theory to get a broad perspective of issues that need to be addressed when it comes to implementing 

the theory based designs to complex systems.

NASA/TM—2008-215027 2
at Lewis Field

Glenn Research Center

Control Design Problem

• Given model of “plant,” find control law which provides:

– Desired command tracking in presence of disturbances

– Robustness to modeling uncertainties

– Stable operation when encountering limits

• Keep integrated system perspective when developing control

Actuators Engine System

Modeling

Sensors

S1

S2

S8

O1

O2

O8

Weights

DT

Isolation

Information 

Compression

Information 

Regeneration

N1

N6

Sensor

Readings

Sensor

Estimates

Diagnostics

and

Prognostics

+ -

PLA

Controller

Control Design Problem

Simply stated, the control design problem is: Given a model of the “plant”, find control law which 

provides desired command tracking in the presence of disturbances, robustness to modeling 

uncertainties and stable operation when encountering limits. Although the focus of this paper is on 

the control laws which are embedded in the controller hardware, it is important to keep an overall 

systems perspective in mind when designing the control laws since a control system consists of many 

separate components, such as the actual control hardware and software, an actuation system, a 

sensing system, on-board models etc.

It is important to note that the real plant always has some disturbances e.g., gust for flight control. 

These disturbances need to be adequately represented in the formulation of the control design 

problem. Also, do not forget, that when you do the control law design, you’re working with a 

mathematical model of the plant. Modeling has many issues; there are uncertainties associated with 

the modeling approach as well as the parameters used to represent physical phenomenon, 

approximations are made to keep the mathematical model tractable, etc. It is important to be 

knowledgeable about the assumptions made in developing the mathematical model of the plant and 

what impact these assumptions might have in terms of controlling the model vs. controlling the plant. 

The importance of robustness to modeling uncertainties is very well understood and there has been 

extensive literature on robust control design methods.

However, the third requirement, to have stable operation when encountering limits, is typically not 

covered in control courses. Every system has hardware limits, such as actuator positions and rates, as 

well as operational limits imposed for safety. It is important to have a good understanding of the 

typical limits for a system and to build in limit protection such that the control laws will provide 

graceful performance degradation and will not drive the system unstable when limits are 

encountered.

NASA/TM—2008-215027 3
at Lewis Field

Glenn Research Center

MVC Unique Nature

• Systems with >1 output being controlled by >1 manipulated input,

with any given input affecting more than single output: multiinput/multi-output (MIMO) 

• “Classical” methods: based primarily on frequency domain 

approach, extend single-input/single-output (SISO) transfer function 

techniques, e.g., Nyquist, to MIMO transfer function matrix

• “Modern” methods: based on state-space approach, formulation of 

quadratic cost function resulting in linear control law typically solved 

through system of Ricatti equations

– Control solution easily amenable for digital implementation

– Analysis typically done using multivariable frequency domain 

techniques

• Unlike simple gain and phase margin measures for SISO, 

“robustness” determination of MVC control requires complex 

analyses using singular value techniques and Monte Carlo 

simulations

MVC Unique Nature

A multivariable control or a multi-input/multi-output (MIMO) system is a system with more than one 

output being controlled by more than one manipulated input. And the important part is that any given 

input affects more than a single output. If each input only affects a single output, then you basically 

have a combination of single-input/single-output systems, and you don’t need multivariable control 

for that. There are many approaches to MVC – some approaches such as Multivariable Nyquist 

Theory extend the classical single-input/single-output approaches to multivariable control, modern 

state-space based methods which center around an optimal solution of a quadratic cost function, 

optimization methods such as neural networks etc. The discussion in the rest of the paper is pertinent 

to any multivariable control design regardless of the synthesis approach, however, the discussion will 

be based on controllers synthesized using modern state-space based methods. There are emerging 

nonlinear control design approaches such as MPC (Model Predictive Control) which might not have 

some of the same issues as those being discussed in this paper. However, such approaches are still at 

a development stage with respect to aerospace applications.

As an aside, it is important to note that the quadratic formulation of the cost function is used in 

typical state-space methods, such as LQR (Linear Quadratic Regulator) because it results in an 

optimal control law which is linear – typically obtained through solving a system of Ricatti 

equations. The control solution is easily amenable to digital implementation, as well as allows all the 

linear analysis tools to be used for performance and robustness analysis of the closed-loop system.

Analysis of control laws is still done using frequency domain techniques. So, to be a good control 

design engineer, it is very important to get the basics right with respect to frequency domain 

analyses. If you don’t understand gain margin, phase margin, Bode plots etc. and their implications 

for closed loop system performance and robustness, it’s very, very difficult to apply the multivariable 

frequency domain analyses techniques, such as singular value analysis and “mu-analysis” techniques 

in a meaningful way. 

NASA/TM—2008-215027 4
at Lewis Field

Glenn Research Center

MVC Benefits and Capabilities

• “1-step” control solution for complex intercoupled systems

– Decoupled command tracking

– “Optimal” control usage

• When to use MVC:

– System has high level of input/output coupling and not 

much separation in loop bandwidths

– Physics of problem are reasonably well-understood to be 

able to use “design handles” effectively

– System is complex with large number of states

– When sequential SISO loop closure will not meet 

performance requirements!

• Remember: MVC cannot make 747 fly like F-16 !

MVC Benefits and Capabilities

Why use multivariable control? Because if you have a truly MIMO (multi-input/multi-output) 

system, doing sequential loop closures or trying to do decoupled command tracking becomes very, 

very difficult. Multivariable control provides “one-step” solution for complex intercoupled systems 

with systematic approaches to perform the fundamental trade-offs between performance, control 

usage and robustness. Although the typical quadratic cost function formulation implies that the 

control law is “optimal” in some way, as will be discussed later, it is important to be aware that the 

“optimality” is based on the way the design plant is formulated, including the choice of the weights 

in the quadratic function, for control law synthesis and it might lead to unexpected results in terms of 

control usage when implemented on the system.

Also it is important to emphasize that MVC cannot be meaningfully applied unless the control 

designer has a good basic understanding of the physics of the system being controlled or works in 

close coordination with someone who has such expert knowledge. The idea of “give me a math 

model and give me requirements, and I will come up with a control law that meets the requirements”

is fine for a classroom project, but does not work too well in real life. Understanding the physics of 

the problem allows the control designer to better apply the “design handles” in the selected control 

synthesis approach and to ensure that the limitations of the math model will not result in a control 

law that does not meet the design requirements when integrated with the physical system.

No matter how fancy your multivariable control synthesis approach is, or how good a control 

designer you are, you cannot make a 747 actually fly like an F-16, because of the inherent dynamics 

of the system and the limitations on the available control authority! The physical properties such as 

mass, inertia, aerodynamics, control surface sizes etc. determine the limitations on achievable 

performance, regardless of what control synthesis technique is used.

NASA/TM—2008-215027 5
at Lewis Field

Glenn Research Center

Typical MVC Approaches

• Loop shaping techniques such as LQG/LTR, H-infinity, Mu-synthesis

– Trade-off between performance, robustness and control usage

– Control objectives are indirectly reflected in formulation—requiring 

iteration to ensure objectives are met

• Critical to formulate problem such 

that it reflects design goals

- Control rate weighting to 

reflect rate limits

- Scaling to accommodate 

large variations in dimensions

•Typical state-based approaches have controller order > “plant” order; 

controller order reduction becomes necessary

Typical MVC Approaches

Modern multivariable control approaches such as H-infinity, mu-synthesis, LQG/LTR (Linear 

Quadratic Gaussian/Loop Transfer Recovery) take the best of state-space and frequency domain 

techniques and merge them for robust control synthesis. All these are based on providing “handles”

to make intelligent tradeoffs, through trial and error, between performance, robustness and control 

usage. The fundamental trade-off between performance and robustness for closed-loop systems is 

evident from the relationship between the sensitivity and transmission (complimentary sensitivity) 

functions which is covered in a typical multivariable control course. 

The generic formulation for H-infinity control synthesis is shown in the block diagram. By selecting 

appropriate weightings WS, WT, and WC on the sensitivity, transmission and control functions, 

respectively, the designer can achieve the desired trade-off between performance, robustness and 

control usage. In terms of control usage, it is important to provide a mechanism to limit the control 

rate in the synthesis process. If the control rate is not weighted properly, it is possible that the control 

law will result in large control rates thus hitting the control rate limit and violating all assumptions of 

linearity. When formulating the design plant, it is also important to keep in mind that scaling has a 

significant impact on the resulting control law. All the multivariable analyses tools are based on 

inputs and outputs being of comparable dimensions. For instance, in aircraft engine control, we have 

interest in controlling the rotor speed, measured in 1000s of rpm, and pressure gain across the fan, 

measured in single digit psi. If the design model is not scaled appropriately, the large units for fan 

speed will end up overshadowing the small changes in pressure.

The order of the controller resulting from modern multivariable control methods is equal to or greater 

than the order of the design plant. From implementation perspective (limited throughput and memory 

in control hardware), it is important to keep the controller order low, so typically controller order 

reduction will be necessary.

NASA/TM—2008-215027 6
at Lewis Field

Glenn Research Center

MVC Design Challenges:

Right Problem Formulation

• Synthesis methods based on mathematical formulation 

that allows for “easier” solution—only indirectly address 

control objectives

• Numerical stability might require some modifications:

– Scaling (discussed earlier)

– Replacing pure integrators with “slow poles”

• Overlooking key physics of problem in process of 

formulating “design plant” can lead to problems

– Control effector blending

– Addressing nonlinearities

– Controller stability

MVC Design Challenges: Right Problem Formulation

The control synthesis methods are based on a mathematical formulation that allows for “easier”

solution – they only indirectly reflect the control objectives. For instance, as discussed earlier, there 

is no direct way of incorporating control position and rate limits in the synthesis process. Since, 

typically the control law solution consists of solving a set of algebraic Ricatti equations, it might be 

necessary to make some modifications in the “design” plant to make sure that numerical stability 

problems are not encountered. Plant scaling and replacing pure integrators with slow poles are some 

examples of such modifications. 

As was discussed earlier, lack of understanding of the “physics” of the problem can lead to totally 

unacceptable control law designs. Three things to keep in mind, which have a significant impact on 

practical applicability of the control law synthesized through the multivariable control design 

technique are: i) Control effector blending; ii) Addressing nonlinearities within the capability of the 

linear methods; iii) Assessing the stability of the controller itself. These issues and how to properly 

address them will be discussed in the next section. 

NASA/TM—2008-215027 7
at Lewis Field

Glenn Research Center

MVC Design Challenges: 

Control Effector Blending

• Typical quadratic type formulations can result in controls 

“fighting” each other, specially if 2 control effectors have 

very similar influence on plant

• Use knowledge of problem physics to “blend” or “gang”

control effectors into pseudo-controls

– Typically blend physical effectors into effective force 

and moment generators

MVC Design Challenges: Control Effector Blending

If the design plant is such that 2 or more control effectors have “similar” effect on the plant, then the 

“optimal” control law might be such that the control effectors end up “fighting” each other in order 

to provide the best performance. It is best to use the knowledge of the physics of the problem to 

blend or gang control effectors into pseudo-controls for the mathematical formulation. For physical 

control effectors, you would typically combine them into effective force and moment generators. 

The schematic shown above is for a conceptual advanced STOVL (Short Take-Off and Vertical 

Landing) aircraft which was used for development of integrated flight/propulsion control methods 

(see Reference below). In the transition from cruise to hover phase, the aircraft is controlled using 

both aerodynamic effectors (elevons and rudder) and propulsive effectors (ejectors on the wings, 

vectorable main and ventral nozzle and 5 RCS (reaction control system) thrusters). Although there 

are 5 RCS thrusters, it is important to note that the Pitch RCS and the 2 Yaw RCS thrusters provide 

thrust only in one direction. So the Pitch RCS is used for pitch up commands while the two Roll RCS 

thrusters are used collectively for pitch down commands. Similarly, the right Yaw RCS is used for 

heading left whereas the left Yaw RCS is used for heading right. If both the Yaw RCS thrusters were 

used in the control design model, then it will result in a control law that uses the two thrusters 

differentially to improve yaw control which will be inconsistent with the implementation, i.e., only 

one or the other should be active. Similarly, if both the Roll RCS thrusters along with the Pitch RCS 

thrusters are used in the control design model, then the control law can result in Roll thrusters 

fighting the Pitch thruster and will also command downward Pitch RCS for pitch down maneuvers 

which is again inconsistent with the actual implementation. How to do the control blending to 

address the limitations of the RCS thrusters will be discussed next.

Ref: Garg, S., “Robust Integrated Flight/Propulsion Control Design for a STOVL Aircraft Using Hinfinity Control Design Techniques,” Automatica, vol. 29, no. 1, pp. 129–145, 1993.

NASA/TM—2008-215027 8
at Lewis Field

Glenn Research Center

MVC Design Challenges: Control 

Effector Blending (cont.)

RCS blending for STOVL 

aircraft

• Use 3 “effective” RCS 

areas

• Allows formulating 

“design plant” such that 

it reflects how control 

effectors are actually 

used

MVC Design Challenges: Control Effector Blending (cont.)

For the purposes of H-infinity based MVC synthesis for the STOVL aircraft, the 5 RCS thruster 

areas were combined into 3 effective areas – AQR, AYR and ARR for pitch, yaw and roll control, 

respectively. An RCS distribution logic that will distribute the three design model RCS commanded 

areas to the five actual areas in the nonlinear control implementation is shown in the figure above. 

Since the Pitch RCS thruster only provides positive (pitch up) pitching moment, a negative AQR 

command is distributed among the left and right wing tip RCS thrusters to generate the commanded 

negative pitching moment taking into account the relative pitch control effectiveness of the nose and 

wing tip RCS thrusters. The ARR command is distributed differentially among the 2 Roll thrusters, 

and the AYR command is sent to either the left or the right Yaw RCS thruster depending on the 

direction for the heading command.

This approach allows formulating the design plant such that it reflects how the control effectors are 

actually used.

NASA/TM—2008-215027 9
at Lewis Field

Glenn Research Center

MVC Design Challenges: 

Addressing Nonlinearities

• Linear control design methods assume that “plant” behaves linearly 

in neighborhood of design point

– Not always true for some nonlinearities: e.g., Hysteresis, 

Stiction, Absolute value etc.

• For STOVL example:

– RCS uses bleed flow that acts as disturbance for engine

– WB ~ Abs (ARCS)—you can’t pump airflow into engine through 

RCS!

– Integrating airframe/engine model removes explicit dependence 

on bleed flow with ARCS appearing as direct control effectors

• Control design using linear integrated controller results in 

ARCS being used to improve engine dynamics by pumping 

flow back!

• Fix: Design model modified:

– Elements of “B” matrix from ARCS to engine states are zero

– Bleed flow added as external disturbance to engine states

MVC Design Challenges: Addressing Nonlinearities

The linear design methods assume that the plant behaves linearly in the neighborhood of the design 

point. This is not always true for some nonlinearities such as hysterisis, stiction, absolute value etc. 

Care should be taken in formulating the design plant when there are such nonlinearities in the 

system.

For the STOVL integrated flight/propulsion control design example, engine compressor bleed flow is 

used for the RCS thrusters. Note that there is an absolute value nonlinearity in the relationship from 

commanded RCS areas compressor bleed flow demand in that although the RCS area may be 

positive or negative, depending on the desired direction of the RCS thrust, the compressor bleed flow 

demand (WB) to generate the thrust is always positive. In an earlier control design problem 

formulation, this nonlinearity was not properly accounted for and the resulting controller was shown 

to lead to unacceptable performance when evaluated with this nonlinearity. The linear control design 

was such that RCS areas were being used to “pump back” air into the engine to regulate the engine 

dynamics in the presence of disturbances due to aircraft motion.

The physics of the problem says that the bleed flow acts as a disturbance on engine dynamics and 

that the RCS thrusters are to be used for flight control and not for engine control. To reflect this 

physics, the elements of the control input matrix, “B” in the linear design plant, which relate RCS 

areas to engine states were set to 0, i.e., the RCS areas do not affect the engine operating point, and 

bleed flow was added as an external disturbance affecting the engine dynamics in the design plant. 

This formulation resulted in a linear control law design which was able to regulate engine dynamics 

in the presence of bleed flow demands to achieve commanded aircraft maneuvers. See the Reference 

listed on page 8 for further details of this design plant formulation and the closed-loop controller 

evaluation.

NASA/TM—2008-215027 10
at Lewis Field

Glenn Research Center

MVC Design Challenges: 

Controller Stability

• MVC design approaches “guarantee” closed-loop stability—what 

about stability of controller itself?

K(s) G(s) K(s) Stable?

• Implementation issues such as independent V&V, operation across 

multiple modes, etc. require that controller implemented be stable

• Check resulting design from your favorite synthesis method to make 

sure controller is stable

• What if it is not?

– Do analysis to see if design plant is “strongly stabilizable”

– Try making changes in performance specifications and/or design 

plant formulation

MVC Design Challenges: Controller Stability

MVC synthesis techniques guarantee stability of the closed loop system, but what about the stability 

of the controller itself? None of these techniques guarantee the stability of the controller (K(s) in the 

above figure). The novice control designer might ask: “why do I care about controller stability as 

long as the closed-loop system is stable?”. One has to keep in mind that implementing the controller, 

as software in the control hardware, requires independent Verification and Validation (V&V) of the 

control software. If the controller design is unstable, this V&V becomes extremely difficult since the 

outputs will exceed the limits very fast. Also, typically there are multiple control modes for operation 

over a wide envelope. For aircraft, the control mode switches from ground control to flight control 

based on the WoW (Weight on Wheels) switch. Having an unstable controller in any of the modes 

makes it difficult to predict as to what is going to happen when the mode switching takes place.

Since MVC synthesis techniques do not guarantee controller stability, it is essential to check the 

stability of the controller resulting from a particular design formulation. If the controller is stable you 

can proceed to next step, otherwise you have to use trial and error to see if the synthesis problem can 

be formulated in such a way as to result in a stable controller. This might mean changing the 

performance specifications, i.e., choosing different weighting functions, adding different sensors, 

choosing different outputs to control etc. If the plant is unstable and you set aggressive performance 

goals, then there’s a high likelihood that you might end up getting an unstable controller. 

An unstable plant is called “strongly stabilizable” if there exists a stable controller which will 

stabilize the plant in a closed-loop system. If the plant is not strongly stabilizable, then no MVC 

approach will give a stable controller. However, most physical systems are “strongly stabilizable” or 

can be made so by the right choice of sensors. If repeated trials end up in an unstable controller, then 

it is worthwhile to perform analysis to see if the plant is strongly stabilizable.

NASA/TM—2008-215027 11
at Lewis Field

Glenn Research Center

MVC Implementation Challenges: 

Controller Scheduling

• Implementation requires “gain scheduling” controller for operation 

over wide envelope

– Controller of order n with r inputs and m outputs requires 

n(1+m+r)+mr parameters scheduled

– Closed-loop stability not guaranteed between design points

• Simplified scheme that exploits 

robustness of control design

• Match loop transfer function at 

controlled output

• Determine Ks to:

Min||G(s)KsK0(s) –

G0(s)K0(s)||

• Only m2 parameters to 

schedule

MVC Implementation Challenges: Controller Scheduling

The traditional approach to designing feedback control laws for complex nonlinear systems is to 

design linear control laws at various operating points and then “gain schedule” the control laws 

through some kind of curve fitting of the various controller gains with the critical operating point 

variables as the independent scheduling parameters. One of the difficulties with implementing gain 

scheduling for MVC laws is the complexity of the scheduling. For a controller of order n with r

inputs and m outputs, there will be n(1+m+r)+mr controller parameters to schedule. Furthermore, 

although the closed-loop system is stable for all design points, the stability of the closed-loop system 

is not guaranteed when operating between design points.

The fundamental objective in using Robust MVC design techniques is to reduce the controller 

complexity while guaranteeing the desired performance and robustness characteristics. The above 

figure shows a simplified controller scheduling scheme which consists of scheduling only the output 

matrix of a nominal controller which is designed to give a robustly stable closed-loop system over a 

wide range of plant operating conditions. The scheduling scheme is of the form: K(s) = KsK0(s), 

where K(s) is the scheduled controller, Ks is the controller output scheduling matrix and K0(s) is the 

nominal controller. For such a scheduling scheme there are only m2 parameters to schedule. The 

approach to synthesize the scheduling gains Ks consists of applying parameter optimization 

techniques such that the transfer function matrix with the loop broken at the controlled outputs ((i) in 

fig. b. above) “closely” matches the output loop transfer matrix of the nominal control loop. The 

details of the controller scheduling synthesis approach are described in the Reference listed below. 

This scheduling scheme is highly effective when the major change in the plant across the different 

operating points is in control effectiveness. An example application will be discussed next.

Ref.: Garg, S., “A Simplified Scheme for Scheduling Multivariable Controllers,” IEEE Control 

Systems, August 1997, pp. 24–30.

NASA/TM—2008-215027 12
at Lewis Field

Glenn Research Center

MVC Implementation Challenges: 

Controller Scheduling (cont.)

• Solved as constrained 

parameter optimization 

problem:

– Control design at

80 knots provided 

stability robustness for 

100-knot model

– Primary change from 80-

to 100-knot model was 

in control effectiveness

– Simplified scheduling 

scheme provided close 

to “nominal” response at 

off-design point

STOVL Example

MVC Implementation Challenges: Controller Scheduling (cont.)

The STOVL IFPC design discussed earlier was implemented as separate, but interconnected, flight 

and propulsion controllers. The H-infinity based design was performed at the nominal flight 

condition corresponding to 80 knots air speed. The controller was designed for the transition flight 

regime, where the control of the aircraft is transitioning from aerodynamically generated forces to 

propulsive forces, which ranges from 50 to 120 knots. Since the nominal control design provided 

closed loop stable response throughout the transition flight regime, and also the most significant 

change in aircraft response to control inputs in this operating regime is that of control effectiveness, it 

was decided to apply the simplified controller scheme to extend the operation of the nominal control 

design to the transition flight regime.

The results for the controller scheduling scheme application to the propulsion control are shown in 

the above figure. The solid line in the figure shows the response of the propulsion system to a step 

command in the Ventral nozzle thrust (FGV) for the nominal design point with the nominal 

controller. The dashed line shows this response for the propulsion model at 100 knots with the 

nominal controller. The need for scheduling the controller is evident from the degraded FGV 

command tracking response and the increased coupling with the engine rotor speed (N2). The dotted 

line shows the response when the controller is scheduled using the gains from the simplified 

scheduling scheme. The results indicate that the simplified scheduling provides a response which 

closely matches the response of the nominal system with the nominal controller in decoupled 

command tracking.

Detailed results of the application of the simplified scheduling scheme to the STOVL propulsion 

system control design are described in the reference listed on page 12, and those for the IFPC design 

are described in the reference listed below.

Ref.: Garg, S., and Mattern, D., “Application of an Integrated Methodology for Propulsion and 

Airframe Control Design to a STOVL Aircraft,” AIAA Paper no. 94–3611, Guidance, Navigation 

and Control Conference, Scottsdale, AZ, August 1994.

NASA/TM—2008-215027 13
at Lewis Field

Glenn Research Center

MVC Implementation Challenges: 

Integrator Windup Protection

• What is integrator windup?

– Integrator action in controller drives steady-state errors to zero

– If controller outputs are limited, such as actuator position limit, 

integral action will continue to command higher controller output—

thus controller integrator(s) will wind up

– Results in deteriorated performance since controller integrator 

must first “unwind” when high actuator deflections are not needed

– Windup can even lead to system instability

• IWP Design Requirements:

– Should: be memory-less; provide smooth transfer; be closed-loop 

stable; provide graceful performance degradation

• For SISO, IWP simply requires “stopping” integration when limit is 

encountered

• How to do this in MVC systems?

MVC Implementation Challenges: Integrator Windup Protection (IWP)

In a control system, the effort to drive steady-state errors to zero is accounted for through integral 

action on part of the controller. If at any point in time the controller outputs are limited and controller 

inputs are non-zero and of the same numerical sign (+/-), the integral action of the controller will 

attempt to increase the magnitude of the already limited controller output, thus the controller’s 

integrator(s) will wind up. Following this period of integrator windup, the controller response to 

command inputs might be very poor because the controller’s integrators must first unwind prior to 

attempting to calculate the new controller outputs for the new controller inputs. Thus, Integrator 

Windup Protection (IWP) must be included in control systems designed for tracking commands with 

zero steady-state error.

Integrator windup protection (IWP) design requirements are: i) Should be memory-less and not 

contribute to controller output when actuation system limits are not encountered; 2) Should provide 

smooth transfer between limited and unlimited case and provide accurate tracking of limited actuator; 

3) Should be closed-loop stable for all possible limit combinations; 4) Should attempt to maintain 

system performance and provide graceful degradation when limit is encountered.

For single-input single-output systems, simply stopping the integration when a limit is encountered 

meets all the IWP requirements. It is not clear as to how to best implement IWP in multivariable 

control systems. Numerous ideas for integrator windup protection and bumpless transfer have been 

published in literature and will be discussed briefly next. 

NASA/TM—2008-215027 14
at Lewis Field

Glenn Research Center

MVC Implementation Challenges: 

IWP (cont.)

• Controller states modified based on difference between 

commanded and limited actuator value

• Gains selected to provide stable effective controller,

1 column at time for single limited actuator

• Typical IWP synthesis 

techniques require 

controller to be 

represented in specific 

form and do not 

guarantee closed-loop 

system stability

– Very much trial and error

MVC Implementation Challenges: IWP (cont.)

To implement IWP on MVC systems, the controller is represented in the form shown in the above 

figure. The block “Integrator Windup Protection Gains” is added to the controller to modify the 

controller states whenever an actuation limit is encountered. The inputs to this block are the errors 

between the outputs of the controller (the commands to the actuators) and the actual actuator 

positions with the limit in place. This implementation of the controller meets IWP design 

requirement 1, that the IWP be memoryless and not affect the system when the controller outputs are 

not being limited.

The IWP design techniques for MVC systems that have been published in literature consist of 

selecting the IWP gains one column at a time considering a single actuator to be limited. The column 

of gains is selected to ensure that the modified controller remains stable and provides good tracking 

of the limited command so as to minimize integrator windup, thus meeting the IWP requirement 2 

listed earlier. However, this approach does not guarantee that the closed loop system will remain 

stable when the IWP becomes active. Neither does it provide a systematic way of ensuring that the 

closed-loop performance will degrade gracefully when the limits are encountered. Application of this 

approach to the STOVL IFPC design resulted mostly in severe degradation in performance when the 

actuator limits were encountered, and in some instances this approach even resulted in the closedloop system being unstable with the modified controller.

A parameter optimization based scheme was developed to determine the IWP column gains such that 

for a single actuator saturation, the modified controller and the closed-loop system will remain stable 

while minimizing the loss in tracking performance compared to the “unlimited” system performance. 

This approach, which is described in detail in reference listed below, will be discussed next.

Ref.: Watts, S.R., and Garg, S., “An Optimized Integrator Windup Protection Technique Applied to 

a Turbofan Engine Control,” AIAA Paper No. 96–3814, Guidance, Navigation and Control 

Conference, San Diego, CA, July 1996.

NASA/TM—2008-215027 15
at Lewis Field

Glenn Research Center

MVC Implementation Challenges: 

IWP (cont.)

• Gains determined to 

trade-off actuator 

and system tracking 

errors using 

parameter 

optimization 

approach

• Limits gains to 

ensure controller and 

closed-loop system 

stability

STOVL Engine 

Example Results

Optimized 

IWP 

Technique

MVC Implementation Challenges: IWP (cont.)

The generalized design plant for determining the parameter optimization based IWP gains is shown 

in the figure above. This problem set up allows for the calculation of errors between the nominal 

closed-loop, or “ideal” system, and the limited system with IWP for the performance loops and the 

actuator command tracking error. The performance errors, ZERROR, are defined as the difference 

between the response of controlled variables for the nominal system, ZNOM, and the response of the 

controlled variables for the limited system with IWP, ZLIMITED. The controlled actuator error, 

UERROR, is defined as the difference between the commanded actuator position, UC, and the 

controller with IWP commanded actuator position, U. For a single actuator being limited, the 

corresponding column of the IWP gains is obtained by minimizing the weighted sum of squares of 

ZERROR and U . The relative weighting between these two errors can be used as a “design handle”

to trade-off between providing tight IWP versus providing tighter tracking performance. The closedloop stability and controller stability is guaranteed with the selected IWP gains by checking for both 

during the optimization process and setting the cost being minimized to be high if any of these 

conditions is violated.

The second figure above, from reference listed below, shows an example result from application of 

the optimized IWP technique to the propulsion control portion of the STOVL IFPC design. Shown 

are the response of the aft nozzle thrust (FG9) to a step command and the corresponding fuel flow 

(WF36) requirement with and without the IWP. Without IWP, dashed lines, when the fuel flow limit 

is encountered, the fuel flow command continues to grow because of integrator wind up. As the FG9 

command is taken out, the integrator takes time to wind down and the FG9 response is degraded. 

With IWP active, solid lines, the fuel flow command tracks the fuel flow limit and good FG9 

tracking performance is obtained when the step command is removed.

Ref.: Mattern, D., and Garg, S., “Propulsion System Performance Resulting from an Integrated 

Flight/Propulsion Control Design,” AIAA Paper No. 1992–4602, Guidance, Navigation and Control 

Conference, Hilton Head, SC, August 1992.

NASA/TM—2008-215027 16
at Lewis Field

Glenn Research Center

Iterative Process for Control Design

• Simplistic look at control design and implementation process:

Math

Model

Prob

Form

Control

Logic Eval

Software

and V&V

Hardware

Testing

Specs

Spec 

Met?

Yes

No

Good to Go

Now What?

• Classical/SISO approaches provide “knobs” that can be tuned 

during “hardware” testing process to meet specs

– Easier to make minor mods for small changes in plant

• Not clear how to do this with MVC

– Typically need to go back to control logic design or earlier steps

Iterative Process for Control Design

The figure above provides a very simplistic look at the control design process. Given performance 

specifications and a math model of the system, the control design problem is formulated in such a 

way as to provide the desired trade-off between performance, robustness and control usage. Once an 

acceptable control law is obtained through the control synthesis process, it is implemented in the 

nonlinear simulation and tested to ensure that controller scheduling and limit protection are 

appropriately implemented. Once the nonlinear evaluation provides satisfactory results, then the 

control laws are converted to software to be implemented in the control hardware. Extensive 

software V&V (Verification and Validation) is conducted to ensure that the software is error free and 

faithfully implements the control law as designed. The control software is then implemented on 

hardware and hardware-in-loop testing and testing on the actual system (flight test for example) is 

conducted.

This is where the so-called “rubber hits the road”. Till now all the control development and 

evaluation had been based on some mathematical models, and mathematical formulations of 

uncertainties etc. Once the control is implemented on the real system and tested under realistic 

operating conditions, that is the final test of whether the control design meets the system performance 

objectives or not. Rarely does it happen that the control design as first implemented meets all the 

objectives over the wide operating envelope. Typically there will be shortcomings identified in the 

testing and these will have to be fixed in order to certify the control design as fully operational.

For single-input single-output systems with classical control structure, such as PID 

(Proportional+Integral+Derivative), the control gains provide individual “tuners” to be adjusted 

during testing to make modifications as needed. How to do such modifications on the fly for MVC 

systems is not at all clear. One almost has to go back to the step one of reformulating and 

resynthesizing the original control law in order to address the shortcoming. This is one of the 

fundamental reasons why MVC has not found application in operating aerospace systems.

NASA/TM—2008-215027 17
at Lewis Field

Glenn Research Center

Modifying MVC Designs

• Understanding physics of problem useful to make mods without 

having to resort to major control redesign

• STOVL example:

– Initial piloted evaluation showed high-frequency pitch oscillation

– Cause of oscillation isolated to time-delays because of digital 

implementation; duplicated by including time delay in simulation

– Pitch damping improved by 

adding pitch rate error 

feedback to elevator

K(s) G(s)

Keq eq Δδe

Modifying MVC Designs

All is not lost though when it comes to having to make modifications to the MVC design in the final 

stages of testing. Understanding the physics of the problem comes in useful in making the 

modifications without having to go back to step 1 of reformulating the control design problem and 

starting all over with the controller synthesis.

For the STOVL IFPC design, initial piloted evaluations in a fixed-base simulator uncovered some 

problems which had not been apparent in the non-realtime evaluation of the design. One of the 

problems was a pitch oscillation during deceleration from cruise to hover. The figure above shows 

the pitch attitude response of the aircraft, from the simulator, for a simultaneous command of flight 

path change and deceleration. The solid line in the figure above is for the nominal IFPC design and 

shows the pitch oscillation. Analysis indicated that this oscillation is due to the significant time delay 

between the computer that hosts the aircraft simulation and the computer that implements the IFPC 

design. The IFPC design was such that it resulted in a low damped aircraft short period mode, and 

the phase loss due to time delay in the real-time simulation environment resulted in the observed 

oscillatory behavior.

To improve the damping of the pitch mode, the IFPC design was modified to include an additional 

constant gain feedback loop from the pitch rate error to the elevator as shown in the block diagram 

above. The root locus technique was used to determine the value of the feedback gain to provide 

improved short period mode damping without having any significant effect on the other closed-loop 

poles. The dashed line in the above figure shows that with this modification, the IFPC design 

resulted in well damped pitch response. The reference listed below provides additional details of how 

such knowledge of the physics led to successful implementation of the IFPC design.

Ref: Bright, M.M., et al. “Piloted Evaluation of an Integrated Methodology for Propulsion and 

Airframe Control Design,” AIAA Paper No. 94–3612, Guidance, Navigation and Control 

Conference, Scottsdale, AZ, August 1994.

NASA/TM—2008-215027 18
at Lewis Field

Glenn Research Center

Conclusion

• Potential benefit of multivariable control design: 

“Improved performance and robustness to modeling uncertainties 

achievable with highly complex systems”

• Use MVC design with Caution:

– Make sure MVC is really needed

– Get good understanding of physics of problem

• You cannot make 747s fly like F-16s, no matter how good a 

control engineer you are!

– Make sure that synthesis problem is formulated right

• Control effector blending

• Nonlinearities around small perturbation model

• Controller stability and order

– Give thought to scheduling and IWP issues before deciding on 

control structure

• Keep these as simple as possible

– Use knowledge of system to make “smart” amendments based 

on test results

Conclusion

Potential benefit of multivariable control is the improved performance and robustness to modeling 

uncertainties, achievable with highly complex systems. So if you are working with a highly complex 

system and very tight performance requirements, then maybe multivariable control is the way to go. 

However, multivariable control should be used with caution and analysis should be done to ensure 

that the use of MVC is justified.

As discussed throughout the paper, getting a good understanding of the physics of the problem is 

essential for the MVC design to be successful in realistic application. Remember that the control 

synthesis process is just a convenient mathematical formulation which results in a tractable, solvable 

control law. The formulation has to take into account the inherent limitations of achievable 

performance for the “plant”. You cannot make a 747 fly like an F-16, no matter how good a control 

engineer you are. Formulating the synthesis problem right means you pay adequate attention to 

issues such as control effector blending, available control authority and effect of nonlinearities 

around the small perturbation model. Once the synthesis process results in a controller that meets the 

closed-loop performance specifications, at least for the design plant, then from an implementation 

perspective, it is important to ensure that the controller itself is stable and that its order can be 

reduced to a “reasonable” number of states. Before starting with the controller synthesis process, 

thought should be given to the overall controller structure in terms of gain scheduling and integrator 

wind up protection. As has been discussed in the paper, the robustness characteristics of the 

controller design can be used to simplify the controller scheduling. 

Finally, use knowledge of the system to make smart amendments based on test results. Keep in mind 

that the controller will be implemented in discrete form and computational effort and sampling will 

result in effective time delays which should be accounted for in the design. Some of the 

shortcomings of the MVC design can be overcome in the implementation stage by applying classical 

control methods in conjunction with a good understanding of the plant dynamics.

NASA/TM—2008-215027 19
REPORT DOCUMENTATION PAGE Form Approved 

OMB No. 0704-0188 

The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the 

data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this 

burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. 

Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB 

control number. 

PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 

1. REPORT DATE (DD-MM-YYYY)

01-01-2008 

2. REPORT TYPE

Technical Memorandum 

3. DATES COVERED (From - To)

4. TITLE AND SUBTITLE

Implementation Challenges for Multivariable Control 

What You Did Not Learn in School!

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S)

Garg, Sanjay 

5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

WBS 732759.03.01.02.17 

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

National Aeronautics and Space Administration 

John H. Glenn Research Center at Lewis Field 

Cleveland, Ohio 44135-3191 

8. PERFORMING ORGANIZATION 

 REPORT NUMBER

E-16220 

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

National Aeronautics and Space Administration 

Washington, DC 20546-0001 

10. SPONSORING/MONITORS 

 ACRONYM(S)

NASA 

11. SPONSORING/MONITORING 

 REPORT NUMBER

NASA/TM-2008-215027; AIAA-2007-

6334 

12. DISTRIBUTION/AVAILABILITY STATEMENT

Unclassified-Unlimited 

Subject Category: 31 

Available electronically at http://gltrs.grc.nasa.gov 

This publication is available from the NASA Center for AeroSpace Information, 301-621-0390

13. SUPPLEMENTARY NOTES

14. ABSTRACT

Multivariable control allows controller designs that can provide decoupled command tracking and robust performance in the presence of 

modeling uncertainties. Although the last two decades have seen extensive development of multivariable control theory and example 

applications to complex systems in software/hardware simulations, there are no “production” flying systems--aircraft or spacecraft, that use 

multivariable control. This is because of the tremendous challenges associated with implementation of such multivariable control designs. 

Unfortunately, the curriculum in schools does not provide sufficient time to be able to provide an exposure to the students in such 

implementation challenges. The objective of this paper is to share the lessons learned by a practitioner of multivariable control in the process 

of applying some of the modern control theory to the Integrated Flight Propulsion Control (IFPC) design for an advanced Short Take-Off 

Vertical Landing (STOVL) aircraft simulation. 

15. SUBJECT TERMS

Engine control; Health management; Adaptive control; Intelligent systems; Fault diagnostics 

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 

 ABSTRACT

UU 

18. NUMBER 

 OF 

 PAGES

25 

19a. NAME OF RESPONSIBLE PERSON

STI Help Desk (email:help@sti.nasa.gov) 

a. REPORT

U 

b. ABSTRACT

U 

c. THIS 

PAGE

U 

19b. TELEPHONE NUMBER (include area code)

301-621-0390 

Standard Form 298 (Rev. 8-98)

Prescribed by ANSI Std. Z39-18