Tài liệu Computer-Aided.Design.Engineering.and.Manufacturing P1 docx

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 pro

1 System Approach

to the Design

of Generic Software

for Real-Time Control of Flexible

Manufacturing Systems (FMS)1.1 Preface

The Control Hierarchy • Objects and Architecture

of the Control Software1.11 Conclusions

1.1 Preface

The control system is the core of any flexible manufacturing system (FMS) because it confers to the plantthe 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 isthe 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 flexibilityand genericity On the contrary, reducing the programming and reprogramming effort needs a genericsoftware 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 abstractformalism representing both hardware/software components of the FMS and the production plans The latterconsists 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 ofthe shop floor (SF) and the production progress To face the second problem, we use the object-orientedapproach to design the kernel of the generic control software The resulting modular architecture isorganized so that modules and interfaces among them can be replaced without altering the overallfunctionality

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 haveemphasized the role of production systems In particular the FMSs are of increasing importance becausethey have the capability to face changes in production environment and to combine the efficiency of themass-production lines with the flexibility of job-shops producing a variety of products in small- ormedium-size batches In any FMS, control software plays a key role since it can allow optimization ofboth hardware (numerically controlled machines, material handling devices, buffers, etc.) and software(information flow, data base content, etc.) Moreover FMS control should offer adaptive and dynamicfeatures to absorb internal and external changes and to use all the resources efficiently However, theliterature 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 contemporarysoftware 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 partmix and minimizing the programming and reprogramming effort

To design a generic and flexible control software, two main problems emerge The first one is thateffective control of the FMS activities depends on the existence of a formalism consisting of a unifyingabstraction upon which a comprehensive and consistent knowledge base can be constructed For thisreason, the search for appropriate frameworks, taking into account the system operation, underlies recentefforts in the area of flexible automation Naylor and Maletz [14], Naylor and Volts [15] The secondproblem consists in identifying an appropriate, modular software architecture capable of integratingstandard 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 accountspecific instances of particular FMSs without changing the software main structure and interfaces amongdifferent parts

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], andmany others In our approach the DEDS state encompasses information on both the current operatingconditions 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 Theinformation on the SF operating conditions and on the production progress is described using theprimitive concepts of entities, entity attributes, and relationships between entities themselves, allorganized in a relational structure [2] updated at each event occurrence The decision rules, appearing assystem state components, can be changed at any instant Due to the formal structure of these rules, onecan 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, ifnecessary, by enriching the state with further entities, attributes, and relationships Moreover, the modelallows us to describe a generic FMS, producing an arbitrary part mix, under an arbitrary schedulingpolicy Finally, the mechanism for state updating and the definition of all the exogenous events triggeringsuch transitions lead to a DEDS model that completely describes the FMS behavior at job release andflow 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 DEDSmodel Indeed, this model establishes how the plant should respond to the command signals and interactsboth with the higher level (production planning) and with the lower one (hardware components) Theresulting 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 generalizesthe formalism proposed in [5], necessary to develop a generic control software at the job release andflow 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 andprocedures (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 itsconfiguration to fit particular production needs These characteristics are key features when the reuse ofexisting software (i.e., for planning, hardware components for managing data base, etc.) is one of themain objectives

The organization of this contribution is as follows The general methodology for building the tial state of the DEDS model is the main concern of Section 1.4 Sections 1.5 and 1.6 specify the basicentities, 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 completesthe DEDS model by defining events, DEDS state, model clock and mechanism for event-driven statetransitions Section 1.9 applies our formalism to a case study Section 1.10 discusses the organization of

sequen-a generic control softwsequen-are, sequen-as it emerges from the DEDS formulsequen-ation Finsequen-ally, Section 1.11 drsequen-aws theconclusions

1.4 Fundamental Steps of the Modeling Process

To build an abstract comprehensive framework, we must specify the circumstances and restrict the aspectsunder 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 involvesvariables changing continuously over time, the DEDS model abstracts from this behavior and records theoccurrence 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 ignorecontinuously occurring micro-changes This is because we can describe the behavior of an FMS by means

of sentences as “at instant t1 the machine m1 starts processing job j 2” or “at instant t1 machine m1 fails” or,again, “job j1 enters the buffer b1 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 atinstants determined by the internal system dynamics or by the environment actions In contrast withconventional dynamic systems, however, states have logical or symbolic, rather than numerical, valueswhich change on the occurrence of events To establish this framework, we refer to the concepts used byZeigler [20], [21], [22] by developing an appropriate DEDS formalism based on the expressive andrigorous tools of logic and set theory

The proposed approach builds the FMS model in a hierarchical, modular manner by putting partstogether to form larger ones in successive steps

The first step is to identify the basic entities of the framework These are both hardware and softwareelements 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 throughthe network of queues Typically, this class includes machine, buffer, server, and transport entitysets The cardinality and the members of such sets are permanent elements of the model structureeven if some resource is unavailable occasionally

2 The processing activity entity sets contain the basic elements of the manufacturing activity Setsbelonging to this category consist of orders, job types, active processing procedures, and allowablealternative sequences of operation steps in a given working procedure The above entities changeduring 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 thesystem 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 withdefining entity attributes Associations take the form of mathematical relations among entities and areexpressed as functions mapping from an entity set into another one or appear in the form of specifiedrelationship 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 andthe attributes defined on entity sets (or subsets) belonging to the same category For instance, the jobentity 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 activityconfiguration (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), namedqueuing network configuration, embodies all the entities with their attributes and relations integratingall the elements in a whole

The third step provides the formal representation of the set of decision rules governing the flow ofthe 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, thesole information about a rule is how it utilizes the queuing network configuration knowledge to makeproper decisions

The fourth step defines the model clock, i.e., the event occurrence times, and measures the elapsedtime from the last event occurrence We consider two types of events The internal system dynamicsgenerates the internal events (operation step and transport operation completion, etc.) The externalevents (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) remainsunchanged

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 andattributes 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 Typicalattributes define resource capacity

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 m0)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 aserver of m i The fictitious machine has no server

Machine entity set: M  {m i , i  1, 2,…, N M}

Buffer entity set: B  {b,  1, 2,…, N B}

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: H  {h 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 : U→H

T  {(h n , m k , m j ) h nH m k , m jM}

TT : T→R

Production Orders

An FMS may manufacture final products of NP types, grouped in NO 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 inexecution 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 theproduct 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 toall 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 WI collects elements from W representing initial working procedures (to perform

on not assembled jobs just loaded into the system)

Job type entity set: P  {p, 1, 2,…, N P}

Order entity set: O  {o,1, 2,…, N O}

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 (ml, ) with each v, where ml  M stands for the machine hosting the piece,

while l} defines the set of workcenters co-operating with ml If { } is the set of all the

subsets of M with cardinality k (k  0, 1,…, NM

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

m1 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 v0 and w0) with BEL-V(v0 )  w0, PT(v0)  0, TS(v0)  N,

JHM(v0)  m0 and where COM(v0) is equal to the empty set The operation step v0 does not stand for a real

processing operation, but it indicates that a job is at m0, i.e., in the central buffer Obviously, v0 does notpertain to any ‘‘true’’ working procedure

Job Configuration

In our experimental frame, when a job enters the system, it lies in the buffer of the first machine thatmust process it If the first operation step can take place immediately, the job directly goes on to one ofthe machine servers with no delay If all the servers of the workstation are busy, the piece waits in theinput (input/output) buffer Once a server becomes free, the job engages it and the machining processcan start In some cases more servers of different machines must concur to the machining After one ormore activity completions, the job goes on to the output (input/output) buffer, waiting for a newdestination, according to a selected route of the associated working procedure

However there are many problems that make the modeling more difficult First, the machine inputbuffer is in general not empty because many jobs may be queuing If the buffer is completely full it cannotreceive 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 Inthis case, the job remains blocked on the server of the hosting machine

After these preliminary remarks, we come to our concern If NJ 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(jk) equals Ready, if jk is in an input or input/output buffer and not all the required servers are available; Ready for assembling, if jk is in a buffer and the pieces concurring in the assembly are not all available; Running, if jk 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 jk 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 jk is moving to the next workcenter.

According to the values of J-STATUS(jk), we can partition the job entity set into the following six subsets:

J R, JRA, J Ru , JDW, JTW , and JC 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 tothe 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: J  {j k,k 1,  2,…, N J}

TJ: J→P

J-STATUS: J→{Ready, Ready for assembling, Running, Waiting for destination

Waiting for transport, Carried}

ROS: J→V

Depending on the value of J-STATUS(jk), the previous function takes the following meanings

if jk  JR  JRA  JTW  JC, ROS(jk) specifies the next operation step already assigned to jk;

if jk  JRu, ROS(jk) coincides with the operation step in progress;

if jk  JDW, ROS(jk) 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(jk) The condition LOS(jk)  n.o.s (no operation step) means that ROS(jk) is the first operation step executed by (or to execute on) jk.

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(jk) indicates the buffer hosting jk, BOO(jk) is the transport unit booked for transferring jk to its next destination and CAR(jk) denotes the transport unit transferring jk to the destination workcenter.

An important attribute in the DEDS model framework is the time to complete either a processing (if

j k  JRu) or a transport operation (if jk  JC) The ‘‘Residual Operation Time’’ function

specifies this attribute In particular ROT( jk) defines the residual time required for the booked transport (i.e., BOO(jk)) to reach the buffer hosting jk, if jk  JTW and the whole time to perform the next operation step (i.e., ROS(jk)), if jk  JR  JRA; finally ROT(jk)  , if j k  JDW 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 atransport or an operation step completion, the destination buffer is full In such a case, the job remainsblocked on the transport unit or on the hosting machine server The blocking attribute function

points out this condition Namely BA(jk) equals 1 (0) if jk is blocked (not blocked) There is another

situation similar to blocking, indicating that a job is prevented from changing its status In this case thejob cannot release the resource it currently holds This condition can be indicated by the attribute ‘‘StateChange Inhibitor”

where SCI(jk)  1 means that J-STATUS(jk) is prevented from changing value On the contrary, if SCI( jk) 

0 no limitation is put on the modification of J-STATUS(jk).

Finally, further attributes can be introduced that are useful to take job priority decisions Someexamples are the arrival time at the buffer and the arrival time at the system

Now we are in the position to define the 13-tuple:

C j  {J, TJ, J-STATUS, ROS, HOS, BOO, CAR, ROT, LOS, BA, SCI, BAT, SAT} named job

configu-ration It fully characterizes the jobs within the system and the operations which they are currentlysubject to

Server Configuration

The number of available servers may change with time as a result of occasional failures and repairs Toexhibit the server operative conditions, we introduce the server status attribute

S-STATUS : S → {Idle, Running, Blocked, Down, Reserved}

where S-STATUS(sij) is equal to: Idle, if sij is inactive; Running, if sij is processing a piece; Blocked, if sij cannot unload the piece already processed because the output (input/output) buffer is full; Down, if sij

is out of order; Reserved, if sij is not currently busy at service, but it is booked for some operation step

requiring machine co-operation

In particular, if S-STATUS(sij)  Reserved, the job requiring service from sij is put in relation to such

a server Analogously, Running or Blocked servers are in relation to Running jobs Such relationships are

specified by the functions reserve and process

where the subset SR collects the Reserved servers, while SRuB groups the Running or Blocked ones Finally

the triple

is called the server configuration

Transport System Configuration

The following function characterizes the status of each truck

U-STATUS : U → {Idle, Carrying, Blocked, Booked, Down}

with an obvious meaning of the four conditions In particular, U-STATUS(unr)  Booked if unr is moving

to the buffer hosting the piece jk to transport next When U-STATUS(unr)  Idle, we assume that unr is standing close to a machine So, denoting by UId the subset of Idle trucks, we establish such a relationship

by the function rest close to the machine

To account for failure conditions of a whole transport subsystem, we introduce the Transport system status attribute

Sub-In conclusion, the triple

fully describes the transport system configuration

Definition of the Queuing Network Configuration

We call queuing network configuration the 4-tuple F  (C p , C j , C s , C h) and denote by F(t) its value at time t Moreover, F indicates the set of all the 4-tuples F Using standard symbols introduced in [13],

Figure 1.1 assembles all the entities and the relationships composing both queuing network configurationand structural view

1.7 Scheduling Policy

Adding flexibility to the factory floor increases the scheduling alternatives and, hence, the decisioncomplexity Moreover, the necessity of quickly reacting to dynamic changes in the system makes theoperation scheduling more difficult To approach this problem, we consider the currently applied sched-uling rules as an essential component of the system state That is, at each instant, the rules are elements

of the knowledge of the current system behavior Hence, we do not propose any particular schedulingpolicy for resource management at the job release and job flow levels; rather we decompose the schedulingproblem into elementary decision makings (micro-decisions) generally concerning the selection of oneentity (job, operation step, server transport unit, etc.) in a proper subset Then, to formally describe suchmicro-decisions, we introduce appropriate functions (decision rules) by indicating their domain andtheir range and leaving undetermined their specific decision mechanism In essence a decision rulecorresponds to a module that, when invoked, receives data from the current queuing network configu-ration and makes the decisions it is in charge of Furthermore a scheduling policy is a set of decisionrules, each of which specifies a micro-decision In consequence of a modification in production goals,the scheduling policy may vary with time because at any instant the upper decision levels may require

to apply a new rule and to remove another one To this aim, a set of possible scheduling rules can bepredetermined by the planning staff and stored in a library

The job loading and job flow management require the choice of the product type to introduce nextinto the system and the corresponding loading time, the routing of each job within the systems, ifalternative paths are available, and the resource allocation when concurrence conditions arise

Job loading decision rules Decisions concerning the piece type to introduce next into the system and

the corresponding loading time must be taken simultaneously The sequencing function and timingfunction describe the loading decisions

In particular, ls(F) specifies the initial working procedure of the next job entering the system In otherwords, the value of ls(F) particularizes the raw piece to load and lt(F) indicates the interval betweenthe current time and the loading instant The trivial element ‘‘n.c.’’ stands for ‘‘no choice is possible,’’ sothat when ls(F) equals ‘‘n.c.,’’ lt(F) must be This indicates that no choice is possible, till a change

in the 4-tuple F occurs By assumption, if , a new job can enter the system and receiveservice according to ls(F) In this case, the first buffer that has to host the new piece is not full

State change inhibition rule On an event occurrence, it establishes if the status change of a job is

allowed or inhibited

In particular, sci(F, jk)  1 (0) indicates that SCI(jk) must be set to 1 (0).

Job routing decision rules As mentioned in Section 1.6, a job is processed according to a sequence of

operation steps selected from a set of alternatives In particular such choices concern the following

FIGURE 1.1 Entity-relationship diagram of both queuing network configuration and structural view.

1 The next step among the alternative operations in a working procedure The following decisionfunction

rules the selection Here v(F, v) specifies the step to execute after the operation already

completed (i.e., after v) Obviously, we get [v, v(F, v)]  R iff

2 The first operation step in a working procedure The corresponding ruling function is

where a,RA(F, jk) gives

a set of Ready for assembling and noninhibited jobs, such that {jk}  (F, jk) collects all the

jobs necessary to perform the assembly step ROS(jk).

5 The selection of a job among those prevented from changing status If denotes the set ofjobs with State Change Inhibitor equal to 1, the function

chooses a job in order to reset to zero its state change inhibitor The condition i(F) n.c means that the function does not select any job

The choices regarding servers refer to:

6 The selection of an idle server to perform an operation step The function

rules this decision Hence s(F, mi) identifies an Idle server belonging to mi

7 The selection of the first server to consider available for a new operation, among those completing

an operation step Let be a server subset such that for any couple of distinct elements

from it holds: BEL-S -S( ) Denoting by { } the set of all possible , weintroduce the function

where fs(F, S) defines a server chosen from S;

8 The selection of a server to unblock next The ruling function is

with bs(F, mi) specifying a Blocked server belonging to mi

The choices regarding transport units relate to:

9 The selection of a unit for a job transport The function

expresses this decision where h(F, mi, mj) indicates the transport unit chosen to move a piece

from mi to mj, with {BEL-U[ h(F, mi, mj)], mi, mj}  T if

10 The selection of a transport unit to unblock next The ruling function is

The unit bh(F, mi) is chosen among the Blocked ones waiting for transferring the just carried

piece to the input (input/output) buffer of mi.

Finally, the 15-tuple:

defines the scheduling policy and (t) denotes its value at time t

Before concluding this section, we define the residual time to the next job input (RT), to completethe information on the system operating condition Namely, since the timing function lt is invoked atdiscrete times (i.e., at the event occurrences only), it is necessary to keep memory of the scheduled time

for the next job input In particular RT(t) is the residual time to the next job input evaluated from the

instant of the last occurred event

In conclusion, in our experimental frame the 3-tuple

holds the information on the system operating condition C(t) is the sequential state at time t for the

“DEDS model [21], [22] In particular, the pair [F(t), RT(t)] corresponds to the informational component,”

i.e., to a set of structured data, describing in-progress activity plans (Cp), status of both resources and jobs,

their mutual associations and, finally, their relations with manufacturing activities (Cj, Cs, Ch) TheScheduling Policy (t) expressing the decision procedures is the second component of the sequential state.