Implementation and Flight Testing of an Onboard Architecture for ...

Implementation and Flight Testing of an Onboard Architecture for Mission Supervision

Implementation and Flight Testing of an Onboard Architecture for Mission Supervision

M. Barbier, J.F. Gabard, J.H. Llareus, C. Tessier * J.Caron, H. Fortrye, L. Gadeau, G. Peiller ** * ONERA/DCSD ** EADS DS SA {Magali.Barbier, Jean-Francois.Gabard, Jean-Henri.Llareus, Catherine.Tessier}@onera.fr {Jean.Caron, Herve.Fortrye, Lionel.Gadeau, Gerard.Peiller}@eads.com

ABSTRACT The paper focuses on a new onboard architecture that is implemented and tested on a light plane that is representative of an Extended Range Multi Purpose UAV. The hardware architecture simulates a generic UAV control architecture: a control computer processes telemetry and decision frames and a decision computer performs mission management. The decision software is based on an environment meant for controlling and monitoring highly autonomous systems. The behaviour of the UAV is modelled using interpreted Petri nets: the UAV follows the different phases of a flight plan prepared offline by the operator; when disruptive events modify the current plan, alternative reactions are encoded, either through Petri nets or specific subsystem software. Several interfaces are required for the connection of the various components. Lab, simulation and ground tests have validated frame transmission in both directions; asynchronous events received during the nominal scenario allows the good supervision of the flight plan; disruptive events occurring in representative non-nominal scenarios illustrate the good replanning capabilities.

BIOGRAPHY ONERA authors are research scientists in the Decision and Control Unit of the System Control and Flight Dynamics Department. Dr. Magali Barbier’s research focuses on the development of autonomous software in aerial and sub-marine onboard decisional architectures. Jean-François Gabard is the head of the Unit; his work deals with mission management system supervision using Petri net-based techniques. Pr. Jean-Henri Llareus works on onboard system architecture and implementation. Dr. Catherine Tessier’s work focuses on situation assessment, decision and co-operation in highly autonomous air and space vehicles. For EADS, Jean Caron is Program Manager for uninhabited intelligence systems at EADS Defense & Security Systems. In the engineering and integration department, Hervé Fortrye is an engineer working on ground segment software, Lionel Gadeau is a system integration engineer and Gérard Peiller is a specialist engineer for mission aircraft and airborne platform definition and integration and flight operational aspects.

21st Bristol UAV Systems Conference – April 2006

Implementation and Flight Testing of an Onboard Architecture for Mission Supervision

Introduction Onboard decision capabilities allow an uninhabited vehicle to reach mission objectives taking into account disruptive events. This decisional autonomy is necessary when the vehicle manoeuvres in a partially known and dynamic environment. Research on autonomy is performed for ground robots, Uninhabited Aerial Vehicles (UAVs), Autonomous Underwater Vehicles (AUVs) and space vehicles. Autonomy is characterised by the level of interaction between the vehicle and the human operator: the higher level the operator’s decisions are, the more autonomous the vehicle is. Between teleoperation (no autonomy) and full autonomy (no operator intervention), there are several ways to allow a system to control its own behaviour during the mission (1). One way to make the vehicle autonomous is to implement onboard decisional capabilities to allow the vehicle to perform the mission even when the initial plan prepared offline is no more valid. Decision capabilities, which guaranty the adaptability of the vehicle, must be implemented within the closed loop architecture {perception, situation assessment, decision, and action}. The architecture is dedicated to mission supervision including autonomous response to disruptive events. The capability to deal with environmental information and to assess its current state is also essential for the vehicle to assure its own safety. EADS and ONERA are involved in a national project that aims at testing a new architecture designed for mission supervision in a UAV and demonstrating the relevance of such architectures in future uninhabited vehicles. As all categories of UAVs have to perform their missions in complex environments with the same types of constraints, the embedded architecture has to be generic, i.e. not dedicated to a given mission, environment or vehicle. As the mission may be disrupted by internal or external events, e.g. failures, weather situation, interfering aircraft, threats, onboard plan monitoring and replanning are required in order to deal with nominal or disruptive events, avoid systematic return to base and proceed with the mission as well as possible given the new constraints. The first section of the paper focuses on the hardware architecture installed on a light plane for experiments. The software decisional architecture is described in the second section. Interfaces

21st Bristol UAV Systems Conference – April 2006

implemented onboard are dealt with in the third section. Several types of tests were conducted to validate the global architecture, they are presented in the fourth section.

1. Hardware architecture Experiments are conducted on a light plane, a Dyn’Aero MCR-4S (Figure 1). This plane is representative of an Extended Range Multi Purpose UAV (medium altitude, persistent Intelligence, Surveillance and Reconnaissance vehicle). MCR-4S characteristics are: length 6.7m, span 8.7m, wing surface 8.3m2, overall height 1.95m, max speed 320km/h. Its spacious cabin allows the implementation of project-dedicated hardware components.

Figure 1 – Light plane used for experiments The 4-seat plane has been modified to receive two computers (Figure 2), one devoted to the control part and the other devoted to the decision part, i.e. mission management. The GFC450 computer manages frame connection with plane sensors and actuators (e.g. the automatic pilot) and with the ground station. Indeed, two computers are required for the control function in order to guarantee real-time reactions at the GFC level. Telemetry frames are composed of eight blocks: communication (state of the other blocks), piloting (modes, commands…), sensors, GPS sensor, camera payload, other mission payloads, navigation (cruise control) and events. Telemetry frames are emitted every 20ms. The control frame includes a decision block and an operator block. On the ground, one computer allows the operator to send mission data to the vehicle and to monitor the mission, and another one is dedicated to the validation of frame content and emission.

Implementation and Flight Testing of an Onboard Architecture for Mission Supervision

. ONBOARD TCP/IP

Control computer

.

Decision computer

.

RS232

nominal mission monitoring and control (vehicle and payload control actions); decision (management of disruptive events, replanning).

These functions, which are often developed as separate subsystems, have to co-operate in order to fulfil the autonomous system behaviour requirements for the specified missions. More precisely, the needs are the following:

GFC450

.

GROUND

Validation computer

data analysis (sensor data, monitoring data, operator’s inputs);

Mission computer

Figure 2 – Hardware architecture The hardware architecture includes all the components that are necessary to perform the mission thus simulating a generic UAV control architecture. In order to perform flight tests rapidly and avoid a heavy flight authorisation process, a pilot onboard closes the autonomous loop: the orders calculated by the decision architecture are actually executed by the pilot on the plane actuators.

2. Decisional software architecture The decision architecture, called Mission and Flight Execution Control (MFEC), is implemented in the decision computer and based on the ProCoSA software (2).

.

off-line tasks: specification of the co-operation procedures between subsystem software, subsystem coding for embedded operation; on-line tasks: procedure monitoring, event monitoring, and management of the dialog with the operator. ProCoSA includes the following components:

. .

.

EdiPet, a graphical interface for Petri nets which is used both by the developer for procedure design and by the operator for execution monitoring (Figure 3); JdP, the Petri net player, which executes the procedures, fires the event-triggered transitions of the Petri nets and synchronises the activation of the associated functions; a socket-based communication protocol allows data to be exchanged with external subsystem software; Tiny, a Lisp interpreter specially dedicated to distributed embedded applications.

The following subsections present ProCoSA, the hierarchical organisation of the supervisor model, the different kinds of events taken into account by the supervisor and their classification, the nominal mission scenario of the UAV and the non-nominal scenarios that modify the initial plan when disruptive events occur; some examples of Petri nets (see annex) modelling the procedures are given.

2.1.

ProCoSA

ProCoSA is a software environment meant for controlling and monitoring highly autonomous systems. System autonomy is usually obtained by putting together various functions, among which:

21st Bristol UAV Systems Conference – April 2006

Figure 3 – EdiPet graphical interface

Implementation and Flight Testing of an Onboard Architecture for Mission Supervision The Petri nets used by ProCoSA are interpreted Petri nets (see annex): triggering events and activation or event generation requests are attached to the transitions. Special places, called “global places”, have been introduced in order to ease synchronisation between nets while preserving modularity: a global place is “shared” between different nets, thus enabling a behaviour modelled by a given net to take into account a state of the system modelled in another net; this feature is particularly suitable for handling disruptive events. Finally, timers can be programmed with ProCoSA: a special activation request enables a timer variable to be instantiated, which allows actions with a limited duration to be modelled. The ProCoSA procedures are used to model the desired behaviours of the autonomous system; the hierarchical modelling features offered by ProCoSA enable to structure the whole application in a generic way: at the highest description level, generic behaviours can be described, regardless of the characteristics of a given vehicle; at the lowest level, they specify the sequences of elementary actions to be performed by the vehicle or the payloads; this modular approach enables a quick adaptation to system changes (e.g. taking into account a new payload). An important feature of ProCoSA lies in the fact that there is no code translation step between the Petri net procedures and their execution: they are directly interpreted by the Petri net player, thus avoiding any supplementary error causes. ProCoSA finally includes a verification tool, which makes use of the Petri net analysis techniques to check that some “good” properties are satisfied by the procedures, both at the single procedure level and at the whole project level (that is to say taking into account inter-net connections); the following properties are checked:

. . .

place safety (not more than one token per Petri net place); detection of dead markings (deadlocks); detection of cyclic firing sequences (loops).

2.2. Hierarchy of the supervision procedures A four-level architecture was defined in order to guarantee a generic approach:

.

level 0: initialisation of the communication protocols between ProCoSA and the other software layers (see section 3);

21st Bristol UAV Systems Conference – April 2006

. . .

level 1: global state of the mission and disruptive event handling; level 2: main nominal phases of the mission; level 3: sub-phases of the mission.

Level 3 corresponds to less generic procedures (i.e. more specific to the vehicle type or to mission and payload characteristics), with an exception for the handling of disruptive events, which was put at level 1.

2.3. Classification of asynchronous events Two kinds of events have to be distinguished: nominal events corresponding to the pre or post conditions associated with the flight phases and disruptive events that may occur anytime during the flight. 2.3.1.

Nominal events

Nominal events are expected at each beginning or end of a flight phase, e.g. takeoff, climb, cruise... and are associated with the transitions of the phase Petri nets (levels 2 and 3). Plan monitoring within the MFEC rests on these events to check the nominal progress of the flight. A nominal event is a logical condition - a combination of ANDs and ORs - on the values of parameters coming from the telemetry frame every 20ms. Example: the end of the climb phase is characterised by event : Frame_OK AND Altitude > Alt1 AND Camera_OK with Altitude > Alt1: (sensor_block OK AND Altitude_parameter OK AND Altitude_measure > Alt1) OR (sensor_block notOK AND GPS_block OK AND GPSAltitude_parameter OK AND GPSAltitude_measure > Alt1), meaning that the altitude is checked with the measure of the sensor_Block unless this block has failed, in which case the GPS_block is used. 2.3.2.

Disruptive events

Many kinds of disruptive events may occur during a mission: vehicle or payload events (e.g. failures), environment events (e.g. weather situation, other agents). A subset of possible disruptive events has to be defined so as to design appropriate reactions and replanning within the MFEC: what are unknown are not the events themselves but whether they will occur or not and when they will occur. Indeed, it is practically impossible to predict and plan all possible events (3).

Implementation and Flight Testing of an Onboard Architecture for Mission Supervision A disruptive event is also a logical condition on the values of parameters coming from the telemetry frame every 20ms. Example: (Frame_OK AND sensor_block OK AND RPM_parameter OK AND RPM_measure < N) OR (Frame_OK AND pilot_block OK AND EngineOff = true) is the event corresponding to an engine failure, with RPM the rotation speed of the engine. In order to have a generic approach to deal with disruptive events (i.e. avoid designing one dedicated processing per event and allow for multiple event processing), they have been classified according to their impacts on the mission:

.

catastrophic events lead to mission abortion. They cannot be recovered and the reaction amounts to make the UAV land as smoothly as possible. When such an event occurs, the processing of any other kind of events is aborted and no further incoming event can be processed. Example: engine total failure.

.

safety-related events lead to modifying the flight profile or the flight plan - e.g. change route for a while - which may induce delays or new constraints on the use of the payload.

When the nominal end-of-phase event occurs, the marking evolves to the next phase of the mission. If a disruptive event occurs, the appropriate reaction is triggered and the marking evolves to the state corresponding to the reaction.

2.4.

Nominal scenario

The nominal mission is represented by levels 2 and level 3 ProCoSA Petri nets allowing the nominal activities of the UAV to be monitored onboard. The situation is replicated for the ground operators through the EdiPet interface of ProCoSA. 2.4.1.

Main mission phases

The main mission phases are modelled by the Level_2 Petri net (Figure 4), from vehicle preparation tasks before takeoff to data collection after landing; some places (e.g. P11_approach) are associated with elementary states, and other ones (e.g. P9_operation) to macro states, which means that their activation launches the execution of a level 3 Petri net, thus expanding this macro state in further elementary states; some “global” places can also be observed on this network (e.g. P9_operation), which means that they will appear in other Petri nets.

Examples: interfering aircraft, new forbidden area, turbulence...

.

mission-related events only have consequences on the mission itself. Replanning amounts to adapt the mission to the new constraints, e.g. remove waypoints.

Examples: camera failure, violated temporal constraint, new mission goal...

.

communication-related events are related to communication breakdowns between the UAV and the ground. Such events result in the UAV being fully “autonomous” therefore it has to proceed with the mission as planned. Example: telemetry failure. 2.3.3.

Event handling

The basic principle is that nominal and disruptive events are expected in the same way: as the current state of the UAV within the mission corresponds to a marking of the Petri nets (e.g. the places corresponding to the ongoing flight phase are marked), the transitions validated by the marked places correspond to all the events that are expected, namely the nominal end-of-phase events and the disruptive events that are likely to occur during the phase.

21st Bristol UAV Systems Conference – April 2006

Figure 4 – Level 2 Petri net

Implementation and Flight Testing of an Onboard Architecture for Mission Supervision Two kinds of events are associated with the transitions of the level 2 Petri net:

. .

nominal events that are associated with a transition following a place representing an elementary state; inter-net synchronisation events that are associated with a transition following a place representing a macro state: those events are emitted by the last transition of the level 3 nets expanding the macro states.

As far as the activation requests are concerned, they also belong to two categories:

. .

net activation request that are associated with a transition followed by a place representing a macro state; event generation requests are associated with the last transition of the network: this event is meant for the level 1 network that models the global state of the mission.

We can notice that no software subsystem activation request appears at this level, which is a generic level. 2.4.2.

Detailed operation phases

For the sake of generality, a flight plan is defined by a mission area where the vehicle follows an ordered set of legs: “payload legs” are relative to mission objective fulfilment and “transit legs” are required between two subsequent “payload legs”. The Level_3_operation net (Figure 5) models the desired behaviour of the UAV within the operation area; this net clearly shows the looped structure enabling the set of pre-programmed legs to be achieved; in comparison with level 2 Petri net, it includes the additional features:

.

.

communication requests to the operator, in order to ask for the operator’s validation after the execution of a payload leg or at the end of the operation phase; ProCoSA timers are used to limit the time allowed for the operator’s answer; software subsystem activation requests are used for waypoints management (e.g.: getting the next waypoint depending on the operator’s decision).

21st Bristol UAV Systems Conference – April 2006

Figure 5 – Level 3 operation Petri net

2.5.

Non-nominal scenarios

This section describes how disruptive events are taken into account by the supervision architecture; the following steps are achieved when a disruptive event occurs:

. .

the level 1 Petri net in charge of global mission monitoring is warned of the non-nominal state of the mission, and the current state is memorised till the possible return to the nominal state; one of the level 1 Petri net dedicated to the disruptive event types is activated; these nets, which are organised according to the generic classification presented in section 2.3, use the “global place” feature offered by ProCoSA to adapt the reconfiguration actions to the current state of the mission; this reconfiguration process is achieved through software subsystem activation requests, which enable to build a set of control orders to be sent to the control computer.

Implementation and Flight Testing of an Onboard Architecture for Mission Supervision The Level_1_catastrophic_events Petri net shown on Figure 6 deals with engine total failure event; this net shows how the set of control orders is generated as a sequence of elementary orders, depending on the current state of the mission (engine failure case): if the engine failure occurs during the initial climbing phase (global place P6_climb active), the remaining capabilities of the UAV will be used to lead it towards the takeoff airfield; if it occurs later during the mission, an activation request of a software subsystem function is used in order to select the closest emergency landing area.

subsystem software

interface software

JdP Petri Player

connection

event processing

Petri nets

decision computation

environment database

EdiPet

frame receipt

frames

ProCoSA

control computer

decision computer

frame emission

mission database

UAV database

dialog windows

Figure 7 – Software architecture implementation

3.2.

Subsystem software layer

The subsystem software layer includes all the software relative to decision making and data updating. Subsystem software has been implemented in C language. The connection subsystem controls the connection of the decision computer with the control computer via the interface software. It filters events received from the interface and triggers associated transitions of the Petri nets. The decision computation subsystem has several functions: Figure 6 – Level 1 catastrophic events Petri net

3. Implementation The MFEC architecture has been implemented in three layers (Figure 7). The ProCoSA layer is generic whereas the interface software layer is dedicated to the UAV.

3.1.

. . .

ProCoSA layer

The ProCoSA layer includes the Petri net player (cf. section 2.1) and the Petri nets modelling the nominal and non-nominal scenarios (cf. sections 2.4 and 2.5).

.

it registers the current plan as a list of payload legs and transit legs and sends the relevant next leg to the Petri net player; it monitors the UAV trajectory and checks the arrival at the waypoints (situation assessment function); it computes decisions (e.g. the way to avoid an interfering aircraft) and the replanning of legs (e.g. which legs have to be cancelled after a payload failure); it may send requests to the operator regarding leg execution.

3.3.

Interface software layer

The interface software layer connects ProCoSA with the UAV through the control computer (and the pilot for flight tests). It computes expected nominal and disruptive events from the telemetry data and send event references to ProCoSA layers. This process can

21st Bristol UAV Systems Conference – April 2006

Implementation and Flight Testing of an Onboard Architecture for Mission Supervision be compared to the Event Detection Assistant and Complex Event Recognition Architecture in (4).

Place 2: Pre-flight tests

Interface software has been written in C++ language using the Visual C++ application framework. Two interfaces may be used by an operator to check mission execution online:

.

Computer

UAV status

Payloads status

the EdiPet graphical interface that shows the state evolution (Petri net marking);

.

Mission onboard

specific dialog windows dedicated to telemetry data and event monitoring.

The TCP-IP frame receipt interface periodically receives telemetry frames from the control computer. Data are registered in buffers in order to separate receipt and processing. The event-processing interface elaborates expected nominal and disruptive events from the frames and sends them to ProCoSA. A list of the UAV parameters is used for value checking, i.e. values are not encoded within the events, which makes event elaboration generic. The event dialog window is shown in Figure 8. Each event is relative to a specific level in the Petri net hierarchy. A particular event-processing window is shown in Figure 9 for the end-pre-flight tests event, which is expected at the beginning of the mission. The frame emission interface receives decisions and operator’s inputs from the decision computation software and asynchronously sends consistent control frames to the control computer. Frame Events

Level 2 : Pre-flight, Transit, Approach and Landing Phases

Level 3 : Operation Phase

Level 3 : Standing Phase

Emission of End-Pre-Flight Tests Event

Figure 9 – An event-processing window

4. Tests 4.1.

ProCoSA layer tests

The properties of the implemented Petri nets have been checked with ProCoSA verification tool (cf. section 2.1). All places are safe and there is no cyclic firing sequence. Several dead markings were detected, which is consistent with the associated situations defined in experimental scenarios. Indeed, reactions to events have been implemented only for some of the phases: when a disruptive event occurs in another phase, the Petri net associated with the processing of this event is blocked in a final marking. This analysis points out that, in order to build a generic architecture, not only a classification of disruptive events is necessary, but also the associated reactions have to be modelled for all possible UAV behaviours. Some default reactions could also be modelled, which would be triggered by the timer function of ProCoSA that can limit the response time to the occurrence of an event at a given transition.

Level 3 : Climb Phases

Level 3 : Roll Phase

Level 3 : Stop Phase

Level 3 : Takeoff Phase

Figure 8 – The event dialog window

The Petri nets modelling the nominal scenario have been validated by emulating the occurrence of nominal events. The non-nominal scenarios described in section 2.5 have also been validated in the same way, by emulating the occurrence of disruptive events in the phases when a reaction has been modelled.

4.2.

Lab tests

Lab tests have been conducted to validate the frame transmission between the different components of the decision and control computers. The whole connection has been validated in both directions.

21st Bristol UAV Systems Conference – April 2006

Implementation and Flight Testing of an Onboard Architecture for Mission Supervision Software was developed to simulate the emission of telemetry frames from the control computer. Tests have validated the frame transmission between the control and the decision computers, their decoding and visualisation on a dialog window, the emission of events towards ProCoSA Petri net player and the triggering of adequate transitions in the Petri nets. The simulator has also been used to check the correct receipt of control frames by the UAV and the operator.

4.3.

Ground and flight tests

Two series of field tests are planned in March and May 2006. A test series will be organised as a two-step process: during the first week, ground tests will be conducted, in order to prepare and simulate the scenarios which will be run on the plane; flight tests will be conducted during the second week, with a pilot and an operator onboard the plane. The nominal scenario will be tested first. Nonnominal scenarios implying a unique disruptive event will be considered afterwards, and eventually scenarios including two or three cumulative disruptive events. A double check process will be achieved during each flight test: flight data (telemetry frames) and the corresponding Petri net states will be registered onboard, and the ProCoSA layer of the MFEC will be duplicated on the ground station which will also receive the real-time telemetry frames, thus enabling the system state to be monitored on the ground.

5. Conclusion and perspectives UAV missions are often unsupervised long missions, and it is difficult to deal with environmental uncertainties. The architecture we have presented allows automatic re-planning with respect to real environmental, UAV and operator data collected during the mission and to safety constraints. The UAV can thus feature autonomous behaviours even in case of communication failure. This asynchronous modular architecture has been designed as generic as possible: the definition of the mission is not dedicated to a specific UAV in a specific environment, the classification of disruptive events allows the processing of generic reactions, reactions are coded within independent subsystem software and UAV parameters are not encoded in event processing. The specificity of the UAV is considered in databases and in the interfaces connected to the control computer.

21st Bristol UAV Systems Conference – April 2006

Simulation tests highlight the robustness of the decisional architecture, which is due to Petri net modelling and associated analysis techniques. The nominal scenario is monitored correctly, and correct reactions to disruptive events have been validated. Ground tests have validated the global transmission of frames in both directions, i.e. for telemetry frames and control and operator frames. Current results point out several possible ways of improvement:

. .

.

. . . .

Reactions to each type of disruptive events have to be designed for all mission phases. The planning algorithm developed in the architecture is very basic. An enhanced planning algorithm could be implemented in the subsystem software with the optimisation of the order of the legs, the selection of the payload legs, the optimisation of the transit legs (according to fuel consumption, dates and other constraints). This planning algorithm could also be implemented in the operator’s mission preparation tool. For a real mission, all possible communications between the ground operator and the UAV have to be defined properly, especially the operator’s decisions sent to the UAV and the associated reactions onboard; this communication link gives the UAV its level of autonomy. An onboard architecture adapting its autonomy level according to the occurring of disruptive events could also be considered. Most of the tests concern cruise phases. For several types of UAVs or missions, automatic takeoff and landing are required, which needs further analyses. A situation assessment subsystem that estimates the parameters of the system and predicts their evolution could help to anticipate the arrival of disruptive events. The decision loop is closed by the pilot onboard. The next flight tests will be autonomous tests with the execution of the decision architecture controls sent directly to the plane actuators. As far as the certification process is concerned, the design of the reactive behaviours to disruptive events (like an interfering aircraft) will have to be specified in a total accordance with the rules of the air.

The decisional architecture could be used for other types of autonomous vehicles. As an example, similar sea tests are going on for the supervision of an

Implementation and Flight Testing of an Onboard Architecture for Mission Supervision AUV (5). Civil applications could also integrate this type of architecture. The collaboration of two or more UAVs to execute a mission is also considered.

Acknowledgements The authors want to thank DGA/SPNuM (“Délégation Générale pour l’Armement / Service des Programmes Nucléaires et de Missiles”, defence procurement agency of the French Defence Ministry / management of missile system and associated resources) for their funding support.

References (1)

(2) (3)

(4)

(5)

(6)

Clough, B.T. Metrics, Schmetrics ! How the heck do you determine a UAV’s autonomy anyway ? Performance Metrics for Intelligent Systems Workshop. Gaithersburg, MA, USA, 2002. http://www.cert.fr/dcsd/cd/PROCOSA Hamilton K., Lane D., Taylor N. and Brown K. Fault diagnosis on autonomous robotic vehicles with RECOVERY: an integrated heterogeneous-knowledge approach. ICRA 2001, IEEE International Conference on Robotics and Automation, Seoul, Korea 2001. Schreckenghost D., Thronesbery C. and Hudson M.B. Situation awareness of onboard system autonomy. i-SAIRAS 2005, 8th International Symposium on Artificial Intelligence, Robotics and Automation in Space, Munich, Germany, September 2005. Dabe F., Ayreault H., Barbier M., Nicolas S. Goal Driven Planning and Adaptivity for AUVs, UUST 05 Unmanned Untethered Submersible Technology, 21-24 août 2005, Durham, New Hampshire USA. Murata, T. (1989). Petri nets: properties, analysis and applications. IEEE. 77(4), 541580.

Annex : a Petri net reminder A Petri net (6) is a bipartite graph with two types of nodes: P is a finite set of places; T is a finite set of transitions. Arcs are directed and represent the forward incidence function F : P × T → /N and the backward incidence function B : P × T → /N respectively. The marking of a Petri net is defined as a function from P→ /N: tokens are associated with places. The evolution of tokens within the net follows transition firing rules. Petri nets allow sequencing, parallelism and synchronisation to be easily represented. An interpreted Petri net is such

21st Bristol UAV Systems Conference – April 2006

that conditions and events are associated with transitions.