• No results found

SMART-FDIR: use of Artificial Intelligence in the implementation of a Satellite FDIR

N/A
N/A
Protected

Academic year: 2021

Share "SMART-FDIR: use of Artificial Intelligence in the implementation of a Satellite FDIR"

Copied!
12
0
0

Loading.... (view fulltext now)

Full text

(1)

SMART-FDIR: use of Artificial Intelligence in the

implementation of a Satellite FDIR

Andrea Guiotto, Andrea Martelli, Carlo Paccagnini Alenia Spazio S.p.A.

Software & Simulation Architectures

Phone: +39 011 7180201/3, Fax: +39 011 7180036

E-mail: { [email protected] }{ [email protected] }{ [email protected] } Michelle Lavagna

Dipartimento di Ingegneria Aerospaziale Politecnico di Milano - Italy

Phone +39/02.2399.8394 Fax +39/02.2399.8334 e-mail { [email protected]}

Keywords:

On-Board FDIR, Autonomy, Artificial Intelligence

Abstract

Nowadays space activities are characterized by increased constraints in terms of on-board computing power and functional complexity combined with reduction of costs and schedule.

This scenario necessarily originates impacts on the on-board software with particular emphases to the interfaces between on-board software and system/mission level requirements.

The questions are: How can the effectiveness of Space System Software design be improved? How can we increase sophistication in the area of autonomy and failure tolerance, maintaining the necessary quality with acceptable risks?

1. INTRODUCTION

In the framework of the European Space Agency (ESA) research studies, Alenia Spazio & Politecnico di Milano have investigated the added value of Artificial Intelligence technology implementing a Satellite On-Board "Failure, Detection, Isolation & Recovery" (FDIR) Software system with real-time performances, robustness architecture, auto-learning & decision making capabilities, named

SMART-FDIR.

The Spacecraft Autonomy concepts are generally implemented on-board by a set of capabilities performing the automated management of the system and its payload. They include, in particular:

− Spacecraft Mission Execution Control (through predefined timelines)

− Continuous Determination of the Spacecraft Performance Status − Detection of anomalies in the Spacecraft Performance

− Failure Management (from identification of Failures to autonomous reaction to the Failure Events).

(2)

The objectives of increasing autonomy are to allow the spacecraft on-board systems to take decisions on the activities to be performed when unplanned events are detected. The purpose is not only to perform a transition to a safe operational mode — as normally required in previous generations of spacecrafts and where the continuation of on-board services provision is suspended — but also to autonomously react to these events, to reduce or suppress their impacts on the on-going mission.

This required capability to react to the detected events, is mainly related to the Spacecraft On-board Failure Detection, Identification, and Recovery (FDIR) provided mechanisms. Being this capability able to operate autonomously on the spacecraft configuration and its performance - Reliability, Availability, Maintainability, and Safety (RAMS) aspects assume a relevant role in the design, development, and verification of any Spacecraft Component supporting on-board the implementation of the FDIR Mechanisms.

Recent advances in System FDIR design and implementation can support the achievement of the increasing spacecrafts autonomy levels. This is particularly supported in the On-board Software Engineering area, where new techniques are available to allow for implementation of robust and effective FDIR solutions and strategies.

Dependable Systems must be approached in such a way to anticipate detection of failures related to mistakes in components and interfaces design/development as well as in operations definition. Reliance must not be put only on on-board FDIR capabilities. These shall, anyhow, be designed not to fail themselves.

The approaches presented in SMART-FIDR project aim to support fulfillment of these objectives by means of new methodologies and design practices, which allow to reduce mistakes in the specification and design of Autonomous System Components.

The selection of the space application has been based on the current involvement of ALENIA Spazio in ESA space programs. It in particular took into account the Alenia roles and responsibility in technical tasks (design, development, manufacturing, assembly, integration, verification and delivery) and overall project management. Among the scientific satellites under design and development in Alenia Spazio and according to the SMART-FDIR study purposes, Alenia Spazio proposed to compare the SMART-FDIR approach to the "GOCE" ESA satellite one. This is intended to be the reference test-bed for the evaluation of the prototype-demonstrator developed in this study.

2. THE PROJECT

The SMART-FDIR project started on 10th June 2002 and will terminate on the 9th June 2003. After providing the User Requirement Document and the Technical Note “Use of

(3)

AI for FDIR development”, the project is currently developing the SMART-FDIR demonstrator which will be delivered to ESA for the acceptance.

The software development is following an iterative approach, where each iteration will address a different FDIR mechanism:

1. Fault Detection 2. Fault Identification

3. Fault Isolation & Recovery

developing and applying the selected techniques and reporting the analyses results to verify if the use of AI techniques:

- improve on-board autonomy - improve classical FDIR

Each iteration is able to conclude on the appropriateness of each technique, its advantages and drawbacks.

First of all, the current state of the art in applying AI techniques to support the FDIR process was analyzed to identify the methodologies that best fit smart FDIR tasks in the space system domain .

The following table presents the chosen methodologies, highlighting benefits and limitation of the proposed approach.

Unit Approach Towards SMART- FDIR selected approaches

Pros&Contras Detection Modelization Model-Based:

Fuzzy Inductive Reasoning,

-two modelization levels, both adaptive: finite state logical level, dynamic qualitative level. Benefits: - mixed mathematical and logic

relationships actually driving the system are both considered with different tasks

- no prior analytical knowledge needed

- light computational effort on-line

- non linearities easily modelled

- re-configurable on-line Deviation

Management

FIR: residual between observer and sensor readings

Benefits: more faithful system monitoring with respect to fixed thresholds

Gravity Level FIR: envelope Benefits:-fast reactivity to dangerous situations -sensitive to smooth monotonic deviation -robust according to false alarms

Identifica tion/ isolation

Logic based: possibilistic reasoning

Benefits: -causal knowledge uncertainty and symptoms uncertainty completely considered: more faithful modelization

-safe: rank of possible failure admitted whenever uncertainty does not permit to identify a unique solution

- easier to configure than probabilistic nets -different level of granularity in failure detection (consistent/relevant)

- autonomous further symptoms check configurable

(4)

Recovery

State variable transition+MADM

Model-based: the same model implemented for the identification module. MADM approach related to an incremental best-first search for the global transition path definition (outer

level)+RANN (or FL) for adaptive control law (inner level)

Benefits:

-unique logic model implementation -easy reconfigurable

- not only feasible but also best recovery path identification in terms of selected criteria -easily insertable into a global Agent (planner, scheduler,executer, FM manager)

3. SOFTWARE ARCHITECTURE

The SMART-FDIR architecture is presented in the following figure:

Figure 1. SMART-FDIR Architecture

Two different logic flows are possible inside the SMART FDIR architecture: one for nominal scenario (no failure injection) and one for failure scenario (with failure injection). Detection Identification Recovery Module User Data Nominal Data Failure Data Failure Scenario Failure Injection Display Subsystem Simulator Output Displays Detection/Identification Displays Analyses Data Failure Injection Failure Scenario Nominal Data Failure

(5)

Choosing the Electrical Power Subsystem and Attitude Control Subsystem

of the GOCE satellite as validation scenarios, Smart-FDIR application has two main use cases:

1. SMART-FDIR POWER BUDGET: it allows to insert failures in the GOCE power budget simulator and makes the detection/identification using smart technique.

2. SMART-FDIR E2E SIMULATOR: it allows to insert failures in the GOCE e2e simulator and makes the detection using smart technique.

In order to accomplish the use cases it is necessary to customize the generic blocks presented in software architecture. Failure injection panel presents two sets of failures based on GOCE FDIR analyses document, one for Power Budget and one for the E2E simulator. Detection Identification Recovery Module contains the pre-processing of data and fuzzy logic algorithm. Both ones are customized for different use cases.

Subsystem simulator is the core of use cases because it is the executable program of subsystem (Power budget or E2E simulator). This module provides outputs to be processed by DIR Module and receives failure data by Failure injection Panel. The application provides the capability to display outputs of simulators and results of SMART-FDIR analysis.

Following paragraphs introduce all modules presented in the above pictures. 3.1 GOCE Simulators

SMART-FDIR made use of the following already existing simulators:

• The adapted GOCE EPS Simulator developed by Alenia in support to the GOCE program to simulate the global behavior of GOCE (Gravity field and Ocean Circulation Explorer) power subsystem during its C/D phase to optimize the satellite design.

• the PC-Win2000-adapted GOCE End-2-End Simulator developed in support to the GOCE program main to verify the system performance through the overall project life.

3.2 Detection Module

The Detection module accomplishes two main tasks: the reference model identification from I\O data set, and the alarm triggering.

The reference model identification, devoted to the pseudo-static relationship definition, can be run either off-line, once, or on-line, whenever a re-identification of the reference model is required.

Moreover, as the alarms are strictly related to the output states, and the alarms define a possible symptom scenario, they represent one of the inputs to the next Identification module. Hence, the state selection has to be done taking into

(6)

account which kind of failures has to be identified; in particular, which set of states is strictly related to the failure domain.

Depending on the dynamic system to be identified, a filtering of the highest frequencies has either to be applied or not. That particular issue turned out to be relevant by managing the two GOCE test-cases, the EPS and the ADCS SMART-FDIR modules development.

According to the envelope technique, two degrees of freedom are available from the user point of view: the size of the time window within which alarms are recorded, and the threshold of the cumulative error to trigger the alarm on. These two d.o.f. allow tuning the timeliness versus the robustness of the Smart-FDIR in terms of false alarm management: the larger the time window and the lower the threshold is the more sensitive the system is to false alarms.

3.3 Identification Module

The Identification Module accomplishes two main tasks: the logical system model identification in case of failure, and the failure scenario identification, with a degree of necessity, given a set of outputs from the former Detection module. The identification module, as already pointed out is based on the Possibilistic Logic approach. A KI net is settled off line in order to represent the logical causal dependence among failure events and system states, managing its intrinsic uncertainty.

According to the knowledge contained in the KIs the crisp values coming from the detection module, in terms of both activated alarms and sensor readings deviation from the reference model, are mapped into two different Fuzzy domains: the first one devoted to define the degree of necessity of each causal relationship in the KB between the symptoms and the failing scenarios,; the second one devoted to define the degree of necessity for each symptom in the KIs to be considered present, according to the crisp inputs from the Detection module.

The mechanism is based on simple union and intersection operations to accomplish both the consistency and the abductive processes: the novelty of the approach stays in that operations are managed on a qualitative domain by applying fuzzy memberships.

The outputs of the module are the degrees of necessity of each failure to be the actual event occurred, starting from the given observations. It could happens to have more than one index greater than zero, and this represents the ability of the tool to identify simultaneous failure occurrence, with a dedicated degree of necessity, even if the modellization process is based on the single failure logical analysis. Moreover, incipient failures, induced by the presence of a main failing event, are easily identified by the module, as it happens within the GOCE EPS application with a F25 failing scenario (loss of a battery cell ) where the F3 (minimum voltage occurrence) starts being correctly identified simultaneously with a linear increasing with time.

(7)

3.4 Recovery Module

The Recovery module receives, as input, the current failure mode identified, and gives, as output, possible path to recover the system functionality.

The module presents, as the former ones: an off-line processing in order to identify the system the Smart – FDIR has to be applied on, as a finite state machine; an on-line module devoted to find the admissible transitions between states according to the current components admissible states due to the failure occurred.

Within a simple text file, the main high level activities the system has to accomplish (such as using the p\l, thrusting the system, having a downlink) are defined in terms of states required, attributes for the states, attribute transition matrix, resource demand. States can be both physical devices and sub-activities. Both redundancy and reconfiguration of the mission goals can be easily managed.

As always, the more detailed the state and attributes domain is represented, the more detailed the reconfiguration path will be. Moreover, multiple reconfiguration paths can be identified, ranked according to a multi-criteria decision making approach, based on the maximisation of the scientific return of the mission, the user preference and the overall system status in terms of available on board resources.

3.5 Implementation aspects

SMART-FDIR made use of the following COTS tools to develop the prototype:

• MICROSOFT VISUAL-C/C++ as compiler

• MATLAB-SIMULINK as modelling and programming language

• MATLAB COMPILER to automatically generate code and final executable program

SMART-FDIR prototype runs under Windows 2000 operating System. 4. VALIDATION

SMART-FDIR approaches have been validated running the prototype, injecting a fixed set of predefined GOCE failures and evaluating the outputs. Each failure passed predefined tests sequences created for each FDIR mechanism (Detection, Identification and Recovery). All results have been documented in the SMART-FDIR Validation report.

As an example, the following table, extracted from the SMART-FDIR Validation report, presents some of the failures injected into the SMART-FDIR prototype and the GOCE Detection approach:

(8)

Failure Name Description Current Detection 4.4.2.2-F1 Loss of Battery Connection Switch Loss of battery

connection switch Battery monitoring 4.4.2.2-F22 Loss of one SA panel (open circuit) Complete loss of SA power because of disconnection By ground investigation

Regarding Failure 4.4.2.2-F22, the next figure shows the model forecast and the real sensor readings for the Solar Array power supply having injected the loss of the Wing1 at 4000s. The real readings (blue) falls out of the “envelope” given by the model, as soon as the failure is injected, creating an instantaneous deviation between the expected and read value.

Figure 2 Detection output

Failure F22, as written in above table has to be investigated from ground. The SMART-FDIR proposed approach based on the FIR technique from the AI domain, makes the symptoms from that failure timely detectable without being trapped by false alarms

5. ACHIEVEMENTS AND LESSONS LEARNED

The results obtained by applying the overall architecture selected and implemented for the Smart_FDIR definition allows to highlight the following benefits and limits, according to the classical approaches within the FDIR management:

(9)

♦ Dynamic system modelling: a reference model definitely adaptive can be created and refreshed whenever required, even on-line, as the model identification works only with time series data. The dynamic system has to be, conversely, sufficiently known according to its frequency band, in order to obtain a correct sampling frequency. In order to maintain the forecast process and, hence, the detection process fast, the data series management in terms of size has to be maintained low. It could be, hence, necessary to filter the signal with low pass-band with a cut at the correct value, not to loose dynamics information that leads to consider as a symptom a correct dynamics oscillation.

♦ False alarm management: the envelope together with the model-based approaches guarantees a good prevention of false alarm. The envelope technique, differently from the classical approaches based on simple threshold tables for selected observed states, makes possible not to be trapped into output deviation from the expected values due to modelling errors and system noise. Moreover, as the envelope width is not fixed throughout the running but correctly follows, dynamically, the modelling current precision, deviations are differently judged according to the actual system status. To make the system more robust, the cumulative error time window and threshold can be varied by the expert user. That represents, again the delicate aspect of the approach, as those two degrees of freedom should be managed carefully, by balancing the sensitivity versus the robustness the user wants to achieve during the running.

♦ Failure identification: the insertion of the degree of necessity allows taking into account all uncertainties the identification process has intrinsically and that normally are definitely cut out in the classic FDIR approach. Each failure scenario are evaluated in parallel and ranked, within a non-excluding mechanism as, whenever a failure is not necessarily happening, it is maintained as possible with a complementary degree and not pruned. In that way, multiple failure can be easily identified starting from a given symptom scenario; moreover, each of them is labeled with a degree of necessity to occur dependent on time. Differently from the classical approach, hence, multiple failures can be identified by the system itself, without setting, off-line, dedicated reading thresholds to identify each failure combination. Moreover, incipient failures are easily highlighted by the system before the failure actually occurs, just by managing the current symptom scenario. Hence, by monitoring its degree of necessity to occur the user has time to evaluate the current evolution and makes consequent decisions, safely in time. The limits stay, again in the effort needed to settle correctly and exhaustively the knowledge base related to the logical causal dependence. Attention has to be paid on symptoms to be necessary within each failure, fundamental to distinguish it from the others.

(10)

♦ Recovery paths: The current approach allows defining recovery paths different from the simplest safe mode, normally settled whenever a failure occurs in the classical approach. The state variable transition approach allows optimizing, in terms of different aspects, the user included, the current reconfiguration, whenever the occurred failure neither does nor implies the spacecraft health loosing. The increased degrees of freedom thanks to the finite state machine modelling of the system, translates the reconfiguration search into a combinatorial constrained problem with possible multiple solutions. That is why the each path is ranked according to an internal multi-criteria decisional process that firstly assures the system survivability in terms of current constraint set satisfaction and, secondly optimizes the reconfiguration in terms of product return. The main limit, as for each former aspect, stays in the necessity of a good knowledge of the system the Smart-FDIR has to operate on. Both a physic and a functional knowledge is needed in order to correctly settle the states and attributes involved in each high level activity and to define the global transition matrix, fundamental for the consistent path definition.

♦ Use of A.I. in the Satellite Design process: The development process of this application has highlighted some critical points to be considered in adoption of SMART-FDIR techniques.

Definition of failure starting form requirement specification.

Use of A.I. techniques needs a clear statement of the system to be modeled: some problems occurred in exchanging information between Susbsytem Engineers and A.I. software developers leading to duplicate single failures. Basically these problems was tight in choosing the same physical measurement or parameter to identify different failure. This can cause misunderstanding during the identification phase. Suggestions are to involve A.I. software developers during the FDIR detailed analysis before starting the FDIR implementation.

Pre-processing of data

The use of Fuzzy logic requires a pre-processing of data involved in FDIR analysis. The characteristics of system can not be changed unless to pre-processing again the data. In fact, changing system characteristic (i.e. attitude control) provides different outputs to be used in FDIR analysis. If a correct pre-processing of outputs is not performed, the fuzzy logic algorithm will not work. Finally a pre-validation of algorithm and freezing of system is required to be sure that FDIR works correctly.

As a conclusion, A.I Software Development guidelines has to be better analyzed before starting to introduce the use of such A.I. techiques in Space projects.

♦ Development approach: The software development environment chosen to develop SMART-FDIR application well granted the :

(11)

1. Development of pre-processing and fuzzy logic algorithm 2. Development of User Interface

3. Integration of UI, FDIR algorithm and subsystem Simulator (as executable program)

4. Automatic code generation for creating a final executable version of Smart-FDIR fully standalone (i.e. without the need to have a Matlab licence running)

This study well demonstrates that Space System Software design can be improved: we can increase sophistication in the area of autonomy and failure tolerance, maintaining the necessary quality with acceptable risks. Artificial Intelligence technology with well defined development guidelines, has to be really considered for the development of a Satellite On-Board FDIR Software with real-time performances, robustness architecture, auto-learning & decision making capabilities.

6. REFERENCES

[Lucas] P.Lucas, A.Onisko, M.Druzdzel, “Comparison of Rule based and Bayesian networks approaches in medical diagnosis systems” Artificial Intelligence in Medicine, Springler, Berlin,2001

[Patton] R.J.Patton, “Robust Model based fault diagnosis: state of the art”, IFAC Symposium, Fault detection, supervision and safety for technical processes, Espoo, vol. 1

[Frank] P.M.Frank,” Analytic and Qualitative Model based fault diagnosis: a survey and some new results”European Journal of Control, 1996 No. 2

[Nebot] A.Nebot, F.Cellier,M.Vallverdu, “Mixed quantitative/qualitative modelling and simulation of the cardiovascular system”, Journal of Computer Methods and Programs in Biomedicine, 1997

[Poole] D.Poole, “Representing Diagnosis Knowledge”, Annals of Mathematics and Artificial Intelligence,no.11, 1994

[Tur] J.M.Tur, R.M.H.Garrido, “Fuzzy Inductive Reasoning Model-Based Fault Detection Applied to a commercial Aircraft”,Simulation journal, vol.75, 2000

[Gertler] J.Gertler, “Fault detection and diagnosis in engineering systems”, Marcel Dekker ed., N.Y 1998

[Escobet] A.Escobet, A.Nebot, F.Cellier, “Model acceptability measure for the identification of failure in qualitative fault monitoring systems”, European Simulation Multi-conference, Warsaw-Poland, 1999

[Nebot] A.Nebot, J.J.Valdes, M.Guiot, R.Alquezar “Fuzzy Inductive Reasoning Approaches to the identification of models of the Central Nervous System

(12)

Control”, ICSC Symposium on Engineering of Intelligent Systems, Tenerife, Spain, February 1998

[Cayrac] D.Cayrac, D.Dubois,H Prade, “Handling uncertainty with possibility theory and fuzzy sets in a satellite fault diagnosis application”, IEEE Transactions on Fuzzy Systems, vol.4, no.3 1996

[Poole] D.Poole, “Normality and Fault in Logic-Based Diagnosis” Proceedings of the International Joint Conference on Artificial Intelligence (IJCAI) Detroit-MI 1989

[Holsti] N.Holsti, M.Pakko, “Towards advanced FDIR Components”, DASIA Congress, 2001

[Goel] P.Goel, G.Dedeoglo, S.Roumeliotis, G.Sukhatme, “Fault Detection and Identification in a mobile robot Using Multiple Model Estimation and Neural Network”,Proceedings of IEEE International Conference on Robotics and Automation, San Francisco, Ca,2000

[Dexter] A.L.Dexter, “Model-based fault diagnosis using fuzzy matching”, Proceedings IEE, Pt D vol. 142, no.6 , 1995

[Welch] G.Welch, G.Bishop,”An Introduction to Kalman filter”,University of North Carolina at Chapel Hill, TR 95-041, June 6, 2002

[Friedland] B.Friedland, “Control System Design: an introduction to state space methods”, Mc.Graw-Hill

[Haykin] Haykin, ”Neural Networks: a comprehensive foundation”N.Y. Mac Millan College publishing Company

[Isermann ] R.Isermann, “Fault diagnosis of machines via parameter estimation and knowledge processing”, Journal of Automatica, 29(4), 1993

[Marcu] T.Marcu, L.Mirea, “Robust Detection and Isolation of process faults using neural networks”, IEEE Control Systems, vol 17, no 5, 1997

[Mirea] T.Marcu, L.Mirea, P.M.Frank “Development of Dynamic Neural Networks with application to observer based fault detection and isolation”, Journal of applied Mathematics and computer science, vol.9, no.5,1999

[Yuan] J. Klir, B. Yuan, “Fuzzy sets and fuzzy logic: theory and applications”, Prentice-Hall Inc. Ed., 1995

[Li] D.Li, F.E.Cellier,” Fuzzy Measures in inductive reasoning”, proceedings of the winter simulation conference, New Orleans, LA, 1990

References

Related documents

Based upon promising results from the combined lenalidomide plus rituximab treatment, the international, multicentre, randomised study RELEVANCE 88 will evaluate standard

Given that a CaMKII molecule consists of 8-12 subunits of at least two possible isoforms and that each of these subunits will be in one of five different states, the number of

These are a combination of unregulated market determined elements (the wholesale price and the retail margin); regulated charges (transmission and distribution charges); central

Advancement of information technologies in the last decades switched the focus of interest from technical performance to service effectiveness and user satisfaction of

A workflow model may be clearly represented using three levels, where the first (highest) level describes the company structure and the possible flows between organizational

The financial liberalisation index for Nepal has been constructed by including eight different policy measures implemented during the liberalization process.

Inflation has a significant positive effect on company profitability, GDP does not have a significant positive effect on profitability, capital structure has

There is also a signifi cant challenge in positioning advice as a relevant and helpful solution to people with both resolvable and unresolvable debt problems: 49 percent of