resource driven planning with plasma: a plan space multi

ESA UNCLASSIFIED – For Official Use

Resource Driven Planning with PLASMA: a PLAn Space Multi-solver Application

Andrea De Maio1, Simone Fratini2, Nicola Policella2, Alessandro Donati2

(1) “La Sapienza” University of Rome, Italy(2) European Space Operations Centre, ESA-ESOC

Wednesday 13th May 2015

PLAn Space Multisolver Application | Andrea De Maio | ASTRA 2015 | 13/05/2015 | Slide 2


Motivations

• Resources as driving factor for most realistic planning process

• Planning for achieving goal on resources availability and not only

planning for tasks that require resources

• Need for accurate resource models

• Planning resource boundaries not to rely only on the “worst case”

when safety conditions are requested

• Flexibility to entail plan execution and monitoring



Background – The APSI Framework

Timeline Based

Modeling Engine

& Planning/Scheduling

General ServicesPlatform

Domain

Description

Language

Platform

Timeline

Description

Language

Current Plan

Tim

eline

Execution

Serv

ices

Platform Timeline

Representation APIs

Platform Visualization

Tools APIs

Pla

tfo

rm A

PIs

Fo

r E

xecu

tio

n

Execu

tor

HCI & MI Services

KE E

nvi

ronm

ent

Problem Solving

V&V Tools

http://upload.wikimedia.org/wikipedia/commons/4/46/ExoMars_model_at_ILA_2006.jpg



Background – The GOAC Framework

Deliberative Layer - APSI Executive Agent - GOAC

GOACGOAL ORIENTED AUTONOMOUS CONTROLLER

Functional Layer

TeleCommands

Telemetry

http://upload.wikimedia.org/wikipedia/commons/4/46/ExoMars_model_at_ILA_2006.jpg



PLASMA: PLAn Space Multi-solver Application

• PLASMA is developed following the ideas of:

Least Commitment (list all actions that need to be taken, but

specify an ordering of the actions only where necessary)

Flaw-Based Solving Process (identify issues and solve them)

• APSI on its side provides:

Flexible Plan & Schedule representation

State Variables and Resources modelling

Domain and Problem representation language (DDL.4)



Partial Order Planning (POP)

• Partial Order Planning (POP) is a well established approach in

Automated Planning

• Its most important features are:

Plan Space based

Partially Ordered

Flaw Oriented

MEX.point_NAD()

HRSC.science(?p2)

PFS.science(?p1)SPICAM.science(?p3)

Point_FIX()

Point_NAD()

Point_NAD()



Partial Order Schedule (POS)

• Given a scheduling problem a Partial Order Schedule (POS) is a set of

solutions that can be represented as a temporal graph

o Any time feasible schedule defined in the graph is also a resource feasible schedule

o Originally the POS concept was introduced to cope with uncertainty and provide robust solutions.

• Here the POS is used thanks to its ability of accommodating possible

changes introduced by the planner without loss of consistency (or, in

the worst case, by minimizing the impact).



Problem Solving: Main Steps

Plan Update

Timeline

Extraction

Flaws

Collection

Flaw Choice

Flaw Resolution



Plan

Application Architecture

DDL.4 Parser

.ddl

.pdl

Domain Theory

+Problem

Application class

Flaws

usesSolver

PLASMA

APSI Plan Database

Query

Updates



Timeline Flaws

1. Timeline Scheduling Flaw

2. Resource Overflow/Underflow Flaw

3. Subgoal Flaw

4. Timeline Gap Flaw

PL.Running(exp_1) <UNDECIDED> PL.Running(exp_2)

MT.RunExperiment(10,20, exp1) MS.At(10,20)requires

max

O

PL.Idle() <UNDECIDED> PL.Idle() <UNDECIDED>

PL.Running(exp_1)

min

O



Reservoir Linear Resources

• A Reservoir Linear Resource has a min and max capacity

• Each activity has a slope representing the consumed units of resource

per time instant

• The resource value is computed summing up the slopes of ongoing

activities

min

O

max

a1 t

P

a2 a3

(t) nttime_insta

(u) unitsslope



Resource Boundaries

• Plan flexibility entails different possible durations for resource activities

• Upper and lower bounds can be

shrank to fulfil resource boundaries

• This does not always solve the problem

• Addition of a compensating activity

(i.e. productions) may be necessary



Consumption

Managing Linear Reservoir via MaxFlow

• Input timeline

o Flexible start-time and duration

o Fixed data slope

o Min/max resource requirements

P Time, Duration | MTL | MS | PLD | CZN | BAT-------------------------------------------------------------------------------------------------------------------------------------------------------------------0 [00.000.00.54.00,00.000.01.19.00] [9,15] | | | | Charging | [0.0,0.0,2.0]1 [00.000.01.03.00,00.000.01.28.00] [0,25] | | | | | [18.0,30.0,0.0]2 [00.000.01.03.00,00.000.01.28.00] [1,20] | | GoTo(10,25) | | | [18.0,30.0,-0.05]3 [00.000.01.04.00,00.000.01.29.00] [0,25] | | At(10,25) | | | [17.0,29.95,0.0]4 [00.000.01.04.00,00.000.01.29.00] [10,10] | RunExperiment | | Running | | [17.0,29.95,-2.0]

s

0 421

t

[18,30]

[0.05, 1] [20,20]

n

[0,40]

[0,40][0,40]

[0,40] [0,40]

Production

Max-flow (with Edge Demands) model:

If solution does not exist then the timeline is not consistent!Given a max-flow solution, the duration of each time interval can be computed by considering the different flows through the network.



Resource Requests

• We introduced a new feature named Resource Level Request to obtain

desiderated resource profiles

LevelRequest1 RESOURCE1.LEVEL(24, 40)

• It represents a request on the min and max values on a given resource

in a particular time instant

LevelRequest1 AT [100,100]

min

O

max

24

100 t

40P'

P



A Use Case: the Rover domain

• The domain models parts of a rover exploration mission

• 1 rover, carrying payload instruments, in charge of doing general

experiments and exploration

• The rover uses a battery shared between the payload and the mobility

system

• The battery is recharged through solar panels. Charging is possible in

limited areas and in given time windows (e.g. out of shadows)




At(?x, ?y)

Run_Experiment(?x, ?y, ?exp)

BATTERYCONS.(?u)

equals

Synchronizations

Transitions

Going_To(?x, ?y)

Idle()

Idle()

Running(?exp)

equals

during

equals

during

CZN.charge(?x,?y, ?flux)

CZN.none()CZN.charge

(?x, ?y, ?flux)CZN.char…CZN.none()

during

duringduring

BATTERYPROD.(?u)




MT.Idle()MT.Run_Experiment

(40, 60, „exp_1‟)MT.Idle() (…)

MS.At(40, 60) MS.Going_To(35, 10) (…)

PL.Idle()PL.Running(„exp_1‟)PL.Idle() (…)

during

Mission Timeline

Mobility System

CZN.charge(25, 10, min) CZN.none() CZN.charge(35, 10, max) (…)

Charging Windows

equals

Payload



Battery


during

ACTIVITY(f(?flux)) > 0 ACTIVITY(-0.05) REQUIREMENT(f(?exp)) (…)

MS.At(?x, ?y) MS.Going_To(?x, ?y) (…)

CZN.charge(?x, ?y, ?flux) CZN.none() (…)

PL.Idle() PL.Running(?exp)

Mobility System Payload

during

MS.At(?x, ?y)

(…)

equals

Charging Windows

equals



• The input is composed of a domain file (.ddl) and a problem file (.pdl)

• The domain models how the system works:

Application Input

COMP_TYPE STATE_VARIABLE MobilitySystemVALUES{

GoTo(coordinate, coordinate);At(coordinate, coordinate);

}TRANSITIONS{

At(?x1, ?y1) TO { GoTo(?x2, ?y2); }GoTo(?x1, ?y1) TO {

At(?x2, ?y2);?x1 = ?x2;?y1 = ?y2;

}}

SYNCHRONIZE BAT.tl{

VALUE ACTIVITY(?production){

[?production > 0];OP1 MS.tl.At(?x,?y);OP2 CZN.tl.Charge(?x,?y,?flux);DURING OP1;OP1 DURING OP2;?production := f_production(?flux);

}

}

COMPONENT Mission MTL { FLEXIBLE tl; }COMPONENT MobilitySystem MS { FLEXIBLE tl; }COMPONENT Payload PLD { FLEXIBLE tl; }COMPONENT Zones CZN { FIX_EST tl; }COMPONENT Battery BAT { FLEXIBLE tl(0.0,40.0,40.0); }



• The problem sets the initial state and the goals:

Application Input

MTL0 <fact> MTL.tl.Idle();MTL0 RELEASE [0,0];MS0 <fact> MS.tl.At(0,0);MS0 RELEASE [0,0];PL0 <fact> PLD.tl.Idle();PL0 RELEASE [0,0];

NOPROD1 <fact> CZN.tl.None();NOPROD1 RELEASE [0,0];NOPROD1 DEADLINE [10,10];PRODZONE1 <fact> CZN.tl.Charge(130,50,min);PRODZONE1 RELEASE [10,10];PRODZONE1 DEADLINE [30,30]; EXP1 <goal> MTL.tl.RunExperiment(?x1 =10,?y1 = 20,?e1 = exp_2);

EXP2 <goal> MTL.tl.RunExperiment(?x2 = 10,?y2 = 25, ?e2 = go_to_cave);

ATHOME <goal> MS.tl.At(?xh = 0, ?yh = 0);

EXP1 BEFORE ATHOME;EXP2 BEFORE ATHOME;



PLASMA Output

• The output is a set of flexible timelines fully specified on the temporal

horizon (plan)

• The plans respect all the constraints set by the user and never exceed

the resource boundaries

• If no solution exists for a given problem, it is detected and the user is

informed through a message



PLASMA Output



Conclusions

Improvement of the ESA-APSI Platform:

Modelling:

Linear Profile Resources

Goals on Resource Profiles

Problem Solving:

Boundary Reasoning on Resources

Flexible Schedules to protect against uncertainty in

execution

Guarantees Resource Availability, not only feasible

consumptions

PLASMA: A new planner that increases the integration of symbolic

planning with numerical reasoning


Thanks for the attention

Questions?

resource driven planning with plasma: a plan space multi

Documents