A Petri net-based methodology to increase flexibility in service-oriented holonic manufacturing systems

Computers in Industry 76 (2016) 53–68

Contents lists available at ScienceDirect

Computers in Industry journal homepage: www.elsevier.com/locate/compind

A Petri net-based methodology to increase flexibility in service-oriented holonic manufacturing systems F. Gamboa Quintanilla *, O. Cardin, A. L’Anton, P. Castagna LUNAM Universite´, Universite´ de Nantes, IRCCyN UMR CNRS 6597, Nantes, France

A R T I C L E I N F O

A B S T R A C T

Article history: Received 4 February 2015 Received in revised form 29 May 2015 Accepted 1 September 2015 Available online 2 January 2016

Distributed control systems such as the holonic manufacturing systems and service-oriented architectures have demonstrated to provide higher levels of flexibility, notably in the planning and scheduling functionalities, if well exploited. In scheduling, the use of fixed process plans generated by traditional planning approaches, usually leads to unrealistic schedules due to the lack of considerations of the workshop status. IPPS approaches try to break the gap between these two functionalities in favor of providing flexible plans adapting to the shop floor’s state. A key element in the creation of flexible process plans is the definition of a process model capable of representing alternatives solutions to the sequencing problem and therefore increasing the potential solution space. This paper presents a methodology to increase planning flexibility in service-oriented manufacturing systems (SOHMS). The methodology introduces a Petri net service-oriented process model (SOP model) capable of computing a product’s deadlock free sequential space and adapts to the fractal character of holonic architectures. A set of modeling rules, with illustrations, is presented for the automatic generation of the Petri net, based on a set of precedence conditions. To explore the solution space represented by the SOP model a holonic interaction protocol is presented. Moreover, a set of behavioral strategies is proposed in order to cope with the effects of a possible combinatorial explosion. A study case applied workshop example is presented to illustrate the modeling process of SOP models, compute the sequential solution space and demonstrate how this notably increases the number of potentially goods feasible solutions. ß 2015 Published by Elsevier B.V.

Keywords: Holonic manufacturing systems Petri nets Integrated process planning and scheduling Process orchestration Manufacturing services Process orchestration

1. Introduction In the last few decades, distributed systems have been subject to great research as a solution to create the ‘‘Next Generation Manufacturing Systems’’. These provide solutions to conventional manufacturing control in terms of robustness to disturbances, rapid adaptability to changes, rapid configuration and an efficient use of available resources [1]. The creation of such characteristics requires certain levels of flexibility in the system’s control architecture. The holonic manufacturing systems (HMS), a network of intelligent and autonomous agents called holons, provides such kind of flexibility by distributing control knowledge and responsibilities among different holons. This distribution of responsibilities and knowledge allows simplifying the complex

* Corresponding author. E-mail addresses: [email protected] (F. Gamboa Quintanilla), [email protected] (O. Cardin), [email protected] (A. L’Anton), [email protected] (P. Castagna). http://dx.doi.org/10.1016/j.compind.2015.09.002 0166-3615/ß 2015 Published by Elsevier B.V.

control problem into simpler tasks. Instead of a global problem formulation satisfying the abovementioned characteristics, the problem reduces to defining behavioral rules for each type of holon that will orient the HMS emergent behavior to converge to one with the desired characteristics. In other domain (computer science), the service-oriented architecture (SoA) contributes with flexibility but at a process level, i.e. in the process information structure. This decentralized control architecture has the main characteristic of decomposing computational processes into sub-processes, called services, to later distribute them among the different available resources [2]. The combination of both paradigms appears to be a very attractive solution as it combines structural flexibility at both; a control level (with the decomposition of control responsibilities) and at a process level (with the decomposition and encapsulation of processes). Work relating both paradigms can be found in [3–6]. From a system’s point of view, these flexibilities should be exploited in order to increase system performance while keeping a reactive behavior. In a flexible job shop environment with individual products, small batches, a high product variety and

54

F. Gamboa Quintanilla et al. / Computers in Industry 76 (2016) 53–68

new product arrivals, the control system should have the flexibility to change its plans and schedules as to absorb new product arrivals, perturbations due to model uncertainties and resource unavailability This flexibility should be achieved in both dimensions, as defined by Slack [7], in range by exploring the solution space provided by the nature of the products’ processes and workshop capabilities and in response by providing feasible and good production plans at different periods of time, when required. This requires two types of flexibilities: planning flexibility and scheduling flexibility. Traditionally, the planning functionality generates fixed process plans that often lead to unsatisfactory schedules with unbalanced resource utilization and superfluous bottlenecks provoking lower resource utilization and poor delivery performance [8]. Due to changes in the shop floor, these have to be frequently modified as defined in [9]. Research has found that nearly 30% of plans have required some modifications do this changes. Moreover, the use of fixed plans limits the scheduling functionality to a reduced solution space that does not correspond to that based on the flexibility found in both; process structure and workshop. Integrated process planning and scheduling (IPPS) [8,10] intends to bridge the gap between these two functionalities. By simultaneously considering the constraints of both planning and scheduling domains, more performing plans can be generated. The combination of both activities reduces as well solution efforts that otherwise will be overlapping. Integrating the process sequential flexibility in the problem’s formulation, the typical flexible job shop scheduling problem passes from a two dimensional problem (resource, time) to a tree dimensional problem (resource, time, operation). The objective of this paper is to present a computational process model capable of providing the process’s sequential solution space to the IPPS functionalities in a service-oriented holonic manufacturing system (SOHMS) where all process operations and resource capabilities are described by services. Thanks to the integration of services, the model’s fractal character allows the exploitation of the flexibility found in the holonic architecture provided also by its fractal character. Additionally a set of strategies is described as to dynamically create process plans in a large solution space while reducing the probability of the combinatorial explosion problem. This paper is presented as: Section 2 presents the modeling methodology to create service-oriented process plans. The section starts with a brief description of what is a manufacturing service and how a product can be constructed by a collection of these, followed by the definition of the Petri net model and concludes with the presentation and illustration of the modeling rules to automatically generate the Petri net model based on precedence constraints. Section 3 describes similar work on modeling approaches for planning and scheduling. Section 4 presents a study case illustrating the modeling process of a product and the generated solution space this generates in a workshop example. Finally, Section 5 proposes some integrated planning-scheduling strategies for the HMS to avoid the combinatorial complexity and orient exploration toward the ‘‘ideal’’ solutions. 2. Service-oriented process plans (SOPPs) Subject of great success, service-oriented architectures (SoA) are decentralized control architectures whose main characteristic is the decomposition of computational processes into subprocesses, called services, to later distribute them among available resources [2]. Its focus relies on the creation of reusable and interoperable function blocks (operations); thanks to the encapsulation of all implementation code through and opaque interface for representing processes, which are services [11].

Although intended for the informatics domain, the application of SoA in factory automation has been studied in [3,12,13], where Web Services technology has been proposed as a universal access interface to solve the problem of device interoperability. In holonic architectures, this is especially true as these can profit from the flexibility provided at a process level with the decomposition and encapsulation of processes that serves to: (i) represent resource capabilities with a collection of services, (ii) define process models as a collection of related services, (iii) create process plans based on service relations and (iv) define schedules with services. Thus, the service becomes the main element of negotiation and exchange among holons making an HMS a Service-oriented Holonic Manufacturing System (SOHMS). Work related to both holonic and service-oriented paradigms can be found in [3–6]. 2.1. A service-oriented process model (SOP model) In manufacturing, a process model prescribes how manufacturing operations are related to each other to create a process plans. Traditionally this operations were directly related to a type of resource, more specifically to the method used to implement a given operation. As mentioned before, in a service-oriented context, such operations are represented by manufacturing services which encapsulate their implementation methods and provide a single interface to all methods producing the same effects on a product or the environment. The service-oriented process planning and scheduling approach presented in this paper is based on the manufacturing service model presented in [14]. In the next sections a brief description of this model is presented followed by the definition of a service-oriented process model and a discussion of some advantages issued from its structure. 2.1.1. Manufacturing service model A manufacturing service (MService) is an operation that adds some value to a base product. This added value can come either as a transformation or an aggregation to the base product. All MServices within an application service-ontology or domain service-ontology are considered as non-interruptible operations that bring the base product in a storable and transportable state. According to [15], a service represents a single activity or a series of activities of a more or less intangible nature that normally takes place in the interactions between customer and provider, and is provided as a solution to achieve the customer’s desired end results. From a product perspective an MService is a black boxatomic operation provided by a resource whose execution will bring the product to a known desired state with no regard of the methods used. On the other hand, resources can be composed of other more granular resources as in a manufacturing cell. The composite resource being the cell controller, can request the MService of its composing resource to provide a higher level MService. Therefore, from a resource point of view an MService can be either provided as an atomic-MService or as a compositeMService depending on its internal structure. For instance, imagine the MService ‘‘Assemble Pin’’ to be offered by two different resources. Resource1 (modeled as an atomic resource) can execute the service in one single step with a pick & place subroutine to pick a pin from a stock and place it on the product. Resource2 (composed of two more granular resources: a ‘‘picker’’ and an ‘‘assembler’’) can provide the same service out of two more granular services: ‘‘Pick pin’’ and ‘‘Insert Pin’’. Due to hierarchical nature of manufacturing processes and holonic resources, the MService model must therefore possess a fractal character (Fig. 1). An MService is composed of one or more process methods, by a collection of process parameters and a collection of attributes. A process method represents an action or a structured group of actions that transform the product and/or the world as described

F. Gamboa Quintanilla et al. / Computers in Industry 76 (2016) 53–68

55

services which adapts to the holonic resource structure, (iii) it leverages reusability of services in different processes also through parametrization, (iv) It facilitates the integration of different resource technologies as resource capability is described by its service offer rather than its internal model. In the definition of SOP models it motivated the creation of an application service-ontology whose services are defined with a sufficient granularity to decompose the operations in the application. The effort of a good ontology definition will contribute in the clarity of SOP models, reusability of MServices and, as it will be explained in Section 5, will contribute in the planners’ agility to explore production plans. 2.2. Need of computational SOP model

Fig. 1. Manufacturing service model.

by the MService type. Three types were identified: product-process model, device-process model and a simple logic address. The first two belong to composite services while the last represents a program contained in the resource controller executing an atomic service. Each method has its own set of attributes used to evaluate its eligibility over other methods and resources. A process parameter embodies a piece of information needed by the process method in order to determine the limits of the process, namely a variable, port id (for service delivery), a material or sub-part. 2.1.2. Service-oriented process model The approach presented in this paper is aimed at productprocesses which are those composed by non-concurrent services, i.e. only one service can be executed at a time by one resource over the product. A product SOP model is then constructed based on the MService model (Fig. 2). It is formed by a collection of services and a collection of service dependencies which describe the relations between services defining the structure of the process. Dependencies are stated in a predecessor perspective with a table of precedence conditions stating the precedence relationships among services, moreover, in Section 2.4. This model was designed taking as reference the ISA SP 95 standard [16] by rearranging the information required for a full product’s production specification. 2.1.3. Discussion The presented service-oriented process model presents the following virtues: (i) it captures fractality of the product structure though the specification of subparts as service parameters, (ii) it captures fractality of processes through the definition composite

Fig. 2. Service-oriented process model.

The SOP model presented above defines the informational elements that are needed to completely specify a product’s process. In order to construct service-oriented process plans (SOP plans) there is a need for a computational model that is exploitable by the planning and scheduling functionalities of the system. Such computerized model should: (i) contain all process information needed for the realization of a product variant, (ii) describe the general structure of a process variant, (iii) comprise all different manufacturing alternatives in one format, (iv) provide a degree of flexibility to be reconfigured in a scalable and modular way, (v) its format should possess the proper elements to represent all possible process branchings that can exist in the type of process, (vi) must have a user readable format, (vii) must be comprehensive by most process planners with a minimum of specialized knowledge and finally (viii) must be suitable for on-line computation and fast enough to provide valid solutions in realtime conditions in order to attain reactivity. In summary, the control system needs of a computerized model that can represent all possible production sequences realizing different product variants in a single and easy to read format that process planners can easily manipulate and design and at the same time allow a fast exploration by the planning functionalities. Added to this, the SOP model should also be independent of any shop floor. The idea is to define SOP models according to a specific application service-ontology (AppSO) and use the control system to identify and explore shop-floor capabilities for generating SOP plans dynamically. The only requirement for a SOP model to be deployable in a system is that both, model and system, ‘‘speak’’ the same service-ontology. 2.3. Petri net representation of SOP models 2.3.1. SOP model overview The computational SOP model is a Petri net as seen in Fig. 3. This Petri net is designed to express in a compact format all precedence relations that characterize a product’s manufacturing process. Its places representing permission places enable transitions indicating at a which service can be executed according to the present product lifecycle state, expressed by the net’s marking. Thanks to an extension of the core Petri net formalism [17], inhibitor arcs avoid the model to arrive into deadlock states thus all sequence of service executions generated by the net satisfy the operative constraints. As seen in Fig. 3, the definition of the Petri net SOP model starts with a product structure or a product family structure. The product family, being a collection of interrelated features, can be mapped into a collection of interrelated manufacturing services. This is based on the belief that commonality in the product structure usually translates in commonality in operations [18,19] giving rise to a process family. Such mapping can be made based on manufacturing knowledge bases as those used by CAPP systems

56

F. Gamboa Quintanilla et al. / Computers in Industry 76 (2016) 53–68

Fig. 3. Petri net service-oriented process model.

[20,21] where each feature is associated to a generic Petri net that can be put together to form a global Petri net. In this approach, however it suffices to generate a list of MService instances with precedence conditions generated out of the product’s geometrical relations. To this table, other non-geometrical constraints are inputted to the precedence table which require of human intuition and expertise. Based in this precedence table and some modeling rules, see Section 2.5, the Petri net SOP model is generated. With this, the planning engine will be able to create areachability graph representing all the sequential solution space formed by the set of all feasible sequences generated by the process’s Petri net model. A feasible sequence is a sequence whose order of service instances respects the sequencing constraints specified by the process structure. These, however, only consider the process nature and have no relation to the shop floor. The task of identifying, allocating and scheduling feasible sequences to create process plans is left to the holonic control system, refer to Section 5.





2.3.2. The formalism The Petri net model is described by the 5-tuple: PN0 = (P, T, A, W, Inh, Read, FI, M0) where:



 P = {p1, p2, . . ., pn} is a finite set of places. There are three types: Permission places, Local exclusion places, and Mutual exclusion



places. Permission places collect the execution all service execution of a minterm (logical AND) in a service’s precedence condition. They are the main enablers of execution. Local execution places are used to register the execution of a service whenever. There are only used for services with a maxterm (logical OR) or a negated element in their precedence condition. Mutual exclusion places are used to limit the execution that are in some situations mutually exclusive. Their function is to avoid deadlock situations, which will be presented in details in the next section. T = {t1, t2, . . ., tm} is a finite set of transitions. Each transition, except for Start and Finish, is associated to a service instance: S = {s1, s2, . . ., sn} ! T = {t1, t2, . . ., tn}, S being the set of service instances forming the process model. A  (P  T) [ (T  P) represents the finite set of arcs from places to transitions and the set of arcs from transitions to places. These capture all precedence relations declared in the precedence table. W:A ! {k} is the arcs weight function with k being the arc’s weight. In an arc (P  T) the weight equals to the number of elements captured by the input permission place, i.e. the number of elements in the minterm condition. M0 is the net’s initial marking. This corresponds to P(Init), all LE(), and all ME() initialized with a token will the rest empty.

F. Gamboa Quintanilla et al. / Computers in Industry 76 (2016) 53–68

 Inh:(P  T)  W ! (N\{0}) [ {+1}) is the inhibition function. Inhibitor arcs, also called zero-test arcs, serve to limit the execution of certain service that could bring the Petri net to a blocking state. They test if a place in the net has no tokens.  Read:(P  T)  W ! N is the lecture function. Lecture arcs are used to test the presence of tokens in a certain place. This is used to reduce the amount of places in the Petri net and make it simpler to read. In this extended Petri net, a transition t is enabled iff Inh(*,t)  (M  Pre(*,t) + Read(*,t). Therefore, the transition state function f:Nn  T!Nn rests the same as for the core Petri net formalism: M0 = M  Pre(*,t) + Post(t,*) that is 8p 2 P M(p)0 = M(p)  Pre(p,t) + Post(t, p) where Pre(*,t) = (P  T)  W ! N N is the precondition relation and Post(t,*) =(T  P)  W ! N is the post condition relation. It is important to note that places do not represent process states as it is usually the tendency in Petri net modeling. A production state is represented by the net’s marking M = [M(p1), M(p2), . . ., M(pn)] indicating the values of the permission and execution places that determine what services have been executed. All transition are in structural parallelism except for those linked to a LE() place or a ME() place which are in structural conflict. All transitions being in an effective parallelism are permutable. A marking M is considered a decision state iff (t1, t2 T), t1 6¼ t2 for which Pre(*,t1)  M Post(*,t2). This means a marking represents a decision state if it enables more than one service transition for which the orchestration engine should make a choice on which to put next in the sequence. The Petri net formalism was selected as the best candidate for constructing computational SOP models and providing the logic dynamics. Petri nets are well known in academics and industry making it a comprehensible to the average process planner. Its strong mathematical foundation, abundant powerful analysis techniques and ability to capture synchronous and asynchronous relations between transitions in a compact format highlight its eligibility. Thanks to its constructs and to its lightweight evolution mechanism a single Petri net has the capacity to model all types of complex dependencies and generate a great number of sequence combinations with a minimal footprint which is also suitable for embedded applications, as in mobile products. Other high-level Petri nets formalisms like colored Petri nets (CPN) are currently subject of great research. However, we consider that the core Petri net formalism with the inhibitor and lecture arcs extension [22] is a sufficient solution for modeling product-level processes. This is justified by the following reasons: (i) the method is conceived under the hypothesis of only having deterministic service effects, i.e. a service execution always reproduce the described effects on the world. This discards the need of the main attribute of CPN’s which is conditional branching. (ii) Core PN express process branches in a more graphical way than CPNs which makes them simpler to read and understand. (iii) CPNs contain more elements in their definition making it have a bigger footprint. (iv) There is a bigger catalog of analysis tools for Core PN than CPNs. (v) The addition of the arcs extension is sufficient to create simple and easy to understand models capable to represent all possible process branches in a flexible job shop type process. 2.3.3. Discussion The Petri net SOP model presented here is an acyclic Petri net where the blocking state represents the conclusion of the products production process. None of its services are live transitions and all are quasi-live transitions. This means that all services are executed at least and at most one time during a product lifecycle. Permission places are bounded to the number of elements if the minterm condition they represent. As mentioned in Section 2.3.1, the model

57

is capable to generate all the sequential solution space of the process. However, the number of production sequences increments very fast with the number of services in a products process and is generally prohibitive for products or sub-assemblies having more than a dozen components [23]. It is a difficult problem to discuss theoretically as the number of solutions depends not only on the number of services in the process but also on the number and type of precedence relations. Moreover, the size of the sequential solution space also depends on the level with which the application service ontology is defined. Clustering of manufacturing operations during service definition can reduce the combinatorial complexity but might come with the cost of some flexibility. Service-ontology designers must identify the just level of granularity for their application. In the development of the SOP model, other modeling formalisms were analyzed. The Process Specification Language (PSL) [24] developed at the National Institute of Specification Technology (NIST) is a proposition of a formal ontology providing a formal description of the components and relations that form a process. Its main purpose is to axiomatize a set of intuitive semantic primitives that is adequate for describing the fundamental concepts of manufacturing processes with a set of logic terms for the description of a processes as well as a vocabulary for classes and relations. However, it uses a successor perspective for the definition of precedence relations which we find inconvenient for exploring flexibility. It is much easier and less exhausting to think of what are the preconditions in terms of predecessors for a service to be executable. Moreover, it demands high theoretical knowledge which makes it complicated to understand and implement within the web services technology, the Web services Description Language (WSDL), is an XML based language dedicated to the abstract description of a service’s interface for its proper invocation. Such interface descriptions contain information about a specific task. However, it does not specify the relations (sequential nor temporal) that can exist with other services in order to form more complex processes. The Business Process Execution Language (WS-BPEL), also an XML based language, is used to describe the different workflows that can be composed by expressing the interaction patterns of the collection of web services found in a process. Unfortunately, as stated in [5], most of the offer of orchestration engines using these languages and methods are not suitable for describing processes in industrial applications. This is due to the verbosity of the XML-based description languages and also to the fact that these are mainly intended for enterprise-level applications exhibiting footprints in the order of 10 MB. This is undesirable in systems with intelligent mobile entities, such as intelligent products or active products (according to the analysis framework of [25]), where the service coordination and orchestration engines must run on embedded systems which usually count with limited resources. 2.4. Defining SOP models based on process knowledge There are two approaches to define process information and generate the computable Petri net SOP model, namely, the serviceoriented approach and the feature-oriented approach (Fig. 4). Both approaches start with the definition of a product family structure containing information of the feature included in all the variants of the family. Next, based on manufacturing knowledge bases such as in Generative Process Planning, features can be mapped into a list of manufacturing services. This is done based on the belief that commonality in the product structure usually translates in commonality in the operations [18,19]. The collection of MServices realizing the product’s family features can be seen therefore, as a process family. The result of such mapping can be either a list of all MServices in the process family or a list of Petri net models related

F. Gamboa Quintanilla et al. / Computers in Industry 76 (2016) 53–68

58

Then other, non-geometric constraints can be added to the precedence conditions which are more complex to model in knowledge bases thus needing of human expertise. In general there are 5 types of operative constraints inspired on [23]:  Geometric constraints. Depend on the product structure. They account for all relations between features such as parent–child relations and neighborhood.  Accessibility constraints. Account for all possible blocking situations due to limiting features, interfering features, coalition fee trajectories based on material such as fixtures, handlers, etc.  Stability constraints. Each sub assembly must be stable, i.e. the product state will not change without the execution of another service.  Manufacturing constraints. These account for any other precedence constraints related to manufacturing procedures not necessarily associated to assembly operations.

Fig. 4. SOP models design process.

to each feature. Such individual feature Petri nets could also be generated with the service-oriented approach. In the service-oriented approach, the issued set of MServices is arranged in a precedence table as shown in Table 1. This precedence table captures all the structure of the process by associating to each service instance a set of service instances that most precede its execution. Such precedence conditions are written using Boolean algebra operators (AND, OR and NOT) with a predecessor perspective. Other modeling process specification formalisms such as PSL use the successor perspective. We find this inconvenient for the generation of a flexible model as process designers have to make intuitively define all the possible successors for each production state which results difficult and exhausting, especially when the number of possibilities is large. It results much easier and less exhausting to think of what are the preconditions in terms of predecessors for a service in order to be executable. With a predecessor perspective it is up to the orchestration engine to compute all the successor possibilities rather than leaving this task to the process designer. In a first instance, the precedence can be presented with some precedence relations accounting just on geometric constraints.

Then, to distinguish product variants a set of modular choices can be added. These can be optional choices or facultative choices. Optional choices indicate feature alternatives in the product family which substitute each other, e.g. in a car toy, a convertible roof is mutual exclusive with a fixed roof. The facultative choices indicate what are the optional features (services), e.g. two laptop versions are differentiated by the inclusion of a webcam. Finally, using some modeling rules which are presented in the next section, the Petri net SOP model is generated. The feature-oriented design approach rather than issuing a list of MService instance from the mapping from feature to process, it issues a Petri net SOP model for each of feature in the structure previously designed. As in the service-approach, geometrical relations are analyzed and a set of precedence condition among feature is generated which is then completed by human expertise to include the other non-geometric operative constraints. After this is done, synthesis techniques [26] can be used to build the general Petri net model of the product. This last step can be easily done with 1-way place merges. As seen in the precedence table, mutual exclusive constraints can also be added to the model. These are applied among all the alternative processes that can produce on same feature. The mutual exclusive constraint is added to the first service of all alternatives. Normally, a good SOP modeling practice will not need of the definition of alternatives as MServices model product state transformation with no regard on the methods leaving this to resources. However, it might become also practical in constructing mixed application service-ontology SOP models, i.e. both alternatives modeled with different ontologies.

Table 1 Precedence table. Service id Service Service Service Service ...

1 2 3 4

Precedence condition – Condition 1 Condition 2 Condition 3 . . ..

Mutual exclusion constraints (Service n)  (Service m) Modular choices (Service i)  (Service j) Service w

Alternative processes in a feature’s Petri net.

F. Gamboa Quintanilla et al. / Computers in Industry 76 (2016) 53–68

2.5. Generating Petri net based SOP models The transformation of a product’s SOP into a Petri net model requires, first, of the identification of all possible process branches existing in a job-shop type process, i.e. all precedence relations allowing process branching, and second, of the definition of a set of modeling rules capable of transforming such precedence relations into structures in the product’s Petri net. 2.5.1. Precedence relations With the adoption of the predecessor perspective the precedence relations found in a manufacturing process where categorized in eight types: 1. Single precedence: a service A is executable when a service B has been completed. 2. Compound AND precedence: a service A is executable when a service B and a service C have been completed. 3. Compound OR precedence: a service A is executable when either a service B or a service C has been completed. 4. Shared single precedence: a single precedence that appears in the precedence condition of other services in the precedence table. 5. Shared compound AND precedence: a compound AND precedence that appears in the precedence condition of other services in the precedence table. 6. Shared compound OR precedence: a compound OR precedence that appears in the precedence condition of other services in the precedence table. All precedence conditions must be written in its minterm canonical form, i.e. as a sum of products. Single and compound AND precedencies represent minterms while compound OR precedencies represent maxterms. This point allows a better understanding of the last two precedence relations: 7. Exclusion precedence: has the form of any precedence condition presented above but includes an exclusion constraint with respect to its predecessors. A service is executable only if one or more services have not been executed before. 8. Mutual exclusion precedence: when two services exclude each other in their precedence condition. These precedence relations represent the operative constraints based on manufacturing knowledge about the process; however other types of constraints are considered in order to include customization at a modular level. Two types of modular choices can be added: optional choices and facultative choices (Table 1). An optional choice is a mutual exclusive choice where several production services are available leaving the choice for one. A facultative choice is a service that can be included or not. Both of these go in the precedence table as modular constraints. 2.5.2. Modeling rules After an exhaustive analysis a set of modeling rules were issued in order to model through the chosen Petri net formalism the different types of precedence relations in a compact and easy to understand PN model. The following rules will serve to construct such Petri net model parting from a specified precedence table as described in Section 2.4. Rule No. 1. Precedence conditions should always be expressed in its minterm canonical form as a sum of products. Example. A condition such as S2 (S1jS3) should be expressed in the precedence table in its minterm canonical form as (S1 * S2)j(S2 * S3). Rule No. 2. For each service entre´e in the precedence table a transition is created.

59

Corollary 2.1. For every service with a precedence condition as a sum of minterms, each minterm should be modeled separately as another entree in the precedence table with the same service label. The generated service label duplicates are called cloned services. Corollary 2.2. For all transitions with the label of a cloned service, a single local execution place is created and linked as input place with single weighted arc. Corollary 2.3. Each entre´e of a cloned service in the precedence table is modeled with the same rules applied to minterm conditions, exclusion conditions and mutual exclusion conditions. Fig. 5 illustrates Rule 2 and its corollaries. In the precedence table service S4 is splited into two entrees of S4, one for each minterm of its condition and a new precedence table is formed. After splitting, all service entrees create a transition labeled with the service name. As service S4 is a cloned service a local exclusion place is added to limit it to one execution. Rule No. 3. For every occurrence of a service in a single precedence, a permission place is created to serve as permission for each successor. Corollary 3.1. Permission places are linked as inputs for the dependent service instance. Taking again example 1 in Fig. 5, service S1 appears as a single precedence to service S3 to P(S1) is created. In the same manner, the null predecessor appears as a single precedence to services S1 and S2 so P(Init)1 and P(Init)2 are created. Rule No. 4. For every occurrence of a minterm in the precedence condition’s column a permission place is created labeled as the minterm. Corollary 4.1. Permission places are linked as inputs for the dependent service instance. Corollary 4.2. For every permission place created, the output arcs (P  T) linking to successor services have a weight equal to the number of elements included in the minterm. This rule applies for the precedence conditions of both occurrences of the cloned service S4. Permission places P(S1 * S2) and P(S2 * S3) are created for the minterm conditions and are linked as input places to their corresponding transition, both labeled with S4. As each of this minterms contain 2 elements, the arc connecting the permission places to their transition has a weight of two in order to extract all token and avoid repeated execution. Rule No. 5. All precedence condition’s in maxterm form as a sum of single elements, e.g. (S1jS2jS3) not (S1 * S2)j(S3), and n occurrences in the precedence condition column, only one permission place is created.

Corollary 5.1. The permission place is linked as input to all successor services with single weight lecture arcs. Corollary 5.2. For all services having a maxterm as an input place, a local execution place is created and linked as input. As seen in example 2, Fig. 6, services S3 and S5 have maxterm conditions, both sharing the same condition. Thus, only one permission place P(S1jS2) is created and is linked to both S3 and S5 with lecture arcs. Additionally, to limit rehabilitation of the service once executed, local execution places LE(S3) and LE(S5) are created. Rule No. 6. Every minterm condition containing negation elements should be separated into a negated minterm and a non-negated minterm.

60

F. Gamboa Quintanilla et al. / Computers in Industry 76 (2016) 53–68

Fig. 6. Illustrative example 2.

(S2) links LE(S4) to S2 with an inhibitor arc. This will limit the ¯ execution of S2, and will be enabled only once S4 has been executed. Rule No. 8. For two services being in a mutual exclusion condition, one mutual exclusion place is created and is linked by single weighted arcs as input to the transitions associated to the minterms containing such mutual exclusive condition.

Fig. 5. Illustrative example 1.

Rule No. 7. Negated minterm conditions do not create new permission places. Instead, a local execution place is created for the successor service if there’s not already one created. Corollary 7.1. The local execution place of the dependent service is linked with inhibitor arcs to all the transitions labeled with services appearing in the negated minterm. Note: not for mutual exclusive services (see Rule No. 8). Rules 6 and 7 seen in example 2 for service S4. The minterm (S1 S2) is separated modeling S1 as a single precedence. As ¯ S4 already has a local execution place associated, the negated part,

Example 3 illustrates a mutual exclusive situation between services S3 and one of the clones of S4. So there is a mutual exclusion place created and linked to S3 and to the clone instance of S4 excluding S3. Note that the mutual exclusive situation is just considered with this clone of S4, however, S3 is also modeled with an exclusion relation with the other clone of S3 (see Rule Nos. 6 and 7) (Fig. 7). Rule No. 9. All services not appearing in the precedence column create a single permission place. Corollary 9.1. A dummy ‘‘Finish’’ transition is created indicating, when enabled, the conclusion of the product’s production process. All permission places created in Rule 9 are lined to this transition. As it can be seen from the previous example, there is no service depending on the execution of neither S3 nor S4 thus permission places are created for each and are linked to a dummy transition labeled as ‘‘Finished’’ that will be enabled when the process has concluded.

F. Gamboa Quintanilla et al. / Computers in Industry 76 (2016) 53–68

61

the number of nodes in the state graph. Lecture arcs also help in this matter creating only one place per maxterm. 3. Integrated planning–scheduling approaches In the previous sections, the proposed modeling methodology has been extensively described with a detailed definition on the parts of a SOP model and a set of rules to construct a Petri net capturing the process’ precedence constraints. This section describes some non-integrated scheduling approaches followed by a description of some scheduling strategies in holonic applications. Finally, it describes other modeling approaches for creating flexible process plans in the area of IPPS. 3.1. Scheduling approaches

Fig. 7. Illustrative example 3.

2.5.3. Discussion These set of rules presented above, can be used in an algorithm to automatically generate product’s Petri net model based on a declared precedence table containing all operative constraints of the process. The flexibility added to the process model depends on the way process designers specify such precedence constraints. Some effort should be done not to over constraint a process by including neither unnecessary nor unrealistic constraints. However, with the present Petri net model, some error detection can be made to detect over constrained processes. For instance, it was mentioned that all service instances in the precedence table must have at least and at most one occurrence in the process, i.e. all transitions are quasi-live and not live. Thus, all services must satisfy this condition in the Petri net’s generated state space graph otherwise the precedence table is over constrained to a point where there is no solution to the sequencing problem. In the Petri net model, as long as the precedence table presents a feasible set of precedence relations, i.e. there exists a feasible process sequence satisfying all constraints, the generated model will issue such sequences. This was proved empirically and the reader is encouraged to discover this by testing the set of modeling rules for any precedence condition written in its minterm canonical form. An important property of the presented Petri net model is its deadlock free characteristic. Indeed, thanks to the use of inhibitor arcs to model exclusion precedencies, all simulation steps of the Petri net is a feasible step. This is a valued characteristic that can be exploited by reactive process planning and scheduling as all complying service are available in one computation step according to the present lifecycle state. Finally, this model was designed to reduce the size of its incidence matrix. The use of dummy transitions is avoided in the model as these create additional places which in turn increase

Flexibility can be added to the system with scheduling strategies which depending on the flexibility provided by the control structure, can add reactivity to the system while aiming for optimization through re-scheduling. Much work has been made to solve the job-shop problem and the flexible job-shop problem with many different optimization methods as in [14] where a hierarchical algorithm based on tabu search metaheuristics is proposed. The problem is that most of these are predictive and lack of flexibility as they are based on assumptions made on the system’s state. These fail to account for model uncertainties and are sensitive to perturbations. Other scheduling methods such as dispatching rules [15] provide a more reactive approach where the scheduling problem is modeled as a set of decisions taken dynamically to create a valid schedule. Approaches like this succeed in trying to account the real state of the system but, as in heterarchical architectures, they do not guarantee the quality of the schedule. To solve these problems in classical control there has been initiatives proposing solutions that combine principles of both predictive and reactive schedules. For instance, group scheduling methods which aim to have sequential flexibility during schedule execution and guarantee a minimal quality according to a worst case scenario. A comparative study of the performance of such method in regards to transportation times in an industrial flexible manufacturing system can be found in [16]. On holonic architectures, extensive work has also been made to define scheduling strategies that could benefit of a more flexible control environment. For instance, [27] proposes an adaptation of the contract net protocol that can handle the temporal constraints and deal with scheduling conflicts to assign dynamically operations to resources. A contract net protocol is also proposed in [28] with a cooperative problem-solving paradigm based on bidding and negotiation mechanisms. Scheduling strategies inspired in biological organizations such as in ant colonies are proposed in [29,30]. Their strategy suggests the exploration of production alternatives in a short term forecast based on stigmergy as an indirect communication method that collects information on system’s future state. In the same matter, [31] came up with an online discrete-event simulation tool in order to increase the vision spectrum of holons. The application of a holonic behavior is encouraged in [32] which at first takes the advantage of predictive methods to create an optimal schedule and then switch to a reactive behavior whenever a perturbation occurs. Similarly, [33] presents an approach for dynamically re-schedule operations in an HMS which shifts between fast reactive re-scheduling and global approaches to maintain optimization. In [34] a flexible assembly cell control system is proposed. It proposes the creation of device drivers as a means to easily program robot applications based on a library non-interruptible operation performed by robot routines. External to the holonic structure, a periodic online reactive

62

F. Gamboa Quintanilla et al. / Computers in Industry 76 (2016) 53–68

scheduler provides schedules based on a dynamic precedence graph with process and capacity constraints. Benchmark tests where made compares results in different scenarios for hierarchical, hierarchical and the holonic approach. 3.2. Modeling approaches for integrated planning-scheduling The most resembling approach in the IPPPS area is the CAPP systems (Computer Automated Process Planning) which concentrate in the automatic generation of non-linear process plans (NLPP). These take product information on features and feature relations to create process models representing manufacturing alternatives. Modeling tools used by these modeling approaches include AND/OR graphs and Petri nets. The FLEXPLAN [20] project is one example of NLPP approach. In this approach a CAPP system to automatically generate NLPP is implemented using 3 manufacturing knowledge bases for compound features, identical manufacturing directions and different manufacturing directions. In the process, two representations are created; first a generic Petri net model is constructed as a generic model containing all geometric relations among feature that can be edited to add non-geometric constraints requiring human expertise to the model; second an AND/OR graph is created relating operations to resources. In order to reduce combinatorial explosion, it uses a hierarchical method to create groups of features, thus operations. This model generation approach however presents some drawbacks, for instance the simulation of Petri net model used to generate the AND/OR graph does not guarantee that the next step leads to a feasible solution. Iterative simulation has to be made to identify valid sequences of operations which contribute to the combinatorial explosion problem. Another inconvenient is the loss of some flexibility in it NLPP graph. Constraining consecutive operations to a resource might not correspond to the availability state of the shop-floor. The COMPLAN project [21], also part of the European ESPRIT project, tries to apply the principles of FLEXPLAN on generative process planning, to small batch production of complex products in a typical job shop environment. It main contribution is in the definition of methods to improve the response time of the CAPP system that generates the NLPPS which have greatly motivate the strategies presented in this study. A computer aided assembly process planning approach presented in [35]. This represents process structure with assembly trees. This precedence graph is created with binary relation between two operations. This binary relation forces the creation of various precedence graphs for a single product. A hypergraph has then to be created combining both graphs with a different binary relation between an operation the execution of at least a list of other operations. Other contributions of this work are also aimed to the reduction of the combinatorial complexity with the inclusion of strategic constraints such as imposed sub-assemblies, grouping of operations and leveraging linear assembly trees. A common critic made on this approach from the IPPS point of view is that these automated process planning systems usually look upstream making static and offline integration with the CAD function and generally overlook the potential downstream integration of the scheduling function [8]. This integration is usually weak with the definition of dispatching rules and comes in a second step after defining NLPP graphs. Unfortunately, they pay little attention on the effect that changing condition may have on the performance of the defined process plans.

blocks, namely, a small 2  2 block, a medium 2  4 block and a large 2  6 block. Each block is available in four colors {red, green, yellow and blue} and can be assembled in any position with in a product base as long as there is an available 2  2 Lego1 interface in its inferior level. As an example, the Lego1 structure results to be ideal to illustrate precedence dependencies among the components of a product and thus of a manufacturing process. For illustrative purposes, the Lego1 blocks are used to represent MService instances required to form the product’s production process. We used the pair block type-layer to represent an MService type. This makes a service-ontology of 4  3 = 2 MService types, Fig. 8, that is A1, B1, C1, A2, B2, C2, A3, etc. We remind to the reader that we use the combination of block type-layer to represent operation types to form a service-ontology which will be used to form a process structure. The Lego1 structure is used as a visual reference to the precedence dependencies. Thus block A in the first layer represents the MService type A1, block B in the second layer represents MService type B2, and so on. MService parameters account for color, position in the x and y coordinates and orientation for all MServices represented by B and C blocks. The product family in Fig. 3 can also be customized in a modular way with the specification of the modular choices. The modular choice (A4.1 * A5)  (A4.2 * A4.3) indicate that the designer, which can be a costumer, has to make a choice to either include the features reproduced by services A4.1 and A5 or those reproduced by services A4.2 and A4.3. Each choice represents a product variant in the product family. To create the SOP model for this product the first step is to define its precedence table. As described in Section 2.4, a preliminary precedence table can be generated based on manufacturing knowledge bases and the relations among features in the product structure. This first step generates a list of MService instances associated to precedence conditions considering only geometric constraints in the product structure. The second step consists in enriching this table with other operative constraints that require of human expertise such as accessibility constraints. In this example, two accessibility constraints are considered. From the product structure a geometric constraint can be seen in Fig. 9. It can be easily seen that once service C3 is executed service A1.5 cannot be executed anymore as its representing block covers its assembly trajectory. So A1.5 must be executed before 3C. We took this problem further and added an accessibility constraint for services B2.2 and B2.1. It is supposed that due to the form and size of the handler placing block A1.5 this can no longer be accessible after executing both services B2.2 and B2.1, as seen in Fig. 11. However, it is accessible if only one of both services has been executed. Thus, this can be modeled with a mutual exclusive precedence constraint between both services

4. SOP modeling example Taking Fig. 3 as a modeling example, the product is a structure of Lego1 blocks formed of maximum four layers and three types of

Fig. 8. Sample application service-ontology.

F. Gamboa Quintanilla et al. / Computers in Industry 76 (2016) 53–68

63

Fig. 9. Valid sequence considering geometric constraints.

according to A1.5. The reader might think of other ways to represent this relation in the precedence table for example constraining A1.5 instead of B2.2 and B2.1. This is actually valid and allowed by the modeling rules. Any precedence constraint declared in the precedence table declared as a sum of minterms with or without negated elements can be represented by the generated Petri net. It is up to the process designer to declare valid and sound conditions representing properly real process constraints, more on this later (Fig. 10). The third step consists in indicating the modular choices and generating the Petri net modeled with all the services included for the product variant. Fig. 3 presents the Petri net model issued for variant 2 of the product family. The generated Petri net treats every precedence condition in the table including all complex conditions. Fig. 11 illustrates the evolution scenario of the accessibility constraint just mentioned making B2.2 and B2.1 mutual exclusive. In stage 1, services A1.1 to A1.4 have been successfully executed but not service A1.5. This situation this situation enables one clone of service B2.1 and one clone of service B2.2 as the ME(B2.1 * B2.2) still contains a token. Then, assuming the execution of B2.2, the tokens in ME(B2.1 * B2.2) and LE(B2.2) will be consumed thus disabling B2.1 and the other clone of B2.2, stage 2. The only way to enable a transition and allow the net’s evolution is to execute A1.5 that will provide the missing token to the second clone of B2.1, stage 3. Finally, B2.1 is executed and all clones of 2B.1 and 2B.2 are disabled. The Petri net model was constructed using the modeling Tool Rome´o [36,37], developed at IRCCyN-CNRS laboratory. With its inhibitor and lecture arcs extension the Petri net can be simulated and a state space graph can be generated. Process planning functionalities can explore the process’s sequential flexibility inside the sequential solution space generated. With a depth-first algorithm, the number of possible sequences hidden in this Petri net can be calculated. For version 1, the sequential solution space sumps up to 480 feasible sequences.

Fig. 10. Forbidden sequence.

Fig. 11. Accessibility constraint in the Petri net model.

The sequential solution space is independent of any work shop and can be used to explore planning flexibility in order to answer to the question ‘‘What is the best production sequence for a product given the workshop’s current state? This implies the need to explore the workshop production flexibility. Considering the example presented in [31], the workshop of study is an HMS located at the AIP PRIMECA Pays de Loire, University Institute of Technology (IUT) of Nantes, France (Fig. 12). It is an automated assembly line widely inspired from an actual line of FILTRAUTO/SOGEFI, world leader of the production of oil filters. It is broadly composed of a conveyor system and six workstations, each of them being represented by an individual Resource Holon (RH). Product goods are transported through the conveyor line by 42 intelligent pallets with the capabilities of a level-2 intelligent product, issue of the work in [38]. Each pallet is equipped with the necessary tools to communicate, take decisions about its own future and even to act on those decisions by activating actuators that will direct its way through the conveyors’ disjunctions. The pallets are responsible for the product’s production lifecycle. It is then within the intelligent product that the orchestration functionality of SOP plans relies. Table 2 shows the services that each workstation can provide. For instance, workstation 1 can provide small and medium blocks of colors red and green. Workshop capacities where designed with

F. Gamboa Quintanilla et al. / Computers in Industry 76 (2016) 53–68

64

may not yield a production plan with the shortest path possible with in the given workshop. Let’s say sequence {1A.1-1A.2-1A.31A.4-1A.5-2B.1-2B.2-3C-4A.1-5A} may look as a good solution from a perspective considering only the process logic. But in some workshops, as in this one here presented, it is not the sequence that best adapts to the workshop’s distribution of capabilities thus missing a potentially better solution space. The first scenario sure generates a greater solution space but it is without doubt too big to explore. The constraint added to the second scenario considerably reduces the solution space to one 153 times smaller. However in systems dealing with new order arrivals on the run, the restricted solution space might skip a great deal of solutions that intersect with the workshop’s current availability. Section 5.3 will introduce some strategies for the orchestration of SOP plans to reduce such combinatorial complexity while exploring the solution space of the first scenario inspired on the results just presented.

Fig. 12. HMS production line. Table 2 Workstation MServices. Workstation

Block type

Block colors

1 2 3 4 5 6

A&B A&B B&C B&C A&C A&C

Red & Green Yellow & Blue Red & Green Yellow & Blue Red & Green Yellow & Blue

the objective of having redundancy in all services, i.e. all services are provided by two different workstations. Not all workstations are identical, some workstations count with a 6-axis robotic arm some others possess a Scara robot. Moreover, they can be of different vendors but provide the same services. The layout has a full reachability among all workstations. In this study case, the layout map declared in the transport system allows the passage of pallets inside the conveyor loops at workstations 2 and 3 to increase the number of alternative trajectories between resources. For instance there are two trajectories from workstation 1 to workstation 5. Two scenarios are considered to assess the effect of the modeling approach on the enlarged solution space that will contribute to planning–scheduling flexibility:  Scenario 1: it is considered full routing flexibility. If a product is planned to execute two consecutive services in the same workstation it can either stay to receive them both or reintegrate the transport system, make a tour and return to it later after, for instance, after one loop in the main conveyor.  Scenario 2: products with two consecutive services in the same workstation are constrained to stay in the workstation until completion of both services. Exploring the first scenario for the sequence {1A.1-1A.2-1A.31A.4-1A.5-2B.1-2B.2-3C-4A.1-5A} the solution space has 8,264,340 feasible plans according to the workshop’s transport system and MService distribution. Extending this calculation to all the 480 possible sequences the solution space extends up to 3,966,883,200 feasible plans. In the second scenario the solution space has 66,240 feasible plans extending up to 25,874,082 feasible plans. The interesting result of this calculation is that 104 out of 480 sequences have the shortest paths found for this layout and 100 sequences yielded the longest path; a sequence with best path: {1A.1-1A.2-1A.3-1A.4-1A.5-2B.2-2B.1-3C-4A.1-5A}, a sequence with worst path: {1A.1-1A.3-1A.5-1A.4-2B.2-1A.2-2B.1-3C-4A.15A}. If a process sequence was to be fixed for the production of this product, with no knowledge about the physical workshop or the capacities embedded within. One can easily define a sequence that

5. A strategy for integrated service-oriented process planningscheduling (ISOPP-S) The main use of the Petri net SOP model is to provide the set of possible service operations that can be executed given a status of the product’s lifecycle. The model is mainly directed to distributed control applications using the concept of services to describe process specification and resource capabilities. However, it is not restrictive to those not applying service orientations. Nonetheless, these will miss some of its advantages especially in terms of integration (models applicable in different service-oriented workshops) and combinatorial complexity (no service encapsulation to represent different methods with the same effects). An example is the wellknown Production 2000+ system [39], implemented at DaimlerChrysler plant in Stuttgart. This is a multi-agent controlsystem designed to flexibly adapt to the systems currents conditions by dynamically allocating tasks to resources using a first-price single round auction. This task allocation is currently made according to fixed operation sequences that have to be arranged according to the position of machines in a certain forced flow of materials. When a disturbance occurs, products might loop backwards to satisfy the initially states process sequence. The Petri net model can be used in this approach to explore other possibilities of operation sequence in this situation. There might be another sequence that from that point does not require looping back in the production line. The model will allow finding the sequence that best adapts to the configuration of the workshop with no previous knowledge. Other works in integrated process-planning such as [40,41] can also make use of the Petri net model. The former presents a local search procedure incorporated to a genetic algorithm considering precedence relations among operations that can be expressed by the model. The latter presents a holonic manufacturing system with a fuzzy logic inference system to select machines according to their reliability and capacity. The Petri net model can also be used here as a method to include other machines in the selection satisfying process precedence constraints. An important property to remember about the present modeling approach is that it provides a feasible solution to the sequential problem at every simulation step. However there are some control systems that do use the concept of services on which the model is not directly applicable. Examples of these are [42,43] belonging to the SOCRADES project (http://www.socrades.eu) which use service integration and Petri nets to define process orchestration models for process optimization thought the calculation of transition invariants. The Petri nets controllers presented are non-linear production plans associated to machines. Here the SOP model can be used as a previous step to define such Petri net.

F. Gamboa Quintanilla et al. / Computers in Industry 76 (2016) 53–68

5.1. The service-oriented holonic control architecture The SOP modeling approach is intended for a service-oriented holonic architecture based on the PROSA reference architecture [44]. This takes the same control elements as the product, resource and order holons and adapts their behavior in order to make service the main element of exchange in holonic interactions and oriented toward the orchestration of Integrated Service-Oriented Process Planning and Scheduling (ISOPP-S). Here is a general description of the holons behavior and of a directory facilitator:  Product holon (PH): as defined in PROSA, possesses the entire product’s process information. In ISOPP-S, it passes from a passive behavior of being just an information server on product information to a more active role. As it contains process information, it becomes the orchestrator of feasible process plans and schedules. It implements strategies to construct feasible scheduled process plans by exploring the process’s sequential solution space, resource capability and resource availability. It is also responsible of evaluating such solutions, intersecting the three solution spaces, based on a certain evaluation criteria that can be a weighted function of various parameters such as make span, plan reliability, quality of service, etc. See [45] for service evaluation criteria.  Resource holon (RH):Provider of manufacturing capability described by its MService offer with service profiles. Its methods are encapsulated by service descriptions. It responds to the service requests by PHs querying on the resource’s availability. It is the manager of its own utilization schedule and change of set-up plans. Its objectives are directed toward maximizing utilization and reduce set-up changes and project in their proposals to PH.  Order holon: Coordinates the execution of production plans sent by the associated PH. In normal behavior follows the PH plans as long as these are available. In case of the absence of a plan it turns to a reactive behavior continuing production based on a feasibility graph and/or the Petri net model also provided by the PH at its creation.  Directory facilitator (DF): works as an information server to provide static information on the system can reduce message traffic. It contains RH registrations with a description of their service offer. PHs can query the DF to identify capable resources to their needs. I maintain as well an updated map of the system’s layout that can be provided to PHs in order to explore the workshop’s reachability.

65

there are no queries on the actual availability of the workshop. This search is made based in depth-first manner to provide a feasible path as soon as possible in order to explore its availability in time. More on the strategies in the next section. 3. As soon as there is a feasible sequence available two types of explorer ants are sent to explore resource availability. One type of ant search the graph in a depth first manner in order to have a feasible process schedule as soon as possible (this aspect is important for an on-line and reactive behavior). The other type of explorer ant searches the feasibility graph (which is being constructed in parallel by feasibility ants) with an A* search algorithm with the intention to find better solutions. The heuristic search is based on the shortest processing time defined by the feasibility ants counting for transport time, service make span and setup times. This is considered a pertinent heuristic as the optimal solution is that in which all products make the shortest plan considering full resource availability. 4. Then at a pertinent moment (determined in function of the time to the next decision point) an intention ant selects the best explored schedule and reserves resource utilization. It projects its intentions in the RH schedules. In case a schedule is no longer available due to the time between exploration and reservation. The intention ant can use the exploration graph to reserve an alternative solution. 5. Finally the established intention is passed to a new OH in order to coordinate and monitor the correct execution of process plans. In this way the functionalities of planning and scheduling are combined in order to explore the solution spaces provided by both domains. Holon interactions are coordinated in an indirect manner due to the projection of the PH intentions in the resources utilization schedules. The concept of process orchestration comes from the principles of SoA and makes reference to the coordination of information exchange to form computational processes based on services. Coordination happens with a local point of view with a designed coordinator of the information exchange. In SOHMS it is the PH who drives the exchange of information with RHs to form such schedules. A choreography, on the other hand, does not have a designed coordinator. As synchronized dancers, participants in choreography coordinate by perceiving their neighbors behavior. Thus the relation PH–RHs can be seen as an orchestration with the PH as orchestrator and the relations PH–PH can be seen as choreography where coordination happens in an indirect way with the projection of their intentions in the resources schedules.

5.2. Orchestration of SOP plans in a nutshell

5.3. Strategies to reduce exploration complexity

Although the interaction protocols for the orchestration of process plans is not the main scope of this paper. An overview of the ideas behind this work in progress will be presented to give some perspective on how process orchestration takes place in an SOHMS. The orchestration process is based on FIPA’s Contract-Net Protocol (CN-P) and the short-term forecasting approach for scheduling of production and transport operations presented in [29,46,47]. The CN-P is used to coordinate the PH–RH interactions. The short-term forecasting approach is used to reduce the myopic behavior of distributed control systems. Here is a brief description of the steps to process orchestration:

As it was described in previous sections, combinatorial complexity is one of the main drawbacks of flexible process plans as the number of alternative solutions increases rapidlywith the size of the process. Added to this, many solutions provide performances far from the optimal or satisfactory performance. Common characteristics found in this kind of solutions are a great number of set-up changes, great number of jumps among resources increasing transport time, mixed trajectories causing transport congestion, among others. In this sections strategies are presented that will help reduce the combinatorial complexity of solutions as well as to guide the exploration process toward the ideally most performing solutions.

1. The PH based on the Petri net SOP model creates state space graph representing the sequential solution space. 2. The PH creates a feasibility ant which will start creating a feasibility graph based on the sequential solution space and the queries it makes on resource capability to the DF. Until this point

5.3.1. Dynamic batch grouping This strategy consists on creating dynamically batches of products of the same type. The idea is to take all products through one same path in order to reduce the need of resource set-up changes and reduce the amount of PH–RH negotiations.

66

F. Gamboa Quintanilla et al. / Computers in Industry 76 (2016) 53–68

composite request the number of exploration nods reduces to a factor of (n!  1). The strategy also leverages the exploration of production plans with shorter transport times; it tries to schedule the more services as possible in one same resource.

Fig. 13. Dynamic holonic batch (dissociation).

With a new order arrival of a product type, a PH is created and assigned as a batch leader. This will engage in the PH–RH negotiations and will try to find a joint plan for all products in the order. If at a given point in exploration resource respond with availability to treat only a part of the batch, the batch is split and anew leader PH is created for the second batch which will continue exploration from that point (Fig. 13). The process continues until all products have an intention schedule. In distributed systems with intelligent physical products this strategy can also tear out the advantage of increasing the number of parallel computation threads for exploration of the solution space as the processing capacities of the other products can be exploited. 5.3.2. Dynamic composite service requests During the exploration of a resource’s availability, PHs identifies if there is a set of subsequent services that the resource has the capability provide, based on the static information in the DF. If this is the case the service request is no longer made for the execution of one service but for the collection of services. For instance, in request No. 1, Fig. 14, holon P1 sends a request to R1 for services S1 to S5. R1 analyses its availability and responds with an alternative proposal for just treating S1 and S2, which adapts better to its goals. P1 receives the proposal and explores the subsequent steps requests S3 and S4 to R2. Service S5 is not included in the request as it is not included in R2’s capabilities. R2 responds with the requested proposal and the process continues. The idea behind this strategy is to reduce the number of exploration node by encapsulating process branching in a single request. For instance for a set of n independent services in a

Fig. 14. Composite service requests and alternative proposals.

5.3.3. Discussion Added to the contributions of both of this strategies (combined), exploration performance is increased with the heuristic search described in the previous section as it takes actual information from the exploration of feasible ants in a full availability scenario. Overall, these strategies will guide exploration of the production solution space toward an ideal solution containing less machine changes, shorter transport, more linear trajectories and fewer set-up changes. These strategies can be used as guidelines to reduce the combinatorial complexity and orient exploration toward an ideal solution. Other strategy in perspective is the use of opportunistic scheduling as proposed in [21] as a method to improve response time of a CAPP system to generate non-linear process plans. This approach consists in identifying, intuitively, a set of important operations and finding a schedule for them. Then, ‘‘non-important’’ operations are tried to be integrated into the schedule. If one does not fit it is included in the important set and the process repeats until finding a solution. In ISOPP-S the selection of such important could be those services that at certain point in the process graph are the only ones enabled. Such services can be seen as a bottleneck in the process evolution and can be classified as critical services. But this topic is out of this paper’s scope and is be subject of future work.

6. Conclusion and perspectives Service-oriented holonic manufacturing systems are e new type of holonic architecture that integrates the concept of service to describe processes specifications and resource capability. The decentralized architecture of this type of systems provides great potential flexibility to the different control functionalities such as for process planning and scheduling. However, the flexibility in this area is usually limited by fixed process plans that cannot adapt to changing conditions in the workshop. In this work, a service-oriented process model has been presented to compute the process sequential flexibility for the planning and scheduling functionalities in order to explore larger solutions spaces with potentially better solutions. One of the main advantages of this model is a fractal character that its services are capable of representing the fractal of holonic architectures. Composite services can encapsulate more granular services such as a holon can encapsulate and holarchy of holons. A set of modeling rules have been proposed to automatically generate a Petri net model that will serve as production recipe for product holons to compute and explore the sequential solution space. An important characteristic of the Petri net design is the lack of blocking states. The model provides a feasible solution at every simulation step. This property becomes a high value for describing complex product with large solutions spaces for with other methodologies would make simulation iterations to assure a feasible solution. Moreover, services function as interfaces allows the integration of all types of technology as they encapsulate process implementation inside a process description. Resource capabilities are offered to the system through manufacturing service types defined within the used application-specific ontology. This makes the SOP model independent from the workshop’s physical layout configuration which makes it implementable in any SOHMS.

F. Gamboa Quintanilla et al. / Computers in Industry 76 (2016) 53–68

Complex product applications as well as highly flexible workshop configurations can generate a combinatorial explosion of solution possibilities. To cope with this, an adapted ant-colony orchestration protocol is presented as well as a set of behavior strategies that will dynamically group products and services. These strategies together with heuristic formulae calculated online (based on the workshop static information such as processing, set-up and transport times) will orient the creation and exploration of a feasible solution space with no restrictions Future work will focus on the implementation of the here presented behavioral strategies to cope with the possible combinatorial explosion. Tests on highly flexible systems with high levels of combinatorial complexity will be made in order to analyze and study their performance and reactivity in feasibility in finding good feasible solutions. Work will also be directed toward the definition of time frames for orchestrating solutions to pass gradually from a fully reactive mode to a stable mode. With the objective to increase global performance, strategies will be studied to add a sense of volatility to future contracts according to their distance in the horizon.

References [1] G. Morel, B. Grabot, Editorial of special issue, Eng. Appl. Artif. Intell. 16 (2003) 271–275, http://dx.doi.org/10.1016/S0952-1976(03)00073-3. [2] N. Komoda, Service oriented architecture (SOA) in industrial systems, xxiii, in: IEEE Int. Conf. Ind. Inform, 2006, http://dx.doi.org/10.1109/INDIN. 2006.275681. [3] F. Jammes, H. Smit, J.L.M. Lastra, I.M. Delamer, Orchestration of serviceoriented manufacturing processes, in: 10th IEEE Conf. Emerg. Technol. Fact. Autom. 2005, ETFA’2005, 2005, p. 8, 624. [4] F.L. Bellifemine, G. Caire, D. Greenwood, Developing Multi-agent Systems with JADE, first ed., Wiley, Hoboken, NJ, 2007. [5] F. Jammes, H. Smit, Service-oriented paradigms in industrial automation, IEEE Trans. Ind. Inform. 1 (2005) 62–70. [6] C. Morariu, O. Morariu, T. Borangiu, Customer order management in service oriented holonic manufacturing, Comput. Ind. 64 (2013) 1061–1072, http:// dx.doi.org/10.1016/j.compind.2013.07.007. [7] N. Slack, Manufacturing systems flexibility – an assessment procedure, Comput. Integr. Manuf. Syst. 1 (1988) 25–31, http://dx.doi.org/10.1016/09515240(88)90007-9. [8] W. Tan, B. Khoshnevis, Integration of process planning and scheduling – a review, J. Intell. Manuf. 11 (2000) 51–63, http://dx.doi.org/10.1023/A: 1008952024606. [9] J. Detand, J.-P. Kruth, J. Kempenaers, A Computer Aided Process Planning System that Increases the Flexibility of Manufacturing, 1992, pp. 1–23 http:// lirias.kuleuven.be/handle/123456789/177355 (accessed 26.05.15). [10] R.K. Phanden, A. Jain, R. Verma, Integration of process planning and scheduling: a state-of-the-art review, Int. J. Comput. Integr. Manuf. 24 (2011) 517–534, http://dx.doi.org/10.1080/0951192X. 2011.562543. [11] A. Molina, C.A. Rodriguez, H. Ahuett, J.A. Corte´s, M. Ramı´rez, G. Jime´nez, et al., Next-generation manufacturing systems: key research issues in developing and integrating reconfigurable and intelligent machines, Int. J. Comput. Integr. Manuf. 18 (2005) 525–536, http://dx.doi.org/10.1080/09511920500069622. [12] K. Nagorny, A.W. Colombo, U. Schmidtmann, A service- and multi-agentoriented manufacturing automation architecture: an IEC 62264 level 2 compliant implementation, Comput. Ind. 63 (2012) 813–823, http:// dx.doi.org/10.1016/j.compind.2012.08.003. [13] G. Caˆndido, J. Barata, A.W. Colombo, F. Jammes, SOA in reconfigurable supply chains: a research roadmap, Eng. Appl. Artif. Intell. 22 (2009) 939–949. [14] F. Gamboa Quintanilla, O. Cardin, P. Castagna, A. L’Anton, Process specification framework in service oriented holonic manufacturing systems, Studies in Computational Intelligence, vol. 594, Springer, 2015, pp. 81–90. [15] C. Gro¨nroos, Service Management and Marketing: A Customer Relationship Management Approach, Wiley, 2000. [16] ISA-95, ISA-95.01, Models & Terminology, 2000 http://www.isa-95.com/ subpages/technology/isa-95/isa-95-01.php (accessed 13.05.14). [17] T. Murata, Petri nets: properties, analysis and applications, Proc. Inst. Electr. Electron. Eng. 77 (1989) 541–580, http://dx.doi.org/10.1109/5.24143. [18] M.T. Martinez, J. Favrel, P. Fhodous, Product family manufacturing plan generation and classification, Concurr. Eng. Res. Appl. (2000) 12–22. [19] K. Schierholt, Process configuration: combining the principles of product configuration and process planning, in: K. Mertins, O. Krause, B. Schallock (Eds.), Glob. Prod. Manag., Springer US, 1999, pp. 391–398, http://link.springer. com/chapter/10.1007/978-0-387-35569-6_48 (accessed 13.05.14). [20] J.P. Kruth, J. Detand, A CAPP system for nonlinear process plans, CIRP Ann. Manuf. Technol. 41 (1992) 489–492, http://dx.doi.org/10.1016/S00078506(07)61251-7.

67

[21] J.-P. Kruth, J. Detand, G. Van Zeir, J. Kempenaers, J. Pinte, Methods to improve the response time of a CAPP system that generates non-linear process plans, Adv. Eng. Softw. 25 (1996) 9–17, http://dx.doi.org/10.1016/09659978(95)00081-X. [22] O.H. Roux, D. Lime, Time Petri nets with inhibitor hyperarcs: formal semantics and state space computation, in: J. Cortadella, W. Reisig (Eds.), Appl. Theory Petri Nets, Springer, Berlin Heidelberg, 2004, pp. 371–390, http://link.springer. com/chapter/10.1007/978-3-540-27793-4_21 (accessed 22.05.15). [23] J.-M. Henrioud, A. Bourjault, LEGA: a computer-aided generator of assembly plans, in: L.S.H. de Mello, S. Lee (Eds.), Comput. -Aided Mech. Assem. Plan., Springer US, 1991, pp. 191–215, http://link.springer.com/chapter/10.1007/ 978-1-4615-4038-0_8 (accessed 17.05.15). [24] National Institute of Standards and Technology (NIST), Process Specification Language (PSL), 2008 http://www.mel.nist.gov/psl/ (accessed 02.05.14). [25] Y. Sallez, Proposition of an analysis framework to describe the ‘‘Activeness’’ of a product during its life cycle, in: T. Borangiu, D. Trentesaux, A. Thomas (Eds.), Serv. Orientat. Holonic Multi-Agent Manuf. Robot., Springer International Publishing, 2014, pp. 257–270, http://link.springer.com/chapter/10.1007/ 978-3-319-04735-5_17 (accessed 29.04.14). [26] M.D. Jeng, F. DiCesare, A review of synthesis techniques for Petri nets, in: Proc. Rensselaers Second Int. Conf. Comput. Integr. Manuf., 1990, 348–355, http:// dx.doi.org/10.1109/CIM.1990.128124. [27] P. Kanchanasevee, G. Biswas, K. Kawamura, S. Tamura, Contract-Net-Based Scheduling for Holonic Manufacturing Systems, 1997, 108–115, http:// dx.doi.org/10.1117/12.294424. [28] P. Sousa, C. Ramos, A distributed architecture and negotiation protocol for scheduling in manufacturing systems, Comput. Ind. 38 (1999) 103–113, http:// dx.doi.org/10.1016/S0166-3615(98)00112-2. [29] T. Holvoet, P. Valckenaers, Beliefs, desires and intentions through the environment, in: Proc. Fifth Int. Jt. Conf. Auton. Agents Multiagent Syst., New York, NY, USA, (2006), pp. 1052–1054, http://doi.acm.org/10.1145/1160633. 1160820 (accessed 14.09.14). [30] P. Verstraete, P. Valckenaers, H. Van Brussel, B. Saint Germain, K. Hadeli, J. Van Belle, Towards robust and efficient planning execution, Eng. Appl. Artif. Intell. 21 (2008) 304–314, http://dx.doi.org/10.1016/j.engappai.2007.09.002. [31] O. Cardin, P. Castagna, Using online simulation in holonic manufacturing systems, Eng. Appl. Artif. Intell. 22 (2009) 1025–1033. [32] C. Pach, T. Berger, T. Bonte, D. Trentesaux, ORCA-FMS: a dynamic architecture for the optimized and reactive control of flexible manufacturing scheduling, Comput. Ind. 65 (2014) 706–720, http://dx.doi.org/10.1016/ j.compind.2014.02.005. [33] P. Leita˜o, F. Restivo, A holonic approach to dynamic manufacturing scheduling, Robot. Comput. -Integr. Manuf. 24 (2008) 625–634. [34] P. Valckenaers, H. Van Brussel, L. Bongaerts, F. Bonneville, Programming, scheduling, and control of flexible assembly systems, Comput. Ind. 26 (1995) 209–218, http://dx.doi.org/10.1016/0166-3615(95)00013-T. [35] J.M. Henrioud, A. Bourjault, Computer aided assembly process planning, Proc. Inst. Mech. Eng. Part B: J. Eng. Manuf. 206 (1992) 61–66, http://dx.doi.org/ 10.1243/PIME_PROC_1992_206_056_02. [36] D. Lime, O.H. Roux, C. Seidner, L.M. Traonouez, Romeo: a parametric modelchecker for Petri nets with stopwatches, in: 15th Int. Conf. Tools Algorithms Constr. Anal. Syst. TACAS’2009, 2009, 54–57. [37] G. Gardey, D. Lime, M. Magnin, O.H. Roux, Rome´o: a tool for analyzing time Petri nets, in: 17th International Conference on Computer Aided Verification (CAV’05), Lect. Notes Comput. Sci., vol. 3576, 2005, pp. 418– 423. [38] F. Gamboa, Q.O. Cardin, P. Castagna, Evolution of a flexible manufacturing system: from communicating to autonomous product, in: T. Borangiu, A. Thomas, D. Trentesaux (Eds.), Serv. Orientat. Holonic Multi Agent Manuf. Robot., Springer, Berlin Heidelberg, 2013, pp. 167–180, http://link.springer. com/chapter/10.1007/978-3-642-35852-4_11 (accessed 09.09.14). [39] K. Schild, An agent-based approach to the control of flexible production systems, in: 8th IEEE. Int. Conf. Emerg. Technol Fact. Autom. 2001 Proc., vol. 2, 2001, 481–488, http://dx.doi.org/10.1109/ETFA.2001.997722. [40] M.R. Amin-Naseri, A.J. Afshari, A hybrid genetic algorithm for integrated process planning and scheduling problem with precedence constraints, Int. J. Adv. Manuf. Technol. 59 (2011) 273–287, http://dx.doi.org/10.1007/s00170011-3488-y. [41] F. Zhao, Y. Hong, D. Yu, Y. Yang, Q. Zhang, A hybrid particle swarm optimisation algorithm and fuzzy logic for process planning and production scheduling integration in holonic manufacturing systems, Int. J. Comput. Integr. Manuf. 23 (2010) 20–39, http://dx.doi.org/10.1080/09511920903207472. [42] J.M. Mendes, P. Leita˜o, F. Restivo, A.W. Colombo, Process optimization of service-oriented automation devices based on Petri nets, in: 8th IEEE Int. Conf. Ind. Inform. INDIN’2010, 2010, 274–279, http://dx.doi.org/10.1109/ INDIN.2010.5549413. [43] J.M. Mendes, A. Bepperling, J. Pinto, P. Leitao, F. Restivo, A.W. Colombo, Software methodologies for the engineering of service-oriented industrial automation: the continuum project, in: 33rd Annu. IEEE Int. Comput. Softw. Appl. Conf. 2009, COMPSAC’09, 2009, 452–459, http://dx.doi.org/10.1109/ COMPSAC.2009.66. [44] H. Van Brussel, J. Wyns, P. Valckenaers, L. Bongaerts, P. Peeters, Reference architecture for holonic manufacturing systems: PROSA, Comput. Ind. 37 (1998) 255–274, http://dx.doi.org/10.1016/S0166-3615(98)00102-X. [45] N. Rodrigues, P. Leita˜o, E. Oliveira, Self-interested service-oriented agents based on trust and QoS for dynamic reconfiguration, in: T. Borangiu, A.

68

F. Gamboa Quintanilla et al. / Computers in Industry 76 (2016) 53–68

Thomas, D. Trentesaux (Eds.), Serv. Orientat. Holonic Multi-Agent Manuf., Springer International Publishing, 2015, pp. 209–218, http://link.springer.com/ chapter/10.1007/978-3-319-15159-5_20 (accessed 26.05.15). [46] P. Valckenaers, B. Hadeli, P. Saint Germain, H. Verstraete, Van Brussel, Emergent short-term forecasting through ant colony engineering in coordination and control systems, Adv. Eng. Inform. 20 (2006) 261–278, http://dx.doi.org/10.1016/j.aei.2006.01.007. [47] J.V. Belle, B.S. Germain, P. Verstraete, P. Valckenaers, O. Ali, H.V. Brussel, et al., A holonic chain conveyor control system: an application, in: V. Marˇı´k, T. Strasser, A. Zoitl (Eds.), Holonic Multi-Agent Syst. Manuf., Springer Berlin Heidelberg, 2009, pp. 234–243, http://link.springer.com/ chapter/10.1007/978-3-642-03668-2_23 (accessed 27.05.15). Francisco Gamboa Quintanilla received his graduate studies degree in Mechatronics engineering at the Instituto Tecnolo´gico y de Estudios Superiores de Monterrey (ITESM) (2008, Mexico). He specialized his studies with a Masters degree on Robotics and Automation in Ecole Centrale de Nantes (ECN) (France, 2012). He recently received his PhD degree of the University of Nantes in the Institut de Recherche en Communications et Cyberne´tique de Nantes (IRCCyN) (Nov, 2015). His research focuses on the design of architectural and behavioral aspects of intelligent distributed systems to achieve agility based on the Holonic and ServiceOriented Paradigms. Olivier Cardin is currently assistant professor in the University of Nantes, where he teaches robotics, discrete-event simulation and automated production. He received

his PhD in automatic control from the University of Nantes in 2007. He is also member of the IRCCyN-CNRS, Nantes, France. His research interests are in the area of production activity control of flexible and agile manufacturing systems. He is a co-chairman of workgroup IMS2 ‘‘Intelligent Manufacturing Systems and Services’’ in the CNRS French research group MACS.

Anne L’Anton is an Assistant Professor at the Department of Quality, Industrial Logistics and Organization (QLIO) of the University Institute of Technology of the University of Nantes, France. She co-hosts a national research group entitled Methods and Tools for Modeling and Evaluation. She belongs to the research team Analysis and Control of Discrete Event Systems, Research Laboratory IRCCyN Nantes, France. She lectures on information systems and databases, simulation, systems modeling. Her research activities focus on modeling systems.

Pierre Castagna is a full professor of the Nantes University, in Industrial Engineering. He is member of ‘‘Institut de Recherches en Communications et Cyberne´tique de Nantes’’ UMR CNRS 6597. After attending an initial education in mechanic an automatic, he work on discrete event simulation, transfer system design, self-organized control, holonic production control and more recently on energy efficiency and sustainable production. He has been a scientific manager of more than 50 research contracts with industry (AIRBUS, TRELLEBORG, SOCCATA, AEROLIA, ALSTOM, . . .).