Stateflow 7.4

Modeling Fault Management Control Logic in an Aircraft Elevator Control System

In this demo, we use Model-Based Design to design a fault detection, isolation, and recovery (FDIR) application for a pair of aircraft elevators with redundant actuators. The control logic used in this model is the same that is used in the Avionics subsystem of the Aerospace Blockset™ demo entitled "NASA HL-20 with FlightGear Interface."

Contents

Figure 1: Top level of aircraft elevator control system model

Description of Elevator Control System

A typical aircraft has two elevators attached on the horizontal tails (one on each side of the fuselage). There are a number of redundant parts in the system to enhance safety of the aircraft.

Figure 2: Schematic showing how the components of the elevator system are connected to one another

For example, as shown in Figure 2, there are:

Control Logic for Elevator Control System

Figure 3: Actuator mode logic

Each outer actuator has a dedicated hydraulic circuit, whereas the inner actuators share one hydraulic circuit. Each actuator can be in either one of five modes: Passive, Standby, Active, Off, and Isolated. By default, the outer actuators are in the Active mode, and the inner actuators are in the Standby mode. If a fault is detected in the outer actuators or in the hydraulic circuits that are connected to them, the system responds accordingly to maintain stability by turning the outer actuators off and activating the inner actuators.

Failure Definition

If the aircraft is flying perfectly level, then the actuator position should maintain a constant value. If the position of an actuator increases or decreases by 10 cm from this zero point, then a failure has occurred in that actuator. A failure also occurs if the change in position is very rapid (i.e., the position changes at least 20 cm in 0.01 seconds).

Similarly, a fault occurs in one of the hydraulic circuits if the pressure is out-of-bounds or if the pressure changes very rapidly. In this demo, the pressure in the hydraulic circuit should always be between 500 kPA and 2 MPa, and the pressure should not change more than 100 kPa in 0.01 seconds.

Injecting Failures Into System

Figure 4: GUI used to inject failures into the system

A separate GUI (shown in Figure 4) that was created in GUIDE is used to inject failures into either the hydraulic circuits or the actuators. By checking or unchecking boxes and pressing the Update button on the GUI, custom MATLAB® code runs as an intermediary between the GUI and the Simulink® model. For example, when checking the H1 box and pressing the Update button to inject a failure into hydraulic circuit 1, the following custom MATLAB code is evaluated:

% Define H1_fail Constant block location and get current value

blockname=[mname '/Signal conditioning '...

'and failures /Hydraulic Pressures/Measured ',char(10),...

'Hydraulic system 1 ',...

'pressures/Hydraulic pressure/H1_fail'];

val=get(handles.H1,'Value');

% Change value of H1_fail Constant block from 0 to 1 or from 1 to 0.

if val

 set_param(blockname,'value','1');

else

 set_param(blockname,'value','0');

end

This effectively turns on a switch within the Signal conditioning subsystem that injects a fault into hydraulic circuit 1.

Figure 5: Switch that injects a failure into hydraulic circuit #1 if value of Constant block H1_fail does not equal 0

Responding to Failures

Stateflow® responds to failures in the hydraulic circuits and actuators using truth table functions, event broadcasting, and control logic. As an example, if there is a failure in hydraulic circuit 1 and no other failures occur, the L_switch truth table function evaluates Decision D1 as true and performs Action 2, which is to turn off the left outer actuator. This event is broadcast to the LO state, where the left outer actuator turns off. After this occurs, an event is broadcast from the LO state to the LI state so that the left inner actuator is activated. The right inner actuator is then activated since the left inner actuator is also active. When this happens, an event is sent from the RI state to the RO state to place the right outer actuator on standby. Thus, after a failure occurs in hydraulic circuit 1, the left outer actuator is turned off, the right outer actuaor is placed on standby, and the inner actuators are activated.

Isolating Actuators When Failures Occur

When a failure occurs in one of the actuators, that actuator can no longer be activated. This is represented in the state chart by adding an Isolated state that contains no outgoing transitions. Therefore, once an actuator enters the Isolated state, it remains in the Isolated state.

Recovering from Failures

A recovery mechanism has also been placed in the control logic in case a failed system comes back online. For example, if failures are no longer detected in hydraulic circuit 1, the condition !u.low_press[0] is true, and the LO state can transition from the Off state to the Standby state. That way, if a failure occurs in another system, such as the left inner actuator, then the left outer actuator can be activated.

References

Pieter J. Mosterman and Jason Ghidella, "Model Reuse for the Training of Fault Scenarios in Aerospace," in Proceedings of the AIAA Modeling and Simulation Technologies Conference, CD-ROM, paper 2004-4931, August 16 - 19, Rhode Island Convention Center, Providence, RI, 2004.

Jason R. Ghidella and Pieter J. Mosterman, "Applying Model-Based Design to a Fault Detection, Isolation, and Recovery System," in Military Embedded Systems, Summer, 2006.