Mme Alemany

F Alarcón

A Ortiz
email: aortiz@cigip.upv.es

Impact of Coordination Mechanisms on the Collaborative Planning Process Components

Keywords: Collaborative Planning Process, Supply Chain, Coordination Mechanisms

In this paper a conceptual framework for characterizing the Supply Chain (SC) Collaborative Planning (CP) under a process perspective is presented. When analyzing the CP process view, the definition of coordination mechanisms among SC members results essential. With the aim of identifying the possible coordination mechanisms that SC members can implement, the structural elements necessary to define them are proposed. Finally, the impact that the coordination mechanisms structural elements have on the definition of the CP process is presented. The knowledge of the CP process, the coordination mechanisms and their relationship constitutes the basis for the latter identification of potential activities that can be supported by decision tools and for the partially or totally automation of the process.

Introduction

Collaborative Planning (CP) can be defined as a joint decision making process for aligning plans of individual Supply Chains (SC) members with the aim of achieving a certain degree of coordination [START_REF] Stadtler | A framework for collaborative planning and state-of-the-art[END_REF]. Because CP belongs to the SC coordination problems category, CP decisions related to the mid and short-term temporal levels must be integrated (temporal integration). Furthermore, for each temporal level, the CP decision-making can be centralized if only one decision-maker exists or distributed, in case several decision makers exist. The plans of these different decision-makers must be also integrated (spatial integration). Indeed, [START_REF] Grossmann | Enterprise-wide optimization: A new frontier in process systems engineering[END_REF] identifies as a major CP challenge to simultaneously achieve both types of integration. In a collaborative distributed context different decision-makers should share some information and should make several decision cycles involving repetitive sequence of decisions until a stopping criteria is achieved, in case negotiation exists. In this situation, the knowledge about the process results essential. Indeed, different authors strength the importance of analyzing the collaboration under a process perspective.

[3] define collaboration as a process in which entities share information, resources and responsibilities to jointly plan, implement and evaluate a program of activities to achieve a common goal and therefore jointly generating value. From the process perspective, there are different works that report flowcharts representing the CP process for a specific distributed decision environment (e.g. [START_REF] Jung | Decentralized supply chain planning framework for third party logistics partnership[END_REF], [START_REF] Sapena | A distributed CSP approach for collaborative planning systems[END_REF], [START_REF] Jain | Dynamic supply chain modeling using a new fuzzy hybrid negotiation mechanism[END_REF]).

However, these CP processes are specifically designed for particular situations being necessary a generic approach that help in the definition, characterization and analysis of CP processes in general. In this sense, [START_REF] Alarcón | Conceptual framework for the characterization of the order promising process in a collaborative selling network context[END_REF] conclude that a process will be defined when the answers to the following questions are known: (a) What activities are to be carried out?, (b) Who is responsible to carry them out and with what?, (c) When and how are they to be carried out?, (d) The process inputs, (e) The process outputs, (f) The process objectives, and (g) The performance indicators.

Through the CP process approach it is possible to implement the coordination mechanisms that link the SC members' plans. In this sense, [START_REF] Gaudreault | Distributed search for supply chain coordination[END_REF] consider that the coordination mechanisms states how the SC members' relationship is operationalized (e.g. rules and protocols to exchange information, which decisions must be taken, by whom and when). [START_REF] Schneeweiss | Distributed decision making in supply chain management[END_REF] affirms that the coordination mechanisms for Distributed Decision-Making systems for a two-level hierarchical environment are: anticipation, instruction and reaction. [START_REF] Arshinder | Supply chain coordination: Perspectives, empirical studies and research directions[END_REF] categorize the supply network (SN) coordination mechanisms into four classes: SN contracts, Information Technology, Information Sharing and Joint Decision Making. [START_REF] Li | Coordination mechanisms of supply chain systems[END_REF] establish that a coordination mechanism for a decentralized SN system should include at least three components: (i) an operational plan to coordinate the decisions and activities of SN members, (ii) a structure to share information among the members, (iii) an incentive scheme to allocate the benefits of coordination so as to entice the cooperation of all members. [START_REF] Stadtler | A framework for collaborative planning and state-of-the-art[END_REF] states that the interaction between the parties involved in a CP scheme can be documented by a protocol defined by the following structural elements: the incorporation or not of a mediator, the initial solution, the number of rounds and the number of offers to be exchanged (stopping criteria) and the final results SN members can expect. In the context of agent technology applied to CP, [START_REF] Forget | Collaborative agent-based negotiation in supply chain using multi-behaviour agents[END_REF] present the main characteristic of automated negotiations (collaboration level, number of participants, number of issues, decision sequence and learning ability), decision mechanisms that can be followed by agents (game theoretic negotiation, argumentation-based negotiation, auctions and heuristic based negotiation). [START_REF] Forget | Study of the performance of multibehaviour agents for supply chain planning[END_REF] proposes an approach that breaks from the hypothesis that planning must always be conducted in the same way. By using multi-behaviour agents they propose to provide planning agents with the ability to adapt their planning behaviours according to changes in the environment.

From the literature reviewed, it can be concluded that there is a strong relationship between the CP process view and the coordination mechanisms that, in our opinion, requires a deeper analysis. This paper attempts to contribute to clarify this relationship being, therefore, the objective of this paper manifold: 1) to propose a conceptual framework for the CP process that support the characterization, definition and analysis of the CP under a process perspective, 2) to identify the structural elements of the CP coordination mechanisms and 3) to define the impact of the coordination mechanisms structural elements on the components of the CP process. The knowledge of the CP process, the coordination mechanisms and their relationship is essential for the latter development of any supporting decisionmaking tool and the partially or totally automation of the process.

The rest of the paper is organized as follows. In section 2 the conceptual framework for characterizing the CP process is described. The coordination mechanisms structural elements for the CP are defined in section 3 and their impact on the CP process components is shown in section 4. Finally, section 5 reports some conclusions.

As [START_REF] Alarcón | Conceptual framework for the characterization of the order promising process in a collaborative selling network context[END_REF], we consider that a process is characterized when the answers to the questions (a)-(g) are known (Table 1). The answer to each question corresponds with the characterization of a specific component of the CP process conceptual framework. For a deeper explanation of the CP process conceptual framework, the reader is referred to [START_REF] Alemany | Conceptual Framework for the Interoperability Requirements of Collaborative Planning Process[END_REF].

The order to answer each question is not sequential, i.e., during the CP process characterization the answer to some questions are interrelated. Furthermore, though global process inputs, outputs, objectives and indicators exist and should be determined for the entire CP process, each activity of the process presents its own inputs, outputs, objectives and performance indicators.

Therefore, to properly define the coordination mechanisms in SCs, the exchanged information among activities should be reflected. This internal information flow is missing if the only analysis of inputs and outputs under a general process perspective as a whole is performed.

As a consequence, the questions (a)-(g) will be answered not only from a whole process perspective but also, when it will be necessary, from an activity perspective. In Fig. 1, a more detailed view of each conceptual framework component and the relationship between them are provided.

Table 1. Components of the CP process conceptual framework

Structural Elements of CP Coordination Mechanisms

In this section, the structural elements that should be specified in order to characterize coordination mechanisms in a CP context are proposed. Through this characterization, an analysis of possible alternatives for implementing the interdependence relationships between SC members will be made. The proposed structural elements are derived from the analysis of the conceptual literature cited in the introduction section combined with the abstraction and generalization of particular CP models and the own experience of the authors.

Number of decision-makers:

it makes reference to the number of SC members that are either under the responsibility of a SC planning domain at a certain planning temporal level or should coordinate and integrate the different plans of other decisionmakers (a mediator). It is of relevance the distribution of the decision-makers along the SC tiers and the number of decision-makers in each one. The most common situations discussed in the literature [START_REF] Forget | Collaborative agent-based negotiation in supply chain using multi-behaviour agents[END_REF] are centered on a two tier SC and are the following: one-to-one, one-to-many and many-to-many negotiations.

Collaboration level: it represents the degree of interest in decision makers' performance. Agreed collaboration level is intensely related with the final results decision-makers should expect, the decision-makers' goal congruence, the information the SC members are in position to share and the trust between them. It is possible distinguish between three main levels of collaboration:

Strong collaboration (altruistic partners that puts the SC goals before its local goals) Low collaboration (self-interested partner that makes decisions mainly following its local goals) Balanced collaboration (any degree of balance between the two previous levels) Interdependence relationships nature: the sharing of power between SC decisionmakers could be not homogeneous. The relative position of each decision-maker in the SC depends on different factors that impact the influence of each decision-maker in the definition of the interdependence relationships. Two differentiate cases could be distinguished:

Hierarchical: the sharing of power between SC members is not homogeneous and, then, CP interdependence relationships are dominated by decision makers with more power in the SC. Their leadership could be reflected in the interdependence relationships in several ways (e.g., defining the negotiation stopping criteria) Non-hierarchical: all the SC members are recognized with the same power and, therefore, all the interdependence relationships are equally agreed. Interdependence relationships type: because SC planning decisions are made at different temporal levels and at each temporal level different decision-makers could exist, two different types of plans integration should be distinguished:

Temporal integration: it involves coordinating planning decisions across different timescales or across various levels of decision-making (tactical and operational). This collaboration type is always hierarchical.

Spatial integration: it involves coordinating the plans of different decisionmakers at the same temporal level. Depending on the sharing of the power between SC members it could be hierarchical or non-hierarchical. Number of coordination mechanisms: it refers to the number of different protocols under which the different decision-makers interact.

Unique: there is an only one protocol that is independent on the environment and other situation characteristics.

Various: when the environment is characterized by high levels of variability, it can be advantageous to define different coordination mechanisms to work under different scenarios. In this case, different options exists: o Pre-defined (non-learning ability): the number of coordination mechanisms are defined in advanced. The situations under which a specific mechanism should be employed and their characteristics should be specified. o Not pre-defined (learning ability): the decision-makers have the ability to acquire experience from previous negotiations (i.e. they are able to adapt their strategies with changing opponents, topics, concerns and user preferences) and to adapt to the context. They can modify their local planning behaviors and/or in concordance with the rest of the decisionmakers. Criteria to select the operation under specific coordination mechanism (available time to make decisions, source of the perturbation in the environment, etc.) in case several coordination mechanism exists.

Information exchanged: for each coordination mechanism the information exchanged between the decision-makers can make reference to SC attributes and decision-makers' outputs:

SC attributes: they consist of known characteristics of the planning SN elements and their environment (demand forecasts, capacity of facilities, operating costs, incentives, penalizations, etc.). It is known in the literature as information sharing.

Decision-makers' outputs: they are those decision variables/ criteria values which, in some way, are passed to other decision-makers. This output data becomes input data for others activities, more specifically they become interdependent parameters of other planning activities. It is known in the literature as joint decision-making and it is the essence of collaborative planning. Depending on the possibility of changing the final value of the outputs by the interdependent decision-makers, two outputs categories could be distinguished: o Final Decision Variables/Criteria: their values cannot be changed under any condition during the negotiation process or, simply, because there is no negotiation. o Non-Final Decision Variables/Criteria: their values can be modified during the negotiation process due to:  Temporal integration: disaggregation of decisions should be made for being implemented (e.g. production volume of families should be disaggregated referred to articles)  Spatial integration: their values are adjusted before reaching the stopping criteria of the negotiation process (e.g. ordered/supplied quantities)

Information processing: the exchanged information for each coordination mechanism could be incorporated in different ways by each decision-maker. Part of the share information can be simply evaluated by other decision-makers (i.e. an ordered pattern can be evaluated by a supplier to know the value of his performance criteria when he does not deviate from the buyer pattern). Other exchanged information can be incorporated in the planning problem of a decision-maker by affecting his decisional space (introduction of constraints) and/or his criteria (penalizations or incentives for deviating from a constraint)

Decision sequence characteristics: it allows define how the coordination mechanisms will be managed.

Beginning of the coordination mechanism: for each coordination mechanism it is necessary to specify when beginning (period, event-driven or a mixed), and how beginning (initial solution by upstream planning, downstream planning, random, by a coordinator, etc.) Sequence of decisions: the order in which the different decision-makers act and the decisions simultaneously made by different SC members should be specified. Stopping criteria of the coordination mechanism: in case negotiation exists, the conditions for ending a coordination mechanism could be defined in terms of number of rounds, limited time and the achievement of a determined aspiration level related with the final results the SN members can expect.

Impact of Coordination Mechanisms Structural Elements on the CP Process Components

In this section, the relationship between the components characterizing the CP under a process perspective and the structural elements of the coordination mechanisms is presented (Table 2). A grey cell in the matrix means that the definition of the specific CP process component is either influenced or it is dependent on the characteristics of the coordination mechanism structural element. For instance, because the number of planning activities should be at least as the number of decision-makers, a grey cell appears in the intersection of the both items.

Table 2. Relationship between CP process components and the coordination mechanisms structural elements

COORDINATION MECHANISMS

-Fig. 1 .

 1 Fig. 1. Conceptual framework components for the CP process and their relationships

INFORMATION (Ex ante) (Ex post)

Therefore, table 2 shows the impact of the coordination mechanisms on the CP process facilitating its properly understanding and representation. To understand the process and the relationship between its elements is, indeed, the first step and constitutes the basis to either totally or partially automated the process (e.g., by means of agent technology) or to develop decision support tools for each SC member, (e.g., mathematical programming models).

Conclusions

In a distributed decision-making environment, the way the collaborative SC members make its decisions and coordinate them results essential to plan the SC operations in a coherent manner. For this reason, there is a wide body of research that develops decision support tools for SC partners and proposes coordination mechanisms between them. The process view is necessary to implement the coordination mechanisms which are the essence of CP because it allows clearly define the information flows, the sequence and timing of decisions, the number of decision cycles, the stopping criteria, etc. Proper process knowledge and characterization is the first step to identify the potential activities for which developing decision support tools and to automate the process. The automation of the process can allow simulate and evaluate different coordination mechanisms under different scenarios before implementing them.


A Luis Osório
email: aosorio@deetc.isel.pt

Hamideh Afsarmanesh
email: h.afsarmanesh@uva.nl

Luis M Camarinha-Matos

Open Services Ecosystem supporting Collaborative Networks

Keywords: Collaborative Networks, Virtual Organizations, Service Oriented computing, Service Oriented Architecture

The growing complexity of the information and communication technologies when coping with innovative business services based on collaborative contributions from multiple stakeholders requires novel and multidisciplinary approaches. Service orientation is a strategic approach to deal with such complexity, and various stakeholders' information systems. Services or more precisely the autonomous computational agents implementing the services, provide an architectural pattern able to cope with the needs of integrated and distributed collaborative solutions. This paper proposes a service-oriented framework, aiming to support a virtual organizations breeding environment which is the basis to establish short or long term goal-oriented virtual organizations. The notion of integrated business services, where customers receive some value developed through the contribution from a network of companies is a key element.

Introduction

Service oriented architecture (SOA) and service oriented computing (SOC) are concepts that have been developed both by research community and industry as innovative patterns to structure the growing complexity of computational infrastructures needed to cope with complex integrated solutions. One main motivation has been the risks of increased dependency of the complex integrated solutions on the proprietary approaches, which in turn make them too dependent on specific suppliers. From the engineering viewpoint, existing integrated solutions tend to follow a "one-of-a-kind" approach making them too expensive not only at the development phase but also along its overall life cycle. In line with service oriented architecture, an initiative such as the service component architecture (SCA) proposes a strategy to develop assemblies of distributed and heterogeneous autonomous components from the same or different providers. Another contribution comes from the open services gateway initiative (OSGi) that proposes a framework to add agility to the development of applications based on loosely coupled components, even though they are too close to the Java technology. The proposed SCA framework is an interesting approach for combining distributed heterogeneous and autonomous computational entities into integrated solutions. Nevertheless the simple combination of heterogeneous and autonomous components originated from different suppliers is not enough to cope with the growing complexity and needs of collaborative networks. Especially when considering the complete life cycle -from, development, deployment, operations management and evolution.

While SOA and SOC tackle complexities in distributed systems, it is fundamental to establish a clear semantics for the concept of services. The organization for the advancement of structured information standards (OASIS) suggests a holistic approach to SOA systems, as networks of a number of entities including service providers, individuals (acting at different roles), machines, suppliers, entities that directly or indirectly establish a system's behavior [START_REF] Laskey | Reference Architecture Foundation for Service Oriented Architecture Version 1.0[END_REF]. More conservative approaches point to an enterprise service bus (ESB) as a structured evolution from enterprise application integration (EAI), where message oriented middleware and data/information transformations play a major role, while they do not present significant innovations. Even when a service wrapper layer is proposed to transform legacy applications/systems into more normalized components, we can question whether this is the right strategy to cope with the requirements of more complex integrated systems.

As pointed out by the IEEE Transactions on Services Computing initiative, a necessary convergence of semantics around service oriented computing is expected to bring some clarity to the currently dispersed contributions. This new body of knowledge is organized around four main areas: i) services and service systems; ii) service technologies; iii) services consulting and delivery; and vi) services applications and management [START_REF] Zhang | Introduction to the Body of Knowledge Areas of Services Computing[END_REF]. This and other complementary initiatives are being pushed by a class of new business services offering people new facilities, and involving contributions from different stakeholders, while making the underlying business arrangements transparent to clients. A paradigmatic example is the utilization of a unique business card (or business nomadic card) that can be used by an individual to pay for public transports, newspapers, street parking, and shopping in stores, based on a unique contract with an integrated service provider. These new collaborative business scenarios, where critical processes rely on a number of diverse information systems, require an innovative distributed computational infrastructure closer to the notion of service ecosystem or service park.

This paper proposes a strategy for creation of a service ecosystem integrating multicultural technical systems through declarative semantics (ontology) in order to make such ecosystem sufficiently agile to cope with the emerging collaborative business scenarios offering integrated value-added services to the customers. For instance, when considering integrated solutions for many different running services at a large complex building, a large shopping centre, a hospital or a public services building, there is also a need for an integrated management and supervision solution to support interoperation among these services. The needed solution must support and shall span over the basic subsystems, e.g. programmable logic controllers (PLC), video camera infrastructures with video server recorders (VSR), heating, ventilation, and air conditioning systems (HVAC), and many other specialized subsystems, which are provided by different technological stakeholders. The open question is how to model and effectively support a network of stakeholders, with offering a single integrated holistic approach to the endusers, while keeping the independence among the service providers.

The notion of integrated business service is not an entirely new concept, as it can be perceived whenever business challenges require a multidisciplinary approach for service provision or the complexity and the need to reduce operational risks requires the participation of more than one company in a given business opportunity. Such services require a balanced approach considering the need for the participation of technology, process, and business expertise. The integrated business service can be linked to the collaborative network (CN) concept as it results from the contribution of heterogeneous and autonomous distributed entities (e.g. organizations, people, software agents) that collaborate to achieve common objectives through sharing their resources and capabilities and thus jointly creating new values [START_REF] Camarinha-Matos | ECOLEAD And CNO Base Concepts[END_REF]. Integrated business services are much more efficiently grounded if they are established within a long-term business alliance that can serve as the breeding environment for formation of business-based collaborations; namely within a virtual organizations breeding environment (VBE) [START_REF] Afsarmanesh | A Framework for Management of Virtual Organization Breeding Environments; Collaborative Network and Their Breeding Environments[END_REF]. The concept of VBE has been proposed to guarantee a minimum collaboration preparedness state for its members, as a pre-condition to participate in collaborative business opportunities, i.e., as the ground for supporting the complete lifecycle of virtual enterprises/ virtual organizations (VE/VO) [START_REF] Camarinha-Matos | The Emerging Discipline of Collaborative Networks; Virtual Enterprises and Collaborative Networks[END_REF].

Establishing an integrated business service (IBS) also requires an adequate preparedness state from its candidate stakeholders in line with the VO concept. From the ICT development point of view, the requirements identified in [START_REF] Afsarmanesh | Ekaterina: VBE Reference Framework; Methods and Tools for Collaborative Networked Organizations[END_REF] for a collaborative network, namely: i) ICT-I reference framework; ii) ICT-I business models; iii) Security framework; and iv) ICT SOA-based infrastructure for collaboration, represent an important basis for the definition of a generic ICT infrastructure for integrated business services. Similar requirements come from other domains as the ePAL/BRAID roadmaps [START_REF] Camarinha-Matos | The Need for a Strategic R&D Roadmap for Active Ageing[END_REF] on ICT and ageing.

At present some IT supplier companies tend to offer some integrated platforms in response to the increasing needs for integrated solutions. As identified in [START_REF] Nikolaou | Bitsaki Marina: Towards a Theory of Emergent Service Value Networks -and an Application[END_REF], this implies that then the complementary networked stakeholders shall negotiate long term service level agreements (SLA) with the IT provider company in order to jointly develop an IBS and establishing their collaborative business relations. Nevertheless, such IT suppliers typically tend to promote monolithic closed solutions, and find it very difficult to cope to the CN requirements of providing an open infrastructure. The open approach is even seen as a threat by some market players.

While most proposed research in the area of CN is centered on identifying the dynamics of business ecosystems involving producers, service providers, consumers, certification bodies, and regulators, with a focus on the business patterns, our research follows a complementary approach to the proposed integrated business service concept. In our approach IBS emerges from collaborative network ecosystems -VBEs -made of complementary autonomous stakeholders which possess their own heterogeneous information systems. Therefore, the discussion is centered on the networked integration perspective, i.e. an integration of contributions (services) linked to diverse IT systems, held by the participating stakeholders. As such, an integrated business service can be defined as a service provided by a network of stakeholders, which are transparent to the subscribing end-user, namely under the assumption that the service subscriber assumes only one contractual relation. In this way, an integrated business service establishes a virtual provider that might be operated and coordinated by a new organizational entity (a new company, a temporary legal entity, or an association where one participating company leads and supports the collaboration). Furthermore, the supporting persons and IT resources are spread over a network. Each participating stakeholder in such collaborative network has its own information system related to its specific organization domain (Fig. 1). Organization domains (OD) establish a trusted execution context under a unified organization's intra-enterprise information system with its associated collaboration layer.

Fig. 1. Collaborative networks formed by multiple organization domains

Provision of an integrated business service requires an extended cooperative space beyond the intra-organization domain. Nevertheless, a key requirement is the need for some unified platform even considering that each participating organization has its own IT system relying on some specific architecture and technology bindings. Furthermore, each organization has its own specific business process framework(s) adapted to its internal process models. On the one hand it is advisable to promote a tight integration between intra organizations' processes and the collaborative processes, those contributing to the realization of the integrated business services. But on the other hand, establishment of strong dependencies among stakeholders when participating in the processes that support integrated business services is against the openness approach and is not desirable or even realistic in time. This situation points to the need for a strategy that can preserve organization´s autonomy while coping with collaboration contractual agreements that underlie integrated business services. As an example, an evolution in one stakeholders' information system should not affect the behavior of the running processes and services participating in collaborative IBPs [8]. Our proposed strategy considers existence of a collaboration layer (CL) at every participating stakeholder, thus providing a separation of contexts between the domain of intra-enterprise information systems, and that of the network collaboration domain (Fig. 1).

For instance, in an intelligent transportation network, an integrated business service can offer an innovative insurance model based on drivers' behavior, which can be identified through the data collected from an enhanced on-board unit, similar to the one nowadays used for tolling (on-board dedicated short range communication transponder). This gives an example of the need for the participation (cooperation) of several systems that can be managed by: a tolling service provider, multiple highway operators (multiple concessionaires) and an insurance company. When a vehicle crosses a tolling infrastructure, the needed information collected from vehicle bus (CAN bus) is sent to the tolling stakeholder in conjunction with the tolling transaction data. As such, within the same contract that was initially exclusively related to highway tolling, the above insurance company, in cooperation with the business integrated service provider, can now offer an innovative insurance fee calculation for customers. Therefore, the extracts (cost statements for customers) can be enhanced with the insurance payments when presented to subscribers, depending on the agreed payment periods (e.g. daily, weekly, monthly or yearly). The example of the Spanish insurance company Mapfre that has developed a pay-as-you-drive (PAYD) model, based on a specialized on-board system, is discussed in [START_REF] Troncoso | PriPAYD: Privacy Friendly Pay-As-You-Drive Insurance in Workshop on Privacy in the Electronic Society -WPES'07[END_REF]. Another similar example is the integrated business service offered by the Portuguese Via-Verde company, which in the same contract covers both the tolling and car parking payments. It is a running example where collaboration among the involved organizations follows a specific IT infrastructure design and developed mechanisms [START_REF] Osório | A Collaborative Networks case study: The extended "ViaVerde" toll payment system[END_REF], even though the information systems of some of the involved stakeholders has evolved to a service oriented culture.

A similar situation can be foreseen for the provision of care services to elderly, in which different entities e.g. care centers, health centers, social security, leisure centers, etc., can contribute to provide integrated services under a single contract. These examples suggest the need for a balanced approach where VBEs might need to involve members at different IT development stages, motivating the proposal of introducing the collaboration layer.

Cooperative Open Service Infrastructure

The integrated business services often require the involvement of a grid of diverse resources, including the computational services, persons interacting through multiple communication channels (human machine interaction channels), and devices (also represented by services), which are able to participate in different collaborative processes. Such resources need to all be represented as adaptive entities or components, embedding meta-information, and able to be managed in different lifecycle phases of the IBSs. In such an environment, collaborative processes can be provided, realizing integrated business services, through the composition of a hierarchy of processes, each one relying on the composition of other already defined simple or composite services.

In this framework the finest grained entity is a simple service seen as an autonomous computational entity, implemented in some technology (e.g. Web Services, JINI, WCF, Multi-agent framework, grid-services). Here, the entire computational logic, even if associated to monolithic systems such as a classic enterprise resource planning (ERP) application, is abstracted as services that are supported through wrappers, according the proposed framework. Motivated by the need to increase reutilization of computational logic, services can be organized in two main classes: i) system services, and ii) application services. The system services are those autonomous computational entities, possibly from different suppliers, that are part of the organization's open service bus. They contribute to establish the ICT culture of the organization, i.e. providing a kind of organization's signature. The planned strategy is to encourage (or force) new service suppliers to reutilize as much as possible the existing resources, instead of developing from scratch. As an example, a new application service for managing human resources (or simply to add a new service to the human resource management facilities) must use the already existing and documented identity management system service. Therefore, a system service is part of the organization's open service bus. On the other hand, an application service is not conditioned to offer services to other peer services and thus it is not part of the organization's open service bus.

The logical structure of an application or system service, while prepared to be involved in collaborative processes, involves four primary aspects:

1. A functional interface making available a number of operations under some predefined semantics (implicit or explicit semantics through the association of an ontology). A functional interface can include operations like add (op1, op1), multiply (op1, op1), as part of a calculator service. 2. Event infrastructure responsible to manage asynchronous relationships among services. Consider a subscription of an event signaling the subscriber each time a functional operation is called in the calculator; 3. Instrumentation port to integrate a monitoring infrastructure based on specialized diagnostic and prognostic services (agents); 4. Meta-data embedding the necessary parameters to support service client's adaptation. This can be done through implicit semantics, data structures and semantics resulting from a normalization process or adopting an ontology, thus offering dynamic adaptability to potential clients. The functional interface establishes a number of operations to be accessed by other services (clients) according their functional needs.

The events infrastructure makes it possible to subscribe to certain events, thus providing an asynchronous access to service relevant information. A client service can subscribe to relevant events directly from their originating services or can access the generated events through a tuple space (in this case shared by all other services in the collaboration network). The utilization of a tuple-space avoids the need for services to know the event ports for each event originating service.

The instrumentation port aims at establishing an open monitoring infrastructure based on coordinated monitoring agents which are specialized to guarantee the correct operation of the running services. This strategy is inspired by the existing monitoring infrastructures for communication systems, like the routers and switches. Network management applications can monitor system's behavior by accessing a management information base through the single network management protocol or using other open standards like the Java management extensions protocol and the corresponding managed Beans.

The associated meta-data is organized under two main groups: i) the information related to the infrastructure, and ii) the information related to the collaboration in the context of a collaborative network (Fig. 2). Both service information (meta-data) groups are organized in two sub groups: i) the acquaintance information holding the knowledge required by potential service clients and market-place to discover and select decision support, and ii) the self information addressing the infrastructure configuration requirements.

The open service framework (OSF) for collaboration among organizations is made of cooperative enabled services (CES) which are available from a market place. One important difference from existing approaches namely the cooperative processes defined by business process modeling notation (BPMN) where collaboration is associated to exchange of messages among organizations, is that the proposed framework considers the CES as public services available to participate in collaborative processes. A collaborative process is enacted on a collaborative network infrastructure, established by the proposed OSF. Furthermore, any service in one organization can access a CES in any other organization within the same collaborative network (CN). This means that all CESs, provided by different service providers within a CN, establish a basis for design of new specialized services, which can be developed and deployed as compositions of the base services available in the network. If the collaboration layer of a service has no defined information, it is considered a private service and as such it is not visible at the collaborative network level.

Fig. 2. Model of a service in a collaborative network

In such a service space at least one service must play the role of service repository, which might be implemented as an LDAP, JINI/Reggie, UDDI, ActiveDirectory or other directory service. To cooperate with other services, a service first looks up at the repository and selects the needed subset of services that are needed in order to generate a cooperative integrated solution (Fig. 2).

Open Collaborative Business Framework

Most existing ICT solutions are so far developed without embedding any capabilities to support their potential future integration with other solutions. This means that existing systems/applications are developed in response to specific functional and/or other requirements, following a software development process considering the completeness of the developed solution against the expected results. Even when solutions are based on open source, their considered criteria and advantage is on an eventual reduction of the total costs by significant reduction in their development-time and complexity as well as the run-time costs. Nevertheless, the costs associated to the extra development and configuration required for open source components may generate expensive solutions.

What is expected to contribute to the reduction of the total cost of ownership of integrated solutions is the approach of grounding the development of complex integrated solutions on a multi-vendor computational autonomous market place. This requires a new approach to service development and establishing a high level language able to abstract a multi-technology and multi-supplier computational infrastructure. In this line, the enterprise generation language (EGL) from IBM [START_REF] Margolis | IBM Rational Business Developer with EGL[END_REF] is an example of the market recognition of the fact that something new is needed to cope with the complexity associated to the development of integrated solutions made of an evolving diverse set of resources, e.g. hardware, operating environments, specialized frameworks and systems.

There is an ongoing discussion on the need for an additional language, however one thing has become accepted -there is a need for a new strategy to cope with the development of integrated solutions.

Beyond the shift to a model-driven development with or without a new language, the proposed service orientation can provide a strategic approach to evolve to multi technology and multi-supplier integrated solutions, as for example demonstrated in practice by the new service-oriented toll management system developed by the Portuguese Brisa company [START_REF] Osório | Towards a Distributed Process Execution Platform for Collaborative Networks[END_REF]. The Brisa's experience however has shown that so far software development companies are not yet prepared to develop solutions under a cooperation approach. Furthermore, the pressure for rapid innovation does not give enough time to consolidate approaches for complex critical systems, where the risks are a strong inhibitor to the adoption of open software development patterns.

Therefore the proposed separation of contexts through collaboration layer, which was introduced above and illustrated in (Fig. 1), is important, considering that not all organizations are expected to internally evolve to adopt a uniform open enterprise service bus (Fig. 3).

Fig. 3. The Collaboration Layer abstracting internal network organization's architecture

While such evolving strategy is important for an increasing reutilization of already existing computational resources, it is up to the collaboration layer to establish the required collaborative ecosystem, making it possible to offer the integrated business services.

This above scenario suggests the assumption that an enterprise's information system might be at one of the following four possible stages: i) it presents a clear service oriented strategy considering it publishes its internal service through the OESB bus as a set of reusable resources (system and application services) to be considered by suppliers / developers of new services; ii) the enterprise is in the migration process and the enterprise service bus (OESB) only partially integrates its application systems, and thus through this bus it is not possible to access all the internal enterprise's systems; and iii) the enterprise is already organized in "islands of automation" while integrated applications are constructed on one-to-one specific protocols; a service bus was not introduced yet as a strategy to get integrated solutions on an open basis (Fig. 3). However the focus of this research is not the intra-enterprise information systems but rather its involvement in collaborative networks [START_REF] Afsarmanesh | A Framework for Management of Virtual Organization Breeding Environments; Collaborative Network and Their Breeding Environments[END_REF], [START_REF] Camarinha-Matos | The Emerging Discipline of Collaborative Networks; Virtual Enterprises and Collaborative Networks[END_REF] offering the integrated business services (Fig. 4).

Fig. 4. Business Integrated Services Framework Reference Architecture

The proposed strategy illustrate in (Fig. 4) above is to abstract the internal diversity of enterprises' information systems by considering only what is shared with others through the organizations' cooperation layer (CL). Therefore, the collaboration layer aims to play a proxy role, hiding the complexity of dealing with intra-enterprise systems and more important it is responsible to present a uniform view of each enterprise to all other participating organizations. It is clearly expected that a CL for a company that has not yet adopted the SOA approach is much more complex to develop than that for a company already owing an open service bus. For the SOA based company, the services in the CL might mainly address security issues and the management of resources needed to support the CN. On the other hand, for the monolithic systems company, there is a need for the services to implement proprietary protocols and interfaces to make the necessary resources available through the CL to the collaborating community. The CL is also an important element for the realization of the open collaboration bus (OCB) concept, considering that all published systems and application services are implemented into the CL of the participating companies (Fig. 4). In short, the collaboration layer (CL) of an enterprise is mainly responsible for the following:

i. It manages all enterprise resources that are shared within the virtual organization breeding environment (VBE) of which the enterprise is a member, and which can be employed through the life cycle of virtual organizations (VO). Availability of these resources through the CL is a part of each enterprise's participation preparedness; ii. All services that an enterprise publishes in the OCB are implemented in its collaboration layer, even if a simple forwarding to the effective service provider inside the company is necessary. The CL implements both the system services and the application services. As stated above, the system services are part of a specific OCB signature while the application services do not follow so rigid rules considering that they are not part of the OCB. The integrated services offered by a collaborative network establish a number of new challenges from the ICT viewpoint considering their intrinsic complexity. On one hand, there is a need for holistic approaches -one collaborative process might require the involvement of systems from different organizations -and, on the other hand, the important requirement to maintain solutions as much as possible independent from a specific supplier is an important pre-condition for the success of such collaborative businesses.

Related Work

The definition of an ICT infrastructure able to support the complexity associated to the CNs is an open research topic. Research projects from diverse areas have attempted to tackle this problem but there is not yet a definite approach that can be considered agile and adaptive enough to receive a consensus as a reference strategy. The European integrated project ECOLEAD proposes that developing a plug-and-play horizontal ICT infrastructure (ICT-I) based on an open platform-independent specifications and ICT standards [START_REF] Rabelo | Advanced Collaborative Business ICT Infrastructures; Methods and Tools for Collaborative Networked Organizations[END_REF] can address this problem. With this approach potentially a collaborative business infrastructure (CBI) can be derived as an open service oriented infrastructure to support the collaborative tasks of CN members in the context of collaborative processes. The proposed approach lacks however a clear strategy on how to cope with the complexity associated to the distribution and vulnerabilities (fault-tolerance, reliability, security, coordination) considering that organization's information system infrastructures follow different development and operation cultures. Our proposed collaboration layer aims to concentrate on the same reference architectural entity to resolve such diversities and embed the necessary coordination mechanisms, able to answer scalability and dependability requirements.

Other works more centered in the area of computer science and computer engineering, are focused on developing an open ICT infrastructure for the interorganizational space, and can be exemplified by the case of NESSI, the European Technology Platform dedicated to Software and Services [START_REF] Nikolov | Building a research university ecosystem: the case of software engineering education at Sofia University[END_REF]. Another common strategy is to consider a centralized architecture as it can be exemplified by the case of the collaborative infrastructure for collaborative genetics experiences; the e-infrastructure to support collaborative embryo research [START_REF] Barker | An Infrastructure to Support Collaborative Embryo Research[END_REF]. The strategy might be acceptable for collaborative research and some other application domains but the integrated business service concept requires a federated approach considering that each organization holds its own culture, processes and technology, and thus the collaboration layer proposed in our research work is grounded on the participation of diverse independent and autonomous nodes. Strategic roadmaps on ICT and ageing as those being developed by the ePAL and BRAID projects [START_REF] Camarinha-Matos | The Need for a Strategic R&D Roadmap for Active Ageing[END_REF] also require a new approach for service integration.

Conclusions

This paper proposes a collaborative network approach to the development of the integrated business service concept. The research work is grounded on the acquired experience with already deployed business solutions requiring the participation of multiple stakeholders considering a single contract for the end users. The case of the Portuguese Via-Verde, initially developed for the tolling service and now extended to payments in parking areas and gas stations, provides a practical guiding background.

Another important example is the provision of care services to elderly by multiple stakeholders.

One important aspect is the federative characteristic considering that organizations have their own process and technological culture what recalls for a strategy that guarantees their independence while committed to the collaborative network. In our proposed approach, it is up to the collaboration layer to support and implement mechanisms able to execute the collaborative processes underlying the business models associated to the offered integrated business services. One additional complexity addressed by our approach is the need for global coordination of the participating autonomous computational services which run on distributed and heterogeneous computational platforms. This second complexity is outside the scope of this paper and will be addressed in forthcoming papers. Furthermore, dependability considering security, reliability, fault tolerance, scalability from other quality issues, are complex requirements that need to be addressed in future and guaranteed in such federated collaborative network. The solution approach, must be balanced considering key issues from technology to process and the business levels, and requires a clear modeling framework and innovative mechanisms contributing to the development of collaborative solutions for collaborative network businesses.

Acknowledgements.

This work was partially supported by BRISA Innovation and Technology company through a research and development project, and by the European Commission through the FP7 BRAID (grant agreement ICT-2009-7.1 2484852) project.


Darío Rubén

Rosa Franco

Angel ORTIZ BAS Pedro Navarro Varela

Gomez-Gasquet

Service Entities in Manufacturing Networks

Keywords:

Service Entities have been proposed as a relevant approach that may help to support structural and functional Collaborative Networks modeling and deployment, especially when they are engineered inside Virtual Breeding Environments. This work is intended to explore the suitability of such approach to next-generation manufacturing networks. By means of a supporting case, the paper identifies main service entities of the problem domain, exemplifies how service interfaces can be defined and how can they be used to compose abstract collaborative processes definitions.

Introduction

Virtual Breeding Environments enhance the effectiveness and rapidness of Virtual Organizations creation and operation [START_REF] Camarinha-Matos Y | A comprehensive modeling framework for collaborative networked organizations[END_REF]. In achieving such goals, it is necessary to design and implement a new kind of systems which can be able of managing both VBE and VO Life Cycles in a consistent and integrated way. The so-called VBE Management Systems are expected to fully support the creation, operation and dissolution of Virtual Organizations, by defining a set of reference models (at structural, functional or behavioral level, to name few of them) that must be adopted by VBE/VO participants when they are willing to be involved in emerging collaboration opportunities [START_REF] Ecolead | D21.1 Characterization of Key Components, Features and Operating Principles of the Virtual Breeding Environments[END_REF].

Manufacturing networks are clear manifestations of those VBEs where spot collaboration opportunities may usually appear. But, in order to fully take advantage of them, next-generation management systems need to be designed and implemented, by combining relevant previous developments [START_REF] Ni | A collaborative engine for enterprise application integration[END_REF] with most recent technological developments.

This work represents the first step in building that kind of systems since the approach here introduced is intended to combine architectural principles of Enterprise Integration [START_REF] Kosanke | CIMOSA: enterprise engineering and integration[END_REF] with fundamental principles of Service Oriented Architectures.

The work has been structured as follows. In Section 2, a short introduction to basic concepts is given; Services Entities concepts and their life cycle are also briefly described. In Section 3, supported by a running case, suitability of Service Entities approach for manufacturing networks is analysed. Finally, in Section 4, main conclusions and further research needs are envisioned.

Main Concepts and Motivation

Virtual Breeding Environments and Virtual Organizations

Collaboration between partners is a preferred way to ensure optimal resource balance and to get perdurable benefits [START_REF] Jagdev | Anatomy of enterprise collaborations[END_REF]. Time of preparation and difficulty of launching a Virtual Organization will increase in the same proportion as the number of potential partners and complexity of collaborative processes to be carried out.

Virtual Breeding Environments [START_REF] Camarinha-Matos Y | Collaborative networks: a new scientific discipline[END_REF] are intended to harmonize the preparedness level of involved organizations while, at the same time, a collaborative infrastructure is deployed in order to deal with interoperability problems at different levels: communications, data, services, processes or business [START_REF] Ruggaber | ATHENA-Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications[END_REF].

In VBEs, the main idea is to restrict the number of potential participants by drawing a border to the open universe and allowing some partners to come inside. Those partners have to agree on common operating principles: business semantics, strategies or goals, distributed business processes management practices or even common ICT tools. Being inside the border reduces uncertainty between partners, basic to share information and to reach their common objectives. Rapidness and flexibility in VO preparation and launching are requirements that any VBE management system must accomplish.

Service Entities

Service Entities (SE) have been defined as the result of logically grouping a finite series of web-oriented business services interfaces which, given its functionality and performance, enable interaction (making requests) with a specific conceptual entity (e.g., bank, supplier, factory, etc.) from an interorganizational network or a working team [START_REF] Franco | Modeling extended manufacturing processes with service-oriented entities[END_REF].

SEs have been proposed as basic modelling constructs for Collaborative Networked Organizations [START_REF] Franco | Supporting Structural and Functional Collaborative Networked Organizations Modeling with Service Entities[END_REF], for both the Structural and Functional dimensions. As they have been defined, a single Service Entity is the result of logically tying together:

-A finite set of business services interfaces which jointly defines the expected behaviour of those conceptual entities involved into the domain being modelled and, -A finite set of attributes which will allow characterize and distinguish between them.

Abstract Service Entities (ASEs)

Abstract Service Entities are generic constructive blocks used to model different "types" of entities that are present in the problem domain under study. For example, in manufacturing networks context, the ASE concept may be used to define and represent the generic characteristics and services of: factories, suppliers, plants, warehouses, subcontractors, transport companies, lines, sections, or, in general, the different types of resources that will be part of the final model. ASEs are not associated with any specific instance of the entity defining it. They not only represent the abstract definition of the series of attributes which may characterize the Entity, but also the specifications of the electronic services interfaces which are defined by each Entity.

If Transport like trucks, are identified within the problem domain to be modeled, they could be defined as an Abstract Services Entity named as Truck which contemplates the attributes and services required to identify them and to discover their electronic behavior.

Concrete Service Entities (CSE)

ASEs may be used in the Design Specification phase to model the problem, but without referring any specific resource to be used. However, as for wishing to support the execution, it is necessary to consider that the activities involved in the processes are carried out by specific requests from the various entities that have been modeled.

These requests are provided by Concrete Service Entities (CSE). The CSE creation process is known as Instancing and leads to specific occurrences of a particular ASE. This explicitly implies that the new entity created must have values which fill the empty ASE structure from which it originates: that is, to give values to the attributes and implementations to their network services.

Therefore, the attributes defined in the ASE will now take the specific values of that particular entity (a machine number, a warehouse identifier, etc.), and the corresponding electronic services will also have an implementation that is typical of the Entity; access to these services, and the request for them to be executed, will be via web.

Service Entities Life Cycle

As defined, Service Entities will also have their own lifecycle. In Figure 1, it is possible to identify some of their main activities.

At their first stage, ASE must be modelled into the VBE Engineering Environment (Figure 1, Step 1). At this stage, and as in the object orientation paradigm, ASE may be refined or generalized as needed. In this way, each specific VBE will count with a repository of ASE that will be used during the instantiation process (Figure 1, Step 2). During the instantiation process, CSE are registered in an Open Repository which can be, later on, accessed from the VO Engineering Environment. This instantiation process provides the membership applicants with the service interfaces that they ought to locally deploy and integrate at level. From now on, they are prepared to be involved into as many VOs as they can be granted to be (Figure 1, step 3).

Service Entities Modeling in Manufacturing Networks

An experiment carried out for the purpose of applying the ASE and CSE concepts to the modeling and coordination of manufacturing network processes is now introduced.

First, a description of the manufacturing network and the main manufacturing process characteristics will be given. Then, how modeling the SEs has been done in this scenario will be shown. Finally, a component of the Technological Platform which will support the network Production Planning process will be described, this being a ASE/CSE-based manufacturing processes editor.

Description of a manufacturing network

The Manufacturing/Supply Network on which this study is based is made up of a series of actors from the automobile sector. The company with which the case is developed (a manufacturer) is, at the same time, a first-tier supplier as it directly supplies the OEM, and is also a second-tier supplier as it supplies components to the second-tier suppliers. Both the OEM and the first-tier suppliers, and in some cases other end clients, are those which generate demand for the manufacturer and, for the purposes of this case, they only play this role with which the references made to finished products, half-finished products, or raw materials actually refer to those originating from the manufacturer (in this case, Molding).

At the same time, the manufacturer not only relates to suppliers of raw materials (RM), which are other second-tier (or third-tier) suppliers, but also to subcontractors to manufacture the ordered products. Finally, the network counts on various logistics operators to move the RM, half-finished products, and finished products.

The manufacturing process starts by receiving RM (spools of steel) in the manufacturer"s warehouse. According to the Production Plan, the spools of steel are transported (internally) to the Molding area where a first operation is carried out. There are two possibilities at this stage: a readily available finished product (which will be sent to the Client and, also in accordance with the Production Plan), or a halffinished product, in which case it will remain in the warehouse until required. Once again in accordance with the Production Plan, and for this particular case, the process requires a welding operation which is subcontracted. The Logistics Operator is in charge of transporting the half-finished products between the manufacturer and the subcontractor.

Once this part of the process has been completed, the half-finished product returns to the manufacturer"s warehouse where other operations are carried out (washing, oiling, labeling, etc.) until the finished product is made which the Logistics Operator is in charge of transporting to the client"s facilities.

From the planning and control perspective of the Manufacturer"s Production Department operations, internal processes could be efficiently monitored. However, when the manufacturing process would need to mobilize half-finished products (WIP) to subcontractors, difficulties would arise in the visibility and control of the operations. Furthermore, the company would be starting to increase its production volume and, as a result, would also increase the need to resort to contracting additional productive capacity.

Modeling service entities

The following approach has been based on the use of Service Entities as constructive elements which could provide solutions to this kind of problems from an integrated business and technology point of view.

After first analyzing the Manufacturing/Supply Network, three types of main ASE were identified (see Fig. 2): Fig. 2. Main ASEs in a manufacturing network -Productive entities: those in charge of totally or partially transforming some reference. In the case of this network, both the Molding section and the subcontractor are examples of productive entities.

-Warehouse entities: destined to store both finished and half-finished products in the network domain. In the example, even though others existed, only the stocks of one warehouse belonging to the manufacturer would be considered.

-Transport entities: these are in charge of moving materials from any possible combination of the two aforementioned entities both internally and externally.

In this case, there are two transport entities: the Logistic Operator and Internal Transport. For each of these entities, the main attributes were defined and a preliminary design of their services was done If we start with this ASE definition, it is possible to rapidly define the manufacturing network structure by making a request (CSE, Concrete Service entities) for each node by assigning values to its attributes. By way of example:

-ASEProductive = {""Molding"", ""Subcontractor""} -ASEWarehouse = {""WarehouseManufacturer""} -ASETransport = {""LogisticOperator"", ""InternalTransport""} One direct benefit that this approach offers is that it is possible to vary the network structure, if it were necessary. For example, should the idea be to incorporate new subcontractors, suppliers of RM or Logistics Operators, all that needs to be done is to use the same request process and register for each new node.

Having defined the structural aspects, we now go on to analyze how ASEs contribute to facilitate the interoperability in the extended processes domain.

As previously mentioned, each ASE possesses a ""homogenized"" series of services interfaces, S = {s1, s2,…, sn}, which may encompass different business activities (or processes) when they are called upon. These services interfaces are defined generically for the ASEs and they are specified for each CSE, depending on each node"s requirements.

In the example, the ""Logistics Operator"" and the ""Internal Transport"" transport entities, which are requests of the same Transport ASE, share the same service interface (s = ""createTransportOrder()"") intended to receive the order to organize the transport of the materials involved. What varies in each case is the implementation of this service, that is, the way in which each implementation is carried out. For one entity it will mean a simple internal warehouse operation to the Molding section, while for the other it will involve transferring half-finished products from the Manufacturer to the Subcontractor.

Having defined the entity"s services, the interfaces are implemented in a corporate computer (or similar) with Web capacities. At this stage, the link with the internal information systems of each node is created.

With a subsequent request, the extended processes are modeled as an orchestration of the activations of the services which the various participating ASE/CSE may supply. For instance, Fig. 3 depicts a simplified representation of the reserveStocks() service of a warehouse-type entity.

Fig. 3. Business service example of inventory reservation in Warehouse ASEs

After the extended processes model has been created, the interface may be used to define, for example, that a Productive Entity requests a Warehouse to reserve the stocks of a given material. In this way, the following representation would be obtained (see Fig. From the network processes management viewpoint, the second interesting aspect of this study, this approach is also very useful for solving the interoperability problems at this level.

If the process has been modeled with the services of an ASE, any of the concrete requests of this type (CSE) which was registered could provide the network with the execution of this service.

Conclusions and Further Research

The main goal of this study has been to explore the suitability of the Service Entities approach for manufacturing networks support.

As it has been presented, service entities modeling seems to be a promising approach when engineering next-generation manufacturing ecosystems. By means of abstract service entities and concrete instances implementing each business service interface, partners involved in a manufacturing network can be easily integrated into the collaborative processes execution.

Since ASEs modeling and CSE intantiation is just a first step in the whole process of creating manufacturing ecosystems, next research actions will cover a fully

Fig. 1 .

 1 Fig. 1. Main activities of the SE lifecycle.

Fig. 4 .

 4 Fig. 4. Process models in manufacturing networks may use ASE Services

implemented scenario where collaborative manufacturing processes can be tested and validated.

Additionally, authors are working in a fully functional platform that will be used as ecosystem management system for those manufacturing networks.


Sofía Estellés

Teresa Barbera Ribera

José Miguel

Albarracín Guillem

Carlos Manuel Dema Pérez

Revision to Theory of Constraints

Keywords: DBR, Drum-Buffer-Rope, Theory of Constraints, TOC, Goal, Thinking-Process

It's intended to give an approximation to the Theory of Constraints (TOC), to achieve that goal we explain the conceptual bases, the thinking process, the flow management and later on we will focus on its application into production, also known as DBR (Drum-Buffer-Rope). A usual critic in the academic environment is that TOC techniques produce results that are feasible but not always optimal. Although defenders of TOC reply that optimal results are very elegant but need to reduce or eliminate variability of systems, while TOC is an appropriate method to work with variable worlds, such as the real one. Anyway, this creates a gap relative to production programming and sequencing, establishment of batch sizes, measures of initial buffer size and determination of the optimal product mix.

Introduction

TOC is a systemic methodology of company management and improvement. The concepts in which is based are compiled from most of the literature published over the topic, we will highlight the concepts goal and constraint. Contribution of TOC can be divided into 2 groups [START_REF] Noreen | La teoría de las limitaciones y sus consecuencias para la contabilidad de gestión[END_REF]:

Thinking Process: Set of tools that ease the analysis and search of systemic solutions for problematic situations. Robust applications based on Systemic thinking and Operations research methods: Production, Operations, Supply Chain, Project Management, Decisionmaking, etc…. There also exist some studies showing evidence that from the start of introducing TOC, companies achieve to increase its production quantity at the same time as they reduce both inventory and cycle time [START_REF] Aggarwal | MRP, JIT, OPT[END_REF]; [START_REF] Johnson | MRP? MRP II? OPT? CIM? FMS? JIT? Is any system letter-perfect?[END_REF]; [START_REF] Koziol | How the constraint theory improved a job-shop operation[END_REF]; [START_REF] Tseng | The study of an Easy-to-Use DBR and BM system[END_REF]. Some academicals tests validate that using TOC techniques produce a better performance than using MRP, Lean Manufacturing and JIT [START_REF] Ramsay | Push, pull and squeeze shop floor control with computer simulation[END_REF], [START_REF] Fogarty | Production and Inventory Management[END_REF]; [START_REF] Cook | A simulation comparison of traditional, JIT, and TOC manufacturing systems in a flow shop with bottlenecks[END_REF]; [START_REF] Duclos | The impact of a constraint buffer in a flow shop[END_REF]; [START_REF] Holt | Candid Comparison of Operational Management Approaches[END_REF]; [START_REF] Mabin | The World of the Theory of Constraints: A review of the International Literature[END_REF]. The result of these studies show that TOC systems produce higher production levels as they reduce inventory, production time or "lead time", and the cycle time standard deviation.

Theory of Constraints

It is a systemic business management and improvement methodology. It's based on the following concepts [START_REF] Agii | La Meta: Cómo ponerla en práctica. Apuntes de un seminario[END_REF]:

1. The goal of any profit company is to earn money in a regular way. If it does not it is because its constraints do not let it. 2. In any company just exist a few constraints. 3. A constraint can be physical or political. 4. Systemic thought defends that the maximum performance of a system is achieved by the maximum performance of its constraints.

Continuous Improvement Cycle

We cannot talk about TOC without mentioning the continuous improvement process in which is based, [START_REF] Agii | Asociación Goldratt Institute Ibérica, Producción: Cómo mejorar con TOC[END_REF]:

1. IDENTIFY the limitation of the system. 2. Decide how to EXPLOIT the limitation of the system.

3. SUBORDINATE everything else to the previous decision. 4. ELEVATE the limitation of the system. 5. If, in a previous step, the limitation has been broken, return to step 1. Do not let that INERTIA turns out into a limitation of the system.

Evolution of TOC

When trying to perform a study or a chronology of the TOC philosophy evolution, its evolution can be segmented into 5 eras [START_REF] Watson | University of New Orleans, College of Business Administration, United Stated. "The evolution of a management philosophy: The theory of constraints[END_REF]:

1. The OPT era (Optimized Production Technology). The secret algorithm. 2. "The Goal" era, using DBR programming (Drum-Buffer-Rope).

3. "The barn syndrome" era, using the TOC measuring systems. 4. The "It's not matter of luck" era, applying reasoning processes to various topics. 5. The "Critical Chain" era or TOC applied to Project Management. We can see the evolution in the figure 1. The mechanisms used by TOC for each of its Management processes, instead of following the eras chronologically, although they could be easily addressed to the eras mentioned before. Fig. 1. Eras of TOC evolution. Source: Own adaptation from [START_REF] Watson | University of New Orleans, College of Business Administration, United Stated. "The evolution of a management philosophy: The theory of constraints[END_REF].

The application of TOC techniques has been discussed in literature in a variety of Management sub-disciplines:

In production: [START_REF] Jacobs | The OPT Scheduling System: A Review of a Production Scheduling System[END_REF]; [START_REF] Koziol | How the constraint theory improved a job-shop operation[END_REF]; [START_REF] Lambrecht | Buffer stock allocation in serial and assembly type of production lines[END_REF]; [START_REF] Raban | Constraint-based control of flexible flow lines[END_REF], [START_REF] Tseng | The study of an Easy-to-Use DBR and BM system[END_REF]. Project management: [START_REF] Goldratt | Cadena Crítica (critical chain) : Una novela empresarial sobre la gestión de proyectos[END_REF], [START_REF] Leach | Critical chain Project Management improves Project performance[END_REF]; [START_REF] Umble | Manage your projects for success: an application of the theory of constraints[END_REF]; [START_REF] Steyn | An investigation into the fundamentals of critical chain project scheduling[END_REF]; [START_REF] Cohen | Multi-project scheduling and control: a process-based comparative study of the critical chain methodology and some alternatives[END_REF]; [START_REF] Leach | Lean Project Management, Eight Principles for Success: Combining Critical Chain Project Management and Lean Tools to Accelerate Project Results Advanced Projects Inc[END_REF]; [START_REF] Woeppel | Projects in Less Time: A Synopsis of Critical Chain[END_REF]. Distribution: [START_REF] Gardiner | Measures of product attractiveness and the theory of constraints[END_REF]; [START_REF] Goldratt | No es cuestión de suerte[END_REF]. Supply Chain management: [START_REF] Rahman | The theory of constraints thinking process approach to developing strategies in supply chains[END_REF]; [START_REF] Watson | Comparison of DRP and TOC financial performance within a multi-product, multi-echelon physical distribution environment[END_REF]; [START_REF] Simatupang | Applying the theory of Constraints to supply chain collaboration[END_REF]. Improvement processes: [START_REF] Schragenheim | Buffer Management: a diagnostic tool for production control[END_REF]; [START_REF] Atwater | Using the theory of constraints to guide the implementation of quality improvement projects in manufacturing operations[END_REF]; [START_REF] Gattiker | A cause-and-effect approach to analyzing continuous improvement at an electronics manufacturing facility[END_REF].

Reviews to TOC

Besides the reviews already mentioned in the introduction, it is usually reproached to TOC that most of the knowledge that is used is based on already existent theories: TOC is based on systemic thought [33]. The Solutions that propose TOC for operations and Project Management are based on the queues theory and the statistical theory of aggregation. [START_REF] Debernardo | Boletín sobre la Teoría de las Restricciones[END_REF].

The Concepts proposed by TOC for Decision making are the method "Direct Costing" that appears in management books from the fifties [START_REF] Noreen | La teoría de las limitaciones y sus consecuencias para la contabilidad de gestión[END_REF]. The solution that TOC proposes for Distribution is basically the application of the aggregation theory [START_REF] Debernardo | Boletín sobre la Teoría de las Restricciones[END_REF].

The thinking processes of TOC are simply the verbalization of common sense, and have also been extracted from Edward De Bono's books. [START_REF] Dogget | A statistical comparison of three root curse analysis Tools[END_REF]. The true achievement of Dr. Goldratt and his team (Donn Novotny, Dale Houle, Dee Jacobs, Oded Cohen, etc) has been to develop a method to be able to use these Tools together in the resolution of problems. The worth has been to find a way for these tools to be used in companies with a high chance of producing excellent results. The reasoning processes are an analytical tool developed by the Abraham Y. Goldratt Institute (AGI) [START_REF] Noreen | La teoría de las limitaciones y sus consecuencias para la contabilidad de gestión[END_REF], but based on the reasoning processes from the author Edward de Bono [START_REF] Dogget | A statistical comparison of three root curse analysis Tools[END_REF].

The Tools used in the reasoning processes are based on the systemic use of the logical relationships of cause-effect, necessity and generalization, so once acquired they result easy to handle and to understand.

They are used for [36]:

To achieve an exact understanding of any aspect of reality and to find way of improving it (understanding of reality).

To improve the communications capacity, because intuition is not enough to express common sense and to achieve understanding with the others. Tools uses are:

Current reality tree. Conflicts elimination. Future reality tree. Pre-requirements tree. Transition tree. These tools are used to answer the following questions.

What should be changed? What should we change to? How to produce the change? Not every tool has to be used at the same time, depending on the kind of problem are used some tools or others.

The cost/benefit balance results more favourable for the use of reasoning processes as they become more complex and therefore more difficult to maintain in a strictly intuitive level [START_REF] Rizzo | The Theory of Constraints[END_REF].

TOC in the Commercial Area

It is a generic application of the reasoning processes used in TOC. The application of TOC in Marketing and sales has as goal the adequate orientation of the company in dynamic, uncertain, open and highly competitive today markets.

The high level of uncertainty in the markets demands to provide the company with flexibility of offer. TOC looks for increasing that flexibility both in the short and the long term to reduce the vulnerability of the company towards the uncertainties of the demand and the attacks of the competition [36].

The keys of flexibility are the market dynamic segmentation starting from offers that include competitive differentials and in the long term, the concept of strategical limitations, and essential competences over which to spread the offers in function of the alternations in the markets. Segment the market, not the resources [START_REF] Agii | Asociación Goldratt Institute Ibérica, Cuaderno del Asistente del Programa Satélite de Eli Goldratt[END_REF].

We could talk widely about the differences that exist between the TOC commercial approach and the traditional offers, but this is not the goal of the present article. But it could also be resumed saying that we are looking for solutions "win to win" [START_REF] Mabin | Applying the TOC thinking process in supply chain management to achieve a strategic level win-win solution[END_REF] (process in which both sides win Examples of this application can be found in various publications: [START_REF] Goldratt | No es cuestión de suerte[END_REF], [START_REF] Servera | una experiencia de TOC en el cambio estratégico de una pequeña empresa[END_REF]; [START_REF] Agii | Asociación Goldratt Institute Ibérica, Cuaderno del Asistente del Programa Satélite de Eli Goldratt[END_REF]; [START_REF] Woehr | Unblock the Power of Your Sales Force! Delta T-Selling[END_REF]; [START_REF] Roff-Mars | Reengineering the Sales Process[END_REF].

Flow Management in TOC

The existence of flows is a common characteristic of the production environments (industrial or services), projects and distribution.

The TOC systemic management model is applied to the management of these flows in the environments defined in function of the following premises [36]:

The uncertainty existent in any environment and the dependence between the flows processes entail that its output is not determined by all the processes it goes through.

The final output must be planned in function of the clients and the resource that is pretended to regulate the flow, in other words, the desirable tactical limitation (DTL). If the limitation is inside the system. Processes performed by DTL must be planned. This should always be done whenever it is not the demand what determines the volume of output for excess of system capacity. This happens if the limitation is located in the market. Buffers (pools of shared resources among non-planned resources), are the mechanism that make possible the subordination of the rest of the system to what was planned letting a higher flexibility. Buffers can be time-related (production and projects) and resource-related in ace of distribution. TOC Flow Management applications are known as: DBR (Drum-Buffer-Rope) in Production. Projects Critical Chain. Reposition in Distribution. In this section are going to be explained the areas previously mentioned except DBR, that will be explained in more retail in the next section.

Application to Project Management

Its goal is to conclude the projects within time, budget and scope. In Project Management 2 limitations interact: time and resources. TOC handles them subordinating project to the "critical chain" through a concentrated buffers in selective points strategy. [START_REF] Goldratt | Cadena Crítica (critical chain) : Una novela empresarial sobre la gestión de proyectos[END_REF]; [START_REF] Woeppel | Projects in Less Time: A Synopsis of Critical Chain[END_REF].

According to Goldratt two problems can be found when working in projects, the student's syndrome and the Parkinson's Law (the work expands to fill all available time), therefore a Project has great chances of not being finished on time. [START_REF] Agii | Asociación Goldratt Institute Ibérica, Cuaderno del Asistente del Programa Satélite de Eli Goldratt[END_REF].

The buffer concept and its application on activities planning are considered an innovation respect the traditional schema of time Management and a big contribution to Project Management [START_REF] Briceño | Dimensionamiento Efectivo de los amortiguadores. Ponencia en el 3er Congreso Iberoamericano de Gerencia de Proyecto Cadena Crítica[END_REF].

To evaluate the state of a project it is used: [START_REF] Agii | Asociación Goldratt Institute Ibérica, Cuaderno del Asistente del Programa Satélite de Eli Goldratt[END_REF]:

1. Critical chain accomplishment percentage. 2. Rate between product buffer consume and the already finished critical chain.

3. Penetration rate in the Project buffer. The difference in the TOC Project Management is based on one side by the treatment of resources for which different activities of the Project compete, and on the other hand TOC takes into account the almost general fact that the intensity of the effort dedicated to one activity is concentrated on the time immediately previous to the milestone of the ending of itself. Protect the critical chain and not each one of the activities [START_REF] Goldratt | Cadena Crítica (critical chain) : Una novela empresarial sobre la gestión de proyectos[END_REF]; [START_REF] Woeppel | Projects in Less Time: A Synopsis of Critical Chain[END_REF].

Application to Distribution

The application of TOC to Distribution is known by the name of Reposition, it is a system for scheduling and control of the distribution system. The goal of a distribution system is to assure sells with the minimum amount of stocks in the system. The limitation is the investment in stocks.

The application of TOC to distribution is based on the reposition of used material in each point of distribution/sell from the previous distribution point. Each distribution/sell point must keep a dimensioned stock in function of the predictable consumption along the supply time from the previous distribution point [36]. Buffers management is adapted for stock control in the different distribution/sell points.

The difference in the application of TOC to Distribution is based on the containment strategy "upstream" of the materials demanded in various distribution/sell points against the "push" strategy to protect each consumption point with its own stocks in function of the local predictions, each TOC stock protects every consumption point "Downstream" in function of the global previsions, that use to be more reliable than local ones.

Inventories must not be kept as near as they can to the market. They must be located in function of their impact on the system on its global. Change from "push" to "pull" [START_REF] Agii | Asociación Goldratt Institute Ibérica, Cuaderno del Asistente del Programa Satélite de Eli Goldratt[END_REF].

TOC Applied to Production: DBR

Manufacturers have historically tried to balance capacity through a sequence of processes in a try to level capacity with market demand [START_REF] Chase | Administración de Producción y Operaciones. Manufactura y Servicios[END_REF]. TOC instead of this, tries to balance the product flow through the system. When the flow is balanced, capacities are not. This is the reason why instead of balancing capacities it must be balanced the flow of product through the system. To change from a CONWIP system to a CONLOAD system.

TOC solution begins from the premise that different resources have different capacities [START_REF] Noreen | La teoría de las limitaciones y sus consecuencias para la contabilidad de gestión[END_REF].

TOC states that some variability cannot be eliminated and the process cannot be totally balanced, especially in JOB-SHOP environments [START_REF] Cespón | La selección del sistema de gestión de la producción en empresas manufactureras[END_REF].

Appears DBR as a solution to the application of TOC to production. The problem is to supply an excellent accomplishment of delivery term as the same time as inventories are minimized.

TOC Control Measures in DBR

Two kinds of measures are proposed:

From a financial point of view (management) [START_REF] Goldratt | El Síndrome del pajar (Haystack syndrome)[END_REF]: o Net benefit. o Profitability (ROI). o Liquidity. From an operative point of view (exploitation) [START_REF] Noreen | La teoría de las limitaciones y sus consecuencias para la contabilidad de gestión[END_REF] o Net income. o Inventory. o Operation expenses. The relationship between Management measures and the 2 main exploitation measures is:

BN = T-OE ROI = (T-OE)/I

(1) There are other secondary measures like the throughoutput-dollar-day that is a measure of delivery terms accomplishment and inventory-dollar-day that measures the excess of inventory.

Conclusions

One of the main benefits of introducing TOC uses to be the generation of clear and realistic productivity indicators, related with the goal of the company.

Many companies present great hidden production capacity, caused by the waste of their bottle necks that, in a majority of cases without investments and through the implantation of TOC can flourish.

Theory of constraints is a coherent and logical frame for complex process Management knowing that is not possible to eliminate all variability.

The difference between DBR and other planning and production control techniques is the concentration of planning and control in a very few points.

While JIT can be similar to a CONWIP system, TOC would be similar to a CONLOAD system. This is a new concept.

At last we should say that some problems are usually found when introducing TOC into production and not to the rest of the company, because generally production is able to improve its own processes to the point that the limitation jumps into the market.