Given the fact that there are two different chro-
mosome types we also need specialised mutation op-
erators e.g. to preserve the permutation in chromo-
some A and B. To permute A and B we randomly se-
lected different procedures for mutation. Therefore,
we have forced to implement four different meth-
ods like Position-Based mutation, Order-Based muta-
tion, Scramble-Based mutation or the Swap mutation
(Syswerda, 1991). This concept supports the idea of
parallelism in the algorithm.
The integer chromosome C is mutated by the ad-
joining mutation (Michalewicz, 1999).
With this last operator we are at the beginning of
the procedure. For the next generation of individu-
als this algorithm has to be repeat until the stopping
criterion is reached.
In the following section we want to introduce a
implementation of this algorithm in our integrated so-
lution.
4 IMPLEMENTATION
The developed and introduced framework for the
evaluation of process variants is part of an integrated
system. For this system we have presented a process
structure in the first section of this paper. Now we
want to introduce our implementation of this struc-
ture. Therefore, we have drafted a five tier architec-
ture which reflects the different abstraction layers of
our final software solution
The lowest level is the persistence layer. This
layer is responsible to keep all information for differ-
ent application states permanently. This data is saved
on storage devices within files or databases.
For the integration and collaboration of the par-
ticular modules we define the communication layer.
This layer provides access to the permanent required
and accruing data of the persistence layer. Addition-
ally, it is basis for the exchange of logical program
data during runtime. The communication layer pro-
vides also the ability to handle the other modules
e.g. to invoke succeeding processing functions or to
provide state information about executed calculations
and their results.
We define the application layer in the third tier. In
detail it consists of four particular modules that con-
sequently represent the implemented components of
the program and algorithms. In the AP 224 CAD
module CAD drawings are modelled. This module
is necessary to instantiate the feature based product
model. The second one is the process variants mod-
ule. Thereby, we develop a system, that generates
different suitable process variants to manufacture the
requested part. Thereby, it maps the expertise of a
process planner to support the decision process. The
process variants are extended by the resource module.
This contains information about assignable resources
and their abilities which provides the ability to deter-
mine e.g. set-up times or accruing costs. Finally on
this layer there is the scheduling module which is dis-
cussed within this paper.
For the implementation of the genetic algorithm in
the scheduling module we are utilizing an optimiza-
tion framework called EvA2(Unversity of Tuebingen,
). EvA2 offers a huge range of heuristics including
evolutionary algorithms. The reason for using EvA
is quite obvious. EvA includes a library for the GA
procedure that we have already discussed in this pa-
per. The graphical user interface (GUI) of EvA pro-
vides a solution for an easy parametrization of the
genetic algorithm. Another advantage of this frame-
work is the integration of a visualization of the own
optimization procedure. To implement our defined
problemwe have mapped our problem into an abstract
scheme. After the problem definition we have adapted
the problem representation for EvA2. In addition to
the problem definition and representation we haveim-
plemented the fitness evaluation. EvA2 uses these
definitions in the genetic algorithm. We only had
to implement specialized operators like the partially
mapped crossover. Consequently, we do not have to
worry about the handling of the genetic algorithm.
The required data is extracted from an ERP system,
in our case SAP. For the data exchange we need an
interface to send and receive master and transaction
data to or from an external application. SAP offers a
solution for the data exchange between the ERP sys-
tem and the APO (Advanced Planner and Optimizer).
This is called the SAP Core Interface (CIF). Addition-
ally to the CIF we use the SAP Java Connector (SAP
JCo). This is a middleware which supports the devel-
opment of SAP connected Java applications includ-
ing incoming and outgoing ABAP calls. These ABAP
calls are received and sent by a Java server and pro-
cessed e.g. in the scheduling module. Therefore, we
had to find, interpret and simulate all required outgo-
ing and incoming function calls to use the containing
data in the external scheduling module. Furthermore,
we have to run the function calls in the SAP system to
load the results from the scheduling module into the
ERP system.
Therefore, the fourth layer is the control layer
which avoids the isolation of processes which are run-
ning within our application modules. Additionally,
this layer controls and coordinates the entire planning
process and states of the particular modules.
The fifth layer is the presentation layer which rep-
DEVELOPMENT OF A SCHEDULING MODULE WITHIN AN INTEGRATED SOLUTION FOR THE EVALUATION
OF PROCESS VARIANTS
397