1 System Approach to the Design of Generic Software for Real-Time Control of Flexible Manufacturing Systems (FMS) 1.1 Preface 1.2 Dedication 1.3 Introduction 1.4 Fundamental Steps of the Modeling Process 1.5 Specification of the Model Static Structure Workstations • Transport System 1.6 Queuing Network Configuration Production Activity Configuration • Job Configuration • Server Configuration • Transport System Configuration • Definition of the Queuing Network Configuration 1.7 Scheduling Policy 1.8 The Discrete Event Dynamic System Model Events • The DEDS Model 1.9 An Example of How the Modeling Process The Model Static Structure of the Application Example • The Queuing Network Configuration of the Application Example • The Applied Scheduling Policy 1.10 The Generic Control Software Organization The Control Hierarchy • Objects and Architecture of the Control Software 1.11 Conclusions Appendix: List of Principal Symbols Maria Pia Fanti Politecnico di Bari Bruno Maione Politecnico di Bari Giacomo Piscitelli Politecnico di Bari Biagio Turchiano Politecnico di Bari © 2001 by CRC Press LLC 1.1 Preface The control system is the core of any flexible manufacturing system (FMS) because it confers to the plant the capability to absorb internal changes and external fluctuations in demand and in production environ- ment. However, the technical literature has repeatedly documented that poor control software design is the major source of difficulties in implementing FMSs. Namely, the FMS potentiality is not yet fully utilized, because typical, contemporary control software packages are still proprietary and do not possess flexibility and genericity. On the contrary, reducing the programming and reprogramming effort needs a generic software usable in an arbitrary FMS, producing an arbitrary part mix. To design a generic software, two main problems must be solved. The former is to define an abstract formalism representing both hardware/software components of the FMS and the production plans. The latter consists in identifying a modular architecture of the control software capable of integrating standard modules. To solve the first problem, we use a system approach leading to a discrete event dynamic system (DEDS) that constitutes a formal framework providing information on both the current operating conditions of the shop floor (SF) and the production progress. To face the second problem, we use the object-oriented approach to design the kernel of the generic control software. The resulting modular architecture is organized so that modules and interfaces among them can be replaced without altering the overall functionality. 1.2 Dedication To our parents Maria Pia Fanti, Biagio Turchiano To the memory of my parents Bruno Maione 1.3 Introduction In recent years, the worldwide competition and the growing demand for a high variety of products have emphasized the role of production systems. In particular the FMSs are of increasing importance because they have the capability to face changes in production environment and to combine the efficiency of the mass-production lines with the flexibility of job-shops producing a variety of products in small- or medium-size batches. In any FMS, control software plays a key role since it can allow optimization of both hardware (numerically controlled machines, material handling devices, buffers, etc.) and software (information flow, data base content, etc.). Moreover FMS control should offer adaptive and dynamic features to absorb internal and external changes and to use all the resources efficiently. However, the literature has repeatedly documented that information flow and control software are the primary sources of difficulties in implementing FMSs. Namely, as a result of their proprietary nature, typical contemporary software packages for controlling manufacturing systems suffer from lack of flexibility and of genericity. They enable particular productivity improvements and focus on particular aspects of a specific plant. On the contrary, a generic software is necessary—usable in an arbitrary FMS producing an arbitrary part mix and minimizing the programming and reprogramming effort. To design a generic and flexible control software, two main problems emerge. The first one is that effective control of the FMS activities depends on the existence of a formalism consisting of a unifying abstraction upon which a comprehensive and consistent knowledge base can be constructed. For this reason, the search for appropriate frameworks, taking into account the system operation, underlies recent efforts in the area of flexible automation Naylor and Maletz [14], Naylor and Volts [15]. The second problem consists in identifying an appropriate, modular software architecture capable of integrating standard software modules, e.g., for data base management, for field-events detection, and so on. More- over, if there is the necessity, the modules of this architecture should be changeable to take into account specific instances of particular FMSs without changing the software main structure and interfaces among different parts. © 2001 by CRC Press LLC To solve the first problem, we refer to Zeigler’s approach [20], [21], [22] which describes DEDS by using a set-theoretic formalism based on system theory concepts of Zadeh and Desoer [19], Wymore [18], and many others. In our approach the DEDS state encompasses information on both the current operating conditions of the SF and the progress of the programmed production. Moreover it includes a logic com- ponent collecting the decision rules necessary to resolve conflicts arising in the resource allocation. The information on the SF operating conditions and on the production progress is described using the primitive concepts of entities, entity attributes, and relationships between entities themselves, all organized in a relational structure [2] updated at each event occurrence. The decision rules, appearing as system state components, can be changed at any instant. Due to the formal structure of these rules, one can establish the information necessary to support the decision making. The approach followed to define the DEDS state is transparent and has some advantages. First of all, it allows a detailed and modular description of the production system. Major details can be given, if necessary, by enriching the state with further entities, attributes, and relationships. Moreover, the model allows us to describe a generic FMS, producing an arbitrary part mix, under an arbitrary scheduling policy. Finally, the mechanism for state updating and the definition of all the exogenous events triggering such transitions lead to a DEDS model that completely describes the FMS behavior at job release and flow management levels. To face the second problem, we consider the operation control of FMS from a model reference point of view. Our approach consists in driving the SF so that it follows the dynamics of the reference DEDS model. Indeed, this model establishes how the plant should respond to the command signals and interacts both with the higher level (production planning) and with the lower one (hardware components). The resulting control architecture emerges as direct consequence of this idea of utilizing the DEDS formulation to define the kernel of a generic software driving the dynamics of the actual FMS. Inspired by the works of Naylor and Volts [15], Naylor and Maletz [14], the paper [7] considerably improves and generalizes the formalism proposed in [5], necessary to develop a generic control software at the job release and flow management levels. Moreover, in the same line of [7], we emphasize the principles of structure, orderly partitioning, and modularity by using an object-oriented approach to design the control software. Namely, we decompose the control software into modules (objects) which encapsulate both data and procedures (methods) characterizing their behavior and which interact by sending one another messages. In addition the role and the interfaces of such objects remain unchanged, even if the FMS modifies its configuration to fit particular production needs. These characteristics are key features when the reuse of existing software (i.e., for planning, hardware components for managing data base, etc.) is one of the main objectives. The organization of this contribution is as follows. The general methodology for building the sequen- tial state of the DEDS model is the main concern of Section 1.4. Sections 1.5 and 1.6 specify the basic entities, relationships, and attributes defined on the entity sets. Section 1.7 introduces the formal rep- resentation of the decision rules that govern the flow of the transitional entities. Section 1.8 completes the DEDS model by defining events, DEDS state, model clock and mechanism for event-driven state transitions. Section 1.9 applies our formalism to a case study. Section 1.10 discusses the organization of a generic control software, as it emerges from the DEDS formulation. Finally, Section 1.11 draws the conclusions. 1.4 Fundamental Steps of the Modeling Process To build an abstract comprehensive framework, we must specify the circumstances and restrict the aspects under which we consider the system. In other terms, we have to define an experimental frame. In respect to this fundamental point, we observe that even if the real behavior of the manufacturing plant involves variables changing continuously over time, the DEDS model abstracts from this behavior and records the occurrence of certain discrete events only. Namely, we consider the evolution of the manufacturing plant as a record (or a trace) of the occurrence of certain discrete, qualitative changes in the system, and ignore continuously occurring micro-changes. This is because we can describe the behavior of an FMS by means © 2001 by CRC Press LLC of sentences as “at instant t 1 the machine m 1 starts processing job j 2 ” or “at instant t 1 machine m 1 fails” or, again, “job j 1 enters the buffer b 1 which becomes empty,” etc. Expressions building such sentences e.g., ‘‘starts processing part,’’ ‘‘the machine fails,’’ ‘‘the job enters the buffer,’’ ‘‘the buffer becomes empty,’’ etc. indicate the occurrence of discrete events, but ignore continuous changes in variables such as ‘‘the amount of metal cut,’’ ‘‘the raw material consumption,’’ ‘‘the instantaneous speed of the transport units,’’ etc. In conclusion, we model a generic FMS taking into account sudden changes of states occurring at instants determined by the internal system dynamics or by the environment actions. In contrast with conventional dynamic systems, however, states have logical or symbolic, rather than numerical, values which change on the occurrence of events. To establish this framework, we refer to the concepts used by Zeigler [20], [21], [22] by developing an appropriate DEDS formalism based on the expressive and rigorous tools of logic and set theory. The proposed approach builds the FMS model in a hierarchical, modular manner by putting parts together to form larger ones in successive steps. The first step is to identify the basic entities of the framework. These are both hardware and software elements and may, or not, change with time. Homogeneous entities are grouped in appropriate sets (entity sets) which, on their part, belong to three categories: 1. The resource entity sets collect the basic elements providing service for customers flowing through the network of queues. Typically, this class includes machine, buffer, server, and transport entity sets. The cardinality and the members of such sets are permanent elements of the model structure even if some resource is unavailable occasionally. 2. The processing activity entity sets contain the basic elements of the manufacturing activity. Sets belonging to this category consist of orders, job types, active processing procedures, and allowable alternative sequences of operation steps in a given working procedure. The above entities change during the manufacturing process and hence are transitionary. 3. The job entity set contains the basic temporary entities of the model, i.e., jobs (pieces) in the system at a given time. Both cardinality and elements of such a set change with time. The second step of the procedure deals with establishing associations between entity sets and with defining entity attributes. Associations take the form of mathematical relations among entities and are expressed as functions mapping from an entity set into another one or appear in the form of specified relationship sets. Functions mapping from an entity set (or a relationship set) into different value sets (such as the set of reals, non-negative integers, {0, 1}, { Up , Down }, etc.) define the entity (relationship) attributes. Typical attributes encountered in the proposed framework are the number of final products, the buffer capacity, the server status, the current position of an Automated Guided Vehicle (AGV), etc. Attributes either characterize each of the entities in the system or keep track of their current status. An entity may also be indirectly related to another one. Hence the need arises of an overall perspective in which all the entities, together with their attributes and relationships, contribute to represent the FMS as a whole. This leads to the concept of configuration. A configuration collects all the relationships and the attributes defined on entity sets (or subsets) belonging to the same category. For instance, the job entity set (or a subset of it) is the domain of attributes and relationships pertaining to the job configuration ( C j ). Furthermore both the server configuration ( C s ) and the transport system configuration ( C h ) consist of relationships and attributes defined on resource entity sets (subsets). Finally the production activity configuration ( C p ) includes all the attributes and relationships defined on processing activity entity sets, e.g., job type, order, working procedure, operation step entity sets, etc. The 4-tuple ( C p , C j , C s , C h ), named queuing network configuration, embodies all the entities with their attributes and relations integrating all the elements in a whole. The third step provides the formal representation of the set of decision rules governing the flow of the transitional entities. Rules concern job loading, routing, and priority setting. In the proposed frame- work, the focus is on the formal representation of rules rather than on the rules themselves. Namely, the sole information about a rule is how it utilizes the queuing network configuration knowledge to make proper decisions. © 2001 by CRC Press LLC The fourth step defines the model clock, i.e., the event occurrence times, and measures the elapsed time from the last event occurrence. We consider two types of events. The internal system dynamics generates the internal events (operation step and transport operation completion, etc.). The external events (hardware component failure or repair, order removal, or insertion, etc.) represent disturbances or manipulated variables. In a time interval in which no event takes place, ( C p , C j , C s , C h ) remains unchanged. All four steps lead to the set-theoretic foundation of the DEDS model. 1.5 Specification of the Model Static Structure This section presents the structural view underlying the model. It combines entities, relationships and attributes that do not change with time and describe the system resources. Typical entities are machines, buffers, servers, and transport subsystems. Typical relations express association between resources. Typical attributes define resource capacity. Workstations We begin to characterize the FMS workstations by defining the machine, buffer, and server entity sets. Consider an FMS with N M available workcenters. These constitute the set Each machine m i is provided with an input/output buffer, or, alternatively, with both an input buffer and an output one. Sometimes, the FMS has a central buffer where jobs wait for their next destination. At this point we introduce the set where N B indicates the number of buffers in the system. The attribute distinguishes the type of buffer, where TB( b ) ϭ I(O, IO) indicates that b is an input (output, input/output) buffer. The central buffer can be viewed as the IO buffer of a fictitious machine (say m 0 ) that must be included in the set M . Moreover, the buffer capacity attribute assigns a finite size to each buffer. Here I ϩ is the positive integer set. Finally, each machine m i is equipped with S i servers. All the servers within the system make up the Now, to specify how elements from B (from S ) are related to elements of M , we introduce the functions where BEL- B ( b ) ϭ m i indicates that the buffer b belongs to m i and BEL- S ( s ij ) ϭ m i means that s ij is a server of m i . The fictitious machine has no server. Machine entity set: Mm i , i{ 1, 2,…, N M }ϭϭ Buffer entity set: Bb , 1, 2,…, N B ϭ{}ϭ TB: B I, O, IO}{→ BC: B I ϩ → Server entity set: Ss ij , i 1, 2,…, N M , j 1, 2,…,S i ϭϭ{}ϭ BEL-B: BM→ BEL-S: SM→ © 2001 by CRC Press LLC Transport System Within the FMS, there are many possible transport subsystems to transfer pieces from a machine to another one. Here we consider only AGV systems, while [7] describes a wide variety of transport systems. So let N H AGV subsystems be available. An AGV subsystem h n ( n = 1, 2,…, N H ) consists of N n trucks (AGV units). For sake of simplicity, we assume that each truck can carry only one piece at a time from the output (input/output) buffer of a machine to the input (input/output) buffer of another workcenter. We group the transport subsystems in a specific entity set Analogously, we arrange the trucks in the following set The following function associates each element from the transport unit entity set with the corresponding one in the transport subsystem entity set and the relationship set (transport set) specifies all the transports the material handling system is able to perform. Finally the function expresses the transport time. In particular, ( h n , m k , m j ) ʦ T if the subsystem h n can carry a piece from m k to m j , while TT[( h n , m k , m j )] indicates the time such a transport requires. 1.6 Queuing Network Configuration The sequential state specification still requires further entities, relationships, and attributes organized in four configurations and constituting the queuing network configuration. In contrast to the structural view, the queuing network configuration varies with time, tracing the system dynamic path. Production Activity Configuration To keep track of the current status of the production activities, we have to take full account of shop orders by specifying their due dates, item types, and quantities. Moreover we must describe the working procedures of each job type and specify how and how many parts are assembled to compose final products. Finally, since many alternative sequences of operation steps can make up the same working procedure, we must indicate the alternative routes each job can follow, the machines involved, and the time each operation step requires. In the sequel we describe orders, working procedures, and operation steps separately. However, they all contribute to set up the production activity configuration.[12] Transport subsystem entity set: Hh n , n 1, 2,…, N H ϭ{}ϭ Transport unit entity set: U {u nr , n 1, 2, …, N H , r 1, 2, …, N n }ϭϭ ϭ BEL-U : UH→ Th n , m k , m j ()h n Hm k , m j Mʦʦ{}ϭ TT : T R ϩ → © 2001 by CRC Press LLC Production Orders An FMS may manufacture final products of N P types, grouped in N O production orders. So the set identifies job types (final product types) in the production mix. A production order is a demand for the production of one or more types of pieces. The set collects the identifiers of the orders currently in execution and the function specifies the production order corresponding to each piece type. To complete the description of a production order, we specify the attributes due date (DD) and the product number (PN) demanded for each type Job Working Procedures A final product may result from assembly operations. Hence, the need arises to establish the way of combining intermediate products. To this end, we preliminary denote with W the number of working procedures necessary to obtain the P -type final product. All the working procedures corresponding to all the job types build up the Moreover the function indicates that every working procedure is in relation with a job type. At this point we are ready to introduce the following assembly relationship set which describes the ways of assembling intermediate into finished products. The pair (w ␣ , w  ) ʦ A iff (if and only if) the parts resulting from the working procedure w ␣ are components of items manufactured according to w  . The relationship set A has the attribute weight where WE(w ␣ , w  ) defines the number of pieces resulting from w ␣ which concur in the assembly of one item to submit to w  . Finally, the subset W I collects elements from W representing initial working procedures (to perform on not assembled jobs just loaded into the system). Job type entity set: Pp , 1, 2,…, N P ϭ{}ϭ Order entity set: Oo ␥ , ␥ 1, 2,…, N O ϭ{}ϭ BEL-P: PO→ DD: O R ϩ → PN: P I ϩ → Working procedure entity set: Ww ␣ , 1,…, N P ␣ 1,…, W ϭ,ϭ{}ϭ BEL-W: WP→ Aw ␣ ( w  ),{ w ␣ w  , W BEL-Ww ␣ ()ʦ BEL-Ww  ()ϭ p }ϭϭ WE: A I ϩ → © 2001 by CRC Press LLC Operation Steps A working procedure is executed by a sequence of operation steps selected in a set of alternative allowable sequences. Denoting by V ␣ the number of operation steps composing w ␣ , we introduce the The relationship indicates the working procedure which an operation step belongs to and the following function represents the attribute processing time of the operation steps. Furthermore, the alternative routing relationship describes all the alternative sequences carrying out a working procedure The pair (v ␣ , v ␣␦ ) ʦ R iff there exists an allowable sequence in which the operation step v ␣ is right before v ␣␦ . Since any operation step may require one or more machines (co-operating machines), we associate an ordered couple (m l , ) with each v ␣ , where m l ʦ M stands for the machine hosting the piece, while ʕ MϪ{m l } defines the set of workcenters co-operating with m l . If { } is the set of all the subsets of M with cardinality k (k ϭ 0, 1,…, N M Ϫ 1), the job hosting machine (JHM) and the co- operating machines (COM) functions establish the following relationships between the entity sets V and M Here JHM(v ␣ ) and COM(v ␣ ) specify respectively the first and the second element of the couple associated with v ␣ . Of course, if is the empty set, the operation step v ␣ needs machine m 1 only. Finally, the attribute type of step indicates if any operation step is normal (N) or involves assembling of parts (A). For systems with a central buffer a particular remark is in order. Namely in this case each of sets V and W must contain a special element (respectively v 0 and w 0 ) with BEL-V(v 0 ) ϭ w 0 , PT(v 0 ) ϭ 0, TS(v 0 ) ϭ N, JHM(v 0 ) ϭ m 0 and where COM(v 0 ) is equal to the empty set. The operation step v 0 does not stand for a real processing operation, but it indicates that a job is at m 0 , i.e., in the central buffer. Obviously, v 0 does not pertain to any ‘‘true’’ working procedure. The 16-tuple is defined as the ‘‘Production Activity Configuration’’ and may change with time, for example in conse- quence of a modification in the production orders. Operation step entity set: Vv ␣ , 1,…, N P ␣ 1,…,W  1,…, V ␣ ϭϭ ϭ{}ϭ BEL-V: VW→ PT : V R ϩ → Rv ␣ v ␣␦ ,()v ␣ v ␣␦ , V BEL-Vv ␣ ()ʦ BEL-Vv ␣␦ ()ϭ{}ϭ M l M l M JHM: VM→ COM: V M {}→ m l , M l () M l TS: V N, A{}→ C p O, P, W, A, V, R, DD, BEL-P, PN, BEL-W, WE, BEL-V, PT, JHM, COM, TS{ }ϭ © 2001 by CRC Press LLC Job Configuration In our experimental frame, when a job enters the system, it lies in the buffer of the first machine that must process it. If the first operation step can take place immediately, the job directly goes on to one of the machine servers with no delay. If all the servers of the workstation are busy, the piece waits in the input (input/output) buffer. Once a server becomes free, the job engages it and the machining process can start. In some cases more servers of different machines must concur to the machining. After one or more activity completions, the job goes on to the output (input/output) buffer, waiting for a new destination, according to a selected route of the associated working procedure. However there are many problems that make the modeling more difficult. First, the machine input buffer is in general not empty because many jobs may be queuing. If the buffer is completely full it cannot receive more pieces. In this case the transport unit cannot unload the job and remains blocked. Finally, after the completion of machining, the job cannot immediately enter the output buffer if this is full. In this case, the job remains blocked on the server of the hosting machine. After these preliminary remarks, we come to our concern. If N J is the number of pieces currently in the system and J is the corresponding the type of job function states the relationship between pieces and job types. The following function defines the attribute specifying the operative status of a job where J-STATUS(j k ) equals Ready, if j k is in an input or input/output buffer and not all the required servers are available; Ready for assembling, if j k is in a buffer and the pieces concurring in the assembly are not all available; Running, if j k is receiving service from one or more machines or if, after an operation completion, it cannot move to the output buffer, because the hosting server is blocked; Waiting for destination, if j k resides in an output or input/output buffer and is waiting for the selection of its next destination and of an appropriate transport unit; Waiting for transport, if j k is in an output or input/output buffer and is waiting for a transport unit. In this case, both the next operation step and the transport unit have been already chosen; and Carried, if j k is moving to the next workcenter. According to the values of J-STATUS(j k ), we can partition the job entity set into the following six subsets: J R , J RA , J Ru , J DW , J TW , and J C . Indeed, introducing the above subsets is necessary to define the functions pertaining to the job configuration. A first group of functions associates jobs with entities belonging to the processing activity entity sets. Namely, at the instant t each piece within the system requests or receives service, according to an operation step from V. This relation is indicated by the function reference operation step: Job entity set: Jj k k 1, 2,ϭ …, N J ,{}ϭ TJ: JP→ J-STATUS: J {Ready, Ready for assembling, Running, Waiting for destination→ Waiting for transport, Carried} ROS: JV→ © 2001 by CRC Press LLC Depending on the value of J-STATUS(j k ), the previous function takes the following meanings if j k ʦ J R ʜ J RA ʜ J TW ʜ J C , ROS(j k ) specifies the next operation step already assigned to j k ; if j k ʦ J Ru , ROS(j k ) coincides with the operation step in progress; if j k ʦ J DW , ROS(j k ) specifies the operation step just completed. In a similar way the function last operation step indicates the operation step executed by a job just before ROS(j k ). The condition LOS(j k ) ϭ n.o.s. (no operation step) means that ROS(j k ) is the first operation step executed by (or to execute on) j k . A second group of functions maps job entity subsets into the resource entity sets. In particular, the following functions establish relationships between subsets of J and the buffer entity set and the transport unit entity set where HOS(j k ) indicates the buffer hosting j k , BOO( j k ) is the transport unit booked for transferring j k to its next destination and CAR(j k ) denotes the transport unit transferring j k to the destination workcenter. An important attribute in the DEDS model framework is the time to complete either a processing (if j k ʦ J Ru ) or a transport operation (if j k ʦ J C ). The ‘‘Residual Operation Time’’ function specifies this attribute. In particular ROT( j k ) defines the residual time required for the booked transport (i.e., BOO( j k )) to reach the buffer hosting j k , if j k ʦ J TW and the whole time to perform the next operation step (i.e., ROS(j k )), if j k ʦ J R ʜ J RA ; finally ROT(j k ) ϭ , if j k ʦ J DW . Note that each residual time is always evaluated starting from the instant of the last event occurrence. As mentioned before, blocking conditions may occur during the FMS operation, i.e., when, on a transport or an operation step completion, the destination buffer is full. In such a case, the job remains blocked on the transport unit or on the hosting machine server. The blocking attribute function points out this condition. Namely BA(j k ) equals 1 (0) if j k is blocked (not blocked). There is another situation similar to blocking, indicating that a job is prevented from changing its status. In this case the job cannot release the resource it currently holds. This condition can be indicated by the attribute ‘‘State Change Inhibitor” where SCI(j k ) ϭ 1 means that J-STATUS(j k ) is prevented from changing value. On the contrary, if SCI( j k ) ϭ 0 no limitation is put on the modification of J-STATUS(j k ). Finally, further attributes can be introduced that are useful to take job priority decisions. Some examples are the arrival time at the buffer and the arrival time at the system LOS: JV n.o.s.{}ʜ→ HOS: J R J RA J DW J TW B→ʜʜʜ BOO: J TW U→ CAR: J C U→ ROT: J R ϩ ϱ{}ʜ→ ϱ BA: J Ru J C ʜ 0, 1{}→ SCI: J 0, 1{}→ BAT: J R J RA J DW J TW R ϩ →ʜʜʜ SAT: J R ϩ → © 2001 by CRC Press LLC [...]... Configuration of the Application Example Let us assume that the FMS has only one production order o1 currently in execution, to manufacture two final products p1 and p2, representing 509 and 640 part types Thus actual job type and order entity sets are P ϭ {p1, p2} and O ϭ {o1} with BEL-P(p) ϭ o1 for ϭ 1, 2 Due dates and product numbers complete the production order description DD ( o 1 ) ϭ K t.u PN ( p... there are NJ ϭ 4 jobs in the system: J ϭ {j1, j2, j3, j4} Table 1.2 lists all the job attributes TABLE 1.2 Job Attributes in the Current State Jobs Attributes j1 j2 j3 j4 JT J-STATUS p1 Waiting for destination p2 Carried p1 Running p2 Ready ROS LOS HOS CAR ROT BA SCI SAT BAT v1,2 v1,1 b10 – v2,2 v2,1 – u1 2 t.u 0 0 20 t.u – v1,1 n.o.s – – 20 t.u – 0 22 t.u – v2,1 n.o.s b7 – 20 t.u – 0 40 t.u 40 t.u ϱ... be easily updated event by event In the following we show how to define decision rules in this case Job loading decision rules For the job type sequencing, we assume a periodic order as the following (p1, p2, p 1 ,…) So, at each event occurrence, a job enters the system if the first resource of its working procedure has at least an idle place in the input buffer and if the transition digraph DTr(qЈ) . flexible manufacturing system (FMS) because it confers to the plant the capability to absorb internal changes and external fluctuations in demand and in production. arbitrary FMS producing an arbitrary part mix and minimizing the programming and reprogramming effort. To design a generic and flexible control software, two main