Planning and Scheduling of Crude Oil Distribution in a Petroleum Plant

Tiago Stegun Vaquero1,2 and Fernando Sette1 and José Reinaldo Silva1 and J. Christopher Beck2
1
Department of Mechatronics, Universidade de São Paulo, Brazil
2
Department of Mechanical & Industrial Engineering, University of Toronto, Canada
tiago.vaquero@poli.usp.br, fernando.sette@poli.usp.br, reinaldo@usp.br, jcb@mie.utoronto.ca

Abstract Due to the size and complexity of this real problem it is

necessary to use tools that provide support for the design
Most real planning problems require intense knowledge man-
process, producing a input-ready model for planners. De-
agement and reasoning about actions. These problems are
challenging not only to designers during knowledge engineer- signing the domain in PDDL (Fox and Long 2003) from
ing but also to automated planners during the planning pro- scratch would have proven extremely difficult and time con-
cess itself. In this paper we present experience and results suming. In this work we use the KE tool itSIMPLE (Vaquero
from designing a real planning application in the petroleum et al. 2007) for the initial phases of the design including re-
industry. We investigate the daily activities of a petroleum quirements acquisition, modeling, testing and plan analysis.
plant for docking, storing and distributing oil from a planning In itSIMPLE’s environment, the model is built using Unified
and scheduling perspective. Due to the complexity of this do- Modeling Language (UML) (OMG 2005), a general purpose
main, the KE tool itSIMPLE was used to support the design language broadly accepted in Software Engineering and Re-
process. The paper describes the construction of the domain quirements Engineering. A PDDL model is automatically
model and the experimental results while testing the gener-
generated from the UML representation to be read by a cho-
ated PDDL model with a modern planner. The experiments
consider two semi-realistic scenarios in order to evaluate the sen planner, in this case the SGPlan (Hsu et al. 2006).
approach. The design process described in this paper extends our
previous work on modeling this application (Sette et al.
2008) by developing a model that considers time constraints
Introduction and introducing quality-metrics for plan analysis. In addi-
Over the last twenty years, an increasing interest in applying tion, two semi-realistic study cases are investigated in order
AI planning has led researchers and industry to investigate to validate the resulting domain model.
such technology in real world domain. In fact, the recent This paper is structured as follows. First, we present the
efficiency improvement of planning systems and the devel- domain, its restrictions and requirements. Then we describe
opment of Knowledge Engineering (KE) tools have become the design process, focusing on the modeling process using
a great motivation to investigate and experience the real de- itSIMPLE. Next, we provide experimental results obtained
sign process of planning applications. From the challenges by using SGPlan to solve two challenging planning prob-
faced by researchers and experts in these applications new lems. This paper ends with some conclusions.
requirements and roadmaps emerge for the planning and
scheduling community. Oil Supply as a Planning/Scheduling Problem
The main purpose of this work is to share the experi- Operations with crude oil involve the unloading of tankers in
ence of designing and investigating a real application in the docking stations into distribution tanks, and the supply of re-
petroleum industry that can challenge both innovative KE fineries through pipelines. Since the refineries are constantly
tools and modern planning algorithms. The real problem consuming oil, the operations must guarantee that, at all mo-
presented in this paper deals with the planning of the daily ments, the amount of oil in the refineries remains above a
activities of a petroleum plant including docking, storing, minimum level, while minimizing the cost of distribution.
and distributing oil. These operations are very important Most research work done in this area has utilized mathe-
to the functioning of refineries and they constitute a com- matical programming in which the models are adapted to
plex problem that is difficult to model mathematically (Da- mixed-integer linear programming (MILP) or mixed-integer
hal et al. 2003). When planning over this problem, engi- non-linear programming (MINLP) to find solutions to this
neers must deal with tanker allocation, docking scheduling, problem. However, current methods have either failed to
tank volume control, crude oil storage with price maximiza- produce feasible solutions or required a great amount of time
tion (avoiding mixing certain types of crude oils) and the to solve these problems. Furthermore, MILP methods re-
minimization of costs. quire the use of linearization, which leads to flaws in the
Copyright c 2009, Association for the Advancement of Artificial final solutions, while the discretization necessary in MINLP
Intelligence (www.aaai.org). All rights reserved. methods greatly increases the size of the problem (Li et al.
2005). Therefore, as described in (Li et al. 2005), there is no tions can begin. Moreover, a docking station is only able to
reliable and robust algorithm for this real problem in current receive another vessel a certain period after the exit order is
literature. issued to the tanker currently occupying it.
In this work we investigate the feasibility of an AI plan- Tank requirements: Petrobras processes several different
ning approach for a real oil supply problem encountered in types of oil in its refineries. Since reserving a tank for each
one of the main distribution complexes of Brazil. The prob- oil type is not practical, the oils are grouped into classes. The
lem description and requirements used in this paper were crude oil types that belong to the same class can be mixed to-
based on the work of Mas and Pinto (2003), and the infor- gether in a tank without losing value (Mas and Pinto 2003).
mation provided by Petróleo Brasileiro S.A. (Petrobras), the At a given moment, a tank can be in either one of three
main petroleum producer and distributor in Brazil. states: loading, inoperative, or unloading. Under no cir-
In this problem, crude oil is processed in four refineries cumstance can a tank be unloading and loading simultane-
in the State of São Paulo (Brazil): Paulinia (REPLAN), São ously. Furthermore, there are some restrictions concerning
José dos Campos (REVAP), Cubatão (RPBC), and Capuava the presence of brine in the tankers inventories. Since ev-
(RECAP). These refineries are supplied through a pipeline ery oil type received from tankers at São Sebastião con-
network that leaves the São Sebastião terminal (GEBAST). tains brine (even after separation in petroleum production
The system also contains two intermediate substations (SE- platforms), the tanks must undergo a settling period (during
BAT in Cubatão, and SEGUA in Guararema), as well as which the tank remains inoperative) before they can send oil
pumping stations in Rio Prado and Guaratuba. All the crude to the refineries. During this period (started after the last
oil that is consumed by the State of São Paulo comes through load process), the brine settles in the bottom of the tank.
GEBAST and is distributed by two pipelines: OSVAT and This is done in the tanks of GEBAST because it is not desir-
OSBAT. This system is detailed in Figure 1. able to transport brine through the pipelines or send it to the
In this work we consider only the planning of three main refineries.
operations performed daily in the São Sebastião terminal In order to prevent the accumulation of volatile compo-
(GEBAST): docking of oil tankers; oil storage; and distri- nents, the tanks operate using a floating roof system. Since
bution of crude oil to refineries. These operations are per- a minimum safety level is required in order to avoid damage
formed in a distribution infrastructure that consists of a port, to these structures, the tanks can not be fully unloaded (Mas
refineries and pipelines that carry the oil to the refineries. and Pinto 2003). This hard restriction is, usually, about two
The port is composed of piers and tanks, along with internal meters, which represents about 15% of the total capacity.
pipelines that connects each pier to the tanks. This inter- Therefore, each tank has a maximum and minimum capac-
nal pipeline system has already been subject of study in the ity that must be respected in the planning process.
planning community, having appeared as a domain in the
fourth International Planning Competition IPC’04. How- Pipeline requirements: The pipelines are used to send oil
ever, while the pipeline problem is operational in nature, this from the terminal to the refineries that will process it. They
paper is concerned with a more strategic issue: the planning are able to transport more than one crude oil type, sequen-
and scheduling of crude oil distribution in order to reduce tially allocated. During this transport operation, an inter-
costs and maximize profit. face forms between two different oil types resulting in a loss
The planning and scheduling of port operations involves of their properties depending on their types (Mas and Pinto
several activities such as assignment of tankers to piers, 2003). Petrobras uses a table that maps oil types and their
unloading of the tankers to the tanks in the terminal, and interface costs. Moreover, a pipeline must not be used to
unloading of the terminal tanks to the pipelines (Mas and unload distinct tanks simultaneously (i.e., one tank must be
Pinto 2003). The requirements associated to these activities unloaded at a time)
are directly related to four main elements: tankers, tanks, Refinery requirements: The refineries have maximum
pipelines and refinery. The main requirements for these ele- and minimum capacity restrictions that must be respected
ments are described below. throughout their operation. However, a complete model of
Tanker requirements: The crude oil arrives at GEBAST the refinery operation will not be considered. Instead, it will
through oil tankers, which are unloaded at the docking sta- be assumed, in the short term, that the refineries will have es-
tions and stored in the tanks of GEBAST. Each docking sta- tablished an average rate of consumption of crude oil. Thus,
tion has a limitation regarding the size of the tankers it can the amount of oil required by the refinery to maintain its ca-
receive. pacity restriction will be given in advance for the planning
process. This oil amount is computed based on the refin-
The unloading operation has to be done quickly and effi-
ery’s consumption rate and the schedule horizon of tanker
ciently, since there are severe overstay costs in this process.
arrivals.
Each tanker has a limited time that it can stay docked in the
pier and unload oil without paying overstay costs. There-
fore, the planning of this operation should respect this period The Design Process with itSIMPLE
whenever possible. Since the planning application requires a careful design pro-
Finally, every tanker takes a certain time to dock and to cess that involves intensive knowledge acquisition and mod-
leave the port. In practice, this means that, after the order eling, a Knowledge Engineering tool called itSIMPLE (Va-
to dock is given, a period must pass before unloading opera- quero et al. 2007) was used to support the construction and
 Figure 1: Crude oil distribution infrastructure of Petrobras in the State of São Paulo

development of a domain model. itSIMPLE’s integrated en-

vironment focuses on the crucial initial phases of a design.
The tool allows users to follow a disciplined design process
to create knowledge intensive models of planning domains,
from the informality of real world requirements to formal
domain models that can be read by planners. The sug-
gested design process for building planning domain models
includes the following phases: requirements specification;
modeling; model analysis; testing with planners; and plan
evaluation (Vaquero et al. 2007). These phases are inherited
from Software Engineering and Design Engineering, com-
bined with real planning domain modeling experiences.
In this work we are going to focus on four of the main
stages of such design process: requirements gathering, mod-
eling, testing with planners, and plan analysis.

Gathering requirements
Figure 2: Use case diagram of the Oil Supply domain
Requirements are gathered and represented using use case
diagrams from UML. These diagrams model the domain in
the highest abstraction level in which the scope is first de- sents the static structure of the planning domain. It shows
fined. The diagrams usually facilitate the unification of the the existing entities, their relationships, their features, oper-
different viewpoints involved. The use case diagram for the ators (actions) and constraints. A class’s attributes and asso-
São Sebastião terminal oil distribution activities is shown in ciations give a visual notion of the semantics of the model.
Figure 2. In the diagram, each use case receives its descrip- Figure 3 shows the class diagram designed for the prob-
tion, pre- and post-condition, constraints, invariants, flow lem at the São Sebastião terminal. The diagram consists
events and other relevant information. of nine classes: Oil Tanker, Port, Pier, Tank, Pipeline,
As shown in Figure 2, the oil distribution system, which is Refinery, Type of Crude Oil, Class of Crude Oil, and Do-
centered at the terminal, possesses three independent agents main Metrics. These classes model all the entities relevant
(actors in UML): tanker, the terminal (port) itself, and the to the real problem.
refinery. The actors interact to perform the tasks required to The Domain Metrics class is a utility class that stores
take the oil from the tankers and deliver it to the refineries. variables that are relevant to all other classes in the model
such as interface costs. In this particular case, these vari-
Domain Modeling ables (corresponding to costs, revenue and time) are used
Modeling in itSIMPLE follows a object-oriented approach as quality-metrics for the optimization of profit (minimiz-
using UML diagrams such as class diagrams, state machine ing losses and costs). The Refinery class controls the vol-
diagrams, and object diagrams. The class diagram repre- ume of oil that must be sent to itself (properties volumeNeed
 Figure 3: Class diagram of the Oil Supply domain

and volumeSent). In fact, the refinery would need to be able

to deal with a continuous variable regarding the volume of
oil; however, the availability of general planners that handle
such domain characteristics constrained the model in this di-
rection. Thus, planners must considered a specific volume
needed in the refinery to solve a problem.
The actions of the domain are modeled using two dia-
grams: the class diagram and the state machine diagram.
In the class diagram we can define the name, the param-
eters and the duration of each operator (in this work we
use discrete time). The dynamics of actions are specified
in the state machine diagram, in which it is possible to
represent the pre- and post-conditions of the operators de-
clared in the class diagram. In the itSIMPLE, pre- and post-
conditions are defined using the formal constraint language
Object Constraint Language (OCL) (OMG 2003).
Usually every class in the class diagram has its own state
machine diagram. One state machine diagram does not in-
tend to specify all changes caused by an action. Instead, the
diagram details only the changes that the action causes in an
object of a specific class. Figure 4 shows the state machine
diagram for the class Tanker.
In itSIMPLE, the UML object diagrams are used to de- Figure 4: State machine diagram of the Tanker
scribe the initial state and goal state of a planning problem.
The object diagram represents a picture of the system at a
specific state. It can also be seen as an instantiation of the
domain structure defined in previous diagrams. This instan-
tiation defines four main aspects: the number and type of
objects in the problem; the values of the attributes of each
object; and the relationships amongst the objects. In this
case the initial state consist of all tankers, tanks, piers, oil the refineries, this variable represents the losses related to
types, and oil classes properly declared and defined. The sending low quality oil to the refineries. When a plan-
goal state consists of all tankers unloaded (zero inventory) ner allocates oil to be sent to the refinery, this variable
and undocked, while the volume sent to the refinery must is incremented by the difference between the price of the
satisfy the given volume needed (volumeSent >= volume- highest quality oil (a fixed price) and the price of the oil
Need). that is about to be sent.
• totalLossAtPort: this variable represents the losses related
to storing oil in tanks that belongs to a low quality class.
Classes of oil must be properly mixed in order to main-
tain their high quality properties. Every time oil is mixed
in a given tank, a price loss is computed based on the dif-
ference between the price of the class of oil in the tank
and the price of the highest quality class of oil in the sys-
tem. The variable is incremented with such price loss ev-
ery time a tank is loaded with oil.
• totalNumberOfTimeActions: this variable measures the
number of durative-actions as a simplified alternative to
total time. However, the model can also use the reserved
PDDL variable totaltime to compute the plan duration, as-
suming that the planner is able to deal with that variable.
Neither the cost of docking time of each tanker, nor the
cost of overtime docking were considered in this work due
to limitation on available general planners in dealing with
Figure 5: Partial view of an initial state continuous properties/time. The continuous approach could
be used to compute the time that a tanker remains at the
pier for its operations, providing the necessary costs to be
considered during planning.

Model Testing with Planners and Plan Analysis

itSIMPLE can automatically generate a PDDL model from
UML representation. Besides the automated translation pro-
cess, the tool can communicate with several planners in or-
der to test the domain models in an integrated design envi-
ronment. In this application the planners must be selected
based on the resulting PDDL model requirements that go
beyond the classical approaches.
In order to analyze the generated plans, itSIMPLE pro-
Figure 6: Goal state of a sample problem vides two main support tools for plan analysis: plan simu-
lation and plan validation. Plan simulation is performed by
Besides the object diagrams for defining initial and goal observing a sequence of snapshots (UML object diagrams),
states, we also model the metric function to be optimized state by state, generated by applying the plan from the initial
in every planning situation. A plan objective must consid- state to the goal state. The tool highlights every change in
ered four main aspects: (1) the cost of oil interfaces; (2) the each state transition as described in (Vaquero et al. 2007).
profit generated by storing oil in the refinery ; (3) the profit For the plan analysis, itSIMPLE provides charts that rep-
resulting from storing oil at the port among the tanks in the resents the evolution of selected variables of the domain
terminal; and (4) the total time. In this application, the op- such as those that affect the quality of a plan (metrics).
timization of these aspects considers four domain variables,
with their respective weights (wLC, wLR, wLP, and wLA), in Experimental Results
a linear equation to be minimized during the planning pro-
cess. These four variables, from the Domain Metrics class, We selected the planner SGPlan (Hsu et al. 2006) for solving
are the following: the planning problems of the oil supply application based on
the minimal requirements of the domain model such as nu-
• totalInterfaceCost: this variable holds the sum of inter- meric properties, durative actions, and metrics. Among 10
face costs during a plan. Every time oil is sent to the planners available in itSIMPLE, SGPlan was the only one
refinery through the pipeline the planner must check the that could handle all model properties. In fact, we tested sev-
interface cost between the last oil type sent and the one eral planners using simplified problems of the domain and
that is about to be sent. SGPlan had outstanding results (most of time only SGPlan
• totalLossAtRefinery: since we want the best oil type at was able to provide a solution), as described in (Sette et al.
2008). However, since SGPlan does not treat optimization 1st iteration 2nd iteration
functions we used the following approach for our applica- time 0.17s 233.5s
tion: in each experiment we run SGPlan multiple times and Number of actions 27 24
in each iteration we try to find a better solution by adding a Metric value 30.636 26.427
request for lower value of the optimization function.
In order to evaluate the domain described in this paper and Table 1: Data of the solution for Case 1
the generated plans from SGPlan, we created two case stud-
ies. These cases reflect real scenarios (with some simplifica-
tions) of the daily activities in the port of São Sebastião, São
Paulo. The scenarios were based on and inspired by those
presented and studied in (Mas and Pinto 2003). The first
case investigates a simple situation and the second presents
a more realistic scenario. In both scenarios we perform a
continuous analysis of the plan produced by SGPlan, even
though the presented model was defined with discrete ac-
tions.

Case Study 1
This case study represents a simplified scenario in the port;
however, real data are used regarding the volumes of oil,
types and classes of crude oil, tankers, tanks, costs and
pipelines. The planning problem in this case contains one
port that receives three tankers: Reboucas, Front Brea, and
Pedreiras. These tankers can be docked in two piers, P1 and Figure 8: The plan for case study 1
P2. The tankers are unloaded using five tanks in the port.
The oil stored in the tanks must be sent (respecting the set-
tling period) to a refinery through one pipeline. all storage level constraints are respected. Due to the re-
The three tankers are loaded with crude oil that must be quired volume (volumeNeed), it is possible to see that the
delivered at the port. The Reboucas tanker carries a type of refinery maintains its reserve at an adequate level.
crude oil called oc38 while Front Brea tanker carries an oil
called oc05. The Pedreiras tanker carries two oil types, oc08
and oc27.
The tanks are available to receive the crude oil. Each one
of the tanks store a distinct class of oil. These classes must
be considered to maintain the quality of the oil while mixing
different types. When loaded, the tanks must remain inop-
erative for 24 hours waiting the brine to reach the bottom.
Finally, the oil must be sent to the refinery, taking the in-
terface cost into account, in order to accomplish the volume
need. This problem is illustrated in Figure 7, along with the
main oil flow.

Figure 9: Oil levels evaluation

Figure 7: Case study 1 illustration
As mentioned, the current model does not considered the
The scenario was sent to SGPlan which generated its best docking period cost and the cost of overtime docking. How-
plan in the second iteration, as shown in Table 1. Figure 8 ever, we have analyzed the solution based on these met-
illustrates the plan. rics. Figure 10 shows the period ordered for each tanker (48
In order to evaluate the solution, charts were used to check hours, blue bars) and the de facto time used by tankers in the
the changes of oil level in the tankers, tanks, and refinery in plan given by SGPlan. The figure shows that the unloading
the continuous time. The charts in Figure 9 represents the activities of tankers were perform efficiently (the docking
evolution of oil levels (m3 ) in some of these domain ele- time was not exceeded). It also shows that in this case, even
ments. This figure shows the viability of the plan in which with the discrete approach, we still achieved a valid solu-
tion concerning the docking costs, surely as a side effect of
minimizing the timed actions. Thus, case study 1 shows a
promising result for a realistic case.

Figure 12: The plan for case study 2

In order to investigate the oil levels in tankers, tanks and

the refinery, charts were also used to check the SGPlan’s
solution. Figure 13 illustrates some of the analyzed charts.

Figure 10: Time used vs. Ordered period of tanker operation

Case Study 2
This case aims to evaluate the model based on a realis-
tic problem encountered daily in the São Sebastião port.
In this scenario, seven tankers are considered: Reboucas,
Front Brea, Pedreiras, Muriae, Vergina II, North Star, and
Presidente. These tankers can unload the oil into ten tanks
(e.g. TQ3243, TQ3237, and TQ3238). For this problem,
four piers are made available (P1, P2, P3, and P4). The de-
livered oil must supply a refinery considering the constraints
on the tanks (24-hour inoperative period), the necessary vol-
ume, and also the quality-metrics. Figure 11 illustrates the
new scenario.

Figure 13: Oil levels evaluation in case 2

We also evaluated the solution based on the docking costs.

Figure 14 shows the pre-established period for each tanker
compared to the time used by the tankers in the generated
plan. This figure emphasizes the efficiency of SGPlan’s so-
lution, i.e., most tankers operations remained below the es-
tablished period. In fact, not all tankers finished their activi-
ties at the pier during the estimated 48-hour period; the Pres-
Figure 11: Case study 2 illustration idente tanker was the only one that had to remain docked
overtime. This affects the final cost of the whole port opera-
As in the previous case, the problem was automatically tion; however, since the other tankers do not completely used
translated to a PDDL model that was then sent to the SG- the established period, a proper reduction of pre-established
Plan. As opposed to case 1, SGPlan generated a valid plan docking periods would decrease the total cost of docking op-
in the first iteration, but it was unable to find a better solu- erations.
tion in a second iteration. Table 2 shows general data about Even with some restriction in the model concerning con-
the plan generated by SGPlan. A partial view of the plan is tinuous time, the approach showed satisfactory results in
shown in Figure 12. two challenging planning problems. The domain discussed
in this paper gathers features that usually challenge recent
1st iteration planners, such as time, large numbers of numeric resources,
time 210.09s quality metrics and optimization. Moreover, these are some
Number of actions 88 of features commonly found in real planning problems. As
Metric value 73.789 discussed in our previous work on this domain (Sette et al.
2008), few planners can handle domain models that combine
Table 2: Data of the solution for Case 2 all these features, but these applications give a clear roadmap
for planning algorithm development.
 goal preferences in pddl3.0. In Proc. Fifth International
Planning Competition, International Conf. on Automated
Planning and Scheduling.
Li, J.; Wenkai, L.; Karimi, I. A.; and Srinivasan, R. 2005.
Robust and efficient algorithm for optimizing crude oil op-
erations. In American Institute of Chemical Engineers An-
nual Meeting.
Mas, R., and Pinto, J. M. 2003. A mixed-integer opti-
mization strategy for oil supply in distribution complexes.
Optimization and Engineering 4(1-2):23–64.
OMG. 2003. UML 2.0 OCL Specification m Version 2.0.
OMG. 2005. OMG Unified Modeling Language Specifica-
Figure 14: Time used vs. Ordered period of tanker operation tion, m Version 2.0.
in case 2
Sette, F. M.; Vaquero, T. S.; Park, S. W.; and Silva, J. R.
2008. Are automated planners up to solve real problems?
Conclusion In Proceedings of the 17th World Congress The Interna-
We have investigated a real planning problem, the plan- tional Federation of Automatic Control (IFAC’08), Seoul,
ning/scheduling of the daily activities of a crude oil distri- Korea, 15817–15824.
bution plant, using an AI planning approach. We described Vaquero, T. S.; Romero, V.; Tonidandel, F.; and Silva, J. R.
the design process used for building a domain model with 2007. itSIMPLE2.0: An integrated tool for designing plan-
the KE tool itSIMPLE. As an extension of the work done in ning environments. In Proceedings of the 17th Interna-
(Sette et al. 2008), we studied the domain model for the oil tional Conference on Automated Planning and Scheduling
distribution activities in the São Sebastião port (São Paulo) (ICAPS 2007). Providence, Rhode Island, USA.
considering time constraints and quality-metrics.
In order to validate the model in real scenarios, two case
studies were tested using the SGPlan. The first one consid-
ers a semi-realistic scenario and the second brings a realistic
case. The planner was chosen based on its capacity of deal-
ing with the domain model requirements (durative-actions,
numeric variables, and metrics). The metrics considered in
these problems focus on the minimization of different pa-
rameters such as losses of mixing different oil types, in-
terface losses in pipelines, and time spent for the activities.
Experimental results showed that in both cases SGPlan was
able to provide valid solutions. It is important to note that
few planners can deal with such combination of PDDL fea-
tures. Therefore, the resulting PDDL model brings inter-
esting challenges even for the state-of-the-art planners. The
model will be made available in order to share our results on
this domain.
Experience from this application have motivated the im-
provement of itSIMPLE towards time-based models. As a
future work, we will insert timed-based diagrams of UML
into itSIMPLE in order to model continuous time. We plan
to create an extended oil supply model with these new fea-
tures in order to consider all costs.

References
Dahal, K.; Galloway, S.; Burt, G.; McDonald, J.; and Hop-
kins, I. 2003. Port system simulation facility with an op-
timization capability. International Journal of Computa-
tional Intelligence and Applications 3(4):395–410.
Fox, M., and Long, D. 2003. Pddl2.1: An extension of
pddl for expressing temporal planning domains. Journal of
Artificial Intelligence Research (JAIR) 20:61–124.
Hsu, C. W.; Wah, B. W.; Huang, R.; and Chen, Y. X. 2006.
New features in sgplan for handling soft constraints and