paper

Especificación PDDL de un Dominio de Ensamblaje*
1
2
2
A. Márquez , C. Del Valle , R. M. Gasca , M. Toro
2
1
Depto. Ingeniería Electrónica, Sistemas Informáticos y Automática,
Universidad de Huelva, amarquez@uhu.es
2
Depto. Lenguajes y Sistemas Informáticos, Universidad de Sevilla,
{carmelo,gasca,mtoro}@lsi.us.es
Resumen. En este trabajo se presenta la especificación en PDDL 2.2 de un dominio de ensamblaje, que incluye la selección y secuenciamiento óptimo de tareas de montaje en un sistema con varias máquinas. El objetivo del plan es la
minimización del tiempo total del ensamblaje, para lo cual el modelo considera,
además de las duraciones y los recursos utilizados por las tareas, los tiempos
necesarios para el cambio de configuración en las máquinas de ensamblaje, y
los retardos asociados al transporte de submontajes intermedios entre distintas
máquinas. En este trabajo se propone una especificación en PDDL de este dominio, así como una crítica sobre algunos inconvenientes y carencias que este
lenguaje presenta a la hora de describir las posibles condiciones iniciales.
1
Introducción
Este trabajo presenta la utilización del lenguaje PDDL2.2 [1], una extensión de PDDL
(Planning Domain Description Language) [2][3], para la especificación del dominio
asociado al problema de la selección y secuenciamiento de tareas de ensamblaje, un
problema de planificación más complejo que otros que han sido estudiados ampliamente en la literatura, como el problema de Job Shop Scheduling [4], ya que, aparte
de requerir la búsqueda de una ordenación óptima de las tareas de montaje, como sucede en los otros, es necesario seleccionar las propias tareas de entre un conjunto de
planes alternativos, y de acuerdo a una serie de restricciones para componer un plan
de ensamblaje factible.
El problema se centra en la selección de tareas y su ordenación óptima, teniendo en
cuenta su ejecución en un sistema simplificado e ideal en cuanto a movimiento, de
múltiples máquinas. El objetivo es la minimización del tiempo total del ensamblaje
(makespan) [5][6][7] para lo cual han sido considerados todos los factores que pueden
tener influencia en este sistema simplificado: una estimación de la duración de las tareas, los recursos usados por éstas (máquina y configuración), así como una estimación del tiempo necesario para realizar operaciones auxiliares, como el transporte de
submontajes intermedios y el cambio de configuración en las máquinas, los cuales son
del mismo orden que el tiempo de ejecución de las tareas de ensamblaje, por lo que no
deben despreciarse.
*
Este trabajo ha sido parcialmente financiado por el MCyT con el proyecto TIC2001-4936-E
El resto del artículo se estructura de la siguiente manera: en la sección 2 se describe el problema de la selección de secuencias de ensamblaje. En la sección 3 se describe el dominio del problema y en la sección 4 se realiza la descripción de un problema
concreto usando PDDL y se comentan los problemas que conlleva. Finalmente en la
sección 5 se exponen las conclusiones y en el anexo se muestra el listado completo
del dominio en PDDL, así como la descripción de un problema concreto.
2
Descripción y Representación del Problema
Una forma habitual de describir y representar el conjunto de todos los planes de ensamblaje factibles es mediante grafos And/Or [8] como el mostrado en la figura 1. En dicho grafo, cada plan de montaje tiene asociado un árbol de ensamblaje, que contiene
un conjunto de tareas suficientes para ensamblar el producto completo, y que recoge
las restricciones de precedencia entre las tareas. En tal representación, los nodos Or se
corresponden con submontajes, siendo el nodo raíz el que hace referencia al producto
completo, y los nodos hoja a las piezas individuales. Cada nodo And se corresponde
con la tarea de montaje que une los submontajes de sus nodos hijos (habitualmente
dos, que es lo que aquí se considerará) produciendo el submontaje de su nodo padre.
ABCDE
M2
C 4 T1
5
5
T2
M1
C2
ABCD
M2
M1
C 4 T3 3 C 1 T4 7
ACD
M2
M1
C 3 T5 1 C 2 T6 8
AB
AC
M1
M2
5 T7 C 9 T8 C
1
3
A
B
AD
CD
M1
M2
3 T9
C 2 2 T10 C 4
C
BE
M2
4 T11 C
3
D
E
Fig. 1. Grafo And/Or para el producto ABCDE.
En la figura 1, para cada posible tarea T (nodo And) de montaje se indica su duración
dur(T), máquina donde se ejecuta M(T) y configuración utilizada C(T).
El problema planteado es la selección de un plan de montaje, uno de los árboles
que componen el grafo And/Or, y el secuenciamiento de las tareas que lo componen,
sujetas a las relaciones de precedencia de tareas impuestas por el árbol y a la utilización de recursos compartidos de uso exclusivo. El objetivo es la minimización del
tiempo total del ensamblaje en un sistema con varias máquinas de ensamblaje, por lo
que se han considerado aquellos factores que pueden influir en tal medida. Para ello,
se parte de una estimación previa de los recursos necesarios (máquina y configuración) y duración aproximada de todas las tareas de montaje correspondientes a los nodos And. Además consideraremos el tiempo necesario para realizar otras operaciones
auxiliares, como el transporte de submontajes intermedios de una máquina a otra, así
como el tiempo necesario para realizar cambios de configuración en las máquinas, los
cuales son del mismo orden que el tiempo de ejecución de las tareas de ensamblaje,
por lo que no deben despreciarse.
Denotaremos por ∆cht(M, C, C') el tiempo necesario para cambiar la configuración
de la máquina M de C a C'. Denotaremos mediante ∆mov(SA, M, M') el retardo asociado
al transporte del submontaje SA desde la máquina M hacia la máquina M' (un submontaje intermedio podría ser ensamblado en una máquina y ser requerido a continuación en
otra distinta para formar otro submontaje).
3
Descripción del dominio
El lenguaje para modelar dominios PDDL2.2 [1] es una extensión de PDDL (Planning
Domain Description Language) [2][3], un estándar para la representación de dominios
de modelos de planificación. PDDL es un lenguaje centrado en acciones, pensado para expresar lo físico de un dominio, es decir, los predicados que hay, las acciones que
son posible realizar, la estructura de las acciones y los efectos que las acciones tienen.
Su sintaxis, inspirada en Lisp, expresa la familiar semántica de las acciones, usando
pre y post condiciones que describen la aplicabilidad y el efecto de las acciones.
Como comentamos en la sección anterior, el objetivo del problema planteado es la
selección y secuenciamiento de las tareas del plan de montaje que minimice el tiempo
total del ensamblaje, sujetas a las relaciones de precedencia de tareas impuestas por el
plan y a la utilización de recursos compartidos de uso exclusivo. Para modelar el problema, debemos tener en cuenta las siguientes restricciones:
-
-
Para poder realizar una tarea de montaje, cada máquina necesita tener una configuración determinada, así como tener en su entorno los submontajes con los
que formará el submontaje superior.
Cada tarea de montaje tiene una duración determinada, que depende de la máquina donde se ejecuta, de la configuración de dicha máquina, así como de los
submontajes que intervienen en el proceso de montaje.
Para cambiar de configuración, la máquina no debe estar ocupada. El tiempo
que tarda el cambio configuración depende de la máquina, de la configuración
original que tenía y de la nueva configuración.
Una vez que un submontaje ha sido montado, éste puede ser utilizado inmediatamente en la máquina en la que se ha creado. Si dicho montaje se requiere
en otra máquina diferente hay un retardo de tiempo asociado al traslado del
submontaje de la máquina origen a la máquina destino.
Una vez que un submontaje se ha realizado, la máquina puede inmediatamente, o bien comenzar una nueva tarea de montaje (si los submontajes están en su
entorno y la configuración a utilizar es la misma), o bien cambiar la configuración que tiene (para realizar otro tipo de montaje diferente).
Las entidades (clases) que intervienen en el problema incluyen máquinas (recursos
de uso exclusivo), configuraciones y submontajes. Cada entidad es descrita por un
identificador (ej. M1, C2, ABCDE) y uno o más predicados y/o funciones que son fijados bien en el estado inicial que es dado al planificador, bien por los efectos de las
acciones instanciadas del plan.
3.1
Predicados y funciones
Esta sección presenta una descripción de los predicados y funciones presentes en la
descripción PDDL del dominio del problema.
Los predicados son los siguientes:
Predicado
(is-built ?sub - subassembly)
(at ?sub - subassembly
?obj - location)
(has-config ?mach - resource
?conf - configuration)
(task ?sub1 ?sub2 ?result - subassembly
?mach - resource
?conf - configuration)
Descripción
El submontaje ha sido creado y aún no
forma parte de un submontaje mayor
El submontaje sub está en el entorno
de obj
La máquina mach tiene la configuración conf
Existe una tarea que se ejecuta en la
máquina mach con la configuración
conf y que une sub1 y sub2 para formar result
Las funciones son los siguientes:
Función
(cht ?M - resource
?C1 ?C2 - configuration)
(mov ?S - subassembly
?L1 ?L2 - location)
(length ?sub1 ?sub2 ?result - subassembly
?mach - resource
?conf - configuration)
3.2
Descripción
Tiempo que tarda en reconfigurarse (de
C1 a C2) la máquina M
Tiempo que se tarda en trasladar el
submontaje S de la máquina L1 a la L2
Duración de la tarea que se ejecuta en
la máquina mach con la configuración
conf, que forma result con sub1 y sub2
Descripción de las acciones del dominio
Una vez presentado el problema y descrito su dominio, así como las predicados y
funciones que usaremos en la descripción, pasaremos a comentar las acciones que
usaremos para describir el problema.
Como comentamos en la sección anterior, para poder realizar una tarea de montaje,
cada máquina necesita tener una configuración determinada y tener en su entorno los
submontajes con los que formará el submontaje superior. Además, cada tarea de
montaje tiene una duración que viene determinada por la máquina donde se ejecuta,
por su configuración, así como por los submontajes que se pretenden ensamblar. Por
otro lado, una vez que una tarea ha terminado, el submontaje formado puede ser utilizado inmediatamente en la misma máquina en la que se ha creado, o bien la máquina
pueda realizar inmediatamente otra actividad (ya sea un nuevo montaje o un cambio
de configuración para futuros montajes).
Para describir este comportamiento, en la figura 2 se define la acción que modela
la realización de una determinada tarea de montaje:
(:durative-action MAKE-SUBASSEMBLY
:parameters (?sub1 ?sub2 ?result - subassembly
?mach - resource ?conf - configuration)
:duration (= ?duration
(length ?sub1 ?sub2 ?result ?mach ?conf))
:condition
(and (at start (at ?sub1 ?mach))
(at start (at ?sub2 ?mach))
(over all (at ?sub1 ?mach))
(over all (at ?sub2 ?mach))
(at start (has-config ?mach ?conf))
(over all (has-config ?mach ?conf))
(at start
(task ?sub1 ?sub2 ?result ?mach ?conf)))
:effect
(and (at end (not (at ?sub1 ?mach)))
(at end (not (at ?sub2 ?mach)))
(at end (at ?result ?mach))))
Fig. 2. Descripción de la acción que modela la realización de una tarea de montaje
Nótese que en nuestra definición de MAKE-SUBASSEMBLY hemos impuesto
que para que la tarea de montaje se pueda realizar, la condición (at ?sub ?mach) debe
cumplirse al comienzo de la acción (el momento en el que la acción es aplicada) y debe mantenerse invariante durante toda la ejecución de la acción, a fin de impedir que
cualquier acción que se ejecute de forma concurrente pueda hacer uso de dichos submontajes durante el tiempo que dura el proceso de montaje. Por la misma razón la
condición (has-config ?mach ?conf) debe cumplirse al inicio, para que la acción pueda ser aplicada, y debe mantenerse invariante durante la ejecución de la acción, para
modelar el hecho de que durante la ejecución de una determinada tarea, la configuración de la máquina no puede ser modificada. El hecho de no imponer que esta condición se cumpla al final de la acción (at end) permite que la máquina pueda cambiar la
configuración que tiene simultáneamente a la terminación de la tarea de montaje.
Como es lógico, la consecuencia de realizar la tarea de montaje es que al terminar
dicha tarea (at end) el submontaje resultante está disponible de forma inmediata (bien
para comenzar una nueva tarea de montaje, bien para trasladarla a otra máquina) y los
submontajes que intervinieron en el proceso desaparecen.
Una vez que el submontaje se ha completado, puede que sea necesario trasladarlo a
otra máquina (un submontaje intermedio podría ser ensamblado en una máquina y ser
requerido a continuación en otra distinta para formar otro submontaje). El traslado no se
realiza de forma inmediata sino que hay un retardo ∆mov(SA, M, M') asociado al transporte del submontaje SA desde la máquina M hacia la máquina M'.
La modelización de esta acción viene dada en la siguiente figura:
(:durative-action MOVE-SUBASSEMBLY
:parameters (?sub - subassembly ?M1 ?M2 - location)
:duration (= ?duration (mov ?sub ?M1 ?M2))
:condition (at start (at ?sub ?M1))
:effect (and (at start (not (at ?sub ?M1)))
(at end (at ?sub ?M2))))
Fig. 3. Acción que modela el traslado de un submontaje de una máquina a otra
Como podemos comprobar para que la acción pueda ser realizada, al inicio el submontaje debe estar en la máquina origen. Una vez que la acción empieza a ejecutarse
el efecto inmediato es que el submontaje deja de estar en la máquina origen. Con ello
evitamos que otra acción que se ejecute de forma concurrente haga uso de ese submontaje durante el tiempo que dura el traslado. Es decir, una vez que un submontaje
empieza a trasladarse, ninguna acción puede actuar sobre él. La duración del traslado
depende del submontaje a mover, así como de las máquinas origen y destino. La función (mov ?sub ?M1 ?M2) devuelve cuál es dicha duración. Como es lógico, al final
de la acción el submontaje se encontrará en la máquina destino.
Para que una máquina pueda realizar un determinado montaje puede ser necesario
realizar un cambio en la configuración de ésta. Para ello, la máquina debe estar libre
(no debe estar realizando ninguna tarea de montaje) y debe permanecer así durante
todo el tiempo que dura dicho cambio de configuración. ∆cht(M, C, C') denota el tiempo necesario para cambiar la configuración de la máquina M de C a C'.
La acción que modela dicho comportamiento viene dado en la figura 4:
(:durative-action CHANGE-CONFIGURATION
:parameters (?mach - resource ?C1 ?C2 - configuration)
:duration (= ?duration (cht ?mach ?C1 ?C2))
:condition (at start (has-config ?mach ?C1))
:effect (and (at start (not (has-config ?mach ?C1)))
(at end (has-config ?mach ?C2))))
Fig. 4. Acción que modela el cambio de configuración en una máquina
El esquema es muy parecido al de la acción anterior, extrapolado a la configuración: para que la acción pueda ejecutarse la máquina debe tener la configuración inicial. Una vez que comienza el cambio de configuración, la máquina de forma inmediata deja de tener la configuración inicial y al final de la acción pasa a tener la nueva
configuración. La duración de la acción depende de la máquina y de la configuración
inicial y final. La función (cht ?mach ?C1 ?C2) devuelve dicha duración.
De esta forma evitamos que, durante el tiempo que dura el cambio de configuración, otra acción que se ejecuta de forma concurrente pueda ser realizada (si recordamos, la otra acción que actúa sobre la máquina es la de crear un submontaje, la cual
tiene impuesta como condición invariante que durante la ejecución de la tarea de
montaje la configuración no puede variar).
4
Descripción de un problema concreto usando PDDL
En PDDL hay una clara separación entre la descripción de las acciones parametrizadas que caracterizan el comportamiento del dominio (domain) y la descripción de los
objetos específicos, condiciones iniciales y objetivos que caracterizan un problema
concreto (problem). Así un problema de planificación es creado emparejando la descripción del dominio con la descripción del problema. La misma descripción del dominio puede ser emparejada con diferentes descripciones del problema obteniéndose
así diferentes problemas de planificación sobre el mismo dominio.
Una vez que hemos definido el dominio del problema y su comportamiento, vamos
a describir un problema de planificación concreto. Para ello nos basaremos en el problema representado en el grafo And/Or de la figura 1. Como podemos observar en dicho grafo aparecen 2 máquinas de ensamblaje (M1 y M2), 4 posibles configuraciones
para ellas (C1, C2, C3 y C4), y un total de 13 submontajes (siendo A, B, C, D, E las piezas individuales y ABCDE el producto completo).
Una de las carencias que presenta PDDL es que no admite disyunciones en la descripción del estado inicial asociado a un problema concreto, para permitir que éste no
sea único, sino múltiple. Debido a esto y teniendo en cuenta que nuestro objetivo es
obtener la secuencia de montaje que minimize el makespan, así como el estado inicial
que nos lleva a ese óptimo, nos vemos obligados para subsanar esa carencia a introducir en el problema una serie de objetos y entidades ficticias: una configuración ficticia
C0 que modela el hecho que la máquina se encuentra en cualquiera de las configuraciones posibles y un objeto NOTHING para modelar el hecho que un submontaje se
puede encontrar en cualquiera de las máquinas posibles que existen en el problema.
(define (problem probAssembly) (:domain assembly)
(:objects
M1 M2 - resource
C0 C1 C2 C3 C4 - configuration
A B C D E AB AC AD CD BE ACD ABCD ABCDE
- subassembly
NOTHING - warehouse ; indica que no esta asociado
)
; a ninguna maquina concreta
Fig. 5. Definición de los objetos del problema representado en el grafo And/Or de la figura 1
Inicialmente, las piezas individuales (que queremos modelar que pueden estar en
cualquiera de las máquinas de montajes) estarán en NOTHING, y las máquinas (que
queremos que puedan tener cualquiera de las posibles configuraciones) tendrán la
configuración C0.
; las piezas no estan en ninguna maquina concreta
(at A NOTHING) (at B NOTHING) (at C NOTHING)
(at D NOTHING) (at E NOTHING)
(has-config M1 C0) ; las maquinas M1 y M2 tienen
(has-config M2 C0) ; cualquier configuracion
Fig. 6. Ubicación de los submontajes y configuración inicial de las máquinas
Finalmente, indicamos que la duración del cambio de configuración en las máquinas es 0 cuando la configuración actual es la C0 y que el retardo asociado al traslado
de submontajes es igualmente 0 cuando se realiza desde NOTHING.
(=
(=
(=
(=
(=
(=
(cht
(cht
(mov
(mov
(mov
(mov
M1 C0 C1)
M2 C0 C1)
A NOTHING
B NOTHING
C NOTHING
D NOTHING
0) (= (cht M1 C0
0) (= (cht M2 C0
M2) 0) (= (mov A
M2) 0) (= (mov C
M2) 0) (= (mov D
M2) 0) (= (mov E
C2) 0)
C2) 0)
NOTHING
NOTHING
NOTHING
NOTHING
M1)
M1)
M1)
M2)
0)
0)
0)
0)
Fig. 7. El cambio de configuración y traslado de submontajes tarda 0 para los objetos ficticios
De esta forma el planificador puede pasar a cualquiera de los posibles estados iniciales sin que haya transcurrido tiempo.
Otra de las carencias que presenta el PDDL en la descripción del estado inicial, es
que, aparte de no permitir disyunciones en la especificación del estado inicial, obliga
a la enumeración de todos los predicados y funciones que se instancian en el problema, lo cual resulta muy tedioso y poco práctico. Sería aconsejable que se permitiera el
uso de (for all) y (when) para poder hacer referencia a instancias de predicados y funciones de forma más genérica evitando tener que hacer una enumeración exhaustiva.
5
Conclusiones
En el presente trabajo se presenta la especificación en PDDL 2.2 de un dominio de
ensamblaje, que incluye la selección y secuenciamiento óptimo de tareas de montaje
teniendo en cuenta su ejecución en un sistema simplificado e ideal en cuanto a movimiento, de múltiples máquinas y cuyo objetivo es la minimización del tiempo total del
ensamblaje.
Como hemos podido comprobar, en PDDL hay una clara separación entre la descripción de las acciones parametrizadas que caracterizan el comportamiento del dominio (domain) y la descripción de los objetos específicos, condiciones iniciales y
objetivos que caracterizan un problema concreto (problem).
Si bien en cuanto a la descripción del dominio creemos que PDDL es lo suficientemente robusto para modelar el comportamiento, pensamos que el lenguaje presenta
ciertas carencias a la hora de poder expresar el estado inicial y los objetivos a alcanzar
en ciertos tipos de problemas, como son la imposibilidad de indicar un estado inicial
múltiple que permita no sólo minimizar la función objetivo, sino calcular cuál es el
estado inicial que nos permite alcanzar dicha función objetivo.
Por otro lado el lenguaje es poco flexible a la hora de instanciar los predicados y
funciones que describen el estado inicial de un problema, lo cual resulta tedioso y poco práctico, por lo que creemos que sería aconsejable que se permitiera el uso de (for
all) y (when) para poder hacer referencia a instancias de predicado de forma más genérica evitando tener que hacer una enumeración exahustiva.
Aunque actualmente se ha resuelto el problema descrito por este modelo utilizando
un planificador específico [6][7], en un futuro se pretende generalizar para otros problemas conjuntos de planificación y scheduling.
Referencias
1. S. Edelkamp and J. Hoffmann. PDDL2.2: The Language for the Classical Part of the 4th
International Planning Competition, draft for the use of the IPC-2004 participants.
http://www.informatik.uni-freiburg.de/~hoffmann/ipc-4/DOCS/pddl2.2.ps.gz.
2. McDermott, D., et al.. The PDDL Planning Domain Definition Language. The AIPS-98
Planning Competition Comitee, 1998.
3. M. Fox and D. Long. PDDL 2.1. An extension to PDDL for expressing temporal planning
rd
domains. JAIR, 2003. Special issue on the 3 International Planning Competition, to appear.
4. Y. Caseau and F. Laburthe. Improving Branch and Bound for Jobshop Scheduling with
Constraint Propagation. Proc. 8th Franco-Japanese 4th Franco-Chinese Confrence CCS’95.
5. C. Del Valle and E.F. Camacho. Automatic Assembly Task Assignment for a Multirobot
Environment. Control Engineering Practice, Vol. 4, No. 7, pp. 915-921, 1996.
6. C. Del Valle, M. Toro, E.F. Camacho and R.M. Gasca. A Scheduling Approach to Assembly Sequence Planning. Proceedings of the 2003 IEEE International Symposium on Assembly and Task Planning, pp. 103-108, Besançon, France, July, 2003.
7. C. Del Valle. A. Márquez, R. M. Gasca, M. Toro. On Selecting and Scheduling Assembly
Plans Using Constraint Programming. Knowledge-Based Intelligent Information and Engineering Systems, Lecture Notes in Artificial Intelligence No. 2774, pp. 1329-1336, 2003.
8. L.S. Homem de Mello and A.C. Sanderson. And/Or Graph Representation of Assembly
Plans. IEEE Transactions on Robotics and Automation. Vol. 6, No. 2, pp. 188-199, 1990.
6
Apéndice: Descripción completa del problema en PDDL
6.1
Definición del dominio
(define (domain assembly)
(:requirements
:strips :typing :existential-preconditions
:fluents :durative-actions :derived-predicates)
(:types subassembly location configuration - object
resource warehouse - location)
(:predicates
(is-built ?sub - subassembly)
(at ?sub - subassembly ?obj - location)
(has-config ?mach - resource ?conf - configuration)
(task ?sub1 ?sub2 ?result - subassembly
?mach - resource ?conf - configuration))
(:functions
(cht ?M - resource ?C1 ?C2 - configuration)
(mov ?S - subassembly ?M1 ?M2 - location)
(length ?sub1 ?sub2 ?result - subassembly
?mach -resource ?conf - configuration))
(:derived (is-built ?sub - subassembly)
(exists (?obj - location) (at ?sub ?obj)))
(:durative-action MAKE-SUBASSEMBLY) ; Ver figura 2
(:durative-action CHANGE-CONFIGURATION) ; Ver figura 3
(:durative-action MOVE-SUBASSEMBLY)) ; Ver figura 4
6.2
Definición de un problema (grafo And/Or de la figura 1)
(define (problem probAssembly)
(:domain assembly)
(:objects
M1 M2 - resource C0 C1 C2 C3 C4 - configuration
A B C D E AB AC AD CD BE ACD ABCD ABCDE - subassembly
NOTHING - warehouse )
(:init
; las piezas pueden estar en cualquier maquina
(at A NOTHING) (at B NOTHING) (at C NOTHING)
(at D NOTHING) (at E NOTHING)
; al inicio las maquinas tienen cualquier configuracion
(has-config M1 C0) (has-config M2 C0)
; indicamos todas las tareas de montaje posibles
(task A B AB M2 C3)
(task A C AC M1 C1)
(task A D AD M1 C2)
(task C D CD M2 C4)
(task B E BE M2 C3)
(task AC D ACD M2 C3)
(task C AD ACD M1 C2)
(task AB CD ABCD M2 C4)
(task B ACD ABCD M1 C1) (task ABCD E ABCDE M2 C4)
(task ACD BE ABCDE M1 C2)
; indicamos la duracion de los cambios de configuracion
(= (cht M1 C1 C2) 4)
(= (cht M1 C2 C1) 4)
(= (cht M2 C3 C4) 5)
(= (cht M2 C4 C3) 3)
; el cambio de configuracion desde C0 a Cn es 0
(= (cht M1 C0 C1) 0)
(= (cht M1 C0 C2) 0)
(= (cht M2 C0 C1) 0)
(= (cht M2 C0 C2) 0)
; indicamos la duracion de los traslados de submontajes
(= (mov AC M1 M2) 1)
(= (mov BE M2 M1) 1)
(= (mov ACD M2 M1) 1)
(= (mov ABCD M1 M2) 1)
; los traslados desde NOTHING a Mn son 0
(= (mov A NOTHING M2) 0) (= (mov A NOTHING M1) 0)
(= (mov B NOTHING M2) 0) (= (mov E NOTHING M2) 0)
(= (mov C NOTHING M1) 0) (= (mov C NOTHING M2) 0)
(= (mov D NOTHING M1) 0) (= (mov D NOTHING M2) 0)
; indicamos la duracion de las tareas de montaje
(=(length A B AB M2 C3) 5)(=(length A C AC M1 C1) 9)
(=(length A D AD M1 C2) 3)(=(length C D CD M2 C4) 2)
(=(length B E BE M2 C3) 4)(=(length AC D ACD M2 C3)1)
(=(length C AD ACD M1 C2) 8)
(=(length AB CD ABCD M2 C4) 3)
(=(length B ACD ABCD M1 C1) 7)
(=(length ABCD E ABCDE M2 C4) 5)
(=(length ACD BE ABCDE M1 C2) 5))
; el objetivo es que el producto completo sea creado
(:goal (is-built ABCDE))
; de forma que se minimize el makespan
(:metric minimize (total-time)))