Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/institute/conference/iwpss/plenary-o1-Jameux.pdf Дата изменения: Tue Mar 20 17:47:28 2012 Дата индексирования: Tue Feb 5 11:32:32 2013 Кодировка:

Monitoring & Diagnosis on-board software module for Mars driller (MODI)
David Jameux ~, Raffaele Vitulli ~, Rita Almeida Ribeiro*, Tiago Fonseca*, Bruno Santos*, Manuel Barata*
~

European Space Agency (ESTEC) * UNINOVA - CA3

Abstract
In this paper we first present the concept of Monitoring & Diagnosis techniques for remote systems within the context of robotic Martian exploration. Then we show how the MODI project is aiming at monitoring and diagnosing a drilling and sampling system for Martian exploration rover, and explain how MODI implements a fuzzy system to monitor and diagnose a drill. Last, we present the preliminary test results of MODI and demonstrate that MODI allows monitoring mileage of the drill and preventing dramatic failures, hence extending the drilling operations capability of a Martian rover in the long term.

Background
ESA developments regarding Monitoring & Diagnosis tools for robotic payloads fit in the context of Martian exploration and the associated constraints on mission operations.

European Mars exploration
In the preparation of the ESA Aurora program, which targets the robotic and human exploration of our solar system bodies holding promise for traces of life, Mars has been naturally designed as the first step before organising more ambitious enterprises. On the basis of the technologies available in the next 20 or 30 years from now, by 2030-2040 an international human mission to Mars may be a reality. In this context, robotic missions will prepare the human missions, by: - collecting as much scientific and engineering data as possible without human scientists in situ, - constructing facilities for the crew, energy and material resources generation, - maintaining the above-mentioned facilities, - supporting human exploration tasks which would be too risky, too complex, or too time consuming, - performing crew-independent exploration tasks under control of the humans on Earth or on the planetary surface.

Figure 1 - Artist's view of the ExoMars rover while drilling and sampling a rock on Mars The two first missions of the European Mars exploration programme, ExoMars and Mars Sample Return foresee drilling and sampling of Martian rocks and sand.

Mars missions operations constraints
The round-trip radio time for Mars operations degrades and sometimes hinders the advantages of telepresence, which implies continuous sensory feedback to the operator. To overcome this problem the robotic systems must carry sufficient sensors, effectors, and computer intelligence on board to perform simple tasks automatically, while higher level commands, as well as the selection and sequencing of tasks, are controlled by the teleoperator. Autonomous machines constitute the next level of robot independence and are very probably the most suitable type for Mars surface applications. Autonomous behaviour based machines evolve in an entirely autonomous way, given the


total absence of control of a programming/supervisory link with an operator station. In this scenario, an operator station plans and then refines the mission, generating a set of tasks to be interpreted and performed by the robot. The robot is fully autonomous at task level. It receives task assignments, which it transforms into sequences of actions using its own interpretation and planning capabilities. Tasks are therefore a temporal and logical composition of elementary actions capable of achieving an objective in a context-dependant way, providing possibly predefined corrective actions to be launched in case of unsuccessful execution.

Monitoring & Diagnosis
Monitoring & Diagnosis consists in monitoring the evolving behaviour a system, detecting subtle deviations over time (from seconds to months), and producing a diagnosis of the system when requested. Just like for on-board Planning & Scheduling, the motivation for investigating on-board Monitoring & Diagnosis technologies is based on the complex nature of remote exploration, characterised by unpredictable environment and restricted communication links. While Planning & Scheduling is usually triggered as a reaction to unpredicted events, Monitoring & Diagnosis allows detecting trends and trigger Planning & Scheduling at an earlier stage in order to optimise resources or avoid that these trends lead to failures.

Monitoring & Scheduling and PS
Monitoring & Diagnosis is a base technology for autonomy, together with Planning & Scheduling. It is not Planning & Scheduling but it is fully complementary to it. Indeed, so far, on-board (re)planning is justified by events because of which the current plan cannot be continued. These events may be recoverable failures of a sub-system, unrecoverable failures of a sub-system, or temporary unavailability of a consumable resource such as time or power. In each case, Monitoring & Diagnosis allows for more efficient re-planning, hence saving time and power. Prognosis of recoverable failures. Planning & Scheduling can be triggered in case of recoverable failure of a subsystem. But the time and the actions required to actually recover the failure have to be scheduled prior to any further attempt to recover the mission plan. Stopping the subsystem before the failure would therefore allow more efficient re-planning. Monitoring & Diagnosis of the subsystem allows forecasting that the sub-system is likely to fail its ongoing operation and therefore taking action to replan the operations. For example, on a driller for Martian soil, it is possible to distinguish between different vibration modes, some of them showing that the drilling is inefficient and is likely to never complete. Monitoring & Diagnosis techniques allow detecting such vibration modes, stop the ongoing drilling and invoke Planning &

Scheduling to re-plan the mission, i.e. drill somewhere else or in different conditions. Prognosis on consumable resources. Planning & Scheduling is also useful in case of temporary unavailability of a consumable resource. But again, the time and the actions required to recover enough of this resource have to be scheduled prior to any further attempt to recover the mission plan. Therefore, re-planning before an operation fails because a resource becomes unavailable would be more efficient. For example, from the behaviour of batteries, it is possible to evaluate their aging and therefore forecast their efficiency in the future. Monitoring & Diagnosis techniques allow evaluating this aging and feed the Planning & Scheduling with evolving battery parameters, so that the re-planning of the mission is more efficient. Hence, Planning & Scheduling is less likely to produce a plan that will either not be completed because of power unavailability or exhaust the batteries so that nothing else than battery charging can be performed next. Unrecoverable failure avoidance. Finally, in the case of unrecoverable failures, Planning & Scheduling is obviously inefficient, especially if the failure occurs on a critical sub-system, i.e. the subset of the system that supports the execution of the most relevant aspects of the mission. Indeed, when a critical subsystem fails, the re-planning required implies dramatic changes to the mission and is therefore likely to be done on ground, by the operations team, rather than on board. Moreover, the scope of the mission is in any case dramatically reduced. Hence the need to avoid such failures. On a critical sub-system, Monitoring & Diagnosis techniques allow detecting that the sub-system is heading towards unrecoverable failure and therefore stopping the on-going operation before such a failure occurs. For example, on a driller for Martian soil, it is possible to distinguish between different vibration modes, some of them being expected and harmless for the driller, other ones being likely to lead to mechanical failure of some part of the driller. Monitoring & Diagnosis techniques allow detecting such harmful vibration modes and stop the operation of the driller before any mechanical failure occurs, hence saving the mission. Planning & Scheduling can then be invoked to re-plan the mission, i.e. drill somewhere else or in different conditions. As Monitoring & Diagnosis allow also detecting the aging of critical mechanical parts, future re-planning can also take this aging into account and decrease the level of expected mechanical stress in future drillings.

Changing operations paradigms
On-board Monitoring & Diagnosis and on-board (re)Planning & Scheduling complement each other within the scope of a more ambitious ESA roadmap to bring more intelligence and autonomy on board deep space missions through the autonomisation of complex payloads. Indeed, when a trend is detected (output of MODI) it is possible to re-plan the mission operations ([1][2][3][4]) either in order to save a critical-subsystem or in order to cancel ongoing


TM TC

TM

TM

TC

recovery
human based operations TM TC safe mode safe mode

degradation

human based operations TM TC

failure

human based planning and scheduling

human based monitoring and diagnosis

Figure 2 - Classical operational mode: on-board failure detection, on-ground diagnosis and re-planning or future useless tasks and modify the mission plan accordingly to benefit from the released resources (e.g. time, power, or instrument). Once systems are developed with such capabilities of continuously and autonomously re-planning their timeline according to trends, non-critical events and mission goals, through dynamic configuration of degraded modes, the burden on ground-operations teams will be lighten and, more important, the science-to-mission-duration ratio will be increased dramatically. Figures 2 and 3 illustrate this change of paradigm.

on-board monitoring and diagnos is

degradation
TM actions TC TM degraded mode TM

nominal mode TM

on-board planning and scheduling

TC

recovery

order to cope with the complexity of Monitoring & Diagnosis and the limited computing capability on board exploration spacecraft, MODI is based on AI techniques that reproduce the expertise of humans, hence allowing advanced FDIR (Failure Detection, Isolation and Recovery). Project objectives. MODI will use explicit fuzzy knowledge models to enhance the real-time fault diagnosis of an existing system. It will have the ability to effectively recognise that anomaly, malfunction or an unpredicted event is taking place. It is indeed possible to develop tools in order to create on-board diagnosis of instruments based on unsupervised modelling and hence capable of monitoring their evolving behaviour, detecting subtle deviations, and thus predicting possible failures [5]. A number of studies and prototypes have discussed and tested the possibility of developing such type of monitoring tools [6] [7]. Although a number of positive results have been achieved using different knowledge-based technologies for diagnosis and control (for instance rule-based reasoning, expert systems, data mining, fuzzy logic, etc.), the real strength of these technologies lies in their combined operation. Therefore, this activity was proposed to demonstrate the capability of European industry and academia to build a monitoring and diagnosis software module for a complex Mars rover payload like Pasteur as an example [5]. In order to balance the stringent requirements for reliable autonomous operation and the constrained resources of the spacecraft, an iterative and phased approach is proposed. Monitoring & Diagnosis capabilities have found little industrial application in space because of a lack of clear need, despite a good basis of theoretical studies on the usage of fuzzy logic or modelbased FDIR. But a Monitoring & Diagnosis tools based on fuzzy logics is already running operational at ESOC, monitoring the gyroscopes of ENVISAT [7]. This shows that the technology is mature if applied on well-known systems and implemented on ground. The suitability of Monitoring & Diagnosis in the frame of Aurora Mars missions is expected but still to be demonstrated: Can software monitor a complex mechanical devices of a robotic payload? If yes, can this be performed on board?

human based operations

human based operations

Figure 3 - Increased autonomy: on-board monitoring, diagnosis, failure avoidance and re-planning

DSS simulator module TC

TM

MDM MDM information

TC module

DSS TM smart visualisation module

MDM output smart visualisation module

The MODI project
The ESA funded MODI activity proposes the use of knowledge-enabled technologies to increase the robustness of the mission monitoring and control systems, as foreseen in the Aurora Roadmap for Knowledge Technologies. In Figure 4 - High-level architecture of the MODI demonstration bench.


Planned activities. The aim of the MODI activity is to answer these two questions, taking as a case study the Monitoring & Diagnosis of the most complex subsystem taken on board the payload of the two first ESA Exploration missions (ExoMars and Mars Sample Return) i.e. a drilling and sampling system [8]. The goal of this activity is thus to assess the feasibility of on-board or on-ground monitoring and diagnosis of devices of a drilling and sampling system (DSS) for Martian soil and to develop and demonstrate the MODI concept i.e. the benefits of a prototype Monitoring & Diagnosis software module (MDM) for this system (see Figure 4).

Input variables. Considering the above variables and knowledge acquired during meetings with the drill's manufacturer, the variables identified for the MODI are ten. These variables are divided in 2 classes: the direct ones which are the real values obtained from the sensors, and the calculated ones which are calculated using other information. Direct variables: 1. RPM speed (rpm) speed 2. Feed Rate speed translational speed 3. Motor Current (A) used by the Motor 4. Motor Voltage (V) used by the Motor 5. Thrust force (N) being made in the tran ­ indicates the current rotational (mm/min) ­ indicates the current ­ Indicates the current that is being - Indicates the voltage that is being Indicates the current force that is slational direction

MODI : Fuzzy knowledge based Monitoring & Diagnosis system
In this section we explain how MODI implements a fuzzy inference tool to monitor and diagnose a Martian drill.

Fuzzy knowledge model architecture
A Fuzzy Knowledge-based approach includes a model expressed in terms of a fuzzy vocabulary and where the underlying relationships, between the related fuzzy sets, are represented by rules [7]. This basically means that the effective model design proceeds from changes in the number, shape and overlapping between fuzzy sets rather than solely from changes in the production rules. All these are fundamental hints in terms of model representation that should be supported by a specific methodology like the one we propose here in order to appropriately encode the system knowledge. Regarding the MODI architecture, this module will be integrated in the general architecture, as shown in Figure 4.

Calculated variables: 6. Total power consumption (W) - Indicates the total power consumption used by the drill 7. Rotation power consumption (W) - Indicates the rotation power consumption used by the drill 8. Feed Rate power consumption (W) - Indicates the translational power consumption used by the drill 9. Torque force (N) - Indicates the current force that is being made in the rotational direction 10. Material Cohesion (MPa) ­ Indicates the material Cohesion Scenarios. The drill's manufacturer performed tests in different types of terrains and could therefore provide the values for the input variables in the frame of the following six test scenarios: 1. Drill profile while not drilling 2. Drill profile in Gas-Concrete 3. Drill profile in Travertine 4. Drill profile in Concrete 5. Drill profile in Tuff 6. Drill profile in Marble For each terrain, six different sub-scenarios (six subsets of values for the input variables) were available, providing overall 36 sub-scenarios.

Input variables & scenarios
At the time of MODI's requirement elicitation with the drill's manufacturer, the Pasteur drill had just completed Phase Study A, and no real prototype existed for the device (only design documentation). However, the manufacturer showed the MODI project team a drill prototype, somewhat similar to the one proposed for ExoMars that MODI used as case study. Further, the documentation provided by the manufacturer allowed understanding the functioning of the drill as well as its representative variables for monitoring. Due to the high restrictions on mass, space and power consumption the number of existing sensors in the drill device is rather limited and the variables that can be assessed are: · Power spent on the DC motor either for: o Rotation movement: torque power. o Translation movement: thrust power. · Rotations per minute (RPM) · Feed Rate (Translation Speed) (mm/min) · Position of the drill Rod

Variables domains
We identified the domain for each variable, as shown in Table 1. Table 1 indicates the value range that each identified variable in the system can assume. It should be pointed that in this project the variables RPM Speed, Feed Rate Speed are considered set points, as these variables will be imposed by humans. Several speeds will be determined a priori in order to obtain a set with the most appropriate speeds for the drills.


Range RPM Speed (rpm) Feed Rate Speed (mm/min) Motor Current (A) Motor Voltage (V) Total Power Consumption(W) Rotation Power Consumption(W) Feed Rate power consumption (W) Penetration Depth (mm) Thrust Force (N) Torque Force (Nm) 0 - 200 0 ­ 1.5 0­3 30 0 - 30 0 ­ 28.5 0 - 1.5 0 ­ 2000 0 - 1200 0­5

the nominal value. The further apart from the nominal value, the more penalized the violation will be. The values outside of the trapezoid are considered faulty values.
1

0



1



2



3

f

Figure 5 - Examples of Singletons

Table 1 - Variables domain ranges In addition, we consider another set point that is the terrain hardness. Table 2 indicates the range of values for the terrains, in which the tests will be performed. With these ranges we hope that it is also possible to infer the type of the terrain.
Range Very Weak Weak Medium Strong Very Strong 0 - 20 20 ­ 40 40 ­ 80 80 ­ 160 160 - 320

1

0

1

µ

2

f

1 = - ( в10%) Triangular ( ) = = Nom _ Value 1 = + ( в10%)

Figure 6 - Triangular Fuzzy set and its creation formula

1

Table 2 - Terrain characterization

0

1

1

µ 2

2

f

1 1 Trapzoidal ( ) = N 2 2

=

1 - ( x 1)
N - ( y N )

=

= No min al Value = = N + ( x N )

2 + ( y 2)

Fuzzification of input variables
How to fuzzify input variables. The variables of the system can be divided in two categories: set points and variables. Set points are the input variables for which the value is given by the user and will not change. Variables are the other input variables. In order to perform the fuzzification of the variables we assume three cases: (1) the linguistic variable that include 3 elements, represented by single point functions (singletons); (2) the linguistic variable that include 1 element, represented by a triangular membership function; (3) the linguistic variable that include 1 element, represented by a trapezoidal membership function. Cases 1 and 2 are two cases for defining the set points. Only exhaustive tests will determine which case should be used. In the case 1, no deviation is allowed and in case 2 very small deviation is allowed. Besides the set points, all other variables are defined as trapezoidal membership functions, defined as in case 3 (Figure 7). The µ is the nominal value for the variable considered. The range between 1 and 2 is the allowed range for the nominal value that a variable can assume, i.e. there is no violation within that range; the distance between 1&a1 and 2&a2 is the allowed deviation from

Figure 7 - Trapezoidal Fuzzy set and its creation formula

Automatic learning for nominal values determination. The new data preparation process, which is based on the classical data preparation paradigm is shown in Figure 8 [10]. In addition to the classic (crisp) paradigm we added a new task, Fuzzy Set Generation. This last step is needed for the automatic construction of the fuzzy membership functions that represent each variable, which will be used later in the fuzzy rule base system. Hence, the Data preparation steps for MODI are: 1. Extraction: this process is characterized by means of obtaining data from different databases or files. In our

Figure 8 - Data Preparation information flow


case, we use test results from a real drill prototype, which provide the identified variables 2. Transformation: data is transformed from a raw state into data most (information) suited for decision support. In our case we removed the headers and unused variables of the data files 3. Cleaning: erroneous records are eliminated and data fields are checked for consistency and missing values. In our case we removed all subsets of data that were not important for the nominal value generation, e.g. transition between defined set points, initialisations, etc. 4. Integration: data from multiple databases and other sources are integrated into a central data repository. In our case it consisted in creating a file with subsets, based on pre-defined scenarios, and calculating the mean and standard deviation for each variable, within the respective scenario. 5. Fuzzy sets generation: we used the mean and deviation of each variable within a scenario to construct the respective fuzzy membership function that represents the variable. This approach is based on the nature of the physical process underlying the monitoring objectives: during the drilling process, each variable is expected to present some small random variation around a central value. Variations are due to the environment electrical noise and micro variations of the physical process. Later in the project, new methods for calculating fuzzy membership functions will be studied and tested in order to tune the system. Among these methods we include clustering, attribute selection, discretizing and data cleansing. For all methods, batches of tests will be performed in order to assess their performance. This will allow adapting the MODI tool to any type of drill that will be developed later.

IF

Terrain is T-GC0 and Feed Rate Speed is FRGC0 and Rotation Speed is RS-GC0 and (Thrust is not T-NominalGC0 or Rotation Voltage is not RV-NominalGC0 or Rotation Current is not RC-NominalGC0 or Rotation Speed is not RS-NominalGC0 or Translation Voltage is not TV-NominalGC0 or Translation Current is not TC-NominalGC0 or Translation Speed is not TS-NominalGC0) THEN Alarm-level.

We do not show the complete set because the other rules are similar. It should be noted that we have to distinguish between set points (given by the user) and variables (values given by the sensors). The set points have to be satisfied, while any other variable that deviates from its nominal value will trigger an alarm-level. The logic in the rules expresses this problematic because the AND (minimum of the membership values) provides the mandatory satisfaction of all set points while the OR (maximum of membership values) provides any faulty variable. Logical AND corresponds to the min-operator and the OR corresponds to the max-operator. The output will provide the severity-level of the alarm, using the LOM (Largest of maximum) deffuzification method.

Data sampling frequency
There was no previous knowledge about the spectral composition of the signal to be acquired: the micro vibrations sensed on the drill holding body due to the drilling process. For those situations, the recommended procedure is to use the maximum sampling rate the acquisition system can support. This procedure, according to the Shannon sampling theorem, will provide an analysis resolution bandwidth of half of the sampling frequency. The maximum sampling rate the acquisition system provides is 10 KHz. As a starting point it was considered that a 0 to 5 KHz bandwidth analysis would be sufficient to detect the micro vibration signal characteristics. After having analysed the collected data, a nominal sample frequency will be selected, probably lower than the one used for preliminary prospecting.

Fuzzy output variables
The output variables represent the warnings/alarms of parameter deviations from "nominal" values. The variable range is [0,1] where each degree represents the severity level of the alarm. For instance, 0 means no alarm, 0,2 a low alarm, 0,8 a high alarm and 1 a critical alarm.

Rules
The first objective of the project is to monitor default working conditions of the drill device. In this case all variables are used and the combined values from the sensors will be used to determine if the drill device is working in a nominal behaviour or if alarms should be triggered. The system has thirty six rules according to the thirty six sub-scenarios provided by the manufacturer. For each subscenario a rule was created. Each rule is created using the three set points (Terrain, Feed Rate Speed and Rotation Speed) and all other available variables. Bellow, we show one example of rule created for the scenario Gas-Concrete and sub-scenario 0 (GC0).

Preliminary results
In this section, we present the preliminary results of the MODI tool. As seen in previous sections, the system has 10 parameters, 3 set points and 7 sensor variables. These variables are considered within six different scenarios that are the result of a test campaign performed by the drill's manufacturer. Each scenario is sub-divided in six different sub-scenarios, leading to a total of thirty-six sub-scenarios. Except the terrain that is defined with six membership functions indicating the terrain hardness, each variable is


defined with thirty-six different membership functions. I.e. each variable will have a different representation depending on the sub-scenarios defined. In addition, we remind that the nominal values and the respective nominal range that we use were determined by using a learning algorithm based on the use of mean and standard deviation to define the nominal values and their deviations, as described in the previous section.

Detection of non-nominal operation
Here we present a first set of tests that were performed on the inference system. At this stage we only performed a reduced set of tests to assess the inference system correctness. Later in the project more validation and tests will be performed with a simulator of the drill that is currently being implemented. With the simulator, we will be able to define validation tests with various noisy data, define more scenarios, and include the terrain recognition capability ­ one of the aims of this project. Test case. In Table 3, we show 5 tests performed for a scenario of gas-concrete and sub-scenario 0.
Set Points Linguistic Variables

Figure 9 : Graphical representation of the 5 cases presented The deviation of the Rotation Voltage from nominal values is smaller than the deviation of Thrust. So the inference value (severity-level of alarm) will be 0.3, corresponding to the highest violation of the nominal values. 4. In the forth case, the Rotation Voltage is outside the acceptable values. The membership value of this variable will be 1 and therefore the firing level is 1 which causes the alarm severity level to be 1 (critical alarm). 5. In the fifth case, the Set Points do not correspond to any Scenario Set Points, so no rule is triggered and the result of the inference is zero. This means that we have no information and by default there is no alarm. Figure 5 shows the graphical representation of these five cases. Impact on operational mode. Detecting critical or noncritical deviations with respect to the nominal operational mode of a drill allows obviously to take actions that can prevent dramatic failure. If the deviation remains within acceptable range (cases 2 and 3), operations could go on while special telemetry is send to the ground station and history of non-critical deviation is recorded that could allow computation of mileage for the drill. Next time such non-critical violation of nominal operation happens, decision could be made to stop the operations because the mileage of the drill has reached a certain level. If the deviation exceeds acceptable range (case 4), operation could be stopped before the drill experiences dramatic failure. This clearly ensures safety of the drill and allows therefore more drilling operations in the long term.

Translation Voltage

Translation Current

Translation Speed

Case 1 membership value Case 2 membership value Case 3 membership value Case 4 membership value Case 5 membership value

20 1 20 1 20 1 20 1 0 0

23 1 2.3 1 2.3 1 2.3 1 0 0

125 1 125 1 125 1 125 1 0 0

22 0 39 0.3 39 0.3 22 0 22 -

18.2 0 18.2 0.3 19.9 0.1 20.4 1 18.2 -

0.44 0 0.44 0 0.44 0 0.44 0 0.44 -

122 0 122 0 122 0 122 0 122 -

1.55 0 1.55 0 1.55 0 1.55 0 1.55 -

0.039 0 0.039 0 0.039 0 0.039 0 0.039 -

Table 3 - Input values and their membership value (firing levels) The results of the inference for the test cases are: 1. In the first case, the output will have a severity-level of 0 (i.e there is no alarm) because, for the scenario triggered, the nominal values are all ok (membership values of 0). The sensors values indicate that all is working as expected in a nominal situation. 2. In the second case of the table, a variable variation was introduced. The value 39 in the Thrust variable corresponds to a value that is not nominal but it is still an acceptable value. The output will be 0.3, i.e. small severity level in the alarm. 3. The third case of the table, the Rotation Voltage also varies. In this situation, the values of Thrust and Rotation Voltage are not nominal but are both in acceptable range.

TranslationSpeed 2.2 95 0 2.2 95 0 2.2 95 0 2.2 95 0 2.2 95 -

Rotation Voltage

Rotation Current

Rotation Speed

Rotation Speed

Terrain

Thrust

Detection of terrain type
We showed previously how, given three set points (terrain and translational and rotational speeds), we can detect deviations of the variables with respect to nominal operation. These deviations may be related to degradation of components of the drilling system, this is why action should be taken in this case to record the deviation (if noncritical) or to stop operations. But the deviations may also be related to one of the set points violating their supposed value. The rotational and translational speeds are maintained by robotic controllers. We can therefore


assume that any violation of one of these two values be reported by the controllers. But the terrain could be different than the expected one. It could be either one of the known terrains or even an unknown type of terrain. In both cases, the output variables of MODI will deviate from their nominal values. Proposed methodology. If the terrain is one of the known terrains, the values of the output variables of MODI should fit the nominal values for this known terrain. A search in the space of all known terrains and sub-scenarios should therefore allow matching the whole set of input variables (set points and variables). If no matching set is found, then the terrain is most likely unknown. By considering the terrain hardness as an output variable and adding inference rules related to terrain hardness, the MODI tool could include a terrain recognition capability: the terrain being drilled could be categorised either as one of the known terrains or as unknown terrain. Impact on operational mode. In case the terrain detection module indicates that the terrain currently being drilled is different than the one expected but known, decision can be made either to proceed with the drilling operation but recording the change in terrain type; or to stop the drilling operation in order to start a new one on another terrain. The decision is obviously related to the scientific goals of the mission and can be made on board or by operators on ground, depending on the decision making capability of the rover.

References
[1] Morris, P.; Muscettola, N.; and Vidal, T. 2001. Dynamic control of plans with temporal uncertainty. In Proc. of IJCAI-01, 494­502. [2] Tsamardinos, I.; Pollack, M. E.; and Ramakrishnan, S. 2003. Assessing the probability of legal execution of plans with temporal uncertainty. In Proc. of ICAPS'03 Workshop on Planning Under Uncertainty and Incomplete Information. [3] John Stedl and Brian C. Williams, A Fast Incremental Dynamic Controllability Algorithm, Proceedings of the ICAPS Workshop on Plan Execution, Monterey, CA, June 2005. [4] M. Fox and D. Long. On-board Timeline Validation and Repair: A Feasibility Study, Proceedings of the International Workshop on Plan and Scheduling for Space, Baltimore, October 2006. [5] B. R. Santos, P. T. Fonseca, M. Barata, R. A. Ribeiro, P. Sousa. New Data preparation process ­ A case study for an ExoMars Drill. Proceedings of the World Automation Congress (WAC2006), Hungary, July 2006. [6] R. A. Ribeiro. Application of fuzzy logic in space monitoring and fault detection problems. Proceedings of the Joint Workshop on Decision Support Systems, Experimental Economics & e-Participation. Graz, Austria, June 2005. [7] A.Pereira, F. Moura-Pires, R. A. Ribeiro, L. Correia, N. Viana, F. J. Varas, G. Mantovani, P. Bargellini, R. PerezBonilla, A. Donati. Fuzzy expert system for gyroscope fault detection. Proceedings of the 16th European Simulation Multiconference, Artificial Intelligence and Neural Network Track, 3-5 June, Darmstadt, Germany 2002. [8] P. Magnani, A. Ercoli Finzi, A.Olivieri, The sampre drill and distribution subsystem of the rosetta lander, Galileo Avionica. [9] Mendel, J. M. Uncertainty rule-based fuzzy logic systems ­iIntroduction and new directions, Prentice-Hall PTR, 2001. [10] Cios, K.J., W. Pedrycz, R. Awiniarski. Data mining methods for knowledge discovery, Kluwer Academic, Boston 1998.

Conclusion
In this paper we have first presented the concept of Monitoring & Diagnosis techniques for remote systems within the context of robotic Martian exploration. Then we have shown how the MODI project is aiming at monitoring and diagnosing a drilling and sampling system for Martian exploration rover, and explained how MODI implements a fuzzy inference system to monitor and diagnose a drill. Last, we have presented the preliminary test results of MODI and demonstrated that MODI allows monitoring mileage of the drill and preventing potential dramatic failures, hence extending the drilling operations capability of a Martian rover in the long term. This technology must be enhanced and extended to unmanned exploration units as well as the control units of manned space vehicles and habitats so that they are able to avoid failures and optimise resources by monitoring their own evolving behaviour, detecting subtle deviations over time. Expected failures will then be avoided through re-planning of activities, leading to longer-term availability of space systems.