3.1. Production Model
SMSs are among the largest and most hi-tech industries in the world. This type of factory is a very capital-intensive business. The SMS process comprises four phases: wafer fabrication, wafer probe, assembly, and testing. One of the most complex operations is wet etching, which is usually performed in a set of AWSs, and it is also the most intensive capital of the production process. The production processes are very complex and require up to 700 single processing steps and up to 3 months to produce. Typically, the production process comprises dozens of process flows, each of which requires more than 100 machines [
25]. Many production models co-exist in an SMS, such as job-shop, flow-shop, and parallel machines. It is also necessary to deal with processes that can require batching or serial production, sequence-dependent setup times, tight due dates, no-wait operations, reworking of a part of wafers, and even more complex developments [
48].
The AWS manufacturing process is carried out in batches and consists of the following processes and operations:
a) The wafer is covered with a thin uniform layer of silicon oxide (SiO2) or gallium arsenide (GaAs).
b) Portions of the wafer are selected and marked to form the circuit configuration (photolithography or photo-masking).
c) Etching is applied; it is a key step in the manufacturing of the wafer. This process is performed by one or more highly automated stations:
d) At these stations, excess film of SiO2 or AsGa is eliminated in a series of chemical and deionizing baths.
e) The batches of AWS wafers are all of the same type and come from previous processing.
f) The lots are subject to processing in chemical and water baths arranged alternatively.
g) The batches are transferred by one or more robots between the baths. In the study case of this research, only one robot is considered for material transfer. Lot transference is performed by a robot on the order of milliseconds and can be different for each pair of baths.
h) The chemical baths follow a zero-wait storage policy and can never be used as temporal buffering (Zero Wait/No Intermediate Storage, ZW/NIS) because chemical overexposure can damage the wafers.
i) The water baths are used for storage (LS).
j) The processing time for each lot depends on the lot and bath.
k) In each bath, one lot can only be processed at a time.
l) It is assumed that the baths and the robot are never out of order.
This study reports a solution to the AWS scheduling problem using one robot. Once the schedule is obtained, an optimized solution is searched with the minimum makespan as the objective function. According to the production process, all jobs are processed sequentially on all baths, always starting at the first machine and, ending at the last one. The jobs are uninterruptible.
3.3. Notations and Nomenclature
Indexes
j - lot;
b – bath;
r – robot.
s – start time
c – completion time
Sets
J - set of lots or job wafers with j∈ J = {1, . . . , |J|-1}.
T - set of discrete time slots t∈ T = {0, . . . , |T|-1}. Where T is the scheduling period.
B - set of k renewable resources (k is the pre-established number of units of a resource that is available for each period of the planning horizon T). In this case, B is the set of baths and each b ∈ B. The arrangement of the baths is alternating, starting with a chemical bath, followed by a water bath, where B = {Bch, Bw }; Bch = {B1, B3, B5,..., BK-1}; Bw = {B2, B4, B6,..., BK}; Bch∩ Bw = ∅; Bch ∪ Bw = B.
R - is the set of robots for job’s transference among baths r∈ R = {1, . . . , |R|-1}. . In this solution, only one robot was used.
Each job j has several properties:
The processing of job j in bath b are uninterruptible.
Usually, the processing times of each job j and, each bath are different. The job’s duration identifies the time of residence of job j in bath b.
A solution contains the following assignments for each job j and, each bath b
- -
the scheduled start time slot for j processing in bath b
- -
the scheduled completion time for j processing in bath b
- -
the bath assigned to job j
- -
he scheduled start time slot for robot r transfer the job j from bath to bath
- -
the scheduled completion time slot for robot r finishes the job transfer from bath to bath
- -
the deadline for finishing processing all the jobs.
3.5. Encoding the Problem in CASP
As previously stated, the main objective of this research is to explore ASP capabilities to solve large problems, e.g., scheduling problems. Therefore, the first intent was to use plain ASP to encode the problem. The solver chosen was
clingo 4.4. However, the set of combinations for these types of problems is extremely large. For example, in scheduling and planning problems, it is necessary to include time variables per time unit and for each variable combination to create the schedule or plan. Consequently, the bottleneck generated during the grounding step was a main obstacle to solving the complete problem, and it was only possible to obtain a partial solution of the problem with four jobs and four baths. Problems with input data beyond this size were untreatable using this approach. The obtained results are not outstanding considering that the problem under study is NP-hard [
49]. On the other hand, the approach in CASP solvers is different and considerably reduces the solving time.
The combinatorial nature of the problem and the ASP difficulties during the grounding clearly showed that a different approach was required to solve the problem. The CASP approach was a natural selection to solve this problem because it is an extension of ASP and is capable of efficiently finding an optimal solution. In the next step, the problem is encoded according to the CASP extensions for ASP proposed by [
15] and solved with the solver
clingcon 2.0.3 [
15]. The characteristics of the computer hardware used in the solution are as follows: intel i7 processor, 1.8 Ghz, 6 Gb memory, OS Ubuntu, 64 bits. For the problem in this study, it is assumed that the AWS is disposed linearly and has a single robot for batch transference (see
Figure 1).
The processing times required for each job and each bath are defined for the next predicate using the following three parameters:
duration(j, b, pjb)
where j represents a job and is an integer with values in the range (1..n); b represents a bath and its range goes from (1..k); and represents the processing times for job j in bath b. Note that the robot transfer times between the baths correspond to the predicate
tRobot(r, k, mb,b+1),
where r represents the robot. In this case, only one robot was used; b represents a bath index in the range (1..k); mb,b+1 represents the transfer time from bath b to bath b+1.
The number of jobs, baths, and robots is given by the constants j, b, and r, respectively. The value ranges for each one are:
The time values were defined as global variables, with the constant deadline representing the time limit to finish all jobs.
The problem was encoded conforming to the known methodology GENERATE, DEFINE and TEST. The GENERATE section is composed of two rules. One rule is used to create all combinations of the job, bath, and duration. The second rule in this section is used to generate the combinations including the jobs, baths and processing times for the robot. It is important to clarify that in the next rules, P and P′ are variables related to jobs; M and M′ are variables related to baths; D and D′ are variables containing the job processing duration; and Tr and Tr′ are variables about the robot transference time for a given bath.
The combinations for the predicates moveBatch and do were transformed into global constraints using the operator distinct of clingcon as follows:
In the DEFINE section, the problem constraint rules were implemented. The implementation in CASP of selected constraints defined in
Section 3.4, are next showed.
Rule 3.5.8 implements Definition 3.4.3. This rule is needed to ensure that in any solution, there exists one job initiating in the first bath at the first instance.
To ensure the strict sequential processing of jobs in consecutive baths (Definition 3.4.2), this constraint is implemented in rule 3.5.9. In this rule, the sequences do(P,M, D) and do(P,M′,D′) represent the assignment of job P to different baths M and M′, and the processing of job P in bath M precedes the processing of job P in bath M′. Also, M′ must be the bath that follows immediately after M.
badSeq(P,M,D,M′,D′):- do(P,M,D), do(P,M′,D′), moveBatch(P,M′,Tr), M’==M+1, iniJob(P,M′) $<
A possible job overlap is of two types: a) jobs P and P′, where P ≠ P′ overlap in the same bath, and; b) the same job P is assigned to two different and sequential baths, M and M′, in overlapping times. The first case corresponds to Definition 3.4.4, and the second case corresponds to the definition in 3.4.6. The implementations appear in rules 3.5.10 and 3.5.11, respectively:
overlapBJ(P,M,D,Tr,P′,D′):- tRobot(R,M,Tr), do(P,M,D), do(P′,M,D′), P != P′, iniJob(P,M) $<= iniJob(P′,M)
overlapJB(P,M,D,Tr,M′,D′):- moveBatch(P,M,Tr), do(P,M,D), do(J,M′,D′), M′==M+1,
iniJob(P,M) $<= iniJob(P,M’)
The implementation of the NZW’s policy, expressed in Definition 3.4.8, consists of the following: as soon as a job P finishes processing in a chemical bath M, it must be transferred to the next bath M′, which is a water bath. If the transfer is not performed immediately, the wafer could suffer damages. This policy is implemented in rule 3.5.12:
chemicalNZWrobot(P,M,D,Tr):- do(P,M,D), do(P,M’,D’), moveBatch(P,M,Tr), M\2>0, M’==M+1,
In the TEST section, the heads of the previously implemented constraint rules in the DEFINE section are written as constraints in ASP language. The constraint syntaxis in ASP are written as rules without heads, and semantically mean that Answer Sets o Solutions where constraints are true, must be deleted of the solutions set to guarantee that constraints are fulfilled and the solution is correct. In this section, only the constraint rules related to the rules (3.5.9 to 3.5.12) are shown.
Finally, makespan minimization is performed with the operator min:
$minimize{iniJob(P,Nb) $+ D $+ Tr : do(P,Nb,D)
Although there are many study cases in the scientific literature related to scheduling problems in SMSs, only a few have focused directly on the AWS problem. Various approaches have been attempted; however, no evidence has been found that the solution to the problem has been addressed using theories and techniques based on non-monotonic logic.