Purpose
To address the problem of disjunctive process plans.
The problem is to choose from the alternative paths given by the process plan,
and how much.
PODL Keywords
Status related variables
:status :min-status :max-status :fixed-status
Constraint type
:process-plan-relation
Equality constraint for status variables
sequential
Sum-Equal constraint for status variables
This is in fact the Kirchhoff’s law for network flow:
parallel
PODL syntax and semantics
With each activity A we attach a :status variable which represents
the percent of usage of this activity in the entire solution of the scheduling.
If the status is not specified, the implicit values are:
:status 100 :min-status 0 :max-status 100 :fixed-status 1
If the status is fixed:
:fixed-status 1
then the status variable cannot be changed during the computation
and its value is provided by the user through the PODL description of the problem.
If the status is not fixed:
:fixed-status 0
then the status variable can be changed during the computation but
obeying the following constraints:
domain
the domain of the status variable is given by :min-status and :min-status
equality constraint
semantics:
all the activities from a path without disjunctive nodes have equal status variables
keyword:
sequential
sum-equal constraint (Kirchhoff's law)
semantics:
The sum of the status variables of the producing activities has to be equal to the status of consuming activity
keyword:
parallel
See also Fixed Percentage Demand.
In the following example, in order to produce inventory INV we may use either
the slow cure activity SC or the fast cure activity FC.
The preference is given to SC which produces better quality, but consumes
more capacity (time). This preference is expressed through the :min-status
and :max-status variables of each activity.
(activity :name SC #slow cure
:min-duration 100
:max-duration 400
:status 65
:min-status 60
:max-status 90
:fixed-status 1
:temporal-relation (after :activity A
:interval 0)
:uses ( role :role-name storage
:amount 1 )
:consumes
( resource-set :set-name INV-RAW
:role-name raw
:amount 1 )
:produces
( resource-set :set-name INV
:role-name cooked
:amount 1 )
)
(activity :name FC #fast cure
:min-duration 50
:max-duration 200
:status 35
:min-status 10
:max-status 40
:fixed-status 1
:temporal-relation (after :activity A
:interval 0)
:uses ( role :role-name storage
:amount 1 )
:consumes
( resource-set :set-name INV-RAW
:role-name raw
:amount 1 )
:produces
( resource-set :set-name INV
:role-name cooked
:amount 1 )
)
The activities SC and FC are producing the inventory INV. The inventory INV is consumed by the activity B.
We set the parallel constraint in the declaration of the activity B as shown below:
(activity :name B
:duration 25
:temporal-relation (after :activity SC
:interval 0)
:uses ( role :role-name machine2
:amount 1 )
:consumes
( resource-set :set-name INV
:role-name cooked
:amount 1 )
:produces
( resource-set :set-name INV3
:role-name colored
:amount 100
)
:process-plan-relation
( parallel :activity SC
:activity FC
)
)
The semantics of this constraint is as follows:
(status of SC) + (status of FC) == (status of B)