research article fdir for the imu component of aocs...

Research ArticleFDIR for the IMU Component of AOCS Systems

Maurício N. Pontuschka1 and Ijar M. da Fonseca2

1 Department of Computer Science, PUC-SP, 01303-050 Sao Paulo, SP, Brazil2 Aeronautical Mechanics Division, Department of Mechatronics ITA and DMC/INPE, 12244-456 Sao Jose dos Campos, SP, Brazil

Correspondence should be addressed to Maurıcio N. Pontuschka; [email protected]

Received 16 May 2014; Accepted 11 July 2014; Published 1 September 2014

Academic Editor: Antonio F. Bertachini A. Prado

Copyright © 2014 M. N. Pontuschka and I. M. da Fonseca. This is an open access article distributed under the Creative CommonsAttribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work isproperly cited.

The main objective of this paper is the study of a FDIR for an IMU aiming at space applications with focus on the gyro signalanalysis and the tests of the filtering algorithms. The algorithms have been tested by using lab data provided by the DMC LABSIM(Physical’s Simulation Laboratory of the Space Mechanics and Control Division of INPE). The results have demonstrated goodagreement with the concepts applied in this study. Automatic detection procedures are very important in the characterization ofoccurrence, definition of criteria, and device types in the scenario of AOCS FDIR. An IMU comprised of four gyros in a tetrahedralconfiguration is one of the assumed components for the AOCS (attitude and orbit control subsystem) considered in this work.Thetypes of failures considered in this paper are the step abrupt change, ramp/drift/slow, stuck, cyclic, erratic, spike, and finally the stuckfor variance alteration noise. An appropriate algorithm for the automatic detection of each type of fault is developed.The approachincludes the mapping capability of fault event indicators to the IMU.This mapping is very important in the characterization of theoccurrence, definition of criteria, and device types as well as associated fault identification for an AOCS.

1. Introduction

The FDIR acronym refers to three main functions related tosoftware (SW) and hardware (HW): fault detection, referringto the ability to discover faults or the process of determiningthat a fault has occurred; fault isolation being the function offault localization within the system by providing informationpinpointing it; fault recovery referring to the process oflimiting the fault propagation and enabling the service to berestored to an acceptable state.

FDIR belongs to a wide area called fault-tolerant con-trol systems (FTCS). In other words, FTCS refers to thecontrol systems with capability to accommodate componentfailures automatically. Such systems are capable of maintain-ing overall system stability and performance in the eventof failures. The FDIR enters in this process by detecting,isolating, and recovering the system being monitored in theevent of fault occurrence [1, 2]. In the FTCS scenario, aclosed-loop control system, which can tolerate component

malfunctions while maintaining desirable performance andstability properties, is said to be a fault-tolerant controlsystem. Despite the many individual research in this area,systematic concepts, design methods, and even terminologyare still not completely standardized for the specific areawhere FDIR and related literature appear [3]. As the subject ismultidisciplinary considering the complete life cycle of FDIRsystems, some standard terminologies come from softwareand hardware specification and development as well as fromquality assurance.

The fundamental requirement for planning current spacemissions is autonomy. The autonomy aims the satellite’sarchitecture improvement and special attention to the FDIRto be implemented in space. Automatic actions have beenincluded in space missions since the beginning of the spaceconquer. Nowadays automatism plus autonomy representthe state of the art of space missions requiring spacecraftwith the capability to operate as intelligent robots. In suchscenario the FDIR appear as one of the most important

Hindawi Publishing CorporationMathematical Problems in EngineeringVolume 2014, Article ID 302716, 9 pageshttp://dx.doi.org/10.1155/2014/302716

2 Mathematical Problems in Engineering

subsystems for the safety assurance of space missions. Theimportance of such subsystems is enhanced with the follow-ing statement regarding FDIR “It is a cornerstone for thesatellite’s autonomy enhancement” [4]. This means that theFDIR subsystem design, test, and implementation are seenas imperative to guarantee a dependable and autonomoussystem with a minimal risk of harmful failures. FDIR systemsaim to provide three important functions: (i) monitoring,where the responses of the system are checked with respectto tolerances and generates alarms to the operator; (ii)automatic protection, where the FDIR automatically initiatesan appropriate counteraction when a dangerous process stateis detected; (iii) supervision, where the fault diagnosis isperformed and contingency actions are taken [5]. As a safety-critical subsystem FDIR development must follow stringentstandards from conception to implementation. The objectiveis risk reduction, in addition to robustness, performance,and reactive detection, isolation, and recovery from failures.According to the ECSS standard [6], dependability is termi-nology used to describe the availability performance and itsinfluencing factors: reliability performance, maintainabilityperformance, and maintenance support performance. Whenworking with safety-critical subsystems as it is the caseof FDIR it is important to take the clear meaning of theterminology, as defined in the standards. The definition andintegration of FDIR technologies in the on-board softwarelifecycle is considered mandatory by different satellites man-ufacturers.

Regarding the on-board software (OBSW) FDIR someconventional FDIR techniques (for example, SW watchdogs,memory scrubbing, parameter monitoring, among others)are typically present in most satellites. More sophisticatedsoftware FDIR techniques have recently been developed. Oneexample is the model-based FDIR with artificial intelligence(AI) support also called smart-FDIR, in addition, advancedFDIR AFDIR) techniques have been made available asreusable components. The FDIR includes the Kalman filter-ing, weighted sum-squared residual testing, and generalizedlikelihood testing.

Considering the currently available software FDIR tech-niques and the actually implemented FDIR schemes indifferent satellites, there exist a gap between the usage of thesetechnologies and their early incorporation into the satellite’sdesign phase. Designers’ trend is toward incorporation ofa generic FDIR architecture into the whole design. Thisarchitecture must be easy to maintain, extend, and adapt.Theabove mentioned gap is characterized by the lack of an earlyincorporable, reusable high-level, flexible, and maintainableFDIR generic architecture to be used customized accordingto the designers’ need. The major satellite manufacturers aresupporting the development of more generic software archi-tectures aiming cost-cutting and further market competen-cies. FDIR is generally taken into consideration, only whenall the equipment designs and specifications are available.It is believed that many recurring on-board problems andfailures can be avoided if a solution is found for the problemof late FDIRdefinition and incorporation.Missions that facedproblems, such as theMars climate orbiter, Ariane 5, Titan IV-B, Mars polar lander, and deep space 2, motivate deep studies

on how to avoid failures which may have shared the samecause in different missions. The relative expensive cost couldbe reduced if generic, maintainable, and extendable FDIRdesigns are available for reuse by different space projectsdesigners.

In general, any complete FDIR arrangement must bedistributed on both HW and software SW levels in any on-board computer architecture. The FDIR concept at the HWlevel can be seen for instance in a processorwatchdog timer orin an individual watchdog that receives beacon signals fromdifferent units. The memory error detection and correction(EDAC) function is also present on theHW level as a classicalFDIR component. The HW level is referred to as HW FDIRand at SW level as SW FDIR. Considering FDIR analysis anddesign the following approach can be used [7].

(i) Define failure scenarios, detection strategies and lev-els of autonomy.

(ii) Partition FDIR functions into on-board hardware andsoftware or TM/TC actions.

(iii) Define FDIR architecture as centralized (single node),distributed FDIR (multiple nodes with majority vot-ing) or a combination of both.

(iv) Create a FDIR analysis tool in UML to derive theFDIR actions.

(v) Create a FDIR model of the system incorporating theFDIR algorithm using UML.

(vi) Evaluate and optimize the system architecture perfor-mance when exposed to different failure scenarios.

(vii) Demonstrate the FDIR algorithm running appro-priate computer simulations. The MARC (modulararchitecture for robust computation) demonstratorhandling failures is an option for demonstration.

(viii) Assess the performance and reliability by using appro-priate communication protocol (MIL-STD-1553B forexample) to handle critical commands/telemetry.

FDIR must be part of many spacecraft subsystems forsafety reasons. AOCS is one of those space vehicles safety-critical subsystems once it failures may lead to mission loss.This paper represents an initial study in the scenario of theBrazilian Amazonia-1 satellite AOCS. The AOCS diagramis shown in Figure 1. The Amazonia-1 AOCS software com-prises the FDIR module that allows performing detection,isolation, and recovery consistent with predefined failures.The FDIR is a dynamic table in which predetermined set offailures are programmed. The Amazonia-1 AOCS includesa tetrahedral IMU (inertial measurement unity) comprisingfour gyros as shown in Figure 1. That IMU is the object ofthe paper for the sake algorithm development aiming thedetection and isolation regarding failures. In this sense thisstudy may apply to any AOCS subsystems comprising IMUs.

The data for simulations and validation of the algorithmdeveloped in this work was obtained from the DMC’sLABSIM (Space Mechanics and Control Division’s SIMula-tion LABoratory–Laboratorio de Simulacao da Divisao deMecanica Espacial e Controle), at INPE (National Institutefor Space Research).

Mathematical Problems in Engineering 3

MW × 4

MTC 3 × 2

Propulsionsubsystem

(hydrazine tank4 + 2 redundant

Thr. 2 LV)

CSS × 8

TAM (3 + 1redundant)

IMU gyros (3 nominal + 1 cold redundant) 1553

interface

Star sensors × 2(1 redundant)1553 interface

AOCS EGSE (electronic

ground supportequipment)

OBDH GPS 1 s IntHandl

OBDH subsystem

(1553 interface)

Coil current

Velocity, rotationdirection

temperature,voltage, torque

current

Torque comm voltage, torque

direction

AOCS SW

On/offpolarity

command

Press, temp, LVstatus, TCE box

currentconsumption

Valve commandand cathalystic

bed heaters

Proportionalcurrent (to the

sun angle)

Threecomponents ofthe magnetic

field

Three-axisangularvelocity

Attitudedata

Sensors andactuators

simulationdata

State and RW,MTC, THRcontr comm

Pulse pps

Telecommand,GPS data

HK data,prescribed solarpanel positionand velocity

Figure 1: Amazonia-1 AOCS enhancing the IMU inside a dashed cycle.

The types of failures considered in this paper are thestep abrupt change, ramp/drift/slow, stuck, cyclic, erratic,spike, and finally the stuck for variance alteration noise. Anappropriate algorithm for the automatic detection of eachtype of fault being analyzed is developed. As a result of thisapproach a mapping of events fault indicators to the IMU isobtained.

2. Discussion on FDIR

This study focuses on the FDIR occurring in inertial units.Those inertial units were originally applied in control ofcritical system operations in military combat aircrafts andspacecrafts [8, 9]. Project of these categories include theability to operate in dynamic environment demanding hugecomputational effort to maintain acceptable levels of stabilityand operability. The stability during the flight requires theuse of inertial sensors to provide output acceleration, rate,and angular position.The purpose of those control devices isto establish reliability, performance, and integrity to providethe lowest error rates aiming at the mission success. Inertialunitsmay be constructed as arrays of strap down sensors withdifferent degrees of freedom. Each sensor provides electricsignals that may contain errors from different natures. Thereare algorithms to compute various types of these knownerrors for fault identification [10]. As scope of this work

we selected the following error types: step abrupt change,ramp/drift/slow, stuck, cyclic, erratic, spike, and stuck forvariance alteration noise.

In most cases the algorithms that were created to identifythe errors are based in signal analysis acting as filters thatraster the signal searching specific patterns [11] that indicatesthe presence of known errors. In these cases the computa-tional construction presents a loop in its main structure toread each byte of an input sequence. The problem is how tomake several analyses simultaneously by a single processorunit. These algorithms have to be combined in a way that thesystem could achieve the best level of performance.

The strategy is this paper is to use a single loop structureand a set of buffers to provide all the analyses in a sequenceinside the loop.The sensor provides the raw signal to the DIFthat initiates the analysis. The first buffer reads the first byteof the raw signal to make it available for the next level ofanalysis. In this level the first filter will uses the informationcontained in the first buffer. Each filter requires a differentquantity of information necessary to begin the analysis. If theinformation is not sufficient to initiate the analysis, the flowof execution is sent to the next loop where a new value isread from the sensor. On the other side, if the informationis sufficient the first filter process provides a new signal to thenext buffer. The next buffer is processed by the next filter inthe same way of the first one. So we can provide in the same


loop all the filter combination necessary to achieve betterperformance in the analysis of the complete set of filters.

When identifying if one of the known errors has occurredwe have to ensure that all of filters have applied the signalmodifications of each buffer in order to process the algorithm,guaranteeing the simultaneous analysis. In the case of iden-tification of any used patterns in the analysis, an exceptionsignal has to be emitted in order to alert that the referredpattern has been identified. It is difficult in this time to saythat this identified pattern is really about a real error, butthe finding is fundamental information about on how thesystem is working and if system behavior is as was expected.Pattern identified, the next step is to send the information to ahigher layer of analysis which uses artificial intelligence, statediagrams or even a set of rules focusing on the interpretationof the context that the systems is inserted and if the findingreally indicates an error condition.

This means that the lower layer is responsible for pro-viding good quality information to the interpretation layer(Figure 6). This time the analysis does not use a signalprocessing base anymore (as used in the previous layer). Adata structure is built from the signal processing analysis. Atthis point the structure includes the necessary information toidentify actions to be taken.

The most critical system environment usually restrictsthe available computational resources. In attention to thisit is recommended to design adaptive systems that canuse efficiently the available resources and still guarantee deprocess efficiency. When we use a set of layers to implementthe analysis, we are using all possible patternmatches that canbe found in first place, but when a patternmatch happens, theeffort is to check if it is in fact an error or not. In this casesome of the checking can be disabled to make possible thenew verification. Some level of checking has to bemaintainedto guarantee that the main systems are still working, butthe most important task in this situations is to decide if theanalysis will mark the pattern matching as an error or not.This choice can decide the system’s mission success.

In practice it is almost impossible to predict all kind oferrors, but it is certainly possible to find a set of errors. It isrecommended to incorporate all those known errors in theFDIR system. In this paper the complete set of those errorsand how to identify, isolate, and recover from each one areused to increase a knowledge base. This base is updated eachtime new information is discovered in the computing errorprocess. It is not a purpose of this work to discuss abouthow that information is updated on orbit operating satellites.However, new satellites could carry error information of pastmissions in their FDIR and include a safer procedure toachieve the mission success.

3. Approach to Develop the FDIR Software

The FDIR software has to be built after the components ofthe satellite are defined. This is necessary because the FDIRanalysis has to explore all possible known errors that may beassociated with the component arrangements. Accordinglythe architecture and components used on FDIR software have

pkg

InputProcess

Output

Buffer Filter

Figure 2: UML schematic model to the signal process.

taken into account the hardware system arrangement. Thisstudy proposes an approach to build a unique software archi-tecture that could encompass different FDIR applications.Such architecture can lead to reuse of code of already testedsoftware components. Further, the code reuse may resultin better reliability, performance, accuracy, cost reduction,and quality improvement in future software developments,instead of building all the software from scratch in eachnew project. A software component that is already used inseveral other missions with good performance and accuracycertainly provides the same quality levels and benefits infurther projects.

The main software component of the signal processingphase (Figure 5) combines the several signals analyzes in asingle loop that can be configured according to the projectneeds. It was developed a framework for FDIR that accom-modates different filter analyzes and an appropriate algorithmfor a future automatic detection of each type of fault beinganalyzed.

Most signal analysis is implemented in a loop that readsa sequence of bytes organized in an array [12]. In this papersuch array is the digital signal that is read from an IMUcomponent [10]. The main architecture is responsible forreceiving that signal and maintaining a main loop to processall filter algorithms. Each algorithm has to have a specificbuffer to receive the signal from the previous algorithm soas it obtains the information necessary to make its analysis.The result of the analysis will be stored at the buffer of thenext algorithm. At this point we can think of each algorithmas a process linked to two buffers, the one comprising theused data and the other storing the results. This approachis presented using UML 2.2 notation with class diagrams forthe conceptualmodel [13].TheUMLmeans unifiedmodelinglanguage and appears in the avionics literature as base forother modeling approaches, such as the category DSML(domain-specific modeling language) to model simulationtesting systems of avionic software [14].

Figure 2 shows the scheme of a general model process forthe signal. Figure 3 shows that each process has its own bufferand filter. Figure 3 also shows that the output of a filter isconnected to the next filter input. Each buffer is independent


sd figure 3

: Input : Output

: Input : Output

2: read()

1: store()

Nextprocess

Previousprocess

: Process

: Buffer : Filter

: Process

: Buffer : Filter

Figure 3: UML schematic model of the processes integration.

pkg

Outside input

Multiple filter analysis

Outside output

Sequence order Executer

Figure 4: Multiple filter analysis main architecture.

AOCS FDIR

FDIR execution

Sensors

Actuators

Sensors

Real

envi

ronm

ent

Shared sensors

Faultrecovery

commands

AOCS execution

Figure 5: Integration between AOCS and FDIR modules.

for each process; the data stored in a buffer has to be used onlyby the associated process. The software has to be constructedin a structured paradigm even when using the same orientedobject like diagram for modeling purpose; Figure 3 presentsin fact the integration of various unit processes.

Figure 4 shows that the main loop has to generate anoutside signal input, a main loop, a connection to the outsideoutput, and also a form to establish the correct order ofthe process executions. This model executes a single step of

analysis in each process filter.The reading loop is not inside ofthe filter algorithm but outside as themain loop that is sharedby all processes.

In Figure 4 the executer reads the next process identifica-tion from sequence order, sends the next word of informationto the process buffer, and executes the respective filter step. Ifthe filter succeeds in processing the information the executertakes the next process from the sequence order. If thefilter fails in processing the information, one more word ofinformation is read from the outside input and sent to thesame process until it returns a success signal. Some internalloop analysis has to consider a specific size of informationto be able to process the signal, so that each process actsso as to provide sufficient information to the next level ofanalysis. Each process that is executed will store the resultsin the next buffer process and check it for success or failure.The workflow returns to the main loop to provide moreinformation to feed the system if a failure is detected.

4. FDIR Analysis Approach

Up to this point we have presented the procedure to obtain aclear signal in the sense that all the set of signal processingto be used is applied. We have to be sure that a correctset of filters and associated correct order are implementedin each specific context the used system. The procedurementioned above provides different groups and sequence offilters to allow more flexible analysis for different subjects.The procedure that has been presented up to now can handleseveral filters in a configurable sequence of execution with aminimal delay. The next step of this strategy is to start thepattern matching for the identification of the signal meaning.In this phase the system should start the analysis by asking apatternmatching from a set of historical data of known errorsfrom each applied context to the executed system. The mainpurpose of this phase is to build a model that could representwhat is beingmonitored and thenmake and compare the datawith those that were expected for that point of the mission.Each kind of mission could have some different approachmodeling the behavior and structure.


Fault detectionmethods

Detection withsingle signals

Detection with multiplesignals and models

Limitchecking

Trendchecking

Signal-modelbased

Process-model based

Multivariatedata analysis

Fixe

d th

resh

olds

Adap

tive

thre

shol

ds

Chan

ge d

etec

tion

met

hods

Cor

rela

tion

Spec

trum

anal

ysis

Wav

elet a

naly

sis

Para

met

er es

timat

ion

Neu

ral n

etw

orks

Stat

e obs

erve

rs

Stat

e esti

mat

ors

Parit

y eq

uatio

ns

Prin

cipa

l com

pone

nt an

alys

is

Figure 6: Overview of different fault detection methods [16].

To accomplish a valid comparison it was built and assem-bled some integration component to generate a consistentcomparable system compatible with the historical data. It isnecessary a good model to represent the historical data andalso an approach to represent the behavior and the structureof the system under study in the paper. The first step is toprovide an integration model to hide all specific elementsfrom the main architecture. In that direction, the systemhas been partitioned in two parts, one that is independentand another that is highly dependent with respect to thecontext.The dependent part is built by observing the system’sspecific hardware (sensors and actuators). The independentpart takes into account all of the system’s common featuresand, consistently, cover all the system’s particularities. Forthe analysis presented in this paper, some known patterndesigns were studied to see how they could help to make thatindependent part of a FDIR. The adopted patterns for thiswork are classified into the categories [11] as shown in Table 1.

Table 1 enhances the different categories of design pat-terns.The FDIR solution uses this sort of patterns to organizethe information about the observed system and to build thedata structure and the desired comparison.

It is developed an approach to interpret the signaland convert it into high-level information representing aninformation model. The model is consistent with the abovepatterns.Themodel involves a set of attributes that representsthe system status and also a more complex structure data ascan be seen in the structure’s patterns. The model is changedaccording the signal readings. Some events are established to

start the comparison routines. The period could be differentin different type of analyses. When referring to the historicaldata, the reference is a set of routines that have to be startedas the system finds a match.The set of routines represents theknowledge base and must contain the routines for all knownerrors that were related to the context in which the systemruns. If a new error is found in one type of the equipment,even if the mission of the equipment fails, it can be used tobuild a new routine and be communicated to all other FDIRequivalent systems to prevent that the error occurs again.Theobjective of these routines is to seek for a possible occurrenceof a problem. The objective of those routines is to seek for apossible occurrence of a problem, each routine for each typeof problem. Each routine has to be built as an independentcomponent and having its own structure and behavior.Whenthe system is set with these considerations it is possible to plugsome contingency routines with the leaves of the decisiontree.

In Figure 5, the shared sensors provide signal read fromthe real environment and the FDIR sensors provide the signalread from the AOCS actuators and sensors. The focus is onthe FDIR execution module which contains some importantmodules to support the FDIR tasks. The FDIR must firstdetect and diagnose a fault before reacting to it [15].

There are several methods for approaching the FDIRsystem for spacecrafts. The choice of each method dependsof the space mission requirements.

Figure 6 illustrates several fault detection methods indifferent levels in the following categories: limit checking,


Table 1: Patterns category and description.

CategoryBehavior pattern DescriptionCommand pattern Command objects encapsulate an action and its parameters.Weak reference pattern Decouples an observer from an observable class.Protocol stack Communications are handled by multiple layers, which form an encapsulation hierarchy.State pattern A clean way for an object to partially change its type at runtime.Strategy pattern Algorithms can be selected on flying.Creational pattern DescriptionAdapter pattern “Adapts” one interface for a class into one that a client expects.

Bridge pattern Decouples an abstraction from its implementation so that the two can varyindependently.

Facade pattern Creates a simplified interface of an existing interface to ease usage for common tasks.Pipes and filters A chain of processes where the output of each process is the input of the next.

Signalprocessor

Data interpreter

AOCS simulation

Resultcomparison

Fault patternmatching

FDIR execution

Figure 7: FDIR execution modules.

trend checking, signal-model based, process-model based,and multivariate data analysis. All these methods are charac-terized by a configurationwhich starts from themost physicallevel to the more conceptual level. Each method is developedfor specific purpose in detecting failures in a particularscenario associated with the system being monitored.

Figure 7 illustrates the organization of an FDIR in termsof its module.The first one is the signal processing unit that isresponsible to provide a clean signal for analysis. The secondis the interpretation of the signal in order to give a goodinput data for the simulator unit. The third is the simulationunit that implements the computer simulations. Next is theresult comparison unit which compares the result of thesimulation with the input data and checks if the data receivedfrom the sensors monitoring the actuators demonstrate goodperformance with the expected AOCS behavior. If the resultsare consistent with the expected ones, they are used as inputfor an error pattern matching in order to try to find therecovery procedure to be started on the AOCS module.On the contrary, the ground base is alerted to assume thesituation and provide the solution for the problem. Assumingthat FDIR execution process is organized in a set of levels, it ispossible to identify the level where each module is executed.The levels are (i) equipment-level where it is located the signalprocessor module; (ii) functional-level where it is locatedthe data interpreter module; (iii) operation-level where itis located the AOCS simulation module; (iv) decision-levelwhere it is located the result comparison and the fault patternmatching modules [4].

TheAOCS simulationmodule ismodeled by the behaviorand creational design patterns. The AOCS simulation willindicate the expected response of the AOCS execution and

compare the results. This action is divided in two mainparts: (i) Verifying if the AOCS functioning is acceptable,and (ii) verifying if there are some software errors thatcould cause a failure situation. For the first part, the AOCSmain software is encapsulated and compares the results fromboth modules. The results are expected to be the same.If a difference is detected then the result could indicate apossible failure situation. The point is to find if the errorhas occurred in the AOCS module or in the FDIR module.So, this can be used only to detect the occurrence of theerror instead of identify it. The other kind of error is theidentification of a software problem.Thedetection is based onnondesirable result from the actuator actions, for the detectedinconsistency in the AOCS simulation. This verification isinside the AOCS simulator that includes the expectation ofeach actuator action and then implements the verificationabout the success of its action. If the result is not consistentwith the expected one, there is a probability of a software erroroccurrence. Another source of this kind of problem couldbe associated with hardware problems. That is why it is onlypossible to infer that an error has occurred, not the associatedsource of error. The result has to be submitted to the errorpattern matching module to determine the error source.

The error patternmatching module includes a set of rulesthat provides a clue about the current status of each subsys-tem.Also it includes the ability to start a subsystemunit checkto verify the hardware good functioning.When the results areanalyzed and a conclusion about the problem is achieved thedata are communicated to theAOCS systemwhich start somedifferent kind of actions such as configuration adjustments;sensors isolation; actuators isolation; change the strategy ofsome algorithm that will have to perform the commands witha different set of hardware devices, and call the ground basefor a procedure solution.

As a future study the suggestion is to build the FDIR sys-tem which verifies the results in order to check the strategiesthat were chosen, build a good set of known problems to forma knowledge base to be used in future missions, as well asstudying good strategies aiming at adapitative systems. Theaim of such work would be to provide a dynamic system

8 Mathematical Problems in EngineeringG

yro

outp

ut d

ata (

V)

Time (s)

51:3

5

51:4

0

51:4

5

51:5

0

51:5

5

52:0

0

52:0

5

52:1

0

0.006

0.005

0.004

0.003

0.002

0.001

0.000

−0.006

−0.005

−0.004

−0.003

−0.002

−0.001

Figure 8: Graphical image of the gyro raw signal.

Gyr

o ou

tput

dat

a (V

)

Time (s)

51:3

5

51:4

0

51:4

5

51:5

0

51:5

5

52:0

0

52:0

5

52:1

0

0.006

0.005

0.004

0.003

0.002

0.001

0.000

−0.006

−0.005

−0.004

−0.003

−0.002

−0.001

Figure 9:Graphical image of the gyro signalwith the impulsive filteractivation.

that can grow with new patterns of new studied errors soas to contribute for FDIR systems more proactive instead ofreactive systems.

5. Simulations and Results

For the sake of the approach assessment a set of data obtainedfor real case at INPE-LABSIM was used in the computersimulations. As a first stage of the development we haveimplemented the filter module for a FDIR using the approachof the single loop.Thismodule uses a file that was recorded inINPE- LABSIM containing up to 100 minutes of a gyro data.The software uses those to simulate the reading of the realsensor and presents a graphical view of the signal and showhow it changes when a set of filters and associated parametersare changed and combined. The results are shown in Figures8 to 12.

Gyr

o ou

tput

dat

a (V

)

Time (s)

51:3

5

51:4

0

51:4

5

51:5

0

51:5

5

52:0

0

52:0

5

52:1

0

0.006

0.005

0.004

0.003

0.002

0.001

0.000

−0.006

−0.005

−0.004

−0.003

−0.002

−0.001

Figure 10: Graphical image of the gyro signals with the impulsiveand Kalman filters activation.

Gyr

o ou

tput

dat

a (V

)

Time (s)

51:3

5

51:4

0

51:4

5

51:5

0

51:5

5

52:0

0

52:0

5

52:1

0

0.006

0.005

0.004

0.003

0.002

0.001

0.000

−0.006

−0.005

−0.004

−0.003

−0.002

−0.001

Figure 11: Graphical image of the gyro signals with the Kalman filteractivated and the impulsive filter deactivated.

Figure 8 shows us the raw gyro signal that was recordedat INPE-LABSIM. Figure 9 shows the same file but withthe impulsive filter activated. The filter can eliminate theundesirable signal peaks that could lead to an erroneousunderstanding of the satellite behavior.

Figure 10 shows the gyro signals by taking into accounttwo combined filters, the impulsive and the Kalman filters.Depending on the required gyro signal analyses, it is neces-sary to make an adequate combination of filters.

In Figure 11 it is presented the signal with the Kalmanfilter activated and the impulsive filter deactivated.

Figure 12 shows the gyro signals output taking intoaccount the both filters activated but in an inverse orderas compared with Figure 9. This filters order inversion haseliminated some characteristics of the gyro output becausesome oscillations were interpreted as signal peaks. So it

Mathematical Problems in Engineering 9G

yro

outp

ut d

ata (

V)

Time (s)

51:3

5

51:4

0

51:4

5

51:5

0

51:5

5

52:0

0

52:0

5

52:1

0

0.006

0.005

0.004

0.003

0.002

0.001

0.000

−0.006

−0.005

−0.004

−0.003

−0.002

−0.001

Figure 12: Graphical image of the signal with the Kalman andimpulsive filters activated.

is recommended a careful analysis of the results whenestablishing the correct order of the filters.

6. Conclusion

Automatic detection procedures as developed in this paperare very important in space applications as characterizationof occurrence, definition of criteria, and device types in thescenario of AOCS FDIR. This work implements a FDIRstudy for an IMU for space applications concerning failuredetection, isolation, and recovery from faults affecting thehardware performance under of the FDIR software mon-itoring. The types of failure considered in this article arethe step abrupt change, the ramp/drift/slow, the stuck, thecyclic, the erratic, the spike, and the stuck for variance. Thevalidation approach was accomplished by using a set of agyro data provided by the DMC’s LABSIM at INPE. Analysesof the gyro signals were made by using different filters andalso a combination of them. The results have demonstratedgood agreement with the concepts applied in this study. Inparticular, referring to the filter applications, it should bepointed out that the inverted order could lead to wrongconclusions since some oscillations that could be interpretedas peaks may not be exactly peaks. So a careful analysis ofthe results is recommended when establishing the correctorder of the filters. A framework for FDIR is developed thataccommodates different filter analyses and an appropriatealgorithm for a future study detection of each type of faultbeing analyzed. The FDIR software developed in this workincludes the capability to implement fault event mappings forIMU.

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper.

Acknowledgments

The authors would like to thank the INCT for Space Studies,CAPES, Aeronautical Mechanics/ITA/SP, and Computer Sci-ence, PUC/SP, for the support to accomplish this work.

References

[1] M. Blanke and R. J. Patton, “Industrial actuator benchmark forfault detection and isolation,” Control Engineering Practice, vol.3, no. 12, pp. 1727–1730, 1995.

[2] M. Bartys, R. Patton, M. Syfert, S. de las Heras, and J. Quevedo,“Introduction to the DAMADICS actuator FDI benchmarkstudy,” Control Engineering Practice, vol. 14, no. 6, pp. 577–596,2006.

[3] Y. Zhang and J. Jiang, “Bibliographical review on reconfigurablefault-tolerant control systems,” Annual Reviews in Control, vol.32, no. 2, pp. 229–252, 2008.

[4] X.Olive, “FDI(R) for satellites: how to deal with high availabilityand robustness in the space domain?” International Journal ofApplied Mathematics and Computer Science, vol. 22, no. 1, pp.99–107, 2012.

[5] R. Isermann, “Model-based fault-detection and diagnosis—status and applications,” Annual Reviews in Control, vol. 29, no.1, pp. 71–85, 2005.

[6] ECSS-P-001B, Glossary of Terms, July 2004.[7] Senior & Phil Ireland, “Modular architecture for robust com-

puting (MARC),” in Proceedings of the International SpaceWireConference, West Park Conference Centre, Dundee, UK, 2007.

[8] W. J. Kubat, “Application of strapdown inertial navigationto high performance aircraft,” AGARD Lecture Series-Strap-Down Inertial Systems 95, 1978.

[9] R. J. Patton, F. J. Uppal, S. Simani, and B. Polle, “RobustFDI applied to thruster faults of a satellite system,” ControlEngineering Practice, vol. 18, no. 9, pp. 1093–1109, 2010.

[10] E. Oliveira, Deteccao e Isolacao d e Falhas em Unidades deMedidas Inerciais com Redundancia Mınima de Giros de FibraOptica [Ph.D. thesis], INPE, Brazil, 2011.

[11] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Pat-terns: Elements of Reusable Object-Oriented Software, AddisonWesley, Reading, Mass, USA, 1994.

[12] U. K. Krogmann, “Failure management in spatio-temporalredundant, integrated navigation and flight control reference-systems,” in Proceedings of the IEEE Position Location andNavigation Symposium (PLANS ’90), pp. 330–337, Uberlingen,Germany, March 1990.

[13] UML Object Management Group, Group. UML 2.2 Super-Structure Specification (Formal/2009-02-02), UMLObjectMan-agement Group, Needham, Mass, USA, 2009.

[14] L. A. Wang, B. Liu, and M. Lu, “A modeling language basedon UML for modeling simulation testing system of avionicsoftware,” Chinese Journal of Aeronautics, vol. 24, no. 2, pp. 181–194, 2011.

[15] M. Muenchhof, M. Beck, and R. Isermann, “Fault-tolerantactuators and drives—structures, fault detection principles andapplications,” Annual Reviews in Control, vol. 33, no. 2, pp. 136–148, 2009.

[16] R. Isermann, Fault-Diagnosis Systems: an Introduction fromFault Detection to Fault Tolerance, Springer, Berlin, Germany,1st edition, 2006.

Submit your manuscripts athttp://www.hindawi.com

Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014

MathematicsJournal of


Mathematical Problems in Engineering

Hindawi Publishing Corporationhttp://www.hindawi.com

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of


Probability and StatisticsHindawi Publishing Corporationhttp://www.hindawi.com Volume 2014

Journal of


Mathematical PhysicsAdvances in

Complex AnalysisJournal of


OptimizationJournal of


CombinatoricsHindawi Publishing Corporationhttp://www.hindawi.com Volume 2014

International Journal of


Operations ResearchAdvances in

Journal of


Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttp://www.hindawi.com Volume 2014

International Journal of Mathematics and Mathematical Sciences


The Scientific World JournalHindawi Publishing Corporation http://www.hindawi.com Volume 2014


Algebra

Discrete Dynamics in Nature and Society



Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttp://www.hindawi.com

Volume 2014 Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014

Stochastic AnalysisInternational Journal of

research article fdir for the imu component of aocs...

Documents