- Email: [email protected]
FMS planning and control-analysis and design
Flexible Manufacturing Systems: Recent Developments A. Raoufand M. Ben-Daya(Editors) 9 1995 Elsevier Science B.V. All rights reserved.
197
FMS P l a n n i n ~ a n d Control -Analvsis a n d D e s i ~ _
_
_
C h r i s t i a n B ~ r a r d a, L u c a s P u n b, B e r n a r d A r c h i m ~ d e c aMaitre de conference au LAP/GRAI Universit6 Bordeaux I, 351 Cours de la lib6ration 33405 Talence (Tel : (33).56.84.65.30 - Fax : (33).56.84.66.44) Email: [email protected], fr bprofesseur honoraire au LAP/GRAI CMaitre de conference ~ l']~cole Nationale d'Ing6nieur 65000 Tarbes
Abstract
:
In this p a p e r FMS P l a n n i n g and Control are regarded as Control problems. Control terminology is used and sometimes re-defined to analyse and design a Convivial FMS Planning and Control System. The objective is to have a unified methodology leading to a specific software. After defining the general concepts, the Analysis phase is concerned with the Modelling tools and techniques used to state the Hierarchical Planning System (called Predictive Control) and the Control System (divided into On-line Control and Dynamic Control). Then the Synthesis phase defines the method to specify and build the final software. This software is designed so t h a t all decisions m a y be made t h r o u g h a dialogue between decision-maker and computer. We call it a Convivial Control.
0
Introduction and problem formulation
The aim of this work is to propose an Analysis and Design Methodology to control FMSs. T h a t leads to specify a Software Architecture allowing to plan and control FMS operation. According to the GRAI terminology [DOU.84], the analysis is based on the two f u n d a m e n t a l concepts of System and Activity. An FMS is composed of two systems : the Physical System and the Monitoring System. Each of t h e m is split into sub-systems and each sub-system into activities. Two sets of activities are considered : Decision Activities when a choice has to be made by a h u m a n operator, and Execution Activities when the operation may be described by a deterministic algorithm. In order to i n t e g r a t e FMS operation in the overall operation of the m a n u f a c t u r i n g system, FMS m a n a g e m e n t is located on a Decision Level closely related to the upper level. In order to s t r u c t u r e our Analysis and Design Methodology we have split the Monitoring System into three parts : Predictive control, On-line control and Dynamic control. To formulate the reaction to d i s t u r b a n c e s we re-define a n u m b e r of t e r m s commonly used in control literature. In fact, controlling a machine is similar to controlling an FMS. But controlling an FMS m a k e s it necessary to specify a more complex technological structure, and to t a k e into account h u m a n decisional factors, various and n u m e r o u s d i s t u r b a n c e s and
198 multiple objectives to reach. This is why we choose to widen the scope of some definitions. To detect and diagnose the origin of a disturbance, we propose to use FlowProfiles presented in [ARC.91-1]. The consequences of a disturbance on the plan are calculated by means of the method of the Minimal Potential-Influence Zone also presented in [ARC.91-1]. The main aim of this paper is to solve FMS control problems convivially. This means t h a t the control software is open to decision-makers : they can enter new constraints and obtain a view of the FMS true state through synthesised graphic diagrams. The co-operation between the decision-makers and the control software is obtained through these interactive diagrams working like input-output devices. Input is used by operators to transmit their choices and output gives information on the situation of the problem-in-process. 1.1.
Role of an FMS in a Discrete Production System
An FMS is a set of machines and equipment which can be reorganised each time a new production program is launched. The objective is twofold : - f a s t adaptation to multiple product types and multiple production program situations, - maximum rate of utilization (100% if possible) of the machines and the equipment. To achieve this aim, two important problems must be solved : - the procurement of materials and articles must suit very closely the m a n u f a c t u r i n g needs, - t h e planning and control of the FMS activities, which become extremely complex, must be very efficient. According to the objectives defined by the long-term m a n a g e m e n t , the medium-term management takes care of two main tasks: - f i r s t , define and realize the procurement program, -second, define the manufacturing program which is realized by the FMS. Therefore, the m a n a g e m e n t of the FMS is a short-term planning and control task.
Procur en~t pro~~n
Medium-Term Management System Orders ~
I Follow-up Performed Orders
/~ements
FMS
Figure
I:
Role
of
an
FMS
199
Each order oi received by FMS has two dates: - di the earliest starting date, - fi the latest ending date. The m a i n objective a s s i g n e d to the FMS by the MTMS ( M e d i u m - T e r m M a n a g e m e n t System) is to perform al_._!lthe orders and meet these two dates. The role of MTMS is to determine the triplets (oi, di, fi) through a hierarchical planning structure described in w 2.1.2.1. 1.2.
Role of an FMS Monitoring System
The m a n a g e m e n t of an FMS is performed by a M o n i t o r i n g S y s t e m . Its objective is to match : - o n the one hand, the m a n u f a c t u r i n g p r o g r a m s r e q u i r e d by the m e d i u m - t e r m planners. - o n the o t h e r h a n d , the r e a l i z a t i o n of t h e s e m a n u f a c t u r i n g programs by the FMS. Practical planning t a s k s : - d e t a i l e d a n a l y s i s of the production p r o g r a m coming from the m e d i u m - t e r m according to the TPP (Technical Process Planning), - e v a l u a t i o n of the m a n u f a c t u r i n g load; if the m a n u f a c t u r i n g load is found insufficient or too important, FMS has to react and ask the MTMS for a modification - e l a b o r a t i o n of a first schedule on the basis of the utilization of the main machines - a n a l y s i s of availability of the logistics (pallets, fixtures, tools, conveyors, set-up problem,...) - r e a d j u s t m e n t of the first schedule according to the results of the analysis (using a Discrete Event Simulation tool) [BER 85], [ARC.87]. Scheduling tasks have to be flexible according to the a m o u n t of time available to obtain a good solution. Strategies and algorithms have to be chosen so t h a t a quick solution may be found. If there is enough time the planning system tries to improve it. I m p r o v e m e n t of scheduling solutions m a y be obtained t h r o u g h an a l g o r i t h m or by a m a n - m a c h i n e co-operation, often by both. We try to determine w h a t strategy, what algorithms and what interfaces are convenient to perform such scheduling tasks. Practical control t a s k s : - e x t r a c t i o n of some o p e r a t i o n s from the p r o d u c t i o n according to the execution of the plan, - dispatching them, - elaboration of the "moving" strategy, - aquisition of "events" from the machines and equipment, - c o m p a r i s o n of FMS true state with plan, - reaction and, if necessary, modification of the plan.
program
200
1.3. FMS Planning and Control viewed as Control problems. In t e r m s of control, FMS planning and control can be divided into three p a r t s each h a v i n g distinct tasks: (a) P r e d i c t i v e c o n t r o l : elaborates adequate schedules to guide the FMS operations. (b) O n - l i n e c o n t r o l : supervises the FMS operation and solves small problems caused by minor disturbances. (c) D y n a m i c c o n t r o l : helps short-term planners to solve big problems caused by i m p o r t a n t disturbances. Those t h r e e types of control are designed to be convivial. There is a big difference b e t w e e n a u t o m a t i c control and convivial control. In a u t o m a t i c control, the control actions are completely predetermined. In convivial control, the real-time control actions are elaborated by exploiting both the n a t u r a l intelligence of the h u m a n monitor, and the artificial intelligence i m p l e m e n t e d in the c o m p u t e r system, so t h a t jointly and convivially, the p l a n n i n g a n d control can be performed efficiently. In such a view of FMS Planning and Control, it is possible to state a generic structure linking the three types of control defined above. Two criteria allow to define t h e m globally: - running mode: p e r i o d i c , e v e n t - d r i v e n or both, - decision level: short or very short term. In this s t r u c t u r e scheduling techniques are used in Predictive Control of course but they are also used in Dynamic Control to react and find a new schedule. The difference is t h a t Predictive Control calculates a global new plan periodically, while Dynamic Control calculates a partial new plan each time a significant disturbance is detected. So, the plan is adjusted as m a n y times as necessary. This plan is used to guide the FMS towards its objectives; it is called the R e f e r e n c e Plan. event-driven Dynamic control
Predictive control
On-line control
Controlled system Figure
2
:
FMS
Planning
and
Control
viewed
as
Control
problems
201 To a n a l y s e those t h r e e control t a s k s it is i m p o r t a n t to define m o r e precisely w h a t a d i s t u r b a n c e is a n d w h a t the types of d i s t u r b a n c e s a n d the types of p l a n are ? 1.3.1.
Disturbances
A d i s t u r b a n c e is an event. It is detected by a difference m e a s u r e d b e t w e e n two events : t h e first one is predictive a n d calculated in the s c h e d u l i n g t a s k , t h e second one is a c q u i r e d from t h e c o n t r o l l e d s y s t e m . T h e e v e n t s m a y be evaluated from several points of view o c c u r r e n c e d a t e , q u a n t i t y o f p r o d u c t , t y p e o f p r o d u c t , q u a l i t y of a product. The problem of the q u a l i t y of a p r o d u c t is e q u i v a l e n t to m e a s u r i n g a q u a n t i t y of product obtained after a control operation on the product. A d i s t u r b a n c e is a more general concept t h a n the error concept (as u s u a l in control l i t e r a t u r e ) ; for us, a n e r r o r is a n e v a l u a t i o n of s o m e disturbances. To define a typology of d i s t u r b a n c e s , we use two criteria: - the t i m e required to react, - t h e consequences on the R e f e r e n c e P l a n if no decision is m a d e . This p l a n o b t a i n e d after a d i s t u r b a n c e w i t h o u t a d j u s t m e n t is called the F o l l o w e d Plan.
So, to define a typology of d i s t u r b a n c e s , we have to define the various types of plans. 1.3.2.
T h e v a r i o u s t y p e s of p l a n s
In an ideal F M S operation, the R e f e r e n c e Plan.
P l a n is identical to the F o l l o w e d
Set of normal plans
~et of plans
bnormal arts
Figure 3 : The various types of plans In a p e r t u r b e d context, the F o l l o w e d P l a n is more or less far from the objectives defined in t h e R e f e r e n c e P l a n . Three sets of plans are considered inside the whole set of possible plans: p l a n s m e e t the m a i n m a n u f a c t u r i n g objectives (to perform all the orders and respect the two dates d i and fi). The R e f e r e n c e P l a n is a n i n s t a n c e of this set.
- The normal
202
- The t o l e r a b l e p l a n s meet a set of tolerable objectives (to perform .a sub-set of the orders and respect the two dates d i and fi with a margin mi). All n o r m a l plans are tolerable. - The a b n o r m a l p l a n s are non tolerable plans. 1.3.3.
Typology of disturbances
Four types of disturbances may be distinguished: The i n c i d e n t s need a light adjustment of the R e f e r e n c e Plan. But the F o l l o w e d P l a n is still a normal plan. The time required to react is not important. On-line control is concerned by incidents. -
E x a m p l e : the duration of an operation is increased because of a machine or a n o t h e r e q u i p m e n t breakdown but the difference is inferior to the predictive margin of the operation. dysfunctions
Dynamic control ~ ~ faults
(
l
intrusions incidents
On-line control ~ ~ shifts
Figure 4 : Typology of disturbances - T h e i n t r u s i o n s are easily detected but need a sophisticated and timeconsuming algorithm to determine the consequences. The F o l l o w e d P l a n is abnormal. The i n t r u s i o n s are treated by Dynamic Control. E x a m p l e : machine breakdown whose duration is superior to the predictive margin of the operation.
- The shifts need not be treated immediately. Generally, the F o l l o w e d P l a n is still tolerable. An accumulation of several shifts may m a k e it abnormal. In this case, the sum of the shifts is called a f a u l t and m u s t be t r e a t e d by the Dynamic Control. On-line control is concerned with shifts.
E x a m p l e : small differences between Reference dates and F o l l o w e d
dates. These differences may be compensated by shifting lightly the next operations. - The d y s f u n c t i o n s are due to a breakdown of the follow-up system. Their t r e a t m e n t m a y take a long time. The F o l l o w e d P l a n is a b n o r m a l . The d y s f u n c t i o n s are treated by the Dynamic Control.
E x a m p l e : a h u m a n operator has forgotten to report the end of an operation. 1.3.4.
On-line control
To s u p e r v i s e FMS execution and solve small problems caused by m i n o r disturbances, the On-line Control is concerned with two main activities: - Dispatching orders and moving products and some equipment,
203 - M a n a g i n g two types of disturbances: shifts and incidents. These d i s t u r b a n c e s are treated by m e a n s of time shifting and techniques u s i n g p e r m u t a b l e operations group [ROU.88] or with a Discrete Event Simulation tool driven by a rule-based expert system [SUN.89].
1.3.5.
D y n a m i c control
To help m e d i u m - t e r m p l a n n e r s solve big problems caused by i m p o r t a n t disturbances, the Dynamic Control has to act as a supervisor for the On-line Control. It uses two tools presented in w 2.1.3 and 2.1.4 : - Flow-Profiles, - M a n u f a c t u r i n g E n v i r o n m e n t Multi-graph. The Flow-Profiles are used to detect a n d d i a g n o s e d i s t u r b a n c e s . The M a n u f a c t u r i n g E n v i r o n m e n t Multi-graph is used to determine the Minimal Potential-Influence Zone of the plan to re-schedule in order to react efficiently. These tools are presented in detail in [ARC.91-1]. 1.3.6.
Predictive control
To be able to guide the FMS towards its objectives, the FMS Control m u s t avoid the Control Reverse phenomenon. This means when the Controlled FMS is no longer guided towards its objectives by the FMS Control. In t h a t case the FMS Control only records the r u n n i n g of the FMS without being able to guide this r u n n i n g . This p h e n o m e n o n occurs when the FMS schedule is not feasible because of the lack of accuracy of the model or because n u m e r o u s and i m p o r t a n t p e r t u r b a t i o n s imply too m a n y c o n s t r a i n t s . The h i e r a r c h i c a l planning s t r u c t u r e aims to avoid this Control Reverse phenomenon. The m a i n objective of Predictive Control is therefore to calculate a set of possible schedules. This activity tries to elaborate schedules, with the following constraints: - meet the date and quantity constraints given by the MTMS, - r u n inside a limited amount of time, - p r o p o s e to the MTMS to relax some constraints if there is a risk of Control Reverse phenomenon, - accept interactive modifications made by a h u m a n operator, - m a x i m i s e flexibility of schedules, i.e. minimise their d i s t u r b a n c e s sensitivity, 1.4.
Development
of the Convivial Control
The development of this convivial control requires analysis and s y n t h e s i s (design of the computer systems). The analysis helps to u n d e r s t a n d , to state the control problems clearly and to solve them. The synthesis allows to build the various components of the computer system (hardware and software), and more particularly, to define an architecture and a methodology to program the software. One i m p o r t a n t objective of the software is to be convivial, therefore analysis m u s t state the interactions between m a n and computer and synthesis has to elaborate a good man-machine interface.
204
Analysis and Problem Solving
0
In the analysis phase, we propose modelling tools and the procedures to use them, in order to solve FMS planning-control problems. First, we present the basic concepts to model the physical system or the FMS controlled system. This model falls into two parts : a kernel, used by all the functions of the Monitoring System, and added elements specific to p l a n n i n g functions. Then, modelling tools for the control system (the monitor) are presented. As our work focused mainly on Predictive Control and Dynamic Control, we have split these tools into t h r e e p a r t s : Predictive Control, A u s c u l t a t i o n a n d Diagnosis for Dynamic Control and Therapy also for Dynamic Control. Modelling tools are used t h r o u g h procedures. Those describe the way these tools m a y be applied to solve planning-control problems convivially. 2.1.
Modelling Languages
The first concepts Oriented Resource the detail
and Techniques.
thing to be modelled is the FMS. For t h a t purpose, we use typical of Discrete E v e n t Model and we s t r u c t u r e t h e m with an Object Approach. Three types of e l e m e n t s are considered : P r o d u c t , and Time. According to the control function using these concepts, level is not the same; so, we organise this model around a kernel.
Then, Predictive Control Model outlines the concepts and principles of the Hierarchical p l a n n i n g and discusses the coordination s t r a t e g y between the Decision Levels. To inspect the FMS operation, we use Flow-Profiles as a modelling tool to reduce the n u m b e r of points to be observed in order to detect disturbances. Flow-Profiles are also efficient to locate the causes of these problems. M a n u f a c t u r i n g E n v i r o n m e n t M u l t i - g r a p h allows to a n a l y s e the effect produced by a disturbance on the reference plan. It determines the Minimal Potential-Influence Zone (MPIZ) of the plan'to re-schedule. 2.1.1.
Modelling the controlled system
Three types of elements have to be modelled : Product, Resource and Time. Product is a generic n a m e for all the m a t e r i a l processed by the FMS. It concerns the modelling of: - t h e description of the flows of products concerned by the FMS, d e s c r i p t i o n of m a i n flows, description of d e t a i l e d i n t e r a c t i o n s between products, main and secondary resources, - t h e TPP (Technical Process Planning), Resource is a generic name for all the equipment used to process the products.
205 It concerns the modelling of: -the m a i n resources" machines, - t h e secondary resources: (pallets, fixtures, tools, conveyors,...); for each of t h e m , the description of t h e i r i n t e r a c t i o n s w i t h m a i n resources and products, -the i n f o r m a t i o n between physical e l e m e n t s allowing to specify dynamic behaviour. Time is a generic n a m e for the elements defining horizon, period, calendar, interval of time. All these elements need: -a d e s c r i p t i o n of the d a t a defining t h e i r s t a t i c a n d d y n a m i c attributes, - a d e s c r i p t i o n of the rules defining t h e i r d y n a m i c b e h a v i o u r according to the state of the other interrelated elements. Two types of dynamic behaviour have to be specified separately: - t e c h n o l o g i c a l b e h a v i o u r linked to the physical s t r u c t u r e of the modelled element, - m a n a g e r i a l behaviour linked to some choices on the way to m a n a g e locally the element. Stating these two dynamic behaviours s e p a r a t e l y is not a trivial task. So, we propose to use concepts commonly used in Discrete Event Model [MAD.90] and some used in Object Oriented P r o g r a m m i n g [GRA.91]. The modelling t a s k has to emphasise a n u m b e r of elements according to the Control phase. But modelling tools have to be coherent to a s s u m e a coherent Information System and therefore a good data base for the FMS. Consequently, we propose to build a c o m m o n k e r n e l defining the common elements of the three phases of the Control [MER.93]. Then we define some added elements for each particular phase. All elements of the model are objects. In m a n y s t a n d a r d Class Libraries the class of this object is called a Collection. For each object, you have: - an identifier, - pointers to navigate in the list of same type objects, 2.1.1.1. Common kernel model We will not give an e x h a u s t i v e description of the k e r n e l but only some examples to explain how to build it. Regarding the modelling of the T i m e c o n c e p t s , we have to define the calendars used in the FMS. Calendars allow to define precisely the nominal availability of each resource. A Calendar is built from the basic concepts : Day Of The Week, Hour, H o u r I n t e r v a l , WeekCalendar, Days Of Rest and Date. All are objects and are defined with their own attributes and operators.
206 For i n s t a n c e , List of W e e k C a l e n d a r s . For each W e e k C a l e n d a r , one has: - s e v e n lists of H o u r I n t e r v a l (one for each D a y Of The Week), e a c h H o u r I n t e r v a l is a couple of Hours (HourD, HourF). List of C a l e n d a r s . For each Calendar, one has: a list of Days Of Rest, a list of (WeekCalendars, DateD, DateF). R e g a r d i n g the modelling of the R e s o u r c e c o n c e p t s , we have to define several c l a s s e s o f r e s o u r c e s (Machine, Operator, pallets, fixtures, tools, conveyors,...) a n d several h i e r a r c h i c a l s t r u c t u r e s (Group, Partition, Layout). H i e r a r c h i c a l s t r u c t u r e s are useful to define dependence relations b e t w e e n resources. G r o u p r e l a t i o n defines sets of equivalent resources. P a r t i t i o n r e l a t i o n is used to settle split r e s o u r c e s (for i n s t a n c e , a work table w i t h t h r e e places, some p r o d u c t s need the whole table, others only one place). L a y o u t r e l a t i o n describes a n inclusion r e l a t i o n b e t w e e n resources (for instance, a m a c h i n e is included in a cell). A resource has its own calendar and a type defining its o p e r a t i n g mode. -
-
For i n s t a n c e , List of Operators - a Calendar, - O p e r a t o r type (operating mode), List of Machines. For each Machine, one has: - m o d e : fully a u t o m a t e d , h a l f - a u t o m a t e d , m a n u a l - a Calendar, - M a c h i n e type (operating mode), - list of authorized Operators - n u m b e r of O p e r a t o r s List of group of Operators - list of Operators belonging to the group - n u m b e r of O p e r a t o r s List of group of Machines - list of Machines belonging to the group n u m b e r of M a c h i n e s R e g a r d i n g the modelling of the P r o d u c t c o n c e p t s , we have to define several t y p e s of p r o d u c t s (for i n s t a n c e , according to the type of T P P ) a n d a m a i n h i e r a r c h i c a l s t r u c t u r e ( G r o u p of O r d e r s , O r d e r , O p e r a t i o n , D e t a i l e d Operation). -
For i n s t a n c e , List of Orders. For each Order oi, one has: di the earliest s t a r t date, fi the latest end date, - O r d e r type (operating mode), - q u a n t i t y to perform, - priority (from 1 to 5), list (or more generally, graph) of operations, For each operation, one has: a code a n d designation, - operation type (operating mode), -
-
-
-
-
207 - m a i n machine,
-(PD, UD, TD), Preparation, Unit and Transfer Duration, - m i n i m u m size of lots, overlapping quantity between lots, - list of substitution machines, 2.1.1.2.
E l e m e n t s for Machine Scheduling
To build the Machine Scheduling Algorithm we propose a modelling tool called the Control Module [BER 81]. Each machine has its own Control Module. It contains the p a r t of the Scheduling Algorithm which concerns the machine. It allows to define a d i s t r i b u t e d a l g o r i t h m which is more robust w h e n the s t r u c t u r e of the model is changed (for instance, n u m b e r of machines) and easy to program on parallel computer [VEE.93]. Operations, constraints
Schedule of the machine
~~ ~ C'~h~ ~ ~~ ~ ....N .......operat!on_~.~ . ~ resources, .~ .'~."~:"~ " ~..... ~~" ~N variables, ~ ~ lists
Simulation of the running of the operation I n p u t Lists Figure
O u t p u t Lists
5 : S t r u c t u r e of a C o n t r o l M o d u l e A Control Module owns two sets of lists: - I n p u t Lists, - O u t p u t Lists. I n p u t Lists are used to m a n a g e the operations involving the machine. T h e y m a y contain the waiting operations with their date of arrival in front of the machine. T h e y m a y also contain the constrained operations with the date when they should be scheduled. O u t p u t Lists record the history of the machine scheduling. The m a i n o u t p u t list contains the current scheduling solution. The others allow the algorithm to m a r k the other a t t e m p t e d solutions and the Decision Points where it is possible to branch or to backtrack. The Control Module operation corresponds to a three step treatment: - C h o o s i n g an operation according to a rule, - Simulating the operation, - U p - d a t i n g the state variables and the Input Lists and recording the scheduled operation in the O u t p u t Lists.
208
The Control Module is one of the basic concept used in SIPA+ software to i m p l e m e n t the scheduling algorithm [BER 89]. 2.1.1.3.
Added Elements for Detailed Scheduling
In this p a r t of the model, more detailed elements are described which allow to s i m u l a t e precisely: - the transfer system, - the tool system, - the r u n n i n g of a machine-type or operation-type. The t r a n s f e r s y s t e m is modelled separately. Its aim is to v a l i d a t e TD, the T r a n s f e r D u r a t i o n . The M a c h i n e S c h e d u l i n g gives a list of t r a n s f e r s to perform between machines. (Mi, Mj, d, f) m e a n s t h a t you have to t r a n s f e r a product from Machine i to Machine j s t a r t i n g at date d and before date f. The objective of this transfer model is to find a solution to t r a n s f e r all the products and to m e e t the d and f dates. If this is not possible, it modifies the dates and t r a n s m i t s the delays to the Machine S c h e d u l i n g . The tool system is also modelled separately. Its aim is to do a first validation of PD, the P r e p a r a t i o n D u r a t i o n . This model describes tools t r a n s f e r s a n d machine configuration globally. The second validation of PD and sometimes UD is done by detailed simulation of the operations on the machine. For this, we describe the list of Operations. For each Operation opi, one has : - d i the s t a r t i n g date and fi the latest ending date calculated by Machine Scheduling, - related order oi, - list (or more generally, graph) of previous and next operations, - F o r each operation, one has : - a code and designation, - operation type (operating mode), - main machine, - UD, Unit Duration, - m i n i m u m size of lots, overlapping quantity between lots, - list of substitution machines. The o p e r a t i n g modes are described with Petri nets [COU.89]. T h e y describe precisely the various s t a t e s of the objects involved (machine, robot, pallet, conveyor, part, data,...). 2.1.2.
Predictive Control Modelling
P r e d i c t i v e Control concerns P l a n n i n g Activity, whose r u n n i n g mode is periodic. This FMS Planning Activity is nested inside a s t r u c t u r e d h i e r a r c h y of P l a n n i n g Activities. In order to i n t e g r a t e the FMS in the whole Production System properly, the FMS Planning Activity m u s t be defined in coherence with the general P l a n n i n g Function. We will first explain the various Hierarchical P l a n n i n g S t r a t e g i e s and t h e i r main concepts: horizon, period, Decision Frame. We will t h e n show the FMS P l a n n i n g S t r a t e g y inside this hierarchical structure.
209 2,1,2,1,
Hierarchical planning
This is a classical m e t h o d in Production Control. It consists in choosing a detail level to define t a s k s and d a t a according to a given p l a n n i n g horizon [POR.87]. F o u r p l a n n i n g levels are obtained from Long T e r m to Very S h o r t Term. This decomposition is very often used in industry [DOU.84]. O t h e r a p p r o a c h e s exist, where p l a n n i n g decisions are not organized in a p u r e l y h i e r a r c h i c a l s t r u c t u r e . [JON.90] proposes a c o m b i n a t i o n of two s t r u c t u r e s , one hierarchical, one heterarchical. In this decomposition, p l a n n i n g decisions at each level are considered as c o n s t r a i n t s and objectives for lower levels. Each level has a distinct couple (horizon, period) [DOU.84]. As a general rule, horizon and period decrease as one approaches toward lower levels. In order to realise a plan, it is n e c e s s a r y to define a co-operation a n d a synchronisation between levels, to run their planning activity coherently. Two solving strategies are considered: - Top-down approach, - I n t e g r a l l y co-ordinated approach. We propose an i n t e r m e d i a t e approach: the P a r t i a l l y co-ordinated a p p r o a c h [ARC.91-1]. To realise this approach, one must know how to determine the p a r t of the plan to t r a n s m i t through the lower levels. In this aim, we define the State of a planning activity and the Decision F r a m e for a planning activity.
a)
The Top-down approach
The Top-down approach's aim is to calculate a plan through a single Top-down pass. A plan elaborated at one level is t r a n s m i t t e d to the lower level as a set of absolute objectives and constraints. The reliability of this approach depends on the capability for a level to know w h a t can be made on the lower level. For this, the work load of the controlled system is calculated but for the moment we do not know exactly how to do such an evaluation. Because t h a t depends on the set of oi and their related TPP. So, a l t h o u g h this a p p r o a c h is not t i m e - c o n s u m i n g , it leads to sub- or overevaluation of the shop capacity.
b)
The Integrally co-ordinated approach
The I n t e g r a l l y co-ordinated approach's aim is to calculate a p l a n t h r o u g h dialogues between adjacent levels. The n u m b e r of passes is not limited, a n d each level m a y contest the objectives and constraints coming from the u p p e r level. The objective is to be sure t h a t the planning solution elaborated is fully admissible. The m a i n objection to this approach is t h a t it is time-consuming. It is difficult to e v a l u a t e the m i n i m u m a m o u n t of time r e q u i r e d to find a first solution, because the lowest level may oblige to re-think the whole hierarchical process planning. But this method has the advantage of giving a very good solution. Therefore, it seems interesting to be able to use it but if you have time.
210
c)
The Partially co-ordinated approach
The P a r t i a l l y co-ordinated a p p r o a c h tries to m a k e a c o m p r o m i s e b e t w e e n the two f o r m e r methods. The objective is to combine the r a p i d i t y of the first m e t h o d and t h e q u a l i t y of the second one. For this, we define the s t a g e notion. It is one step in the solving h i e r a r c h i c a l process.
Admissibility
A high - -
Totally~~ 1 Coordinated ] Partially Coordinated[ Approach [
Medium- -
Low - -
I
I
Low
Medium
I
Time
high
Figure 6 : Hierarchical Planning Approach. A stage is defined in a s s o c i a t i n g two a d j a c e n t levels to find a plan s a t i s f y i n g both levels. The control is t h e n given to the next lower stage, w i t h o u t a possibility to return. solving stages
levels
1, C2, C3 C 1 ~ ~ ~ 3
f
M1
~
M2 M3 M4 M5 M6 M7 M8 M9
CI, M1, M2
C2, M3, M4, M5
C3, M6, M7, M8, M9
F i g u r e 7 : Solving s t a g e d e f i n i t i o n w i t h a t h r ~ : l e v e l h i e r a r c h y
(Shop, Cell, Machine). On one stage, one has one e n t i t y on the u p p e r level, and n on the lower level. The u p p e r e n t i t y e l a b o r a t e s a p l a n a n d a s k s t h e n e n t i t i e s to a p p r o v e or d i s a p p r o v e of its plan. This dialogue is stopped w h e n the two levels agree or w h e n t h e m a x i m u m n u m b e r of passes is reached.
d)
State of a planning activity
In t h e GRAI M e t h o d , t h e p l a n n i n g a c t i v i t y h a s a periodic execution. A decision level Li is c h a r a c t e r i s e d by a horizon, Hi a n d a period, Pi. T h e p l a n n i n g a c t i v i t y (PAi) is a c t i v a t e d every period Pi. An a c t i v a b l e p l a n n i n g activity (PAi) m a y be in one of the two following states:
211
- the auto-activable state, if and only if the planning activity PAi+ 1 of level Li+ 1 (Hi+ 1, P i + l ) has not reached the end of its period, - the waiting state, to be activated by the planning activity PAi+ 1, if and only if the planning activity PAi+ 1 has not reached the end of its period Pi+ 1.
e) Decision Frame for a planning activity Let two adjacent planning activities be PAi+I and PAi, we called the d a t a they exchanged Decision F r a m e for a planning activity. This frame consists of: - the products to plan, - the TPP, - di the earliest starting date and fi the latest ending date, - the n u m b e r of the current pass, - the m a x i m u m n u m b e r of passes. We called Hci the Horizon of the Decision F r a m e for a planning activity. It is the part of the Hi+ 1 whose data has to be transmitted by level Li+l to level Li. Hci is bounded by Hi and Hi + P i + l because PAi needs information on the Hi horizon to m a k e a plan. Hi Levels
Hci
<
< Pi+l + Hi
[ The level is in the waiting state, to be activated The level is auto-activable
qt•
Decision Frame
Hi+l Pi+ 1 - - - - - - - ~
-__~
i+l
~ H i
JL
~
l
i-1
. tO
-:--/
tl
.
.
.
.
.
.
.
.
.
.
.
~
Time
t2
F i g u r e 8 9 Decision F r a m e for a p l a n n i n g activity. APi r u n s every period Pi. In t2, APi receives a new frame from APi+I. So, the last time APi needs frame information to make a plan before t2, is t l . Then, we can write: Hci = (t2 - tO) + H i , i.e.: Hci
= Hi+
P i + l - Pi
212 Let (Hi = k i . P i , Hi+l = ki+l.Pi+l), We obtain the following relations: Relation between Pi+ 1, Pi and Hci Hci = Pi+l-(1-
ki) Pi]
Relation between Hi+ 1, Hi and Hci
i_(ki11), i 1(1
,Hi
We have determined the part of the plan to be t r a n s m i t t e d downto the lower level. Now, we have to state clearly how FMS Control dialogs with MTMS to elaborate the Reference Plan. 2.1.2.2.
Principles and scheme of a hierarchical planning strategy.
Viewed from the FMS the p a r t i a l l y co-ordinated approach is a dialogue between MTMS and the Load Evaluation and Machines Affectation task. The Decision F r a m e sent by the MTMS Planning activity is decomposed with T P P information, and the machine load is smoothed out. Load smoothing is done by m e a n s of M a c h i n e s Affection. These affectations are o b t a i n e d t h r o u g h algorithms and by a man-machine co-operation t h r o u g h a convivial interface. We design and develop such an interface in [BER 90]. An example of a screen is presented in w 3.5.2. If Flexibility Knowledge is specified, it is also possible to make these choices through an inference engine (w 3.3.1.1).
I
MTMS Planning)
[ --- Partially coordinated approach
-
f FMS Predictive control ~ . . . . . . . . . . . . . . . . . . . Oad Evaluation and"~ I achine Affectation J Machine Scheduling
_1
[,
(tools ~~T~tranfersDetailed Scheduling )) (operations)
,
I[Plan ready to launch
#
',, ,'
FMS Control " .....
"perio(lic . . . . . .
[ .....
event'-driven . . . . . .
F i g m ~ 9 9Decision F r a m e for a p l a n n i n g activity
213 H a v i n g the machine scheduling t a s k r u n inside a limited a m o u n t of time is the main objective to reach, even if some of the date objectives are not respected. The reason is t h a t if no Reference Plan is elaborated the FMS Control is blind. This is why we suggest to use a List Method (for its rapidity) and an improving process b a s e d on a l g o r i t h m s a n d M a n - M a c h i n e I n t e r a c t i o n s both. The i m p r o v i n g a l g o r i t h m is b a s e d on p e r m u t a t i o n s m a d e by a S i m u l a t e d Annealing algorithm [ELO. 92]. For the machine scheduling task, the m a n u f a c t u r i n g operations are modelled by m e a n s of three durations: - P D , P r e p a r a t i o n Duration, the a m o u n t of time required to p r e p a r e the machine for a lot of parts, - UD, Unit Duration, the a m o u n t of time required to process one part, - TD, Transfer Duration, the a m o u n t of time required to t r a n s f e r the part to the next machine. In the FMS, t h e s e d u r a t i o n s are not k n o w n with the s a m e precision. Generally, UD is the best known d u r a t i o n because it is related to a fully a u t o m a t e d process. PD is often well-known, but if a tool is shared with a n o t h e r m a c h i n e PD m a y vary. And TD is the less well-known duration, because it depends on the work load of the transfer system. The machine scheduling t a s k elaborates a first schedule, using these t h r e e d u r a t i o n s . Then, the detailed s c h e d u l i n g t a s k m a k e s a D i s c r e t e - E v e n t Simulation to check if PD and TD durations have been evaluated correctly. If n e c e s s a r y , the PD and TD d u r a t i o n s are increased, and the schedule is adjusted. We use the SIMGRAI tool to perform this task [BER 85]. [MON.90] proposes an i n t e r e s t i n g analysis of dispatching rules and how to select t h e m with a discrete event simulator. [MUK.91] has developed an integrated model to realize jointly tool allocation t a s k and sheduling tasks for parts, pallets, machines and conveyors. 2.1.3. Modelling the Auscultation and Diagnosis of disturbances by Flow-Profiles The auscultation-diagnosis method t h a t we will suggest is based on the use of F L O W - P R O F I L E S [ARC.91-2]. These flow-profiles establish a link between the t h e o r e t i c a l production p r o g r a m and the actual m a n u f a c t u r i n g s i t u a t i o n s . Other similar methods are proposed, see [WAR.91] and [BOC.91]. The problem of auscultation is basically a problem of reduction of the set of points to be observed (tested) when a dysfunctioning s y m p t o m appears. In simple cases, such as machine or tool failures, the point to be observed is directly indicated by the location of the symptom. In complex situations, such as b o t t l e n e c k s or i m p o r t a n t m a n u f a c t u r i n g delay (the s y m p t o m s ) , it is necessary to check every preceding point in the flow of parts and in the circuit of machines. Thus, the number of points to be observed may become very large and incompatible with the production program. The flow-profiles will allow, first of all, to locate the hidden causes of the symptoms, and then, to reduce the n u m b e r of points to be observed. A flow-profile is a 3-attribute diagram indicating the load situations of a given machine with respect to time (figure 10) :
214 Pf = ( load L, Waiting Time WT, colour C) Level of load flow Processing starting of machine B processing end of
3
. . . . .
0
t1
I _ . _ _
t2
_
A
t3
t4
t5
Time
F i g u r e 10 : F l o w - p r o f i l e Let t h i s m a c h i n e be called m a c h i n e B; the load m a y come from a n o t h e r machine, called A. Load-level L indicates the a m o u n t of work t h a t the m a c h i n e B is going to u n d e r t a k e . W a i t i n g time WT indicates the period d u r i n g which the i n t e r m e d i a t e stock between m a c h i n e s B and A r e m a i n s constant. Colour C indicates the type of p a r t s on which the machine B will operate. It indicates in fact one type of operations, or one group of operations. With r e s p e c t to the a u s c u l t a t i o n problem, the aim of the flow-profiles is to reflect various t r a n s f e r s i t u a t i o n s b e t w e e n machines. For instance 9 (a) At t l , end of one processing by machine A (b) Between t l and t2, the i n t e r m e d i a t e stock r e m a i n s constant (c) At t2, end of a n o t h e r processing by machine A, hence, an increase of the w a i t i n g stock. (d) At t3, m a c h i n e B s t a r t s to work, t h e r e f o r e , a d e c r e a s e of t h e i n t e r m e d i a t e stock level. (e) Between t3 and t4, the i n t e r m e d i a t e stock r e m a i n s constant (f) At t4, more work comes from m a c h i n e A The d i a g r a m is r e l a t e d to the pair of m a c h i n e s A a n d B. Should m a c h i n e B receive work from several other m a c h i n e s A1, A2, A3,..., one has to establish - firstly, several flow-profiles A1-B, A2-B, A3-B, .... - secondly, one global flow-profile by s u m m i n g up the individual ones. For a u s c u l t a t i o n a n d diagnosis, we need a Reference Flow-Profiles (RFP) which reflects the given production p r o g r a m (Reference Plan). One should be a w a r e t h a t the theoretical p e r f o r m a n c e s of the machines, as a s s u m e d in the production p r o g r a m , m a y be different in reality. Therefore, this R F P m u s t be p e r m a n e n t l y , (or periodically), adjusted according to the real situation.
215 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
~'PI Detection of I ]perturbation
i ..............
, ..............
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
I
.
.
.
.
generation of Flow-Profiles
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
~Set of basic ~ Flow-Profiles j
r
L.~ .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Confirmation of I the perturbation I .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
F i g u r e 11 : D e t e c t i o n process Practically, R F P use for a u s c u l t a t i o n and diagnosis proceeds as follows : step 1 - Occurrence of a significant s y m p t o m at time tn step 2 - D e t e r m i n a t i o n of the RFP, the part from tO to tn step3 - D e t e r m i n a t i o n of the a c t u a l flow-profile w h i c h is different from the RFP (even up-dated) (The R F P reflects s i t u a t i o n s which are w i t h i n the "Earliest-Latest" m a r g i n of the operations. Any f a i l u r e - S y m p t o m indicates t h a t some operations are on the fringe or even beyond this margin)
2.1.4. graph
Modelling the Therapy by Manufacturing Environment Multi-
The m o d e l l i n g a p p r o a c h m a y be s u m m a r i z e d as follows. F r o m the notion of Reduced M a n u f a c t u r i n g E n v i r o n m e n t we define a M u l t i - g r a p h whose edges are t h e predicted p a t h of the products, a n d whose nodes are the m a c h i n e s . U s i n g connex g r a p h s , we define the M i n i m a l P o t e n t i a l - I n f l u e n c e Zone of the plan after a d i s t u r b a n c e has occurred. 2.1.4.1. M a n u f a c t u r i n g E n v i r o n m e n t of a General Workshop (MEGW) For a given [0,T] horizon, the M E G W is defined as the set of usable e l e m e n t s ( m a c h i n e s and e q u i p m e n t ) a n d " - products to be m a n u f a c t u r e d - T P P and sub-TPP associated with these products - physical configurations of the m a n u f a c t u r i n g elements
216 2,1,4,2, Reduced M a n u f a c t u r i n g E n v i r o n m e n t (Ev) For a given horizon [0,T], the Ev is defined u n d e r the following conditions" -Products associated with linear TPP representing p r o g r a m m e d and non-executed operations Feasible m a c h i n e s with non-blocking resource supports. 2.1.4.3. M u l t i - g r a p h of a Reduced M a n u f a c t u r i n g E n v i r o n m e n t Ev
the
-
The m u l t i - g r a p h is defined as 9 G=(S,A), where 9 S: is the set of nodes associated to m a c h i n e s and e q u i p m e n t , defined by the following bijective function f: M ~ S verifying the conditions V (mi,mk) 9 M2 f(mi ) # f ( m k ) V m i 9 M 3 si 9 S/f(m.~=s i A: is the set of edges such as we construct an edge between s i and Si+l, if t h e r e exists a p r o d u c t whose predicted p a t h in the w o r k s h o p t r a n s i t s in e i t h e r direction between m i and mi+ 1. Between s i and Si+l, for a given product, there will be as m a n y edges as t r a n s i t i o n s predicted b e t w e e n the 2 a s s o c i a t e d machines. For a given w o r k s h o p s t r u c t u r e : m l , m 2 , . . . , m i _ l , m i , m i + l , . . . , m k ; for a given product Pi associated with a linear TPP gi, we construct a s u b - G r a p h with k-1 links defined in the following way: v i=l,...,k-1, we connect with one edge the nodes si, s i + l associated with m a c h i n e s m i and m i + l The M u l t i - g r a p h of the m a n u f a c t u r i n g e n v i r o n m e n t of a given workshop is the u n i o n of the set of sub-graphs associated to the products of the m a n u f a c t u r i n g environment. Example I ~
Operations "~ op.1 op.2 op.3 op.4 op.51 pl 1 5 3 6 2 Machines
I
1~
3
6
1
a,
p3 pt
7 6
9 2
8 4
4
ps
3
s
3
s"
p6
8
4
2
9
/ ~ /
F i g u r e 12 : M a n u f a c t u r i n g p r o c e s s .
217
F i g u r e 13 : A s s o c i a t e d m u l t i - g r a p h .
1
F i g u r e 14 : A s s o c i a t e d v a l u e d m u l t i - g r a p h . Let us consider a production program in which" - six products (Pl to P6) are involved - each product may involvel to 5 operations (opl to op5) - 9 machines are used: (1 to 9) U s i n g the TPP associated to the products, the scheduling t a s k assigns a machine to each operation for each product. The schedule-table (figure 12) is obtained. From the schedule-table, we deduce the associated multi-graph of figure 13: -each node r e p r e s e n t s the s i t u a t i o n of a m a c h i n e (s 1 to s 9 correspond to the 9 machines), - t h e r e is one edge (non-oriented link) each time t h e r e is an i n t e r m e d i a t e succession of m a n u f a c t u r i n g sequences either of the same product, or between two different products (example: edge between s 8 and s9). -there are as m a n y edges as immediate successions (example: 2 edges between s 6 and s2). In some p r o d u c t i o n p r o g r a m s , especially w h e n t h e r e are few m a c h i n e s (multiple-purpose machines and conveying robots), the associate m u l t i - g r a p h becomes heavy and difficult to manage. In such a case, the m u l t i - g r a p h of figure 13 is replaced by the valued multi-graph of figure 14 where the multiedge is replaced by a single-edge associated to a n u m b e r r e p r e s e n t i n g the n u m b e r of edges. 2.1.4.4. Absorbing Capacity of an operation In a m a n u f a c t u r i n g schedule, t h e r e are often gaps. A gap occurs e i t h e r because a machine is waiting or because a product is waiting. This gap can be
218 defined with respect to an operation, by considering the consecutive operations of this operation. There are two types of consecutive operations: (figure 15) operation Sm(ij) linked by the machine - toperation (i+ l~j) linked by the product. For the therapy, these gaps can be used for dividing adjusting reactions. -
The Absorbing Capacity CA(ij) of an operation (i j) can therefore be defined as the m a x i m u m m a r g i n which can be employed to annihilate a p e r t u r b a t i o n on this operation without disturbing the consecutive operations. The CA(ij) can be calculated in the following way. In the following expressions, the symbols dd, df, d e stand for: dd (ij) starting date of operation (ij), df (ij) ending date of operation (ij), de (i) due date of product i, ATp(ij) be the margin between operation (ij) and its successor ( i + l j )
Let 9
if the operation (i+ 1j) exists, then ATp(ij) = dd (i+ 1j) - df (i j) - if the operation ( i + l j ) does not exist, then ATp(ij) = Max ( 0, de(j) - df (i,j)). -
Let 9
ATM(ij) be the margin between operation (ij) and its successor Sm(ij) - if operation Sm(ij) exists, then ATM(iJ) = dd(Sm(ij)) - df (ij) if operation Sm(ij) does not exist, then ATM(iJ) = oo. -
The local absorbing capacity of operation (ij) is then: i
CA(iJ)= Min ( A T p ( i j ) , ATM(iJ) ) ATp(1,2)
ATM(1,2) Machines ~"~",i"~-~':i~,.'~
M4
M3 .
.
.
.
M2 M1
'~/"~~!" 'i~ x
x
_ ~
(2,2~~,:. 9
__
U
_
ii:i!!:!!!:i!i:i!~i::::i!:ii!:ii::! ii:i!!:!!!:i! ~-~ Time
F i g u r e 15 : M a r g i n s of a n o p e r a t i o n (ij) 2,1.4,5. Minimal Potential-Influence Zone (MPIZ) One of the key-ideas for solving the NP-complexity scheduling problems, is to decompose the N P - c o m p l e x i t y into isolated small ( n r p k ) - c o m p l e x i t i e s ([BUR.S6], [POR.88]).
219 If this idea is applied to our method, we need to decompose the M a n u f a c t u r i n g E n v i r o n m e n t of the workshop into small m a n u f a c t u r i n g e n v i r o n m e n t s . T h u s , the MPIZ is defined as follows (figure 16) : - the zone is initiated by a p e r t u r b a t i o n , - the zone has a spatial r a n g e in machines and e q u i p m e n t , - the zone has a t e m p o r a l range, - a n y a d j u s t i n g reaction in this zone has a m i n i m u m influence on the following operations. 2.1.4.6. Connex G r a p h s Local zones (nrpk) reflect the situations of the m a n u f a c t u r i n g capacities of the e n v i r o n m e n t s . The connex g r a p h s a r e o p e r a t i o n a l tools, w h i c h t r a n s f o r m zones (nrPk) into a model, from which the m o n i t o r can calculate his a d j u s t i n g reactions quantitatively. realised Zone temporal range
I
M a c h i n e s
. ~
I
minimal ootential-influence
~
MS
m
Set of a c t i v i t i e s -
Time
Di:
F i g u r e 16 : M i n i m a l p o t e n t i a l - i n f l u e n c e
z o n e .
A c o n n e x g r a p h is a s u b - g r a p h of t h e m u l t i - g r a p h r e p r e s e n t i n g t h e m a n u f a c t u r i n g e n v i r o n m e n t . The i n i t i a l m u l t i - g r a p h m a y c o n t a i n i s o l a t e d c o n n e x - g r a p h s (connex components of the multi-graph). A connex c o m p o n e n t m a y a p p e a r after the execution of some m a n u f a c t u r i n g operations (figure 17, figure 18). Operations
•
op.1
op.2 op.3
op.4 op.5
pl
1
5
3
6
ti2
3
6
1
4
p3
7
9
8
p4
6
2
4
p5
3
5
3
2 Machines
/
./ 5
F i g u r e 17 : N e w s c h e d u l e - t a b l e .
220
F i g u r e 18 : V a l u e d m u l t i - g r a p h a s s o c i a t e d to t h e schedule-table of f i g u r e 17. E x a m p l e : Let us s t a r t w i t h the s c h e d u l e - t a b l e in figure 12. S e v e r a l m a n u f a c t u r i n g o p e r a t i o n s have been executed so t h a t the p r o d u c t P5 is achieved. S e v e r a l m a c h i n e - a s s i g n m e n t s have occurred, r e s u l t i n g in the schedule-table in the figure 17. The multi-graph in figure 13 becomes t h e n t h a t of figure 18. The l a t t e r now contains two connex components. One on the left, and the other one on the right.
2.2.
Planning
2.2.1.
or Predictive Control
Convivial p l a n n i n g
The first principle to respect when specifying a Convivial P l a n n i n g Software is t h a t the H u m a n Operator responsible for the scheduling t a s k m u s t not be idle in front of his computer, or the P l a n n i n g Software is not convivial and the H u m a n Operator does not use it. Secondly, the H u m a n constraints easily.
O p e r a t o r m u s t be able to e n t e r his solutions
or
Thirdly, the Convivial P l a n n i n g Software m u s t explain the solutions it has found. So, the Convivial Planning Software relies on [BER 87]: -an Interactive Man-Machine Interface, - a very quick basic algorithm, - s e v e r a l improving a l g o r i t h m s r u n n i n g in the b a c k g r o u n d , which can explain the solutions found, - m a n y utility functions to analyse the scheduling situation. 2.2.2. Man-Machine Interface The h e a r t of the Man-Machine Interface for a Convivial P l a n n i n g Software is the Interactive Graphic Representations for Planning, i.e. a G a n t t d i a g r a m or a Load diagram. The m e a n i n g of Interactive is t h a t the Graphic Representations are the media used by M a n and C o m p u t e r to co-operate towards a solution. The Graphic R e p r e s e n t a t i o n s have to be reactive, i.e. t a s k s on a d i a g r a m m u s t be easily
221 movable w i t h the mouse, and a double-click should open an i n f o r m a t i o n window on the selected task. A Graphic R e p r e s e n t a t i o n for Planning is a 2D view of a 3D Abstract Object: the planning. The three dimensions of a planning are: -T, Time used to r e p r e s e n t P l a n n i n g Horizon, Period, o p e r a t i o n duration,... - P, Product, a generic term used for all the materials transformed by the FMS, - It, Resource, represents all the objects t h a t serve as support for the FMS operation. To specify a Graphic Representation for Planning, we have to define: - a selection among these three sets (T, P, R); i.e. an interval of Time, a sub-set of Products and a sub-set of Resources, - a g r a p h t y p e : Gantt, Load, Day planning, - the set of t o o l s used to Interact with the planning.
- r - ]
InteractiveGraphical Representntions for P l a n n / n g
~[::]']~
(Tools) ISelectron v
I
I
i
Horiz. ~cale
l
,,
i
I
I
I
i
I
I
I
Res. 1
Res.2
period
r~ G2
cD
Res.255
iMi i
_AAI
I •!!!•!!!!!!i!!•!!!•i•i•ii•i•i•i•i!i•i•i•i•i!iii!!!i!i!i••T••i!i!i!i•i•i•i•i•i•i•i!i!!•!ii!i!i•i•i•i•i•ii!!!!i•i•i•i•i!!i!i•
I0
F i g m ~ 19 : P r o p o s i t i o n of a P l a n n i n g Interface 2.2.3.
I,i~ method
The proposed List Algorithm is based on the use of the [BER.83] Control Module. H is the horizon, TO is the beginning date of the plan, T is the current date, the g l o b a l a l g o r i t h m dispatches operations in the i n p u t lists of the Control Modules. Each Control Module with its l o c a l a l g o r i t h m manages the choice of operations in its input list.
222 T is set to TO WHIIJE T < T0 + H DO F O R each free machine DO Activate C o n t r o l M o d u l e of the Machine at date T Update the I n p u t Lists of others Control_Modules END OF F O R Increase T END OF WI-III,E F i g u r e 2 0 : Global a l g o r i t h m To C h o o s e an operation Oi in the Input List according to a rule, I F Oi is chosen T H E N S i m u l a t e the operation on the Machine at date T U p d a t e the state variables and the Input Lists and r e c o r d the scheduled operation in the Output Lists END OF IF F i g u r e 21" Local a l g o r i t h m o f t h e Control_Module This a l g o r i t h m is very simple in its general s t r u c t u r e . This d i s p a t c h e d structure makes it easy to execute by a parallel computer. This is i m p o r t a n t to reduce the a m o u n t of time required for scheduling.
2.2.4.
Improving solution with a Simulated Annealing algorithm
The Simulated Annealing algorithm to improve Shop scheduling solutions is i n t e r e s t i n g because of its generality. Its s t r u c t u r e is not d e p e n d e n t on the structure of the Shop. The first t a s k to perform is to choose an evaluation criterion to m e a s u r e the quality of the scheduling solution. This criterion may be used : - t o minimise the total processing time, - t o minimise the total processing time of a set of m a n u f a c t u r i n g orders (for example, those with a high priority), - to maximise the load of bottlenecked machines. The Simulated Annealing algorithm [BON. 91] is as follows 9
Begin To evaluate criterion C for the current scheduling solution k <-- 0 (initialisation) To evaluate starting temperature T(0) (T is temperature) W h i l e (the stop criterion is not verified) Do
Begin Repeat_Count <-- 0 (initialisation) W h i l e (Repeat_Count < N(k)) Do
Begin Change a product choice for one machine
223 Make a new schedule To evaluate criterion C' for the new scheduling solution If (criterion value C' better t h a n C) T h e n the new scheduling solution becomes the current one Else A(T) = exp ( ( C - C' ) / T ) a random number p is generated in the range [0, 1] If p < A(T) T h e n the new scheduling solution becomes the current one Else the product choice Change is cancelled E n d of If E n d of If Repeat_Count <- Repeat_Count + 1 E n d of w h i l e k <--k+ 1 To evaluate T(k) End of while
End Simulated Annealing algorithm T e m p e r a t u r e T and probability P aim to allow the criterion C to grow between two decreases. T e m p e r a t u r e T is a decreasing geometric function T(k) = a.T(k1); "a" is a constant strictly inferior to 1. The n u m b e r of repetitions "N(k)" is linked to the m a x i m u m number of attempts accepted between two decreases of the criteria; it is often constant. The main loop depends on a stop criterion for the improving process. For us, this stop criterion depends on the a m o u n t of time allowed by the user to the computer to devise this improving process. Figure
22 : The
The Simulated Annealing algorithm is based on the following p a r a m e t e r s : the initial schedule and temperature, the decreasing geometric function, the stop criterion and the rule to make the change of product choice.
2.3.
Supervising or On-line
ControL
The On-line Control is the part of the FMS Control t h a t is most developed in i n d u s t r y . Few generic studies about it are available. The modelling tools commonly used are : -SADT to s t r u c t u r e the physical elements, mainly resources whose w o r k load is limited (machines, e q u i p m e n t , m a t e r i a l s , stocks) [KER.93], [BOW.91], - GRAI-nets [PUN 83], [PUN 84]: - to model the activities and the situations of the product flows, - to model the command signals and their reception points, - to model of the supervising points in the product flows. To m a k e real-time scheduling decisions, the most common approach is to use dispatching rules [HUT.91], [MAH.90], [MON.90].
224 2.4.
Dynamic
Control
We have p r e s e n t e d above (w 2.2.3 and 2.2.4) the modelling tools to be used : - f l o w - p r o f i l e m o d e l l i n g to r e f l e c t m a n u f a c t u r i n g situations ( m a n u f a c t u r i n g load), -capacity-diagram m o d e l l i n g to r e f l e c t a n d u n d e r s t a n d t h e s i t u a t i o n s of the capacity utilisation. We will now explain the procedures to solve the following d y n a m i c p r o b l e m s : -auscultation and diagnosis, - therapy. 2.4.1. M e t h o d o l o g y for A u s c t d t a t i o n a n d D i a g n o s i s In t e r m s of F M S p l a n n i n g a n d control, the a u s c u l t a t i o n process occurs w h e n t h e c a u s e s of t h e p e r t u r b a t i o n s y m p t o m c a n n o t be clearly detected. Once t h e c a u s e s a r e d e t e c t e d t h e d i a g n o s i n g p r o c e s s t a k e s place. In t e r m s of " s u p e r v i s i n g " a n d " d y n a m i c a d j u s t i n g " activities, the d i a g n o s i n g process is lies b e t w e e n t h e s e two activities. This process, in fact, consists of two activities : (a) perception, which i n t e r p r e t s the r e s u l t s of the a u s c u l t a t i o n , n a m e l y , w h a t the causes of the dysfunctioning are; and (b) d e t e r m i n a t i o n of a field of possible actions which will guide the therapy. In our m e t h o d , both a u s c u l t a t i o n and diagnosis are b a s e d on the use of t h e S i t u a t i o n a l D i a g r a m of the flow_Profiles of t h e W o r k s h o p m a c h i n e s (Figure 23). Let : SIT-P : situation of a m a c h i n e which produces a load SIT-C : s i t u a t i o n of a m a c h i n e w h i c h receives a n d c o n s u m e s a load n : t h e n u m b e r of m a c h i n e s used in a workshop. The S i t u a t i o n a l D i a g r a m shows relations b e t w e e n various s i t u a t i o n s of FlowProfiles b e t w e e n the m a c h i n e - s i t u a t i o n s : (a) Level 0 : S i t u a t i o n of Flow-Profiles of n m a c h i n e s in SIT-P a n d n m a c h i n e s in SIT-C (top p a r t of the diagram) (b) Level 1 : Two situations of Flow-Profiles (b l ) S i t u a t i o n of Flow-Profiles of n m a c h i n e s in SIT-P a n d the whole of the n m a c h i n e s in SIT-C considered as one m a c h i n e (middle left) (b2) S i t u a t i o n of Flow-Profiles of n m a c h i n e s in SIT-C a n d the whole of the n m a c h i n e s in SIT-P considered as one m a c h i n e (middle right) (c) Level 2 : Situation of Flow-Profiles of the situation (bl) plus (b2) (bottom of the diagram)
225 Summation of flow profiles
// ",,,,
Machines in state vroducer 0 0
//
Z Aggregation of
/
ines in state consumer
Aggregation of
~Sh~g~s ' / '
p~auc~
Level 0 .
o 0
~ =, .el_ ~.
Aggregated glow-Profile:
0
Aggregation o 1 ~ ~ " . . . . . . . . producers N ~
Level 1 _ Aggregstion of
o
.< Level 2 .
F i g u r e 23 : Situational D i a g r m n of Flow-Profiles
226 The Flow-Profiles reflect the s i t u a t i o n s of the m a n u f a c t u r i n g operations. It is i m p o r t a n t to note t h a t , t h e o r e t i c a l l y , w h e n t h e r e are n m a c h i n e s in t h e m a n u f a c t u r i n g process, the total n u m b e r of Flow-Profiles is n*n (100 only for n = 10). This is w h y a u s c u l t a t i o n is difficult. However, for a given p r o d u c t i o n p r o g r a m , t h i s n u m b e r is m u c h s m a l l e r . If each m a c h i n e is u s e d once, t h i s n u m b e r is 9 for n = 10. This n u m b e r r e m a i n s s m a l l even if some of t h e m a c h i n e s are to be used several times. The global a u s c u l t a t i o n a n d d i a g n o s i n g process comprises t h r e e m a i n s t e p s (each one including several sub-steps) 9 (Figure 24). d e t e r m i n a t i o n of the observable critical point identification of the critical activity identification of the faulty actor or actors. Step 1- D e t e r m i n a t i o n of the observable critical point -
-
-
For this, we use the S i t u a t i o n a l D i a g r a m of Flow-Profiles ( F i g u r e 2). The process s t a r t s w h e n a significant p e r t u r b a t i o n is detected. Step 1.1 - E v a l u a t i o n of the tendency The "tendency" i n f o r m a t i o n a c c e l e r a t e s the s e a r c h for the o b s e r v a b l e critical point. This i n f o r m a t i o n is obtained by c o m p a r i n g the reference Flowprofiles (up-dated) and the p e r t u r b e d one of level 2. An uphill t e n d e n c y (some m a c h i n e s P R O D u c e too m u c h load) indicates t h a t the p e r t u r b a t i o n is on the "PROD" side. A d o w n s t r e a m t e n d e n c y (some m a c h i n e s have too m u c h load to C O N S u m e ) indicates t h a t the p e r t u r b a t i o n is on the "CONS" side. Step 1.2- D e t e r m i n a t i o n of the first m a c h i n e At this sub-step, we compare the Reference and the p e r t u r b e d Flow-profiles at the level 1. W h e n the tendency is "PROD", we identify as the first m a c h i n e , the p e r t u r b e d producer. W h e n the t e n d e n c y is "CONS" we i d e n t i f y as the first m a c h i n e , t h e p e r t u r b e d consumer. Step 1.3- D e t e r m i n a t i o n of the second m a c h i n e At this sub-step, we compare the Reference and the P e r t u r b e d Flow-Profiles at Level 0, which contains all the e l e m e n t a r y flow-profiles. Note t h a t , from Substep 1.2, only one producer or one c o n s u m e r is identified. Therefore, at Substep 1.3, a c c o r d i n g to w h e t h e r this is a p r o d u c e r or a c o n s u m e r , we only c o m p a r e one s e t of n c o r r e s p o n d i n g c o n s u m e r s or of n c o r r e s p o n d i n g producers. The final r e s u l t of Step 1 is one flow-profile connecting a pair of well-defined producer a n d consumer. The search for the observable critical point r e q u i r e s 9 1 comparison at level 2, n comparisons at levels 1 and 0. We therefore reduce a problem of complexity O(n 2) to one of complexity of O(2n+ 1). Step 2. Identification of the critical activity Once the observable critical point is located, we identify the critical activity in space a n d in time. This is done by using the load d i a g r a m corresponding to the flow-profile a r o u n d the critical point. The various types of causes are identified
227 by c o m p a r i n g t h e r e f e r e n c e load d i a g r a m f p (defined by t h e p r o d u c t i o n p r o g r a m ) w i t h t h e real a c t u a l load d i a g r a m f r (Figure 4). The difference b e t w e e n the two d i a g r a m s m a y a p p e a r in the length L of the w a i t i n g time, in the load level N, or in the Colour C (p : index for reference production p r o g r a m , r : real c u r r e n t situation, ti : m o m e n t in time w h e n the difference is observed). Load-flow level
4
reference . . . . . actual
3 2 1
0
I 1
! 2
I
'.
~.
',
3
4
5
6
F i g u r e 24 : C o m p a r i s o n
of load
=
Time T
diagrams
(a) The lengths are different 9 L~ v dr F u r t h e r m o r e , load-levels are also different : (al) L~ < d r a n d N ~ +1 >N~ The p e r t u r b a t i o n causes m a y be : - m a c h i n e failure of the uphill unit A - u n d e r - e v a l u a t i o n of the processing time of A (a2) k~ < lirandN~+1
(a3) Lb > ~randNir +1 > dr The causes may be : -
over-evaluation of the processing time at A of B larger t h a n previously a s s u m e d problems in the percentage of waste parts
-capacity -
9
(a4) Lb > ~r and Ni~l< I~r The causes may be : the t r a n s f e r between A and B is too fast problems of the m a c h i n e s - w r o n g choice of m a c h i n e s (b) Diagnosis on the waste-rate -
-procurement
T h i s h a p p e n s if N ~ ~rand~p= dr. The s i t u a t i o n confirms t h a t t h e u n d e r l y i n g activities are critical. (c) Diagnosis on the sequencing This h a p p e n s if ~.p r ~r The causes m a y be
228 either a misconveying of parts a wrong sequencing of operations Step 3 Identification of critical actors Locating the critical activity allows identification of the critical actor or actors. This is done by representing the activities by m e a n s of the GRAI-nets ( G r a p h s w i t h R e s u l t s a n d Activities I n t e r r e l a t e d ) [ P U N 84]. In t h i s representation, each activity is symbolically characterised by : input and output events, intellectual supports, m a t e r i a l supports, - operator. The i n t e r r e l a t i o n s between activities are always defined by the fact t h a t the support of one activity always comes from the result-event of another activity. Based on the GRAI-nets, the v a r i o u s causes identified at step 3 are symbolically t r a n s l a t e d into real elements. -
-
o
r
-
-
-
2.4.2.
Therapy Procedure
The aim of the procedure is to help the monitor, after the p e r t u r b a t i o n has occurred, and after the critical elements have been located, to d e t e r m i n e a d j u s t i n g reactions with a m i n i m u m of consequences. Step 1: Initiation Auscultation and diagnosis have identified the critical elements, causing the pernicious p e r t u r b a t i o n s . The Monitor displays the schedule-table and the G a n t t d i a g r a m of the m a n u f a c t u r i n g program. From the G a n t t diagram, the Monitor identifies the p e r t u r b a t i o n date dp (figure 26). Its t a s k is now to i d e n t i f y the MPIZ. For this, he c a r r i e s out a s p a t i a l a n d t e m p o r a l decomposition. Step 2: Spatial Decomposition The MPIZ is c h a r a c t e r i s e d by a spatial and a t e m p o r a l range. F r o m the schedule-table and the G a n t t diagram, the Monitor generates the associated Multi-graph. (An automatic generator m u s t be implemented in the decisionaid system). If the multi-graph possesses 2 or more connex components, the monitor chooses the smallest one. If not, the Monitor carries out a temporal decomposition. Step 3" Temporal Decomposition Each time a m a n u f a c t u r i n g operation is performed, a r u p t u r e m a y occur in some link of the multi-graph. As a consequence, new connex components m a y occur. There are three types of ruptures: t.ype a. The operation achieved is associated in the valued graph with a link of a value superior to one. The value decreases by one unit. No r u p t u r e in the graph. The connexity remains the same. type b. The operation achieved is associated in the valued g r a p h with a link of a value of 1 between nodes s i and Si+l. After this rupture, there exists
229 no circuit between these two nodes. The initial graph components.
splits into two connex
tvoe c. The operation achieved is associated in the valued graph with a link of a value of 1 between nodes s i and si+ 1" After this r u p t u r e , there still exists some circuit between these two nodes. No new connex components are created. The connexity of the initial graph remains the same. For the t e m p o r a l decomposition, the Monitor displays the schedule-table (figure 25) and the corresponding Gantt diagram (figure 26). He simulates the successive achievements of the m a n u f a c t u r i n g program (automatic pointer to be implemented in the decision-aid system). -~
Operations
r " M op.l I
op.3] op.4[ op.5]
op.',
917 71s 816 612 3 l 6 IP61 I 15 3 15
2 l
l
Machines
I/I
Figure 25 :Schedule~table under temporal decompositiom Machines
Ii :
_
~
_
i
i
. i
i I
-.,~-.~(a'2~',.
_
M9
_
i i
i
,,
M8
I
M7 M6
,
:
I
;;--
,,
i
,,
i i , i i . i -- ~ ( 1 , 4 ~ ~ ~ 2 . 5 ~ ~ " ~2-:3.T~., ~ I I i i
(4,6 " - ~ -,--T
M5 M4 ~
(1,5~
(1,7~
'
~ , 4 ~ ! ,
''
~
M3 M2
,
.
|
i
'.
~
~(3~3~ i i
(5,6_!i
I(I,~
MI
i
dO I
. . . .
=
=
!
i i
~'d~
i
i
:d3= (!1
I
I
(~'d61
i
I
i
~'d~
'
'
!
:~----
Time
F i g m ~ 26 : G a n t t d i a g r a m u n d e r t e m p o r a l d e c o m p o s i t i o m After each operation has been completed, he analyses the new structure of the m u l t i - g r a p h of the m a n u f a c t u r i n g e n v i r o n m e n t (connection b e t w e e n the pointer and the multi-graph generator to be implemented in the decision-aid system, the l a t t e r m u s t have a multi-window possibility). The succession of multi-graphs is shown in figure 27. The various steps of the decomposition are the following.
230 a- Initial structure A0 of the multi-graph at date do. b- At date dl, operation(I,3) ends. Rupture of link (s6, s8). Graph A0 splits into two connex components A1 and A2. c- At date d2, operation(2,5) ends. Rupture of link (s6, sl). Sub-graph A1 splits into two connex components A l l and A12. d- At date d3, operation(2,2) ends. Rupture of link (s9, s8). Sub-graph A2 splits into two connex components A21 and A22. e- At date d4, operation(3,5) ends. Rupture of link (sl, s4). Sub-graph A12 splits into two connex components A121 and A122. f- At date d5, operation(3,6) ends. Rupture of link (s3, s6). Sub-graph A l l splits into two connex components A l l l and Al12. g- At date d6, operation(3,1) ends. Rupture of link (s7, s8). Sub-graph A21 splits into two connex components A211 and A212. h- At date d7, operation(3,7) ends. Rupture of link (s3, s5). Sub-graph A l l l splits into two connex components A l l l l and All12. i - A t date d8, operation(4,6) ends. Rupture of link (s2, s6). Sub-graph A l l 2 splits into two connex components A l l 2 1 and Al122.
co,_ :,_ A2
A1
A12
T
A.11
Ittlttll
Figure 27 : Temporal decomposition of a multi-graph.
231 At each step a, b, c, .... , i, the monitor tries to determine the adequate adjusting reactions. If he does not succeed at one particular step, he goes to the next one. The earlier he succeeds with the dates, the better the adjusting reactions are. This p r o c e d u r e is i n t r i n s i c a l l y an o p t i m i s i n g procedure. The m i n i m i s e d criterion are the consequences of the perturbation on the production program. Step 4: Adjusting through permutation (figure 28) Once t h e connex c o m p o n e n t is i d e n t i f i e d , t h e M o n i t o r d i s p l a y s t h e c o r r e s p o n d i n g schedule-table and G a n t t d i a g r a m . He tries to absorb the p e r t u r b a t i o n through permutation. Two operations (i~j) and (k,1) scheduled on the same resource mi are said to be permutable if Max (df (i-lj), df (k-l,1)) < Min (dd(ij),dd(k,1)) Max (df (ij),df (k,1)) < Min (dd(i+l~), dd(k+l,1)) (Automatic computation of these conditions to be implemented in the decisionaid system). Step 5: Adjusting through transfer (figure 29) An operation (i~j) scheduled on resource mi is said to be t r a n s f e r a b l e if t h e r e exists at least one alternative resource mk r mi available between dd(ij) and df(i,j). (Automatic prospecting to be implemented in the decision-aid system). Permutation
M3~
~~%~(2,3~.~~(3,4~ _
~_~ time
Figure 28 : Permutation of manufacturing operations. Reassigned operation
Ma~ioes
~a,~ O,,01acedo~ratioo/
time
Figure 29 : Transfer of m a n u f a c t u r i n g o p e r a t i o n s .
232
Synthesis and Software architecture
1
From the tools and methods chosen for solving FMS Control problems this part proposes a methodology to build the Software architecture. The aim is not to describe a trivial programming method but to insist on the difficult points: - general principles to organize the global architecture, -construction of the various elements of the Software: Database, Knowledge, Programs, Interfaces, - l a n g u a g e and development methodology. The FMS Control we propose is a Convivial Control. For this reason, the presentation emphasises the heart of a Convivial Software: the Man-Machine interface. Then the FMS Control has to be integrated in the overall Enterprise Control. So, the software architecture must be designed and developed with a modular organisation [SAN.91].
3.1.
General architecture.
3.1.1.
Logical Architecture
The following scheme (figure 30) defines the general architecture of the FMS Planning and Control System for one part of the FMS, i.e. Cell control or Central control in figure 31.
periodic
event-driven
(MTMSPlanning)
]
Partially coordinated approach I f FMS Predictive control~" Load Evaluation and'~
achine Affectation_.] Machine Scheduling
Cooperative c~ Local
)
I
Dynamic control
Detailed Scheduling ) (tools~""~tranfers) ] ~ ~operations) j
Database for follow-up data
On-line control J
FMS Control
Controlled system Figure 30 : FMS P l a n n i n g a n d Control System.
: ..... i
233 Co-operative control concerns exchange with upper level to find solution when the Decision frame cannot be respected. Local D a t a b a s e is used to m a i n t a i n an image of the controlled system. Some aggregation functions allow to t r a n s m i t to the upper level the results achieved by the controlled system. 3.1.2.
Physical Architecture
The practical aim of the Physical Architecture is : - o p e r a t o r s m u s t use the Control Software, - o p e r a t o r s have to be motivated to obtain the best "score" with their FMS, - o p e r a t o r s have to be involved in the improvement of functions and interfaces. For this, the FMS Control Software must be: - a n agreeable software to use, it m u s t encourage to "play" with all the functions, -efficient to obtain information, to print reports on all the aspects of the FMS, - a media allowing the decision m a k e r s to c o m m u n i c a t e between t h e m but also p r o v i d i n g all o p e r a t o r s w i t h i n f n r m a t i o n a n d knowledge, So, the actual trend is to install a local network of Workstations : - one station for the Central Control, - o n e station for each h u m a n cell responsible for a p a r t of the FMS (Cells, Complex machines,...), - o n e station for each function (transfer, d a t a b a s e , tools, storage, Direct Numeric Control). Each workstation has the following specifications : - connected to the other workstations by a network, - r u n n i n g with multi-task and real-time operating system, -owning a multi-windowing interface capable of connecting several colour screens, - e q u i p p e d with office utilities for operators: mail, word processing, s p r e a d s h e e t and copy/paste functions between office software and control software.
234 Physical
-
-I
control
Architecture
Central controll
Functional
---
Control
I
(,.transfers)
Architecture
I
i
I
(,.tools
)
t
]Cell control Cell
l
] Cellc~176 ] (Cell~ 2 L )
! ...... I
(Database)
Network
]
[Workstation(
I
QDNC machines)
) Controlled O bFunction jeCtor
F i g u r e 31 : P h y s i c a l A r c h i t e c t u r e . A n u m b e r of principles have to be respected w h e n u s i n g this physical architecture: - D e c i s i o n - m a k e r c o d e : each operator liable to use the workstation m u s t have a card or a badge to control access to a n u m b e r of critical functions of the FMS Control Software, - F l e x i b i l i t y i n c o n t r o l 9 each operator must have access to its tasks from all the Workstations, - A c c e s s t y p e : each task or program may be used under different modes (consultation, modifications, information) according to the responsibility of the operator. 3.2.
Building of the Database (object-oriented
approach).
The Database is a fundamental element of the FMS Control Software. It m u s t be a Real-time Database with the following problems to solve : - A c c e s s t i m e : when a disturbance is detected or when a schedule is computed a lot of data has to be reached rapidly. -Updating : all the shared information m u s t be recorded in and retrieved from the Database to prevent inconsistencies between two programs. - M u l t i p l e d o m a i n s : the Database contains several aspects of the same data according to the domain : routes operations for schedules, operations for D.N.C. In an FMS Control Software, we are essentially concerned with A c c e s s t i m e . So, we propose to realise a RAM Database through an object language (RAM: Random Access Memory, a work memory whose Access time is quicker t h a n disk memory). This Database will be managed by a dedicated workstation with a great a m o u n t of RAM memory to be accessed rapidly from any workstation. The contents of the Database are essentially: - the object m o d e l s of the Controlled FMS - object model of the FMS (Common kernel), - a d d e d models: Machine Scheduling, Detailed Scheduling, - object model of the Flow-Profiles -object model of the Manufacturing Environment Multi-graph
235 - the o b j e c t m o d e l of the FMS P l a n n i n g Control System Each p r o g r a m of the global software is an object in this structure. This concept allows to design an Open Control S y s t e m easy to develop a n d m a i n t a i n . The software d e v e l o p m e n t t a s k is unified in one p r o g r a m m i n g e n v i r o n m e n t . 3.3.
Building of the Knowledge-base
(predicate-logic approach).
We will t r y to specify two points about the building of the Knowledge-base 9 - the content of a Knowledge-base for an FMS Control Software, - the w a y to e n t e r knowledge in the base. Two other i m p o r t a n t questions are not t r e a t e d in this p a p e r " the m a n a g e m e n t of t h e k n o w l e d g e coherence a n d K n o w l e d g e - b a s e o r g a n i s a t i o n to m a n a g e jointly object models a n d sets of rules. For a first r e s p o n s e to this r e s e a r c h problem, see [PAC 92]. 3.3.1.
Contents of the Knowledge-base
Generally, the Knowledge-base contains information about how to use d a t a a n d models in the FMS Control Software. This knowledge m a y be divided into four parts" - Knowledge about Flexibility, - History of the FMS operation, - K n o w l e d g e about M a n - M a c h i n e Interactions, - Knowledge about D y n a m i c Control. 3.3.1.1. Knowledge about Flexibility In m a n y control s i t u a t i o n s , the o p e r a t o r s or the p r o g r a m s need i n f o r m a t i o n about the flexibility of the shop. Two m a i n types of flexibility are considered 9 - M a c h i n e or e q u i p m e n t Flexibility, - Product Flexibility. E a c h e q u i p m e n t of the FMS h a s various o p e r a t i n g modes. A n o r m a l mode is chosen b u t one m a y h a v e to switch to a n o t h e r mode in order to solve some d i s t u r b a n c e s i t u a t i o n s . This technical i n f o r m a t i o n is often u n k n o w n to t h e Control Software. It is i m p o r t a n t to describe all these modes and to e n t e r t h e m in the Knowledge-base. E a c h m a c h i n e m a y also have several configurations. T h e s e c o n f i g u r a t i o n s a r e r e l a t e d to t h e tools, t h e p r o g r a m s or specific e q u i p m e n t a t t a c h e d to t h e m a c h i n e . If a f o r m a l d e s c r i p t i o n of t h e s e configurations is available in the Knowledge-base, the F M S Control Software (or t h e o p e r a t o r ) will be able to s e a r c h a s u b s t i t u t i o n s o l u t i o n w h e n a d i s t u r b a n c e occurs. To m e e t a m a n u f a c t u r i n g order, several T P P m a y be used to obtain one s a m e product. In t h e s a m e way, w i t h i n a route, for c e r t a i n o p e r a t i o n s , s e v e r a l m a c h i n e s m a y be used. This flexibility knowledge about the product should be described to give the operators and the software a capability to react a n d a d j u s t the plan. All t h e s e possible choices ( o p e r a t i n g mode, m a c h i n e configuration, route,...) m a y be guided (or inferred) by an Analysis of the set of m a n u f a c t u r i n g orders
236 sent by the MTMS. This analysis may be made by a rule-based expert system [SUN.S9]. 3.3.1.2.
History
This part of the Knowledge-base concerns the record of the FMS operation and its Control Software. The history of the shop allows operators or software to compare present situations with past situations. We propose to classify this historical knowledge into four parts: - Disturbance situations, - Strategies used to solve disturbances situations, - AI solving strategies for generic situations, - Statistics about each route type. 3.3.1.3. Knowledge about Man-Machine Interactions This p ar t of the Knowledge-base is concerned with the m a n n e r to introduce situations to the Decision-Makers. In a disturbance situation, the FMS Control Software must show the operator the identified situation and the result of the Dynamic Control analysis (Auscultation, Diagnosis and Therapy). But, according to the disturbance situation and to the operator, the Man-Machine Interactions are different. So, the FMS Control Software m u s t a d a p t its interface and must learn new ways of presentation. 3.3.1.4.
Knowledge about Dynamic Control
This part of the Knowledge-base is concerned with how to use the Flow-Profiles and M a n u f a c t u r i n g E n v i r o n m e n t Multi-graph tools to solve d i s t u r b a n c e problems [ARC.91-3]. 3.3.2.
Principle
of Human
know-how
and knowledge integration
Formalising H u m a n know-how is difficult, which makes it necessary to adopt a p r a g m a t i c approach. Today, in FMS Control, we are not capable of p r o g r a m m i n g the computer learning of H u m a n know-how. So, we propose a progressive integration by defining Software Intelligence Levels (Esprit Project n~ [Milin 87]). The principle of this approach is to integrate gradually H u m a n know-how by observing Man-Machine Interactions. This allows to develop the software step by step without re-programming the lower levels.
237 Intelligence Man-Machine Interactions
Software Level in project More abstract Software Levr
More deterministic and less abstract Software Level
Figure
32:
Integration
of Human know-how Levels
in Software
Intelligence
The intelligence of a Software Level is related to the lower levels a l r e a d y implemented. In such a structure, the capabilities of the new level become simple functions of the new software. Once i m p l e m e n t e d , t h e y are not intelligent any more. Then, Intelligence is in the user and in the way to use these new functions. Accordingly, we have to analyse how this is done and try to design the new software level. So, in order to integrate knowledge in the FMS Control Software, we propose the following steps : - O b s e r v e and record the FMS Control Software operation including the Man-Machine Interactions; - A n a l y s e the previous records to define new concepts in the Knowledge-base; -Design a Man-Machine Interface to allow operators to use this Knowledge-base convivially; - O b s e r v e and record the Man-Machine I n t e r a c t i o n s on this new interface to identify generic behaviours; - Design and program new functions using the new concepts of the Knowledge-base.
3.4.
Building the processing modules.
Each processing module is a instance of an object Application.
object Application)
(objectViewl)
(objectView2)(
objectViewn )
F i g u r e 33 : Object s t r u c t u r e of a p r o g r a m .
238 An application is a t a s k or a computer job. It m a n a g e s several views. A view is generally located in a window. The skeleton of the object Applications depends on the Graphic E n v i r o n m e n t used (X-Windows, Windows, Motif, OpenLook, Macintosh,...). P r o g r a m m e r s should refer to the related "toolbox". 3.5.
Building Man-Machine
interfaces.
Before p r o g r a m m i n g i n t e r f a c e s , one should a n a l y s e the M a n - M a c h i n e Interactions precisely [BOY 92]. This can be done by the Scenario Method based on the analysis of Decision Activities, whose operating mode depends both on Man and Machine t h r o u g h an interface. When the scenarios are defined, the interface screens or windows m u s t be specified. Each interface is an instance of the object View. P r o g r a m m i n g a Man-Machine interface is very expensive. T h a t is why, it is i m p o r t a n t , for the work to be reusable, to build software components i n d e p e n d e n t l y of computer languages and m a c h i n e s [NEE.90]. For this, Graphic Abstract Data Type is a good tool to design the more difficult part of an interface: namely the Interactive Diagram. 3.5.1.
Scenarios Method to define Man-Machine Interactions.
This p a r t presents an analysis and design method for Interactive Decision Aid S y s t e m s using advanced M a n - M a c h i n e Interfaces (pull-down m e n u s , multiwindowing,...) [BER 90]. The basic principle is the same as in the GRAI's method: decision activities are first analysed, then those supported by Man and Machine both are detailed. To build a scenario it is necessary to identify Man actions a n d M a c h i n e actions and t h e r e f o r e the e v e n t s r e l a t e d to the synchronisation of these actions. First, we will present a form of GRAI net adapted to the modelling of ManMachine Decision Activities. Then, the second tool is the scenario using a three columns table for stating Man-Machine Interactions and Events. 3.5.1.1.
Man-Machine Decision Activities
Man reasoning may be characterised by active phases (Decision Activity) and passive phases (Decisional Situations). These two concepts and the Activity and E v e n t concepts in Discrete Event Modelling are very similar. To describe a reasoning process is to define and relate all these active and passive phases. The GRAI Net is used to m a k e a global description of the reasoning process as shown in figure 34.
239 F i g u r e 34 : D e c i s i o n A c t i v i t y w i t h
Man-Machine Interactions
E a c h Decision A c t i v i t y b e g i n s w i t h a n initial s i t u a t i o n Si a n d e n d s w i t h a final s i t u a t i o n Sj. E a c h d e c i s i o n a l s i t u a t i o n is a s t e p in t h e r e a s o n i n g p r o c e s s , c h a r a c t e r i s e d by a s c r e e n E l . T h e D e c i s i o n A c t i v i t i e s w i t h M a n - M a c h i n e I n t e r a c t i o n s a r e s u p p o r t e d b o t h by M a n M a n l a n d M a c h i n e M 1 . In t h e u p p e r l e f t - h a n d c o r n e r it is i n d i c a t e d w h e t h e r t h e s u p p o r t is t h e M a i n or a S e c o n d a r y s u p p o r t . T h e M a i n s u p p o r t m a n a g e s t h e I n t e r a c t i v e process. B e t w e e n t h e s e two s u p p o r t s , a t r a p e z i u m f o r m a l i s e t h e i n t e r f a c e I n t l . T h e E i s c r e e n s c h a r a c t e r i s e t h e decisional s i t u a t i o n s a n d a r e specified by : -
t h e list of active p u l l - d o w n m e n u s , t h e list of o p e n e d w i n d o w s a n d the active w i n d o w Fi, t h e objects (icons), o u t s i d e t h e w i n d o w s , a copy of t h e s c r e e n in its m o r e classical state. Overload Situation
Sj - an origin is f o u n d Simulate and evaluate the effect of a modification SI=Si Q
k = situation without overload
F i g u r e 35 : D e c i s i o n P r o c e s s w i t h M a n - M a c h i n e I n t e r a c t i o n s
240 F i g u r e 35 s h o w s a n e x a m p l e of Decision P r o c e s s w i t h M a n - M a c h i n e Interactions. The objective is to solve an overload problem before scheduling. This iterative Decision Process consists of two activities: - the first activity is concerned with the search for the origin of the overload; it is driven by the m a n aided by the m a c h i n e (H1 is the m a i n support), -the second a c t i v i t y a i m s at m o d i f y i n g the p l a n a n d m a k e a s i m u l a t i o n to e v a l u a t e t h e consequence of this modification; it is driven by the computer (M1 is the m a i n support); two s i t u a t i o n s m a y be obtained Sl--Si w h e r e there is still an overload and S k w h e r e the overload problem is solved. Two different interfaces I n t l and I n t 2 support this interaction. 3.5.1.2.
Scenario
To define the scenario concept, we have to recall the two m a i n types of ManM a c h i n e Dialogue" - t h e modal dialogue, - t h e non-modal dialogue. T h e m o d a l d i a l o g u e is r u n u n d e r c o m p u t e r control. This dialogue asks a precise i n f o r m a t i o n from the h u m a n operator. As long as the m a n has not given his a n s w e r w i t h i n the f r a m e defined by the dialogue, he c a n n o t t a k e a n o t h e r step. This type of dialogue is i n t e r e s t i n g w h e n there is a risk of d a t a incoherence. This mode is easy to m a n a g e (and to p r o g r a m ) b u t it is h a r d l y interactive. The n o n - m o d a l d i a l o g u e is r u n u n d e r m a n control. He is free to select a m e n u , to activate a window or any object on the screen. This type of dialogue is highly interactive and allows a software to help a h u m a n user efficiently. A M a n - M a c h i n e scenario has to characterise these two interaction modes. It is composed of a t h r e e - c o l u m n table" - the first column describes m a n actions ( A m a n i), -the second one c o n t a i n s t h e e v e n t s e i and s c r e e n s Scri c h a r a c t e r i s i n g the beginning of a m a n or m a c h i n e action, - the t h i r d one defines the machine actions (Am i).
Menu: New model
Scri
Mouse: Close window
~
Open window
.1~
Aman
Save Dialog ~
Am
Scrj F i g u r e 36 : E x a m p l e of a s c e n a r i o E v e n t s are symbolized by arrows (figure 36).
241 E a c h Decision Activity is generally detailed by a scenario. T h a t is w h y it begins w i t h a s c r e e n S c r i (initial s i t u a t i o n ) a n d ends w i t h a s c r e e n S c r j (final situation). T h i s e x a m p l e shows t h a t a m a n action on the m e n u : N e w mode l leads to open a window. The scenario of figure 37 describes a Decision Activity b e g i n n i n g w i t h a m o d a l dialogue. The initial screen S e r i leads n e c e s s a r i l y to the m a n action A m a n l which leads to m a c h i n e action A m l . The end of the Decision Activity is decided by m a n action A m a n 2 which a u t o m a t i c a l l y leads to m a c h i n e action A m 2 a n d screen S c r j (final situation).
Aman
-----Tscri
I
AmX
I ]
Aman2 S
c
r
I
--- Am 2 j
~
F i g u r e 37 : S c e n a r i o w i t h e v e n t s l i n k e d to initial a n d final s i t u a t i o n s
Aman 1
Scri
Aman2
~lP.-
Am 1
~~.-
Am 2
Scrj F i g u r e 38 : S c e n a r i o w i t h n o n - m o d a l d i a l o g u e In figure 38, all the a r r o w s of the scenario go from m a n to m a c h i n e . No e v e n t a s k s for a c o m p u l s o r y r e s p o n s e from m a n . He can choose freely b e t w e e n A m a n l or A m a n 2 action. This is a purely non-modal scenario.
Aman 1
Scri
Aman2 .At--""
Am 1 ~lP--
Am 2
Scrj F i g u r e 39 : S c e n a r i o w i t h m o d a l d i a l o g u e F i g u r e 39 r e p r e s e n t s a p u r e l y m o d a l scenario. M a n action A m a n 2 consequence of m a c h i n e action A m 1 . 3.5.2.
is the
G r a p h i c A b s t r a c t D a t a T y p e s t o specify I n t e r a c t i v e D i a g r a m s .
G r a p h i c A b s t r a c t D a t a Types are a w a y to describe an I n t e r a c t i v e D i a g r a m i n d e p e n d e n t l y of a p r o g r a m m i n g l a n g u a g e . The a i m is to f o r m a l i s e t h e I n t e r a c t i v e D i a g r a m at two levels:
242 -its - its
g e o m e t r i c form, behaviour.
A G r a p h i c A b s t r a c t D a t a Type is c o m p o s e d of t h r e e parts: - a g e o m e t r i c form a n d its v a r i a b l e s , attributes, -methods describing the dynamic Diagram. -
behaviour
of t h e
Interactive
H e r e is a n e x a m p l e of a g e o m e t r i c form a n d of some of its v a r i a b l e s . H1 a n d Lc a r e t w o v a r i a b l e s c o r r e s p o n d i n g r e s p e c t i v e l y to t h e h e i g h t of a line a n d t h e w i d t h of a c o l u m n . T h e v a r i a b l e s a r e r e l a t e d to t h e g e o m e t r i c f o r m of t h e Interactive Diagram. If we u s e t h i s basic A b s t r a c t D a t a T y p e to define a R e s o u r c e G a n t t D i a g r a m , a line is a s s o c i a t e d to a r e s o u r c e a n d a c o l u m n to a period. T h e s e d e f i n i t i o n s a r e a t t r i b u t e s of t h e G r a p h i c A b s t r a c t D a t a Type. T h e a t t r i b u t e s a r e r e l a t e d to t h e s e m a n t i c c o n t e n t s of t h e I n t e r a c t i v e D i a g r a m . T h e classical m e t h o d s are: - c r e a t i o n of a n e w I n t e r a c t i v e D i a g r a m , - d e s t r u c t i o n of a n I n t e r a c t i v e D i a g r a m , - drawing method, - access to a t t r i b u t e s a n d v a r i a b l e s , - m a n a g e m e n t of m o u s e actions, m e n u actions, k e y b o a r d a c t i o n s . . . (xo,Yo) (o,o) Horizontal a line is a resource ........ .........:~:~:!~' i:.l Vertical Scale
~HI Graph
i a column 9,
.
F i g u r e 40 : G e o m e t r i c f o r m o f a G r a p h i c
Abstract
Data
Type
T h e following G a n t t D i a g r a m , L o a d D i a g r a m a n d D a y p l a n n i n g D i a g r a m a r e t h r e e e x a m p l e s i n h e r i t e d from this G r a p h i c A b s t r a c t D a t a Type.
243
Milling man Milling dnc
, ~ - ~ - ~ - ~ - ~ - ~ - ~ - ~ - ~ , - ~ - ~ - ~ . - ~ 9 . 9
"
Milling x25
:
9
l el i i~ i ~ l
~ l
:
....
I~lll~Ulllllill
."
.
~
9
DNC7222
1
DNC651
.
Tool 621 Painting _
I
I
!
.
I
.
.
I
.
.
Control 1
"
i.
i
i,
9
"
"
"
"
I
!
1
1
.-
~ ' ~ " ~ " ~ " ~ ' ~ ' ~ ' ~ " ~ _, .
i
I .......
.
"
~ ^ ^ ^
.
i
"
.
9. . . .
.
.
I
~
9
.....
.
-;____~%'~'~v~l
.
.
9 i
~
~
9
Z-
.
..~l~.l~.l~.l~.~_. . .
i
~
"
Washing
41 : Example
Figure
of Gantt
Diagram
9
.
l"- Il l l l!i'l l l li_ vac.
Figure
Monday 9 /
.
,i
.
i
~, /
.
42 : Example
Tuesday
i
,i
.
./
.
.
.
of Load Diagram
Wednesday .
~
.
Thursday :~....~i~
Friday
.........
-~ % % % % % % % % % % % % % % % ,"
/
s,
,,r
/
/
8h-15h
"."
/
,t
,,,,
... ..
./' . " ,,
t ,~ / / / / ,s / # % % % % % % % % ,, ,,, ,,, ,,, ,s / / ,,, ,,,
.% .% . %. %. %. %. .% r
,t
/
/
/
/
% ,s ,~ t .
9' " - ' " " " - " - ' " - ' " - ' " - ' ' -
......
...
.....~: ..:.~.,..:. . . . . :.
:
i
i
: ..:..
a .
.
.
.
--
.
.
.
.
.
' '== 8h-20h .
.I:.:?:..:"Z.....
". . . . . . . . : .
I
10h30 -20h - -
Figure
43 : Example
of Day planning
Diagram
Day of rest
244 This generic approach presents a n u m b e r of advantages: it gives added precision to the model, it m a k e s generalisations easier, it helps software development, it defines a software component independently of computer languages, these software components may be specified by users, it facilitates automatic generation of programs. 3.6.
Elaboration of a suitable programming
language.
The choice of a suitable p r o g r a m m i n g language has to be made according to the following criteria : -Modelling c a p a b i l i t y : t h e p r o g r a m m i n g data types of the language should facilitate the description of the various models used in the Software; to program lists and trees, the data type pointers and handles m u s t exist. - R a p i d i t y 9 to compute the scheduling algorithm or to search in graphs, the l a n g u a g e have to be very quick. So, it is not possible to use an Artificial Intelligence P r o g r a m m i n g E n v i r o n m e n t based on Lisp or Prolog. We therefore need a procedural language. -Objects 9 the conceptual models for Controlled FMS, for Software A r c h i t e c t u r e or for I n t e r a c t i v e D i a g r a m s are b a s e d on objects. Therefore, we need an object-oriented l a n g u a g e to p r o g r a m t h e s e models. - Reusability o f t o o l s : This criterion may be regarded as reusability of software components : - w i t h i n one same software, - from an FMS Planning and control software to another one, - f r o m an FMS P l a n n i n g and control software to a n o t h e r P l a n n i n g and control software applied to a correlated problem such as Course Scheduling, Project planning,... For this, the language m u s t support the notion of encapsulation to build software components (with one interface part and one i m p l e m e n t a t i o n part ). - P o r t a b i l i t y : the software m u s t be portable from a platform (hardware, operating system, multi-windowing environment) to a n o t h e r one. - I n t e r a c t i v i t y 9 this criterion is very much linked to the multi-windowing e n v i r o n m e n t . Today, t h i s c r i t e r i o n is often i n c o m p a t i b l e w i t h portability; choosing a common object library is a way to increase portability. C++, ADA or an Object Pascal may be good choices for the basic language. The choice of the Basic Object library will be made so t h a t it r u n s on several computers and operating systems. 3.7.
Development
methodology.
Once a processing module or program is specified, we need a method to write the program, to modify it and to rationalise its structure in order to m a k e it reusable [SAR.93].
245 MODEL
PHASIS
Object l i b r a r y of programming environment
Data
First object Specific Object l i b r a r y for Planning a n d ~ Control S t r u c t u r e of the main orogram
;pecific Object l i b r a r y for FMS Planning a n d _ Control
Definition of a subset of classes for the Model
5
I Testing a n d i n t e g r a t i o n in the m a i n o r o g r a m
Scenarii m e t h o d gives the user specifications
Writing of a set of m e t h o d s on a given subject
PROTOTYPE
PHASIC
Complete object Modification of the objects c o n c e r n e d Testing a n d i n t e g r a t i o n in the m a i n p r o g r a m and validation of m e t h o d s ng of a set of m e t h o d s on a given subiect Rational|sat|on Modification of the objects c o n c e r n e d
12
esting a n d v a l i d a t i o n
F~ Figure
44
9 Programming
Rational|sat|on
Methodology
~ - ~
246 Today, we are not able to design a final interactive program directly. Even with methods like the Scenarii Method, it is necessary to test the feasibility of the most interactive functions with the future users. So, the development methodology is an iterative process consisting of two m a i n phases [BER 91]: - t h e Model phasis aims at validating the m a i n concepts of the program, to prove its feasibility. This phasis consists in defining a first h i e r a r c h y of object classes and testing its capability to model simple cases. Only the main interactive functionality is p r o g r a m m e d to show the principle of Man-Machine Interactions. - t h e Prototype phasis gives the first program t h a t can be used for real cases. The P r o t o t y p e m u s t realise all the f u n c t i o n a l i t i e s described by the scenarii method. The flow d i a g r a m shows the successive steps of the m e t h o d and the m a i n supports of these phases: - the Scenarii Method gives the user specifications, - three object libraries are used to build the program: -Basic Object library of p r o g r a m m i n g environment, - Specific Object library for Planning and Control, - Specific Object library for FMS Planning and Control. The Basic Object library belongs to the p r o g r a m m i n g e n v i r o n m e n t and m u s t not be modified by the program. This library allows to m a n a g e the basic elements of the software: files, mouse and keyboard, menus, screens and windows, basic controls of the windows such as buttons, scroll bar, pictures,... All the programs in the FMS Software must use the same Basic Object library. The Specific Object library for Planning and Interactive Gantt Diagrams, Calendars, Tasks,... Many concepts of the Kernel Model library. For the purpose of FMS Control they fit better with FMS modelling.
Control concerns objects such as Resources, P r o d u c t s , R o u t e s , are inherited from objects in this can be modified by inheritance to
The Specific Object library for FMS P l a n n i n g and Control contains all the objects designed specifically for our software. They may be inherited from the two other libraries. The objects m u s t be able to be used in several programs of the software. The use of this three related libraries is a good m a n n e r to save time (and money) w h e n p r o g r a m m i n g an FMS P l a n n i n g and Control S o f t w a r e . Reusability of objects saves time, in addition, encapsulation of code avoids wasting time in debugging programs. MODEL PHASIS Step 1 :
D a t a Dictionary
It is a classical step in p r o g r a m analysis. It consists in describing all the d a t a entities with t h e i r a t t r i b u t e s and relations. Most of these entities have to become objects.
247
Step 2:
First object hierarchy The F i r s t object h i e r a r c h y is d e s i g n e d from the D a t a Dictionary. It is an object h i e r a r c h y specific to our problem. The rules to choose which objects have to be created are issued from the two specific Object libraries and from the know-how of object p r o g r a m m i n g in the e n v i r o n m e n t t h a t has been chosen.
Step 3"
Structure o f the main program The S t r u c t u r e of the main program is directly related to the p r o g r a m m i n g e n v i r o n m e n t and to its Basic object library. Each environment has its own way to organise the skeleton of a main program. This step is also concerned with the design of main m e n u s and windows.
Step 4:
Definition o f a subset o f classes for the Model The purpose of the Model is to test the feasibility of the m a i n concepts concerning the program. So, this step selects a set of classes t h a t are significant for these concepts.
Step 5"
Testing a n d Integration in the main program The aim is to achieve c o m p a t i b i l i t y b e t w e e n the object h i e r a r c h y designed for our FMS Control problem and the more s t a n d a r d object structure of the main program.
Step 6"
Writing o f a set o f methods on a given subject The global s t r u c t u r e of the p r o g r a m is now defined. The p r o g r a m m i n g job begins. Steps 6, 7 and 8 are a loop. For each loop, a subject is chosen (for instance, saving objects in the Database) and all the related methods are programmed for all the objects concerned.
Step 7"
Modification o f the objects concerned P r o g r a m m i n g an object m e t h o d m a y lead to modify an attribute of the object or the interface (external view) of another object.
Step 8"
Testing and validation of methods This step builds simple cases to use and validate the method algorithms.
PROTOTYPE PHASIS Step 9"
Complete object hierarchy F r o m the first object hierarchy and the results of the Model this step builds the object h i e r a r c h y specific to FMS. Some attributes are added to model FMS real cases better.
248
Step 10:
Testing and Integration in the main program Idem step 5
Step 11:
Writing o f a set of methods on a given subject Idem step 6
Step 12:
Modification of the objects concerned Idem step 7
Step 13:
Testing and valhtation of methods Idem step 8
Rat/ona//sat/on The r a t i o n a l i s a t i o n step aims at c r e a t i n g or u p d a t i n g objects a f t e r a d e v e l o p m e n t phasis. It is a t e a m work b e t w e e n p r o g r a m m e r s b u i l d i n g different p a r t s of the same software. Even if this step is not included in the d e v e l o p m e n t methodology, it is very i m p o r t a n t to improve both specific libraries. The more extended these libraries will be, the less expensive the programs will be to develop.
4.
Conclusion
FMS P l a n n i n g and Control is an interdisciplinary field. Required tools come from O p e r a t i o n a l R e s e a r c h , C o n t r o l T h e o r y , S o f t w a r e E n g i n e e r i n g , M a n u f a c t u r i n g Systems Modelling. To design an efficient Software Architecture we t h i n k t h a t it is n e c e s s a r y to have a global and integrated approach of the problem. We therefore propose to view this problem as a Control Problem, as the main objective is to guide the FMS towards m a n u f a c t u r i n g objectives defined by the upper Decision Levels. In order to m a s t e r the complexity of FMS our basic option is to design a convivial Control Software. The second option is to design an Open a n d Evolutive System. The p r o g r a m m i n g option to choose an object e n v i r o n m e n t allows to r e u s e software components and to realise a true Open and Evolutive Software. So, it is a good way to a t t e m p t to reduce prohibitive development and m a i n t e n a n c e costs. To continue and to improve the efficiency of the Control S y s t e m we use a m u l t i p l e - a g e n t a p p r o a c h . To put it shortly, this approach t r a n s f o r m s each object into an agent by giving it an objective to reach and its own knowledge. The scheduling a l g o r i t h m is based on a cooperative a g e n t net. It m a y be activated according to several strategies depending on the a g e n t s u m m o n e d . For instance, it is possible to activate only one operation agent or one machine agent. In t h a t case, the agent activated controls the algorithm by exchanging m e s s a g e s w i t h others. So, the s c h e d u l i n g a l g o r i t h m p o s s e s s e s s e v e r a l strategies according to the agent activated. Each agent is potentially an input
249 point of the algorithm. This operation structure should improve the scheduling algorithm flexibility. On-line and dynamic control will be able to use it to make p a r t i a l plans. This should also help users to enter t h e i r s decisions more quickly and to obtain partial plans more easily.
5.
Biblio
[ARC.87]
raohv
ARCHIMEDE B., D6veloppement du noyau de l'outil de simulation SIMGRAI et des outils logiciels pour le t r a i t e m e n t des r6seaux de donn6es, M6moire de DEA, Universit6 de Bordeaux 1, Septembre 1987. [ARC.91-1] B. A R C H I M E D E - C o n c e p t i o n d'une a r c h i t e c t u r e r 6 a c t i v e distribu6e et hi6rarchis6e pour le pilotage des s y s t ~ m e s de production - Th~se de doctorat - Universit6 de Bordeaux 1.1991. [ARC.91-2] B. ARCHIMEDE, L. PUN, C. BERARD, G. DOUMEINGTS - RealT i m e D y n a m i c a l D i a g n o s i s in t h e C o n t r o l of F l e x i b l e M a n u f a c t u r i n g System - IMACS S y m p o s i u m - 7,10 Mai 1991 Casablanca, Maroc. [ARC.91-3] L. PUN, B. A R C H I M E D E , C. BERARD, G. D O U M E I N G T S I n t e l l i g e n t L e a r n i n g - a i d for an I n t e l l i g e n t F M S - M o n i t o r i n g Process - CIRP Workshop on intelligent Learning M a n u f a c t u r i n g System - March 6,8 1991 - Budapest. Ch. BERARD, D. BREUIL, G. DOUMEINGTS & L. PUN. Decision [BER.81] aid in job shop production. 6th I n t e r n a t i o n a l Conference on Production Research, Novisad, Yougoslavie (August 1981). BERARD Christian, Contribution h la conception de s t r u c t u r e s [BER.83] logicielles pour le pilotage d'atelier, Th~se de Docteur-Ing6nieur, Universit6 de Bordeauxl, Janvier 1983. C. BERARD, A. GUDEFIN, A. BOURELY, G. D O U M E I N G T S . [BER 85] "SIMGRAI : a new tool to s i m u l a t e m a n u f a c t u r i n g systems". IMACS, Oslo, Norv~ge (August 1985). C H R I S T I A N BERARD, GUY D O U M E I N G T S . - M a n - M a c h i n e [BER 87] Communication Analysis in a Decision Aid System for Controlling M a n u f a c t u r i n g Activities - New Techniques and Ergonomics, Hermes, Paris, 1987, p.68-81. [BER89] B E R A R D C h r i s t i a n , L.T.N. S E G U I N , A. D u p e u x , M a n u e l d ' u t i l i s a t i o n de SIPA+, l a b o r a t o i r e GRAI, U n i v e r s i t 6 de Bordeauxl, Janvier 1991. [BER90] C. B E R A R D , Ph. N G U Y E N . I n t e l l i g e n c e A r t i f i c i e l l e et Productique, IFIP: "M6thode des scenarii: Analyse et Conception des interfaces Homme/Machine", Bordeaux, (Mai 1990). [BER91] BERARD Christian, Les R6seaux de Donn6es, r a p p o r t interne, laboratoire GRAI, Universit6 de Bordeauxl, Janvier 1991. [BOC.91] BONNEVAL A., COURVOISIER M., COMBACAU M., FMS Realtime Monitoring: Decision-Making Aspects in Automatic Recovery, C o m p u t e r A p p l i c a t i o n s in P r o d u c t i o n a n d E n g i n e e r i n g . , IFIP,1991, p. 409/416. [BON. 91] C. BONNEMOY et S.B. HAMMA, La m6thode du recuit simul6 optimisation globale dans R n, RAIRO Vol 25, N~ 1991 (477-496)
250 [BOW.91] [BOY. 92] [BUR.86] [COU.89]
[DOU.84] [DOU.90] [DOU.87]. [ELO. 92] [GRA.91]
[GUY 91] [HUT.91] [JON.85] [JON.90] [KAL.85] [KAL.85] [KER.93]
[LEC 90]
R.BOWDEN, J.BROWNE, Approach to the production environment design task within factory coordination, Computer I n t e g r a t e d Manufacturing Systems, Vol.4 N~ February 1991 pp 42-50. BOY G., M~thodologies et outils pour l ' I n t e r a c t i o n HommeMachine, M~moire d'habilitation, Universit~ Paris 6, Juin 1992 BURBIDGE J. L., Production flow analysis, International Journal of Production Research, Octobre 1986. COURVOISIER M., VALETTE R., SAHRAOUI A., COMBACAU M., Specification and implementation techniques for multilevel control and m o n i t o r i n g of FMS, C o m p u t e r Applications in Production and Engineering., IFIP,1989, p. 509/516. DOUMEINGTS G., M~thode GRAI: m~thode de conception des syst~mes en productique, Th~se d'~tat, Automatique, Universit~ de Bordeaux I, 13 Novembre 84, 519 p.. D O U M E I N G T S G., M~thode pour concevoir et specifier les syst~mes de production, L a b o r a t o i r e GRAI, U n i v e r s i t ~ de Bordeaux I, CIM 90,Teknea, p. 89/103. DOUMEINGTS G., DARRICAU D., POUMEYROL E. et ROBOAM M., La m~thode GRAI, Cours de l'Universit~ de Bordeaux I, 1986 / 87, 43 p. A. ELOMRI, M~thodes d ' o p t i m i s a t i o n d a n s un c o n t e x t e productique, Th~se de Doctorat de l'Universit~ Bordeauxl, 1992 PETER O'GRADY, RAMADURAI SESHADRI, X-Cell intelligent cell Control using object-oriented programming (part I), Computer Integrated Manufacturing Systems, Vol.4 N~ August 1991 pp 157163. GUYOT J e a n Edouard, Les outils de r~action du module PCS (Planification, Conduite, Suivi), laboratoire GRAI, Universit~ de Bordeauxl, M~moire DEA, Septembre 91. HUTCHISON Jim, LEONG Keong, SNYDER David, WARD Peter, S c h e d u l i n g a p p r o a c h e s for r a n d o m job shop flexible manufacturing systems, Prod. Res., vol 29,n ~ 5,1991, p. 1053/1067. J O N E S A., MCLEAN C., A Production Control Model for the AMRF, Proceedings of the International ASME Conference on Computers in Engineering J O N E S Albert, SALEH Abdol, A m u l t i - l e v e l / m u l t i - l a y e r architecture for intelligent shopfloor control, Computer Integrated Manufacturing, vol 3 ,n ~ 1,1990, p. 60/70. KALLEL G., PELLET X., BINDER Z., Conduite d~centralis~e coordonn~e d'atelier, R.A.I.R.O., APII, vol 19,n ~ 4, 1985, p. 371/ 387. KALLEL Ghazali, Proposition d'une COnduite DEcentralis~e COordonn~e(CODECO) pour un atelier de fabrication, Th~se de Docteur, Institut National Polytechnique de Grenoble, Juin 1985. L.KERMAD, C.AUSFELDER, J.P. BOUREY, E CASTELAIN, Integrative approach for a functional specification of FMS Control, C o m p u t e r I n t e g r a t e d M a n u f a c t u r i n g S y s t e m s , Vol.6 N~ November 1993 pp 219-227. LECLERC Christophe, Aide au pilotage: R~alisation d'une architecture multit~ches pour le pilotage temps r~el de l'atelier,
251
laboratoire GRAI, Universit~ de Bordeauxl, M~moire d'ing~nieur, Septembre 90. LE GAL A., Un syst~me interactif d'aide ~ la d~cision pour le [LEG.89] l'ordonnancement et le pilotage en temps r~el d'atelier, Th~se de Doctorat, Universit~ Paul Sabatier de Toulouse, Septembre 1989. [MAD.90] H.K.MADHUSUDHANA, KRIPA SHANKA, FMS s i m u l a t i o n model u s i n g P C - S I M S C R I P T II.5, C o m p u t e r I n t e g r a t e d Manufacturing Systems, Vol.3 N~ August 1990 pp 150-156. [MAH.90] MAHMOODI F., DOOLEY K. J., STARR P., An investigation of dynamic group scheduling heuristics in a job shop m a n u f a c t u r i n g cell, Prod. Res., vol 28,n~ p. 1695/1711. [MER.93] K. M E R T I N S , W . S U S S E N G U T H , I n t e g r a t e d i n f o r m a t i o n modelling for CIM, Computer Integrated Manufacturing Systems, Vol.4 N~ August 1991 pp 123-131. MILIN : "Amelioration de solutions d'ordonnancement pour l'aide [MIL 87] au pilotage d'ateliers", Th~se d'universit~: Automatique: Bordeaux I:1987. [MON.90] MONTAZERI M., VAN WASSENHOVE L. N., A n a l y s i s of scheduling rules for an FMS, Prod. Res., vol 28,n ~ 4,1990, p. 785/ 802. [MUK.91] MUKHOPADHYAY S. K., MAITI B., GARG S., Heuristic solution to the scheduling problems in flexible m a n u f a c t u r i n g system, Prod. Res., vol 29,n ~ 10,1991, p. 2003/2024. Francis NEELAMKAVIL, Development of graphical software for [NEE.90] CIM applications, Computer Integrated Manufacturing Systems, Vol.3 N~ August 1990 pp 157-162. PACHET F., Representation de connaissances par objets et r~gles: [PAC 92] le syst~me N~Opus, Th~se de Doctorat : Informatique option Intelligence Artificielle, Universit~ Paris 6, Septembre 1992 PELLET X., Sur la hi~rarchisation des d~cisions. Application ~ la [PEL.85] c o n d u i t e d ' a t e l i e r , Th~se de Docteur, I n s t i t u t N a t i o n a l Polytechnique de Grenoble, 1985. PLOBNER Alain, M~thodes de conception et de d~veloppement des [PLO.84] logiciels de pilotage d'unit~s de production, Th~se de Docteur ing~nieur, Universit~ de Bordeaux 1, 1984. PORTMANN M. C., M~thodes de d~composition s p a t i a l e et [POR.88] temporelle en o r d o n n a n c e m e n t de la production, R.A.I.R.O., APII, vol 22,n ~ 5, 1988, p. 439/451. P O R T M A N N M.C.,M~thodes de d~composition s p a t i a l e et [POR.87] temporelle en ordonnancement de la production, Th~se de doctorat d'~tat ~s sciences, Universit~ de Nancy 1, Septembre 1987. [PUN 83] L. PUN, G. DOUMEINGTS, A. BOURELY. "GRAI Methodological Approach to the design of Flexible Manufacturing". ICPR 83, Windsor, Canada (August 22-24 1983). [PUN 84] L. PUN. Syst~mes industriels d'Intelligence Artificielle - Outils de Productique. Editions : Editest en fran~ais (1984), Plenium en anglais (1986), Friendship en chinois (1986). [ROU.88] ROUBELLAT F., THOMAS V., Une m~thode et un logiciel pour l'ordonnancement en temps r~el d'ateliers, R.A.I.R.O., APII, vol 22,n ~ 5, 1988, p. 419/438.
252 [SAN.91] [SAR.93] [SUN.89] [THO.80]
[THO.90]
[TIT.79] [VEE.93]
[WAR.91]
S.P.SANOFF, D.POILEVEY, Integrated information processing for production scheduling and control, Computer Integrated Manufacturing Systems, Vol.4 N~ August 1991 pp 157-163. P.SARGENT, Inherently flexible cell communications : a review, C o m p u t e r I n t e g r a t e d M a n u f a c t u r i n g Systems, Vol.6 N~ November 1993 pp 244-259. SUN QI-ZHI, Expert simulation for online production control, Computer Integrated Manufacturing Systems, Vol.2 N~ August 1989 pp 172-180. THOMAS V., Aide ~ la d~cision pour l'ordonnancement en temps r~el d'atelier, Th~se de 3 ~ cycle, Universit~ Paul Sabatier, Toulouse, 1980. THOMESSE Jean-Pierre, Les services de t e r r a i n FIP et l ' i n t ~ g r a t i o n dans les syst~mes automatisms, Colloque International CIM90, 12-14 juin 1990, p. 565/ 573, Bordeaux, France. TITLI (A.).- Analyse et commande des syst~mes complexes. Toulouse, Cepadues Editions, 1979, 237 p. D.VEERMANI, B.BHARGAVA, M M BARASH, Information system architecture for heterarchical control of large FMSs, Computer Integrated Manufacturing Systems, Vol.6 N~ May 1993 pp 76-92. H.J.WARNECKE, W.DANGELMAIER, Functions and interfaces in a flexible production planning and control system, Computer Integrated Manufacturing Systems, Vol.4 N~ February 1991 pp 3141.
197
FMS P l a n n i n ~ a n d Control -Analvsis a n d D e s i ~ _
_
_
C h r i s t i a n B ~ r a r d a, L u c a s P u n b, B e r n a r d A r c h i m ~ d e c aMaitre de conference au LAP/GRAI Universit6 Bordeaux I, 351 Cours de la lib6ration 33405 Talence (Tel : (33).56.84.65.30 - Fax : (33).56.84.66.44) Email: [email protected], fr bprofesseur honoraire au LAP/GRAI CMaitre de conference ~ l']~cole Nationale d'Ing6nieur 65000 Tarbes
Abstract
:
In this p a p e r FMS P l a n n i n g and Control are regarded as Control problems. Control terminology is used and sometimes re-defined to analyse and design a Convivial FMS Planning and Control System. The objective is to have a unified methodology leading to a specific software. After defining the general concepts, the Analysis phase is concerned with the Modelling tools and techniques used to state the Hierarchical Planning System (called Predictive Control) and the Control System (divided into On-line Control and Dynamic Control). Then the Synthesis phase defines the method to specify and build the final software. This software is designed so t h a t all decisions m a y be made t h r o u g h a dialogue between decision-maker and computer. We call it a Convivial Control.
0
Introduction and problem formulation
The aim of this work is to propose an Analysis and Design Methodology to control FMSs. T h a t leads to specify a Software Architecture allowing to plan and control FMS operation. According to the GRAI terminology [DOU.84], the analysis is based on the two f u n d a m e n t a l concepts of System and Activity. An FMS is composed of two systems : the Physical System and the Monitoring System. Each of t h e m is split into sub-systems and each sub-system into activities. Two sets of activities are considered : Decision Activities when a choice has to be made by a h u m a n operator, and Execution Activities when the operation may be described by a deterministic algorithm. In order to i n t e g r a t e FMS operation in the overall operation of the m a n u f a c t u r i n g system, FMS m a n a g e m e n t is located on a Decision Level closely related to the upper level. In order to s t r u c t u r e our Analysis and Design Methodology we have split the Monitoring System into three parts : Predictive control, On-line control and Dynamic control. To formulate the reaction to d i s t u r b a n c e s we re-define a n u m b e r of t e r m s commonly used in control literature. In fact, controlling a machine is similar to controlling an FMS. But controlling an FMS m a k e s it necessary to specify a more complex technological structure, and to t a k e into account h u m a n decisional factors, various and n u m e r o u s d i s t u r b a n c e s and
198 multiple objectives to reach. This is why we choose to widen the scope of some definitions. To detect and diagnose the origin of a disturbance, we propose to use FlowProfiles presented in [ARC.91-1]. The consequences of a disturbance on the plan are calculated by means of the method of the Minimal Potential-Influence Zone also presented in [ARC.91-1]. The main aim of this paper is to solve FMS control problems convivially. This means t h a t the control software is open to decision-makers : they can enter new constraints and obtain a view of the FMS true state through synthesised graphic diagrams. The co-operation between the decision-makers and the control software is obtained through these interactive diagrams working like input-output devices. Input is used by operators to transmit their choices and output gives information on the situation of the problem-in-process. 1.1.
Role of an FMS in a Discrete Production System
An FMS is a set of machines and equipment which can be reorganised each time a new production program is launched. The objective is twofold : - f a s t adaptation to multiple product types and multiple production program situations, - maximum rate of utilization (100% if possible) of the machines and the equipment. To achieve this aim, two important problems must be solved : - the procurement of materials and articles must suit very closely the m a n u f a c t u r i n g needs, - t h e planning and control of the FMS activities, which become extremely complex, must be very efficient. According to the objectives defined by the long-term m a n a g e m e n t , the medium-term management takes care of two main tasks: - f i r s t , define and realize the procurement program, -second, define the manufacturing program which is realized by the FMS. Therefore, the m a n a g e m e n t of the FMS is a short-term planning and control task.
Procur en~t pro~~n
Medium-Term Management System Orders ~
I Follow-up Performed Orders
/~ements
FMS
Figure
I:
Role
of
an
FMS
199
Each order oi received by FMS has two dates: - di the earliest starting date, - fi the latest ending date. The m a i n objective a s s i g n e d to the FMS by the MTMS ( M e d i u m - T e r m M a n a g e m e n t System) is to perform al_._!lthe orders and meet these two dates. The role of MTMS is to determine the triplets (oi, di, fi) through a hierarchical planning structure described in w 2.1.2.1. 1.2.
Role of an FMS Monitoring System
The m a n a g e m e n t of an FMS is performed by a M o n i t o r i n g S y s t e m . Its objective is to match : - o n the one hand, the m a n u f a c t u r i n g p r o g r a m s r e q u i r e d by the m e d i u m - t e r m planners. - o n the o t h e r h a n d , the r e a l i z a t i o n of t h e s e m a n u f a c t u r i n g programs by the FMS. Practical planning t a s k s : - d e t a i l e d a n a l y s i s of the production p r o g r a m coming from the m e d i u m - t e r m according to the TPP (Technical Process Planning), - e v a l u a t i o n of the m a n u f a c t u r i n g load; if the m a n u f a c t u r i n g load is found insufficient or too important, FMS has to react and ask the MTMS for a modification - e l a b o r a t i o n of a first schedule on the basis of the utilization of the main machines - a n a l y s i s of availability of the logistics (pallets, fixtures, tools, conveyors, set-up problem,...) - r e a d j u s t m e n t of the first schedule according to the results of the analysis (using a Discrete Event Simulation tool) [BER 85], [ARC.87]. Scheduling tasks have to be flexible according to the a m o u n t of time available to obtain a good solution. Strategies and algorithms have to be chosen so t h a t a quick solution may be found. If there is enough time the planning system tries to improve it. I m p r o v e m e n t of scheduling solutions m a y be obtained t h r o u g h an a l g o r i t h m or by a m a n - m a c h i n e co-operation, often by both. We try to determine w h a t strategy, what algorithms and what interfaces are convenient to perform such scheduling tasks. Practical control t a s k s : - e x t r a c t i o n of some o p e r a t i o n s from the p r o d u c t i o n according to the execution of the plan, - dispatching them, - elaboration of the "moving" strategy, - aquisition of "events" from the machines and equipment, - c o m p a r i s o n of FMS true state with plan, - reaction and, if necessary, modification of the plan.
program
200
1.3. FMS Planning and Control viewed as Control problems. In t e r m s of control, FMS planning and control can be divided into three p a r t s each h a v i n g distinct tasks: (a) P r e d i c t i v e c o n t r o l : elaborates adequate schedules to guide the FMS operations. (b) O n - l i n e c o n t r o l : supervises the FMS operation and solves small problems caused by minor disturbances. (c) D y n a m i c c o n t r o l : helps short-term planners to solve big problems caused by i m p o r t a n t disturbances. Those t h r e e types of control are designed to be convivial. There is a big difference b e t w e e n a u t o m a t i c control and convivial control. In a u t o m a t i c control, the control actions are completely predetermined. In convivial control, the real-time control actions are elaborated by exploiting both the n a t u r a l intelligence of the h u m a n monitor, and the artificial intelligence i m p l e m e n t e d in the c o m p u t e r system, so t h a t jointly and convivially, the p l a n n i n g a n d control can be performed efficiently. In such a view of FMS Planning and Control, it is possible to state a generic structure linking the three types of control defined above. Two criteria allow to define t h e m globally: - running mode: p e r i o d i c , e v e n t - d r i v e n or both, - decision level: short or very short term. In this s t r u c t u r e scheduling techniques are used in Predictive Control of course but they are also used in Dynamic Control to react and find a new schedule. The difference is t h a t Predictive Control calculates a global new plan periodically, while Dynamic Control calculates a partial new plan each time a significant disturbance is detected. So, the plan is adjusted as m a n y times as necessary. This plan is used to guide the FMS towards its objectives; it is called the R e f e r e n c e Plan. event-driven Dynamic control
Predictive control
On-line control
Controlled system Figure
2
:
FMS
Planning
and
Control
viewed
as
Control
problems
201 To a n a l y s e those t h r e e control t a s k s it is i m p o r t a n t to define m o r e precisely w h a t a d i s t u r b a n c e is a n d w h a t the types of d i s t u r b a n c e s a n d the types of p l a n are ? 1.3.1.
Disturbances
A d i s t u r b a n c e is an event. It is detected by a difference m e a s u r e d b e t w e e n two events : t h e first one is predictive a n d calculated in the s c h e d u l i n g t a s k , t h e second one is a c q u i r e d from t h e c o n t r o l l e d s y s t e m . T h e e v e n t s m a y be evaluated from several points of view o c c u r r e n c e d a t e , q u a n t i t y o f p r o d u c t , t y p e o f p r o d u c t , q u a l i t y of a product. The problem of the q u a l i t y of a p r o d u c t is e q u i v a l e n t to m e a s u r i n g a q u a n t i t y of product obtained after a control operation on the product. A d i s t u r b a n c e is a more general concept t h a n the error concept (as u s u a l in control l i t e r a t u r e ) ; for us, a n e r r o r is a n e v a l u a t i o n of s o m e disturbances. To define a typology of d i s t u r b a n c e s , we use two criteria: - the t i m e required to react, - t h e consequences on the R e f e r e n c e P l a n if no decision is m a d e . This p l a n o b t a i n e d after a d i s t u r b a n c e w i t h o u t a d j u s t m e n t is called the F o l l o w e d Plan.
So, to define a typology of d i s t u r b a n c e s , we have to define the various types of plans. 1.3.2.
T h e v a r i o u s t y p e s of p l a n s
In an ideal F M S operation, the R e f e r e n c e Plan.
P l a n is identical to the F o l l o w e d
Set of normal plans
~et of plans
bnormal arts
Figure 3 : The various types of plans In a p e r t u r b e d context, the F o l l o w e d P l a n is more or less far from the objectives defined in t h e R e f e r e n c e P l a n . Three sets of plans are considered inside the whole set of possible plans: p l a n s m e e t the m a i n m a n u f a c t u r i n g objectives (to perform all the orders and respect the two dates d i and fi). The R e f e r e n c e P l a n is a n i n s t a n c e of this set.
- The normal
202
- The t o l e r a b l e p l a n s meet a set of tolerable objectives (to perform .a sub-set of the orders and respect the two dates d i and fi with a margin mi). All n o r m a l plans are tolerable. - The a b n o r m a l p l a n s are non tolerable plans. 1.3.3.
Typology of disturbances
Four types of disturbances may be distinguished: The i n c i d e n t s need a light adjustment of the R e f e r e n c e Plan. But the F o l l o w e d P l a n is still a normal plan. The time required to react is not important. On-line control is concerned by incidents. -
E x a m p l e : the duration of an operation is increased because of a machine or a n o t h e r e q u i p m e n t breakdown but the difference is inferior to the predictive margin of the operation. dysfunctions
Dynamic control ~ ~ faults
(
l
intrusions incidents
On-line control ~ ~ shifts
Figure 4 : Typology of disturbances - T h e i n t r u s i o n s are easily detected but need a sophisticated and timeconsuming algorithm to determine the consequences. The F o l l o w e d P l a n is abnormal. The i n t r u s i o n s are treated by Dynamic Control. E x a m p l e : machine breakdown whose duration is superior to the predictive margin of the operation.
- The shifts need not be treated immediately. Generally, the F o l l o w e d P l a n is still tolerable. An accumulation of several shifts may m a k e it abnormal. In this case, the sum of the shifts is called a f a u l t and m u s t be t r e a t e d by the Dynamic Control. On-line control is concerned with shifts.
E x a m p l e : small differences between Reference dates and F o l l o w e d
dates. These differences may be compensated by shifting lightly the next operations. - The d y s f u n c t i o n s are due to a breakdown of the follow-up system. Their t r e a t m e n t m a y take a long time. The F o l l o w e d P l a n is a b n o r m a l . The d y s f u n c t i o n s are treated by the Dynamic Control.
E x a m p l e : a h u m a n operator has forgotten to report the end of an operation. 1.3.4.
On-line control
To s u p e r v i s e FMS execution and solve small problems caused by m i n o r disturbances, the On-line Control is concerned with two main activities: - Dispatching orders and moving products and some equipment,
203 - M a n a g i n g two types of disturbances: shifts and incidents. These d i s t u r b a n c e s are treated by m e a n s of time shifting and techniques u s i n g p e r m u t a b l e operations group [ROU.88] or with a Discrete Event Simulation tool driven by a rule-based expert system [SUN.89].
1.3.5.
D y n a m i c control
To help m e d i u m - t e r m p l a n n e r s solve big problems caused by i m p o r t a n t disturbances, the Dynamic Control has to act as a supervisor for the On-line Control. It uses two tools presented in w 2.1.3 and 2.1.4 : - Flow-Profiles, - M a n u f a c t u r i n g E n v i r o n m e n t Multi-graph. The Flow-Profiles are used to detect a n d d i a g n o s e d i s t u r b a n c e s . The M a n u f a c t u r i n g E n v i r o n m e n t Multi-graph is used to determine the Minimal Potential-Influence Zone of the plan to re-schedule in order to react efficiently. These tools are presented in detail in [ARC.91-1]. 1.3.6.
Predictive control
To be able to guide the FMS towards its objectives, the FMS Control m u s t avoid the Control Reverse phenomenon. This means when the Controlled FMS is no longer guided towards its objectives by the FMS Control. In t h a t case the FMS Control only records the r u n n i n g of the FMS without being able to guide this r u n n i n g . This p h e n o m e n o n occurs when the FMS schedule is not feasible because of the lack of accuracy of the model or because n u m e r o u s and i m p o r t a n t p e r t u r b a t i o n s imply too m a n y c o n s t r a i n t s . The h i e r a r c h i c a l planning s t r u c t u r e aims to avoid this Control Reverse phenomenon. The m a i n objective of Predictive Control is therefore to calculate a set of possible schedules. This activity tries to elaborate schedules, with the following constraints: - meet the date and quantity constraints given by the MTMS, - r u n inside a limited amount of time, - p r o p o s e to the MTMS to relax some constraints if there is a risk of Control Reverse phenomenon, - accept interactive modifications made by a h u m a n operator, - m a x i m i s e flexibility of schedules, i.e. minimise their d i s t u r b a n c e s sensitivity, 1.4.
Development
of the Convivial Control
The development of this convivial control requires analysis and s y n t h e s i s (design of the computer systems). The analysis helps to u n d e r s t a n d , to state the control problems clearly and to solve them. The synthesis allows to build the various components of the computer system (hardware and software), and more particularly, to define an architecture and a methodology to program the software. One i m p o r t a n t objective of the software is to be convivial, therefore analysis m u s t state the interactions between m a n and computer and synthesis has to elaborate a good man-machine interface.
204
Analysis and Problem Solving
0
In the analysis phase, we propose modelling tools and the procedures to use them, in order to solve FMS planning-control problems. First, we present the basic concepts to model the physical system or the FMS controlled system. This model falls into two parts : a kernel, used by all the functions of the Monitoring System, and added elements specific to p l a n n i n g functions. Then, modelling tools for the control system (the monitor) are presented. As our work focused mainly on Predictive Control and Dynamic Control, we have split these tools into t h r e e p a r t s : Predictive Control, A u s c u l t a t i o n a n d Diagnosis for Dynamic Control and Therapy also for Dynamic Control. Modelling tools are used t h r o u g h procedures. Those describe the way these tools m a y be applied to solve planning-control problems convivially. 2.1.
Modelling Languages
The first concepts Oriented Resource the detail
and Techniques.
thing to be modelled is the FMS. For t h a t purpose, we use typical of Discrete E v e n t Model and we s t r u c t u r e t h e m with an Object Approach. Three types of e l e m e n t s are considered : P r o d u c t , and Time. According to the control function using these concepts, level is not the same; so, we organise this model around a kernel.
Then, Predictive Control Model outlines the concepts and principles of the Hierarchical p l a n n i n g and discusses the coordination s t r a t e g y between the Decision Levels. To inspect the FMS operation, we use Flow-Profiles as a modelling tool to reduce the n u m b e r of points to be observed in order to detect disturbances. Flow-Profiles are also efficient to locate the causes of these problems. M a n u f a c t u r i n g E n v i r o n m e n t M u l t i - g r a p h allows to a n a l y s e the effect produced by a disturbance on the reference plan. It determines the Minimal Potential-Influence Zone (MPIZ) of the plan'to re-schedule. 2.1.1.
Modelling the controlled system
Three types of elements have to be modelled : Product, Resource and Time. Product is a generic n a m e for all the m a t e r i a l processed by the FMS. It concerns the modelling of: - t h e description of the flows of products concerned by the FMS, d e s c r i p t i o n of m a i n flows, description of d e t a i l e d i n t e r a c t i o n s between products, main and secondary resources, - t h e TPP (Technical Process Planning), Resource is a generic name for all the equipment used to process the products.
205 It concerns the modelling of: -the m a i n resources" machines, - t h e secondary resources: (pallets, fixtures, tools, conveyors,...); for each of t h e m , the description of t h e i r i n t e r a c t i o n s w i t h m a i n resources and products, -the i n f o r m a t i o n between physical e l e m e n t s allowing to specify dynamic behaviour. Time is a generic n a m e for the elements defining horizon, period, calendar, interval of time. All these elements need: -a d e s c r i p t i o n of the d a t a defining t h e i r s t a t i c a n d d y n a m i c attributes, - a d e s c r i p t i o n of the rules defining t h e i r d y n a m i c b e h a v i o u r according to the state of the other interrelated elements. Two types of dynamic behaviour have to be specified separately: - t e c h n o l o g i c a l b e h a v i o u r linked to the physical s t r u c t u r e of the modelled element, - m a n a g e r i a l behaviour linked to some choices on the way to m a n a g e locally the element. Stating these two dynamic behaviours s e p a r a t e l y is not a trivial task. So, we propose to use concepts commonly used in Discrete Event Model [MAD.90] and some used in Object Oriented P r o g r a m m i n g [GRA.91]. The modelling t a s k has to emphasise a n u m b e r of elements according to the Control phase. But modelling tools have to be coherent to a s s u m e a coherent Information System and therefore a good data base for the FMS. Consequently, we propose to build a c o m m o n k e r n e l defining the common elements of the three phases of the Control [MER.93]. Then we define some added elements for each particular phase. All elements of the model are objects. In m a n y s t a n d a r d Class Libraries the class of this object is called a Collection. For each object, you have: - an identifier, - pointers to navigate in the list of same type objects, 2.1.1.1. Common kernel model We will not give an e x h a u s t i v e description of the k e r n e l but only some examples to explain how to build it. Regarding the modelling of the T i m e c o n c e p t s , we have to define the calendars used in the FMS. Calendars allow to define precisely the nominal availability of each resource. A Calendar is built from the basic concepts : Day Of The Week, Hour, H o u r I n t e r v a l , WeekCalendar, Days Of Rest and Date. All are objects and are defined with their own attributes and operators.
206 For i n s t a n c e , List of W e e k C a l e n d a r s . For each W e e k C a l e n d a r , one has: - s e v e n lists of H o u r I n t e r v a l (one for each D a y Of The Week), e a c h H o u r I n t e r v a l is a couple of Hours (HourD, HourF). List of C a l e n d a r s . For each Calendar, one has: a list of Days Of Rest, a list of (WeekCalendars, DateD, DateF). R e g a r d i n g the modelling of the R e s o u r c e c o n c e p t s , we have to define several c l a s s e s o f r e s o u r c e s (Machine, Operator, pallets, fixtures, tools, conveyors,...) a n d several h i e r a r c h i c a l s t r u c t u r e s (Group, Partition, Layout). H i e r a r c h i c a l s t r u c t u r e s are useful to define dependence relations b e t w e e n resources. G r o u p r e l a t i o n defines sets of equivalent resources. P a r t i t i o n r e l a t i o n is used to settle split r e s o u r c e s (for i n s t a n c e , a work table w i t h t h r e e places, some p r o d u c t s need the whole table, others only one place). L a y o u t r e l a t i o n describes a n inclusion r e l a t i o n b e t w e e n resources (for instance, a m a c h i n e is included in a cell). A resource has its own calendar and a type defining its o p e r a t i n g mode. -
-
For i n s t a n c e , List of Operators - a Calendar, - O p e r a t o r type (operating mode), List of Machines. For each Machine, one has: - m o d e : fully a u t o m a t e d , h a l f - a u t o m a t e d , m a n u a l - a Calendar, - M a c h i n e type (operating mode), - list of authorized Operators - n u m b e r of O p e r a t o r s List of group of Operators - list of Operators belonging to the group - n u m b e r of O p e r a t o r s List of group of Machines - list of Machines belonging to the group n u m b e r of M a c h i n e s R e g a r d i n g the modelling of the P r o d u c t c o n c e p t s , we have to define several t y p e s of p r o d u c t s (for i n s t a n c e , according to the type of T P P ) a n d a m a i n h i e r a r c h i c a l s t r u c t u r e ( G r o u p of O r d e r s , O r d e r , O p e r a t i o n , D e t a i l e d Operation). -
For i n s t a n c e , List of Orders. For each Order oi, one has: di the earliest s t a r t date, fi the latest end date, - O r d e r type (operating mode), - q u a n t i t y to perform, - priority (from 1 to 5), list (or more generally, graph) of operations, For each operation, one has: a code a n d designation, - operation type (operating mode), -
-
-
-
-
207 - m a i n machine,
-(PD, UD, TD), Preparation, Unit and Transfer Duration, - m i n i m u m size of lots, overlapping quantity between lots, - list of substitution machines, 2.1.1.2.
E l e m e n t s for Machine Scheduling
To build the Machine Scheduling Algorithm we propose a modelling tool called the Control Module [BER 81]. Each machine has its own Control Module. It contains the p a r t of the Scheduling Algorithm which concerns the machine. It allows to define a d i s t r i b u t e d a l g o r i t h m which is more robust w h e n the s t r u c t u r e of the model is changed (for instance, n u m b e r of machines) and easy to program on parallel computer [VEE.93]. Operations, constraints
Schedule of the machine
~~ ~ C'~h~ ~ ~~ ~ ....N .......operat!on_~.~ . ~ resources, .~ .'~."~:"~ " ~..... ~~" ~N variables, ~ ~ lists
Simulation of the running of the operation I n p u t Lists Figure
O u t p u t Lists
5 : S t r u c t u r e of a C o n t r o l M o d u l e A Control Module owns two sets of lists: - I n p u t Lists, - O u t p u t Lists. I n p u t Lists are used to m a n a g e the operations involving the machine. T h e y m a y contain the waiting operations with their date of arrival in front of the machine. T h e y m a y also contain the constrained operations with the date when they should be scheduled. O u t p u t Lists record the history of the machine scheduling. The m a i n o u t p u t list contains the current scheduling solution. The others allow the algorithm to m a r k the other a t t e m p t e d solutions and the Decision Points where it is possible to branch or to backtrack. The Control Module operation corresponds to a three step treatment: - C h o o s i n g an operation according to a rule, - Simulating the operation, - U p - d a t i n g the state variables and the Input Lists and recording the scheduled operation in the O u t p u t Lists.
208
The Control Module is one of the basic concept used in SIPA+ software to i m p l e m e n t the scheduling algorithm [BER 89]. 2.1.1.3.
Added Elements for Detailed Scheduling
In this p a r t of the model, more detailed elements are described which allow to s i m u l a t e precisely: - the transfer system, - the tool system, - the r u n n i n g of a machine-type or operation-type. The t r a n s f e r s y s t e m is modelled separately. Its aim is to v a l i d a t e TD, the T r a n s f e r D u r a t i o n . The M a c h i n e S c h e d u l i n g gives a list of t r a n s f e r s to perform between machines. (Mi, Mj, d, f) m e a n s t h a t you have to t r a n s f e r a product from Machine i to Machine j s t a r t i n g at date d and before date f. The objective of this transfer model is to find a solution to t r a n s f e r all the products and to m e e t the d and f dates. If this is not possible, it modifies the dates and t r a n s m i t s the delays to the Machine S c h e d u l i n g . The tool system is also modelled separately. Its aim is to do a first validation of PD, the P r e p a r a t i o n D u r a t i o n . This model describes tools t r a n s f e r s a n d machine configuration globally. The second validation of PD and sometimes UD is done by detailed simulation of the operations on the machine. For this, we describe the list of Operations. For each Operation opi, one has : - d i the s t a r t i n g date and fi the latest ending date calculated by Machine Scheduling, - related order oi, - list (or more generally, graph) of previous and next operations, - F o r each operation, one has : - a code and designation, - operation type (operating mode), - main machine, - UD, Unit Duration, - m i n i m u m size of lots, overlapping quantity between lots, - list of substitution machines. The o p e r a t i n g modes are described with Petri nets [COU.89]. T h e y describe precisely the various s t a t e s of the objects involved (machine, robot, pallet, conveyor, part, data,...). 2.1.2.
Predictive Control Modelling
P r e d i c t i v e Control concerns P l a n n i n g Activity, whose r u n n i n g mode is periodic. This FMS Planning Activity is nested inside a s t r u c t u r e d h i e r a r c h y of P l a n n i n g Activities. In order to i n t e g r a t e the FMS in the whole Production System properly, the FMS Planning Activity m u s t be defined in coherence with the general P l a n n i n g Function. We will first explain the various Hierarchical P l a n n i n g S t r a t e g i e s and t h e i r main concepts: horizon, period, Decision Frame. We will t h e n show the FMS P l a n n i n g S t r a t e g y inside this hierarchical structure.
209 2,1,2,1,
Hierarchical planning
This is a classical m e t h o d in Production Control. It consists in choosing a detail level to define t a s k s and d a t a according to a given p l a n n i n g horizon [POR.87]. F o u r p l a n n i n g levels are obtained from Long T e r m to Very S h o r t Term. This decomposition is very often used in industry [DOU.84]. O t h e r a p p r o a c h e s exist, where p l a n n i n g decisions are not organized in a p u r e l y h i e r a r c h i c a l s t r u c t u r e . [JON.90] proposes a c o m b i n a t i o n of two s t r u c t u r e s , one hierarchical, one heterarchical. In this decomposition, p l a n n i n g decisions at each level are considered as c o n s t r a i n t s and objectives for lower levels. Each level has a distinct couple (horizon, period) [DOU.84]. As a general rule, horizon and period decrease as one approaches toward lower levels. In order to realise a plan, it is n e c e s s a r y to define a co-operation a n d a synchronisation between levels, to run their planning activity coherently. Two solving strategies are considered: - Top-down approach, - I n t e g r a l l y co-ordinated approach. We propose an i n t e r m e d i a t e approach: the P a r t i a l l y co-ordinated a p p r o a c h [ARC.91-1]. To realise this approach, one must know how to determine the p a r t of the plan to t r a n s m i t through the lower levels. In this aim, we define the State of a planning activity and the Decision F r a m e for a planning activity.
a)
The Top-down approach
The Top-down approach's aim is to calculate a plan through a single Top-down pass. A plan elaborated at one level is t r a n s m i t t e d to the lower level as a set of absolute objectives and constraints. The reliability of this approach depends on the capability for a level to know w h a t can be made on the lower level. For this, the work load of the controlled system is calculated but for the moment we do not know exactly how to do such an evaluation. Because t h a t depends on the set of oi and their related TPP. So, a l t h o u g h this a p p r o a c h is not t i m e - c o n s u m i n g , it leads to sub- or overevaluation of the shop capacity.
b)
The Integrally co-ordinated approach
The I n t e g r a l l y co-ordinated approach's aim is to calculate a p l a n t h r o u g h dialogues between adjacent levels. The n u m b e r of passes is not limited, a n d each level m a y contest the objectives and constraints coming from the u p p e r level. The objective is to be sure t h a t the planning solution elaborated is fully admissible. The m a i n objection to this approach is t h a t it is time-consuming. It is difficult to e v a l u a t e the m i n i m u m a m o u n t of time r e q u i r e d to find a first solution, because the lowest level may oblige to re-think the whole hierarchical process planning. But this method has the advantage of giving a very good solution. Therefore, it seems interesting to be able to use it but if you have time.
210
c)
The Partially co-ordinated approach
The P a r t i a l l y co-ordinated a p p r o a c h tries to m a k e a c o m p r o m i s e b e t w e e n the two f o r m e r methods. The objective is to combine the r a p i d i t y of the first m e t h o d and t h e q u a l i t y of the second one. For this, we define the s t a g e notion. It is one step in the solving h i e r a r c h i c a l process.
Admissibility
A high - -
Totally~~ 1 Coordinated ] Partially Coordinated[ Approach [
Medium- -
Low - -
I
I
Low
Medium
I
Time
high
Figure 6 : Hierarchical Planning Approach. A stage is defined in a s s o c i a t i n g two a d j a c e n t levels to find a plan s a t i s f y i n g both levels. The control is t h e n given to the next lower stage, w i t h o u t a possibility to return. solving stages
levels
1, C2, C3 C 1 ~ ~ ~ 3
f
M1
~
M2 M3 M4 M5 M6 M7 M8 M9
CI, M1, M2
C2, M3, M4, M5
C3, M6, M7, M8, M9
F i g u r e 7 : Solving s t a g e d e f i n i t i o n w i t h a t h r ~ : l e v e l h i e r a r c h y
(Shop, Cell, Machine). On one stage, one has one e n t i t y on the u p p e r level, and n on the lower level. The u p p e r e n t i t y e l a b o r a t e s a p l a n a n d a s k s t h e n e n t i t i e s to a p p r o v e or d i s a p p r o v e of its plan. This dialogue is stopped w h e n the two levels agree or w h e n t h e m a x i m u m n u m b e r of passes is reached.
d)
State of a planning activity
In t h e GRAI M e t h o d , t h e p l a n n i n g a c t i v i t y h a s a periodic execution. A decision level Li is c h a r a c t e r i s e d by a horizon, Hi a n d a period, Pi. T h e p l a n n i n g a c t i v i t y (PAi) is a c t i v a t e d every period Pi. An a c t i v a b l e p l a n n i n g activity (PAi) m a y be in one of the two following states:
211
- the auto-activable state, if and only if the planning activity PAi+ 1 of level Li+ 1 (Hi+ 1, P i + l ) has not reached the end of its period, - the waiting state, to be activated by the planning activity PAi+ 1, if and only if the planning activity PAi+ 1 has not reached the end of its period Pi+ 1.
e) Decision Frame for a planning activity Let two adjacent planning activities be PAi+I and PAi, we called the d a t a they exchanged Decision F r a m e for a planning activity. This frame consists of: - the products to plan, - the TPP, - di the earliest starting date and fi the latest ending date, - the n u m b e r of the current pass, - the m a x i m u m n u m b e r of passes. We called Hci the Horizon of the Decision F r a m e for a planning activity. It is the part of the Hi+ 1 whose data has to be transmitted by level Li+l to level Li. Hci is bounded by Hi and Hi + P i + l because PAi needs information on the Hi horizon to m a k e a plan. Hi Levels
Hci
<
< Pi+l + Hi
[ The level is in the waiting state, to be activated The level is auto-activable
qt•
Decision Frame
Hi+l Pi+ 1 - - - - - - - ~
-__~
i+l
~ H i
JL
~
l
i-1
. tO
-:--/
tl
.
.
.
.
.
.
.
.
.
.
.
~
Time
t2
F i g u r e 8 9 Decision F r a m e for a p l a n n i n g activity. APi r u n s every period Pi. In t2, APi receives a new frame from APi+I. So, the last time APi needs frame information to make a plan before t2, is t l . Then, we can write: Hci = (t2 - tO) + H i , i.e.: Hci
= Hi+
P i + l - Pi
212 Let (Hi = k i . P i , Hi+l = ki+l.Pi+l), We obtain the following relations: Relation between Pi+ 1, Pi and Hci Hci = Pi+l-(1-
ki) Pi]
Relation between Hi+ 1, Hi and Hci
i_(ki11), i 1(1
,Hi
We have determined the part of the plan to be t r a n s m i t t e d downto the lower level. Now, we have to state clearly how FMS Control dialogs with MTMS to elaborate the Reference Plan. 2.1.2.2.
Principles and scheme of a hierarchical planning strategy.
Viewed from the FMS the p a r t i a l l y co-ordinated approach is a dialogue between MTMS and the Load Evaluation and Machines Affectation task. The Decision F r a m e sent by the MTMS Planning activity is decomposed with T P P information, and the machine load is smoothed out. Load smoothing is done by m e a n s of M a c h i n e s Affection. These affectations are o b t a i n e d t h r o u g h algorithms and by a man-machine co-operation t h r o u g h a convivial interface. We design and develop such an interface in [BER 90]. An example of a screen is presented in w 3.5.2. If Flexibility Knowledge is specified, it is also possible to make these choices through an inference engine (w 3.3.1.1).
I
MTMS Planning)
[ --- Partially coordinated approach
-
f FMS Predictive control ~ . . . . . . . . . . . . . . . . . . . Oad Evaluation and"~ I achine Affectation J Machine Scheduling
_1
[,
(tools ~~T~tranfersDetailed Scheduling )) (operations)
,
I[Plan ready to launch
#
',, ,'
FMS Control " .....
"perio(lic . . . . . .
[ .....
event'-driven . . . . . .
F i g m ~ 9 9Decision F r a m e for a p l a n n i n g activity
213 H a v i n g the machine scheduling t a s k r u n inside a limited a m o u n t of time is the main objective to reach, even if some of the date objectives are not respected. The reason is t h a t if no Reference Plan is elaborated the FMS Control is blind. This is why we suggest to use a List Method (for its rapidity) and an improving process b a s e d on a l g o r i t h m s a n d M a n - M a c h i n e I n t e r a c t i o n s both. The i m p r o v i n g a l g o r i t h m is b a s e d on p e r m u t a t i o n s m a d e by a S i m u l a t e d Annealing algorithm [ELO. 92]. For the machine scheduling task, the m a n u f a c t u r i n g operations are modelled by m e a n s of three durations: - P D , P r e p a r a t i o n Duration, the a m o u n t of time required to p r e p a r e the machine for a lot of parts, - UD, Unit Duration, the a m o u n t of time required to process one part, - TD, Transfer Duration, the a m o u n t of time required to t r a n s f e r the part to the next machine. In the FMS, t h e s e d u r a t i o n s are not k n o w n with the s a m e precision. Generally, UD is the best known d u r a t i o n because it is related to a fully a u t o m a t e d process. PD is often well-known, but if a tool is shared with a n o t h e r m a c h i n e PD m a y vary. And TD is the less well-known duration, because it depends on the work load of the transfer system. The machine scheduling t a s k elaborates a first schedule, using these t h r e e d u r a t i o n s . Then, the detailed s c h e d u l i n g t a s k m a k e s a D i s c r e t e - E v e n t Simulation to check if PD and TD durations have been evaluated correctly. If n e c e s s a r y , the PD and TD d u r a t i o n s are increased, and the schedule is adjusted. We use the SIMGRAI tool to perform this task [BER 85]. [MON.90] proposes an i n t e r e s t i n g analysis of dispatching rules and how to select t h e m with a discrete event simulator. [MUK.91] has developed an integrated model to realize jointly tool allocation t a s k and sheduling tasks for parts, pallets, machines and conveyors. 2.1.3. Modelling the Auscultation and Diagnosis of disturbances by Flow-Profiles The auscultation-diagnosis method t h a t we will suggest is based on the use of F L O W - P R O F I L E S [ARC.91-2]. These flow-profiles establish a link between the t h e o r e t i c a l production p r o g r a m and the actual m a n u f a c t u r i n g s i t u a t i o n s . Other similar methods are proposed, see [WAR.91] and [BOC.91]. The problem of auscultation is basically a problem of reduction of the set of points to be observed (tested) when a dysfunctioning s y m p t o m appears. In simple cases, such as machine or tool failures, the point to be observed is directly indicated by the location of the symptom. In complex situations, such as b o t t l e n e c k s or i m p o r t a n t m a n u f a c t u r i n g delay (the s y m p t o m s ) , it is necessary to check every preceding point in the flow of parts and in the circuit of machines. Thus, the number of points to be observed may become very large and incompatible with the production program. The flow-profiles will allow, first of all, to locate the hidden causes of the symptoms, and then, to reduce the n u m b e r of points to be observed. A flow-profile is a 3-attribute diagram indicating the load situations of a given machine with respect to time (figure 10) :
214 Pf = ( load L, Waiting Time WT, colour C) Level of load flow Processing starting of machine B processing end of
3
. . . . .
0
t1
I _ . _ _
t2
_
A
t3
t4
t5
Time
F i g u r e 10 : F l o w - p r o f i l e Let t h i s m a c h i n e be called m a c h i n e B; the load m a y come from a n o t h e r machine, called A. Load-level L indicates the a m o u n t of work t h a t the m a c h i n e B is going to u n d e r t a k e . W a i t i n g time WT indicates the period d u r i n g which the i n t e r m e d i a t e stock between m a c h i n e s B and A r e m a i n s constant. Colour C indicates the type of p a r t s on which the machine B will operate. It indicates in fact one type of operations, or one group of operations. With r e s p e c t to the a u s c u l t a t i o n problem, the aim of the flow-profiles is to reflect various t r a n s f e r s i t u a t i o n s b e t w e e n machines. For instance 9 (a) At t l , end of one processing by machine A (b) Between t l and t2, the i n t e r m e d i a t e stock r e m a i n s constant (c) At t2, end of a n o t h e r processing by machine A, hence, an increase of the w a i t i n g stock. (d) At t3, m a c h i n e B s t a r t s to work, t h e r e f o r e , a d e c r e a s e of t h e i n t e r m e d i a t e stock level. (e) Between t3 and t4, the i n t e r m e d i a t e stock r e m a i n s constant (f) At t4, more work comes from m a c h i n e A The d i a g r a m is r e l a t e d to the pair of m a c h i n e s A a n d B. Should m a c h i n e B receive work from several other m a c h i n e s A1, A2, A3,..., one has to establish - firstly, several flow-profiles A1-B, A2-B, A3-B, .... - secondly, one global flow-profile by s u m m i n g up the individual ones. For a u s c u l t a t i o n a n d diagnosis, we need a Reference Flow-Profiles (RFP) which reflects the given production p r o g r a m (Reference Plan). One should be a w a r e t h a t the theoretical p e r f o r m a n c e s of the machines, as a s s u m e d in the production p r o g r a m , m a y be different in reality. Therefore, this R F P m u s t be p e r m a n e n t l y , (or periodically), adjusted according to the real situation.
215 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
~'PI Detection of I ]perturbation
i ..............
, ..............
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
I
.
.
.
.
generation of Flow-Profiles
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
~Set of basic ~ Flow-Profiles j
r
L.~ .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Confirmation of I the perturbation I .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
F i g u r e 11 : D e t e c t i o n process Practically, R F P use for a u s c u l t a t i o n and diagnosis proceeds as follows : step 1 - Occurrence of a significant s y m p t o m at time tn step 2 - D e t e r m i n a t i o n of the RFP, the part from tO to tn step3 - D e t e r m i n a t i o n of the a c t u a l flow-profile w h i c h is different from the RFP (even up-dated) (The R F P reflects s i t u a t i o n s which are w i t h i n the "Earliest-Latest" m a r g i n of the operations. Any f a i l u r e - S y m p t o m indicates t h a t some operations are on the fringe or even beyond this margin)
2.1.4. graph
Modelling the Therapy by Manufacturing Environment Multi-
The m o d e l l i n g a p p r o a c h m a y be s u m m a r i z e d as follows. F r o m the notion of Reduced M a n u f a c t u r i n g E n v i r o n m e n t we define a M u l t i - g r a p h whose edges are t h e predicted p a t h of the products, a n d whose nodes are the m a c h i n e s . U s i n g connex g r a p h s , we define the M i n i m a l P o t e n t i a l - I n f l u e n c e Zone of the plan after a d i s t u r b a n c e has occurred. 2.1.4.1. M a n u f a c t u r i n g E n v i r o n m e n t of a General Workshop (MEGW) For a given [0,T] horizon, the M E G W is defined as the set of usable e l e m e n t s ( m a c h i n e s and e q u i p m e n t ) a n d " - products to be m a n u f a c t u r e d - T P P and sub-TPP associated with these products - physical configurations of the m a n u f a c t u r i n g elements
216 2,1,4,2, Reduced M a n u f a c t u r i n g E n v i r o n m e n t (Ev) For a given horizon [0,T], the Ev is defined u n d e r the following conditions" -Products associated with linear TPP representing p r o g r a m m e d and non-executed operations Feasible m a c h i n e s with non-blocking resource supports. 2.1.4.3. M u l t i - g r a p h of a Reduced M a n u f a c t u r i n g E n v i r o n m e n t Ev
the
-
The m u l t i - g r a p h is defined as 9 G=(S,A), where 9 S: is the set of nodes associated to m a c h i n e s and e q u i p m e n t , defined by the following bijective function f: M ~ S verifying the conditions V (mi,mk) 9 M2 f(mi ) # f ( m k ) V m i 9 M 3 si 9 S/f(m.~=s i A: is the set of edges such as we construct an edge between s i and Si+l, if t h e r e exists a p r o d u c t whose predicted p a t h in the w o r k s h o p t r a n s i t s in e i t h e r direction between m i and mi+ 1. Between s i and Si+l, for a given product, there will be as m a n y edges as t r a n s i t i o n s predicted b e t w e e n the 2 a s s o c i a t e d machines. For a given w o r k s h o p s t r u c t u r e : m l , m 2 , . . . , m i _ l , m i , m i + l , . . . , m k ; for a given product Pi associated with a linear TPP gi, we construct a s u b - G r a p h with k-1 links defined in the following way: v i=l,...,k-1, we connect with one edge the nodes si, s i + l associated with m a c h i n e s m i and m i + l The M u l t i - g r a p h of the m a n u f a c t u r i n g e n v i r o n m e n t of a given workshop is the u n i o n of the set of sub-graphs associated to the products of the m a n u f a c t u r i n g environment. Example I ~
Operations "~ op.1 op.2 op.3 op.4 op.51 pl 1 5 3 6 2 Machines
I
1~
3
6
1
a,
p3 pt
7 6
9 2
8 4
4
ps
3
s
3
s"
p6
8
4
2
9
/ ~ /
F i g u r e 12 : M a n u f a c t u r i n g p r o c e s s .
217
F i g u r e 13 : A s s o c i a t e d m u l t i - g r a p h .
1
F i g u r e 14 : A s s o c i a t e d v a l u e d m u l t i - g r a p h . Let us consider a production program in which" - six products (Pl to P6) are involved - each product may involvel to 5 operations (opl to op5) - 9 machines are used: (1 to 9) U s i n g the TPP associated to the products, the scheduling t a s k assigns a machine to each operation for each product. The schedule-table (figure 12) is obtained. From the schedule-table, we deduce the associated multi-graph of figure 13: -each node r e p r e s e n t s the s i t u a t i o n of a m a c h i n e (s 1 to s 9 correspond to the 9 machines), - t h e r e is one edge (non-oriented link) each time t h e r e is an i n t e r m e d i a t e succession of m a n u f a c t u r i n g sequences either of the same product, or between two different products (example: edge between s 8 and s9). -there are as m a n y edges as immediate successions (example: 2 edges between s 6 and s2). In some p r o d u c t i o n p r o g r a m s , especially w h e n t h e r e are few m a c h i n e s (multiple-purpose machines and conveying robots), the associate m u l t i - g r a p h becomes heavy and difficult to manage. In such a case, the m u l t i - g r a p h of figure 13 is replaced by the valued multi-graph of figure 14 where the multiedge is replaced by a single-edge associated to a n u m b e r r e p r e s e n t i n g the n u m b e r of edges. 2.1.4.4. Absorbing Capacity of an operation In a m a n u f a c t u r i n g schedule, t h e r e are often gaps. A gap occurs e i t h e r because a machine is waiting or because a product is waiting. This gap can be
218 defined with respect to an operation, by considering the consecutive operations of this operation. There are two types of consecutive operations: (figure 15) operation Sm(ij) linked by the machine - toperation (i+ l~j) linked by the product. For the therapy, these gaps can be used for dividing adjusting reactions. -
The Absorbing Capacity CA(ij) of an operation (i j) can therefore be defined as the m a x i m u m m a r g i n which can be employed to annihilate a p e r t u r b a t i o n on this operation without disturbing the consecutive operations. The CA(ij) can be calculated in the following way. In the following expressions, the symbols dd, df, d e stand for: dd (ij) starting date of operation (ij), df (ij) ending date of operation (ij), de (i) due date of product i, ATp(ij) be the margin between operation (ij) and its successor ( i + l j )
Let 9
if the operation (i+ 1j) exists, then ATp(ij) = dd (i+ 1j) - df (i j) - if the operation ( i + l j ) does not exist, then ATp(ij) = Max ( 0, de(j) - df (i,j)). -
Let 9
ATM(ij) be the margin between operation (ij) and its successor Sm(ij) - if operation Sm(ij) exists, then ATM(iJ) = dd(Sm(ij)) - df (ij) if operation Sm(ij) does not exist, then ATM(iJ) = oo. -
The local absorbing capacity of operation (ij) is then: i
CA(iJ)= Min ( A T p ( i j ) , ATM(iJ) ) ATp(1,2)
ATM(1,2) Machines ~"~",i"~-~':i~,.'~
M4
M3 .
.
.
.
M2 M1
'~/"~~!" 'i~ x
x
_ ~
(2,2~~,:. 9
__
U
_
ii:i!!:!!!:i!i:i!~i::::i!:ii!:ii::! ii:i!!:!!!:i! ~-~ Time
F i g u r e 15 : M a r g i n s of a n o p e r a t i o n (ij) 2,1.4,5. Minimal Potential-Influence Zone (MPIZ) One of the key-ideas for solving the NP-complexity scheduling problems, is to decompose the N P - c o m p l e x i t y into isolated small ( n r p k ) - c o m p l e x i t i e s ([BUR.S6], [POR.88]).
219 If this idea is applied to our method, we need to decompose the M a n u f a c t u r i n g E n v i r o n m e n t of the workshop into small m a n u f a c t u r i n g e n v i r o n m e n t s . T h u s , the MPIZ is defined as follows (figure 16) : - the zone is initiated by a p e r t u r b a t i o n , - the zone has a spatial r a n g e in machines and e q u i p m e n t , - the zone has a t e m p o r a l range, - a n y a d j u s t i n g reaction in this zone has a m i n i m u m influence on the following operations. 2.1.4.6. Connex G r a p h s Local zones (nrpk) reflect the situations of the m a n u f a c t u r i n g capacities of the e n v i r o n m e n t s . The connex g r a p h s a r e o p e r a t i o n a l tools, w h i c h t r a n s f o r m zones (nrPk) into a model, from which the m o n i t o r can calculate his a d j u s t i n g reactions quantitatively. realised Zone temporal range
I
M a c h i n e s
. ~
I
minimal ootential-influence
~
MS
m
Set of a c t i v i t i e s -
Time
Di:
F i g u r e 16 : M i n i m a l p o t e n t i a l - i n f l u e n c e
z o n e .
A c o n n e x g r a p h is a s u b - g r a p h of t h e m u l t i - g r a p h r e p r e s e n t i n g t h e m a n u f a c t u r i n g e n v i r o n m e n t . The i n i t i a l m u l t i - g r a p h m a y c o n t a i n i s o l a t e d c o n n e x - g r a p h s (connex components of the multi-graph). A connex c o m p o n e n t m a y a p p e a r after the execution of some m a n u f a c t u r i n g operations (figure 17, figure 18). Operations
•
op.1
op.2 op.3
op.4 op.5
pl
1
5
3
6
ti2
3
6
1
4
p3
7
9
8
p4
6
2
4
p5
3
5
3
2 Machines
/
./ 5
F i g u r e 17 : N e w s c h e d u l e - t a b l e .
220
F i g u r e 18 : V a l u e d m u l t i - g r a p h a s s o c i a t e d to t h e schedule-table of f i g u r e 17. E x a m p l e : Let us s t a r t w i t h the s c h e d u l e - t a b l e in figure 12. S e v e r a l m a n u f a c t u r i n g o p e r a t i o n s have been executed so t h a t the p r o d u c t P5 is achieved. S e v e r a l m a c h i n e - a s s i g n m e n t s have occurred, r e s u l t i n g in the schedule-table in the figure 17. The multi-graph in figure 13 becomes t h e n t h a t of figure 18. The l a t t e r now contains two connex components. One on the left, and the other one on the right.
2.2.
Planning
2.2.1.
or Predictive Control
Convivial p l a n n i n g
The first principle to respect when specifying a Convivial P l a n n i n g Software is t h a t the H u m a n Operator responsible for the scheduling t a s k m u s t not be idle in front of his computer, or the P l a n n i n g Software is not convivial and the H u m a n Operator does not use it. Secondly, the H u m a n constraints easily.
O p e r a t o r m u s t be able to e n t e r his solutions
or
Thirdly, the Convivial P l a n n i n g Software m u s t explain the solutions it has found. So, the Convivial Planning Software relies on [BER 87]: -an Interactive Man-Machine Interface, - a very quick basic algorithm, - s e v e r a l improving a l g o r i t h m s r u n n i n g in the b a c k g r o u n d , which can explain the solutions found, - m a n y utility functions to analyse the scheduling situation. 2.2.2. Man-Machine Interface The h e a r t of the Man-Machine Interface for a Convivial P l a n n i n g Software is the Interactive Graphic Representations for Planning, i.e. a G a n t t d i a g r a m or a Load diagram. The m e a n i n g of Interactive is t h a t the Graphic Representations are the media used by M a n and C o m p u t e r to co-operate towards a solution. The Graphic R e p r e s e n t a t i o n s have to be reactive, i.e. t a s k s on a d i a g r a m m u s t be easily
221 movable w i t h the mouse, and a double-click should open an i n f o r m a t i o n window on the selected task. A Graphic R e p r e s e n t a t i o n for Planning is a 2D view of a 3D Abstract Object: the planning. The three dimensions of a planning are: -T, Time used to r e p r e s e n t P l a n n i n g Horizon, Period, o p e r a t i o n duration,... - P, Product, a generic term used for all the materials transformed by the FMS, - It, Resource, represents all the objects t h a t serve as support for the FMS operation. To specify a Graphic Representation for Planning, we have to define: - a selection among these three sets (T, P, R); i.e. an interval of Time, a sub-set of Products and a sub-set of Resources, - a g r a p h t y p e : Gantt, Load, Day planning, - the set of t o o l s used to Interact with the planning.
- r - ]
InteractiveGraphical Representntions for P l a n n / n g
~[::]']~
(Tools) ISelectron v
I
I
i
Horiz. ~cale
l
,,
i
I
I
I
i
I
I
I
Res. 1
Res.2
period
r~ G2
cD
Res.255
iMi i
_AAI
I •!!!•!!!!!!i!!•!!!•i•i•ii•i•i•i•i!i•i•i•i•i!iii!!!i!i!i••T••i!i!i!i•i•i•i•i•i•i•i!i!!•!ii!i!i•i•i•i•i•ii!!!!i•i•i•i•i!!i!i•
I0
F i g m ~ 19 : P r o p o s i t i o n of a P l a n n i n g Interface 2.2.3.
I,i~ method
The proposed List Algorithm is based on the use of the [BER.83] Control Module. H is the horizon, TO is the beginning date of the plan, T is the current date, the g l o b a l a l g o r i t h m dispatches operations in the i n p u t lists of the Control Modules. Each Control Module with its l o c a l a l g o r i t h m manages the choice of operations in its input list.
222 T is set to TO WHIIJE T < T0 + H DO F O R each free machine DO Activate C o n t r o l M o d u l e of the Machine at date T Update the I n p u t Lists of others Control_Modules END OF F O R Increase T END OF WI-III,E F i g u r e 2 0 : Global a l g o r i t h m To C h o o s e an operation Oi in the Input List according to a rule, I F Oi is chosen T H E N S i m u l a t e the operation on the Machine at date T U p d a t e the state variables and the Input Lists and r e c o r d the scheduled operation in the Output Lists END OF IF F i g u r e 21" Local a l g o r i t h m o f t h e Control_Module This a l g o r i t h m is very simple in its general s t r u c t u r e . This d i s p a t c h e d structure makes it easy to execute by a parallel computer. This is i m p o r t a n t to reduce the a m o u n t of time required for scheduling.
2.2.4.
Improving solution with a Simulated Annealing algorithm
The Simulated Annealing algorithm to improve Shop scheduling solutions is i n t e r e s t i n g because of its generality. Its s t r u c t u r e is not d e p e n d e n t on the structure of the Shop. The first t a s k to perform is to choose an evaluation criterion to m e a s u r e the quality of the scheduling solution. This criterion may be used : - t o minimise the total processing time, - t o minimise the total processing time of a set of m a n u f a c t u r i n g orders (for example, those with a high priority), - to maximise the load of bottlenecked machines. The Simulated Annealing algorithm [BON. 91] is as follows 9
Begin To evaluate criterion C for the current scheduling solution k <-- 0 (initialisation) To evaluate starting temperature T(0) (T is temperature) W h i l e (the stop criterion is not verified) Do
Begin Repeat_Count <-- 0 (initialisation) W h i l e (Repeat_Count < N(k)) Do
Begin Change a product choice for one machine
223 Make a new schedule To evaluate criterion C' for the new scheduling solution If (criterion value C' better t h a n C) T h e n the new scheduling solution becomes the current one Else A(T) = exp ( ( C - C' ) / T ) a random number p is generated in the range [0, 1] If p < A(T) T h e n the new scheduling solution becomes the current one Else the product choice Change is cancelled E n d of If E n d of If Repeat_Count <- Repeat_Count + 1 E n d of w h i l e k <--k+ 1 To evaluate T(k) End of while
End Simulated Annealing algorithm T e m p e r a t u r e T and probability P aim to allow the criterion C to grow between two decreases. T e m p e r a t u r e T is a decreasing geometric function T(k) = a.T(k1); "a" is a constant strictly inferior to 1. The n u m b e r of repetitions "N(k)" is linked to the m a x i m u m number of attempts accepted between two decreases of the criteria; it is often constant. The main loop depends on a stop criterion for the improving process. For us, this stop criterion depends on the a m o u n t of time allowed by the user to the computer to devise this improving process. Figure
22 : The
The Simulated Annealing algorithm is based on the following p a r a m e t e r s : the initial schedule and temperature, the decreasing geometric function, the stop criterion and the rule to make the change of product choice.
2.3.
Supervising or On-line
ControL
The On-line Control is the part of the FMS Control t h a t is most developed in i n d u s t r y . Few generic studies about it are available. The modelling tools commonly used are : -SADT to s t r u c t u r e the physical elements, mainly resources whose w o r k load is limited (machines, e q u i p m e n t , m a t e r i a l s , stocks) [KER.93], [BOW.91], - GRAI-nets [PUN 83], [PUN 84]: - to model the activities and the situations of the product flows, - to model the command signals and their reception points, - to model of the supervising points in the product flows. To m a k e real-time scheduling decisions, the most common approach is to use dispatching rules [HUT.91], [MAH.90], [MON.90].
224 2.4.
Dynamic
Control
We have p r e s e n t e d above (w 2.2.3 and 2.2.4) the modelling tools to be used : - f l o w - p r o f i l e m o d e l l i n g to r e f l e c t m a n u f a c t u r i n g situations ( m a n u f a c t u r i n g load), -capacity-diagram m o d e l l i n g to r e f l e c t a n d u n d e r s t a n d t h e s i t u a t i o n s of the capacity utilisation. We will now explain the procedures to solve the following d y n a m i c p r o b l e m s : -auscultation and diagnosis, - therapy. 2.4.1. M e t h o d o l o g y for A u s c t d t a t i o n a n d D i a g n o s i s In t e r m s of F M S p l a n n i n g a n d control, the a u s c u l t a t i o n process occurs w h e n t h e c a u s e s of t h e p e r t u r b a t i o n s y m p t o m c a n n o t be clearly detected. Once t h e c a u s e s a r e d e t e c t e d t h e d i a g n o s i n g p r o c e s s t a k e s place. In t e r m s of " s u p e r v i s i n g " a n d " d y n a m i c a d j u s t i n g " activities, the d i a g n o s i n g process is lies b e t w e e n t h e s e two activities. This process, in fact, consists of two activities : (a) perception, which i n t e r p r e t s the r e s u l t s of the a u s c u l t a t i o n , n a m e l y , w h a t the causes of the dysfunctioning are; and (b) d e t e r m i n a t i o n of a field of possible actions which will guide the therapy. In our m e t h o d , both a u s c u l t a t i o n and diagnosis are b a s e d on the use of t h e S i t u a t i o n a l D i a g r a m of the flow_Profiles of t h e W o r k s h o p m a c h i n e s (Figure 23). Let : SIT-P : situation of a m a c h i n e which produces a load SIT-C : s i t u a t i o n of a m a c h i n e w h i c h receives a n d c o n s u m e s a load n : t h e n u m b e r of m a c h i n e s used in a workshop. The S i t u a t i o n a l D i a g r a m shows relations b e t w e e n various s i t u a t i o n s of FlowProfiles b e t w e e n the m a c h i n e - s i t u a t i o n s : (a) Level 0 : S i t u a t i o n of Flow-Profiles of n m a c h i n e s in SIT-P a n d n m a c h i n e s in SIT-C (top p a r t of the diagram) (b) Level 1 : Two situations of Flow-Profiles (b l ) S i t u a t i o n of Flow-Profiles of n m a c h i n e s in SIT-P a n d the whole of the n m a c h i n e s in SIT-C considered as one m a c h i n e (middle left) (b2) S i t u a t i o n of Flow-Profiles of n m a c h i n e s in SIT-C a n d the whole of the n m a c h i n e s in SIT-P considered as one m a c h i n e (middle right) (c) Level 2 : Situation of Flow-Profiles of the situation (bl) plus (b2) (bottom of the diagram)
225 Summation of flow profiles
// ",,,,
Machines in state vroducer 0 0
//
Z Aggregation of
/
ines in state consumer
Aggregation of
~Sh~g~s ' / '
p~auc~
Level 0 .
o 0
~ =, .el_ ~.
Aggregated glow-Profile:
0
Aggregation o 1 ~ ~ " . . . . . . . . producers N ~
Level 1 _ Aggregstion of
o
.< Level 2 .
F i g u r e 23 : Situational D i a g r m n of Flow-Profiles
226 The Flow-Profiles reflect the s i t u a t i o n s of the m a n u f a c t u r i n g operations. It is i m p o r t a n t to note t h a t , t h e o r e t i c a l l y , w h e n t h e r e are n m a c h i n e s in t h e m a n u f a c t u r i n g process, the total n u m b e r of Flow-Profiles is n*n (100 only for n = 10). This is w h y a u s c u l t a t i o n is difficult. However, for a given p r o d u c t i o n p r o g r a m , t h i s n u m b e r is m u c h s m a l l e r . If each m a c h i n e is u s e d once, t h i s n u m b e r is 9 for n = 10. This n u m b e r r e m a i n s s m a l l even if some of t h e m a c h i n e s are to be used several times. The global a u s c u l t a t i o n a n d d i a g n o s i n g process comprises t h r e e m a i n s t e p s (each one including several sub-steps) 9 (Figure 24). d e t e r m i n a t i o n of the observable critical point identification of the critical activity identification of the faulty actor or actors. Step 1- D e t e r m i n a t i o n of the observable critical point -
-
-
For this, we use the S i t u a t i o n a l D i a g r a m of Flow-Profiles ( F i g u r e 2). The process s t a r t s w h e n a significant p e r t u r b a t i o n is detected. Step 1.1 - E v a l u a t i o n of the tendency The "tendency" i n f o r m a t i o n a c c e l e r a t e s the s e a r c h for the o b s e r v a b l e critical point. This i n f o r m a t i o n is obtained by c o m p a r i n g the reference Flowprofiles (up-dated) and the p e r t u r b e d one of level 2. An uphill t e n d e n c y (some m a c h i n e s P R O D u c e too m u c h load) indicates t h a t the p e r t u r b a t i o n is on the "PROD" side. A d o w n s t r e a m t e n d e n c y (some m a c h i n e s have too m u c h load to C O N S u m e ) indicates t h a t the p e r t u r b a t i o n is on the "CONS" side. Step 1.2- D e t e r m i n a t i o n of the first m a c h i n e At this sub-step, we compare the Reference and the p e r t u r b e d Flow-profiles at the level 1. W h e n the tendency is "PROD", we identify as the first m a c h i n e , the p e r t u r b e d producer. W h e n the t e n d e n c y is "CONS" we i d e n t i f y as the first m a c h i n e , t h e p e r t u r b e d consumer. Step 1.3- D e t e r m i n a t i o n of the second m a c h i n e At this sub-step, we compare the Reference and the P e r t u r b e d Flow-Profiles at Level 0, which contains all the e l e m e n t a r y flow-profiles. Note t h a t , from Substep 1.2, only one producer or one c o n s u m e r is identified. Therefore, at Substep 1.3, a c c o r d i n g to w h e t h e r this is a p r o d u c e r or a c o n s u m e r , we only c o m p a r e one s e t of n c o r r e s p o n d i n g c o n s u m e r s or of n c o r r e s p o n d i n g producers. The final r e s u l t of Step 1 is one flow-profile connecting a pair of well-defined producer a n d consumer. The search for the observable critical point r e q u i r e s 9 1 comparison at level 2, n comparisons at levels 1 and 0. We therefore reduce a problem of complexity O(n 2) to one of complexity of O(2n+ 1). Step 2. Identification of the critical activity Once the observable critical point is located, we identify the critical activity in space a n d in time. This is done by using the load d i a g r a m corresponding to the flow-profile a r o u n d the critical point. The various types of causes are identified
227 by c o m p a r i n g t h e r e f e r e n c e load d i a g r a m f p (defined by t h e p r o d u c t i o n p r o g r a m ) w i t h t h e real a c t u a l load d i a g r a m f r (Figure 4). The difference b e t w e e n the two d i a g r a m s m a y a p p e a r in the length L of the w a i t i n g time, in the load level N, or in the Colour C (p : index for reference production p r o g r a m , r : real c u r r e n t situation, ti : m o m e n t in time w h e n the difference is observed). Load-flow level
4
reference . . . . . actual
3 2 1
0
I 1
! 2
I
'.
~.
',
3
4
5
6
F i g u r e 24 : C o m p a r i s o n
of load
=
Time T
diagrams
(a) The lengths are different 9 L~ v dr F u r t h e r m o r e , load-levels are also different : (al) L~ < d r a n d N ~ +1 >N~ The p e r t u r b a t i o n causes m a y be : - m a c h i n e failure of the uphill unit A - u n d e r - e v a l u a t i o n of the processing time of A (a2) k~ < lirandN~+1
(a3) Lb > ~randNir +1 > dr The causes may be : -
over-evaluation of the processing time at A of B larger t h a n previously a s s u m e d problems in the percentage of waste parts
-capacity -
9
(a4) Lb > ~r and Ni~l< I~r The causes may be : the t r a n s f e r between A and B is too fast problems of the m a c h i n e s - w r o n g choice of m a c h i n e s (b) Diagnosis on the waste-rate -
-procurement
T h i s h a p p e n s if N ~ ~rand~p= dr. The s i t u a t i o n confirms t h a t t h e u n d e r l y i n g activities are critical. (c) Diagnosis on the sequencing This h a p p e n s if ~.p r ~r The causes m a y be
228 either a misconveying of parts a wrong sequencing of operations Step 3 Identification of critical actors Locating the critical activity allows identification of the critical actor or actors. This is done by representing the activities by m e a n s of the GRAI-nets ( G r a p h s w i t h R e s u l t s a n d Activities I n t e r r e l a t e d ) [ P U N 84]. In t h i s representation, each activity is symbolically characterised by : input and output events, intellectual supports, m a t e r i a l supports, - operator. The i n t e r r e l a t i o n s between activities are always defined by the fact t h a t the support of one activity always comes from the result-event of another activity. Based on the GRAI-nets, the v a r i o u s causes identified at step 3 are symbolically t r a n s l a t e d into real elements. -
-
o
r
-
-
-
2.4.2.
Therapy Procedure
The aim of the procedure is to help the monitor, after the p e r t u r b a t i o n has occurred, and after the critical elements have been located, to d e t e r m i n e a d j u s t i n g reactions with a m i n i m u m of consequences. Step 1: Initiation Auscultation and diagnosis have identified the critical elements, causing the pernicious p e r t u r b a t i o n s . The Monitor displays the schedule-table and the G a n t t d i a g r a m of the m a n u f a c t u r i n g program. From the G a n t t diagram, the Monitor identifies the p e r t u r b a t i o n date dp (figure 26). Its t a s k is now to i d e n t i f y the MPIZ. For this, he c a r r i e s out a s p a t i a l a n d t e m p o r a l decomposition. Step 2: Spatial Decomposition The MPIZ is c h a r a c t e r i s e d by a spatial and a t e m p o r a l range. F r o m the schedule-table and the G a n t t diagram, the Monitor generates the associated Multi-graph. (An automatic generator m u s t be implemented in the decisionaid system). If the multi-graph possesses 2 or more connex components, the monitor chooses the smallest one. If not, the Monitor carries out a temporal decomposition. Step 3" Temporal Decomposition Each time a m a n u f a c t u r i n g operation is performed, a r u p t u r e m a y occur in some link of the multi-graph. As a consequence, new connex components m a y occur. There are three types of ruptures: t.ype a. The operation achieved is associated in the valued graph with a link of a value superior to one. The value decreases by one unit. No r u p t u r e in the graph. The connexity remains the same. type b. The operation achieved is associated in the valued g r a p h with a link of a value of 1 between nodes s i and Si+l. After this rupture, there exists
229 no circuit between these two nodes. The initial graph components.
splits into two connex
tvoe c. The operation achieved is associated in the valued graph with a link of a value of 1 between nodes s i and si+ 1" After this r u p t u r e , there still exists some circuit between these two nodes. No new connex components are created. The connexity of the initial graph remains the same. For the t e m p o r a l decomposition, the Monitor displays the schedule-table (figure 25) and the corresponding Gantt diagram (figure 26). He simulates the successive achievements of the m a n u f a c t u r i n g program (automatic pointer to be implemented in the decision-aid system). -~
Operations
r " M op.l I
op.3] op.4[ op.5]
op.',
917 71s 816 612 3 l 6 IP61 I 15 3 15
2 l
l
Machines
I/I
Figure 25 :Schedule~table under temporal decompositiom Machines
Ii :
_
~
_
i
i
. i
i I
-.,~-.~(a'2~',.
_
M9
_
i i
i
,,
M8
I
M7 M6
,
:
I
;;--
,,
i
,,
i i , i i . i -- ~ ( 1 , 4 ~ ~ ~ 2 . 5 ~ ~ " ~2-:3.T~., ~ I I i i
(4,6 " - ~ -,--T
M5 M4 ~
(1,5~
(1,7~
'
~ , 4 ~ ! ,
''
~
M3 M2
,
.
|
i
'.
~
~(3~3~ i i
(5,6_!i
I(I,~
MI
i
dO I
. . . .
=
=
!
i i
~'d~
i
i
:d3= (!1
I
I
(~'d61
i
I
i
~'d~
'
'
!
:~----
Time
F i g m ~ 26 : G a n t t d i a g r a m u n d e r t e m p o r a l d e c o m p o s i t i o m After each operation has been completed, he analyses the new structure of the m u l t i - g r a p h of the m a n u f a c t u r i n g e n v i r o n m e n t (connection b e t w e e n the pointer and the multi-graph generator to be implemented in the decision-aid system, the l a t t e r m u s t have a multi-window possibility). The succession of multi-graphs is shown in figure 27. The various steps of the decomposition are the following.
230 a- Initial structure A0 of the multi-graph at date do. b- At date dl, operation(I,3) ends. Rupture of link (s6, s8). Graph A0 splits into two connex components A1 and A2. c- At date d2, operation(2,5) ends. Rupture of link (s6, sl). Sub-graph A1 splits into two connex components A l l and A12. d- At date d3, operation(2,2) ends. Rupture of link (s9, s8). Sub-graph A2 splits into two connex components A21 and A22. e- At date d4, operation(3,5) ends. Rupture of link (sl, s4). Sub-graph A12 splits into two connex components A121 and A122. f- At date d5, operation(3,6) ends. Rupture of link (s3, s6). Sub-graph A l l splits into two connex components A l l l and Al12. g- At date d6, operation(3,1) ends. Rupture of link (s7, s8). Sub-graph A21 splits into two connex components A211 and A212. h- At date d7, operation(3,7) ends. Rupture of link (s3, s5). Sub-graph A l l l splits into two connex components A l l l l and All12. i - A t date d8, operation(4,6) ends. Rupture of link (s2, s6). Sub-graph A l l 2 splits into two connex components A l l 2 1 and Al122.
co,_ :,_ A2
A1
A12
T
A.11
Ittlttll
Figure 27 : Temporal decomposition of a multi-graph.
231 At each step a, b, c, .... , i, the monitor tries to determine the adequate adjusting reactions. If he does not succeed at one particular step, he goes to the next one. The earlier he succeeds with the dates, the better the adjusting reactions are. This p r o c e d u r e is i n t r i n s i c a l l y an o p t i m i s i n g procedure. The m i n i m i s e d criterion are the consequences of the perturbation on the production program. Step 4: Adjusting through permutation (figure 28) Once t h e connex c o m p o n e n t is i d e n t i f i e d , t h e M o n i t o r d i s p l a y s t h e c o r r e s p o n d i n g schedule-table and G a n t t d i a g r a m . He tries to absorb the p e r t u r b a t i o n through permutation. Two operations (i~j) and (k,1) scheduled on the same resource mi are said to be permutable if Max (df (i-lj), df (k-l,1)) < Min (dd(ij),dd(k,1)) Max (df (ij),df (k,1)) < Min (dd(i+l~), dd(k+l,1)) (Automatic computation of these conditions to be implemented in the decisionaid system). Step 5: Adjusting through transfer (figure 29) An operation (i~j) scheduled on resource mi is said to be t r a n s f e r a b l e if t h e r e exists at least one alternative resource mk r mi available between dd(ij) and df(i,j). (Automatic prospecting to be implemented in the decision-aid system). Permutation
M3~
~~%~(2,3~.~~(3,4~ _
~_~ time
Figure 28 : Permutation of manufacturing operations. Reassigned operation
Ma~ioes
~a,~ O,,01acedo~ratioo/
time
Figure 29 : Transfer of m a n u f a c t u r i n g o p e r a t i o n s .
232
Synthesis and Software architecture
1
From the tools and methods chosen for solving FMS Control problems this part proposes a methodology to build the Software architecture. The aim is not to describe a trivial programming method but to insist on the difficult points: - general principles to organize the global architecture, -construction of the various elements of the Software: Database, Knowledge, Programs, Interfaces, - l a n g u a g e and development methodology. The FMS Control we propose is a Convivial Control. For this reason, the presentation emphasises the heart of a Convivial Software: the Man-Machine interface. Then the FMS Control has to be integrated in the overall Enterprise Control. So, the software architecture must be designed and developed with a modular organisation [SAN.91].
3.1.
General architecture.
3.1.1.
Logical Architecture
The following scheme (figure 30) defines the general architecture of the FMS Planning and Control System for one part of the FMS, i.e. Cell control or Central control in figure 31.
periodic
event-driven
(MTMSPlanning)
]
Partially coordinated approach I f FMS Predictive control~" Load Evaluation and'~
achine Affectation_.] Machine Scheduling
Cooperative c~ Local
)
I
Dynamic control
Detailed Scheduling ) (tools~""~tranfers) ] ~ ~operations) j
Database for follow-up data
On-line control J
FMS Control
Controlled system Figure 30 : FMS P l a n n i n g a n d Control System.
: ..... i
233 Co-operative control concerns exchange with upper level to find solution when the Decision frame cannot be respected. Local D a t a b a s e is used to m a i n t a i n an image of the controlled system. Some aggregation functions allow to t r a n s m i t to the upper level the results achieved by the controlled system. 3.1.2.
Physical Architecture
The practical aim of the Physical Architecture is : - o p e r a t o r s m u s t use the Control Software, - o p e r a t o r s have to be motivated to obtain the best "score" with their FMS, - o p e r a t o r s have to be involved in the improvement of functions and interfaces. For this, the FMS Control Software must be: - a n agreeable software to use, it m u s t encourage to "play" with all the functions, -efficient to obtain information, to print reports on all the aspects of the FMS, - a media allowing the decision m a k e r s to c o m m u n i c a t e between t h e m but also p r o v i d i n g all o p e r a t o r s w i t h i n f n r m a t i o n a n d knowledge, So, the actual trend is to install a local network of Workstations : - one station for the Central Control, - o n e station for each h u m a n cell responsible for a p a r t of the FMS (Cells, Complex machines,...), - o n e station for each function (transfer, d a t a b a s e , tools, storage, Direct Numeric Control). Each workstation has the following specifications : - connected to the other workstations by a network, - r u n n i n g with multi-task and real-time operating system, -owning a multi-windowing interface capable of connecting several colour screens, - e q u i p p e d with office utilities for operators: mail, word processing, s p r e a d s h e e t and copy/paste functions between office software and control software.
234 Physical
-
-I
control
Architecture
Central controll
Functional
---
Control
I
(,.transfers)
Architecture
I
i
I
(,.tools
)
t
]Cell control Cell
l
] Cellc~176 ] (Cell~ 2 L )
! ...... I
(Database)
Network
]
[Workstation(
I
QDNC machines)
) Controlled O bFunction jeCtor
F i g u r e 31 : P h y s i c a l A r c h i t e c t u r e . A n u m b e r of principles have to be respected w h e n u s i n g this physical architecture: - D e c i s i o n - m a k e r c o d e : each operator liable to use the workstation m u s t have a card or a badge to control access to a n u m b e r of critical functions of the FMS Control Software, - F l e x i b i l i t y i n c o n t r o l 9 each operator must have access to its tasks from all the Workstations, - A c c e s s t y p e : each task or program may be used under different modes (consultation, modifications, information) according to the responsibility of the operator. 3.2.
Building of the Database (object-oriented
approach).
The Database is a fundamental element of the FMS Control Software. It m u s t be a Real-time Database with the following problems to solve : - A c c e s s t i m e : when a disturbance is detected or when a schedule is computed a lot of data has to be reached rapidly. -Updating : all the shared information m u s t be recorded in and retrieved from the Database to prevent inconsistencies between two programs. - M u l t i p l e d o m a i n s : the Database contains several aspects of the same data according to the domain : routes operations for schedules, operations for D.N.C. In an FMS Control Software, we are essentially concerned with A c c e s s t i m e . So, we propose to realise a RAM Database through an object language (RAM: Random Access Memory, a work memory whose Access time is quicker t h a n disk memory). This Database will be managed by a dedicated workstation with a great a m o u n t of RAM memory to be accessed rapidly from any workstation. The contents of the Database are essentially: - the object m o d e l s of the Controlled FMS - object model of the FMS (Common kernel), - a d d e d models: Machine Scheduling, Detailed Scheduling, - object model of the Flow-Profiles -object model of the Manufacturing Environment Multi-graph
235 - the o b j e c t m o d e l of the FMS P l a n n i n g Control System Each p r o g r a m of the global software is an object in this structure. This concept allows to design an Open Control S y s t e m easy to develop a n d m a i n t a i n . The software d e v e l o p m e n t t a s k is unified in one p r o g r a m m i n g e n v i r o n m e n t . 3.3.
Building of the Knowledge-base
(predicate-logic approach).
We will t r y to specify two points about the building of the Knowledge-base 9 - the content of a Knowledge-base for an FMS Control Software, - the w a y to e n t e r knowledge in the base. Two other i m p o r t a n t questions are not t r e a t e d in this p a p e r " the m a n a g e m e n t of t h e k n o w l e d g e coherence a n d K n o w l e d g e - b a s e o r g a n i s a t i o n to m a n a g e jointly object models a n d sets of rules. For a first r e s p o n s e to this r e s e a r c h problem, see [PAC 92]. 3.3.1.
Contents of the Knowledge-base
Generally, the Knowledge-base contains information about how to use d a t a a n d models in the FMS Control Software. This knowledge m a y be divided into four parts" - Knowledge about Flexibility, - History of the FMS operation, - K n o w l e d g e about M a n - M a c h i n e Interactions, - Knowledge about D y n a m i c Control. 3.3.1.1. Knowledge about Flexibility In m a n y control s i t u a t i o n s , the o p e r a t o r s or the p r o g r a m s need i n f o r m a t i o n about the flexibility of the shop. Two m a i n types of flexibility are considered 9 - M a c h i n e or e q u i p m e n t Flexibility, - Product Flexibility. E a c h e q u i p m e n t of the FMS h a s various o p e r a t i n g modes. A n o r m a l mode is chosen b u t one m a y h a v e to switch to a n o t h e r mode in order to solve some d i s t u r b a n c e s i t u a t i o n s . This technical i n f o r m a t i o n is often u n k n o w n to t h e Control Software. It is i m p o r t a n t to describe all these modes and to e n t e r t h e m in the Knowledge-base. E a c h m a c h i n e m a y also have several configurations. T h e s e c o n f i g u r a t i o n s a r e r e l a t e d to t h e tools, t h e p r o g r a m s or specific e q u i p m e n t a t t a c h e d to t h e m a c h i n e . If a f o r m a l d e s c r i p t i o n of t h e s e configurations is available in the Knowledge-base, the F M S Control Software (or t h e o p e r a t o r ) will be able to s e a r c h a s u b s t i t u t i o n s o l u t i o n w h e n a d i s t u r b a n c e occurs. To m e e t a m a n u f a c t u r i n g order, several T P P m a y be used to obtain one s a m e product. In t h e s a m e way, w i t h i n a route, for c e r t a i n o p e r a t i o n s , s e v e r a l m a c h i n e s m a y be used. This flexibility knowledge about the product should be described to give the operators and the software a capability to react a n d a d j u s t the plan. All t h e s e possible choices ( o p e r a t i n g mode, m a c h i n e configuration, route,...) m a y be guided (or inferred) by an Analysis of the set of m a n u f a c t u r i n g orders
236 sent by the MTMS. This analysis may be made by a rule-based expert system [SUN.S9]. 3.3.1.2.
History
This part of the Knowledge-base concerns the record of the FMS operation and its Control Software. The history of the shop allows operators or software to compare present situations with past situations. We propose to classify this historical knowledge into four parts: - Disturbance situations, - Strategies used to solve disturbances situations, - AI solving strategies for generic situations, - Statistics about each route type. 3.3.1.3. Knowledge about Man-Machine Interactions This p ar t of the Knowledge-base is concerned with the m a n n e r to introduce situations to the Decision-Makers. In a disturbance situation, the FMS Control Software must show the operator the identified situation and the result of the Dynamic Control analysis (Auscultation, Diagnosis and Therapy). But, according to the disturbance situation and to the operator, the Man-Machine Interactions are different. So, the FMS Control Software m u s t a d a p t its interface and must learn new ways of presentation. 3.3.1.4.
Knowledge about Dynamic Control
This part of the Knowledge-base is concerned with how to use the Flow-Profiles and M a n u f a c t u r i n g E n v i r o n m e n t Multi-graph tools to solve d i s t u r b a n c e problems [ARC.91-3]. 3.3.2.
Principle
of Human
know-how
and knowledge integration
Formalising H u m a n know-how is difficult, which makes it necessary to adopt a p r a g m a t i c approach. Today, in FMS Control, we are not capable of p r o g r a m m i n g the computer learning of H u m a n know-how. So, we propose a progressive integration by defining Software Intelligence Levels (Esprit Project n~ [Milin 87]). The principle of this approach is to integrate gradually H u m a n know-how by observing Man-Machine Interactions. This allows to develop the software step by step without re-programming the lower levels.
237 Intelligence Man-Machine Interactions
Software Level in project More abstract Software Levr
More deterministic and less abstract Software Level
Figure
32:
Integration
of Human know-how Levels
in Software
Intelligence
The intelligence of a Software Level is related to the lower levels a l r e a d y implemented. In such a structure, the capabilities of the new level become simple functions of the new software. Once i m p l e m e n t e d , t h e y are not intelligent any more. Then, Intelligence is in the user and in the way to use these new functions. Accordingly, we have to analyse how this is done and try to design the new software level. So, in order to integrate knowledge in the FMS Control Software, we propose the following steps : - O b s e r v e and record the FMS Control Software operation including the Man-Machine Interactions; - A n a l y s e the previous records to define new concepts in the Knowledge-base; -Design a Man-Machine Interface to allow operators to use this Knowledge-base convivially; - O b s e r v e and record the Man-Machine I n t e r a c t i o n s on this new interface to identify generic behaviours; - Design and program new functions using the new concepts of the Knowledge-base.
3.4.
Building the processing modules.
Each processing module is a instance of an object Application.
object Application)
(objectViewl)
(objectView2)(
objectViewn )
F i g u r e 33 : Object s t r u c t u r e of a p r o g r a m .
238 An application is a t a s k or a computer job. It m a n a g e s several views. A view is generally located in a window. The skeleton of the object Applications depends on the Graphic E n v i r o n m e n t used (X-Windows, Windows, Motif, OpenLook, Macintosh,...). P r o g r a m m e r s should refer to the related "toolbox". 3.5.
Building Man-Machine
interfaces.
Before p r o g r a m m i n g i n t e r f a c e s , one should a n a l y s e the M a n - M a c h i n e Interactions precisely [BOY 92]. This can be done by the Scenario Method based on the analysis of Decision Activities, whose operating mode depends both on Man and Machine t h r o u g h an interface. When the scenarios are defined, the interface screens or windows m u s t be specified. Each interface is an instance of the object View. P r o g r a m m i n g a Man-Machine interface is very expensive. T h a t is why, it is i m p o r t a n t , for the work to be reusable, to build software components i n d e p e n d e n t l y of computer languages and m a c h i n e s [NEE.90]. For this, Graphic Abstract Data Type is a good tool to design the more difficult part of an interface: namely the Interactive Diagram. 3.5.1.
Scenarios Method to define Man-Machine Interactions.
This p a r t presents an analysis and design method for Interactive Decision Aid S y s t e m s using advanced M a n - M a c h i n e Interfaces (pull-down m e n u s , multiwindowing,...) [BER 90]. The basic principle is the same as in the GRAI's method: decision activities are first analysed, then those supported by Man and Machine both are detailed. To build a scenario it is necessary to identify Man actions a n d M a c h i n e actions and t h e r e f o r e the e v e n t s r e l a t e d to the synchronisation of these actions. First, we will present a form of GRAI net adapted to the modelling of ManMachine Decision Activities. Then, the second tool is the scenario using a three columns table for stating Man-Machine Interactions and Events. 3.5.1.1.
Man-Machine Decision Activities
Man reasoning may be characterised by active phases (Decision Activity) and passive phases (Decisional Situations). These two concepts and the Activity and E v e n t concepts in Discrete Event Modelling are very similar. To describe a reasoning process is to define and relate all these active and passive phases. The GRAI Net is used to m a k e a global description of the reasoning process as shown in figure 34.
239 F i g u r e 34 : D e c i s i o n A c t i v i t y w i t h
Man-Machine Interactions
E a c h Decision A c t i v i t y b e g i n s w i t h a n initial s i t u a t i o n Si a n d e n d s w i t h a final s i t u a t i o n Sj. E a c h d e c i s i o n a l s i t u a t i o n is a s t e p in t h e r e a s o n i n g p r o c e s s , c h a r a c t e r i s e d by a s c r e e n E l . T h e D e c i s i o n A c t i v i t i e s w i t h M a n - M a c h i n e I n t e r a c t i o n s a r e s u p p o r t e d b o t h by M a n M a n l a n d M a c h i n e M 1 . In t h e u p p e r l e f t - h a n d c o r n e r it is i n d i c a t e d w h e t h e r t h e s u p p o r t is t h e M a i n or a S e c o n d a r y s u p p o r t . T h e M a i n s u p p o r t m a n a g e s t h e I n t e r a c t i v e process. B e t w e e n t h e s e two s u p p o r t s , a t r a p e z i u m f o r m a l i s e t h e i n t e r f a c e I n t l . T h e E i s c r e e n s c h a r a c t e r i s e t h e decisional s i t u a t i o n s a n d a r e specified by : -
t h e list of active p u l l - d o w n m e n u s , t h e list of o p e n e d w i n d o w s a n d the active w i n d o w Fi, t h e objects (icons), o u t s i d e t h e w i n d o w s , a copy of t h e s c r e e n in its m o r e classical state. Overload Situation
Sj - an origin is f o u n d Simulate and evaluate the effect of a modification SI=Si Q
k = situation without overload
F i g u r e 35 : D e c i s i o n P r o c e s s w i t h M a n - M a c h i n e I n t e r a c t i o n s
240 F i g u r e 35 s h o w s a n e x a m p l e of Decision P r o c e s s w i t h M a n - M a c h i n e Interactions. The objective is to solve an overload problem before scheduling. This iterative Decision Process consists of two activities: - the first activity is concerned with the search for the origin of the overload; it is driven by the m a n aided by the m a c h i n e (H1 is the m a i n support), -the second a c t i v i t y a i m s at m o d i f y i n g the p l a n a n d m a k e a s i m u l a t i o n to e v a l u a t e t h e consequence of this modification; it is driven by the computer (M1 is the m a i n support); two s i t u a t i o n s m a y be obtained Sl--Si w h e r e there is still an overload and S k w h e r e the overload problem is solved. Two different interfaces I n t l and I n t 2 support this interaction. 3.5.1.2.
Scenario
To define the scenario concept, we have to recall the two m a i n types of ManM a c h i n e Dialogue" - t h e modal dialogue, - t h e non-modal dialogue. T h e m o d a l d i a l o g u e is r u n u n d e r c o m p u t e r control. This dialogue asks a precise i n f o r m a t i o n from the h u m a n operator. As long as the m a n has not given his a n s w e r w i t h i n the f r a m e defined by the dialogue, he c a n n o t t a k e a n o t h e r step. This type of dialogue is i n t e r e s t i n g w h e n there is a risk of d a t a incoherence. This mode is easy to m a n a g e (and to p r o g r a m ) b u t it is h a r d l y interactive. The n o n - m o d a l d i a l o g u e is r u n u n d e r m a n control. He is free to select a m e n u , to activate a window or any object on the screen. This type of dialogue is highly interactive and allows a software to help a h u m a n user efficiently. A M a n - M a c h i n e scenario has to characterise these two interaction modes. It is composed of a t h r e e - c o l u m n table" - the first column describes m a n actions ( A m a n i), -the second one c o n t a i n s t h e e v e n t s e i and s c r e e n s Scri c h a r a c t e r i s i n g the beginning of a m a n or m a c h i n e action, - the t h i r d one defines the machine actions (Am i).
Menu: New model
Scri
Mouse: Close window
~
Open window
.1~
Aman
Save Dialog ~
Am
Scrj F i g u r e 36 : E x a m p l e of a s c e n a r i o E v e n t s are symbolized by arrows (figure 36).
241 E a c h Decision Activity is generally detailed by a scenario. T h a t is w h y it begins w i t h a s c r e e n S c r i (initial s i t u a t i o n ) a n d ends w i t h a s c r e e n S c r j (final situation). T h i s e x a m p l e shows t h a t a m a n action on the m e n u : N e w mode l leads to open a window. The scenario of figure 37 describes a Decision Activity b e g i n n i n g w i t h a m o d a l dialogue. The initial screen S e r i leads n e c e s s a r i l y to the m a n action A m a n l which leads to m a c h i n e action A m l . The end of the Decision Activity is decided by m a n action A m a n 2 which a u t o m a t i c a l l y leads to m a c h i n e action A m 2 a n d screen S c r j (final situation).
Aman
-----Tscri
I
AmX
I ]
Aman2 S
c
r
I
--- Am 2 j
~
F i g u r e 37 : S c e n a r i o w i t h e v e n t s l i n k e d to initial a n d final s i t u a t i o n s
Aman 1
Scri
Aman2
~lP.-
Am 1
~~.-
Am 2
Scrj F i g u r e 38 : S c e n a r i o w i t h n o n - m o d a l d i a l o g u e In figure 38, all the a r r o w s of the scenario go from m a n to m a c h i n e . No e v e n t a s k s for a c o m p u l s o r y r e s p o n s e from m a n . He can choose freely b e t w e e n A m a n l or A m a n 2 action. This is a purely non-modal scenario.
Aman 1
Scri
Aman2 .At--""
Am 1 ~lP--
Am 2
Scrj F i g u r e 39 : S c e n a r i o w i t h m o d a l d i a l o g u e F i g u r e 39 r e p r e s e n t s a p u r e l y m o d a l scenario. M a n action A m a n 2 consequence of m a c h i n e action A m 1 . 3.5.2.
is the
G r a p h i c A b s t r a c t D a t a T y p e s t o specify I n t e r a c t i v e D i a g r a m s .
G r a p h i c A b s t r a c t D a t a Types are a w a y to describe an I n t e r a c t i v e D i a g r a m i n d e p e n d e n t l y of a p r o g r a m m i n g l a n g u a g e . The a i m is to f o r m a l i s e t h e I n t e r a c t i v e D i a g r a m at two levels:
242 -its - its
g e o m e t r i c form, behaviour.
A G r a p h i c A b s t r a c t D a t a Type is c o m p o s e d of t h r e e parts: - a g e o m e t r i c form a n d its v a r i a b l e s , attributes, -methods describing the dynamic Diagram. -
behaviour
of t h e
Interactive
H e r e is a n e x a m p l e of a g e o m e t r i c form a n d of some of its v a r i a b l e s . H1 a n d Lc a r e t w o v a r i a b l e s c o r r e s p o n d i n g r e s p e c t i v e l y to t h e h e i g h t of a line a n d t h e w i d t h of a c o l u m n . T h e v a r i a b l e s a r e r e l a t e d to t h e g e o m e t r i c f o r m of t h e Interactive Diagram. If we u s e t h i s basic A b s t r a c t D a t a T y p e to define a R e s o u r c e G a n t t D i a g r a m , a line is a s s o c i a t e d to a r e s o u r c e a n d a c o l u m n to a period. T h e s e d e f i n i t i o n s a r e a t t r i b u t e s of t h e G r a p h i c A b s t r a c t D a t a Type. T h e a t t r i b u t e s a r e r e l a t e d to t h e s e m a n t i c c o n t e n t s of t h e I n t e r a c t i v e D i a g r a m . T h e classical m e t h o d s are: - c r e a t i o n of a n e w I n t e r a c t i v e D i a g r a m , - d e s t r u c t i o n of a n I n t e r a c t i v e D i a g r a m , - drawing method, - access to a t t r i b u t e s a n d v a r i a b l e s , - m a n a g e m e n t of m o u s e actions, m e n u actions, k e y b o a r d a c t i o n s . . . (xo,Yo) (o,o) Horizontal a line is a resource ........ .........:~:~:!~' i:.l Vertical Scale
~HI Graph
i a column 9,
.
F i g u r e 40 : G e o m e t r i c f o r m o f a G r a p h i c
Abstract
Data
Type
T h e following G a n t t D i a g r a m , L o a d D i a g r a m a n d D a y p l a n n i n g D i a g r a m a r e t h r e e e x a m p l e s i n h e r i t e d from this G r a p h i c A b s t r a c t D a t a Type.
243
Milling man Milling dnc
, ~ - ~ - ~ - ~ - ~ - ~ - ~ - ~ - ~ , - ~ - ~ - ~ . - ~ 9 . 9
"
Milling x25
:
9
l el i i~ i ~ l
~ l
:
....
I~lll~Ulllllill
."
.
~
9
DNC7222
1
DNC651
.
Tool 621 Painting _
I
I
!
.
I
.
.
I
.
.
Control 1
"
i.
i
i,
9
"
"
"
"
I
!
1
1
.-
~ ' ~ " ~ " ~ " ~ ' ~ ' ~ ' ~ " ~ _, .
i
I .......
.
"
~ ^ ^ ^
.
i
"
.
9. . . .
.
.
I
~
9
.....
.
-;____~%'~'~v~l
.
.
9 i
~
~
9
Z-
.
..~l~.l~.l~.l~.~_. . .
i
~
"
Washing
41 : Example
Figure
of Gantt
Diagram
9
.
l"- Il l l l!i'l l l li_ vac.
Figure
Monday 9 /
.
,i
.
i
~, /
.
42 : Example
Tuesday
i
,i
.
./
.
.
.
of Load Diagram
Wednesday .
~
.
Thursday :~....~i~
Friday
.........
-~ % % % % % % % % % % % % % % % ,"
/
s,
,,r
/
/
8h-15h
"."
/
,t
,,,,
... ..
./' . " ,,
t ,~ / / / / ,s / # % % % % % % % % ,, ,,, ,,, ,,, ,s / / ,,, ,,,
.% .% . %. %. %. %. .% r
,t
/
/
/
/
% ,s ,~ t .
9' " - ' " " " - " - ' " - ' " - ' " - ' ' -
......
...
.....~: ..:.~.,..:. . . . . :.
:
i
i
: ..:..
a .
.
.
.
--
.
.
.
.
.
' '== 8h-20h .
.I:.:?:..:"Z.....
". . . . . . . . : .
I
10h30 -20h - -
Figure
43 : Example
of Day planning
Diagram
Day of rest
244 This generic approach presents a n u m b e r of advantages: it gives added precision to the model, it m a k e s generalisations easier, it helps software development, it defines a software component independently of computer languages, these software components may be specified by users, it facilitates automatic generation of programs. 3.6.
Elaboration of a suitable programming
language.
The choice of a suitable p r o g r a m m i n g language has to be made according to the following criteria : -Modelling c a p a b i l i t y : t h e p r o g r a m m i n g data types of the language should facilitate the description of the various models used in the Software; to program lists and trees, the data type pointers and handles m u s t exist. - R a p i d i t y 9 to compute the scheduling algorithm or to search in graphs, the l a n g u a g e have to be very quick. So, it is not possible to use an Artificial Intelligence P r o g r a m m i n g E n v i r o n m e n t based on Lisp or Prolog. We therefore need a procedural language. -Objects 9 the conceptual models for Controlled FMS, for Software A r c h i t e c t u r e or for I n t e r a c t i v e D i a g r a m s are b a s e d on objects. Therefore, we need an object-oriented l a n g u a g e to p r o g r a m t h e s e models. - Reusability o f t o o l s : This criterion may be regarded as reusability of software components : - w i t h i n one same software, - from an FMS Planning and control software to another one, - f r o m an FMS P l a n n i n g and control software to a n o t h e r P l a n n i n g and control software applied to a correlated problem such as Course Scheduling, Project planning,... For this, the language m u s t support the notion of encapsulation to build software components (with one interface part and one i m p l e m e n t a t i o n part ). - P o r t a b i l i t y : the software m u s t be portable from a platform (hardware, operating system, multi-windowing environment) to a n o t h e r one. - I n t e r a c t i v i t y 9 this criterion is very much linked to the multi-windowing e n v i r o n m e n t . Today, t h i s c r i t e r i o n is often i n c o m p a t i b l e w i t h portability; choosing a common object library is a way to increase portability. C++, ADA or an Object Pascal may be good choices for the basic language. The choice of the Basic Object library will be made so t h a t it r u n s on several computers and operating systems. 3.7.
Development
methodology.
Once a processing module or program is specified, we need a method to write the program, to modify it and to rationalise its structure in order to m a k e it reusable [SAR.93].
245 MODEL
PHASIS
Object l i b r a r y of programming environment
Data
First object Specific Object l i b r a r y for Planning a n d ~ Control S t r u c t u r e of the main orogram
;pecific Object l i b r a r y for FMS Planning a n d _ Control
Definition of a subset of classes for the Model
5
I Testing a n d i n t e g r a t i o n in the m a i n o r o g r a m
Scenarii m e t h o d gives the user specifications
Writing of a set of m e t h o d s on a given subject
PROTOTYPE
PHASIC
Complete object Modification of the objects c o n c e r n e d Testing a n d i n t e g r a t i o n in the m a i n p r o g r a m and validation of m e t h o d s ng of a set of m e t h o d s on a given subiect Rational|sat|on Modification of the objects c o n c e r n e d
12
esting a n d v a l i d a t i o n
F~ Figure
44
9 Programming
Rational|sat|on
Methodology
~ - ~
246 Today, we are not able to design a final interactive program directly. Even with methods like the Scenarii Method, it is necessary to test the feasibility of the most interactive functions with the future users. So, the development methodology is an iterative process consisting of two m a i n phases [BER 91]: - t h e Model phasis aims at validating the m a i n concepts of the program, to prove its feasibility. This phasis consists in defining a first h i e r a r c h y of object classes and testing its capability to model simple cases. Only the main interactive functionality is p r o g r a m m e d to show the principle of Man-Machine Interactions. - t h e Prototype phasis gives the first program t h a t can be used for real cases. The P r o t o t y p e m u s t realise all the f u n c t i o n a l i t i e s described by the scenarii method. The flow d i a g r a m shows the successive steps of the m e t h o d and the m a i n supports of these phases: - the Scenarii Method gives the user specifications, - three object libraries are used to build the program: -Basic Object library of p r o g r a m m i n g environment, - Specific Object library for Planning and Control, - Specific Object library for FMS Planning and Control. The Basic Object library belongs to the p r o g r a m m i n g e n v i r o n m e n t and m u s t not be modified by the program. This library allows to m a n a g e the basic elements of the software: files, mouse and keyboard, menus, screens and windows, basic controls of the windows such as buttons, scroll bar, pictures,... All the programs in the FMS Software must use the same Basic Object library. The Specific Object library for Planning and Interactive Gantt Diagrams, Calendars, Tasks,... Many concepts of the Kernel Model library. For the purpose of FMS Control they fit better with FMS modelling.
Control concerns objects such as Resources, P r o d u c t s , R o u t e s , are inherited from objects in this can be modified by inheritance to
The Specific Object library for FMS P l a n n i n g and Control contains all the objects designed specifically for our software. They may be inherited from the two other libraries. The objects m u s t be able to be used in several programs of the software. The use of this three related libraries is a good m a n n e r to save time (and money) w h e n p r o g r a m m i n g an FMS P l a n n i n g and Control S o f t w a r e . Reusability of objects saves time, in addition, encapsulation of code avoids wasting time in debugging programs. MODEL PHASIS Step 1 :
D a t a Dictionary
It is a classical step in p r o g r a m analysis. It consists in describing all the d a t a entities with t h e i r a t t r i b u t e s and relations. Most of these entities have to become objects.
247
Step 2:
First object hierarchy The F i r s t object h i e r a r c h y is d e s i g n e d from the D a t a Dictionary. It is an object h i e r a r c h y specific to our problem. The rules to choose which objects have to be created are issued from the two specific Object libraries and from the know-how of object p r o g r a m m i n g in the e n v i r o n m e n t t h a t has been chosen.
Step 3"
Structure o f the main program The S t r u c t u r e of the main program is directly related to the p r o g r a m m i n g e n v i r o n m e n t and to its Basic object library. Each environment has its own way to organise the skeleton of a main program. This step is also concerned with the design of main m e n u s and windows.
Step 4:
Definition o f a subset o f classes for the Model The purpose of the Model is to test the feasibility of the m a i n concepts concerning the program. So, this step selects a set of classes t h a t are significant for these concepts.
Step 5"
Testing a n d Integration in the main program The aim is to achieve c o m p a t i b i l i t y b e t w e e n the object h i e r a r c h y designed for our FMS Control problem and the more s t a n d a r d object structure of the main program.
Step 6"
Writing o f a set o f methods on a given subject The global s t r u c t u r e of the p r o g r a m is now defined. The p r o g r a m m i n g job begins. Steps 6, 7 and 8 are a loop. For each loop, a subject is chosen (for instance, saving objects in the Database) and all the related methods are programmed for all the objects concerned.
Step 7"
Modification o f the objects concerned P r o g r a m m i n g an object m e t h o d m a y lead to modify an attribute of the object or the interface (external view) of another object.
Step 8"
Testing and validation of methods This step builds simple cases to use and validate the method algorithms.
PROTOTYPE PHASIS Step 9"
Complete object hierarchy F r o m the first object hierarchy and the results of the Model this step builds the object h i e r a r c h y specific to FMS. Some attributes are added to model FMS real cases better.
248
Step 10:
Testing and Integration in the main program Idem step 5
Step 11:
Writing o f a set of methods on a given subject Idem step 6
Step 12:
Modification of the objects concerned Idem step 7
Step 13:
Testing and valhtation of methods Idem step 8
Rat/ona//sat/on The r a t i o n a l i s a t i o n step aims at c r e a t i n g or u p d a t i n g objects a f t e r a d e v e l o p m e n t phasis. It is a t e a m work b e t w e e n p r o g r a m m e r s b u i l d i n g different p a r t s of the same software. Even if this step is not included in the d e v e l o p m e n t methodology, it is very i m p o r t a n t to improve both specific libraries. The more extended these libraries will be, the less expensive the programs will be to develop.
4.
Conclusion
FMS P l a n n i n g and Control is an interdisciplinary field. Required tools come from O p e r a t i o n a l R e s e a r c h , C o n t r o l T h e o r y , S o f t w a r e E n g i n e e r i n g , M a n u f a c t u r i n g Systems Modelling. To design an efficient Software Architecture we t h i n k t h a t it is n e c e s s a r y to have a global and integrated approach of the problem. We therefore propose to view this problem as a Control Problem, as the main objective is to guide the FMS towards m a n u f a c t u r i n g objectives defined by the upper Decision Levels. In order to m a s t e r the complexity of FMS our basic option is to design a convivial Control Software. The second option is to design an Open a n d Evolutive System. The p r o g r a m m i n g option to choose an object e n v i r o n m e n t allows to r e u s e software components and to realise a true Open and Evolutive Software. So, it is a good way to a t t e m p t to reduce prohibitive development and m a i n t e n a n c e costs. To continue and to improve the efficiency of the Control S y s t e m we use a m u l t i p l e - a g e n t a p p r o a c h . To put it shortly, this approach t r a n s f o r m s each object into an agent by giving it an objective to reach and its own knowledge. The scheduling a l g o r i t h m is based on a cooperative a g e n t net. It m a y be activated according to several strategies depending on the a g e n t s u m m o n e d . For instance, it is possible to activate only one operation agent or one machine agent. In t h a t case, the agent activated controls the algorithm by exchanging m e s s a g e s w i t h others. So, the s c h e d u l i n g a l g o r i t h m p o s s e s s e s s e v e r a l strategies according to the agent activated. Each agent is potentially an input
249 point of the algorithm. This operation structure should improve the scheduling algorithm flexibility. On-line and dynamic control will be able to use it to make p a r t i a l plans. This should also help users to enter t h e i r s decisions more quickly and to obtain partial plans more easily.
5.
Biblio
[ARC.87]
raohv
ARCHIMEDE B., D6veloppement du noyau de l'outil de simulation SIMGRAI et des outils logiciels pour le t r a i t e m e n t des r6seaux de donn6es, M6moire de DEA, Universit6 de Bordeaux 1, Septembre 1987. [ARC.91-1] B. A R C H I M E D E - C o n c e p t i o n d'une a r c h i t e c t u r e r 6 a c t i v e distribu6e et hi6rarchis6e pour le pilotage des s y s t ~ m e s de production - Th~se de doctorat - Universit6 de Bordeaux 1.1991. [ARC.91-2] B. ARCHIMEDE, L. PUN, C. BERARD, G. DOUMEINGTS - RealT i m e D y n a m i c a l D i a g n o s i s in t h e C o n t r o l of F l e x i b l e M a n u f a c t u r i n g System - IMACS S y m p o s i u m - 7,10 Mai 1991 Casablanca, Maroc. [ARC.91-3] L. PUN, B. A R C H I M E D E , C. BERARD, G. D O U M E I N G T S I n t e l l i g e n t L e a r n i n g - a i d for an I n t e l l i g e n t F M S - M o n i t o r i n g Process - CIRP Workshop on intelligent Learning M a n u f a c t u r i n g System - March 6,8 1991 - Budapest. Ch. BERARD, D. BREUIL, G. DOUMEINGTS & L. PUN. Decision [BER.81] aid in job shop production. 6th I n t e r n a t i o n a l Conference on Production Research, Novisad, Yougoslavie (August 1981). BERARD Christian, Contribution h la conception de s t r u c t u r e s [BER.83] logicielles pour le pilotage d'atelier, Th~se de Docteur-Ing6nieur, Universit6 de Bordeauxl, Janvier 1983. C. BERARD, A. GUDEFIN, A. BOURELY, G. D O U M E I N G T S . [BER 85] "SIMGRAI : a new tool to s i m u l a t e m a n u f a c t u r i n g systems". IMACS, Oslo, Norv~ge (August 1985). C H R I S T I A N BERARD, GUY D O U M E I N G T S . - M a n - M a c h i n e [BER 87] Communication Analysis in a Decision Aid System for Controlling M a n u f a c t u r i n g Activities - New Techniques and Ergonomics, Hermes, Paris, 1987, p.68-81. [BER89] B E R A R D C h r i s t i a n , L.T.N. S E G U I N , A. D u p e u x , M a n u e l d ' u t i l i s a t i o n de SIPA+, l a b o r a t o i r e GRAI, U n i v e r s i t 6 de Bordeauxl, Janvier 1991. [BER90] C. B E R A R D , Ph. N G U Y E N . I n t e l l i g e n c e A r t i f i c i e l l e et Productique, IFIP: "M6thode des scenarii: Analyse et Conception des interfaces Homme/Machine", Bordeaux, (Mai 1990). [BER91] BERARD Christian, Les R6seaux de Donn6es, r a p p o r t interne, laboratoire GRAI, Universit6 de Bordeauxl, Janvier 1991. [BOC.91] BONNEVAL A., COURVOISIER M., COMBACAU M., FMS Realtime Monitoring: Decision-Making Aspects in Automatic Recovery, C o m p u t e r A p p l i c a t i o n s in P r o d u c t i o n a n d E n g i n e e r i n g . , IFIP,1991, p. 409/416. [BON. 91] C. BONNEMOY et S.B. HAMMA, La m6thode du recuit simul6 optimisation globale dans R n, RAIRO Vol 25, N~ 1991 (477-496)
250 [BOW.91] [BOY. 92] [BUR.86] [COU.89]
[DOU.84] [DOU.90] [DOU.87]. [ELO. 92] [GRA.91]
[GUY 91] [HUT.91] [JON.85] [JON.90] [KAL.85] [KAL.85] [KER.93]
[LEC 90]
R.BOWDEN, J.BROWNE, Approach to the production environment design task within factory coordination, Computer I n t e g r a t e d Manufacturing Systems, Vol.4 N~ February 1991 pp 42-50. BOY G., M~thodologies et outils pour l ' I n t e r a c t i o n HommeMachine, M~moire d'habilitation, Universit~ Paris 6, Juin 1992 BURBIDGE J. L., Production flow analysis, International Journal of Production Research, Octobre 1986. COURVOISIER M., VALETTE R., SAHRAOUI A., COMBACAU M., Specification and implementation techniques for multilevel control and m o n i t o r i n g of FMS, C o m p u t e r Applications in Production and Engineering., IFIP,1989, p. 509/516. DOUMEINGTS G., M~thode GRAI: m~thode de conception des syst~mes en productique, Th~se d'~tat, Automatique, Universit~ de Bordeaux I, 13 Novembre 84, 519 p.. D O U M E I N G T S G., M~thode pour concevoir et specifier les syst~mes de production, L a b o r a t o i r e GRAI, U n i v e r s i t ~ de Bordeaux I, CIM 90,Teknea, p. 89/103. DOUMEINGTS G., DARRICAU D., POUMEYROL E. et ROBOAM M., La m~thode GRAI, Cours de l'Universit~ de Bordeaux I, 1986 / 87, 43 p. A. ELOMRI, M~thodes d ' o p t i m i s a t i o n d a n s un c o n t e x t e productique, Th~se de Doctorat de l'Universit~ Bordeauxl, 1992 PETER O'GRADY, RAMADURAI SESHADRI, X-Cell intelligent cell Control using object-oriented programming (part I), Computer Integrated Manufacturing Systems, Vol.4 N~ August 1991 pp 157163. GUYOT J e a n Edouard, Les outils de r~action du module PCS (Planification, Conduite, Suivi), laboratoire GRAI, Universit~ de Bordeauxl, M~moire DEA, Septembre 91. HUTCHISON Jim, LEONG Keong, SNYDER David, WARD Peter, S c h e d u l i n g a p p r o a c h e s for r a n d o m job shop flexible manufacturing systems, Prod. Res., vol 29,n ~ 5,1991, p. 1053/1067. J O N E S A., MCLEAN C., A Production Control Model for the AMRF, Proceedings of the International ASME Conference on Computers in Engineering J O N E S Albert, SALEH Abdol, A m u l t i - l e v e l / m u l t i - l a y e r architecture for intelligent shopfloor control, Computer Integrated Manufacturing, vol 3 ,n ~ 1,1990, p. 60/70. KALLEL G., PELLET X., BINDER Z., Conduite d~centralis~e coordonn~e d'atelier, R.A.I.R.O., APII, vol 19,n ~ 4, 1985, p. 371/ 387. KALLEL Ghazali, Proposition d'une COnduite DEcentralis~e COordonn~e(CODECO) pour un atelier de fabrication, Th~se de Docteur, Institut National Polytechnique de Grenoble, Juin 1985. L.KERMAD, C.AUSFELDER, J.P. BOUREY, E CASTELAIN, Integrative approach for a functional specification of FMS Control, C o m p u t e r I n t e g r a t e d M a n u f a c t u r i n g S y s t e m s , Vol.6 N~ November 1993 pp 219-227. LECLERC Christophe, Aide au pilotage: R~alisation d'une architecture multit~ches pour le pilotage temps r~el de l'atelier,
251
laboratoire GRAI, Universit~ de Bordeauxl, M~moire d'ing~nieur, Septembre 90. LE GAL A., Un syst~me interactif d'aide ~ la d~cision pour le [LEG.89] l'ordonnancement et le pilotage en temps r~el d'atelier, Th~se de Doctorat, Universit~ Paul Sabatier de Toulouse, Septembre 1989. [MAD.90] H.K.MADHUSUDHANA, KRIPA SHANKA, FMS s i m u l a t i o n model u s i n g P C - S I M S C R I P T II.5, C o m p u t e r I n t e g r a t e d Manufacturing Systems, Vol.3 N~ August 1990 pp 150-156. [MAH.90] MAHMOODI F., DOOLEY K. J., STARR P., An investigation of dynamic group scheduling heuristics in a job shop m a n u f a c t u r i n g cell, Prod. Res., vol 28,n~ p. 1695/1711. [MER.93] K. M E R T I N S , W . S U S S E N G U T H , I n t e g r a t e d i n f o r m a t i o n modelling for CIM, Computer Integrated Manufacturing Systems, Vol.4 N~ August 1991 pp 123-131. MILIN : "Amelioration de solutions d'ordonnancement pour l'aide [MIL 87] au pilotage d'ateliers", Th~se d'universit~: Automatique: Bordeaux I:1987. [MON.90] MONTAZERI M., VAN WASSENHOVE L. N., A n a l y s i s of scheduling rules for an FMS, Prod. Res., vol 28,n ~ 4,1990, p. 785/ 802. [MUK.91] MUKHOPADHYAY S. K., MAITI B., GARG S., Heuristic solution to the scheduling problems in flexible m a n u f a c t u r i n g system, Prod. Res., vol 29,n ~ 10,1991, p. 2003/2024. Francis NEELAMKAVIL, Development of graphical software for [NEE.90] CIM applications, Computer Integrated Manufacturing Systems, Vol.3 N~ August 1990 pp 157-162. PACHET F., Representation de connaissances par objets et r~gles: [PAC 92] le syst~me N~Opus, Th~se de Doctorat : Informatique option Intelligence Artificielle, Universit~ Paris 6, Septembre 1992 PELLET X., Sur la hi~rarchisation des d~cisions. Application ~ la [PEL.85] c o n d u i t e d ' a t e l i e r , Th~se de Docteur, I n s t i t u t N a t i o n a l Polytechnique de Grenoble, 1985. PLOBNER Alain, M~thodes de conception et de d~veloppement des [PLO.84] logiciels de pilotage d'unit~s de production, Th~se de Docteur ing~nieur, Universit~ de Bordeaux 1, 1984. PORTMANN M. C., M~thodes de d~composition s p a t i a l e et [POR.88] temporelle en o r d o n n a n c e m e n t de la production, R.A.I.R.O., APII, vol 22,n ~ 5, 1988, p. 439/451. P O R T M A N N M.C.,M~thodes de d~composition s p a t i a l e et [POR.87] temporelle en ordonnancement de la production, Th~se de doctorat d'~tat ~s sciences, Universit~ de Nancy 1, Septembre 1987. [PUN 83] L. PUN, G. DOUMEINGTS, A. BOURELY. "GRAI Methodological Approach to the design of Flexible Manufacturing". ICPR 83, Windsor, Canada (August 22-24 1983). [PUN 84] L. PUN. Syst~mes industriels d'Intelligence Artificielle - Outils de Productique. Editions : Editest en fran~ais (1984), Plenium en anglais (1986), Friendship en chinois (1986). [ROU.88] ROUBELLAT F., THOMAS V., Une m~thode et un logiciel pour l'ordonnancement en temps r~el d'ateliers, R.A.I.R.O., APII, vol 22,n ~ 5, 1988, p. 419/438.
252 [SAN.91] [SAR.93] [SUN.89] [THO.80]
[THO.90]
[TIT.79] [VEE.93]
[WAR.91]
S.P.SANOFF, D.POILEVEY, Integrated information processing for production scheduling and control, Computer Integrated Manufacturing Systems, Vol.4 N~ August 1991 pp 157-163. P.SARGENT, Inherently flexible cell communications : a review, C o m p u t e r I n t e g r a t e d M a n u f a c t u r i n g Systems, Vol.6 N~ November 1993 pp 244-259. SUN QI-ZHI, Expert simulation for online production control, Computer Integrated Manufacturing Systems, Vol.2 N~ August 1989 pp 172-180. THOMAS V., Aide ~ la d~cision pour l'ordonnancement en temps r~el d'atelier, Th~se de 3 ~ cycle, Universit~ Paul Sabatier, Toulouse, 1980. THOMESSE Jean-Pierre, Les services de t e r r a i n FIP et l ' i n t ~ g r a t i o n dans les syst~mes automatisms, Colloque International CIM90, 12-14 juin 1990, p. 565/ 573, Bordeaux, France. TITLI (A.).- Analyse et commande des syst~mes complexes. Toulouse, Cepadues Editions, 1979, 237 p. D.VEERMANI, B.BHARGAVA, M M BARASH, Information system architecture for heterarchical control of large FMSs, Computer Integrated Manufacturing Systems, Vol.6 N~ May 1993 pp 76-92. H.J.WARNECKE, W.DANGELMAIER, Functions and interfaces in a flexible production planning and control system, Computer Integrated Manufacturing Systems, Vol.4 N~ February 1991 pp 3141.