1

Flight Control System Clearance using Static Tests at Iron Bird

Ambalal V. Patel♣, Vijay V. Patel♣ Girish Deodhare♣

♣ IFCS Directorate, Aeronautical Development Agency, P. B. 1718, Bangalore 560017, India,

and

Shyam Chetty♠ ♠ FMCD, National Aerospace Laboratories, Kodihalli, Bangalore 560017, India,

The Indian Light Combat Aircraft (LCA) has flown more than 485 flights so far without encountering any major faults in the flight safety critical fly-by-wire control software. This is partly due to the stringent quality control process and rigorous testing of the Control Laws (CLAW) and Air Data System Algorithms (ADS) carried out on various ground platforms such as Iron bird before flight. The pass/fail criteria for the tests carried out at the Iron bird test rig are defined based on the tolerance bounds provided on the expected results which take into account the characteristics of the associated hardware. These tolerance bounds guarantee that the correctness in functionality of the modules (CLAW, ADS) is retained, if the set of bounded inputs generate a set of bounded outputs. The processing of tolerance bounds is an algorithmic development that plays an important role in defining the acceptance criteria for the tests and enables clearance (certification) of the different modules. This paper presents the procedure used for the clearance of the static tests of the CLAW and ADS on the Iron Bird platform. The details on the pass/fail criteria for the static tests and the tool developed for generating the bounds are also described. The tolerance bounds for static tests were evolved based on manufacturer’s data, testers experience and engineering judgment gathered during various levels of testing of ADS and CLAW algorithms. This process yielded excellent results and was accepted as a formal clearance methodology for the onboard safety critical software.

I. Introduction Testing is an integral part of any aerospace program. The use of an unstable airframe and fly-by-wire control has placed stringent requirements on quality and mean time between failures of the overall system. This has resulted in increased emphasis on testing of software. Flight safety critical hardware and software are tested on various platforms before integrating on the aircraft. Extensive flight tests are then carried out to exercise the aircraft in various modes thereby ensuring reliable performance1, 7. Software failures have led to system failures, loss of life and money2. The Indian Light Combat Aircraft (TEJAS) has flown more than 485 flights without encountering any critical software failures so far. Being attempted for the first time in the country, it speaks volumes for the strict quality control in the software development process and the extensive testing carried out on the various platforms. TEJAS is an unstable platform and has a Quadruplex Digital Flight Control Computer (DFCC) embedded with advanced Flight Control Laws (CLAW) and Airdata System (ADS) algorithms for stabilization and good handling qualities3. This paper presents the procedure developed for the clearance of the end-to-end static testing of the ADS and CLAW modules on the integrated Iron Bird test platform (software and hardware). The

♣ Scientist, Integrated Flight Control System (IFCS) Directorate, Aeronautical Development Agency, P.B.1718, Bangalore – 560 017, India. E-mail: avpatel@css.nal.res.in, vvp2069@yahoo.com, and girish@dishnetdsl.net ♠ Scientist, Flight Mechanics & Control Division (FMCD), National Aerospace Laboratories, Kodihalli, Bangalore – 560 017, India. E-mail: shyam@css.nal.res.in

AIAA Guidance, Navigation, and Control Conference and Exhibit21 - 24 August 2006, Keystone, Colorado

AIAA 2006-6203

Copyright © 2006 by A.V.Patel, V. V. Patel, G.S. Deodhare, and Shyam Chetty. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.

2

details on the pass/fail criteria for the static tests and the implementation of the software tool developed for generating the nominal values and tolerance bounds are presented in this paper. The procedure used for clearance of software containing ADS and CLAW module is presented in Section II. Section III describes the Iron Bird test setup and types of tests performed. The tool used for generating expected values and tolerance bounds and processing of the tolerance bounds based on the experience gathered during initial testing of the ADS and CLAW are described in Sections IV and V, respectively. General remarks on the tolerance bound computations are given in Section VI and concluding remarks are given in the last Section.

II. Procedure used for clearance of ADS and CLAW modules The software development life cycle followed for TEJAS4 is given below -

1. The ADS and CLAW functional modules are designed and developed by the design teams and coded by the system house in ADA language for porting it on the Digital Flight Control Computer (DFCC). This on-board software is called Operational Flight Programme (OFP).

2. The modules in OFP are tested on various platforms by performing different types of tests. Once CLAW, ADS is coded in ADA, it goes through Non Real Time (NRT) testing, where the modules implemented in ADA language are validated against the designer supplied “master” code using Independent Verification and Validation (IV & V) techniques5.

3. The complete OFP software consisting of redundancy management (RM), ADS, and CLAW is ported on to the DFCC and its testing is carried out at the Iron bird with the real / simulated actuators, sensors and other aircraft hardware elements6 for subsequent ground tests of the Integrated Flight Control System (IFCS).

4. Different types of tests were performed on the DFCC at Iron bird6 and the test results are validated against the expected results. The design team also provides the tools for generating the expected results.

5. After the tests are cleared at the Iron bird, the DFCC containing the tested software is installed on the aircraft for further ground tests, which include End-to-End checks, Engine Ground Runs (EGR), Low and High Speed Taxi Trials (LSTT and HSTT).

6. Once the HSTT is cleared, the aircraft is ready for flight. Subsequently, flight-tests are carried out.

7. For every upgraded software version, the above procedure is strictly followed. The designers provide the test cases to ensure that the functionality of the each module is implemented by the system house as intended. The expected results for validation on the Iron Bird / Aircraft are also generated by designers. Testing at Iron Bird involves testing of the software and hardware in an End-To-End manner. The effects of the associated hardware characteristics influence the outputs from the software. Therefore, how close the monitored results are with respect to the expected values need to be specified in terms of certain bounds (Pass/Fail criteria for each test). These bounds on the expected values (tolerance bounds) guarantees that the functionality of the modules (CLAW, Air Data System) is retained, i.e., for a set of given inputs, the outputs lie within the expected tolerance bounds. Thus, tolerance bounds play an important role in defining the acceptance criteria for the tests and in turn enable the clearance (certification) of the modules for safe flight. For the TEJAS programme, the design team has developed an Evaluation Tool software (EVTOOL) for generating expected results and tolerance bounds taking into account various hardware characteristics, for subsequent use by the test teams. This yielded excellent results and was accepted for formal clearance of the onboard safety critical software.

III. Iron Bird Test Setup Figure 1, shows block schematic of Iron Bird setup for testing the DFCC software. Inputs (rates and accelerometers sensors, stick, pedal, and Events etc.) to the DFCC are provided from Flight Dynamic Simulator (FDS) through the Engineering Test Station (ETS). The outputs (CLAW command to actuator and intermediate test points) of the DFCC are acquired in FDS through ETS. Actuator ram positions used in the actuator feedback loop are also available. Cockpit, Data acquisition using FTI-RS422 and other interfaces also exist at the Iron Bird, but are not shown in Fig. 1.

3

Discretes / Events

Outputs

I N P U T S

ADS & CLAW (With

tolerance processing)

Tolerance bounds

generation on inputs

(Hardware characteristics)

Signal without tolerance boundsSignal with tolerance bounds

Figure 2. Block schematic of EVTOOL software.

The CLAW tests carried out at the Iron bird can be broadly classified into three categories:

i) Open loop end-to-end static tests ii) Open loop end-to-end dynamic tests iii) Closed loop tests

Performance verification tests are also conducted for testing of the ADS algorithms. Detailed descriptions for various types of tests conducted at Iron bird are available in6. Static testing involves

• Scaling and defining the sign convention of the DFCC input and output variables

• Studying the effect of the various CLAW elements (non-linearities, rate limiters, etc.) implemented in the DFCC

• Ensuring the output tracking of all the four channels of the DFCC • Testing the Functionality of the CLAW for nominal and active status of the different CLAW

events In static tests, fixed inputs are applied for finite time either individually or in combination so that the intermediate signals and output signals settle down to their steady state values. The values are selected judiciously to invoke all segments of the various nonlinearities. The objective of the dynamic tests is to characterize the dynamics of the DFCC Hardware and the software to enable verification of the design assumptions used for CLAW design. These tests involve injecting sinusoidal excitation with and without biases from a Frequency Response Analyzer (FRA) at the sensor input and monitoring the CLAW commands to the actuator and the actual actuator ram positions. The tolerance bounds of these tests are defined in frequency domain i.e., in gain (dB) and Phase (rad/sec or degree). The objective of closed loop tests is to verify the time domain response of the overall system in closed loop operation with and without failures.

IV. Expected value generation tool for static tests Hardware elements in various paths of the static tests include Sensors (rate gyros and

accelerometers), Amplifiers / Signal conditioners, Linear / Rotary Variable Differential Transformers (L/RVDTs), Analog to Digital Converters (ADCs), Analog Filters, and Hydro-Mechanical elements of the actuator. The effects of the associated hardware characteristics such as offset, gain bias and gain tolerances appear in the outputs of the OFP software and this leads to a mismatch between the monitored values and the expected values generated without accounting for the hardware characteristics. Thus, it is necessary to know how close the monitored results are with expected values in terms of certain bounds, i.e. to define the Pass/Fail criteria for each test. Fig. 2 shows the block schematic of the EVTOOL software that is used to generate

expected results with tolerance bounds. EVTOOL incorporates hardware characteristics and model of the data-recording unit apart from the ADS and CLAW modules. The hardware characteristics for all paths are obtained by taking into account offset, gain bias and gain tolerances of the different hardware elements. In EVTOOL, tolerances are initially generated on the inputs to the software based on the hardware characteristics. Thus, any output signal from the tolerance bounds generation block has 3 values consisting of lower, nominal (input value) and upper bound. The discrete / flags are directly sent to the

FDS

Input / Output Rack and ETS

DFCC

(ADS & CLAW)

Act

uato

rs

Figure 1. Block schematic of Iron Bird.

4

ADS and CLAW computations. The processing on the input signals with three values is carried out in the ADS and CLAW blocks as shown in Fig. 2. The block schematic of the longitudinal axis controller is shown in Fig. 3. Processing of the signals with tolerance bounds in such a type of controller is a very complex task. The control laws (CLAW) involve longitudinal, lateral, directional, elevon signal consolidation, leading edge slat controllers, and the air data consolidation block. Thus, processing of the tolerance bounds through the CLAW for defining the proper pass/fail criteria is a challenging task. The ADS and CLAW modules in turn consists of various components such as filters, rate limiters, lookup tables, nonlinearities and events. Typical filters like Lag [1/(1+K2s)], Lead-lag [(1+K1s)/(1+K2s)] and washout [(K1s)/(1+K2s)] are extensively used in the ADS and CLAW. In static tests, our objective is to obtain the steady state value for the given set of inputs from the expected value generation tool. According to the final value theorem of the Laplace’s transform, the time (t) t → ∞ implies s → 0, where s is the Laplace’s operator. Therefore, the steady state gain is unity for lag and lead-lag filter and zero for washout filter. The unity gain of the filter at steady state indicates that, the input and output of the filter is same (i.e. short circuit) while zero gain of the filter at steady state indicates that, irrespective of any value of the input signal, the output signal of the filter has a zero value (open circuit). Thus, for filters and rate limiters we do not need to implement them as they can be by passed or cutoff by suitably instrumenting the expected value generation tool for static tests. Since static tests to be conducted are exhaustive, these features reduce the unnecessary computations associated with the filters and in turn the computational time. Nonlinearities and lookup tables result in equivalent gains in the signal path.

V. Computations with tolerance bounds

The processing of the nominal value and tolerance bounds associated with the other components in the CLAW module, i.e., nonlinearities, lookup tables, and events are now described. Consider two signals A = [aL, a0, aU] and B = [bL, b0, bU], where the subscript L, 0 and U denotes Lower, Nominal and Upper bound, respectively for the signals. Further, let Y = [yL, y0, yU] be the output signal with tolerance bounds obtained from the operations performed on the input signals A and B. The operation refers to addition, multiplication, computations such as nonlinearities, table lookup involving interpolation, etc. which is defined in the subsequent subsections. The computation of worst case tolerance assumes all the signals occur at their worst limit simultaneously. It is used by designers to ensure that all end-to-end signals will meet the specified limits. However, as the number of input signals increase, the tolerances must be appropriately reduced

δe

Control Logic and Nonlinearity

Pitch Stick Shaping & Limiting

Small Amplitude

Pre-Filter

Rate-Limiter

Auto-Pilot Limits as a function of Pitch Stick Command

Nz

q Anti-aliasing & Notch Filters

Phase advance and Dynamic Compensation

1g

Low-Pass Filter

Nz-alpha conversion

Desensitizer

Signal Conditioning Filter

Dynamic Compensation

Washout Filter ≅α.

Washout Filter ≅α.

≅α

Saturation and Rate-Limiter

Square Root Function and Limiting

U/C Status

Trim Correction

No-Windup Integrator

Pitch Trim

Feedback

Forward Path

≅α

≅α

Figure 3: Longitudinal Controller Block Schematic

Low-Pass Filter

Anti-aliasing & Notch Filters

Signal Conditioning Filter

Low-Pass Filter

Large Amplitude

Pre-Filter

Signals from Air Data System

5

in order to generate the realistic output limit. For this reason Root Sum Square (RSS) tolerance is computed wherein, the low probability of the worst-case combination occurring is taken into account statistically, assuming a Normal or Gaussian distribution for signal variations. This gives rise to realistic tolerance on the output results. Tolerances are commonly assumed to correspond to integral multiples of the standard deviations (±6σ or ±3σ). In the following subsections computation of both worst-case and RSS tolerance is discussed. A. Sum or difference of signals with tolerance bounds The worst case tolerance bound for sum (A + B) or difference (A – B) of signals can be obtained respectively as follows: Y = [yL, y0, yU] =[(aL + bL), (a0 + b0), (aU + bU)] (1a) Y = [yL, y0, yU] =[(aL - bU), (a0 - b0), (aU - bL)] (1b) The Root Sum Square (RSS) Y = [yL, y0, yU] = A + B for the two uncorrelated input signals A and B with tolerance bounds can be obtained as follows:

( ) ( )

( ) ( )

2 20 0 0

0 0 0

2 20 0 0

L L L

U U U

y y a a b b

y a b

y y a a b b

⎫= − − + − ⎪⎪= + ⎬⎪

= + − + − ⎪⎭

(2)

Similarly the Root Sum Square for difference of two signals (A - B) can be obtained by changing the sign of B and adding as described above in Eq. (2), i.e., [A + (-B)]. The nominal value for (-B) will -b0 and the lower and upper bound will be - bU and - bL, respectively. The worst-case sum or difference in Eq. (1) widens the tolerance bounds as compared to RSS in Eq. (2). The use of Eq. (1) or Eq. (2) is most of the time subjective. B. Multiplication or division of signals with tolerance bounds The resulting worst-case product or division Y with tolerance bounds of A and B can be obtained first performing Kronecker tensor product, respectively as defined in Eqs. (3a) and Eq. (3b). Z = A ⊗ B = [aLbL, aLb0, aLbU, a0bL, a0b0, a0bU, aUbL, aUb0, aUbU] (3a) Z = A ⊗ (1/B) = [aL/bL, aL/b0, aL/bU, a0/bL, a0/b0, a0/bU, aU/bL, aU/b0, aU/bU] (3b) Then, Y = [yL, y0, yU] = [min (Z), {a0b0 or a0/b0}, max (Z)]. This is absolute worst-case tolerance bound on the product or division of two signals. C. Product of the signal and gain with tolerance bounds

In Eqs. (3a) and (3b), the worst-case tolerance bound for the product of two signals is defined. However, for testing purposes, this worst-case tolerance bound will be too wide to detect the failure cases. Therefore, for the product of gain and signals, the low probability of the worst-case combination occurring is taken into account statistically, assuming a Normal or Gaussian distribution for signal and gain variations. Let us consider the gain G = [gL, g0, gU] and signal X = [xL, x0, xU]

with tolerance bounds. Gain could be one of the following:

i) Constant with tolerance bounds,

G X Y=X*G

Figure 4: Product of signal and gain

6

ii) static output of the two dimensional nonlinearity (or the value resulting from one-dimensional lookup table),

iii) static output of the two dimensional nonlinearity with varying slopes of it’s linear segments (or the value resulting from two-dimensional lookup table).

Then, the tolerance bounds and nominal value for the resulting signal Y due to the product of the signal and gain is Y = [yL, y0, yU] = X*G where,

D. One-dimensional linear interpolation with tolerance bounds Consider nonlinearity (gain) defined using lookup table with input-output grid points. The input and output grid points for the lookup table are defined by the vectors Xo and Yo, respectively. Consider X = [xL, x0, xU] and Y = [yL, y0, yU] with tolerance bounds to be the input and output signal (after performing linear interpolation) for the lookup table. If the input-output data is linear, lookup table can be expressed in the form of piecewise linear segment (i.e., y=mx+c form). The interpolated output for this nonlinearity is a gain for the specified input. In the present case, this gain is with tolerance bounds. Depending upon the ascending or descending order of the grid points (+ve or –ve slope), the lower and upper bounds of the output signal are interchanged with respect to the lower and upper bounds of the input signal as shown in Figs. 6 and 7, respectively.

E. Two-dimensional linear interpolation with tolerance bounds

Consider nonlinearity (gain) defined using two dimensional lookup table as shown in Fig. 8. It has two inputs. The grid points of the lookup table are defined using vectors A0 and B0. Let A = [aL, a0, aU] and B = [bL, b0, bU], are the input signals with tolerance bounds to the lookup table. The interpolated output Y = [yL, y0, yU] with tolerance bounds is computed as described below. Consider set C = {(aL, bL), (aL, b0), (aL, bU), (a0, bL), (a0, b0), (a0, bU), (aU, bL), (aU, b0), (aU, bU)} (4)

with all possible combinations of the lower, nominal and upper bounds of both the input signals for table lookup. Let, Z = {z1, z2, z3, z4, z5, z6, z7, z8, z9} is the set of the interpolated values obtained corresponding to each element of the set C. The interpolated output with tolerance bounds is Y = [yL,

Figure 6. Positive slope

xL, x0, xU

yU y0 yL

X0

Y0

xL, x0, xU

yU y0 yL

Y0

X0 Figure7. Negative slope

Xo Yo

X Y

Figure 5. One-dimensional Table lookup

Y

Figure 8. Two-dimensional Table lookup

A0 B0 A

B

yL=min {zL1,zL2,zU1,zU2} y0=x0g0 and yU=max {zL1,zL2,zU1,zU2}

( )( ) ( )( )

( )( ) ( )( )

( )( ) ( )( )

( )( ) ( )( )

2 21 0 0 0 0 0

2 22 0 0 0 0 0

2 21 0 0 0 0 0

2 22 0 0 0 0 0

L L L

L L L

U U U

U U U

z y x g g g x x

z y x g g g x x

z y x g g g x x

z y x g g g x x

⎫= + ⋅ − + ⋅ − ⎪⎪

= − ⋅ − + ⋅ − ⎪⎪⎬⎪= + ⋅ − + ⋅ −⎪⎪

= − ⋅ − + ⋅ − ⎪⎭

7

y0, yU] =[min (Z), z5, max (Z)]. Note that the nominal output (y0) corresponds to the nominal values of inputs (a0, b0). F. Nonlinearity viewed as two-dimensional lookup table Fig. 9 shows the variable saturation limits nonlinearity, i.e. saturation limit is the signal with

tolerance bounds. The input signal to the nonlinearity is A = [aL, a0, aU] and the signal indicating the variation in saturation limit is B = [bL, b0, bU]. It is obvious from Fig. 9 that tolerance bounds for signal B are interchanged as the straight line passes from 3rd quadrant to the first quadrant which is similar to the two-dimensional lookup table. The first grid point vector A0 is considered along the X-axis and the second grid point vector B0 (also output signal Y) are considered along the Y-axis. In fact, output Y is the third dimension of the nonlinearity. In order to simplify the understanding through an illustration in the two-dimensional plane, B0 and Y are considered along the same axis. The set of the interpolated values obtained corresponding to each element of the set C is given by Eq.(4) and shown in Fig. 9. The interpolated output with tolerance bounds is Y = [yL, y0, yU] = [min(Z), z5, max (Z)]. Note the nominal output (y0) corresponds

to the nominal inputs (a0, b0). G. Variation in tolerance bounds due to nonlinearity The output tolerance bounds changes depending upon the nonlinearity for an input with tolerance bounds, as follows:

Figure 10. Uneven tolerance bound on the output signal due to nonlinearity.

(a) Smooth Nonlinear Curve

X=[xL, x0, xU]

yU y0 yL

X0

Y0

(b) Piecewise Linear (S1 < S2)

yU y0 yL

Y0

X0X=[xL, x0, xU]

Slope= S1

Slope=S2

X0

(d) –ve Saturation Limit (S1 < S2)

Y0

Slope=S2

Slope= S1

X=[xL, x0, xU]

yU yL, y0

Slope= S1

(c) +ve Saturation Limit (S1 > S2)

X=[xL, x0, xU] X0

Y0

y0, yU yL

Slope=S2

Slope = S1

Slope = S2

Slope = S3

A0

Y or B0

A = [aL, a0, aU]

Y

Z

z1 z2 z3 z4 z5 z6 z7 z8 z9

z9 = yLz5= y0

z1 = yU

Figure 9. Variable Saturation Limits

B

bU

bL

b0

8

1. Lower and upper bounds simultaneously are widened or narrowed. 2. Only lower bound is narrowed while upper bound is widened and vice versa.

The first case occurs depending upon the slope of the linear segment on which the input signal operates. The tolerance bounds for output do not change if the slope of the linear segment is unity. If the slope of the linear segment is less than or greater than one, then the output tolerance bounds are narrowed or widened, respectively. The second case occurs when either one of the following phenomena happens:

1. If the segment of the nonlinearity on which the input signal is operating is not linear, i.e., it is a smooth nonlinear curve as shown Fig. 10 (a).

2. If the input signal is operating at a point on the piecewise nonlinearity where, the two linear segments with different slopes are connected as shown in Fig. 10 (b).

3. In saturation nonlinearity, if the input signal is operating around the saturation point. Depending upon the quadrant of the nonlinearity, the tolerance on one side is zero and on the other side, it is nonzero as shown Fig. 10 (c) &(d).

H. Tolerance bound computations for non-monotonic nonlinearity Fig. 11 shows two linear segments of the piecewise nonlinearity having slopes with opposite signs (non-monotonic part) and spanned over the tolerance bounds. In this case, the monitored output of the nonlinearity falls out of the output tolerance bounds, even though the monitored input to the nonlinearity is within the tolerance bounds. Fig. 11 (a) shows the convex nonlinearity, where the output signal has tolerance bounds Y = [yL, y0, yA]. The upper bound is yA (not yU), which corresponds to the apex point of the nonlinearity. Similarly, Fig. 11 (b) shows the concave nonlinearity, where the output signal has tolerance bounds Y = [yA, y0, yU]. The lower bound is yA (not yL), which corresponds to the apex point of the nonlinearity. Thus, in both these cases algorithm involves a step to find the maximum or minimum output (apex point) of the nonlinearity for the non-monotonic portion. However, note that the correspondence between nominal input and nominal output is always retained.

I. Tolerance bounds at the extreme (out of) range of the input signals The failure of Ariane-501 was caused by the complete loss of guidance and attitude information 37 seconds after start of the main engine ignition sequence8. This loss of information was due to specification and design errors in the software of the Inertial Reference System (SRI). The SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This out of range value resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected. In case of LCA, based on the previous experience and engineering judgment, the tolerance bounds are widened by 10% of the extreme value for the input signals at the limit values. Consider a signal x

y0 yU yL

X

Y (output)

xL Monitored input

x0 xU

Tolerance (output)

Monitored output

(a) Convex Nonlinearity

Apex input

Apex output

xAxM

yA yM

yUyL y0

X

Y (output)

(b) Concave Nonlinearity

xU x0 xA

Apex input Monitored input

xMxL

yAApex output

yM Monitored output

Tolerance (output)

Figure 11. Non-monotonic Nonlinearity

9

with operating range from xmin to xmax. The tolerance bounds are defined by X = [xL, x0, xU]. If the nominal value is at it’s minimum of the operating range, i.e., x0 = xmin, then the set of the tolerance bounds on x0 is defined by X = [xL, x0, xU], where xL = (xmin – 0.1* xmin) x0 = x0 = xmin xU = upper bound as defined on the signal, i.e., xU (5) Similarly, if the nominal input value is at it’s maximum of the operating range, i.e., x0 = xmax, then the set of tolerance bound on x0 is defined by X = [xL, x0, xU], where xL = lower bound as defined on the signal, i.e., xL x0 = x0 = xmax xU = (xmax + 0.1* xmax) (6) Example: Consider that pitch rate as input signal X = [xL, x0, xU], in degree/sec. The operating range for

pitch rate sensor is [xmin, xmax]=[-60,60] deg/sec. If the nominal pitch rate (x0) value is at minimum (-60 deg/sec) and if the tolerance bounds are [-62.4 –60 -57.5] (deg/sec), then the modified tolerance bounds from Eq. (5) will be [–66 -60 -57.5] (deg/sec). Similarly, if the nominal pitch rate value is at maximum (60 deg/sec) and has the tolerance bounds as [57.5 60 62.4] deg/sec, then the modified tolerance bounds from Eq. (6) will be [57.5 60 66] deg/sec.

J. Event (Flag or discrete) declaration All events are declared based on the nominal values of the input signal only. Here the input signal

triggers the event, i.e., either true or false. Thus, even though the, the input signal to the event, i.e., X = [xL, x0, xU], has nonzero tolerance bounds, the output signal of the event, i.e., Y = [yL, y0, yU] will have zero tolerance bounds (lower and upper bounds will be same as that of the nominal value). It is to be noted that the output signal Y = [yL, y0, yU] is a discrete signal.

Let us consider the example that will operate in two stages on two different events, which are linked to each other. Consider the input signal X = [xL, x0, xU], is the speed in Kilometers per hour (Kmph) to the event1 denoted as EV01. Operation of the EV01 is as follows:

(i) If speed is less than 70 Kmph then the EV01 is set TRUE, i.e., y0 = 1 and (ii) If speed is greater than 70 Kmph then the EV01 is set FALSE, i.e. y0 = 0.

Next, the operation of the event2 (EV02) is defined as follows:

(i) If the EV01 is true, then set the angle of attack (AoA) to default value, i.e., z0 = 13 degree, (Z = [zL, z0, zU] is the output signal of the EV02) and

(ii) If the EV01 is false, then start computing the angle of attack as per the defined algorithm

Consider the input signal X = [xL, x0, xU] =[67,69.5,71.3] Kmph. If the EV01 is declared based on the individual values (tolerance bounds and nominal value) of the input signal, then we will have the output signal Y = [yL, y0, yU] =[1,1,0]. Z = angle of attack is the output of EV02 which is an analog signal with tolerance bounds. Now, if we define the output of the EV02 based on the individual values of it’s input signal Y = [yL, y0, yU] =[1,1,0], then we will have the output signal i.e., AoA = Z = [zL, z0, zU] = [13, 13, 4] degree. Since yU = 0, as per the second part of the operation of the EV02, we have zU , the computed value of the AoA as per the algorithm.

Event X = [xL, x0, xU] Y = [yL, y0, yU]

Figure 12. Event declaration

EV01 X = [xL, x0, xU] Y = [yL, y0, yU]

EV02Z = [zL, z0, zU] = AoA

Figure 13. Cascaded event declaration.

10

Consider another set of input to the EV01, X = [xL, x0, xU] =[69.5,71.3,73] Kmph. As per the earlier discussion, we will have Y = [yL, y0, yU] =[1,0,0] and Z = [zL, z0, zU] = [13,4,5.2] degree. z0 = 4 and zU = 5.2 are the values computed from the algorithm. Now, if we declare event based on the nominal value, then in case of the first set of input X = [xL, x0, xU] =[67,69.5,71.3] Kmph, we will have Y = [yL, y0, yU] =[1,1,1] and Z = [zL, z0, zU] = [13, 13, 13] degree. In the case of second set of input X = [xL, x0, xU] =[69.5,71.3,73] Kmph, we will have Y = [yL, y0, yU] =[0,0,0] and Z = [zL, z0, zU] = [2.9, 4, 5.2] degree the values computed by the algorithm. It can be seen that, if the events are declared on the individual values, then due to the first set of inputs, we find that the output of the EV02 has zero tolerance on the lower side while, it is of 9 degrees on the upper side. Similarly, in the second set of inputs, the output of the EV02 has very high tolerance on the lower side while it is low on the upper side. All this happens because the computed values correspond to different status of the event settings. If the events are declared based only on the nominal value of the input signal then we have consistency in the tolerance bounds obtained on the angle of attack for both the set of inputs.

VI. Additional remarks on tolerance computations Repeated root sum square operations on the tolerance bound computations should be avoided as this will narrow down the tolerance bound too much. Figure 14 illustrates the process of eliminating the repeated RSS operation on signals X1 and X2. The gains K1 = [k1L, k10, k1U], K2 = [k2L, k20, k2U] and K3 = [k3L, k30, k3U] are with tolerance bounds. Fig. 14 (a) depicts computation of output Y = [yL, y0, yU] by performing a repeated RSS operation on the input signals X1 = [x1L, x10, x1U] and X2 = [x2L, x20, x2U]. This repeated RSS is avoided by moving the summation point of the signals X1 and X2 as shown in Fig. 14 (b) to the point just before computing the final output, where all four signals are root sum squared only once. This has been done at the cost of increasing the multiplication operation with the gain K1. If gains K1, K2, and K3 are without tolerance bounds, then both schemes in Figs. 14 (a) and (b) are same. Example: Consider the sets of signals and gains with tolerance bounds (Figure 14):

Then the final outputs computed using both the schemes as shown in Fig. 14 are: Y = [ 26.644, 28.68, 30.716 ] with first scheme in Fig. 14 (a) [ 26.6437, 28.68, 30.7163] with second scheme in Fig. 14 (b)

X1 X2

X3

X4

X12 X12K1

X3K2

X4K3

Y

(a)

Figure 14. (a) Repeated root sum square operation is done on signals X1 and X2, (b) repeated root sum square operation on signals X1 and X2 is eliminated

X1

X2

X3

X4

X2K1

X3K2

X4K3

Y

X1K1

(b)

K1

K2

K3

K1

K1

K2

K3

Gains K1 = [0.2285, 0.2300, 0.2312] K2 = [0.6200, 0.7000, 0.7500] K3 = [0.1000, 0.1100, 0.1300]

Signals X1 = [9.8000, 10.0000, 10.3000] X2 = [29.7000, 30.0000, 30.2000] X3 = [24.9000, 25.0000, 25.2000] X4 = [17.8500, 18.0000, 18.2000]

11

Elimination of RSS widens the tolerance bounds. The nominal output value is always unaffected while doing the processing on tolerance bounds.

VII. Conclusions The computations and processing of the tolerance bounds is an algorithmic development and it is extremely important to justify the pass/fail criteria for the tests conducted on software and hardware at various ground rigs. The tolerance bounds also help in ensuring that the functionality of the module is retained if the inputs within tolerance bounds generate outputs within the tolerance bounds. Designer’s involvement in understanding the test setup is very important, as it is necessary to model the various elements in the expected value generation tool and to define the various test points (which are possible to measure in the ground rig) in the module to be tested. The TEJAS ADS and CLAW were tested at the Iron bird rig with the expected values and tolerance bounds generated using the procedure described in this paper. This concept of tolerance bounds definition has also been extended for tests conducted in hangar on TEJAS. This process and extensive testing of the ADS and CLAW has helped in successful flights of LCA without encountering any major defects in the safety critical fly-by-wire software.

Acknowledgments The authors are grateful to Director, ADA) and Director, NAL for permitting this work to be published and are also thankful to the Project Director (IFCS) for his constant encouragement. Thanks are also due to the test team members at the Iron Bird for providing the necessary data and cooperation in all test related activities.

References

1Roger W Pratt, Flight Control Systems, Progress in Astronautics and Aeronautics, Vol. 184, AIAA and IEE, 2000

2Nancy G Leveson, "The Role of Software in Spacecraft Accidents", AIAA Journal of Spacecrafts and

Rockets, Vol 41, No 4, pp 564-575, July 2004. 3Shyam Chetty, Girish Deodhare, B.B. Misra: "Design, Development and Flight Testing of Control Laws for

the Indian Light Combat Aircraft", AIAA Guidance, Navigation and Control Conference, Monterey, CA, August 2002

4Steven R. Rakitin, Software Verification and Validation - A Practitioner's Guide, Artech House, Norwood

MA, 1997 5Y.V. Jeppu, K Karunakar and P.S. Subramanyam, "Testing Safety Critical Ada Code Using Non Real Time

Testing", Reliable Software Technologies ADA-Europe 2003, edited by Jean-Pierre Rosen and A Strohmeier, Lecture Notes in Computer Science, 2655, pp 382-393.

6D. Sitarama Raju, Girish Dixit, P.S. Subramanyam, and B. Subba Reddy, “LCA integrated flight control

system evaluation on iron bird,” Workshop on Control Systems for Defence Applications (CONSYS-2002), pp. 61-65, February 2002, held at RCI, Hyderabad, India.

7T. Smith, “Ground and flight testing of digital fight control systems – chapter 6” of “Flight Control Systems”

edited by Roger W. Pratt, Volume 184, Progress in astronautics and aeronautics, AIAA, 2000. 8ARIANE 5, Flight 501 Failure, Report by the Inquiry Board, from the website:

http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html, paris, 19th July 1996.